-----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----- -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
