W3C home > Mailing lists > Public > public-device-apis-log@w3.org > February 2019

Re: [deviceorientation] Add API for requesting permission to receive device motion / orientation events (#57)

From: erikmchut via GitHub <sysbot+gh@w3.org>
Date: Tue, 05 Feb 2019 18:47:06 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-460756288-1549392423-sysbot+gh@w3.org>
Just some food for thought as progress is made here. Native apps and the web alike are moving towards more natural UX, where moving and pointing your phone is how you interact with the content. ARKit (native), ARCore (native), 8th Wall (web), and AR.js (web) are prominent examples of this.

Put another way, device orientation and motion are starting to replace user touches as input.

On native, Apple has made this very easy with ARKit.
On web, iOS Safari is about to make this harder or default-disabled.

Please consider the implications of a double-standard that indirectly benefits a closed app ecosystem. 

Also, as you make changes here, do please consider the following:

- Unlike other mobile browsers, Safari/WebKit doesn’t currently cache permissions per-domain, so any permission request occurs *every single time* you view the page. This contributes to permissions fatigue and users generally making less informed decisions about privacy.
- For pages whose entire input is device motion / orientation, like many AR/VR pages, there is currently no user gesture (since canvas touches aren’t considered user gestures). Thus in the pathologically worst end-state, Safari might require a prompt for each of the following *every* pageload:
    - 1) Bespoke dialog stating ‘This page would like to use camera and device motion, click ‘here’ to request permission.
    - 2) Permission dialog, this page is requesting camera access (yes/no)
    - 3) Permission dialog, this page is requesting device motion (yes/no)
    - 4) Permission dialog, this page is requesting device orientation (yes/no)

While I expect that we end up with a much better state than the scenario above – If I could suggest anything, it would be to enable permissions caching at the domain level in Safari, perhaps combined with a check-box that says ‘don’t ask again for this site’. This would prevent permissions fatigue and give parity with native apps which do not need to request permission on every app load. Much of this may be addressed in future permissions APIs, but it would be helpful if Safari/WebKit teams would be open to mitigate these concerns before making changes to device motion/orientation permissions.

GitHub Notification of comment by erikmchut
Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/57#issuecomment-460756288 using your GitHub account
Received on Tuesday, 5 February 2019 18:47:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 5 February 2019 18:47:39 UTC