Hacker News new | past | comments | ask | show | jobs | submit login

You cited this so I think this is what you mean:

"Signal is designed to never collect or store any sensitive information."

I interpret this, I think reasonably, to not include encrypted information. For that matter they collect (but probably don't store) encrypted messages. The question is, does PIN+SGX qualify as sufficiently encrypted? This line is a lie only if it does not.

Sorry I skimmed those articles, I don't want to read them in depth. But it sounds like they are again ultimately saying "PIN+SGX is not secure enough".




> I interpret this, I think reasonably, to not include encrypted information

I disagree since attacks and leaks can happen/have happened which could compromise that data. Signal was already found to be vulnerable to CacheOut. Even ignoring that guessing or brute forcing a pin is all anyone would need to get a list of everyone a signal user has been in contact with. just having that data (and worse keeping it forever) is a risk that absolutely should be disclosed.

> I don't want to read them in depth. But it sounds like they are again ultimately saying "PIN+SGX is not secure enough".

that was my conclusion back when all this started. The glaring lie and omissions in their privacy policy were just salt in the wound, but charitably, it might be a dead canary intended to help warn people away from the service. Similarly dropping the popular feature of allowing unsecured sms/mms and introducing a crypto wallet nobody asked for might have also been done to discourage the apps use.


Okay, so you not only take issue with PIN+SGX, you think that any encryption scheme (at least from Signal) isn't secure enough. Your point still comes down to "they are storing sensitive information in a form that is ostensibly encrypted but still subject to attack (in the opinion of XYZ reputable people...)".

My point is only that the headline of your point was "they are lying about not storing sensitive information". That leaves out a very important part of your point. IMO it makes the claim seem sensationalized and starts you off on the wrong foot.


That's fair, I can see how someone could feel that way.


"I interpret this, I think reasonably, to not include encrypted information"

Why? Encrypted information is still sensitive information.


Maybe via metadata? The size of the information, etc. Do you mean that they should have a caveat about that?

Or if you want to be literal, you have to say that they're storing sensitive information even if it's encrypted. But by connotation that phrase implies that someone other than the user could conceivably have access to it. So for all any user could care, they just as well are not storing it. Do you mean that they should rephrase it so it's literally correct?

Or do you mean that it's actually bad for them to be collecting safely encrypted sensitive data? Because if so, you literally cannot accept any encrypted messenger because 3rd parties will always have access to it.


Yes, I think they should rephrase it so that it's literally correct. Personally, I have a very high trust in the safety of Signal's encryption and security practices. But privacy policies aren't for the Signals of the world, they're for the ad networks and sketchy providers. For example, many ad networks collect "Safely Encrypted" email addresses—but still are able to use that information to connect your Google search result ad clicks with your buying decisions on Walmart.com. Whether something is "safely" encrypted is a complicated, contextual decision based on your threat model, the design of the secure system in question, key custody, and lots of other complicated factors that should each be disclosed and explained, so that third parties can assess a service's data security practices. Signal is a great example of a service that does an excellent job explaining and disclosing this information, but the fact that their privacy policy contradicts their public docs lessens the value of privacy policies.


Okay that's fair. But as I said to autoexec, if your point includes that you don't rely on the encryption to be safe, you should probably include that in your point. A lot of people probably don't share that as a prior. (I suspect that's why autoexec was downvoted and flagged).


A ciphertext is not sensitive information. If your ciphertext can't be exposed to an adversary, your cryptography is fundamentally broken.


You can't make that statement blindly without knowledge of the entire cryptosystem and threat model. For example, to me, an encrypted version of my email address, as used by many ad networks to do retargeting, is still sensitive information if it lets Walmart serve me ads based on my Google search history.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: