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