Skip to content
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

Relation to Feature Policy #133

Closed
dontcallmedom opened this issue Sep 19, 2016 · 7 comments
Closed

Relation to Feature Policy #133

dontcallmedom opened this issue Sep 19, 2016 · 7 comments
Assignees
Labels
needs-research permissions privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response.
Milestone

Comments

@dontcallmedom
Copy link
Member

The under-incubation Feature Policy spec provides a framework to selectively enable and disable permissions from embedded contexts; we should probably figure how the generic-sensor based API interacts with that proposal.

@tobie tobie modified the milestone: Level 1 Oct 27, 2016
@tobie tobie self-assigned this Oct 28, 2016
@tobie tobie added privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. permissions labels Nov 8, 2016
@maryammjd
Copy link

@dontcallmedom can you please explain more how possibly we might be able to use the same proposal in the sensor spec?

@tobie
Copy link
Member

tobie commented Nov 14, 2016

I've looked at this and it seems there's quite a large overlap indeed. I like their custom WebIDL extended attribute-like constructs. Will reach out.

@lknik
Copy link
Contributor

lknik commented Nov 16, 2016

Interesting white/black listing of features.

@tobie tobie added the security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response. label Dec 2, 2016
@tobie tobie modified the milestones: Level 1, Level 2 Jan 25, 2017
@anssiko
Copy link
Member

anssiko commented Oct 9, 2017

The Feature Policy spec has stabilized during the last year and v1 is shipping in Chrome. There has also been recent interest from implementers to integrate more specs with it, see e.g.:

w3c/geolocation#14
w3c/battery#13

This suggest the priority of the Generic Sensor API Feature Policy integration should be raised as to allow all Generic Sensor-based concrete sensors take benefit of it.

Cc @raymeskhoury @clelland

@anssiko
Copy link
Member

anssiko commented Nov 21, 2017

Since I hear no concerns, this feature seems appropriate to be cherry-picked into the Generic Sensor API v1.

@alexshalamov @pozdnyakov, could you submit a PR for the group to review.

@dontcallmedom @xfq, my expectation is that adding the Feature Policy spec (as it stands today) as a normative reference won't block us from entering CR in the near future.

(For Proposed Rec, we need to satisfy the CR exit criteria of two interoperable implementations, and when we eventually get there, I'd expect other implementers to have also implemented the Feature Policy and the spec to have advanced to the standards track.)

@pozdnyakov pozdnyakov self-assigned this Nov 21, 2017
@raymeskhoury
Copy link

Thanks @anssiko. I apologize for the delay here. I think FP support is conceptually reasonable but I think it's still helpful to outline use cases and justification.

pozdnyakov pushed a commit to pozdnyakov/sensors that referenced this issue Nov 22, 2017
Thus the API can be used inside child browsing contexts in a secure way.

Fixes w3c#133
@anssiko
Copy link
Member

anssiko commented Nov 23, 2017

@raymeskhoury, the key use cases are explained in the following WebKit bugs:

https://webkit.org/b/150072
https://webkit.org/b/152299

We will outline the use cases and justification in the Generic Sensor API specification per your suggestion. @alexshalamov @pozdnyakov, please take a note.

Related comment:

Since the work on DeviceOrientationEvent/DeviceMotionEvent spec has stopped we cannot add new features to that legacy specification (as was suggested in the WebKit bugs). The best we can do for that spec is to fix the remaining known issues to improve interoperability across browsers and allow the legacy spec finish its progress on the Recommendation track. This work is already underway, see w3c/deviceorientation#46 and w3c/deviceorientation#47.

Luckily we can add Feature Policy integration into the Generic Sensor API to address these important use cases developers are asking for to selectively enable sensors in cross-origin iframes, see #328.

pozdnyakov pushed a commit to pozdnyakov/sensors that referenced this issue Nov 23, 2017
Thus the API can be used inside child browsing contexts in a secure way.

Fixes w3c#133
pozdnyakov pushed a commit to pozdnyakov/sensors that referenced this issue Nov 24, 2017
Thus the API can be used inside child browsing contexts in a secure way.

Fixes w3c#133
pozdnyakov pushed a commit to pozdnyakov/sensors that referenced this issue Nov 29, 2017
Thus the API can be used inside child browsing contexts in a secure way.

Fixes w3c#133
pozdnyakov pushed a commit to pozdnyakov/sensors that referenced this issue Nov 29, 2017
Thus the API can be used inside child browsing contexts in a secure way.

Fixes w3c#133
pozdnyakov pushed a commit to pozdnyakov/sensors that referenced this issue Nov 29, 2017
Thus the API can be used inside child browsing contexts in a secure way.

Fixes w3c#133
@anssiko anssiko modified the milestones: Level 2, Level 1 Nov 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-research permissions privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. security-tracker Group bringing to attention of security, or tracked by the security Group but not needing response.
Projects
None yet
Development

No branches or pull requests

7 participants