Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Briar: Peer-to-Peer Encrypted Messaging

briarproject.org

Post reply on HN
Print view View original

101–110 of 145 posts

Re: Briar: Peer-to-Peer Encrypted Messaging

#101

Post by dfc »

Semaphor wrote: post #42
KennyBlanken wrote: post #37

Earlier quoted context omitted.

> It's actually instant messaging without any client hiccups or latency (looking at you, Signal). This is almost certainly poor wifi / cell coverage, not Signal having "hiccups" or "latency." I routinely have real-time texting conversations with friends and I can see the messages are "seen" almost instantaneously, half-way across the US. I've also never had an issue with voice chat. It's been flawless, and very high…

> This is almost certainly poor wifi / cell coverage, not Signal having "hiccups" or "latency." Signal is very finicky about that, though. I have friends who prefer Whatsapp simply because they don’t have to worry about connection stability. With Signal, you sometimes don’t even know if messages actually arrived or not.

I have never had the message delivery status icon be different than reality. Sometimes, rarely, things don't show as delivered for some time. But I have never had anyone tell me the message was delivered when the checkmark said otherwise.

Have you had the checkmark be inaccurate?

Re: Briar: Peer-to-Peer Encrypted Messaging

#102

Post by MayeulC »

lsh123 wrote: post #4

Building a completely p2p (no servers) e2ee messaging app is not hard except one big problem: contacts discovery. I looked through briar website and it seems the solution is to constantly ping all contacts and hope that everyone is online plus at least one of IPs stays the same between pings. Did I miss something more interesting?

It's not hard for IRC-style chats, but it gets harder if you want to handle:

* Asynchronous messaging: what if the two devices are not online at the same time, or on disjointed networks? Store the message on a server somewhere? Secure Scuttlebutt[1] relies on devices pulling encrypted data that does not belong to them.

* NAT or firewall hole-punching, though it can be remediated by leveraging other nodes. Some implementations use a DHT[2], but you're often relying on other servers of some sort.

* What you call contact discovery is also typically handled through a DHT of some kind. Yggdrasil-like (or hyperboria, cjdns, .onion) overlay networks are usually able to route to a public key, regardless of how it moves around on the network.

* Push notifications. Either you accept the use of an external server (like the Tox client TRIfA, which has an add-on[3] that also supports UnifiedPush), or you have to rely on a separate persistent connection that will drain your battery faster, especially if there's some computation involved.

The last point is why I uninstalled Briar: I had almost no contacts, and didn't want an extra battery-draining service.

[1] https://scuttlebutt.nz/docs/introduction/detailed-start/#mor...

[2] https://blog.ipfs.tech/2022-01-20-libp2p-hole-punching/

[3] https://github.com/zoff99/tox_push_msg_app

Re: Briar: Peer-to-Peer Encrypted Messaging

#103

Post by upofadown »

You can verify identities in person by scanning a QR code. That's completely solid. Otherwise you can send someone a link. It should be made clearer in the documentation that that link might end up with someone other than who you expect and the potential downside of that.

Re: Briar: Peer-to-Peer Encrypted Messaging

#104

Post by giphyman »

anonymousDan wrote: post #80

How does it handle spam?

Briar uses a rendevouz system for adding contacts over the internet: https://code.briarproject.org/briar/briar-spec/blob/master/p...

And a 2-party QR code protocol for adding contacts in person: https://code.briarproject.org/briar/briar-spec/blob/master/p...

In short, both these methods of adding contacts require both parties to actively add each other in the same time period. So even if you post your briar contact code publicly, only the contacts you are adding as well will be able to connect with you.

Re: Briar: Peer-to-Peer Encrypted Messaging

#106

Post by kybernetikos »

andai wrote: post #95
kybernetikos wrote: post #79

Earlier quoted context omitted.

Seems like Briar might be good for messaging to young kids. I could give them an old phone without a sim card, and run Briar on it.

What is your motivation for the "without a sim card" part? If the phone is connected to Wifi then they're either at home or at school--isn't the point being able to reach them no matter where they are? I'm not too keen on my kids being on the internet all day. In my case the opposite solution seems better, a dumbphone so I can reach them, but TikTok can't.

They're mainly not online, and not signed up to online services, but it'd still be nice to be able to message the rest of the family, listen to music, share photos, etc.

Re: Briar: Peer-to-Peer Encrypted Messaging

#107

Post by class4behavior »

anon400232 wrote: post #92
anonym29 wrote: post #52

Earlier quoted context omitted.

>iOS, which is superior for digital privacy False dichotomy. GrapheneOS, LineageOS, you have options on (some) Android handsets. You have no options on iOS. Further, much of Apple's walled-garden ecosystem is closed source. Apple is HORRIBLE for user privacy, only marginally less horrible than Google. The difference is that Google isn't a tyrant who insists on making devices that MUST run their own OS. Ironically, Pi…

Privacy is not a one dimensional thing. Just like security, it exists in context, relative to a threat model. Think about the threat model for an "everyday" person. It is different than an American journalist contacting sources in the United States, which is different than a journalist in Russia or China.

That only supports the above statement. Apple is particularly bad for everyday privacy at population scale.

Re: Briar: Peer-to-Peer Encrypted Messaging

#108

Post by giphyman »

anigbrowl wrote: post #50
Ptchd wrote: post #5

Briar is nice, too bad they don't have a Linux app (only an Android app)... Also, it chews through battery in no time.

The battery is a bigger problem. You can work around OS issues but if yourun out of battery at the same time you are cut off from normal communications you now have two major problems, and your expedited/unexpected disappearance from the conversation creates unnecessary anxiety for others. I hope they make fixing this a priority, it's a serious shortcoming.

They are working on a mailbox app to offload the constant background tor processes which use a lot of the battery life: https://code.briarproject.org/briar/briar-mailbox

Re: Briar: Peer-to-Peer Encrypted Messaging

#109

Post by orblivion »

neilv wrote: post #27

Briar's "F-Droid" installation option wants you to add a new package distribution repo to the F-Droid app. Rather than the usual way, which is to have F-Droid verify the source build of each version, and distribute through the official F-Droid repo. (And normally that "Get it on F-Droid" button links to F-Droid's page for the app, rather than to another page of the project.)

It's still in the normal F-Droid repository:

https://f-droid.org/en/packages/org.briarproject.briar.andro...

Last update a month ago.

Re: Briar: Peer-to-Peer Encrypted Messaging

#110

Post by [deleted] »

O__________O wrote: post #93
californiadreem wrote: post #18

My wife and I use Briar for household communication because of subsidiarity rather than any direct privacy concerns. Out of all the messenger projects that we've tried, Briar actually works for local communication. It's actually instant messaging without any client hiccups or latency (looking at you, Signal). We've tried a ton of other options, but we keep ending up back at Briar. There are points of UX friction in t…

If an adversary is within bluetooth range of a Briar user what if any data or meta data they are able to gain? For example, say there is a protest and law enforcement is running devices to capture the Briar data and meta data, what would they be able to record and would it be possible to playback (decrypt) the data at a later point if they were able to capture keys; my understanding is Signal counters playback attack…

[deleted]
Post reply on HN