Add API for requesting permission to receive device motion / orientation events

[cdumez]

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):

[Exposed=(Window)]
interface DeviceOrientation {
  [Exposed=Window] static Promise<boolean> requestPermission();
};

What are your thoughts?

[reillyeon]

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 "accelerometer" and "gyroscope" permissions for deviceorientation and devicemotion events and additionally "magnetometer" permission for deviceorientationabsolute events. This would match the existing Orientation Sensor, Accelerometer, Gyroscope and Magnetometer specifications which provide access to the same or similar data.

Is there any plan to implement navigator.permissions.query() in WebKit?

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.

[cdumez]

@reillyeon I may be missing something but where is that API that JS actually calls to request permission for something? navigator.permissions.query() seems to only query, not request.

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.

[reillyeon]

That is correct, I forgot that the navigator.permissions.request() method has been removed in favor of each specification integrating its own method for requesting more permission, but calling into the algorithm you mention. A cursory look at query() made me think that that had been integrated into it instead.

Given that the Generic Sensors specifications I linked to above should be updated to include a requestPermission() method similar to Notification.requestPermission().

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 deviceorientationabsolute event and so implementing a single RelativeOrientationSensor.requestPermission() method would suffice for your purposes.

[cdumez]

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 LinearAccelerationSensor.requestPermission() ?

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.

[anssiko]

navigator.permissions.request() is specified in https://wicg.github.io/permissions-request/

@jyasskin probably knows the status of that work.

[reillyeon]

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.

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.

How about for the 'devicemotion' events, would it be a LinearAccelerationSensor.requestPermission() ?

devicemotion events should require the "accelerometer" and "gyroscope" permissions which conveniently is the same as the ones I think should be required for deviceorientation events so a single call could provide the necessary permissions for either event type.

Honestly, the fact that the names do not match would be super-confusing IMO.

I don't disagree. It sounds like navigator.permissions.request() is not as abandoned as I thought it was. That API feels like a better solution.

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.

That seems reasonable if doing this solely through the Permissions Request API is untenable.

[cdumez]

So if I understand correctly, it would look like:

navigation.permissions.request({ name: “gyroscope” }); // For DeviceOrientationEvents
navigation.permissions.request({ name: “accelerometer” }); // For DeviceMotionEvents

This does not look bad actually.

[reillyeon]

You need both "gyroscope" and "accelerometer" for both so it would look like:

Promise.all([navigation.permissions.request({ name: “accelerometer” }),
             navigation.permissions.request({ name: “gyroscope” })])
    .then(results => {
      ...
    });

[jyasskin]

I think https://github.com/w3c/permissions/issues/158 is the most recent discussion about permissions.request(...), and it links to the older discussions. Firefox folks have generally been opposed, Chrome's been in favor, and Edge and Safari have ignored it. I haven't been paying a lot of attention in the last year so can't really help guide here.

[cdumez]

@annevk Based on https://github.com/w3c/permissions/issues/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?

[annevk]

