What we do and don't expose to client toolkits

[Daniel van Vugt]

That's an important point worth highlighting again:

"Wayland does prevent clients from knowing the absolute positions of
surfaces, but not for security reasons. More for being able to do
input transformations and non-traditional compositing."

Indeed compositing is potentially free-form if you get creative like in 
Compiz. This means a surface doesn't have one position on screen - it 
might have multiple positions like "Always on visible workspace". And 
its pixels might not be the same size as those of the server either. 
Finally your screen might not even be a single two dimensional space; it 
might be multiple workspaces with different coordinate systems or even 
3D. So for many reasons it could create bugs in future if you were to 
let the client know its absolute position.

Nothing controversial here, just a reminder...


On 02/09/16 22:27, William Hua wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> I asked Jonas Adahl how the Wayland side is dealing with this, and
> roughly:
>
> Wayland doesn't see any of this as a security concern and broadcasts
> the geometry of the display to clients:
>
> https://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml#n
> 2364
>
> So, the menu positioning feedback is no concern either, and they
> currently have an unstable protocol that notifies the client of where
> its popup surfaces were actually positioned, relative to the parent
> surface:
>
> https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg
> - -shell/xdg-shell-unstable-v6.xml#n1018
> (same link referenced by Alan)
>
> Jonas said there's some plans towards making this stable, but didn't
> make any guarantees.
>
> Wayland does prevent clients from knowing the absolute positions of
> surfaces, but not for security reasons. More for being able to do
> input transformations and non-traditional compositing. And if a client
> goes out of its way to "probe" for its absolute position using this
> feedback mechanism, that may end up working terribly since they're
> making assumptions about undefined behaviour. For example, workspaces
> larger than the display that are able to pan around.
>
> Anyways, if we continue to specify display geometry as private
> information, Mir needs to be smart enough to detect when a client is
> abusing this new feature and disconnect them. Easiest thing I can
> think of is a simple rate limit. We can also re-evaluate if it is
> still worthwhile to prevent clients from knowing the geometry, but I
> don't know the security implications there or the history behind this
> decision.
>
>
>
> On 2016-09-02 09:40 AM, Alan Griffiths wrote:
>> On 01/09/16 12:02, Alan Griffiths wrote:
>>>
>>>
>>> Thoughts and suggestions for the right way forward please.
>>>
>>
>> A data point from Wayland
>> (https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/
> xdg-shell/xdg-shell-unstable-v6.xml#n1018):
>>
>>  <event name="configure"> <description summary="configure the popup
>> surface"> This event asks the popup surface to configure itself
>> given the configuration. The configured state should not be applied
>> immediately. See xdg_surface.configure for details.
>>
>> The x and y arguments represent the position the popup was placed
>> at given the xdg_positioner rule, relative to the upper left corner
>> of the window geometry of the parent surface. </description> <arg
>> name="x" type="int" summary="x position relative to parent surface
>> window geometry"/> <arg name="y" type="int" summary="y position
>> relative to parent surface window geometry"/> <arg name="width"
>> type="int" summary="window geometry width"/> <arg name="height"
>> type="int" summary="window geometry height"/> </event>
>>
>> So (in their current "unstable" anyway) they are returning the
>> relative placement. And running the risk of sneaky clients probing
>> the display boundaries.
>>
>> I claim this as "prior art" and propose that we do the same by
>> sending a MirRectangle notification.
>>
>> Any objections before the weekend please.
>>
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJXyYxRAAoJENtfC4FFqZmIgQkP/24EVx69iWlyjhlWeScYexeF
> mVp8bhcORoLLxOn8ITKUGNqijrPYstDaaS8tr1QaMNZ/bZmqGi1pEUDnRTGitTn+
> pn26Y+csOqiV+NducloBYhxVFkQeOMNciV0eWSFvPR8OF0J/Kv0Jti+5MNb5JTSc
> y+L/zcHDcQFKb1Q9hmlinIZ97GSGiKP7vp8tzzdiehgFcTYncRYryAMqcIern6iD
> s27gQpZkRLGryMdRo1Bcl17zoH5m5E3X6dFxN0j4CxXTVK0enSY454ODVPYHIcdm
> Tm/Az5ufB4u1mP4yhWT4KN3FV9Obt1by7PiHfjChObPWoIhNObcA+2WfG0C4w+Kf
> sLLrO+gKRXqfz6XA8WW4clzxCMRdpIhbKNbModZiHjUSQ7e0ODmD/YRE3f7yy/LF
> NcU4mu6gAiobyqb1kbtI/BLUHPfFk2JCv61FUOnA3kzLcjf0OY8L/ySOSc+SXMxr
> L3Ew6MDkvQXpilDMHvuJjNPzu9nJQIIDAYJ3YLJQRGzPm9jjPVPVf0qnQG/ptUu1
> KbWE0WqAzEwcOtKuMNJO2+nZUHADV4OKzZjQJx8/hLoHN0e14wTk+aSBCsuo6y2v
> e2rwhIX8eTVfasmtDgb3XqlDbE9CTaqMwosEaPsCNq/ypI2EG2lcZXqv42+ornYc
> L0j0R3PUl6AJLODN4rMg
> =iIEA
> -----END PGP SIGNATURE-----
>