Hacker News Reader

Comment by rmbyrro | Hacker News Reader

> How are my calls with Brave Talk encrypted? (...) Assuming no malevolence, neither Brave nor its partner, 8x8, have this key by default.

I'm sorry, when did we start to take security measures assuming no malevolence?

View on HN

ProtonMail have been selling this for years. And not mentioning it much.

The fact of the matter is that first-party end-to-end encryption is pretty much broken by design, and very few people ever talk about this.

Couldn't this be solved by Diffie-Helman key exchange? [1]

[1] https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...

Using the Diffie-Helman would be good practice, but it's not enough to assume a defence against a malevolent actor who controls the client. It's not about the key exchange itself.

Essentially, a determined malevolent actor who controls the client could exfiltrate your keys easily. Maybe it's intentionally introducing a subtle vulnerability and then exploiting it server-side[0], or it's just simply doing a file upload of the keys. Basically, you can't be certain there isn't a backdoor from a malevolent actor.

[0] IIRC, there was some vulnerability in the Linux Kernel a few years ago that was basically there due to an errant space. Some people theorized that this could have actually been intentionally introduced by sophisticated actors, to hide in plain-sight open source code.

No. The problem with first-party end-to-end encryption is that the entity whose customer you are not just providing the pipe for unknown encrypted traffic, but are also providing the encryption software, and can therefore subvert the encryption software (in order to report the key, or other similar actions) if they decide to act maliciously, or are compelled to by any third party (most likely government). If the software is third-party, then the service provider cannot breach the encryption in any way, or provide any assistance in doing so: the third-party software provider will be the party to attack/require to insert a back door, which in this age will generally be a fair bit harder, though it’s far from inviolable.

I think that's just to cover their butts in case of hacking or state actor taking over their servers.

Given the company's colorful history of mishandling data and abusing user trust, it also seems like a general scapegoat CYA for their own use, too.

I wasn’t aware of this and thought Brave had a good record. Where can I learn more about their mishandling of data and abuse of user trust?

It's admittedly hard to find non-biased takes on their history because everyone seems to have a love/hate relationship with them, but here's a couple things off the top of my head that might give searchable terms:

* Inserting their own affiliate links into URLs you visit (now removed)

* Their implementation of Tor didn't actually work; leaked your browsing activity (now fixed)

* Received BAT donations on behalf of creators without notifying donators whether creators had opted-in to receive donations or not, and without notifying creators that they even had donations unless they reached a certain $ threshold (donations are now returned to users after a set time unless creators opt in to Brave's rewards platform)

* Similarly, they used to scrape site creators' socials (twitter, youtube, etc) to use their images/details in the donation CTA a la shadow profiles (now removed)

* They require Uphold to "cash out" earned BAT, which has a ton of their own controversies around freezing/deleting accounts when people try to withdraw a majority of their wallet (AFAIK still an issue)

There's plenty of others that inevitably get brought up in most threads about Brave. Most have been fixed after complaints/callouts, but employee reactions to getting called out are usually to the tune of "sorry you're surprised, but it's legal for us to do" instead of "we're sorry we did XYZ without telling you; we'll remove it".

I think perhaps they are insinuating that this is secure assuming Brave, 8x8, and/or your meeting participants are not compromised outside the scope of the application. Though I'd agree that phrase does a poor job of communicating that.

Reply on news.ycombinator.com