Intent to Deprecate and Remove
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/IVgkxkRNtMo

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/416b2f1ded0eb7454dc1e84600341bbd75dd23ed

commit 416b2f1ded0eb7454dc1e84600341bbd75dd23ed
Author: dominickn <dominickn@chromium.org>
Date: Thu Feb 09 01:28:51 2017

Add a deprecation warning for notifications on insecure contexts.

This CL adds a deprecation warning for the M60 removal of access to the
Notifications API on insecure contexts.

See the blink-dev Intent to Deprecate and Remove thread at
https://groups.google.com/a/chromium.org/forum/#!topic/Blink-dev/IVgkxkRNtMo
for more information.

BUG= 679821 

Review-Url: https://codereview.chromium.org/2681723003
Cr-Commit-Position: refs/heads/master@{#449180}

[modify] https://crrev.com/416b2f1ded0eb7454dc1e84600341bbd75dd23ed/third_party/WebKit/Source/core/frame/Deprecation.cpp
[modify] https://crrev.com/416b2f1ded0eb7454dc1e84600341bbd75dd23ed/third_party/WebKit/Source/core/frame/UseCounter.h
[modify] https://crrev.com/416b2f1ded0eb7454dc1e84600341bbd75dd23ed/third_party/WebKit/Source/modules/notifications/Notification.cpp
[modify] https://crrev.com/416b2f1ded0eb7454dc1e84600341bbd75dd23ed/tools/metrics/histograms/histograms.xml

Updating milestone to M61.

Thanks 

Thanks 

Please consider those of us who have many (as in MANY) internal business tools, that are only ever connected to via LAN or through SSH/VPN tunnels. For such tools HTTPS is nothing but a hassle.

I understand the need to make this more secure, but surely something can be done to allow notifications over plain HTTP using commandline flags or something similar.

Please?  :)

c#7: please see https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins, particularly the section on "Testing a Powerful Feature".

c#8: I have read that, and I stumbled on the "Note that you also need to include the --user-data-dir=/test/only/profile/dir to create a fresh testing profile for the flag to work" part.

This does not seem like a very good solution for tools that are not being tested, but are actually running in production.

How about just having --enable-powerful-features-for-insecure-origins="http://example.com,....."

Can we even get certificates for domain names that only exist in our local context? How would we validate such certificates?

Please consider having a solid system for using notifications (and similar features) on LAN services that are trusted by the user.

Hi Thomas --

If your infrastructure is on the Internet, use LetsEncrypt or similar to get a publicly trusted certificate, or
If your infrastructure isn't on the Internet, create a private root certificate, configure your dev/test machines to trust it, and use that certificate to issue certificates to your test/dev/preproduction environments.

Hi Emily

Our infrastructure is not on the Internet. It's LAN only and in production.

My problem with this change is not in regards to dev/test, but with the fact that HTTPS make little to no sense for LAN only tools/services, of which we have a whole bunch.

Setting up and managing certificates in such a scenario is a massive hassle, for absolutely zero gain.

I really really really hope you'll consider having some sort of flag/option to either bypass this, or at the very least mark certain domain names as "safe", even though they are accessed over plain HTTP, else we'll be stuck on Chromium <61 forever.

Hi,
Will using the notifications API in a non-secure origin throw an Exception? So In case of using it in a non-secure origin should i just catch the exception?

c#13: the intention is that using the notifications API on a non-secure origin will behave exactly like the user denying the site permission. No exception should be thrown.

This thread nicely describes why HTTPS on LAN is a pain:

https://security.stackexchange.com/questions/121163/how-do-i-run-proper-https-on-an-internal-network

Have you guys come up with a decent solution for those of us who use notifications on LAN services?

+Thomas, 

I'm in the kinda same situation. Except that my site is on the web, but only used by us. I was thinking to create a Chrome Extension to deal with the Notifications, but the bug report doesn't really explain this part. We are still in the "Proof of concept" part and eventually we will move completely to LAN. Our company use self certs but its so much pain that we constantly getting "This site is not trusted..." warnings. We can go to the site by clicking "Visit site anyway" but still, its ugly... 
I hope Chrome guys can find us some nice solution as I'm sure soooo many of us out there. 

This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues.

We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate.

For more details see here: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit

For any questions, please contact owencm, sshruthi, larforge

Pues esta bien y mal porque los rejistran. Y luego los venden

Siempre va hacer el mismo problema los venfen o sr nos csen o los rbsn siempre seta la misms historia 

Hi,
Our dev apps urls look like http://johndoe.local 
We cant debug Notification API in new Chrome 62 on our dev .local domain. 
How should we debug Notification API tasks? What should we do?

Could you please introduce a setting, browser chrome://flags or something to bring Notifications back for dev purposes?

HEY, MAYBE LOOK AT USING TRUSTED SITES AS DEFINED IN INTERNET EXPLORER OPTIONS SINCE CHROME ALREADY LOOKS THERE FOR THE PROXY SETTINGS IT USES, BECAUSE THE COMPANY DEFINITELY IS NOT PAYING TO SLAP SSL ONTO ALL THE INTERNAL DEV QA STG AND UAT SERVERS NO MATTER HOW MUCH I BEG THEM.  IF THEY WON'T SLAP SSL ON THE QA AND STG AND UAT SERVERS, I CAN'T SHIP THIS MESSAGING STUFF AND WE ALL LOSE.

OR AT LEAST CHANGE "BLOCKED FOR HER PROTECTION" TO SOMETHING USEFUL AND DON'T EVEN ALLOW THE USER TO PERMIT NOTIFICATION MESSAGES IF THE BROWSER WILL ACTUALLY SECRETLY IGNORE USER AND REFUSE TO ALLOW THE NOTIFICATIONS.  USER SAYS "YES" AND BROWSER SHOWS "YES" TO USER, BUT THE SECRET REAL ANSWER IS "NO" WHICH IS ONLY FOUND IF USER DIGS THRU SETTINGS, BUT EVEN THERE, NO REAL EXPLANATION GIVEN.  SUCH AWFUL UX DECISIONS BEING MADE ON THIS ONE. SAD!

I have been attempting to use --unsafely-treat-insecure-origin-as-secure as suggested here: https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins

However Notification API still fails, stating the deprecated message.

More confusing as pointed out by the previous commenter, even for insecure sites Notification API permissions is shown to users (see attachment).

Could an enhancement be considered to allow this feature for unsecure sites if explicitly set to Allow in chrome settings?  That seems the easiest way to allow development and let work admins choose which sites to allow this on without needing SSL on internal sites.

The only other thought would be an enhancement to how VPN and Chrome interact, ideally it would be nice if Chrome told me the access to my internal site was secure because it's being accessed over a private VPN.  It should be easy enough to see in the routing table, but I guess that only works when on VPN and not on internal LAN...

Deleted: chrome.png 8.8 KB

	chrome.png 8.8 KB View Download

I'm using Chrome 62.0.3202.94 (64 bits) on Windows 7 and the demo on push.min.js not working.  I can select whether to always permissions for that page. But not working. My message is not visible.  What do i do for fixed it?

Re #26: Which build are you encountering this on? As noted in  Issue 792993 , the command line flag appears to be broken in Chrome 63. 

This shipped.

This causes https://bugs.chromium.org/p/chromium/issues/detail?id=798361