Intent to Deprecate and Remove: Insecure origin usage of Notifications

[Emily Schechter]

Primary eng (and PM) emails

domi...@chromium.org

emilysc...@chromium.org

Summary

Remove access to the Notifications API on insecure origins. This will prevent sites from requesting notification permission or creating non-persistent local notifications over HTTP.

Sites using the Notification API for web push must already be on secure origins due to the requirement for a service worker.

Motivation

This continues the application of concepts from http://www.w3.org/TR/powerful-features/ to features which have already shipped. It follows the successful removal of getUserMedia() and geolocation from insecure origins.

Notifications are a powerful feature as they allow websites to invoke system UI to transmit either private information itself or a signal that private information has been changed. Attackers may sniff or steal any information sent through a notification over an insecure connection.

Compatibility Risk

Usage of non-persistent local notifications is well under the deprecation threshold at 0.0142%. Over 90% of daily notification permission requests in Chrome are already made on a secure origin.

Web push requires a secure origin, so this change will align non-push notifications with push notifications.

Alternative implementation suggestion for web developers

Migrate your site to HTTPS to continue using the Notification API for non-persistent local notifications.

Usage information from UseCounter

Usage is 0.0142%:

https://www.chromestatus.com/metrics/feature/popularity#NotificationInsecureOrigin

OWP launch tracking bug

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

Entry on the feature dashboard

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

Requesting approval to remove too?

Yes. If the discussions are not controversial, we plan to add a console warning in M57, with full restriction to secure origins in M59. If we miss M57, we will adjust to M58 with remove in M60.

[Jochen Eisinger]

lgtm1

[Mike West]

Non-OWNER's LGTM. The usage is relatively low, and aligning all our notification code under the same requirements will make things simpler for developers.

Have you talked to other vendors about this change?

How will you implement the restrictions? Do you plan on changing the API to a no-op in non-secure contexts? Hiding the interface entirely? Throwing? 

-mike

[Anne van Kesteren]

On Wed, Jan 11, 2017 at 10:01 AM, Mike West <mk...@chromium.org> wrote:
> Have you talked to other vendors about this change?
>
> How will you implement the restrictions? Do you plan on changing the API to
> a no-op in non-secure contexts? Hiding the interface entirely? Throwing?

It would be good to have a PR against the Notifications API Standard
that indicates what exactly is planned here. (For the record, this is
the first I heard of this.)


--
https://annevankesteren.nl/

[Drew Wilson]

I don't entirely understand the motivation - is the concern that with insecure origins attackers could inject notifications (that then seem like they come from that insecure origin)? How is this any different from the content within the webview itself (I guess we are concerned that the system notification UI may not fully reflect the insecure origin of the notification)? That seems reasonable to me, but that doesn't seem to be the stated motivation so perhaps I'm missing something.

-atw

[Dominick Ng]

On 11 January 2017 at 20:01, Mike West <mk...@chromium.org> wrote:

Non-OWNER's LGTM. The usage is relatively low, and aligning all our notification code under the same requirements will make things simpler for developers.

Have you talked to other vendors about this change?

The notifications team has privately talked with other vendors, but no public statements as yet. We felt that this post was as good a way as any to start public discussion.

 

How will you implement the restrictions? Do you plan on changing the API to a no-op in non-secure contexts? Hiding the interface entirely? Throwing? 

We're very open to suggestions here. The current plan is to make it behave similar to geolocation on HTTP: act as though the permission is denied by the user. This includes checking the permission status, requesting permission, and creating a notification.

On 11 January 2017 at 20:12, Anne van Kesteren <ann...@annevk.nl> wrote:

It would be good to have a PR against the Notifications API Standard
that indicates what exactly is planned here. (For the record, this is
the first I heard of this.)

Thanks for this; we'll definitely follow up with a PR for discussion on the behaviour.

On 11 January 2017 at 21:36, Drew Wilson <atwi...@chromium.org> wrote:

I don't entirely understand the motivation - is the concern that with insecure origins attackers could inject notifications (that then seem like they come from that insecure origin)? How is this any different from the content within the webview itself (I guess we are concerned that the system notification UI may not fully reflect the insecure origin of the notification)? That seems reasonable to me, but that doesn't seem to be the stated motivation so perhaps I'm missing something.

