Comments (10)
My preference would still be that we disallow vibrate in subframes by default, requiring embedders to say "allow='vibrate'" to enable. But my understanding is that other folks are keen to have it enabled by default in subframes with a user-gesture requirement for having it work. @benfredwells
In either case, I think disabling via feature policy should definitely turn the feature off.
from webappsec-permissions-policy.
I think annoyance/abuse mitigations are different from permissions. Potentially annoying APIs like vibrate, autoplay, window.open, should be gated on a gesture by default and enabled in any frames that have had a gesture. Whereas APIs that need permissions should be off by default in subframes because, in general, the user doesn't understand that it's a subframe asking for the permission. As far as the user is concerned, they're only interacting with the top-page.
Am I missing something significant we gain by defaulting to requiring the top-page to grant vibrate to subframes instead of just requiring that the subframe has had a user gesture?
from webappsec-permissions-policy.
I agree with @raymeskhoury in the sense that a "global" allowance should still be available and complementary to make it possible for publishers, interested in vibration content, to allow it by default without gesture. For instance a page based on haptic content for impaired people to enjoy different content without the need of gestures. Take into account that a blind person is unable to press the iframe so he/she will never activate it. Also old people has problems to control hands movements so this kind of global allowance will easy these possibilities.
Further, In advertising content sometimes we can sign a private agreement with a publisher (let's say BBC site), then they provide of a special iframe in their website only for our format to be displayed without the need of a gesture (just as it worked before Chrome modification), so BBC allows vibration by default (using policy) and only our format will be displayed in such iframe, this way they receive more money from marketers by selling Haptter advertising spaces creating a higher engagement with users.
As a conclusion, I think that both possibilities Allow and Disallow policies should be available. This way no one will be harmed in the future.
What do you think @lubin2010 ?
from webappsec-permissions-policy.
Using user gestures should work fine with accessibility APIs. Users don't physically click, but they do actions that the browser interprets as a click.
Context
Chrome plans to limit vibrate on top-level pages to mitigate rampant abuse of vibrate for phishing. So, top frames will also require having had a user gesture before they can vibrate. We can talk about ways we might loosen those restrictions in the future, but should discuss that in a separate forum since it's not related to FeaturePolicy.
As a general FeaturePolicy principle, the top page cannot delegate permissions to subframes that it doesn't have access to. So, given the above, if the top frame hasn't had a gesture, then it can't delegate it to a subframe.
New Proposal
allow="vibrate" should allow the subframe to vibrate in the case that the top-frame has had a user gesture, regardless of whether the subframe has. That keeps the top page in charge of what it's subfames can do. Of course, the top-level page would still be able to use the vibrate FeaturePolicy to fully disable vibrate in subframes as they can with any other FeaturePolicy directive.
In this world, subframes that don't have allow="vibrate" but have had a user gesture would still be allowed to vibrate as they can today.
from webappsec-permissions-policy.
In this world, subframes that don't have allow="vibrate" but have had a user gesture would still be allowed to vibrate as they can today.
@ojanvafai, do you mean that even if not enabled by FP, a user gesture in a subframe would enable vibrate in that frame?
If the behaviour for vibrate is "allowed top-level and same-origin frames" (after gesture), then you'd still need to use allow="vibrate"
to delegate to cross-origin subframes. -- I think this is acceptable.
On the other hand, if the behaviour for vibrate is "allowed at top-level and in all frames -- even cross-origin" (still after gesture), then the only way to disable vibrate completely would be through an HTTP header, at least until we sort out some kind of <iframe disallow>
syntax.
from webappsec-permissions-policy.
@ojanvafai, do you mean that even if not enabled by FP, a user gesture in a subframe would enable vibrate in that frame?
Right.
If the behaviour for vibrate is "allowed top-level and same-origin frames" (after gesture), then you'd still need to use allow="vibrate" to delegate to cross-origin subframes. -- I think this is acceptable.
I don't see what we gain by being this restrictive for this feature.
On the other hand, if the behaviour for vibrate is "allowed at top-level and in all frames -- even cross-origin" (still after gesture), then the only way to disable vibrate completely would be through an HTTP header, at least until we sort out some kind of <iframe disallow> syntax.
I think that's fine. People aren't clamoring to disable vibrate. I think the attribute disabling of it can easily wait until we've figured out attribute disabling for feature policy.
To be clear, my last proposal was that it's allowed in all frames after a gesture (in that frame), but that allow="vibrate" would also let a subframe vibrate after the parent page has had a gesture.
from webappsec-permissions-policy.
To be clear, my last proposal was that it's allowed in all frames after a gesture (in that frame), but that allow="vibrate" would also let a subframe vibrate after the parent page has had a gesture.
Hmm, but doesn't that get us back to a tri-state feature policy situation that we were trying to avoid?
I think I'm ok with allowing vibrate everywhere by default, as long as there is a gesture requirement, but I don't think specifying allow="vibrate" should do anything extra or else it complicates the FP mechanism (the default is "allow everywhere" so allow="vibrate" should be a no-op).
I know you've talked about the idea of passing around user gestures to subframes in the past. I think that might be an interesting direction to think more about that fits in with your suggestion though.
from webappsec-permissions-policy.
There are at least four different features here:
- Vibrate after receiving a gesture
- Vibrate without a gesture
- Spend the parent's gestures
- Spend the parent's gestures on vibrating
If it's ambiguous which one "vibrate"
refers to, we can/should use a longer name.
from webappsec-permissions-policy.
There's been little movement on this in the last year or so -- I'm wondering whether this is still something we want to pursue. I'd propose that we drop this, unless people feel strongly that the current behaviour (no use without activation, Chrome's behaviour since version 60) is insufficient for vibration.
The other options I see are:
- We can add a vibrate-without-activation feature, off by default, which needs to be enabled in all frames from the top-level to any frame which wants to use it.
- We implement something like gesture delegation to allow fine-grained control of which frames receive activation after a gesture, and try to spec something that works to allow the no-vibrate, vibrate-only-after-activation, and vibrate-without-activation scenarios.
from webappsec-permissions-policy.
Closing this out; vibrate is currently implemented without any FP integration. If it comes up again, we can re-open this or file a new issue for the semantics.
from webappsec-permissions-policy.
Related Issues (20)
- support <meta http-equiv> mechanism to set the policy HOT 2
- document.featurePolicy vs document.permissionsPolicy HOT 2
- Clarify the expected usage of "Should request be allowed to use feature?"
- Potential bug in access delegation to cross-origin iframe for feature that has default allowlist value "self"? HOT 2
- allow disabled-by-default features HOT 5
- Does url match expression in origin with redirect count? takes a URL, not an origin HOT 7
- "If the allowlist contains an origin representing self" is unclear HOT 2
- Editorial: "If origin is opaque" needs to use a cross reference
- Inconsistency in text and parsing algorithm (invalid member value)
- Add "mediasession" to the list of permission policies HOT 1
- Set declared policy for powerful features to self by default HOT 9
- A request's "window" is never a Window HOT 1
- methiyaowala HOT 2
- Permissions Policy report missing a document URL HOT 2
- Send reports for Permissions Policy violations in iframe to parent frame's endpoint HOT 19
- > 07881334 2 002065 031525 054161 F-3525824 PANYA YAOWALA ( AIA ) 0107537002761 0872220535 3410200102061 *01401125350 341020009143 3410200102096 41001470 165467 T-078813339 T078813342
- Query: Can trusted subframe allocate permission to one of it's cross-domain subframe HOT 2
- [clipboard] document.execCommand('copy') and presumably paste bypass permissions policy
- Permissions Policy "deferred-fetch"
- JS playgrounds leak permissions. Guidelines and examples needed HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webappsec-permissions-policy.