I have noticed that since the protests began there has been a huge influx of my contacts onto Signal and I've gotten a few questions about how to use PGP. I'm glad folks are starting to take privacy in their messengers more seriously, but a lot of the privacy-focused messengers are pretty bad (with Bridgefy being a particularly egregious case). Unfortunately there seems to be a trade off continuum between user friendliness and privacy in all currently available offerings and for most people I think Signal hits the sweet spot. I'd be interested to hear what other tools people would recommend here, as I haven't used all of them (eg Telegram/Matrix).
My money is on p2p matrix. It doesn't solve the immediate case Bridgefy does yet (I think it expects to have an internet connection), but it does solve the 'we have to trust central services like signal and or have incredibly difficult ux' scenario somewhat. Metadata resistant to a point etc.
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.
I can't wait to see more progress with p2p matrix. I hope there will be one flavor that will allow privacy/anonymity.
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.
We're working on a PGP app called Safe Easy Privacy on iOS. Our idea is that if PGP was easier to use more would use it for private communications, we're still in the early stages and we know that PGP isn't the perfect solution, but it's better than nothing. We've noticed people saying they're using Safe to share keys with people who aren't tech savvy.
Signal's disappearing messages will appear on your other devices such as the desktop app long after disappearing on the phone, and you still get group message asking if you'd like to join back the group you just left. Imagine these messages popping up right at the moment during police interrogation.
The proposed change to use the signal protocol wouldn't seem to address all the metadata issues with their core tech. Their statement mentioned nothing more than "oops we're a startup", the signal change, and an intention to continue to invest in the "mesh".
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?
* 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.
Do you think a company has zero obligations to its users if those users are not paying for the service?
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.
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.
You're explaining why there _is_ a difference, but not why their _should be_ a difference.
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.)
So it seems like it ends up being a moral dilemma:
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..
> 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.
Jamming is a big step I don't think we've seen in the US so far and I'm not sure the police have that tech readily at hand. Inherently though you're going to want to be able to include people into the network easily which already opens you up to eavesdropping of the public channels. For purely public broadcasts radio is nice because anyone can listen and it doesn't reveal location in the network.
Probably harder to disrupt (cell networks, WiFi, and Bluetooth are all specialized, relatively low power radios after all).
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.
People do. More than a few hams have been involved in the recent US protests.
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.)
Does anyone have a design that works for this kind of adhoc meshing network with good privacy guarantees? It seems like a really hard problem to solve, especially the social graph problem because inherently messages will take time to propagate through the network based on proximity. Maybe adding random wait and hop count increments? Efficient routing kind of depends on being able to discover the network graph.
Briar works quite well, but due to the darknet nature you only exchange data with those you paired with (by exchanging a "link" via some other channel or meeting in-person and scanning a QR code on each other's device (then followed by a short wireless p2p exchange to properly exchange all required information)).
It's afaik android-only, and doesn't use nodes as relays for private messages.
That sounds like it only solves the very narrow issue of private messages and only while the two users are within direct communication right?
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.
It also supports two kinds of group chats and contact introductions.
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.
>A key shortcoming that makes many of these attacks possible is that Bridgefy offers no means of cryptographic authentication, which one person uses to prove she’s who she claims to be.
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.
Somebody needs to expend a bunch of effort to provide identity. It doesn't have to be you (in a PKI the effort is expended by the Certificate Authorities and those overseeing them, not by Relying Parties) but it does have to be somebody you trust.
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.
> But trust isn't transitive so PGP's apparently more powerful offering doesn't actually do anything ...
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.
> 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.
That article isn't particularly relevant to what I said.
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.)
No one really wants their legal identity linked to a messaging identity anyway. It just isn't a suitable concept. Identity in a messaging context normally has multiple instances. You don't want your work identity linked to your family identity linked to your bar identity...
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.
The only usable tool for any organization of resistance is Telegram. Anything else is garbage. Here's why:
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.
> You can choose a username, instead of a phone number
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.
Good point. I think a better description is both the phone number and the username are tied to the account, and you can change both at will. There are enough privacy settings in Telegram that can effectively turn off having your phone number show up anywhere. You disable contact syncing and even delete synced contacts.
But in Hong Kong's case, a number of Telegram chat room operators have been prosecuted by the police for anti-government activities. If TG is really secure then this shouldn't have happened.
Well there is a number of ways for identity information to leak, from simple self-deanon mistakes to "third degrees" of key positions who were unfortunate to be caught in action and unable to prevent their chats from being analyzed. A good old handcuffing to a radiator still works too. Your claim can only be strictly true in an ideal world of ideal operation on one side and an ideal human-respecting law on the other.
>actually go and try using your proposed alternatives in protests. Most if not all of these so-called secure chats are completely unusable
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.
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.
reply