Notifications are a powerful feature where you can invoke (trusted system) UI outside the webview, and we want to restrict powerful features to secure contexts. Unifying the requirements for push and non-push notifications is another benefit.

[Mike West]

On Wed, Jan 11, 2017 at 12:12 PM, Dominick Ng <domi...@chromium.org> wrote:

How will you implement the restrictions? Do you plan on changing the API to a no-op in non-secure contexts? Hiding the interface entirely? Throwing? 

We're very open to suggestions here. The current plan is to make it behave similar to geolocation on HTTP: act as though the permission is denied by the user. This includes checking the permission status, requesting permission, and creating a notification.

SGTM. For a new API, I'd suggest using the `[SecureContext]` IDL attribute. Given that there's existing usage, acting as though the permission has been denied seems like a safe way of approaching this deprecation.

-mike

[Chris Harrelson]

Hi,

0.0142% is quite a lot. Could you please do some research into which sites are using it and how they might break?

--
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.

[Dominick Ng]

Sorry for the slow response here.

It's tricky to get breakage insights since local notifications are typically fairly hidden - you don't often get them when you first visit a site. Their utility is also limited since the site must be open in a tab to send a notification (you must have HTTPS to send a push notification).

Additionally, I believe that the 0.0142% usage is possibly slightly inflated. Sites can call the notification constructor (triggering the UseCounter) without having previously asked for permission. The notification object will be created, but never shown to the user.

Looking at a random day's sample of notification permission requests to Chrome over HTTP, 41% come from just 10 sites, and 20% come from AOL alone, whom Chrome Security is already working with on HTTPS migration. Note that this is just sites which *request* the permission, not those that have actually used it.

We hope that a two milestone deprecation period will help unearth any large problems before we remove this API on HTTP. However, like geolocation and getUserMedia before, it is our strong belief that sites should migrate to HTTPS to continue accessing powerful APIs on the web.

[Chris Harrelson]

Hi Dominick,

Thanks for the helpful response.

Based on this data, I'm ok with a deprecation, but before removing I would like to see a lower percentage broken. It sounds to me like there are a few large sites that are causing a lot of this usage, which we can drive down with outreach like you mentioned for AOL; I would like to wait for that to happen and the number to decrease.

Just to reiterate here, the "0.02% threshold" is not a hard and fast rule. What is acceptable depends on the situation at hand and our research into the problem.

Thanks,

Chris

[Jochen Eisinger]

Do you happen to have numbers what percentage of the sites that touch the API actually get permission to use them from their users?

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

--
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+...@chromium.org.

[Rick Byers]

I talked with Dominick, Emily and Peter about this briefly.  They mentioned a couple things that weren't obvious to me or not fully covered above:

• The notification permission acceptance rate for https sites is 3x larger than for http sites.  This suggests to me that as a group, http sites are somewhat more likely to be things users don't really want (spammy) than things they'd find very valuable
• This is only about local notifications which have limited utility.  Push notifications already require https.
• The usage is somewhat an overcount - eg. local notifications on Android already require https but will still trigger the usecounter

Overall LGTM to deprecate in M58 with a plan to remove in M60.  But let's continue with the outreach (eg. AOL, any other major sites we can find - for example maybe do a HTTP Archive grep?) and check back on the data and any feedback we've received in M60 prior to actual removal.  If we have reports of some legitimate sites that need more time and usage hasn't fallen a lot then we might want to delay the removal for a little longer to give sites more time to adapt.

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

--
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.

[Jochen Eisinger]

my lgtm also still stands

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

--
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+...@chromium.org.

[Philip Jägenstedt]

Has an issue/PR been filed on https://github.com/whatwg/notifications yet? Or does some other spec define this in a roundabout way?

[Dominick Ng]

On 7 February 2017 at 17:50, Philip Jägenstedt <foo...@chromium.org> wrote:

Has an issue/PR been filed on https://github.com/whatwg/notifications yet? Or does some other spec define this in a roundabout way?

We'll file an issue against the Notifications spec shortly. :)

By my count, that's 2 LGTMs. Chris, you mentioned you were okay to deprecate, but wanted to see lower usage before removal. Does that still stand (i.e. we will move ahead to deprecate in M58, and continue with the outreach etc.)?

[Philip Jägenstedt]

What milestone do you have in mind for removal? Having this seems to be useful to both make it clear that it's actually going to be removed and it allows developers to plan their work.

