Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]

ndss-symposium.org

Post reply on HN
Print view View original

131–140 of 206 posts

Re: Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]

#131

Post by sneak »

strogonoff wrote: post #26
hansel_der wrote: post #17

Earlier quoted context omitted.

on ios if one does not grant addressbook permission for the app: * 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.

WhatsApp on iOS cripples user experience without access to OS contact list. You cannot create groups, and cannot initiate a chat with anyone, even by phone number. It works if someone else messages you first or adds you to a group.

I can't imagine the use case where you want to keep your contacts from WhatsApp for privacy, but continue using a Facebook service.

Re: Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]

#132

Post by sneak »

ISO-morphism wrote: post #125

Every time I open the Snapchat Android app it prompts me with a Snapchat-styled (not the system) dialog to share my contacts. Every time I hit "Don't allow". Every time it prompts me again. 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 b…

The "screw you, never" option is to delete your Snapchat and Venmo accounts, and delete those apps from your device. This is what I did.

Re: Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]

#133

Post by MrDresden »

de6u99er wrote: post #92
Jonnax wrote: post #12

There needs to be two lists of contacts. 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

It would be much smarter if your contacts could chose to allow you to share or not share their details.

While I agree with the sentiment, I am not so sure how well this could be implemented in practice.

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)

Re: Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]

#134

Post by MrDresden »

ISO-morphism wrote: post #125

Every time I open the Snapchat Android app it prompts me with a Snapchat-styled (not the system) dialog to share my contacts. Every time I hit "Don't allow". Every time it prompts me again. 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 b…

The system does have a "screw you, never" option for all permissions.

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.

Re: Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]

#135

Post by lucb1e »

Karrot_Kream wrote: post #9

The authors have an implementation of an improvement on these messengers' contact discovery algorithms at https://contact-discovery.github.io/

That's an interesting project / paper[1]. I don't have the time to dive deeply into it and understand how this works, but at a glance it seems better than what I was working on a few months ago[2]. Does anyone else know more about this, since the paper is really written for the in-crowd? The video[3] helps a little for a very high-level overview (to give some context before starting to read), but doesn't explain how it works or what properties their algorithm has.

[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

Re: Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]

#136

Post by MrDresden »

zibzab wrote: post #128
LeifCarrotson wrote: post #116

Earlier quoted context omitted.

Why would an app developer ever think their own app should use the method reserved for untrustworthy apps? 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.

Because it would be easier for the users and allow some customization you can't otherwise have? Sure it can be abused, but there are also legit use cases

While I get where you are coming from, but giving that option is a design flaw.

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"

Re: Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]

#137

Post by ISO-morphism »

sneak wrote: post #132
ISO-morphism wrote: post #125

Every time I open the Snapchat Android app it prompts me with a Snapchat-styled (not the system) dialog to share my contacts. Every time I hit "Don't allow". Every time it prompts me again. 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 b…

The "screw you, never" option is to delete your Snapchat and Venmo accounts, and delete those apps from your device. This is what I did.

Indeed, that's what I should do as an individual and try to drag along as much of my social graph as I can. There probably isn't any salvaging platforms built on data collection as a business model.

Re: Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]

#138

Post by MiddleEndian »

lucb1e wrote: post #122
MiddleEndian wrote: post #112

Earlier quoted context omitted.

They can just lie to the old apps. Tell them they're getting the full list when the API is called.

Privacy Guard in Cyanogenmod used to do this I think, at least to fake the list to be empty. It somehow still broke a tiny number of apps (unintentionally, i.e. the app owners didn't purposefully add code to annoy those users) so there seems to have been some flaw between 'empty list with permission granted' and 'empty list with permission not granted'. Regardless, I'm not sure why this didn't become mainline Android…

For backwards compatibility, they could just put in some nonsense entries. If the program can figure out those entries are nonsense, it's no longer out of date and it's on them.

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.

Re: Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]

#139

Post by GrinningFool »

spitfire wrote: post #129
Jonnax wrote: post #12

There needs to be two lists of contacts. 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

In time I expect all OSes (mobile and desktop) will provide a "give false data" option. So Sandboxed+false inputs, sort of a digital Descartes deceiver. 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.

> In time I expect all OSes (mobile and desktop)

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.

Re: Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]

#140

Post by the_duke »

remram wrote: post #127
birksherty wrote: post #99

Earlier quoted context omitted.

Matrix tools like Element is decentralised which is preferred, wire is not. The company keeps a list of all the users you contact until you delete your account. Source: https://archive.fo/ARZe4#im

It is federated, not decentralized. You need to use a server, which will have access to your contacts and the rest of the metadata such as how often you talk to them etc (and all message content that is not E2EE). You are only safe from third party if both you and people you talk to run their own servers.

That's changing. Dendrite [1] is the official next-generation server implementation and optionally supports decentralization.

But due to the usability constraints of truly decentralized systems, I think most users are better off with federation.

[1] https://github.com/matrix-org/dendrite

Post reply on HN