[mzajc]

I have given your service a try, and while the UX was impressive, I was bothered by an apparent lack of encryption. The landing page, the privacy policy, and your mission statement all make many mentions of encryption and security, yet (besides TLS) there doesn't seem to be any encryption going on as far as my browser is concerned.

I created a new folder, created a text file in the folder, and added some text to the file. The name of the folder, the text file, and the content itself were sent to the server unencrypted (besides TLS).

I'm sure your server encrypts the data immediately, but this adds unnecessary trust when client-side encryption could be employed. It also enables an attacker or a potential future operator to sniff the data before it is encrypted. That's no good!

[pino82]

That's a lot of trust for a project that is proud for having it tested with one browser, and wants to hear from you on Facebook or Discord. My trust in such a project would be quite minimal.

[owenfar]

It was tested and should work on all browsers (though the extension is only chromium based at the moment).

But for the sake of simplicity, we placed that badge since it's the most familiar icon to the wider audience. Initially most of our visitors thought it's an OS they have to download, this helped solve some of the doubts.

I had to create Facebook just for this, because whether we like it or not, it's a huge platform that shouldn't be missed.

[klaussilveira]

Curious: is WebCrypto compatibility better now?

[owenfar]

This is a really good point and I have thought about this multiple times along the way. Web Crypto API seemed ideal, but it brought its own complexities, especially if you want to have quick access on multiple browsers/devices.

It's true that as it is, it still requires trust. We do have our own custom servers, and we made sure that no logs related to personal data are ever stored, and encryption is done on the application level before it is sent on the DB server.

This is something I want to see implemented 100%

[ferbivore]

So what you've done is redefine "application" to mean half of your backend? Meaning your privacy page, which claims "we don't & cannot observe what you are doing", is outright lying? Meanwhile you're here commenting about how "the encryption & anonymity are rock solid" and nothing at all like the "encryption at rest" other services have. This is insanely sketchy.

[mzajc]

Personally, I feel like the bold statements about encryption should be removed until this is implemented to avoid misleading users.

Out of curiosity, is the data encrypted with a client-provided secret (eg. a password hash, or something that would otherwise be impossible to extract from the server), or is the secret stored on the server?

[owenfar]

I'm not sure I agree about it being a bold statement. Our description is very clear, and our approach is still much safer.

I see hundreds of products slapping "Encryption at rest" to make people believe their data is safe :) Yet, it's accessible by anyone that controls the server...

We also go further into details in the privacy page too.

The data cannot be decrypted without a client-provided secret. We'll make sure to be more transparent regarding all this.

[botanical76]

In my opinion it is misleading. Your "privacy by default" section has three headings which claim encryption, and while none of them are false, you can still just log everything your server receives. This is less private than What's App, and it's marketed as an Operating System -- for everything that you do. I think it's worth considering moving the encryption to be done client-side as long as there are no performance concerns.