search

w3c / webappsec-permissions-policy

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

What happened to "notifications"? #243

Open annevk opened 6 years ago

annevk commented 6 years ago

It was added in #3 / #33, but got dropped since then. Maybe while migrating the features out of the main document it got lost?

cc @johannhof

annevk commented 6 years ago

Is the problem here perhaps primarily with push notifications, which you cannot really delegate? (This also seems problematic with "persistent-storage".)

johannhof commented 6 years ago

Yeah this seems a bit problematic to me.

Let's say third-party.com is embedded in example.com and through that is granted the ability to send notifications. In some cases this might be limited to the document lifetime but in other cases it might be used in workers that outlive the document.

Should we add a permanent (top-level) permission to third-party.com to enable it to keep sending notifications? How do we explain/justify to the user that third-party.com was given this access outside of the context of example.com? I don't see any way you can reasonably double-key notifications (the "solution" for persistent-storage here would be to double key the storage itself).

If we for some reason decide to grant a permanent permission for third-party.com, what do we do when example.com decides to change its policy and disallow usage of notifications?

Chrome seems to have solved these problems by just deprecating notifications in iframes without considering feature policy: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/n37ij1E_1aY

It would be great to be able to include this in feature policy somehow, though...

clelland commented 6 years ago

I think (though @raymeskhoury may remember more) that the issue with notifications (and push, and background sync and the like) was that they can all be mediated through a service worker, and we hadn't worked out how policies should apply to workers created by restricted documents.

If workers aren't affected by the opening document's feature policy (and only use their own headers, for instance), then an iframe which was not allowed to use notifications could create a service worker and a shared worker, and then have the shared worker call showNotification on the service worker registration. (I think this is possible, but I'd be very happy to be shown wrong here)

(And if they are affected by their opening document's active policy, then there can be a race between frames from the same origin with different policies to create such shared resources)

annevk commented 6 years ago

(I think this is possible, but I'd be very happy to be shown wrong here)

Only if they already have permission somehow. And you can only ask permission through a document.

martinthomson commented 5 years ago

Discussed with folks at Mozilla, it's the "push" permission that is troublesome, and that relates to #207. If, as @annevk suggests, requesting permissions is done via a document, then that suggests a clear solution to the shared and service worker issue: limit the scope to permissions.

raymeskhoury commented 5 years ago

I agree with what @clelland said.

Only if they already have permission somehow. And you can only ask permission through a document.

Hmm, but the point of feature policy is not just about blocking requests for permission, it's about blocking use of a feature altogether. If a user had previously granted permission and then the site blocked the feature, the feature should be blocked.

Discussed with folks at Mozilla, it's the "push" permission that is troublesome, and that relates to #207. If, as @annevk suggests, requesting permissions is done via a document, then that suggests a clear solution to the shared and service worker issue: limit the scope to permissions.

I don't think I agree that it's only push that's troublesome. Regular notifications (not push-initiated) are available in service workers too. I think the problem exists for any feature that is accessible from a service worker.

martinthomson commented 5 years ago

If it is the act of acquiring consent to use notifications, then as long as that is only via a document, then the use of that feature can be allowed in workers based on a pre-existing consent. That might not be much help if the intent is to govern use. Maybe that's another question we need resolved.

raymeskhoury commented 5 years ago

I think we usually want to govern actual usage of the feature (I don't know of any cases where governing acquisition of the feature over usage has been the concern)

annevk commented 5 years ago

From the perspective of there only being an allow attribute (and no header, see #249), it's really only about the permission, no? By default a framed cross-origin resource would not have permission and therefore not be able to use the feature.

And we want to move to that world so that the permission prompt doesn't have to show an origin that's different from the address bar's origin.