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

What happened to "notifications"? #243

Open
annevk opened this issue Nov 14, 2018 · 9 comments

Comments

5 participants
@annevk
Copy link
Member

commented Nov 14, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Nov 14, 2018

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

@johannhof

This comment has been minimized.

Copy link

commented Nov 14, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Nov 14, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Nov 14, 2018

(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

This comment has been minimized.

Copy link
Member

commented Nov 19, 2018

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

This comment has been minimized.

Copy link

commented Nov 19, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 20, 2018

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

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Nov 20, 2018

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.

@pabrai pabrai added this to New input in FP Engagement May 13, 2019

@pabrai pabrai moved this from New input to Questions in FP Engagement May 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.