Why couldn't the entire system be E2E encrypted by default, though? In 2022, that's my standard expectation from any service. Even such things as Pocket / Instapaper / Raindrop should come with E2E encryption by default. It's better for the service provider, too: no issues with GDPR, or in case of a database hack.
Genuine question - have you ever implemented an E2E encrypted system?
Because it's not particularly easy to do, and there are a lot of caveats and drawbacks.
Let me rephrase your assumption: "Why couldn't you just mail me the letter in a 100lb safe. In 2022, that's my standard expectation from any service".
So - are you willing to pay to ship 100lbs for every letter you send? Are you meticulously managing the details of how to handle locking and unlocking that safe? Are you working out the details on recovery and storage, handling lost devices, configuring a communication channel for sharing certs/keys, managing several crypto dependencies and libraries - all so that you can go "Hey - what's up!" in a notification to your phone?
Or should you just stop whining - accept that this is free - and take the authors advice and host it yourself?
I run a E2E system using public and private keys. It's really not that complex.
Sure, it's not free, but the implementation effort was 1/100 of the UI work.
Clients encrypt data in the browser, share id of the data and key (+ optional password). Some other clients receive id of the data and the key and read it.
For a notification service, you would just need a setup step to generate a key and store it in the browser + on the phone.
That said, I'm not sure I understand why would someone need to notify its own phone.
> Are you working out the details on recovery and storage, handling lost devices, configuring a communication channel for sharing certs/keys, managing several crypto dependencies and libraries - all so that you can go "Hey - what's up!" in a notification to your phone?
In 2022, there is no need to invent anything new about E2E encryption. There are many successful open-source examples, including Keybase and Firefox Sync.
There is no question that it adds development overhead, but I personally wouldn't even run a public service for others without E2E encryption.
> Or should you just stop whining - accept that this is free - and take the authors advice and host it yourself?
I am not attacking the author, nor do I currently care about this particular service he is providing.
This is Hacker News, a discussion platform, and I am raising a question about software development in general.
>This is Hacker News, a discussion platform, and I am raising a question about software development in general.
No - no you aren't. You're complaining about a feature in a product you've admitted you won't use.
Which... is fine. At the end of the day - the feedback might be helpful or it might not, part of the journey of publishing software (or making anything, really) is figuring out what advice to listen to, and what to ignore.
But personally - I don't really find your point sensible. You have no use-case, you have no threat model, you have a very unclear understanding of what E2E encryption entails, in my opinion - since you point to apps whose entire marketing shtick is that they have E2E encryption and say "if they are doing it, it must be easy" - Ignoring that they are literally using the difficulty of doing it as the distinguishing factor for their product.
But hey - I worked for a security company that did E2E encryption for fortune 100 companies, mostly banks, for 5 years (and eventually went out of business... as an aside) so what do I know...
> But personally - I don't really find your point sensible. You have no use-case, you have no threat model [...]
My point is very clear and simple: all private communication on the internet should be E2E encrypted by default, unless there is a good reason not to.
> [...] say "if they are doing it, it must be easy" - Ignoring that they are literally using the difficulty of doing it as the distinguishing factor for their product.
I am not claiming that it's easy, but there has been plenty of open-source projects launched with E2E encryption by default in the past few years.
> all private communication on the internet should be E2E encrypted by default, unless there is a good reason not to.
Why? Why do you think this. What value do you imagine this is bringing you beyond simple TLS?
Because to me, this is like saying "All conversations should be whispered by default, unless there is a good reason not to." except that's obviously not reasonable, because there are many reasons not to whisper all the time. In the same way that there are many reasons wrapping all your communication into a black box is a bad idea (discoverability and search being the most obvious two, although data loss is right on up there).
> My point is very clear and simple: all private communication on the internet should be E2E encrypted by default, unless there is a good reason not to.
Are you counting HTTPS as “E2E encrypted”? Because if not, consider that we do private communication over mere HTTPS all day long. Me loading the HN web page and having my own personal rendering of it with my user cookie header and all my upvote/downvote/karma/profile state is private communication, for example.
> Because if not, consider that we do private communication over mere HTTPS all day long. Me loading the HN web page and having my own personal rendering of it with my user cookie header and all my upvote/downvote/karma/profile state is private communication, for example.
Because there is a good reason for it: it wouldn't work well with E2E encryption.
Well, ok, I guess we can use that as a justification for anything then. For example, the “good reason not to” use E2E for ntfy could be “market analysis says the small and somewhat theoretical benefit isn’t worth the complexity.”
Yes, but you said all private communication should be E2E. Apparently you're defining communication in some way that excludes an awful lot of what I'd consider communication (e.g. HTTPS traffic).
My key point was "unless there is a good reason not to". And in many cases there is a good reason not to use E2E encryption, like the example you have given. But in the case of Ntfy, E2E encryption would be a perfect fit, and eliminate any need for self-hosting.
I'll be blunt - as someone who worked in the space extensively... if you really need e2e encryption, you want to be self hosting anyways.
By the time you're trusting a hosting provider to properly do e2e for you... you've basically already lost the game. At any point they can update what's running and remove any/all protections you think you have.
So again - what is your threat model here? Because it sounds like you want "super convenient" and also "super secure" and those aren't two options you just check off - they're really more like diametrically opposed sides of the same slider.
You solve that by forwarding/decrypting/adding noise between servers, enough to cover metadata traffic you generate. The only data you reveal is anyone listening know you might have used it at some point. See https://vuvuzela.io/ I suspect it is named so because it uses a lot of bandwidth.
Encryption and convenience usually don't go well together. ntfy was mainly built for simplicity. That said, I have designed and started working on E2E here: https://github.com/binwiederhier/ntfy/issues/69
The pitch is that you can go `curl -d "My message" ntfy.sh/my_topic` and it just works. That's impossible if you want E2EE.
Fortunately, it's open-source, so if you really want, you can fork the app to add a decryption layer and then use `curl -d "$(echo "My Message" | openssl enc -aes-256-cbc -pbkdf2 -e -k "My Password")" ntfy.sh/my_topic` and that'll be E2E encrypted.
Or, you know, host your own ntfy server and trust in SSL.
You have perfectly captured my intention. :-) ntfy is supposed to be simple simple simple.
E2E stands in the way in many ways. I have implemented crypto formats and such in the past, and the lack of a standard in this space is really blocking wide spread adoption and interoperability IMHO. That said, I have proposed a design here (https://github.com/binwiederhier/ntfy/issues/69#issuecomment...) that I have already partially implemented, and that seems easy enough to implement in many languages. But it definitely won't be the one-liner anymore.
The most important bits aren't the technical aspects, but rather who controls them.
It is entirely meaningless when the keys are generated by a closed source application, when there exists no way to verify that the data isn't exfiltrated before its encryption or after its decryption, or when the only transportation method is entirely in an untrusted party's hands.
When all those things are controlled by the same entity, especially one with a history of abusive and manipulative behaviour such as the operator of WhatsApp, it's not "encryption" but a "bad joke".
Encrypting stuff in a way that can’t be trivially subverted by a malicious client app is actually pretty hard, so what have you actually gained if you’re going to trust the client app?
Encryption by default eliminates the biggest advantage: simplicity. But as an option, it's an useful addition that will be implemented sooner or later.
If you don’t trust a communication channel, you could always do a Diffie-Hellman key exchange in the clients which lets you create a shared encrypted channel between two parties by sharing public keys. This works even if they are trying to monitor you.
It can work with simplex channels if you have the public key of the receiver. Both parties just need to know each other's public keys to create encrypted communication. After exchanging the public keys, it can be one-way communication.
I guess it wouldn't work for a one-to-many channel though, just individual one-to-one channels.
If you run binaries compiled by the author of the software it wouldn't matter that it is open source, so play store is out of the question. So then it must be open source and you must use distributor you trust: your distro maintainers and F-Droid.
Also you must trust that people did really take a look at the code.
> Therefore, no need to trust anybody, as long as the software is open-source.
Demonstrably untrue. You must trust that the contributors are trustworthy, they have implemented a strong security posture for their project, and that the code is reviewed by people who are trustworthy. Many open-source projects have been, and continue to be, compromised on a regular basis.
That's only the case if I am unable to review the code myself, before any update, I fully understand the code, and I am smart enough that the contributors are unable to pull a fast one on me.
Given that I'm not a cryptography expert, I have a limited number of hours in the day, and open-source supply chain attacks are typically obfuscated, I don't consider that to be a trivial statement.
You have 0 guarantee that the open source code is actually the code that runs on your device.
And you have 0 guarantee that the device itself is not compromised.
And you have 0 guarantee that the OS is not storing your data.
E2E on mobile devices is a security blanket with holes the size of the solar system.
