5 ms·

"Either way, the paper's story is "correct" -- but it causes a crapload of harm to the application developer, who only wanted to make a dollar by providing an e

by maqp 7y ago

"Either way, the paper's story is "correct" -- but it causes a crapload of harm to the application developer, who only wanted to make a dollar by providing an equal-and-opposite value, and never intended for these things to happen!" They themselves took the risk when creating an insecure product. There are two ways companies can botch up security. 1) Introduce a bug that can be exploited by intelligence agencies. These happen sometimes and they're just a fact of life. 2) Design a crappy protocol. If you want to lock yourself out from your users contact's you must by definition implement strong, authenticated end-to-end encryption, and open source client with reproducible builds. That's the only way. Once you've done that, any vulnerability will be a bug, and those are okay, they can be fixed when found. The problem here is ToTok developers didn't do that. They didn't even try. Now, as for metadata, VoIP capability makes Tor-routing by default impossible, thus we have need for two secure messaging apps on networked TCBs: Signal for E2EE VoIP, Briar for anonymous messaging. Networked TCBs can not be made unhackable, thus you can't expect privacy from remote endpoint compromise, but that's again, OK, because it scales less, and is a fundamental limitation. So no I do not agree with you because they could've done a LOT more but chose not to. So here's what we know: ToTok is not E2EE, thus we know for a fact their server has access to user data. The only way for NYT to independently verify the company is handing out data from the server, is to either obtain documents (which might never happen) or hack ToTok server to see such processes taking place. Which is illegal. So I agree I'd rather see some whistleblower reveal documents, but we can't hope for that to happen if Signal etc. are blocked in UAE. If this leads to unblocking of more secure messaging apps, perhaps we'll see the evidence you need one day.

peter_d_sherman 7y ago
Your claim that "They themselves took the risk when creating an insecure product" is based on the idea that you know how to create a secure product. Your idea that you know how to create a secure product is based on the use of E2EE being secure. E2EE's security is based on the use encryption and secret keys, which must remain secret. Well... if you read enough articles on HN, you'll see that there are a variety of ways that secret keys could potentially be compromised, for example, malware, spyware, what-have-you. Most of these attacks are out-of-band. That is, there is no way that an application developer could possibly be responsible for them, should they occur to their app... "They themselves took the risk when creating an insecure product" "So no I do not agree with you because they could've done a LOT more but chose not to." Yes, but the jury is still out on those... I have no arguments with you personally. My skepticism is directed solely towards the New York Times. All I know is that if I ever created an app and ran a company and acted with the best intentions for my users, I'd never want an article like this to appear about my app or my company in some foreign press... That is why I give ToTok the benefit of the doubt until stronger more compelling evidence (which includes intentionality) is revealed.
- maqp 7y ago
  I apologize for the delay, I don't come here all the time. "E2EE's security is based on the use encryption and secret keys, which must remain secret -- there are a variety of ways that secret keys could potentially be compromised," The argument can not be "anything can be compromised with sufficient resources, _therefore it does not matter if you don't follow best practices within limitations of the architecture_". "Most of these attacks are out-of-band." Agreed, but you also can't argue "the rest of the entire software stack isn't perfect, therefore I don't have to follow best practices". If E2EE fails because of vulnerability in OS, you aren't responsible. If it fails because of vulnerability in your app, then you are responsible. The same way, messaging app vendor is responsible for not using E2EE protocol which eliminates a huge gaping hole: e.g. the entire crypto community has criticized Telegram cloud chats that leave plaintext copies of messages on the server. Not knowing this is the same as not doing your job. It's also the case you can design your software around more secure architecture to protect against remote key exfiltration, see my work on TFC for example: https://github.com/maqp/tfc https://github.com/maqp/tfc "All I know is that if I ever created an app and ran a company and acted with the best intentions for my users" The question is, with E2EE becoming almost ubiquitous, would you really think not implementing modern encryption protocol is the same as acting with best intentions. "That is why I give ToTok the benefit of the doubt" I can see where you're coming from but having worked with secure messaging so long, to me it's the same as surgeon not verifying they were using industry standard materials for medical screws they use. Were they really acting in best interest of client? You can't excuse not verifying (industry best practice) just because you're "trying your best to minimize other complications". You're working with sensitive data. You have industry checklists available. If you choose the business, there will be obligations. You don't get benefit of the doubt as a participation award when it's effin obvious you did not use the checklist.

by maqp 7y ago

peter_d_sherman 7y ago

Your claim that "They themselves took the risk when creating an insecure product" is based on the idea that you know how to create a secure product. Your idea that you know how to create a secure product is based on the use of E2EE being secure. E2EE's security is based on the use encryption and secret keys, which must remain secret. Well... if you read enough articles on HN, you'll see that there are a variety of ways that secret keys could potentially be compromised, for example, malware, spyware, what-have-you. Most of these attacks are out-of-band. That is, there is no way that an application developer could possibly be responsible for them, should they occur to their app... "They themselves took the risk when creating an insecure product" "So no I do not agree with you because they could've done a LOT more but chose not to." Yes, but the jury is still out on those... I have no arguments with you personally. My skepticism is directed solely towards the New York Times. All I know is that if I ever created an app and ran a company and acted with the best intentions for my users, I'd never want an article like this to appear about my app or my company in some foreign press... That is why I give ToTok the benefit of the doubt until stronger more compelling evidence (which includes intentionality) is revealed.

maqp 7y ago
I apologize for the delay, I don't come here all the time. "E2EE's security is based on the use encryption and secret keys, which must remain secret -- there are a variety of ways that secret keys could potentially be compromised," The argument can not be "anything can be compromised with sufficient resources, _therefore it does not matter if you don't follow best practices within limitations of the architecture_". "Most of these attacks are out-of-band." Agreed, but you also can't argue "the rest of the entire software stack isn't perfect, therefore I don't have to follow best practices". If E2EE fails because of vulnerability in OS, you aren't responsible. If it fails because of vulnerability in your app, then you are responsible. The same way, messaging app vendor is responsible for not using E2EE protocol which eliminates a huge gaping hole: e.g. the entire crypto community has criticized Telegram cloud chats that leave plaintext copies of messages on the server. Not knowing this is the same as not doing your job. It's also the case you can design your software around more secure architecture to protect against remote key exfiltration, see my work on TFC for example: https://github.com/maqp/tfc https://github.com/maqp/tfc "All I know is that if I ever created an app and ran a company and acted with the best intentions for my users" The question is, with E2EE becoming almost ubiquitous, would you really think not implementing modern encryption protocol is the same as acting with best intentions. "That is why I give ToTok the benefit of the doubt" I can see where you're coming from but having worked with secure messaging so long, to me it's the same as surgeon not verifying they were using industry standard materials for medical screws they use. Were they really acting in best interest of client? You can't excuse not verifying (industry best practice) just because you're "trying your best to minimize other complications". You're working with sensitive data. You have industry checklists available. If you choose the business, there will be obligations. You don't get benefit of the doubt as a participation award when it's effin obvious you did not use the checklist.