W3C home > Mailing lists > Public > public-device-apis-log@w3.org > March 2017

Re: [sensors] Relax requirements for asking permissions in sensors

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Wed, 08 Mar 2017 22:44:49 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-285194689-1489013087-sysbot+gh@w3.org>
So after more consideration, I see two options here:

1. Hook into the permission system and always return "granted" as it seems the Permission spec let's you do (see [user intent](https://w3c.github.io/permissions/#new-information-about-the-users-intent)), or
2. Completely bypass the permission's API.

If it's option 1, you're already good to go. You'll still need to spec and implement as if there were permissions, define a permission name, etc., but permission will be always "granted" by default on Chrome (whether always granting is a good idea or not is another discussion that might be worth having on Chromium's tracker). Option 1 has the added benefit of allowing different vendors to adjust their permission settings for sensors. Given the documented privacy and security issues of exposing sensors to the Web, this is the right thing to do.

Option 2 is a no go as it would create interop issues should another vendor decide to require permission where Chrome decided it doesn't need to. The only way this could work would be to get all vendors to agree upfront about this for a given set of sensors (and create a `PermissionBasedSensor` API inheriting  from `Sensor` were there would be agreement that permissions were needed). This seems like an ineffective way to handle this.

Given the above, I'll close this. Feel free to reopen if you can get all vendors on the same page here or if there's another solution to this problem that I haven't thought about.

GitHub Notification of comment by tobie
Please view or discuss this issue at https://github.com/w3c/sensors/issues/174#issuecomment-285194689 using your GitHub account
Received on Wednesday, 8 March 2017 22:44:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 12:18:52 UTC