Web-Facing Change PSA: Notifications API disabled in incognito in Chrome 49+

[John Mellor]

From Chrome 49, it will no longer be possible for websites to gain notifications permission in incognito. Instead it will appear as if the user always denies the permissions prompt (after a random time delay), which is web compatible.

This is to prevent websites that have notifications permission from being able to detect whether incognito mode is active. Previously, since the Push API has never been supported in incognito, a website that has notifications permission could reliably detect incognito mode by checking whether the Push API works.

It's an unfortunate trade-off, though in practice we haven't found many use cases where notifications were useful in incognito.

If/when the Push API becomes supported in incognito, this restriction will be removed.

[Elliott Sprehn]

This means logging into Google Music or other music services in an incognito window won't tell you what song is currently playing? :/

Also what's being done about this causing Facebook to cover the entire page in a black overlay which makes Facebook seem broken in Chrome?

How does Chrome tell the user that the notification permission is rejected? Apps will tell you to accept the permission prompt but none will ever appear. This seems like bad Chrome UX.

[John Mellor]

On 15 January 2016 at 18:16, Elliott Sprehn <esp...@chromium.org> wrote:

This means logging into Google Music or other music services in an incognito window won't tell you what song is currently playing? :/

Correct.

Also what's being done about this causing Facebook to cover the entire page in a black overlay which makes Facebook seem broken in Chrome?

Facebook shows a black overlay until the Push API PushManager.subscribe() promise - which also requests notification permission - is resolved or rejected. Previously that promise would just hang forever in incognito. In m49, the promise will be rejected once the permission reject is automatically denied, after the random time delay (1-2 seconds).

 

How does Chrome tell the user that the notification permission is rejected? Apps will tell you to accept the permission prompt but none will ever appear. This seems like bad Chrome UX.

It's a compromise. UX folks felt it was better to silently deny it than to show an unactionable reminder that this feature isn't available every time they visit such a site in incognito.

[Mounir Lamouri]

On Fri, 15 Jan 2016, at 18:36, John Mellor wrote:
> On 15 January 2016 at 18:16, Elliott Sprehn <esp...@chromium.org> wrote:
>
> > This means logging into Google Music or other music services in an
> > incognito window won't tell you what song is currently playing? :/
> >
>
> Correct.

I'm not aware of a website using the Notifications API to show the
currently playing title. Given the user gesture restrictions that might
even not be doable. Does one of you know of such website?

-- Mounir

[PhistucK]

The user gesture is only required for approving the permission (you seem to be implying that it requires it for showing a notification, but perhaps I misunderstand).

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

[Mounir Lamouri]

On Tue, 19 Jan 2016, at 21:55, PhistucK wrote:
> The user gesture is only required for approving the permission (you seem
> to
> be implying that it requires it for showing a notification, but perhaps I
> misunderstand).

You're right. My comment didn't make sense. Thanks for correcting :)

Still interested to know if there are websites in the wild using the
Notifications API to show media info. I would be interested to look at
what they are doing.

-- Mounir

[Elliott Sprehn]

Yes, Google Music shows "Now Playing" notifications.

[Mounir Lamouri]

Interesting. I use Google Music so I was surprised to see that there is
actually a Lab (ie. experiment off by default) that enables Desktop
Notifications. Fairly hard to find if you don't know what you are
looking for.

-- Mounir

[Jeffrey Yasskin]

Do we really need to disguise the fact that a user is running in incognito mode? The user-facing documentation and the privacy policy only say Chrome won't save data to the local machine. We explicitly say that incognito doesn't hide your browsing from the sites you visit.

Of course, doing things differently in incognito mode can make incognito web-incompatible, but that points toward supporting Push in incognito, not making notifications also differ.

Jeffrey

On Fri, Jan 15, 2016 at 9:34 AM, John Mellor <joh...@chromium.org> wrote:

[Chris Palmer]

On Tue, Jan 19, 2016 at 3:34 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

Do we really need to disguise the fact that a user is running in incognito mode?

I have always heard — and I recognize this is just 'lore' :( — that it is a key guarantee of Incognito Mode that servers should not be able to tell if a client is in Incognito Mode.

The user-facing documentation and the privacy policy only say Chrome won't save data to the local machine. We explicitly say that incognito doesn't hide your browsing from the sites you visit.

Correct — but "doesn't hide your browsing from sites" is a (non-)guarantee distinct from "doesn't reveal to sites that you are using Incognito".

Of course, doing things differently in incognito mode can make incognito web-incompatible, but that points toward supporting Push in incognito, not making notifications also differ.

If I understand correctly, I think I agree.

[Brett Wilson]

On Tue, Jan 19, 2016 at 3:58 PM, 'Chris Palmer' via blink-dev <blin...@chromium.org> wrote:

On Tue, Jan 19, 2016 at 3:34 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

Do we really need to disguise the fact that a user is running in incognito mode?

I have always heard — and I recognize this is just 'lore' :( — that it is a key guarantee of Incognito Mode that servers should not be able to tell if a client is in Incognito Mode.

Yes, I think this is a goal.

Brett