feat(webpush): Add admin setting to allow opt-in and out of webpush

[nickvergessen]

[Antreesy]

There's no - according to spec: https://datatracker.ietf.org/doc/html/rfc8030

Suggested change

	<h3>{{ t('notifications', 'Web-push') }}</h3>
	<h3>{{ t('notifications', 'Web push') }}</h3>

Or maybe Web push settings?

[nickvergessen]

• yeah lets go with "Web push settings"
• But I guess it also makes sense to either wait for Front/webpush #2663 or to at least add the config in the same moment, as only the browser one should have the warning note card
• At the same time it makes sense to explain to admins whatelse the usecase of this is

[miaulalala]

Suggested change

	* @param string $webpushEnabled Enable web push notifications ('yes' or 'no')
	* @param string $webpushEnabled Enable external web push notifications ('yes' or 'no')

Make sure the admins understand it's external web push services

[miaulalala]

Suggested change

	{{ t('notifications', 'Enable web push notifications') }}
	{{ t('notifications', 'Enable external web push notifications') }}

Same as above

[p1gp1g]

Suggested change

	{{ t('notifications', 'Web push notifications are encrypted but routed through services provided by Microsoft, Apple, and Google. While the content is protected, metadata such as timing and frequency of notifications may be exposed to these providers.') }}
	{{ t('notifications', 'Web push notifications are encrypted but routed through services provided by Microsoft, Apple, Mozilla and Google. While the content is protected, metadata such as timing and frequency of notifications may be exposed to these providers.') }}

Mozilla is one of the big providers too

[nickvergessen]

Right, I thought M… is already in the list. But we have 2 M…

[p1gp1g]

metadata such as timing and frequency of notifications may be exposed to these providers

This is also true with the proxy push to APNS/FCM

[p1gp1g]

I think web push should be enabled by default, just like proxy push is enabled by default, because it doesn't goes against Nextcloud default threat model (cf SSRF, Version disclosure).

In details, compare to other Nextcloud features, web push doesn't really add privacy concern. Concretely, we are talking about one potential risk for hidden instances, not exposed on the Internet, without any federation or email feature, that would exposed their existence to the web push servers used by the users.

So, this hidden instance exposes its existence to the browser provider, which likely already know the instance existence with the browsing history.

This kind of setup must already set outbound connection protection (VPN/Tor), and probably be served as a hidden service too

We are explicitly not talking about the risk that communications would be correlated by a push provider, which isn't in the threat model, because it is already possible with proxy-push and email notifications: we would need a setting to block proxy-push as well.

BTW, every other self-hostable service I know don't even provide a way to disable push.

Anyway, I think an option to disabling web push/push in general is nice to have. I think the config file should be enough for that, I don't know if it is worth a UI setting which is better to avoid when the default is good enough

[nickvergessen]

I think web push should be enabled by default, just like proxy push is enabled by default, because it doesn't goes against Nextcloud default threat model (cf SSRF, Version disclosure).

Not security-wise, but our GDPR office made that call, my hands are tied a bit.

Concretely, we are talking about one potential risk for hidden instances, not exposed on the Internet, without any federation or email feature, that would exposed their existence to the web push servers used by the users.

This is quite a common thing. But yeah I guess we should follow https://github.com/nextcloud/server/blob/bb4c9ecc0e316782227570257856891995b1e369/config/config.sample.php#L985-L990 with it. At least for the browser part.

For mobile apps aka. unified push, it might even be okay as such an organization could set up a local unified push and people then get push notifications via a server that is inside the offline/air-gapped setup? Would that work?

We are explicitly not talking about the risk that communications would be correlated by a push provider, which isn't in the threat model, because it is already possible with proxy-push and email notifications: we would need a setting to block proxy-push as well.

This can and is done via build options in the mobile clients and e.g. by installing the Android apps from F-Droid rather then Google Play.

[p1gp1g]

I think web push should be enabled by default, just like proxy push is enabled by default, because it doesn't goes against Nextcloud default threat model (cf SSRF, Version disclosure).

Not security-wise, but our GDPR office made that call, my hands are tied a bit.

Oh, OK. This is indeed a good thing to think about.

The push server is given by the user, and push notifications don't contains PII (everything is encrypted, the origin IP isn't the user's one, nor the receiving IP). But we know advanced attacks may be done to correlate activities between 2 "users"/push sessions. This the responsibility of the push server the user has registered to with their browser, independently of Nextcloud.

But we should be transparent to the user: in this case, it would be better to get the user consent when they enable push notifications, before registering on the server. There could be a dialog informing that the feature makes the server sharing to the browser service information regarding when they receive a notification.

For example:

1. User opens notifications view
2. Browser ask for notification permission
3. If granted, we show a dialog like "Push notifications allows you to be notified when you have new activity even if Nextcloud isn't opened. The notifications are encrypted but gives information about when you have activity to your browser remote service. Would you like to continue ?"
4. If refused => continue without push, else => register to Nextcloud

Concretely, we are talking about one potential risk for hidden instances, not exposed on the Internet, without any federation or email feature, that would exposed their existence to the web push servers used by the users.

This is quite a common thing. But yeah I guess we should follow https://github.com/nextcloud/server/blob/bb4c9ecc0e316782227570257856891995b1e369/config/config.sample.php#L985-L990 with it. At least for the browser part.

That's a good idea. We can also have another feature push_notifications that has the same value than has_internet_connection by default, but can be different (for the point below)

For mobile apps aka. unified push, it might even be okay as such an organization could set up a local unified push and people then get push notifications via a server that is inside the offline/air-gapped setup? Would that work?

Yes, this is one of the edge-cases covered by decentralized push systems like UnifiedPush: they work in air-gapped setups