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?
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
(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.)
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
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.
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)
> 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.
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.
[+] [-] californiadreem|3 years ago|reply
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.
[+] [-] O__________O|3 years ago|reply
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?
[+] [-] rand0mx1|3 years ago|reply
[+] [-] ziggypieman|3 years ago|reply
> 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?
[+] [-] thaumasiotes|3 years ago|reply
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?
[+] [-] GTP|3 years ago|reply
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.
[+] [-] kybernetikos|3 years ago|reply
[+] [-] KennyBlanken|3 years ago|reply
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.
[+] [-] kevinfiol|3 years ago|reply
[+] [-] smeej|3 years ago|reply
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.
[+] [-] vel0city|3 years ago|reply
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.
[+] [-] zikduruqe|3 years ago|reply
[+] [-] jabedude|3 years ago|reply
[+] [-] FollowingTheDao|3 years ago|reply
[+] [-] abdullahkhalids|3 years ago|reply
Were you connected to the Wi-Fi, with browsing blocked behind a paywall? And that was sufficient for Brair to find the other phones?
[+] [-] dang|3 years ago|reply
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)
[+] [-] neilv|3 years ago|reply
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.)
[+] [-] jacooper|3 years ago|reply
Supposedly its should come out with the improved mobile apps too, which are sorely needed.
[+] [-] avnigo|3 years ago|reply
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/
[+] [-] Ptchd|3 years ago|reply
[+] [-] palata|3 years ago|reply
[+] [-] lsh123|3 years ago|reply
[+] [-] maqp|3 years ago|reply
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.
[+] [-] MayeulC|3 years ago|reply
* 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
[+] [-] Ptchd|3 years ago|reply
[+] [-] maqp|3 years ago|reply
[+] [-] anigbrowl|3 years ago|reply
[+] [-] prmoustache|3 years ago|reply
[+] [-] lrvick|3 years ago|reply
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.
[+] [-] giphyman|3 years ago|reply
[+] [-] maqp|3 years ago|reply
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.)
[+] [-] martin82|3 years ago|reply
This sounds like a complete showstopper to me.
[+] [-] dijit|3 years ago|reply
https://i.imgur.com/5YiR1Xk.jpg
[+] [-] ale42|3 years ago|reply
[+] [-] Teckla|3 years ago|reply
Searching for Briar shows Signal. I can't find Briar on the iOS app store at all.
[+] [-] nullc|3 years ago|reply
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.
[+] [-] ofrzeta|3 years ago|reply
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.
[+] [-] rakoo|3 years ago|reply
[+] [-] klabb3|3 years ago|reply
[+] [-] oska|3 years ago|reply
https://keet.io/
[+] [-] ementally|3 years ago|reply
[+] [-] huhtenberg|3 years ago|reply
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.
[+] [-] maqp|3 years ago|reply
[+] [-] bawolff|3 years ago|reply
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.
[+] [-] snoopy_telex|3 years ago|reply
[+] [-] upofadown|3 years ago|reply
[+] [-] puntofisso|3 years ago|reply
[+] [-] exabrial|3 years ago|reply
[+] [-] LibertyBeta|3 years ago|reply
[+] [-] braingenious|3 years ago|reply