You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
{{ message }}
This repository has been archived by the owner on Jul 23, 2020. It is now read-only.
There are two independent concerns that seem applicable here.
First, there's the normal restriction to applications in the current seat, just as with local input devices or audio devices. I would suggest handling this via the standard "uaccess" mechanism.
Second, even for such applications that qualify, sufficiently clever applications could infer keyboard or mouse events from high-precision accelerometer information. For sandboxed applications that intentionally do not have access to input devices when not in the foreground, that could be a concern; however, for non-sandboxed applications, I don't think this is worth solving. So, I would suggest documenting that access to raw accelerometer data (rather than heavily cooked data like orientation in 90 degree increments) can potentially leak information about user input ,and then letting sandboxing mechanisms handle this via their permissions mechanism.
Only foreground applications? Only to applications in the current seat? Should applications request it through an agent a-la Geoclue?
The text was updated successfully, but these errors were encountered: