I hope people find it interesting because for me it's yet another AI-powered note taking subscription that may or may not send all your data to random people all over the planet. At least you should make it E2E encrypted which would solve most privacy problems.
end-to-end (...) encryption add friction
How?
And we're building canoes over here, not storing nuclear codes.
I agree, but it is also very difficult to actually do. Either needs hosted or local LLM, right? how else can you process? I try to explain my views clearly on the landing page. And say to use apple, obsidian, or reflect where that is the priority. I find the utility of passing to LLMs worth it for what I'm taking notes on.
They have, by using one of the million other note taking apps.
I understand that on hn it's good karma to be a privacy-absolutist, but I think in the space of note taking apps, surely, there is enough product to let makers who are slightly more flexible cook?
That's only spiritually correct. You can guarantee full e2e encryption with webapps, the issue is with the potential to leak the key to the middleman, giving them the ability to decrypt it as well - but itd still be e2e encrypted.
It means you either need to persist the key to localStorage or a cookie. If you clear your browsing data or switch browsers, you can't just log in again, you have to use an existing device to share the key (e.g., with a qr code). That's the friction.
Now I could be way off here, but could you hash/salt the users password in 2 different ways:
- the first way would be used before sending the password to the server. This would then be hashed and salted again to be used for authentication with the server.
- the second way would be used locally. You could have the user create a pin to go with the password that would be used to create this hash. This hash would be the key to decrypt the contents. It would never be sent to the server.
I haven’t actually done the thinking or research to validate or invalidate something like this though. My uses of encryption have all been rather standardized.
It's not a password, it's an encryption key. You don't want to use a password because if you can derive a key from the password it means there's one key per password. You can salt them but then the server can crack your key because it's exactly the same complexity as cracking a password (since the server has the salt).
If you're doing e2ee, anyone you chat with needs to exchange key material with you (like diffie-hellman). Your private key decrypts messages sent to you, while the public key that you share encrypts messages that can be decrypted with your private key.
The process has little to do with authenticating with the server, it has everything to do with exchanging keys with the people you talk to. And you can't just trust the server to do it, since a malicious server could just send its own public keys to the chat participants and man-in-the-middle the conversation.
If you want to use Signal on your laptop instead of your phone, your private key needs to get to the laptop without going through the server. You could encrypt it, but then you need to encrypt it using a key derived from a password or PIN, and now you have the same problem as before.
PWA unlocked with a key is perfectly feasible. It keeps the key in memory and filters localstorage/network data with it. New instances require the key again. Have you ever used 1password or equivalents?
Comments
I hope people find it interesting because for me it's yet another AI-powered note taking subscription that may or may not send all your data to random people all over the planet. At least you should make it E2E encrypted which would solve most privacy problems.
How?
The good old "I have nothing to hide."
I agree, but it is also very difficult to actually do. Either needs hosted or local LLM, right? how else can you process? I try to explain my views clearly on the landing page. And say to use apple, obsidian, or reflect where that is the priority. I find the utility of passing to LLMs worth it for what I'm taking notes on.
Yes. Or at least the option to use/self host one is great. At the very least, ensure the user has the option to turn it off explicitly.
They have, by using one of the million other note taking apps.
I understand that on hn it's good karma to be a privacy-absolutist, but I think in the space of note taking apps, surely, there is enough product to let makers who are slightly more flexible cook?
As long it’s an web app it cannot reliably guarantee e2e anyway, so where is the point
That's only spiritually correct. You can guarantee full e2e encryption with webapps, the issue is with the potential to leak the key to the middleman, giving them the ability to decrypt it as well - but itd still be e2e encrypted.
It means you either need to persist the key to localStorage or a cookie. If you clear your browsing data or switch browsers, you can't just log in again, you have to use an existing device to share the key (e.g., with a qr code). That's the friction.
Now I could be way off here, but could you hash/salt the users password in 2 different ways:
- the first way would be used before sending the password to the server. This would then be hashed and salted again to be used for authentication with the server. - the second way would be used locally. You could have the user create a pin to go with the password that would be used to create this hash. This hash would be the key to decrypt the contents. It would never be sent to the server.
I haven’t actually done the thinking or research to validate or invalidate something like this though. My uses of encryption have all been rather standardized.
It's not a password, it's an encryption key. You don't want to use a password because if you can derive a key from the password it means there's one key per password. You can salt them but then the server can crack your key because it's exactly the same complexity as cracking a password (since the server has the salt).
If you're doing e2ee, anyone you chat with needs to exchange key material with you (like diffie-hellman). Your private key decrypts messages sent to you, while the public key that you share encrypts messages that can be decrypted with your private key.
The process has little to do with authenticating with the server, it has everything to do with exchanging keys with the people you talk to. And you can't just trust the server to do it, since a malicious server could just send its own public keys to the chat participants and man-in-the-middle the conversation.
If you want to use Signal on your laptop instead of your phone, your private key needs to get to the laptop without going through the server. You could encrypt it, but then you need to encrypt it using a key derived from a password or PIN, and now you have the same problem as before.
PWA unlocked with a key is perfectly feasible. It keeps the key in memory and filters localstorage/network data with it. New instances require the key again. Have you ever used 1password or equivalents?