-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add API for requesting permission to receive device motion / orientation events #57
Comments
This specification is superseded by the Generic Sensors family of specifications, which include integration with the Permissions API. I think that this specification should be updated with a similar integration by requiring Is there any plan to implement Blink is currently considering similar changes to start notifying users or prompting when sites request access to device sensors. The plumbing is already implemented to manage these permissions however they are still granted by default. |
@reillyeon I may be missing something but where is that API that JS actually calls to request permission for something? There is a section in the Permissions API spec about "requesting more permission" but it seems to merely be an algorithm, no actual API for it. What we want in WebKit is really an API to ask for permission to access device orientation. Without such permission request, the content would not be getting the events at all. |
That is correct, I forgot that the Given that the Generic Sensors specifications I linked to above should be updated to include a As the DeviceOrientation API does not provide an object in the global scope like AbsoluteOrientationSensor or Notification (except perhaps DeviceOrientationEvent) what do you think about not adding a method specific to this API but instead relying on the ones that need to be added to the newer specifications? My recollection is that WebKit does not implement the |
I think relying on a Permissions API from another spec would probably work (although, I'd have to see what it looks like first). That said, it would be bit confusing to use Permissions API from another (newer) API and predicate using the (older) API on it. How about for the 'devicemotion' events, would it be a Honestly, the fact that the names do not match would be super-confusing IMO. I get that the DeviceOrientation API does not have a global scope object at the moment but it seems like it could have one. Or I actually like the idea of adding static requestPermission() methods to the existing DeviceOrientationEvent / DeviceMotionEvent interfaces. |
@jyasskin probably knows the status of that work. |
I believe that use of either API should be predicated on the same permission since they expose the same capability. Having two functions that request the same permission feels like unnecessary bloat but I'm willing to accept that in favor of not confusing developers.
I don't disagree. It sounds like
That seems reasonable if doing this solely through the Permissions Request API is untenable. |
So if I understand correctly, it would look like:
This does not look bad actually. |
You need both Promise.all([navigation.permissions.request({ name: “accelerometer” }),
navigation.permissions.request({ name: “gyroscope” })])
.then(results => {
...
}); |
I think w3c/permissions#158 is the most recent discussion about |
@annevk Based on w3c/permissions#158, it looks like Mozilla considered gating the old deviceorientation / devicemotion events behind a permission as well. Did you end up doing it or do you still have plans to do so? |
Yes, I discussed it internally a bit and I do not think we are interested in the generic permissions.request(). A few things we could do:
I would have preferred option 1 I think but given the mess with permissions it seems, I am starting to think about option 3. |
From the study referenced in that Wired article (PDF paper: https://sensor-js.xyz/webs-sixth-sense-ccs18.pdf) the recommendations given to browser vendors are as follows:
This specification could instead be updated to include normative text that limits the sampling rate for At that point, a permissions API could then be introduced for accessing higher frequency sensor data from devices. Or, just require higher frequency sensor data to be obtained only via the Generic Sensors API going forward. Incremental improvements based on these research recommendations seem possible. Putting all access to these events behind a permission dialog seems like a Really Big Gun to start with. It may still be required to eventually look at that approach but for an API that has been available for 8+ years this could be extremely damaging for legitimate use cases given its widespread adoption. |
This would not be acceptable on WebKit-side. Limiting sampling rate for those events would mitigate fingerprinting but not some of the other privacy issues (e.g. The site can tell if the user is standing or laying in bed). We'd require a user gesture / permission for any of those events. We could also disable the API altogether as @annevk mentioned. |
Determining which way the user is pointing their device is the entire purpose of this API. Enabling usage for legitimate sites while preventing fingerprinting seems to be the objective of this proposal based on the contents and research in the cited studies. The studies you referenced to justify this addition do not recommend putting this behind permission prompts as a first course of action. Those studies present many other options that could be considered. Why the immediate and full rejection of all recommendations from your own references? |
Though the attached research paper investigated quantization, (a) It acknowledged that quantization only reduced the fingerprinting surface area, and did not eliminate it; (b) It acknowledged that quantization, though it did not break a toy game, might still break other important use cases; (c) It did not address at all concerns like key logging and other forms of privacy invasion, which are mentioned in the Wired article; (d) It did not address the unusually high power impact of the motion and orientation (which we probably should have mentioned earlier). I don't think we reject quantization as an area of investigation. Rather, we acknowledge that quantization is an area of investigation, and we also acknowledge the need to solve this privacy and security problem without waiting for the conclusion of an open-ended investigation. |
I am in favor of adding
(2) is necessary to maintain compatibility with existing sites and the existing information leaks are partially mitigated by (3). (1) provides a framework for enabling (a) future use cases that require more data and (b) a move towards reducing the amount of data available without a permission in a gradual fashion in order to allow sites to adapt. |
@reillyeon If we must add permissions to this API then your approach seems like a least disruptive way to do that - progressively reducing the data available (assuming (2) continues to be available by default without permissions). We could also add a relevant console warning message during this process informing developers of the planned change to access in future releases. What the research in https://arxiv.org/pdf/1605.08763.pdf suggests is that a combination of reducing the frequency of events + sensor obfuscation + sensor quantization would be enough to significantly fix security and privacy concerns in this thread without significantly disrupting web app UI and UX for legitimate actors. Permission dialogs or any changes that disrupt a user's flow while using a web app should be considered as a last resort (when all you have is a hammer...). There is going to be a disruptive impact of adding permission requirements for sensor events on the nascent web VR/AR/360 ecosystem. e.g. Developers will need to start wrapping their calls for sensor events within user-gesture events IIUC. It is unclear if or how permission requests would display if called from within e.g. iframes (with e.g. correct Anything we can do to reduce the impact of blocked requests and disrupted UI/UX experiences within this ecosystem - gradually introducing such disruptive changes only if all other techniques have been tried and deemed unsatisfactory after further studies, making developers aware of these updates via e.g. |
In summary, changes could be made immediately to implementations by obfuscating, quantizing and/or reducing the rate of sensor event data emitted without impacting the existing API footprint or validity/conformity of implementations to this specification. We could also immediately add security and privacy considerations to this effect to this specification based on these emergent research studies since last publication. We can then continue to discuss additional requirements / API changes as required, hopefully with a view to reducing the impact of those changes on current legitimate consumers of this API. |
I would very much appreciate a more sober reflection on how this might possibly affect developers and users. The privacy concerns are perfectly valid. But removing the API, or locking it down, will wipe out a complete genre of interactive online games. Not only the ones on the web, but rather those distributed to mobile devices via Cordova (et al.). Additionally, how do you intend to communicate this permission request to the users? What's the difference between device acceleration and orientation data for the end-user? What if the user only permits either of them? Based on what rationale? What if the user does not understand the requested sensor function? Does requesting permissions protect users? Or does it simply limit the “tracking” to big platforms that provide so many features that there's at least one with a credible use case for one of these APIs, opening them for the whole rest of the platform? I'm unconvinced these questions have sufficiently been answered. |
@richtr you have two-out-of-three implementers saying that's not enough. That doesn't seem like a good summary to me. |
There are many softer approaches to be explored here as opposed to implementing a black-and-white “on/off” switch straight out of the gate. Following your current course will effectively destroy nascent VR/AR/360/gaming companies and industries and pretending otherwise is silly. I want to avoid a cliff-edge scenario where access to these sensors would change overnight without proper planning — particularly in browsers where no platform-alternative browser engines exist. For that purpose there are many many intermediate steps, recommended in the cited papers - before you need to implement on/off switches for an 8+ year old API. Jumping straight for that approach is incredibly hostile to web developers. Have you evaluated the full impact that would have? That is the purpose of the summary above. |
I believe @geoffreygaren’s comment above explains why we want a permission api and user consent in WebKit. For us, it is either this or disabling the API by default until we can make it safe. The other proposals do not address all our concerns as explained by Geoff. |
All content relying on the API will break overnight. No replacement sensor access is provided on WebKit (Generic Sensors API). No alternative browser engines are allowed on iOS so there is no way to keep any applications relying on those APIs running. No deprecation strategy is planned warning developers of disruption or revocation of sensor data before they land in Safari. A cliff-edge backward-incompatible fall-off of usage is deemed the correct way to modify an extensively used 8+ year old web platform API. Browser-based content and embedded web view content in native applications will cease operation in all of the following use cases:
Multiple proposals exist to make the emitted motion sensor data both a.) still useful for legitimate use cases and b.) resistant to raised security and privacy concerns by refining/limiting the data emitted in different ways. Those solutions will not be considered further because the effectiveness of those solutions needs further investigation/research even though they are cited as potentially resolving all current security and privacy concerns by the original investigators. Instead we will modify the API invocation to require permissions/user-gesture or just remove the whole API because it is easier, less implementation work and resolves all security and privacy concerns because then there are no use cases or usage anymore. Now contrast this to the alternative approach/summary I posted above. |
How many of these things are implemented as web apps/views? And why would requiring them to ask permission be that big of a deal? There is exactly zero people who should be able to access any of this data without asking for permission, in my opinion. And I honestly couldn't care less how many business models or apps would be affected by having to ask permission. If the app is scared of asking for permission first, I don't want them having my data anyway. |
Companies like UnifyID use gyroscope data for user gait profiling. I would definitely prefer if gyroscope data required permission to access. |
Sacrificing UX in the name of a slight privacy increase is regressive at best. Not only will most end-users not understand what granting the permission actually entails, it just creates friction when trying to build solutions that “just work.” In HTML5 eBook reader I created I actually leverage device orientation to determine when someone is laying down to suggest turning on night mode at certain hours. There are plenty of valid reasons not to put these standard features behind a permissions prompt. Throttling polling rates is a decent mitigation. |
A note on scoping with my chair hat on: As @reillyeon pointed out earlier, DAS WG's position is this specification is superseded by the Generic Sensors family of specifications which include integration with the Permissions API. The DAS WG considers this spec to be in maintenance, and as such no new feature work per charter. The charter is not super clear on this, says "fix remaining known issues and to finish" so I'm open to discussion if someone feels strongly we should add new API surface to this spec. An alternative transition plan to browsers who are planning to unship this legacy feature sometime in the future would be to first implement (applicable parts of) the new API surface (see Generic Sensor API and related concrete sensors at https://www.w3.org/das/roadmap), and deprecate the legacy API surface only after a reasonable grace period during which web developers are recommended to migrate to the new API that provides the permission hooks and other privacy enhancements. |
This is disappointing. I hope the API will make it into an update soon. For anyone looking for a workaround, the best thing to do is to detect the disabled state via a timeout and clear it in the event handler. Something like this:
|
To add to @neave's workaround, it appears the deviceorientation API still works in Chrome, so you could prompt the user to open the page in Chrome if you detect that deviceorientation is broken. Something like:
Not a great solution, but possibly the easiest option for the user given the current state of things. |
@cdumez it'd be nice if toggling the switch at |
Fun edge case... iPhone X + iOS 12.2 + "Motion and Orientation Access" on: I guuuesss we can add a some window.navigator.userAgent checks, but getting in to the "pretty janky checks" arena :\ |
Regarding the last couple comments, please report implementation-specific issues to the appropriate issue tracker. |
@cdumez Does iOS 12.3 add an implementation for the request permissions spec? |
For WebKit and iOS questions please use bugs.webkit.org and bugreport.apple.com respectively. This is not the right place to ask about implementation status in particular engines. |
@reillyeon is there a link to an existing bug that we can track progress and get updates on? |
I searched bugs.webkit.org but didn't find one. @cdumez might be able to provide a link. |
Bugs.webkit.org is not a way to track when a particular feature ships. Apple also does not comment on when a particular will ship. @nbutko Please coordinate internally. I already asked Erik from 8th Wall to file a bug on bugreport.apple.com and he did (49748962). When the feature ships, this bug should get closed and you will be notified. You could also simply test if DeviceOrientationEvent.requestPermission is defined in any new build that comes out (it is not in 12.3), or even ping me on Twitter (@chris_dumez) where I am already in contact with 8th Wall. Just please let's stop pinging on this GitHub issue. |
For people interested in trying out this new API on iOS, I suggest installing the iOS 13 developer beta 1. If you find issues, please file them at https://bugs.webkit.org, not here. I am also happy to answer questions on Twitter (@chris_dumez) or at WWDC WebKit Labs this week for those attending. |
Hi @cdumez I'm having some problems requesting permissions for Motion Sensors on WkWebKit. My team was able to succesfully request permisions when we were navigating using Safari. But when using a WebView in App, althought we use the same function and calls, the permission window does not appear. We have already tested adding further permissions to the iOS app in our Info.Plist, but it's just not working. Any ideas we could pursue? Thanks in advance for any guidance! |
This is not the place for WebKit support. Please file bugs on bugs.webkit.org or ping me on Twitter. |
Hi @chris_dumez I filed the bug here, let me know if there is any further specification that should be looked at: https://bugs.webkit.org/show_bug.cgi?id=203287 |
Useful articles for those wanting to implement this in their client code, showing implementation: |
Just a quick note for anyone who keeps running into |
Hi @cdumez I have the same problem |
iOS 12.2+ (Privacy switch turned on):
iOS 12.2+ (Privacy switch turned off):
|
@yoyo837 thank But I want to know how WKWebView turned on in ios13 |
Bugs.webkit.org is the right place for WebKit support. Also, I have just tried https://www.audero.it/demo/device-orientation-api-demo.html in a WKWebView and it worked fine. To test, I used the WebView app in the App Store. |
I'm locking this issue. Please use the WebKit issue tracker for questions about WebKit's implementation. |
Due to the privacy issues related to this API (e.g. https://www.wired.com/story/mobile-websites-can-tap-into-your-phones-sensors-without-asking/ and https://arxiv.org/pdf/1605.08763.pdf), we are considering adding to WebKit a permission dialog in order to ask the user if they want to expose their device orientation/motion to the Website.
However, because trackers already register such event listeners on top sites, we are worried about the risk of over-prompting. We wouldn't want this prompt to start showing on a lot of top-sites.
To address the issue, we'd like to propose adding a new API allowing the page's script explicitly ask for permission to access the device / motion. We think we should also require a user-gesture to call this new API.
It could look something like this (similar to Notification API):
What are your thoughts?
The text was updated successfully, but these errors were encountered: