Add webpush headers, fake encryption for now

[p1gp1g]

This is a first step for #32

[CLAassistant]

All committers have signed the CLA.

[rfc2822]

For curiosity: Is it for real use? With which server/service?

Faking security doesn't sound like a good idea to me. Would it be an option to change the server so that it doesn't always enforce encrypted payload?

[p1gp1g]

Sunup uses mozilla's webpush server which enforce encryption. It will be advertised as the goto distributor, since it doesn't need any user login, nor to change any setting, the default server doesn't have rate limits and it follows the last specifications.

So, this is a workaround for a real use, until notifications are properly encrypted (following webpush specs)

[rfc2822]

I still think it's a security issue to mark non-encrypted data as encrypted. Let's assume the service is hacked and data leaks – then they can and will say "we made sure that all data is encrypted". If however DAVx5 or Nextcloud had marked unencrypted data as encrypted, DAVx5 or this extension will then rightly be blamed for the data leak.

If it's that important, we should implement encryption instead.

Or is there anything I have missed?

[p1gp1g]

I agree, and this is definitely a workaround until encryption is properly setup.

But there 2 things to keep in mind:

• Push notifications don't contain any sensitive information (It sends only the collection id)
• This extension is properly marked as unstable and not ready for production (in the README) :

This extension is in an early stage of development. It is for demonstration and testing purposes only. Don't use it on production systems!

So, I think this is OK to do the hack as a first step for a transparent transition to the encrypted notifications

[rfc2822]

Push notifications don't contain any sensitive information (It sends only the collection id)

Plus the sync token. Hopefully servers won't use sensitive information for the topic or sync-token.

This extension is properly marked as unstable and not ready for production (in the README) :

Good point. I suggest that we also add the hint that it marks unencrypted data as encrypted into the README, directly after the sentence above.

[p1gp1g]

It makes sense, I've pushed a change for the README