@cdumez we haven't made progress on this yet I believe, but I strongly suspect we're still interested. Perhaps not in a generic request() method though, but something specific for this API. Either that, or seeing if we can remove the API altogether (we don't expose it so widely I think).

cc @ehsan

[cdumez]

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:

1. add a permission request api to this spec
2. drop the api altogether but there are some legit use cases so it would be unfortunate.
3. maybe require a user gesture when adding the event listener (and then we’d show a prompt). Avoids over prompting and adding any api.

I would have preferred option 1 I think but given the mess with permissions it seems, I am starting to think about option 3.

[richtr]

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:

• W3C’s recommendation for disabling sensor access on crossorigin iframes [80] will limit the access from untrusted thirdparty scripts and is a step in the right direction. However, Safari and Firefox are the only two browsers that follow this recommendation. Our measurements indicate that scripts that access sensor APIs are frequently embedded in crossorigin iframes (67.4% of the 31 444 cases). This shows that W3C’s mitigation would be effective at curbing the exposure to untrusted scripts. Allowing sensor access on insecure pages is another issue where browsers do not follow the W3C spec: all nine browsers we studied allowed access to sensors on insecure (HTTP) pages.

• Feature Policy API [16], if deployed, will allow publishers to selectively disable JavaScript APIs. Publisher may disable sensor APIs using this API to prevent potential misuses by the third-party scripts they embed.

• Provide low resolution sensor data by default, and require user permission for higher resolution sensor data.

• To improve user awareness and curb surreptitious sensor access, provide users with a visual indication that the sensor data is being accessed.

• Require user permission to access sensor data in private browsing mode, limit resolution, or disable sensor access all together.

[80] Rich Tibbett, Tim Volodine, Steve Block, and Andrei Popescu.

2018. DeviceOrientation event specification. https://w3c.github.io/deviceorientation/

[16] Ian Clelland. 2017. Feature policy: Draft community group report. https://wicg.github.io/feature-policy/.

This specification could instead be updated to include normative text that limits the sampling rate for deviceorientation, deviceorientationabsolute and devicemotion events to less than or equal to 60 Hz as effective mitigation to fingerprinting and other security and privacy issues.

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.

[cdumez]

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.

[richtr]

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?

[geoffreygaren]

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.

[reillyeon]

I am in favor of adding requestPermission() methods to DeviceOrientationEvent and DeviceMotionEvent (as well as the equivalent Generic Sensors APIs). Acknowledging WebKit's concerns I think it is reasonable for an implementation to choose to completely deny permission for these APIs by default if they wish to. Blink's current plans are to,

1. Implement a permissions API allowing a site to request a particular level of precision and/or frequency.
2. Allow access to the existing level of precision and frequency by default.
3. Notify the user that a site is using the device sensors and allow them to revoke permission.

(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.

[richtr]

@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 allow attributes cross-origin).

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. console.warn before they land and not just landing these changes one day in mainline browsers without letting existing API consumers adapt - would be very welcome here.

[richtr]

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.

[19h]

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.

[annevk]

@richtr you have two-out-of-three implementers saying that's not enough. That doesn't seem like a good summary to me.

[richtr]

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.

[cdumez]

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.

[richtr]

For us, it is either this or disabling the API by default until we can make it safe.

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:

• Games and gaming
• Navigation
• Virtual Reality
• Augmented Reality
• 360 viewers (videos, panoramas)
• 3D scanning
• Gesture recognition
• Step counters
• Physical activity monitoring
• Sleep monitors

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.

[zchrykng]

Browser-based content and embedded web view content in native applications will cease operation in all of the following use cases:

• Games and gaming
• Navigation
• Virtual Reality
• Augmented Reality
• 360 viewers (videos, panoramas)
• 3D scanning
• Gesture recognition
• Step counters
• Physical activity monitoring
• Sleep monitors

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.

[eligrey]

Companies like UnifyID use gyroscope data for user gait profiling. I would definitely prefer if gyroscope data required permission to access.

[andrewmd5]

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.

[anssiko]

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.

[anssiko]

According to an article discussing iOS 12.2 beta features:

• Accessing sensor APIs is now disabled by default, so no accelerometer, gyroscope or magnetometer APIs are working unless the user enables a Settings option under “Safari”

Assuming this beta feature will ship in stable (edit: it will according to the release notes), it will diverge from Blink's plan to allow access to the existing level of precision and frequency by default.

A possible impact on iOS users is that websites start to show bespoke modal dialogs to iOS Safari users that ask to enable the "Motion & Orientation Access" option in iOS Settings (similarly to those "Add to homescreen" bespoke dialogs).

That seems like a suboptimal UX for iOS users, so I'm interested in finding a consensus position among implementers that would enable a better UX for all implementers. If requestPermission() is a fix all implementers can live with, we can make a case that it is needed to "fix a remaining known issue" in the API and see if anyone has concerns, and spec it. As said, the charter has some leeway in this regard, so we could likely pull that off with all implementers on board.

Seeking feedback from @cdumez and @reillyeon (with his Blink hat on).

[larsgk]

If the aim is to cripple/disable 3rd party ads/scripts to access sensor data for evil intentions, using Feature Policy seems to be a good way forward. Has this been considered? If we want to prevent the main page from accessing sensors, we have to consider how requiring installation of a native app would provide better assurance - if any at all.

In addition, permissions could be granted when installing the web application (to home screen/pwa). Has this been considered?

If too many features require user approval or flipping switches in the global settings, the effect will most likely disappear (e.g. like most people run as Administrator on Windows as the alternative is just too cumbersome).

[cdumez]

@anssiko What sort of feedback are you looking for? I filed this issue so requestPermission() is definitely sometime we want and it would definitely be a better situation than having the API disabled by default. @annevk was also on board with such API, so that's 2 implementers. If Blink wants to keep providing access to the API without user consent, this is fine, the requestPermission() could always be a no-op for them.

@larsgk FYI, third-party content already does not have access to the API in WebKit so this discussion is about first party for us. Also note that the whole reason we want a permission API is to avoid over-prompting the user since there is a lot of content out there already using the API but not actually requiring it (e.g. tracking). With regards to Web Applications (PWA), we'll need to discuss this internally, this is more of a system policy and I do not think this should be spec'd.

[anssiko]

@cdumez thanks for confirming your position. That’s what I meant.

@reillyeon would you be fine with the proposed requestPermission() that could in your case be no-op or return a promise that immediately resolves?

All - any concerns with the proposal, please let us know.

[griffin2000]

So what is the timeline on adoption of both the new Sensor API and the new permission features? Turning off this feature on IOS completely breaks our product! This is part of the web standard that we were using, and we've put a great deal of effort into developing for. To have it suddenly stop working is incredibly frustrating.

[reillyeon]

@anssiko, I am positive on this. Blink's implementation will start as a no-op that immediately resolves with "granted" but I agree that it is important for it to be present nonetheless.

@cdumez, can you put together a draft of this change in a PR so we can discuss the specifics on how this will be specified? From the preceding discussion it sounds like we have settled on extending the DeviceOrientationEvent and DeviceMotionEvent interfaces with something like,

enum PermissionState {
  "granted",
  "denied",
};

[Exposed=(Window)]
interface DeviceOrientationEvent {
  static Promise<PermissionState> requestPermission();
};

[Exposed=(Window)]
interface DeviceMotionEvent {
  static Promise<PermissionState> requestPermission();
};

These are a specialization of the so-far unspecified requestPermission() method that should be added to the Generic Sensor API that will likely have parameters to control things like requested sampling frequency.

[griffin2000]

@richtr The permission pop up seems the obvious choice for this. The applications you list above (like ours) are absolutely valid uses of the API, but it wouldn't be at all problematic to have a popup. We also use the camera, and its absolutely straight forward to ask for permission when we do. It seems the only case where it would be problem is if you are doing something where it is not clear to your user that you are using the accelerometer. And in that case telling the user via a pop up is even more important.

[cdumez]

@reillyeon Yes, your proposal looks good to me. With regards to the PR, I'll try and make one soon but this is a busy period for me.

[rigel-prime]

Rigel from 8th Wall here - I updated an iPhone 8 Plus to iOS 12.2b today and noticed it broke several sites due to the issues laid out above. I filed a radar earlier and posted an openradar here: https://openradar.appspot.com/47645367

Can we expect by the time iOS 12.2 is released publicly, to have had sufficient lead time to update our software to accommodate any of the proposed changes so that none of our customers' websites break? There are several high profile VR/AR projects currently in production that this would directly affect. Thank you.

[anssiko]

(Related: I submitted a PR #62 that converts the spec source from its custom HTML format into Bikeshed format to make it easier to edit the spec as well as to publish updates using the W3C's publication system Echidna. @cdumez when you start working on the PR, I recommend you base it off of the Bikeshed source.)

[TimvanScherpenzeel]

Even though I agree with the general premise I have a few concerns:

The existing VR / AR / 360 camera viewers / experiences will break (similar to the autoplay audio policy did on Chrome). If certain permissions have existed on the web for a long time you cannot remove them without breaking anything.

I'm not sure if I agree with the proposal of @griffin2000 regarding a pop-up asking for permissions. I dread going to any news websites because as soon as the page loads I get bombarded with permission requests and I refuse them 99.9% of the time.

If we want the web to be able to compete with native applications (think seamless AR / VR) developers need powerful tools and be able to create a user experience that does not feel like installing an app everytime to go to a website. In my opinion the web should feel like an open space to surf and explore, not a walled off section with border security for each website.

How exactly are advertisers exploiting these sensors in a way that is deemed so disastrous and unsafe that the rest of the people who try to push the web into new creative directions have to suffer?

[richtr]

I'm exasperated by the level of cognitive dissonance in this discussion.

The 3 recommendations to resolve all fingerprinting or key logging ability in this API and to prevent a breakdown of all existing web developer code are as follows:

• Obfuscation: Add a random constant in the range [-0.05, 0.05] to all deviceorientation data and [-0.005, 0.005] to all devicemotion data on each new invocation of the API. Optionally adjust that value during idle periods of inactivity for dynamic obfuscation (when e.g. the device is placed on a table).

• Quantization: Round all sensor data to a discrete set of values. For deviceorientation round the data emitted to e.g. 2 decimal places. For devicemotion round the data emitted to e.g. 4 decimal places.

• Frequency: Optionally, reduce sensor data frequency from 60Hz to e.g. 30Hz.

Why are these solutions, that do not impact the footprint of this API, still not being seriously considered? Even if that turns out to be an interim solution it presents a more positive development of this API than the disruptive, backward-incompatible changes being considered.

How would these updates not strike the correct pragmatic balance of resolving all privacy concerns while protecting access for legitimate users?

If these low-impact fixes for the original reported issue continue to be ignored this is what a responsible deprecation process for established Web APIs looks like: https://developers.google.com/web/updates/2018/09/chrome-70-deps-rems#deprecation-policy

Nobody has ruled out a permissions approach for this API if that is the least-worst acceptable solution. I'm just surprised that there is such little interest in progressively experimenting and fixing issues according to the recommendations of all studies in to the issues.

[reillyeon]

@richtr The problem with those recommendations is that they still break existing applications but in more subtle ways. As outlined in my previous comment before we can realistically restrict the fidelity of the data available via this or the Generic Sensors API there needs to be a mechanism for developers to express to the user agent the level of data fidelity required for their particular application. The proposed requestPermission() amendment to this API, and the additional parameters to the Sensor constructor in the Generic Sensors API, are that mechanism.

[othermaciej]

We'd adopt the requestPermission() proposal here in Safari if there is general agreement on it.

Regarding @richtr's comment, we consider this to be a privacy and security hole that is being actively exploited in the wild. Given that, we don't think it is acceptable to do the slow deprecation path or to experiment with different forms of partially limiting the data to see if it works. If the stakes were lower, we would not feel the need to aggressively remove.

[erikmchut]

@richtr - I'd be concerned that reducing the quality of the sensor data would significantly degrade the quality of existing AR and VR uses of this standard API. In these webapps, (many of which already request camera permissions), an additional devicemotion permission would be much preferable than materially affecting tracking quality or breaking synchronicity with the camera.

[richtr]

@erikmchut Your points are valid wrt VR/AR usage. These changes would increase "motion sickness" considerably.

However, the DeviceOrientation Events API is not the correct API to use to implement VR/AR. The fact it is used on WebKit-based browsers is because it currently provides the only way to polyfill access to requisite sensor data in those browsers.

There are other/better APIs for Web VR/AR implementations available for implementation:

https://immersive-web.github.io/webvr/spec/1.1/ https://www.w3.org/TR/gyroscope/

The issue is that these APIs are not currently supported in WebKit. Instead of implementing those APIs, the proposals here suggest we instead modify/remove this existing API. Unfortunately that breaks other "progressive enhancement" type uses of this API where it doesn't make sense to show a permissions prompt to the user.

What I proposed above that we make deviceorientation and devicemotion un-fingerprintable and un-key-loggable by making it a source for lower resolution data right now. A lot of non-VR/AR use cases are also at risk here that do not require such precise data.

On implementation of the above specifications in web browsers we would then have the following scenario:

1. Low-resolution deviceorientation and devicemotion data, that eliminates fingerprinting or key-logging abilities remains available by default without permissions.
2. High-resolution sensor data is available via both the WebVR API and the Generic Sensors API (see above for links) with user permissions being acquired first.

This represents a way to keep things moving on a web page that need to move (e.g. motion parallax effects, custom gesture recognition, CSS animations attached to device pose, etc) with a path for developers to "upgrade" that default low-level data access to something suitable with the permission of users via the APIs listed above. By introducing a permissions model here we lose the ability to do "progressive enhancement" visual effects or features (e.g. https://github.com/rikschennink/shiny).

@othermaciej thank you for your response.

If the stakes were lower, we would not feel the need to aggressively remove.

This is detrimental to every stakeholder concerned and a real shock to the established system. I'm not aware of any other such widely used Web API receiving the same treatment previously. As such it feels unprecedented in the history of Web Standards to take such a drastic course of action instead of progressively fixing what is a fixable Security and Privacy issue.

[geoffreygaren]

@richtr You keep asserting that obfuscation, quantization, and frequency reduction solve the privacy and consent problem.

But the only sources cited in this conversation acknowledge that all such efforts so far have failed to solve the privacy and consent problem.

Regarding fingerprinting, Das-Borisov-Acar-Pradeep acknowledge that users who want privacy still need to “disable sensor access all together” (Section 7, DISCUSSION AND RECOMMENDATIONS”), and they “recommend browser vendors to rethink the risks of exposing sensitive sensors without any form of access control mechanism in place” (Section 8, LIMITATIONS). Das-Borisov-Chou-Mughees acknowledge that their best effort to curtail fingerprinting still has a Random Forest F-score of 26% (Section 6.2, Effectiveness of Countermeasures).

Regarding key logging and other forms of eavesdropping, nobody has suggested that obfuscation, quantization, or frequency reduction is a mitigation at all. In fact, Das-Borisov-Chou-Mughees demonstrate that these techniques intentionally preserve substantial signal and, by design, “many applications of sensor data are unlikely to be affected” (Section 7, CONCLUSION).

Regarding battery life, obfuscation, quantization, and frequency reduction use the same underlying sensors, so they plainly do not resolve the problem.

Can you cite some evidence to support your assertion that obfuscation, quantization, and frequency reduction solve the privacy and consent problem?

Or, if the solution is as simple as you say it is, you might as well just code it up and we can test it empirically.

Until then, we have an absence of evidence to support your assertion, and a presence of evidence to refute your assertion, so we have to conclude that your assertion is without merit.

[TimvanScherpenzeel]

For any new readers: earlier in this thread the new study on https://sensor-js.xyz/ is referenced. The relevant paper can be found here: https://sensor-js.xyz/webs-sixth-sense-ccs18.pdf. From what I understand the main issue is the misuse of the sensors for browser fingerprinting and various ad-tracking techniques (such as distinguishing between bots and real users).

In the study some other studies and exploitations are referenced (reading PIN's, reading keystrokes, sniffing browser history) which many have already said in the past to be highly impractical and extremely difficult to pull off in a short amount of time in the confined space that is the web browser. They are neat hacks (see: https://blog.lukaszolejnik.com/stealing-sensitive-browser-data-with-the-w3c-ambient-light-sensor-api/) but I have problems considering them to be actual threats.

The paper is also not clear on how this raw data is actually used to help towards browser fingerprinting seeing as the sensor data rapidly changes over time and is not a consistent identifier over a longer period of time. If someone could explain that to me in more detail it would be highly appreciated.

I think there is plenty we can do to make it a lot more difficult for advertising networks to misuse these sensors (for example block any 3rd party iframe embeds / cross-origin sources from using these sensors by default, even secure sources). Browser fingerprinting is still very successful and won't be affected in any major way by this change: just have a look at fingerprinting through WebRTC / WebSocket / canvas / font detection / plugin support / evercookie / user agent / WebGL renderer & extensions.

The damage of this proposed change far outweighs the possible benefits in my opinion and should be seen as a last resort. I feel that we should push for blocking default sensor access through 3rd party services (even secure ones) but leave it open for 1st party users that can use these sensors in creative ways (AR / VR / parallax effects etc..).

[othermaciej]

@TimvanScherpenzeel

• We (Apple) consider all of the cited threats to be real threats. We trust our security experts

• We consider first-party fingerprinting to be a threat, not just third-party fingerprinting.

• We don't accept the argument that fingerprinting attack surface can be added freely because other fingerprinting attack surface already exists. We agree with the TAG Security and Privacy Questionnaire's view on sensor data. (In any case, there are risks more severe than fingerprinting.)

Given these considerations, it's unlikely we will enable this API by default on Apple platforms. We will however consider enabling it via user consent if there's agreement on a permissions API (which there n=mostly seems to be).

[TimvanScherpenzeel]

Thank you for your clear reply @othermaciej.

In that case I trust that you and the security experts are making the right choice in making this change. I don't have the experience in what it takes to make a browser safe nor do I have a clear view on exactly how malicious parties are exploiting the mentioned sensor API's. The Gyrophone reference in the TAG Security and Privacy Questionnaire is really clever.

I hope we can find an elegant solution for how the requesting of permissions is done. To be completely honest, when I started looking into the API's myself about a year and a half ago I was very surprised users did not have to give explicit permission.

[tangobravo]

According to an article discussing iOS 12.2 beta features:

• Accessing sensor APIs is now disabled by default, so no accelerometer, gyroscope or magnetometer APIs are working unless the user enables a Settings option under “Safari”

Assuming this beta feature will ship in stable (edit: it will according to the release notes),

[...]

I've seen quotes from earlier in the day from the release note page including a sentence that the option to allow sensor events would be disabled by default. Looking at the link now, there is no comment about the default state of these options. @anssiko can you confirm this was explicitly specified before? Anyone from the Safari team care to clarify?

The worry of this change is it buries the option in the settings without even offering a permissions API to the browser. I'm on the AR/VR use case side and think a permission prompt perfectly acceptable. However having to direct users to some obscure part of the settings app to enable this option definitely seems a step too far which will be damaging for the web.

My hope is Apple/Safari have decided to keep the setting enabled by default in 12.2. That will give time to finalise the permission model without breaking web content, but still give the privacy conscious the opportunity to disable globally.

[erikmchut]

@richtr we are members of the immersive web working group and are following the progress there closely, but the device motion / orientation APIs are in broad use today and this change affects the community acutely.

@othermaciej, while the devicemotion permissions API is under consideration, could the WebKit team help lessen the impact to existing AR pages by allowing access to deviceorientation and devicemotion when a user has explicitly approved camera permissions for the page through getUserMedia()? This is used in 6 Degree-of-Freedom JavaScript libraries that power pages like the Sony Pictures' Spider-Man AR Experience: https://www.intothespiderverse-ar.com/ (currently broken in beta Safari 12.2b). Since the iOS getUserMedia permission is requested on every page load and typically only on high-trust sites, it seems likely to mitigate the fingerprinting concerns and privacy concerns from additional motion information.