Hacker News new | past | comments | ask | show | jobs | submit login
Briar: Peer-to-Peer Encrypted Messaging (briarproject.org)
424 points by matthewmorgan 68 days ago | hide | past | favorite | 141 comments

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 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.

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 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?

You may like this app Meshenger (P2P Voice- and video phone App.) https://f-droid.org/packages/d.d.meshenger/

Sean Connery approves

"I'll take anal bum cover for $7000." -fake Sean Connery on SNL Jeopardy, selecting from the "An Album Cover" category

I'd like to hear more how you use forums/blogs for managing household projects.

> 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?

> 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.

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?

The page says that messages are also transported via wifi and Bluetooth. Presumably, the app can send messages locally when they are 100 feet away.

> we both have email hosting in Europe

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.

He probably uses protonmail

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.

Shared custody? I like being able to communicate, send/receive pictures/videos, do videocalls with my daughters when they are in their mother's place without having to ask her to share her phone for that.

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.

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.

Awesome idea.

You'd have no idea how many accounts they have, who they're talking to, and about what. Perfect privacy!

> 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 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.

>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, Pixel devices have some of the best support for flashing other OS's, modded ROMs, rooting, etc.

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.

>GrapheneOS, LineageOS, you have options on (some) Android handsets

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.

Apple absolutely is horrible for privacy. To insist otherwise suggests you might either be uninformed, willfully ignorant, falling victim to Apple's sham marketing around privacy, experiencing stockholm syndrome, or an apple employee.

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.

>To insist otherwise suggests you might either be uninformed, willfully ignorant, falling victim to Apple's sham marketing around privacy, experiencing stockholm syndrome, or an apple employee.

No, it means I'm optimizing for the average user who will not go out of their way to LARP a paranoid opsec level.

The average user's probably got their SSN, DoB, address, full name, employment history, credit card track 2's, passport details, and more spread across multiple breaches, being sold across multiple darkweb markets, precisely because they have zero regard for privacy.

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".

> available on iOS too

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.

Well, while not officially endorsed, there is `signald`. With mautrix-signal, I'm able to bridge my Signal and Matrix accounts. I can also make signald my primary device.



Amen to this. I bank with Starling and having decided to minimise my phone usage am having to move away from them. Likewise a variety of other services.

Honestly my banking situation + Signal is the biggest barriers to me switching. I pushed pretty hard to get friends and family to successfully switch off Messenger, LINE, and SMS for Signal (and now they're confused why the need a separate messaging app for SMS--thanks Moxie). I suppose I could write my own front-end wrapper around the bank, but they ain't paying me for that and would likely shut it down as insecure if they found out (even though there's no responsive design, they don't allow you to copy-paste or right-click, or use commas and other punctuation because the web system is built with TIS encoding I think, and they log you out with a meta refresh after 15 or 20 minutes of activity with no pop-up to save your work (in case you were trying to reformat another complaint message without puncuation in their messaging system), and I saw code checking for IE4 and Netscape Navigator 4).

comes* to phone useage

nicely said

"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."

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.

Yeah, Signal is definitely not a reliable messenger. I've also had messages arrive with hours of delay.

iMessage is way more reliable in my experience.

> 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.

Especially on Signal Desktop, its more reliable to close the app and reopen it than wait for it to reconnect to the server.

Meanwhile Element reconnects to Matrix super quick...

Element + Matrix. *chefs kiss*

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?

Here in Australia I can send a message from one phone in onee hand to the other phone in the other hand. Most of the time I can unlock the second phone and open signal before the message arrives. Fast enough for me but not instant.

Can you give more info on the data reporting options that we should be disabling?

Just wanna say this app saved my family and I when we went on a cruise. Normally, we would had had to pay to use the chat service via the ship's paid-only Wi-Fi (since we get no phone reception on the seas). Without needing to pay for the Wi-Fi, we were all able to use Briar to communicate whilst connected to the network, which made coordinating and finding each other on the ship way easier. It was great and worked really well. So thanks, Briar!

I was pleased to discover that if I was within hotspot range of the person I was trying to talk to (approximately WiFi range), I could connect directly to their device and send messages over that WiFi connection.

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.

I'm a bit torn about this. On one hand, it definitely makes coordinating things last minute easier on a cruise ship. On the other hand, to me being nearly forced to untether is most of the reason for going on a cruise, so still carrying my phone around with me even if only to message family is partially missing the point!

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.

Definitely depends on the size of your party. We were a group of five, split between three cabins on different floors of the ship. With how tremendously huge modern cruise liners are and how crowded cruises can be, I found it was invaluable. For example, being able to quickly message "I went back to the cabin" or "I'm on deck 6 at the table at the far back" or "meet you at the dining hall at 5pm" was very helpful.

Check out https://berty.tech for direct off network communications when you do not have internet.

The site has some hard dependency of AMP, takes a long time to load when ampproject.org is blocked and then renders broken.

It looks very cool regardless, thanks for mentioning it.

How does this work? Do the two devices still need to be on some sort of net work accessible to each other? Two cell phones not on the same Wi-Fi are going to have a hard time talking to each other buy anything other than Bluetooth, no?

It is Bluetooth (Low Energy), yep. https://berty.tech/features

It uses only BLE. What's the point when Briar is a better alternative?

I think it supports both. There’s options for off grid that includes Bluetooth and multipeer connectivity, and options for multicast dns and relay servers. As for the why: it supports Android and iOS so if you don’t have an Android device, Briar is basically out.

Does Briar work on iOS?

No, only Android and any Android-derivative that can run .apk files. For more convenient installation, it's available on Google Play and F-Droid.

Oh wow, I love this use case. I'd imagine it's also quite useful on a plane as well

Except I don't usually lose my family in the plane xD

I can see it being useful to type and chat between each other if we aren’t seated together on a plane.

We used it with my gf to make comments about other passengers quietly.

Sounds like a very important and constructive use-case :-)

Watching real life social and dysfunctional families interactions is much more entertaining than netflix or telenovelas imho. :)

I miss the days of mystery and adventure as a child, of being totally disconnected and unfindable, and lost without fear.

That's cool and and me too, but I don't see how that relates to my use-case. None of us were lost or in fear or un-findable without Briar, it just made the trip more convenient for coordinating time and place between multiple parties.

Because you aren't a child anymore or because you can't put your phone away?

I am in my late 50's and many women still call me a child (in a positive way), so I do not think that is my problem.

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.

Sorry, how exactly were messages being transmitted from phone to phone?

Were you connected to the Wi-Fi, with browsing blocked behind a paywall? And that was sufficient for Brair to find the other phones?

Sorry I may have communicated this poorly.

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!

To be fair, it would absolutely be possible to set up a hotspot where all the clients were jailed and invisible to each other, had IPs in different subnets, whatever.

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.

It’s not really more work; it’s just a matter of enabling the ‘client isolation’ setting on the wireless AP.

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.

Even that extremely minor step counts as “more work” for the clientele we’re talking about here.

I would certainly expect a cruise-ship-wide paid network to be managed professionally.

Realistically though, it's probably a multi-ship contract involving some small IT firm who installs everything, and then gives the onboard electrician/maintenance-guy a quick primer on how to do basic diagnosis of problems.

I'd bet that most of the configuration decisions are made based on how to minimize the likelihood of such problems ever occurring.

But you can't use Briar and the like with this Client Isolation, can you?

Isn't that their point? The only reason it worked on a cruise ship connected to the WiFi was because local devices could talk to eachother and were not isolated.


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)

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.)

They want to sign their software themselves that's ok. Everybody learned their lesson from the Signal vs Fdroid drama

F-Droid purposefully makes it convenient to use multiple repos. I have F-Droid, microG, and Briar enabled right now.

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


Last update a month ago.

I am waiting for Matrix's P2P support, once its out, its going to crush everything else.

Supposedly its should come out with the improved mobile apps too, which are sorely needed.

I am too, but the Matrix implementation feels quite complex with many moving parts, when apps like Briar, Berty, or keet.io [0] show up and look more straightforward to use. I don't know if that will be its downfall or ultimately actually make it more robust, but I'm rooting for it.

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/

Matrix is so buggy right now without p2p, so I doubt it... specially when it comes to decryption

Bugs in a frontend implementation ≠ bugs in the protocol

Is it close to being released? Or is that all theoretical?

TL;DR: "Not yet."

You can test it on their Element client's TestFlight beta: https://testflight.apple.com/join/Tgh2MEk6

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?

Tor hosts a directory service, a (de)centralized repository of rendezvous nodes from which the Onion Service (server) can be reached, thus the IP address is not lost, but since the circuit is rebuilt every 10 minutes or so, the connection will probably get cut every now and then.

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.

Thanks, this is basically combination of somewhat central servers plus nearly always online model. I need to think about it - on the first glance I am not 100% sure the role Tor plays in this model.

Is this described somewhere in more details? As I said, I clicked around but didn’t see any docs about this.

The directory services are the equivalent of DNS.

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

Separate topic so replying in a separate sub thread

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.

I understand, but the server (dns like) still knows everything which is not good imho

The directory service only receives an anonymous notification behind Tor proxyt chain that "hey, if someone asks for this .onion URL, point them to this node as it can provide further directions". It doesn't know "everything". The point of Tor has been from the beginning to compartmentalize what each node knows the the bare minimum.

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

And for mobile, network connectivity.

If contacts discovery is somehow solved, then I can see potential options of using short range comms (eg bluetooth) for connectivity. Basically all ideas I have are: 1) somewhat central server(s) 2) always on plus constant updates (what briar seems to be doing) 3) every node knows large part of topology (not very scalable)

I am wondering if I am missing something in briar’s architecture

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

It's a work in progress in terms of feature parity but there is: https://briarproject.org/download-briar-desktop/

nice, thanks!

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

Great to hear that they are working on this issue. Who will host the mailbox though?

you'll actually need to host it yourself. It's going to be a one-to-one relationship between mailboxes and briar users on purpose to avoid centralization of any kind (think techies hosting mailboxes for many friends etc.). To make hosting rather easy, the mailbox can be run on a spare (old) Android device, ideally plugged into a power outlet and connected to Wifi. Setup will include installing the app onto the Android and going through a pairing procedure by scanning a QR-code from the mailbox app from the briar settings screen.

There is a desktop client as well as an headless client that you can use to build bots.

The biggest privacy problem of Briar is it requires iOS or Android to use.

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.

There is a WIP desktop client which is targeting linux phones: https://code.briarproject.org/briar/briar-desktop#design-goa...

Briar is one of the most important secure messaging projects currently. Not only does it remove the need to trust the vendor about content (like with all E2EE messaging apps), you also get to keep the metadata about communication to yourself as data transits from one Tor Onion Service to another.

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.)

Why would you say that Bluetooth MAC Adress problem is a "small caveat"?

This sounds like a complete showstopper to me.

Note: on iOS's App Store searching for Briar shows Signal for me.


that's probably some "intelligent" thing by the App Store showing you similar applications to what you are looking for... unless Signal has "briar" as a keyword but I'd doubt

Same here.

Searching for Briar shows Signal. I can't find Briar on the iOS app store at all.

Since the protocol appears to use adhoc synchronization, the authors might be interested in https://github.com/sipa/minisketch/ which is a library that implements a data structure (pinsketch) that allows two parties to synchronize their sets of m b-bit elements which differ by c entries using only b*c bits. A naive protocol would use m*b bits instead, which is potentially much larger.

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.

Related: Are there any standards, APIs, best practices for p2p peer discovery?

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.

Pretty much any bittorrent library implements peer discovery through DHT (global database of who is interested in what hash), PEX (Peer exchange, ie if you and a peer are interested in the same content you can both exchanges other peers each side is connected to)

Check out libp2p, they're fairly mature and has discovery, relays, gossiping etc.

I think this is what Ethereum's gossip network uses.

Keet (still in Alpha) is also doing P2P encrypted messaging (and video calls).


Well... P2P isn't the best when it comes to messaging https://github.com/simplex-chat/simplex-chat/blob/stable/doc...

P2P is not an exact term.

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.

> The adversary has a limited ability to monitor short-range communication channels (Bluetooth, WiFi, etc).

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.

Cisco’s meraki has that built into their devices. I run meraki in my home and have it enabled and it’s pretty powerful. If you see a wifi network, it most certainly can track you and if it’s not a residential network, I assume it is.

This is why I don’t like the automatically re-enabling wifi setting on iOS.

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.

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.

What I find interesting is that such p2p comms applications return with a certain recurrence. I think one of the first was Nokia Sensor (2005?), and there was one that was famous during the Arab Spring/Hong Kong protests.

Most of the world uses Android, so I can understand the reason why it's an Android project. I just wish there was an iOS port too!

I want to like Brair, but I have yet to find any one who does use it. Which is a shame, really.

This is super cool! I’m assuming that there is nothing on iOS that’s comparable, which is a bummer.

Another mobile-only messaging app. If I wanted to use my phone, I'd just use SMS or RCS!

The desktop app is currently in development: https://briarproject.org/download-briar-desktop/

Interesting - the Java version runs on Windows[0][1]! I suppose I'll check it out, then.

[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)

[1]: https://cdn.upload.systems/uploads/RC0uthIY.png

Are you able to get messaging working on Windows? Their website says they only support linux currently.

Well, it's a Java app. It just works everywhere.

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.

Are there similar iOS Apps?

Useful in warzones I'd imagine

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.

Thanks. I meant more with respect to users spamming forums - to send a message to a particular forum do I just have to know of its existence? Or is it that each user only sees messages from its contacts on each forum?

A Briar user can either create a new forum, or get invited via a Briar contact that is already in an existing forum. There's some more info on this topic in Briar's user manual if you're interested: https://briarproject.org/manual/

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.

Why this, and not something with a proven record of stability like Tox?

Tox doesn't anonymize by default. You're leaking your IP address to every peer, and you're leaking metadata about to whom you communicate to every entity in the backbone.

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.

Is that sarcasm? Tox came out from 4chan and has a very questionable security record.

Briar, for when security and deliverability of your messages aren't really the point...

I understand why you don't think Briar has good deliverability.

But what makes you think that the security of Briar messages is suspect?

If he had an argument, he'd have presented it in his post.

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