Briar: Peer-to-Peer Encrypted Messaging
briarproject.org
briarproject.org
There are points of UX friction in the name of good opsec that are inconvenient but totally understandable given the project goals. The big ones being that you have to manually login after any reboots and notifications are intentionally sparse, so good luck using a smartwatch for reading or replying. Otherwise, the forums and blogs are great for managing household projects, IM is a dream, and as a bonus, anyone willing to install and use it probably has a large enough values overlap that we can use it as a social pre-filter for close friends.
The only other option that has come even remotely close to being as functional as Briar is DeltaChat. The only issue that stops us from using DeltaChat (or email in general) is that we both have email hosting in Europe while we live in the US, so neither of us, being frugal in principal, wants to send information to Europe and back in order to tell the person 100 ft away to come help bring in the groceries.
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 quality audio. As good or better than Facetime.
Also, unlike Briar, Signal is available for iOS, which is superior if you care about digital privacy, allowing users to disable a slew of data reporting (particularly location data) back to Apple that Android forces you to give Google.
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.
Meanwhile Element reconnects to Matrix super quick...
Have you had the checkmark be inaccurate?
Ah yes, the two operating systems: Android + iOS. You can't have an account without registering a primary device on one of those OSs. No KaiOS, no Linux phones, no desktop machines, no web-only options. I'm mad about these mobile-duopoly-app-first services because you can't participate in alternative lifestyles when it Cowes to phone usage.
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, Pixel devices have some of the best support for flashing other OS's, modded ROMs, rooting, etc.
These are not normal approaches used by the common person. Apple is not horrible for privacy, they simply help prevent certain types of surveillance capitalism.
Examples include: - Apple surreptitiously recording conversations without user consent (https://www.politico.eu/wp-content/uploads/2020/05/Public-St...) - Apple approving apps in the app store that have libraries ostensibly singly focused on the violation of privacy, complete with behavior that would be expected from those with suspicious or questionable motives, like uploading in the middle of the night (https://www.oregonlive.com/opinion/2019/05/its-3-am-do-you-k...) - Misleading users into thinking that their wifi and bluetooth may be disabled when they actually aren't - a UI control that merely disconnects the radios from APs / remote devices, rather than turning the radios off (https://www.theguardian.com/technology/2017/sep/21/ios-11-ap...) - iPhones send a ton of data (including call logs) to Apple servers, which participated in the illegal PRISM mass surveillance scandal, and conceivably report to similar secret programs that the public is not aware of to this day (https://theintercept.com/2016/11/17/iphones-secretly-send-ca...) - iMessage reports back to Apple every phone number you've ever entered into it, data that Apple probably shares with law enforcement (https://theintercept.com/2016/09/28/apple-logs-your-imessage...) - iCloud is enabled by default. All of your pictures, videos, documents, etc are NSA-accessible, but also rendered vulnerable to anyone with your credentials. This was the root cause of the celebrity nude photo leaks several years ago. - Mac computers had routinely sent files stored on encrypted disks to Apple servers without user permission ever being prompted for or granted (https://www.theguardian.com/technology/2014/nov/04/apple-dat...) - Here's a great analysis of all the snooping Apple did on Yosemite with all privacy features enabled (https://github.com/fix-macosx/yosemite-phone-home) - More various articles (https://arstechnica.com/gadgets/2014/05/new-guidelines-outli...), (https://www.theguardian.com/technology/2014/jul/23/iphone-ba...), (https://finance.yahoo.com/blogs/the-exchange/privacy-advocat...).
And these are just privacy concerns. This doesn't even begin to delve into the realms of DRM, downgrade prevention, planned obsolescence, dark patterns, censorship, or open collaboration with inhumane, authoritarian regimes.
No, it means I'm optimizing for the average user who will not go out of their way to LARP a paranoid opsec level.
Suggesting that usage of GrapheneOS is "LARP"ing a "paranoid" opsec level is dismissive of the very-real threats facing domestic abuse victims, whistleblowers, journalists & political activists/dissidents in repressive, authoritarian regimes, and countless others.
Just because you live in a safe, privacy-respecting, liberal democracy doesn't mean everyone else does, and it absolutely isn't reasonable justification to demean those who don't by painting them as irrationally paranoid. That's gaslighting real victims who actually have to be concerned about these companies handing out their data to countries that will put them through, in extreme cases, excruciating torture, before killing them or imprisoning them for life.
Not everyone is lucky enough to live your life, so stop assuming your threat model is automatically the "right" one for everyone else, and that any more intensive threat models than yours are inherently "irrational", "unrealistic", or "paranoid".
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.
Here in europe not so much. Most of the time it works somewhat instantly, but it too often happend, that a single message arrived a unknown time later.
It seems signal is optimizing for real time chat, so people do not notice, but sending a single message can be delayed. The thing is, it happened too many times already, that it arrived hours or days later, up to the point that I would not use Signal anymore for any important, time critical message.
iMessage is way more reliable in my experience.
The Briar page seems to suggest messages are routed through Tor:
> Briar uses the Tor network to prevent eavesdroppers from learning which users are talking to each other.
How different is that?
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.
I am actually travelling 10 thousands kilometers away from them for a month, having an instant messaging app is a saver for both me and my daughters.
We are currently using deltachat for this with email accounts I set up for them. They don't even have access to these accounts outside of deltachat yet and they can't be reached by others like they would with whatsapp.
You'd have no idea how many accounts they have, who they're talking to, and about what. Perfect privacy!
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 attacks, but lacks P2P Bluetooth support.
Worth noting that Briar’s Bluetooth support appears to forward data, but not in real-time, so it’s technically not a mesh network; though not sure what you would call what it supports, maybe an asynchronous network?
If this is for privacy reasons, I have to point it out that the GDPR protects the data of people that are physically in the EU. I'm not a lawyer, but I'm not sure this applies to non-EU citizens that just happen to deposit some of their data in the EU without being physically here. Maybe you should delve in this corner case deeper, or if you did, I'm curious to know the answer.
> we both have email hosting in Europe while we live in the US, so neither of us, being frugal in principal, wants to send information to Europe and back in order to tell the person 100 ft away to come help bring in the groceries.
I like the frugality in principle. However, AFAICT, Briar uses Tor onion services, Bluetooth or WiFi to communicate. Does using Tor onion services for out-the-home IM violate the principle?
It looks very cool regardless, thanks for mentioning it.
Were you connected to the Wi-Fi, with browsing blocked behind a paywall? And that was sufficient for Brair to find the other phones?
We were connected to the local area network, but we had no Internet access (which was behind a paywall). However, only being connected to the local network was sufficient for Briar -- no Internet needed!
Conventionally, I guess that sort of isolation doesn't typically happen as it's more work to set up and only really benefits users (privacy from each other), but maybe if more apps figure out how to take advantage of this things could change.
For example, see Cisco’s Meraki documentation: https://documentation.meraki.com/MR/Firewall_and_Traffic_Sha...
> With Client Isolation enabled, clients will only be able to communicate with the default gateway and will not be able to communicate with any other devices on the same VLAN (or broadcast domain). In order for the wireless client to communicate with another device, the upstream gateway must be used to enable this communication (e.g. inter-VLAN routing and ACLs). Any traffic bound for an address on the same VLAN as a device in client isolation will be denied. Traffic bound for other VLANs will be forwarded and routed normally.
I'd bet that most of the configuration decisions are made based on how to minimize the likelihood of such problems ever occurring.
It's great for things like concerts where service is spotty and you lose somebody, but know they probably aren't too awfully far away.
Maybe I'll feel different with kids on a cruise ship, but honestly I enjoyed the freedom of spending my day with nothing but a wristband for everything I wanted.
It is not about my phone use, but the expectation that I should always be findable since I have a cellphone. But I do admit to working at challenging my fear of living without a cellphone, but I am homeless so it is more difficult than when I had housing.
Fear is the hook I guess. It is ok to not know where your kids are or for them to miss dinner on a cruise ship.
Briar Project – Secure messaging, everywhere - https://news.ycombinator.com/item?id=33412171 - Oct 2022 (7 comments)
Briar has been removed from Google Play - https://news.ycombinator.com/item?id=30498924 - Feb 2022 (85 comments)
Briar Desktop for Linux - https://news.ycombinator.com/item?id=30023169 - Jan 2022 (84 comments)
Briar 1.4 – Offline sharing, message transfer via SD cards and USB sticks - https://news.ycombinator.com/item?id=29227754 - Nov 2021 (110 comments)
Secure Messaging, Anywhere - https://news.ycombinator.com/item?id=27649123 - June 2021 (63 comments)
Briar Project - https://news.ycombinator.com/item?id=24031885 - Aug 2020 (185 comments)
Briar and Bramble: A Vision for Decentralized Infrastructure - https://news.ycombinator.com/item?id=18027949 - Sept 2018 (11 comments)
Briar Project - https://news.ycombinator.com/item?id=17888920 - Aug 2018 (10 comments)
Briar: Peer-to-peer encrypted messaging and forums - https://news.ycombinator.com/item?id=16948438 - April 2018 (1 comment)
Darknet Messenger Briar Releases Beta, Passes Security Audit - https://news.ycombinator.com/item?id=14825019 - July 2017 (85 comments)
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.)
https://f-droid.org/en/packages/org.briarproject.briar.andro...
Last update a month ago.
Supposedly its should come out with the improved mobile apps too, which are sorely needed.
As convenient as it'd be for one implementation to crush everything else and become better because of it, I think different choices are good in terms of having alternatives and competing for features and niches.
[0]: https://keet.io/
I am wondering if I am missing something in briar’s architecture
I'm not sure if this really works, but if it's a short message and you periodically check the server if there's a reply and the service responds with short reply, the Tor cell padding (to 500 bytes IIRC) would make it harder to observe metadata about when communication takes place. This all of course goes out the window if it's a large packet that requires multiple cells, or if it's the client that just POSTs the outgoing messages to the server over an established connection.
Is this described somewhere in more details? As I said, I clicked around but didn’t see any docs about this.
The role of Tor is it facilitates anonymous, end-to-end encrypted connection between client and server, each messaging app is both a client (or a set of clients) and a server (a Tor Onion Service) that talk to each other through the Tor network. This way the traffic never exists the Tor network*.
Tor Project has an excellent new article about Onion Services at https://community.torproject.org/onion-services/overview/
The laptop/phone is the client, and Secure Drop is the server. With Briar the client-side Tor socket connects to the messaging app instead of browser, and on server side the socket again connects to the messaging app instead of web server. Whether messages flow from client to server (via POST request) or server to client (GET request) is doesn't really matter. The architecture where each user runs both server and client makes it effectively peer-to-peer.
Because messaging apps are these days expected to be always online, you pretty much need to have the server and client (and thus the app) always running.
---
*This is in contrast to Tor Messenger that, while it defaulted to Tor, used exit nodes unless the XMPP server was also a Tor Onion Service. While with Tor Messenger you were anonymous, XMPP server was usually not self-hosted thus a third party might have aggregated some metadata about when conversations between two accounts took place etc.
Things used to be even worse before Tor Messenger. With Pidgin it was possible to forget to configure Tor (unless you used XMPP Onion Service), and even worse, forget to enable OTR end-to-end encryption for every session, and if that happened the content could easily deanonymize you.
With Onion Service messaging, provided you verified the authenticity of the V3 onion address (or E2EE protocol's key fingerprint), you can be rest assured
1) connection is always E2EE
2) always inside Tor with no possibility to F up by connecting over 'clearnet'
3) no third party has access to communications metadata
The clients are not always on, iOS and Android don’t like background processes, connections go down, battery runs out, etc. I understand how to build always on clients but it’s not a practical solution.
* 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...
If you cannot control your endpoint, you cannot control your keys or your privacy.
Briar will become useful to me when it can run on open platforms like a Pinephone, Librem 5, Precursor, etc.
The downside is of course, you need to keep the endpoint powered on when you want to be reachable so it will increase the battery drain on your phone.
Note: There's also a desktop client if that's easier to keep online https://briarproject.org/download-briar-desktop/
One extremely important thing Briar is doing, is it's using the P2P as means to host alternative social interaction formats, like forums and blogs. Similar to Signal/WhatsApp stories (which is somewhat similar to microblogs/FB wall), it's a way to indirectly share information. You could pretty much emulate any social media platform on top of E2EE protocol with ~zero infrastructure cost and without having to worry about data mining. I'd argue what Briar's innovating on here is one of the most important aspects in what's left for secure messaging.
Finally a small caveat: Briar will share your Bluetooth MAC address with all peers so it can automatically use that when you're in close proximity with your peer. Thus sharing your Briar ID publicly is not a good idea for two reasons:
1) major global adversaries may have access to the leaking Bluetooth MAC (e.g. if Google aggregates it) which can deanonymize your account. This also allows slightly technical person to confirm identity of briar account if they suspect it's you (a bit wonky threat model but still).
2) it ties everything you do across your accounts on same device together, so there's strong linkability even if you rotate the identity key by reinstalling the app.
Briar is pretty clear about this in it's FAQ, but it's still not very well known although it definitely should be.
---
That being said, if you want similar Onion Service based communication with no such linkability, there's https://cwtch.im/ which is a fantastic project.
There's also https://www.ricochetrefresh.net/
Both are spiritual successors to John Brooks' `Ricochet` application which pioneered the whole Onion Service based instant messaging in 2014.
You can also chat and share files (among other things) with https://onionshare.org/
(And finally, you can get remote exfiltration security for keys/plaintexts with TFC https://github.com/maqp/tfc (my personal work), at the cost of losing some features like message forwarding etc that the architecture prevents you from doing.)
This sounds like a complete showstopper to me.
Searching for Briar shows Signal. I can't find Briar on the iOS app store at all.
I'd guess that under normal usage the message densities probably don't justify such efficient means-- we developed this library for use in bitcoin targeting rates on the order of a dozen new messages per second and where every participant has many peers with potentially differing sets--, but it's still probably worth being aware of. The pinsketch is always equal or more efficient than a naive approach, but may not be worth the complexity.
The somewhat better known IBLT data structure has constant overheads that make it less efficient than even naive synchronization until the set differences are fairly large (particular when the element hashes are small); so some applications that evaluated and eschewed IBLT might find pinsketch applicable.
I found this https://github.com/status-im/bigbrother-specs/blob/master/da... (mentions Gossip and Kademlia) but it is several years old and doesn't contain much info on peer discovery.
It is widely used to refer to direct communication between two nodes, via LAN, VPN, Bluetooth, etc., i.e. without any mesh routing involved.
From the looks of it Briar is that way + it can also route via Tor.
That seems like a pretty big assumption. From what i understand there already exists deployment of wifi hot spots to track people (both for advertising purposes and for spying purposes) to the extent that phone providers started radomizing MAC addresses.
Yes you can still turn it “really off” in settings (until the phone reboots again) and yes I put a shortcut on my home screen to turn wifi/bluetooth all the way off in one click, but probably barely anyone is doing those things because it’s inconvenient/they don’t know/they forget.
[0]: if you drop a dependency into the jar - https://github.com/JetBrains/skiko/releases/download/v0.7.40... (you want the DLL, the checksum, and the .dat)
I was able to create an account just fine, though I don't have any contacts to message. I don't have any reason to believe it wouldn't work fine, though.
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.
Briar also has the ability to introduce contacts to each other, so while it doesn't support totally public forums, you can spread information between contacts fairly effectively.
Also, feel free to participate in the social experiment of '4chan writes a secure messaging app with the CVE programming language', I know I never will.
But what makes you think that the security of Briar messages is suspect?