Bridgefy, the messenger promoted for mass protests, is a privacy disaster
arstechnica.com
arstechnica.com
Cwtch.im (pronounced couch) is an app I'm looking closely at but doesn't seem to have much movement in terms of shipping new releases or getting it going in apks or Fdroid. But I keep any eye there too.
You can forget about this one. With a name like that, it isn't going anywhere.
I mean I see the advantages of p2p for a more resilient network. Which is great when the internet is shut down but I also hope there will be some way to protect the people's identities.
* deanonymizing users
* building social graphs of users’ interactions, both in real time and after the fact
* decrypting and reading direct messages
* impersonating users to anyone else on the network
* completely shutting down the network
* performing active man-in-the-middle attacks, which allow an adversary not only to read messages, but to tamper with them as well
This app basically allows for the exact opposite of what people are expecting from the app. Doesn't that qualify as some sort of fraud or false advertising? If not, I wonder if we need further regulation to protect the public from developers that are either incompetent or straight malicious.
Most of us have never directly paid Google for anything. I think we would still have justification in being upset if there was a central Google flaw that allowed users to view our search or Gmail histories.
-- There were general flaws w/ Google & gMail to allow governments to snoop in on unencrypted communication. There probably still is.
Fraud typically requires some sort of mens rea. It sounds to me like Bridgefy is just really bad as making secure applications.
> If not, I wonder if we need further regulation to protect the public from developers that are either incompetent or straight malicious.
There is a long history of people trying to create liability for software bugs. It was a bad idea then and it's still a bad idea today.
If a bridge is built wrong and kills people when it collapses, someone must be at fault.
What’s the difference if it happens with a virtual “thing”?
Certification. Engineering is a protected profession, which means there are preconditions to working in that field and real consequences for failure. Software "engineering" has none of the preconditions.
1. "It is a bad idea to make software developers liable for bugs".
2. "Why? We make engineers liable for physical malfunctions, why not make software engineers liable for software malfunctions?"
3. "Because they are uncertified"
It fails to address the actual point. Is it better that software developers are uncertified? Why not introduce standards?
I guess it's easier to transport software, even running software, across borders today. But even there, one could say, "If Google relocates to Canada, then stuff them - we will drop their packets at the border till they comply with domestic law."
This would be a disruption of the free market, but we already admit that a free market shouldn't exist in house construction. Why should a free market exist in message distribution? The question is always, why is software on this side of the border, and bridges on that side?
(My guess is that it's because few people die when your email is mishandled, but many people could die if bridges fell out of the sky whenever they got bored.)
If a software issue causes for example a data breach, it could cause lots of people to experience mild annoyances, like time wasted on changing passwords, money lost through more effective scamming attempts, etc..
If we compare an actual life lost in an accident with lots of people losing some hours/days from their lives, when can we say they are an equal loss?
1 people = 100 people losing 1 year?
How about if the person is your family member?
This gets waaay too complicated to resolve rationally..
Some times, yes, other times, no. Yet, it's not fraud, when someone is at fault, it's for other issues.
> If a bridge is built wrong and kills people when it collapses, someone must be at fault.
1. We mostly know how to build bridges that don't collapse. We do not know how to create software that doesn't contain bugs. Even with the most intense scrutiny.
2. Software exists along a gradient between casual to critical, whereas all structural/civil engineering is of critical importance. It simply makes no sense for society to force you to analyze your Excel formulas as intensely as a civil engineer analyzes a bridge.
We're acutely aware of this conversation, and know that we must prioritize the safety of our user base. All of the issues reported on the article are already being fixed, and we should have updates published in the next few weeks.
Here's our blog post: https://bridgefy.me/bridgefys-commitment-to-privacy-and-secu...
As always, we're available to keep the conversation going; please refer to the email address included in the blog post.
Thanks!
Identity is critical in encrypted messaging. Identity is a hard problem in practice. Very few things do an adequate job. The things that do are awkward and require concepts that few people understand.
For personal identity the most plausible outside authority is government, and it's unlikely that people protesting a government would trust it to identify them - after all government counter-protest forces would presumably be able to make use of that against them.
So you're probably screwed in the larger sense. Is this tip that "There is a team with food and water on the North side of the bridge" from "Kirsty" real? Well you haven't the faintest idea who "Kirsty" is so even if you could magically be entirely confident the message is really from "Kirsty" that doesn't help you decide.
Signal does the absolute most it's practical to attempt here, you can choose to check that your friend Kirsty is actually your friend Kirsty by some trustworthy means (e.g. meeting up physically) and then Signal promises you'll know that future messages are really from Kirsty. But trust isn't transitive so PGP's apparently more powerful offering doesn't actually do anything except maybe give you a false sense of security.
Bridgefy doesn't offer even that very limited capability from Signal, but I'm dubious about the practical import for a live protest. I can buy that BLM or Extinction Rebellion which are long-term organisations with sustained buy-in from local organisers benefit from something like that (and indeed ER uses Signal) but individual protests or protesters I don't think so.
Trust in the abstract isn't inherently transitive, agreed. I'd argue that employing PGP as though it were is misusing the tool (that might well be easier to do than it ought to be, but that's a different conversation).
WoT as realized by PGP seems to me to be a very good tool for manually assessing whether to trust a previously unknown key for someone that a third (untrusted) party sends you.
I remain highly optimistic that some future take on the WoT concept will be advanced enough to tackle trust in general in a distributed manner.
The issues it describes only affect keyservers that behave in a specific manner. I'd also argue that a keyserver behaving that way in the first place is fundamentally flawed for the reason pointed out by @tialaramex above - trust isn't transitive in the generalized case (nor is it boolean IMO).
It is still entirely possible for a small group (say a FOSS software project) to engage in cross signing. Previously unseen keys received from an untrusted (or less trusted) third party can then be judged on a case by case basis by manually assessing how many times they have been signed and by which keys.
(Similar to above, I believe Matrix employs cross signing among the keys of a single user.)
Leaving off the question of how useful the transitive stuff is, PGP has a reasonable and simple framework. The terminology of key trust is terrible though. Few people know what it means to trust a key (my house key is OK but I think my shed key might be up to no good).
Messaging identity reputation is all about what you think of the other people's identities. Do you know them? What context do you know them from (e.g. a particular protest)? Why you think this messaging identity relates to a person somehow? How is this entity allowed to interact with you? This stuff can't be automated away.
I think the ultimate answer would have to involve generating a simple conceptual model of a messaging identity and then teaching people about it. If you solve identity then everything else is easy.
It's afaik android-only, and doesn't use nodes as relays for private messages.
That seems like a relatively easy corner to deal with. What I really want to see is one with meshing, public chats, and open joining (of the public chats, verifying contact names can be done offline). That’s where it starts to be actually useful in protest etc situations where public internet access might not be available.
Forums allow any member to invite anyone in their contact list.
Group chats have an admin who can invite anyone in their contact list, and also forcibly kick members out of the group.
Forums show a HN-like threaded view, and afaik group chats show a linear history.
Group/Forum message sharing is done between peered contacts whenever they get connected (either locally by being in the same WLAN/in blutooth range, or remove via a tor hidden service).
It currently lacks the requested open joining, though this can be emulated by using a "Forum" and the spam issue there could be handled by adding UI to see who gossip'd you a certain message (which you deem to be spam), so that you can have a word with this contact. Temporarily stopping incoming gossiping from a peer for specific forums might also be needed to scale to "huge" forums without having a massive spam problem, as you don't (necessarily) want to remove them from your contact list without giving them a chance to block the source of spam they had, as they'd perceive your removal of them from your list as you never going online again.
Joining is very simple, so you could probably just approach a few people at the protest about whether they have Briar, and if so, whether they'd pair with you to share the current protests forum.
It also has a "blog" functionality where there's a history of your "current status", and you could, if you wanted to, tell your peers about going to a new protest or so and that they should both ask you for a forum invite for the protest, and send you an invite if they get into a forum for this protest.
It shouldn't require many links to get reasonable message relaying across a relatively dense protest, especially considering that sneakernet aspects are essentially automatic.
I think with some more manpower they could quite soon have a system that's highly resilient to spam (provenance visualization/blocking), blackout-capable, and privacy-preserving/secure for non-public groups/forums.
It does seem like a nice feature for existing platforms to be able to enable in disasters and at events.
As for protests, maybe some communication is better than none if the government is shutting things down?
In the US, legal radio usage would be easier to eavesdrop on (I believe encryption is effectively banned). But if you're willing to ignore that detail then it won't be easy to eavesdrop on you.
It would be trivial for a state funded adversary to triangulate broadcasters though.
Radio has different characteristics that make it an imperfect substitute in protests. The biggest one is that people already have cell phones, but pre-event coordination also becomes much more important, and people have to practice. (Not much, but radio discipline is a thing, and in an emergency you need it.)
Bluetooth/Mesh based local broadcast apps such as FireChat and Bridgfy are literally extreme low signal to noise streams of thoughts coming from everyone around you. We don't even need to get to the privacy or security part to eliminate it due to it being completely unusable in areas with more than a couple people.
Signal:
Slow, requires phone number to register and access to contacts. Users still receive messages after leaving a group, and the history still remain on the desktop app. Disappearing messages disappeared on the phone you'll still get it after it purported it have disappeared.
Wire:
Extremely slow.
Why is Telegram good?
* Super fast
* Good balance of security and usability.
* Early flaws in mtproto has largely been fixed.
* You can choose a username, instead of a phone number
* Good privacy settings to select who can find you, how to find you, who can call you, who can pull you into group chats etc.
* Desktop app has feature parity with the mobile apps. No glaring flaws found in Signal.
* Operationally extremely battle tested by successful protests around the world such as Hong Kong, Iran and Belarus.
* Any problems found on the ground, when reported, will be fixed in a matter of days to weeks by Telegram. They are that responsive.
Words of advise to Silicon Valley companies and security professionals in general. Stop bashing Telegram and actually go and try using your proposed alternatives in protests. Most if not all of these so-called secure chats are completely unusable for any organizations trying to avoid being arrested or be used as evidence against you.
Unless this has changed recently -- and I can't find any indication that it has -- this is not true. You can choose a username in addition to a phone number, but you must have a phone number. Your username is effectively an alias for your number; your account is tied to the number, not the username.
This cannot be stressed enough. One can do their imaginary layman revolutions and or secret operation in these chats, citing theoretical security features, etc. But when it comes to the real world, they simply do not work, in the same way your todolist mvc example doesn't work for project management and accounting.