search

w3c / webappsec-permissions-policy

A mechanism to selectively enable and disable browser features and APIs
https://w3c.github.io/webappsec-permissions-policy/
Other
398 stars 155 forks source link

allow="" attribute model #337

Open annevk opened 5 years ago

annevk commented 5 years ago

I figured I'd raise https://github.com/w3c/webappsec-feature-policy/issues/230#issuecomment-519525216 in a new issue.

When A delegates to B, B can share the permission with whoever it wants. So A is not protected from B, if it decides to delegate. And if B wants to protect A from B being navigated to C, it has to rely on A getting it right. In general I'd also expect B to open popups instead and not navigate the frame as that's not something that's well-understood and works poorly on mobile.

So I don't think the rather complicated model we have today is really justified and therefore I'd rather only support feature/permission identifiers and not https://w3c.github.io/webappsec-feature-policy/#allow-list.

cc @bzbarsky @clelland

clelland commented 5 years ago

When A delegates to B, B can share the permission with whoever it wants.

True, that was by design, since b could (in most cases) just proxy data to C if it was interested in doing something nefarious anyway. By delegating to B, a is expressing a degree of trust in B that it will use the features responsibly, and that includes being able to further delegate as required.

And if B wants to protect A from B being navigated to C, it has to rely on A getting it right.

I'm not sure I follow -- does B need to protect A? A, by delegating to B specifically, is just saying "I trust B, and B can delegate further if it needs to, but if the frame ends up hosting content that neither I nor B have delegated the permission to, then it doesn't get the permission"

In general I'd also expect B to open popups instead and not navigate the frame as that's not something that's well-understood and works poorly on mobile.

In what way is it not well-understood? B only has to include an <a> element in order for the frame to be navigated. Is it that the back/forward history navigation gets more complex in that case?

annevk commented 5 years ago

B does not need to protect A, but if it wants to there are no tools. It was mostly meant to indicate that this functionality isn't really serving B either.

And I meant that navigation of frames is not well-understood by users and likely avoided by a third-party service.