How exactly Notification Delegation does work?

[FluorescentHallucinogen]

From the description, I don’t quite understand how Notification Delegation works.

Could you please explain?

If I set enableNotifications to true, does this mean that notifications will be managed by TWA wrapper and Chrome notification permission prompts will not be displayed (because TWA wrapper is Android native app and notifications in Android native apps are enabled by default without permission prompts)?

If yes, how does this fit with the recent notification experiment in Chrome?

[PEConn]

You've got it correct.

The first time the TWA is run, we enable Chrome notifications for the associated origin. If the TWA has notifications disabled in Android Settings, we disable them in Chrome instead. There's a little bit of latency with how this gets propagated, but things should get updated on the next TWA launch at latest.

When the TWA is uninstalled, the notification permission is set to whatever it was before it was installed.

I don't know about those experiments 100%, but this should take precedence over them. (It looks like the experiments are to do with how the notification prompt is displayed to the user - we just set the notification permission, not requiring a user prompt at all.)

[FluorescentHallucinogen]

@PEConn

Thanks for clarification!

By the way, what about delegation of other permissions (like geolocation, etc.), not only notifications? Is it possible?

PTAL at https://crbug.com/974785 for motivation.

TL;DR: It's very difficult, if not impossible, to explain to ordinary users (not developers) that in order to change permissions for the app they need to go to the browser. This is not obvious and inconvenient (hidden deep in the browser settings). Most ordinary users don't distinguish PWA from Android native apps (they look and feel like native Android app: icon on the home screen, standalone mode, etc.). It would be really nice to integrate PWA permissions more deeply into OS (into Android app settings). This is the first place users try to open to change permissions.

[PEConn]

Yeah, we're planning on expanding permission delegation to include permissions other than notifications.

Since each different permission needs to be plumbed through manually, we're going to be starting with the bigger ones (Geolocation and maybe Camera, although that's a complex API) and then evaluating the payoff for the rest. The other difficulty is that while notifications are enabled by default, the rest aren't, so when a website requests a permission, we need to pipe that through to the client app and have that display the Android UI.

[FluorescentHallucinogen]

@PEConn I've partially fixed the problem described in #60 (comment) by #61.

[FluorescentHallucinogen]

@PEConn

Yeah, we're planning on expanding permission delegation to include permissions other than notifications.

Any progress on that?

[PEConn]

We're going to be looking into Geolocation this quarter (no guarantees on when it will be finished).

Is there any specific API you're waiting on?

[FluorescentHallucinogen]

Is there any specific API you're waiting on?

I look forward for geolocation permission delegation.

The only nuance that I see is that we should cover the case when geolocation disabled in the OS/device settings (not Android app settings):

[FluorescentHallucinogen]

Also very interested how Geolocation Delegation will fit with background geolocation (https://joebirch.co/2019/03/18/exploring-android-q-location-permissions/)?

[PEConn]

We don't have any answers for you now, but should do in the coming months.

…

On Tue, 14 Jan 2020 at 11:31, Alexey Rodionov ***@***.***> wrote: Also very interested how Geolocation Delegation will fit with background geolocation ( https://joebirch.co/2019/03/18/exploring-android-q-location-permissions/)? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60?email_source=notifications&email_token=AA4LBZNL2EHCZ2HGYXK22W3Q5WPAFA5CNFSM4JIWZII2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI4I5TI#issuecomment-574131917>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4LBZLNVPU7ZNIUO44RWB3Q5WPAFANCNFSM4JIWZIIQ> .

[tobiasharle]

The first time the TWA is run, we enable Chrome notifications for the associated origin. If the TWA has notifications disabled in Android Settings, we disable them in Chrome instead. There's a little bit of latency with how this gets propagated, but things should get updated on the next TWA launch at latest.

Are you saying that Notification.permission should return true without the need to call Notification.requestPermission?

Because that is not the case for me. I still have to request the permission even though I have my TWA setup with a DelegationService working. It is receiving the notifications I'm sending.

[PEConn]

Yes, that should be the case. Are you setting `enableNotifications` to true in the build.gradle? And verification is completing successfully? Other than that, are you requesting the permission the instant the user loads the page? There may be a delay with the propagation, so maybe wait for a user interaction.

…

On Wed, 22 Jan 2020 at 04:22, tobiasharle ***@***.***> wrote: The first time the TWA is run, we enable Chrome notifications for the associated origin. If the TWA has notifications disabled in Android Settings, we disable them in Chrome instead. There's a little bit of latency with how this gets propagated, but things should get updated on the next TWA launch at latest. Are you saying that Notification.permission should return true without the need to call Notification.requestPermission? Because that is not the case for me. I still have to request the permission even though I have my TWA setup with a DelegationService working. It is receiving the notifications I'm sending. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60?email_source=notifications&email_token=AA4LBZLLHOPQKYPJASC7B33Q7AF4XA5CNFSM4JIWZII2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJS2NZA#issuecomment-577087204>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4LBZOVSIMRPBGIZKPWAILQ7AF4XANCNFSM4JIWZIIQ> .

[FluorescentHallucinogen]

@PEConn @andreban I'm concerned that Notification Delegation could be used to circumvent Quieter Notifications.

[PEConn]

Your link doesn't talk about users getting too many notifications, but about users getting too many notification permission prompts. Notification Delegation helps with this because an installed TWA doesn't have to ask for the notification permission, it gets it automatically. Yes, it's true that a user installing a TWA can now get push notifications, but this aligns with how native Android apps work and we're trying to reduce the differences between TWAs and native apps. Also, app installation is seen as a stronger signal than accepting the notification permission.

…

On Wed, 22 Jan 2020 at 11:36, Alexey Rodionov ***@***.***> wrote: @PEConn <https://github.com/PEConn> @andreban <https://github.com/andreban> I'm concerned that Notification Delegation could be used to circumvent Quieter Notifications <https://blog.chromium.org/2020/01/introducing-quieter-permission-ui-for.html> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#60?email_source=notifications&email_token=AA4LBZOEYWRZ6VW6DAJA3STQ7BYXHA5CNFSM4JIWZII2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJUHYPQ#issuecomment-577272894>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4LBZLNW4QHQK6JKZHOLRDQ7BYXHANCNFSM4JIWZIIQ> .

[andreban]

Quieter Notifications aim to fix the issue where sites ask for notification permission even before a user engages with it for the first time (eg: on the first visit).

TWAs have the same behaviour as native Apps and get the notification permission by default. I think the concern here would be for developers to abuse and spam users with notifications. But this frustrates those who could be the most engaged users, and leads to the user uninstalling the app.