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

[nickvergessen]

[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

[p1gp1g]

I'm thinking about the GDPR concern: it would apply to https://push-notifications.nextcloud.com/ * too as it works the same way, but in addition, it isn't provided by the user

* And all mobile applications that use push notifications

[nickvergessen]

as it works the same way, but in addition, it isn't provided by the user

The GDPR concern is mostly about the default case, not about opt-in like using a mobile app. The self-hosted unified push is less an issue compared to the "by default as soon as your browser is subscribed you send meta info to Apple, Google, Microsoft, Mozilla, …"

The user simply opts-in by granting the browser the notification permission. But we want to keep an admin opt to control this.

The default value of the bool config is a quick change afterwards and I will discuss it again with the relevant people once the feature is ready for testing (with frontend and everything merged)

[nickvergessen]

/compile amend

[Antreesy]

Looks good