If outreach is needed and the removal date is uncertain, is deprecation still valuable? Deprecations don't reliably drive down usage, especially when starting from a low level.

[Dominick Ng]

We're planning to deprecate in M58 for removal in M60. As you say, a concrete removal date is valuable, and some partners have already mentioned to us that having a solid date will help push their HTTPS migration plans.

[Chris Harrelson]

Hi,

I'm ok with deprecation in M58 and a goal of removal in M60, but I think you should come back to us at that time with a new Intent with updated numbers, at which time we can make a final decision.

Chris

[Dominick Ng]

Thanks Chris and everyone else. We'll proceed with deprecation and have an update on this thread for M60 for a final decision.

[Philip Jägenstedt]

LGTM3 to that, if the deprecation is happening we might as well commit to the removal. I would say though that updating the spec (not just filing an issue) should block the actual removal, can you comment here when that's done? Given the non-trivial usage, it matters rather a lot precisely how it will be broken.

[Dominick Ng]

Thanks Philip. I've filed a spec issue at https://github.com/whatwg/notifications/issues/93. We'll look to codify exactly how the API will behave over HTTP prior to the actual removal (with our suggested option being to act like the permission was previously denied by the user).

[vand...@gmail.com]

Rather than wrangle over the latest API to receive this treatment, could I--as a web developer--request that the Chrome folks
provide a roadmap of what will receive this treatment?  The arguments used here could apply to <audio>, <video>,
heck ultimately <input>/<button>/<textarea> (except for usage percentage).  Rather than find the holes in the Swiss
cheese sequentially, could you just break out a list of what will be pulled behind the "HTTPS everywhere" line, and in
what timeframe?

I do consulting for disaster IT planning, and there are multiple scenarios where we need to bring up services behind
networks with ad hoc addressing and limited DNS support.  I'm concerned that something's going to surprise us just
when we least need a surprise.  We hit the getUserMedia one already, now I'm wondering about uploads?  Worse,
the thing I'm not guessing and then I miss the announcement.

[PhistucK]

I advise you to start a new thread for that, it will get more exposure and maybe more responses from the various teams.

☆PhistucK

--
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.

[Peter Beverloo]

Hi all -

The intended removal of being able to request notification permission from insecure contexts has been pushed back by one milestone, to M61.

It will now coincide with removal of the ability to request notification permission from iframes. We hope that grouping them together will make communicating the changes to developers easier.

https://groups.google.com/a/chromium.org/d/topic/blink-dev/n37ij1E_1aY/discussion

Thanks,

Peter

[Anne van Kesteren]

On Wed, Feb 8, 2017 at 5:29 AM, Dominick Ng <domi...@chromium.org> wrote:
> Thanks Philip. I've filed a spec issue at
> https://github.com/whatwg/notifications/issues/93. We'll look to codify
> exactly how the API will behave over HTTP prior to the actual removal (with
> our suggested option being to act like the permission was previously denied
> by the user).

Is this still happening? It's been a couple months and it's still
unclear how to change the standard. (And I don't think
web-platform-tests have been created either.) Also, will you be filing
bug reports against other browsers suggesting they do something
similar?


--
https://annevankesteren.nl/

[Dominick Ng]

We'll be following up on this in the near future. Per Peter's email from two weeks ago, we'll remove requesting Notifications permission from Chrome in M61, scheduled for release in mid September.

[skul...@gmail.com]

What is the status of this? M61 is released to general public but notifications still work.

Also, the following real-life use case rely on notifications to alert the listener as to when a show changes from a playlist to live.

http://player.gridstream.org/

Now, https is planned for the domain down the road but not possible due to technical and financial reasons currently.

However the use of notifications in this case has no security implications.

[michel....@veolia.com]

I'm sorry for asking this here, but i cannot find the right answer and the communication around this breaking change is not really clear...

Is it the request to use Notifications that supposedly will no longer work in M61?

I'm using M61 (61.0.3163.100) and the request still happens & the notifications still appear.

This is on a intranet website by the way - so it should not be considered as "insecure"...

It's also overkill to make us install SSL certificates on an intranet website just to make use of the Notifications API

[Dominick Ng]

This change was pushed back one additional milestone to Chrome M62 (due for release later this week) as the implementation work took longer than expected. Apologies for the missing update here.