Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]
ndss-symposium.org
ndss-symposium.org
They are contributing to IETF MLS for end-to-end encrypted group messaging: https://datatracker.ietf.org/wg/mls/about/
But it would be nice if the sender could be notified that the message was never delivered.
It's not obvious, but if status never changes from "Sent", then it wasn't "Delivered".
For those who like to leave your message unread on the server for up to a year, then go with signal or telegram.
As I've observed for a long time: UX is more powerful than anything else except maybe cost, and even then one driver for user preference for "free" apps is not having to dig out a card... so cost is also UX.
Bitcoin isn't... neither is cash in hand. Neither is a drop. Someone knows.
A discussion of 'anonymity' in this context is one of increasing the difficulty of discovery, not thinking that the discovery is impossible. If a major world government is after you, good luck with "anonymous"
It could be done truly anonymously when up against the full weight and might of US, Western, Israeli etc intelligence budgets and methods?
I should still note that it isn't a magic bullet, and that things you do in connection to the monero blockchain can obviously still give the authorities an idea of what you are doing.
Etc etc. My point is that anonymous is an ideal, not a absolutist reality.
There's not many kinds of payments which aren't fairly easy to do anonymously.
These guys must be making insane amounts of money, would love to build a competitor.
In any case, doesn't this only link your personal data to the ownership of a Threema app usage license and not to the content (user ID) inside the app?
It's definitely different to entering your phone number into the app.
You can just get a gift card and pay in cash for it.
Not needing a phone number is nice, but last I checked Wire does little when it comes to metadata, while Signal is more or less the state of the art in that regard.
The phone number requirement itself is supposed to be eventually dropped in Signal (although I'll admit it's taking quite some time, and with the spam issues it might take some more).
Features are available and work everywhere (unlike Signal which has a dumbed-down desktop client and no web client at all), it does everything you generally need and the search is actually superb (better than Telegram even, since tg only does word matching and Wire can do symbol and arbitrary string matching and is also very fast) although limited to one chat so you need to know which chat contains what you're looking for. Meanwhile Element (Matrix) goes "can't search encrypted chats"... useless if you want to communicate something non-ephemeral, you'd need to switch to pgp-encrypted email and all its problems or another chat service.
Compared to all the alternatives, Wire with all its faults is the best encrypted messenger. I would recommend it to everyone aside from the network effect: Signal clearly has more users (while being worse on features and privacy). Because it's useless to be alone on a messenger and because it's still a step forwards from the status quo, most of the time I end up recommending subpar solutions.
That used to be true, but now the desktop client has almost all the feature of the mobile clients. Which feature do you miss there?
> Signal clearly has more users (while being worse on privacy)
I assume you're talking about the phone number requirement? This is fair criticism, but what about the rest? Signal leaks way less metadata than Wire, which is more similar to WhatsApp in that regard.
See also this comment: https://news.ycombinator.com/item?id=14069674
Some things might have changed, but it's not clear to which extent.
Since centralized services are currently also the convenient ones and neither Wire nor Signal show any sign of wanting to use a decentralized protocol, those that can't be bothered to use inconvenient services have to trust that their centralized service is ethical about what they do with your data.
The privacy differences are very minimal by comparison when they're all missing one basic feature or other like message editing (Signal), a desktop client (Threema[2]), cross-chat searching (Wire), searching a chat at all (Element), any usable encryption (Telegram), etc. If you're going to use an end-to-end encrypted messenger where the server can't read any contents, the privacy differences are just not that large when you trust them all equally. The only thing that you can objectively compare is what the client sends, since that's something they can minimize and you can actually check.
[1] "clients derive a 96-bit delivery token from their profile key and register it with the service. The service requires clients to prove knowledge of the delivery token for a user in order to transmit “sealed sender” messages to that user". It's a bit opaque so in regular English: my Signal client sends something like deliveryKey = H(profileKey, currentTime) to Signal, where my profileKey is something only my contacts and I know. Great, so my contacts only specify the deliveryKey and not who's sending, so you send anonymously! But wait, those contacts connect to Signal with an IP address and are doing other things like updating their profile or registering their delivery keys for their account from that same IP address. 1+1=2 and you know who is sending messages to whom.
[2] They have it, but your phone plays Chinese Whispers with your computer and every time your laptop or phone reconnects to wifi/mobile data you need to open the app on your phone and navigate two menus to re-enable it.
With Matrix you still end up trusting the server sysadmin (both in terms of ethics and technical abilities), it's not like it solves the problem for mass communication where at least one user has to agree on a 3rd-party instance.
> those contacts connect to Signal with an IP address and are doing other things like updating their profile or registering their delivery keys for their account from that same IP address.
Correct me if I'm wrong, but I think that happens within SGX. This in itself is its own can of worms, but assuming it's secure, I don't think you can do this association IP / account that easily. At least it seems so easy to work around that I would expect it to be like this (given that they already use SGX for other things). Now of course SGX is not secure, but it still makes the attacks more expensive and complex than they would be otherwise. If you have access to a Wire server, it would take you minutes to get all the group memberships of one user. If you have access to a Signal server, you'd need to log connections over some time, and do some statistical analysis to extract useful information. Not impossible, but far more costly and less reliable.
In terms of privacy Wire might be better with respect to the phone number requirement, but otherwise Signal has an edge.
The IP address is also something you can solve independently (VPN / Tor), so it makes sense not to solve it within Signal. But it would be nice to have some integration with Tor eventually.
It likely doesn't really add much security. Anyone capable of running processes on the chip hosting the SGX enclave can probably run a side-channel attack to recover the necessary keys. I was very disappointed that Signal took that approach.
I do think there's some improvements that can be made, such as a better visibly into how to sign up without a phone number (I think this is still the default on the phone app) and a more visible download option on their website (the free version is buried under "Resources" -> "Downloads". You can make backups, but there's no easy method to do a plain text export. I get the feeling sometimes messages get "Stuck", and there's been issues in the past with notifications not being sent or push notifications not getting through certain Android sleep states. Sometimes I'll edit a message just to "resend" it such that it's delivered.
Overall though, It's still my secure messanger of choice by far. Glad to see it discussed here.
The company keeps a list of all the users you contact until you delete your account.
Source: https://archive.fo/ARZe4#im
But due to the usability constraints of truly decentralized systems, I think most users are better off with federation.
E.g. it states: "A collection of decentralized computers systems are components of a larger computer network, held together by local stations of equal importance and capability. These systems are capable of running independently of each other." This is true for Matrix with Homeservers being the decentralized computers and the network of the same being the larger computer network.
If you are going to pick a tiny part of the page, you might find that it's not sufficient. In the sense of your chosen quote, Twitter is decentralized, since it runs on multiple computers organized in a network. Those are capable of running independently of each other, to a degree, if Twitter Inc did their High Availability work correctly.
It is not decentralized from a user's perspective though, since the software they use on their devices cannot run independently of the remote systems of twitter.com.
I don't know where that leaves us, but then again I don't know what you were trying to argue either.
Yeah, and I agree there are different types of decentralization: e.g. physical, authority, ... or combinations
Each incarnation with different goals
It's a bit hard to find, looks like they've given up trying to compete for non-business users, but the client has a registration form open to everyone.
I think they'll keep supporting this because inviting those 'guest' accounts into rooms of business users is a big feature. We regularly collaborate with people via Wire (customers or freelancers, who can just use their personal Wire accounts) because it's the easiest way to collaborate without forfeiting encryption or features.
Not a pro move in my opinion.
This is an inexcusable dark pattern. Two things need to happen:
1. The operating system needs to provide a "screw you, never" option for any permissions.
2. We as engineers need to say "screw you, never" to requests to implement behavior like this. Sure, this could be a bug, but I see the same behavior with Venmo and location access.
Personally I'm rather disillusioned with where we've found ourselves. This sort of adversarial relationship in which people are property of a platform and treated as such is winning.
Edit: Venmo had been set to "Only while using the app" and was prompting to enable location services on the device, not for permission. That's my own fault.
The issue is that Snapchat (in your case, as I don't have this happen on v11.23.3.36) is told that they wont get the permission and wont be able to ask for it either.
And so they perform their own inhouse permission request to you.
There is nothing that can be done from the system's point of view for that.
v11.25.0.29 Beta for me
> in house permission request
That's what I had feared. I'd expand the scope of "the system" to include Play store rules.
Why they haven't done so already is a mystery to me.
They can ban the app from app stores for using any non-system interface to request permissions, like they do for payments.
That is a very normal practice on Android. The fact that Snapchat decides that pestering the user for the permission is acceptable I find to be a very strange design decision.
If you have an interface that looks like "requestPermissions(...)" or something like that and have a case where users can reject permissions forever without nags, then how do you handle users who inadvertently deny permissions forever? One solution is to just nag forever, if you can.
Another workaround is to enable permissions manually through settings, but you need to make errors loud and obvious with workaround instructions and people interpret the issue as a bug in your code rather than a feature of the platform.
This is a problem on MacOS, just as an example.
The engineers have spoken. They say, "I'm getting paid too much to care."
Or they look at it from my perspective- who cares? According to you this is an issue but from another perspective there are clueless users who accidentally denied the permission and are grateful later. Can we really afford to have every engineer constantly objecting to the slightest subjective interpretation of what makes a dark pattern?
That's not for me to decide.
One which I allow to be shared with apps And another which are my contacts I use with my dialer.
People don't need their messenger apps knowing the phone number of their doctor
When an app requests permission to all photos the user gets the option to share only a subset of photos with the app. (This subset can be different for each app.)
Popular apps like WhatsApp, Twitter, Facebook, Telegram, etc, could just fall back to the default picker when full access is not available.
* telegram uses an "internal" contact list for which one can add contacts via the desktop client and then works as expected.
* whatsapp let's the user freely initiate contact by phone numbers, but then only shows the number (no name).
don't know about signal.
Very intuitive, I know.
Not great indeed.
as stated before, i can initiate convo by number just fine. it's just that i can't edit the identifier/handle and so it's always shown by number. thankfully most ppl have set their profile pic public, but it gets messy pretty fast.
https://wa.me/their-phone-number-in-international-format . Type this link in the browser or in some chat. Long press, click open and it will open in whatsapp by default.
You can start a chat with yourself in whatsapp, to send these links to yourself and easily click on them. (type wa.me/your-phone-number-in-international-format , click and send any message )
Here it's pretty common for people to, for example, put a notice up in my apartment foyer "does anyone have xyz that I can borrow, please app me at +123456789" and having to create a contact is an annoying bit of overhead.
I feel it would rather be better to disconnect the more static portions of a contact (in this case the phone number) from the contact on the chat network, and use something a bit more transient. Like an email address.
And while yes, primary email addresses are even more static to our identity then phone numbers, having the option of using a single address for each chat network would disconnect this contact graph somewhat.
Going further, if each platform (iOS/Android) would have a more granular portions of the contact queryable rather than handing over the whole contact, the applications could simply just request the "chat network identity" portion of the contact (never to receive the phone number, country, home address etc etc)
Because you know the slimy app developers will refuse to work if you don't hand over your full contact list. and people will just accept that.
So the end game is a completely adversarial relationship, even on your own device.
How much time? This has been a thing in one form or another since j2me. Some j2me platforms actually supported this kind of behavior, but that was all lost once Android and iOS came along. Same with fine-grained permissions over network access (eg, user having complete control over what networks/etc an app can access).
We /had/ all of this in the days of BlackBerry, and lost it. Nobody wants to give it back now.
What social tipping point needs to happen for those to be implemented? How can we lower the social bar for that to happen?
I have no clue. I'm almost always wrong on the social side of things.
This link has some screenshots and gives an idea of the capabilities. Adblock recommended:
https://crackberry.com/blackberry-101-application-permission...
The protection must be set higher up (the law, I guess) since the operating system has become spyware.
A piece of info they very likely can derive, but would really appreciate if I'd help them out and confirm it. Screw them.
Governments don't enforce privacy acts in this circumstance.
Users just roll their eyes, knowing there is no way for them to complain except though boycotts, which are difficult to organise and might not work unless coordinated on a massive scale which has never been tried.
And so it goes.
However, it isn't really surprising considering a large chunk of this very community makes their money off large-scale stalking and the same unethical things they complain about.
With email the server operators know who is talking to who but do not necessarily know who any of those people are. Email clients will not show who has you in their contact list. There is no practical way to enumerate every active email address in use.
[1] https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
They also propose a global salt as a mitigation. I'm a little confused there too, because wouldn't the salt need to be present in the endpoint application? If so it would be trivial to extract.
Their proposal of using a key stretching hash algorithm (e.g. Argon2) seems reasonable? At a significant increase in cost on the server side.
> Signal acknowledged the issue of enumeration attacks as not fully preventable,
So rate-limiting is fine as long as you don't hurt user experience, e.g. you can still message your contacts within 1min if you have around 500 contacts. It's also nice to lower the load on the servers. But there's no real fix as long as phone numbers are used.
And it's fine, given that Signal basically leaks one bit of information: whether a phone number has a Signal account or not.
...of course, assuming that the account owner doesn't accept unsolicited messages (and thus shares their profile, with their picture and "About" field).
It took me way too long to realize it's even more applicable in the descriptive sense: the people you spend most of your time with are a good statistical predictor of who you are.
Did not know that taking over a WhatsApp account is that easy.
For WhatsApp it would be nice to change the defaults so that no information (other than the fact that the number is registered) is shared with no interaction.
I had a proof of concept of something similar working a couple years ago. I was writing a file-sharing app, and the goal was to piggy-pack on the existing social graph that you had from Facebook, Skype and so on. I could not register as a proper Facebook app, since that required having a domain, and I would be legally catchable in case somebody used my app to share copyrighted or illegal stuff.
Back then, Facebook messenger was based on XMPP/Jabber, which allows sending custom stanzas (secret messages that are not shown to the user). My app would ask for your login, then send a message to every contact, and if it got a reply from another instance, it would perform a handshake and exchange keys. This also worked over (old) Skype, which although it didn't support XMPP, you could do something similar with SkypeAPI. (Unfortunately, a few months later almost every messaging service that allowed such a trick stopped it...)
Now, this trick doesn't help if you are trying to set up a new social graph in the first place. But I think with this "send an invisible message to a potential contact's app" primitive, you could build a list of mutuals securely. (Other caveats apply, you'd let somebody know that you have their number for example...)
Signal partially solves this with SGX. Partially because SGX will probably never be fully secure.
Explanation: the toggle to opt out is made available after you log into Google and you must navigate in multiple screens which gives Google ample time to collect hundreds of contact details. Of course, it is not possible to turn on airplane mode during this procedure since the log in requires an Internet connection.
This is 100% against the EU GDPR. I've submitted a complaint to my local privacy regular (French CNIL) but never heard back.
This probably impacts 200+ hundreds millions of EU citizens (since 2/3 of the population must be using an Android phone). I can't imagine a more massive data collection program, since each user must probably have more than 50 people on their device so the total amount of people that is affected exceeds my imagination.
How can Google get such a pass?
Actually GDPR is of great help to them, by putting smaller competitors away from using similar techniques. For those, a 1% revenue is a lot.
https://www.itnews.com.au/news/monitoring-fail-allowed-westp...
I suppose the consequences for Westpac are... nothing.
[1] https://eprint.iacr.org/2019/517
[2] This would do partial hash matching against a database on the server (similar to HIBP) and then do an interactive session with each of the matches, basically alternating sending the next binary bit of the phone number until either party gets it wrong or the value fully matched. The todo is to check whether there are parameters that make it both scale and protect privacy.
[3] https://dro.pm/a.webm/preview (link works for 18 hours after posting) or if you've already accepted the Google terms of service: https://www.youtube.com/watch?v=4vgKHmNaAAw
Strange that they keep and return metadata for non-registered numbers though.
From the paper:
> With its focus on privacy, Signal excels in exposing almost no information about registered users, apart from their phone number. In contrast, WhatsApp exposes profile pictures and the About text for registered numbers, and requires users to opt-out of sharing this data by changing the default settings.
https://www.bellingcat.com/resources/how-tos/2019/04/08/usin...
For example, I don't want any person who I interact with once or twice a month to have access to my WhatsApp or any other social media app. But I can't do this in Android because once you add contact every damn app has access to that contact list. It's full access or no access if app uses permissions. I need something where I can label contacts to not appear in main contact list.
In Android you have two ways of accessing most things: full access or use the system to access one entry.
You should blame WhatsApp for not supporting the second method.
Why they didn't do this by default is anyone's guess. Maybe they like app devs more than users. More technology should lie on users' behalf.
The first method is good to have for apps you trust, and requires permission from the user.
https://developer.android.com/guide/topics/permissions/overv...
The second method is what you want with apps you don't yet fully trust or for some other reason don't want to give direct access to your contacts.
https://developer.android.com/training/permissions/evaluatin...
All incentives suggest the developer should prevent using the app without full permissions being given (basically force the user into giving permission) and only implement the first method.
Sure it can be abused, but there are also legit use cases
As Android developers, we should only be given one pipe to consume from. The system should then present the user with the ability to choose if that pipe for this particular application is going to be:
"All contacts" / "A subset of contacts" / "No contacts
And even better yet just "A subset of the values for a subset of contacts"
Signal: when you’re most concerned about privacy of your message content.
Telegram: when you’re most concerned about association with contacts.
WhatsApp: when you’re most concerned about losing your ability to reach out and contact someone.
Nothing is absolute.
But don’t tell our politicians and lobbyists that. Oh wait.
How many people in the world share the same contact list as you?
answer is in the paper
If users' behaviour has shown us anything, it's that they love it. And for all the dangers of their privacy loss, they happily trade it for the convenience of finding the people they know.
The average person barely knows what a server is. They install e.g. WhatsApp on their phone, they are likely to think that the app on their phone is doing the work of telling them who else is on WhatsApp. They are not likely to think that their contact list is being scraped and uploaded and stored on someone else's computer in a warehouse, and then profiled for advertising purposes and then exposed to strangers via an API.
The average person may love the convenience, but the average person does not understand how it is implemented or the consequences of using such a service (as described in this paper).
Last time it was the (I think Whatsapp?) feature that allows, when replying to a message with an attached picture, to highlight a portion of the attached picture. That's it. There was no network effect at this point whasoever. This pseudo-feature was enough for an adult person to decide to switch back to Whatsapp and fuck my and everyone's privacy. THEN the network effect kicks in in favor of Whatsapp, because of course Whatsapp is a walled garden, so everyone is forced to switch to Whatsapp.
I have seen this already happen several times network-wide and I will see it happen again. Non-walled garden IM networks are just set-up to lose.
Mass uploading contacts should be limited, like Telgram rightfully implemented. Signal should do the same.
Also, for signal you have to give the list of your contacts. And you don't have with Telegram (and I didn't).
Some may argue that Matrix still a centralized server by the virtue of seeding your group info somewhere. But this seeding can be done via paper-only thereby it is still a true decentralized messaging server.
But it’s design intent isn’t FEDERATION, not at all.
There are also multiple client and server implementations already. You can find them here: https://matrix.org/docs/projects/try-matrix-now/
There are also at least two companies offering homeserver hosting: https://matrix.org/hosting/
As long as one for-profit company decides how it changes and evolves, it's nothing more than that.
What do you understand by federated protocol?
As I understand it, Matrix seems to be an open protocol that supports federation.
The open protocol part is evident by the extense documentation of the protocol specification that I linked in my previous message and by the fact that anyone can propose a change in the spec: https://spec.matrix.org/unstable/proposals/
You can see how the protocol supports federation here: https://matrix.org/docs/spec/server_server/r0.1.4
As for the organization governing the protocol, there is The Matrix.org Foundation: https://matrix.org/foundation/
In the foundation page it states it is "a non-profit UK Community Interest Company, incorporated to act as the neutral guardian of the standard on behalf of the whole Matrix community"
Until this is possible, it is not really a protocol, it's more like a private API available on multiple instances.
Sounds like a fair position to have.
Further, there is a alternative server implementation: Conduit.
What main selling point are you talking about?
Same thing here. It's a product of one commercial company, which fully decides how it works.
Conduit is not finished, and, given the monolytic nature of matrix protocol (as opposed to XMPP, by the way) it will likely never be finished. Even on it's GitHub page it writes with big big letters: DO NOT RELY ON IT.
True, but this isn't the case. The device you are talking about is Element, which uses the protocol. Here you can find the protocol: https://spec.matrix.org/unstable/
It is an open standard.
> Same thing here. It's a product of one commercial company, which fully decides how it works.
You, again, conflate Matrix with Element, which btw. does not fully decide how it works. Read more about that here: https://matrix.org/foundation/
> Conduit is not finished, and, given the monolytic nature of matrix protocol (as opposed to XMPP, by the way) it will likely never be finished. Even on it's GitHub page it writes with big big letters: DO NOT RELY ON IT.
Conduit is a server of a competing entity. I didn't claim it was finished or will ever be finished in the way that there won't be any development any more.
what's it's RFC number? which body does govern the development of this 'protocol'?
It's governed by the Matrix Foundation, which I have linked before
Why didn’t you write it then? It’s easy to dismiss the work of others, not so easy to do the work yourself.
Any thoughts on this?
I'm not saying this is good. But merely that assuming otherwise was always a bit naive. Now in terms of GDPR and similar laws in the US, leaking information via a scrapable API is of course still a problem.
But who I have in my contact list is _not_ public information. You can infer a lot from that.
And the idiots who create these social apps always assume you want to "connect" with whoever is in your contact list.
Even if you added their number so you know to _not_ pick up when they call.
From the paper:
> With its focus on privacy, Signal excels in exposing almost no information about registered users, apart from their phone number. In contrast, WhatsApp exposes profile pictures and the About text for registered numbers, and requires users to opt-out of sharing this data by changing the default settings.
So if you only use Signal you don't leak the connection between your profile (which could contain your name) and your phone number, at least not until you accept a message from an attacker.