Intent to Deprecate and Remove: Insecure origin usage of Notifications

瀏覽次數:1,664 次
跳到第一則未讀訊息

Emily Schechter

未讀,
2017年1月10日 下午3:19:282017/1/10
收件者:blin...@chromium.org、domi...@chromium.org、mk...@chromium.org、Rick Byers、Joel Weinberger
Primary eng (and PM) emails

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%:

OWP launch tracking bug

Entry on the feature dashboard

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

未讀,
2017年1月11日 凌晨3:57:162017/1/11
收件者:Emily Schechter、blin...@chromium.org、domi...@chromium.org、mk...@chromium.org、Rick Byers、Joel Weinberger
lgtm1

Mike West

未讀,
2017年1月11日 凌晨4:02:122017/1/11
收件者:Jochen Eisinger、Emily Schechter、blink-dev、domi...@chromium.org、Rick Byers、Joel Weinberger
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

未讀,
2017年1月11日 凌晨4:12:082017/1/11
收件者:Mike West、Jochen Eisinger、Emily Schechter、blink-dev、domi...@chromium.org、Rick Byers、Joel Weinberger
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

未讀,
2017年1月11日 清晨5:36:332017/1/11
收件者:Anne van Kesteren、Mike West、Jochen Eisinger、Emily Schechter、blink-dev、domi...@chromium.org、Rick Byers、Joel Weinberger
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

未讀,
2017年1月11日 清晨6:12:562017/1/11
收件者:Drew Wilson、Anne van Kesteren、Mike West、Jochen Eisinger、Emily Schechter、blink-dev、Dominick Ng、Rick Byers、Joel Weinberger
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

未讀,
2017年1月11日 清晨7:32:052017/1/11
收件者:Dominick Ng、Drew Wilson、Anne van Kesteren、Jochen Eisinger、Emily Schechter、blink-dev、Rick Byers、Joel Weinberger
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

未讀,
2017年1月12日 下午1:12:412017/1/12
收件者:Mike West、Dominick Ng、Drew Wilson、Anne van Kesteren、Jochen Eisinger、Emily Schechter、blink-dev、Rick Byers、Joel Weinberger
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

未讀,
2017年1月23日 下午6:49:392017/1/23
收件者:Chris Harrelson、Mike West、Dominick Ng、Drew Wilson、Anne van Kesteren、Jochen Eisinger、Emily Schechter、blink-dev、Rick Byers、Joel Weinberger
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

未讀,
2017年1月24日 晚上11:42:322017/1/24
收件者:Dominick Ng、Mike West、Drew Wilson、Anne van Kesteren、Jochen Eisinger、Emily Schechter、blink-dev、Rick Byers、Joel Weinberger
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

未讀,
2017年1月25日 清晨6:02:012017/1/25
收件者:Chris Harrelson、Dominick Ng、Mike West、Drew Wilson、Anne van Kesteren、Emily Schechter、blink-dev、Rick Byers、Joel Weinberger
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

未讀,
2017年2月2日 晚上8:27:132017/2/2
收件者:Jochen Eisinger、Chris Harrelson、Dominick Ng、Mike West、Drew Wilson、Anne van Kesteren、Emily Schechter、blink-dev、Joel Weinberger
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

未讀,
2017年2月2日 晚上8:30:132017/2/2
收件者:Rick Byers、Chris Harrelson、Dominick Ng、Mike West、Drew Wilson、Anne van Kesteren、Emily Schechter、blink-dev、Joel Weinberger

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

未讀,
2017年2月7日 凌晨1:50:502017/2/7
收件者:Jochen Eisinger、Rick Byers、Chris Harrelson、Dominick Ng、Mike West、Drew Wilson、Anne van Kesteren、Emily Schechter、blink-dev、Joel Weinberger
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

未讀,
2017年2月7日 凌晨1:57:202017/2/7
收件者:Philip Jägenstedt、Jochen Eisinger、Rick Byers、Chris Harrelson、Dominick Ng、Mike West、Drew Wilson、Anne van Kesteren、Emily Schechter、blink-dev、Joel Weinberger
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

未讀,
2017年2月7日 上午11:35:112017/2/7
收件者:Dominick Ng、Jochen Eisinger、Rick Byers、Chris Harrelson、Mike West、Drew Wilson、Anne van Kesteren、Emily Schechter、blink-dev、Joel Weinberger
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

未讀,
2017年2月7日 下午5:20:242017/2/7
收件者:Philip Jägenstedt、Dominick Ng、Jochen Eisinger、Rick Byers、Chris Harrelson、Mike West、Drew Wilson、Anne van Kesteren、Emily Schechter、blink-dev、Joel Weinberger
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

未讀,
2017年2月7日 下午5:39:012017/2/7
收件者:Dominick Ng、Philip Jägenstedt、Jochen Eisinger、Rick Byers、Mike West、Drew Wilson、Anne van Kesteren、Emily Schechter、blink-dev、Joel Weinberger
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

未讀,
2017年2月7日 下午5:44:452017/2/7
收件者:Chris Harrelson、Dominick Ng、Philip Jägenstedt、Jochen Eisinger、Rick Byers、Mike West、Drew Wilson、Anne van Kesteren、Emily Schechter、blink-dev、Joel Weinberger
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

未讀,
2017年2月7日 晚上10:52:492017/2/7
收件者:Dominick Ng、Chris Harrelson、Jochen Eisinger、Rick Byers、Mike West、Drew Wilson、Anne van Kesteren、Emily Schechter、blink-dev、Joel Weinberger
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

未讀,
2017年2月7日 晚上11:29:462017/2/7
收件者:Philip Jägenstedt、Dominick Ng、Chris Harrelson、Jochen Eisinger、Rick Byers、Mike West、Drew Wilson、Anne van Kesteren、Emily Schechter、blink-dev、Joel Weinberger
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

未讀,
2017年2月8日 下午2:18:102017/2/8
收件者:blink-dev、domi...@chromium.org、mk...@chromium.org、rby...@chromium.org、j...@chromium.org、emilysc...@chromium.org
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

未讀,
2017年2月8日 下午3:43:362017/2/8
收件者:vand...@gmail.com、blink-dev、Dominick Ng、Mike West、Rick Byers、jww、Emily Schechter
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

未讀,
2017年4月11日 下午2:46:322017/4/11
收件者:Dominick Ng、Emily Schechter、blink-dev、Joe Medley
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.


Thanks,
Peter

Anne van Kesteren

未讀,
2017年4月24日 清晨5:13:062017/4/24
收件者:Dominick Ng、Philip Jägenstedt、Chris Harrelson、Jochen Eisinger、Rick Byers、Mike West、Drew Wilson、Emily Schechter、blink-dev、Joel Weinberger
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

未讀,
2017年4月24日 清晨6:33:102017/4/24
收件者:Anne van Kesteren、Dominick Ng、Philip Jägenstedt、Chris Harrelson、Jochen Eisinger、Rick Byers、Mike West、Drew Wilson、Emily Schechter、blink-dev、Joel Weinberger
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

未讀,
2017年10月3日 上午10:36:042017/10/3
收件者:blink-dev、domi...@chromium.org、mk...@chromium.org、rby...@chromium.org、j...@chromium.org、emilysc...@chromium.org
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.

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

未讀,
2017年10月20日 上午9:44:052017/10/20
收件者:blink-dev、ann...@annevk.nl、domi...@chromium.org、foo...@chromium.org、chri...@chromium.org、joc...@chromium.org、rby...@chromium.org、mk...@chromium.org、atwi...@chromium.org、emilysc...@chromium.org、j...@chromium.org
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

未讀,
2017年10月22日 晚上8:07:402017/10/22
收件者:michel....@veolia.com、blink-dev、Anne van Kesteren、Dominick Ng、Philip Jägenstedt、Chris Harrelson、Jochen Eisinger、Rick Byers、Mike West、Drew Wilson、Emily Schechter、Joel Weinberger
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.


回覆所有人
回覆作者
轉寄
0 則新訊息