Intent to Deprecate and Remove: requesting notification permission from iframes

조회수 1,902회
읽지 않은 첫 메시지로 건너뛰기

Dominick Ng

읽지 않음,
2017. 2. 27. 오후 8:00:2017. 2. 27.
받는사람 blink-dev

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

읽지 않음,
2017. 2. 27. 오후 9:27:1317. 2. 27.
받는사람 blink-dev
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

읽지 않음,
2017. 2. 28. 오후 9:10:0917. 2. 28.
받는사람 Dominick Ng, blink-dev
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

읽지 않음,
2017. 3. 3. 오전 9:04:0317. 3. 3.
받는사람 Chris Harrelson, Dominick Ng, blink-dev
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

읽지 않음,
2017. 3. 9. 오후 2:43:4717. 3. 9.
받는사람 blink-dev, chri...@chromium.org, domi...@chromium.org
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

읽지 않음,
2017. 3. 9. 오후 5:03:5517. 3. 9.
받는사람 Dru, blink-dev, Chris Harrelson, 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

읽지 않음,
2017. 3. 16. 오후 7:56:1217. 3. 16.
받는사람 Dominick Ng, Dru, blink-dev, Chris Harrelson
Friendly ping to API owners on this one.

Dimitri Glazkov

읽지 않음,
2017. 3. 17. 오전 10:31:4917. 3. 17.
받는사람 Dominick Ng, Dru, blink-dev, Chris Harrelson
LGTM2

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


Dru

읽지 않음,
2017. 3. 27. 오후 7:45:3417. 3. 27.
받는사람 blink-dev, domi...@chromium.org, dk...@chromium.org, chri...@chromium.org
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

읽지 않음,
2017. 3. 27. 오후 9:35:4217. 3. 27.
받는사람 Dru, blink-dev, domi...@chromium.org, Chris Harrelson
LGTM3.

--
TAMURA Kent
Software Engineer, Google


adre...@gmail.com

읽지 않음,
2017. 7. 10. 오후 6:51:4817. 7. 10.
받는사람 blink-dev
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

읽지 않음,
2017. 7. 10. 오후 8:13:4917. 7. 10.
받는사람 adre...@gmail.com, blink-dev
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.

cka...@vertical.com

읽지 않음,
2017. 7. 11. 오후 3:35:2417. 7. 11.
받는사람 blink-dev
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

읽지 않음,
2017. 7. 11. 오후 8:39:1117. 7. 11.
받는사람 cka...@vertical.com, blink-dev
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.

samuel...@gmail.com

읽지 않음,
2017. 7. 13. 오후 8:14:5817. 7. 13.
받는사람 blink-dev, cka...@vertical.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

읽지 않음,
2017. 7. 13. 오후 8:28:3917. 7. 13.
받는사람 samuel...@gmail.com, blink-dev, cka...@vertical.com
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.

ahsan...@gmail.com

읽지 않음,
2017. 7. 14. 오전 9:46:0317. 7. 14.
받는사람 blink-dev
Its going to have many consequences. Many sites rely on 3rd party services, and this ruins user experience. 

John Mellor

읽지 않음,
2017. 8. 16. 오후 2:05:5317. 8. 16.
받는사람 Dominick Ng, samuel...@gmail.com, blink-dev, cka...@vertical.com
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.

Philip Jägenstedt

읽지 않음,
2017. 8. 16. 오후 5:57:0017. 8. 16.
받는사람 John Mellor, Dominick Ng, icle...@chromium.org, samuel...@gmail.com, blink-dev, cka...@vertical.com
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.

ad...@sortex.co.il

읽지 않음,
2017. 11. 20. 오후 3:14:4617. 11. 20.
받는사람 blink-dev
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

읽지 않음,
2017. 11. 21. 오후 12:52:4517. 11. 21.
받는사람 ad...@sortex.co.il, blink-dev
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.
전체답장
작성자에게 답글
전달
새 메시지 0개