Intent to Deprecate and Remove: requesting notification permission from iframes

[Dominick Ng]

Intent to Deprecate and Remove: requesting notification permission from iframes

Primary eng (and PM) emails

domi...@chromium.org

pe...@chromium.org

ray...@chromium.org

aw...@chromium.org

emilysc...@chromium.org

Summary

Remove the ability to call Notification.requestPermission() from non-main frames.

It is intended to align this with the deprecation and removal of access to the Notifications API over insecure connections, which will be deprecated in M58 and removed in M60.

Motivation

This change will completely align the requirements for notification permission with that of push notifications, easing friction for developers. It also allows us to unify notification and push permissions.

More generally, permission requests from iframes cause significant confusion for users. It is difficult to distinguish between the main frame origin and the origin requesting the permission. The scope of the permission decision (within or outside an iframe) is also unclear, making it difficult to reason about when a granted or denied permission takes effect.

Compatibility Risk

Notification.requestPermission() from an iframe is commonly used to allow push aggregation services to work on insecure origins. This is because the push API requires HTTPS, and cannot be instantiated from an iframe without prior push or notifications permission being granted.

The aggregator provides a secure iframe which requests notification permission; if it is granted, the HTTPS aggregator may then use the notification permission to send push notifications on behalf of the HTTP site through their own origin. Major push aggregators were contacted for feedback on this change, and no strong objections were made. It was requested that this change should align with the removal of the Notifications API from HTTP if possible.

Alternative implementation suggestion for web developers

Instead of using an iframe, affected websites can open a new window (i.e. a new main frame) to request notification permission. One group has already experimented with this flow and found that it did not significantly impact acceptance rates.

Usage information from UseCounter

An early metric (currently on Canary for M58) pegs the use of Notification.requestPermission() from iframes at 0.0003%.

The Notification constructor is called from secure cross-origin iframes on 0.0009% of page loads. It is called from insecure cross-origin iframes on 0.0029% of page loads, but this will be restricted by the upcoming removal of access to the Notifications API on HTTP.

Notification.requestPermission() from iframes: 0.0003%

(https://www.chromestatus.com/metrics/feature/popularity#NotificationPermissionRequestedIframe)

Secure origin iframes: 0.0009% (https://www.chromestatus.com/metrics/feature/popularity#NotificationAPISecureOriginIframe)

Insecure origin iframes: 0.0029%

(https://www.chromestatus.com/metrics/feature/popularity#NotificationAPIInsecureOriginIframe)

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=695693

Entry on the feature dashboard

https://www.chromestatus.com/feature/6451284559265792

Requesting approval to remove too?

Yes. We plan to add a console warning in M58, with full restriction in M60. This aligns with the restriction of the Notifications API to secure origins.

[Dominick Ng]

It's been pointed out that chromestatus.com lists incorrect usage stats when the metric is only in Canary. The revised early data suggests Notification.requestPermission() from iframes occurs on 0.07% of page loads in the current Canary.

I'll reiterate that much of this usage is driven by push aggregator services whom we've already reached out, and that none of them have significant concerns regarding this deprecation.

[Chris Harrelson]

Hi,

I assume the aggregators have committed to removing their usage soon? LGTM1, assuming you come back with updated data at time of removal to verify that the usage is almost all gone once aggregators stop.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

I'd like some clarification. Is the intention to reject with an exception precisely at the place where NotificationPermissionRequestedIframe is now measured?

In https://github.com/whatwg/notifications/issues/93 the suggestion is to restrict to secure contexts, but there are secure contexts in iframes, including cross-origin iframes. Can you elaborate on what behavior you'd like to ship, and is there anything blocking making the spec changes to match?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dru]

In addition to our deprecation warning and Chromestatus entry, have we made sure that devrel will be able to do an explanatory post ahead of the removal? It may be possible just to roll this up into the usual beta deprecations/removals post.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Dominick Ng]

Sorry for the delay in responding here.

Philip: yes, we will likely reject with an exception at that point. With these two deprecations, it is intended that requesting notification permissions will have the following behaviour:

• main frame, secure context -> success
• main frame, insecure context -> failure
• iframe, secure context -> failure
• iframe, insecure context -> failure

This behaviour is exactly how push behaves. As with the HTTP deprecation, we'll follow up with pull requests on the spec.

Dru: we will be working with devrel to ensure that wider notice than just the usual beta announcement is made.

Thanks!

-Dom.

[Dominick Ng]

Friendly ping to API owners on this one.

[Dimitri Glazkov]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dru]

I believe this is still blocked on API owner feedback. So far we have 2 LGTMs, Dimitri and Chris.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[TAMURA, Kent]

LGTM3.

--

TAMURA Kent
Software Engineer, Google

[adre...@gmail.com]

This needs to be revisited. Denial of login permission results in continuous future requests for permission, upon every reboot. For those not interested in granting login access permission this is a problem.

[Dominick Ng]

adre...@gmail.com: your issue does not seem to have anything to do with blocking notification permission requests from iframes. I'm not sure what you mean by "login permission".

If you're experiencing some sort of issue, please file a bug with as much detail as possible (ideally with screenshots / exact instructions to reproduce what you see) at crbug.com/new and the team will look into it for you.

On 11 July 2017 at 08:51, <adre...@gmail.com> wrote:

This needs to be revisited. Denial of login permission results in continuous future requests for permission, upon every reboot. For those not interested in granting login access permission this is a problem.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/144d01ac-cb22-4828-8ec9-f98253227bd0%40chromium.org.

[cka...@vertical.com]

Just to clarify - this only covers requesting notification permission, not actually creating/showing a notification once permission has been granted?  

At a high level our application uses an iframe to host sub-applications and some of the sub-applications use notifications.  If we move the notification permission request up to the main application can we leave the notification code itself in the sub-applications?

I tried testing this with 61.0.3141.7 and all notifications worked normally so it seems like it hasn't been removed yet?

Thanks!

[Dominick Ng]

ckaczor: Yes, this applies only to *requesting* permission, not creating Notifications once you have permission. When you have acquired permission in the main frame, you may create a notification from any iframe hosted on that same origin.

We haven't yet landed the code to disable requesting in Canary, but this should happen quite soon.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f6074400-52f0-4ecd-a286-8cba6468ce0b%40chromium.org.

[samuel...@gmail.com]

Would this scenario still work?

User approves notification permissions on https://example1.com. User visits https://example2.com which has an embedded iframe containing https://example1.com. From the iframe, https://example1.com creates a notification.

I'm wondering because the way you phrased it makes it sound like notifications from iframes will only work if the iframe is the same origin as the parent (even if the origin the iframe points to has successfully approved notifications elsewhere).

Sam

On Tuesday, July 11, 2017 at 6:39:11 PM UTC-6, Dominick Ng wrote:

ckaczor: Yes, this applies only to *requesting* permission, not creating Notifications once you have permission. When you have acquired permission in the main frame, you may create a notification from any iframe hosted on that same origin.

We haven't yet landed the code to disable requesting in Canary, but this should happen quite soon.

On 12 July 2017 at 05:35, <cka...@vertical.com> wrote:

Just to clarify - this only covers requesting notification permission, not actually creating/showing a notification once permission has been granted?  

At a high level our application uses an iframe to host sub-applications and some of the sub-applications use notifications.  If we move the notification permission request up to the main application can we leave the notification code itself in the sub-applications?

I tried testing this with 61.0.3141.7 and all notifications worked normally so it seems like it hasn't been removed yet?

Thanks!

On Monday, February 27, 2017 at 8:00:20 PM UTC-5, Dominick Ng wrote:

Intent to Deprecate and Remove: requesting notification permission from iframes

Primary eng (and PM) emails

[Dominick Ng]

Sam,

Yes, that scenario should work. To rephrase, once you have acquired permission in a secure, top-level frame for an origin, an embedded iframe from that same origin will be able to create notifications.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/77a0537e-7710-4224-9b8a-7def63b08405%40chromium.org.

[ahsan...@gmail.com]

Its going to have many consequences. Many sites rely on 3rd party services, and this ruins user experience. 

[John Mellor]

To clarify, is this intended to block same-origin iframes from calling Notification.requestPermission()? It seems a little futile to do so when same-origin iframes can directly script the top frame (unless sandboxed etc), but I don't know whether there is precedent for this kind of thing.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOLd7fFmv69DY7f_3Fffz8Nkix2WvaNmVZw-gf58GsLvVBamnQ%40mail.gmail.com.

[Philip Jägenstedt]

There is precedent for such "futile" restrictions in the case of fullscreen, where even same-origin iframes need the allowfullscreen attribute, even though they can reach out and add it to themselves. However, with feature policy (+Ian Clelland) that's changing, and the new model will rather be to just allow the same-origin case. It'd probably make sense for other APIs to also behave that way.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG_kaUYOQWSsMxEEsdGjT%3DPK0q-ONhBTMUGW_s8OhC7soPmc8Q%40mail.gmail.com.

[ad...@sortex.co.il]

Does this means that i won't be able to connect to http and have to use https from now on?

Before 62 all worked, but since 62, even browsers that have the domain confirmed doesn't show notification anymore...

[Peter Beverloo]

Hi Adam,

Your understanding is correct. Notifications will only work for websites that use a secure context (https) starting with Chrome 62.

Thanks,

Peter

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ef9ac3aa-8634-4637-9220-92e6d52d0ce6%40chromium.org.