-
Notifications
You must be signed in to change notification settings - Fork 59
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
Comments
@dontcallmedom can you please explain more how possibly we might be able to use the same proposal in the sensor spec? |
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. |
Interesting white/black listing of features. |
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 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. |
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.) |
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. |
Thus the API can be used inside child browsing contexts in a secure way. Fixes w3c#133
@raymeskhoury, the key use cases are explained in the following WebKit bugs: https://webkit.org/b/150072 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. |
Thus the API can be used inside child browsing contexts in a secure way. Fixes w3c#133
Thus the API can be used inside child browsing contexts in a secure way. Fixes w3c#133
Thus the API can be used inside child browsing contexts in a secure way. Fixes w3c#133
Thus the API can be used inside child browsing contexts in a secure way. Fixes w3c#133
Thus the API can be used inside child browsing contexts in a secure way. Fixes w3c#133
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.
The text was updated successfully, but these errors were encountered: