6 ms·

From the FAQ[1]: > Will you know what topics exist, can you spy on me? > If you don't trust me or your messages are sensitive, run your own server. This i

by krono 4y ago

From the FAQ[1]: > Will you know what topics exist, can you spy on me? > If you don't trust me or your messages are sensitive, run your own server. This is the way. No pinky promises in whitepaper format[2] that leave out the most important bits, no meticulously constructed but entirely meaningless marketing statements[3][4], but unassuming and deferential logic with a mitigation path. 1: https://ntfy.sh/docs/faq/#will-you-know-what-topics-exist-can-you-spy-on-me https://ntfy.sh/docs/faq/#will-you-know-what-topics-exist-ca... 2: (warning: redirects with identifiers, how ironic) https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf https://www.whatsapp.com/security/WhatsApp-Security-Whitepap... 3: https://privacy.microsoft.com/en-us/privacy-report https://privacy.microsoft.com/en-us/privacy-report 4: https://www.apple.com/privacy/ https://www.apple.com/privacy/

krn 4y ago
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.
- ilogik 4y ago
  If you don't trust the person that wrote the software, it doesn't matter if it's E2E encrypted or not. There could be a back-door
  - ilyt 4y ago
    which software ? You might have 3rd party client implementation that talks with another client and only server would be "unknown" party. E2E allows both clients to talk to eachother without server having a way to snoop on
  - krn 4y ago
    E2E encryption happens on the client side, not on the server side. Therefore, no need to trust anybody, as long as the software is open-source.
    - hawski 4y ago
      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.
      - krn 4y ago
        That's exactly how Signal and Keybase work, and nobody has any problems with that.
        hawski 4y ago
        I had exactly this in mind. Mostly if I wouldn't trust the author with binaries I wouldn't really trust with source code either.
        hamburglar 4y ago
        That’s because most people hear “E2E” and think that somehow means they can automatically trust the client app. It’s a panacea.
    - kube-system 4y ago
      > 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.
      - krn 4y ago
        > You must trust that the contributors are trustworthy In theory, that's only the case if you are unable to review the code yourself. In practice, it's like saying that TLS encryption is pointless, because one needs to trust every single person who implements it.
  - xyzzy4747 4y ago
    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.
    - megous 4y ago
      Doesn't work with simplex channels.
      - xyzzy4747 4y ago
        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.
- binwiederhier 4y ago
  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 https://github.com/binwiederhier/ntfy/issues/69
  - deleted 4y ago
    [deleted]
- horsawlarway 4y ago
  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?
  - krn 4y ago
    > 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.
    - seqastian 4y ago
      > I personally wouldn't even run a public service for others without E2E encryption. So don't? seems like everyone got what they wanted.
      - krn 4y ago
        Well, thinking logically: if everyone really got what they wanted, that question wouldn't be in the FAQ, would it?
- krono 4y ago
  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".
- hdjjhhvvhga 4y ago
  Encryption by default eliminates the biggest advantage: simplicity. But as an option, it's an useful addition that will be implemented sooner or later.
- oliwarner 4y ago
  Go figure out key exchange and use this as transport for encrypted messages. Encrypting stuff isn't hard.
  - hamburglar 4y ago
    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?
- hatware 4y ago
  >Why couldn't the entire system be E2E encrypted by default, though? Probably because getting the system together in its current state was enough work. > In 2022, that's my standard expectation from any service. You have high standards. Do you expect others to raise their standards as high as yours...?
- bccdee 4y ago
  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.
  - binwiederhier 4y ago
    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-1183839284 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.
- googlryas 4y ago
  The answer is simply because that is not how the dev implemented it. Why couldn't you write a patch to do that, and submit it? Or clone the code and release e2entfy.sh?
mathfailure 4y ago
I wish they also provided the code to run own server of ntfy, but instead it looks like they meant "write and run your own server".
- sidpatil 4y ago
  The server is open source. https://github.com/binwiederhier/ntfy https://github.com/binwiederhier/ntfy
- vlugorilla 4y ago
  https://ntfy.sh/docs/faq#can-i-self-host-it https://ntfy.sh/docs/faq#can-i-self-host-it The next topic on the FAQ. Also install instructions are provided.
- sorieus 4y ago
  Didn't look deep but looks like the sever code is provided + multiple ways of self hosting. https://github.com/binwiederhier/ntfy/blob/main/server/server.go https://github.com/binwiederhier/ntfy/blob/main/server/serve...
EGreg 4y ago
Why not end to end encrypt notifications with a public key? Both iOS and Android can run a completionHandler to decrypt them using a private key that can be stolen if the app is disassembled. But you can generate a private key per user, after install, and each mailbox publisjes a public key. The thing I find ironic is that the actual encryption is done in JS, which is served by a webserver so anyway you have to trust the webserver. Same as you trust WhatsApp to not send your text to Facebook. Is there a way around this having to trust an app? Seems the only way to do that would be to have a browser extension or several, that you trust not to collude with a website.
- flir 4y ago
  Could the app not take a copy of the per-user private key when it's generated? (I know nothing about mobile security models).
  - djbusby 4y ago
    Or when you paste in a key to the app to use for decrypt. Not specific to mobile. Give an app data and it can do what it wants.
    - flir 4y ago
      I thought maybe mobile OSes might have a decryption sandbox, so apps could manipulate keys without having full access to them.
- Ajedi32 4y ago
  Ultimately there's no way around having the trust the client. The state of the art on that front right now is open source code with reproducible builds[1] and binary transparency[2]. Unfortunately none of that is currently implementable on the web for the reason you cited; the web server can just replace the entire application with any code it wants when you refresh the page. One possible path to fixing that is web packaging[3], but those standards are still in their infancy and don't yet have a mechanism for enforcing binary transparency. [1]: https://reproducible-builds.org/ https://reproducible-builds.org/ [2]: https://developers.google.com/android/binary_transparency https://developers.google.com/android/binary_transparency [3]: https://wicg.github.io/webpackage/draft-yasskin-wpack-use-cases.html#name-third-party-security-review https://wicg.github.io/webpackage/draft-yasskin-wpack-use-ca...
duxup 4y ago
Is that really much different than anything else other than an faq? No promises so they could be selling your info more than anyone else…
- binwiederhier 4y ago
  I am absolutely making promises. See the privacy policy: https://ntfy.sh/docs/privacy/ https://ntfy.sh/docs/privacy/ > I love free software, and I'm doing this because it's fun. I have no bad intentions, and I will never monetize or sell your information, and this service and software will always stay free and open. If you're still paranoid (which is your right), go host it yourself, or wait until I finished implementing E2E :-D
  - duxup 4y ago
    I don’t really know what anyone is doing. Im just wondering why anyone would feel better about an faq that really isn’t much different than anything else. The application, I’ve no idea/ don’t assume any malicious intent or actions.
- krono 4y ago
  You plucked the word "promises" out of the context it was written in.
  - duxup 4y ago
    I don’t understand what you mean.
    - krono 4y ago
      "No pinky promises in whitepaper format that leave out the most important bits" Difference here, is that the promises are verifiable and their concequences avoidable altogether (by self compiling and hosting). The developer also acknowledges the existing holes rather than misdirecting away from them. Edited my previous comment slightly as it was not at all my intention to accuse you of malicious intent. My apologies if it might have have come across that way.
deleted 4y ago
[deleted]

by krono 4y ago

krn 4y ago

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.

ilogik 4y ago
If you don't trust the person that wrote the software, it doesn't matter if it's E2E encrypted or not. There could be a back-door
- ilyt 4y ago
  which software ? You might have 3rd party client implementation that talks with another client and only server would be "unknown" party. E2E allows both clients to talk to eachother without server having a way to snoop on
- krn 4y ago
  E2E encryption happens on the client side, not on the server side. Therefore, no need to trust anybody, as long as the software is open-source.
  - hawski 4y ago
    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.
    - krn 4y ago
      That's exactly how Signal and Keybase work, and nobody has any problems with that.
      - hawski 4y ago
        I had exactly this in mind. Mostly if I wouldn't trust the author with binaries I wouldn't really trust with source code either.
      - hamburglar 4y ago
        That’s because most people hear “E2E” and think that somehow means they can automatically trust the client app. It’s a panacea.
  - kube-system 4y ago
    > 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.
    - krn 4y ago
      > You must trust that the contributors are trustworthy In theory, that's only the case if you are unable to review the code yourself. In practice, it's like saying that TLS encryption is pointless, because one needs to trust every single person who implements it.
- xyzzy4747 4y ago
  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.
  - megous 4y ago
    Doesn't work with simplex channels.
    - xyzzy4747 4y ago
      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.
binwiederhier 4y ago
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 https://github.com/binwiederhier/ntfy/issues/69
- deleted 4y ago
  [deleted]
horsawlarway 4y ago
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?
- krn 4y ago
  > 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.
  - seqastian 4y ago
    > I personally wouldn't even run a public service for others without E2E encryption. So don't? seems like everyone got what they wanted.
    - krn 4y ago
      Well, thinking logically: if everyone really got what they wanted, that question wouldn't be in the FAQ, would it?
krono 4y ago
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".
hdjjhhvvhga 4y ago
Encryption by default eliminates the biggest advantage: simplicity. But as an option, it's an useful addition that will be implemented sooner or later.
oliwarner 4y ago
Go figure out key exchange and use this as transport for encrypted messages. Encrypting stuff isn't hard.
- hamburglar 4y ago
  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?
hatware 4y ago
>Why couldn't the entire system be E2E encrypted by default, though? Probably because getting the system together in its current state was enough work. > In 2022, that's my standard expectation from any service. You have high standards. Do you expect others to raise their standards as high as yours...?
bccdee 4y ago
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.
- binwiederhier 4y ago
  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-1183839284 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.
googlryas 4y ago
The answer is simply because that is not how the dev implemented it. Why couldn't you write a patch to do that, and submit it? Or clone the code and release e2entfy.sh?

mathfailure 4y ago

I wish they also provided the code to run own server of ntfy, but instead it looks like they meant "write and run your own server".

sidpatil 4y ago
The server is open source. https://github.com/binwiederhier/ntfy https://github.com/binwiederhier/ntfy
vlugorilla 4y ago
https://ntfy.sh/docs/faq#can-i-self-host-it https://ntfy.sh/docs/faq#can-i-self-host-it The next topic on the FAQ. Also install instructions are provided.
sorieus 4y ago
Didn't look deep but looks like the sever code is provided + multiple ways of self hosting. https://github.com/binwiederhier/ntfy/blob/main/server/server.go https://github.com/binwiederhier/ntfy/blob/main/server/serve...

EGreg 4y ago

Why not end to end encrypt notifications with a public key? Both iOS and Android can run a completionHandler to decrypt them using a private key that can be stolen if the app is disassembled. But you can generate a private key per user, after install, and each mailbox publisjes a public key. The thing I find ironic is that the actual encryption is done in JS, which is served by a webserver so anyway you have to trust the webserver. Same as you trust WhatsApp to not send your text to Facebook. Is there a way around this having to trust an app? Seems the only way to do that would be to have a browser extension or several, that you trust not to collude with a website.

flir 4y ago
Could the app not take a copy of the per-user private key when it's generated? (I know nothing about mobile security models).
- djbusby 4y ago
  Or when you paste in a key to the app to use for decrypt. Not specific to mobile. Give an app data and it can do what it wants.
  - flir 4y ago
    I thought maybe mobile OSes might have a decryption sandbox, so apps could manipulate keys without having full access to them.
Ajedi32 4y ago
Ultimately there's no way around having the trust the client. The state of the art on that front right now is open source code with reproducible builds[1] and binary transparency[2]. Unfortunately none of that is currently implementable on the web for the reason you cited; the web server can just replace the entire application with any code it wants when you refresh the page. One possible path to fixing that is web packaging[3], but those standards are still in their infancy and don't yet have a mechanism for enforcing binary transparency. [1]: https://reproducible-builds.org/ https://reproducible-builds.org/ [2]: https://developers.google.com/android/binary_transparency https://developers.google.com/android/binary_transparency [3]: https://wicg.github.io/webpackage/draft-yasskin-wpack-use-cases.html#name-third-party-security-review https://wicg.github.io/webpackage/draft-yasskin-wpack-use-ca...

duxup 4y ago

Is that really much different than anything else other than an faq? No promises so they could be selling your info more than anyone else…

binwiederhier 4y ago
I am absolutely making promises. See the privacy policy: https://ntfy.sh/docs/privacy/ https://ntfy.sh/docs/privacy/ > I love free software, and I'm doing this because it's fun. I have no bad intentions, and I will never monetize or sell your information, and this service and software will always stay free and open. If you're still paranoid (which is your right), go host it yourself, or wait until I finished implementing E2E :-D
- duxup 4y ago
  I don’t really know what anyone is doing. Im just wondering why anyone would feel better about an faq that really isn’t much different than anything else. The application, I’ve no idea/ don’t assume any malicious intent or actions.
krono 4y ago
You plucked the word "promises" out of the context it was written in.
- duxup 4y ago
  I don’t understand what you mean.
  - krono 4y ago
    "No pinky promises in whitepaper format that leave out the most important bits" Difference here, is that the promises are verifiable and their concequences avoidable altogether (by self compiling and hosting). The developer also acknowledges the existing holes rather than misdirecting away from them. Edited my previous comment slightly as it was not at all my intention to accuse you of malicious intent. My apologies if it might have have come across that way.

deleted 4y ago

[deleted]