[HN Gopher] Large-Scale Abuse of Contact Discovery in Mobile Mes...
___________________________________________________________________
Large-Scale Abuse of Contact Discovery in Mobile Messengers [pdf]
Author : weinzierl
Score : 380 points
Date : 2021-04-19 08:02 UTC (14 hours ago)
(HTM) web link (www.ndss-symposium.org)
(TXT) w3m dump (www.ndss-symposium.org)
| walterbell wrote:
| Wire (from the creators of Skype) does not mandate a mobile phone
| number (SIM cards are tied to government identity in many
| countries). Only an email address is required to open a free
| account. Nor does Wire mandate upload of your phone's address
| book with personal social graph of contacts. Free for consumers
| with paid teams offering for enterprises, optional on-prem
| server. Open-source clients and server. Cross-device history if
| the device logs in within a few weeks of the sent message. Basic
| export/import for moving your device's message archive to a new
| device of the same type.
|
| https://wire.com/download/
|
| They are contributing to IETF MLS for end-to-end encrypted group
| messaging: https://datatracker.ietf.org/wg/mls/about/
| qwertox wrote:
| Threema also does not require your phone number.
| ReptileMan wrote:
| It requires payment - so google account or your paypal/credit
| card are on record.
| qwertox wrote:
| I forgot this fact. One could create a new Google account
| and buy a gift card.
|
| 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.
| c0wb0yc0d3r wrote:
| FWIW, your threema identity isn't tied to your license key.
| ThermalCube wrote:
| You can pay by Wire transfer, MasterCard, Visa, PayPal or
| even Bitcoin[1] so there is at least one anonymous payment
| option available
|
| 1: https://shop.threema.ch/terms
| norcux wrote:
| Who said Bitcoin is anonymous?
| criley2 wrote:
| There is no such thing as an anonymous transaction, for a
| fully informed definition of anonymous.
|
| 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"
| Ticklee wrote:
| Monero is.
| criley2 wrote:
| So you think if a notorious terrorist or whatever moved
| millions of dollars through Monero to fund a terror
| attack, American or other intelligence agencies wouldn't
| be able to identify the transaction?
|
| It could be done truly anonymously when up against the
| full weight and might of US, Western, Israeli etc
| intelligence budgets and methods?
| Ticklee wrote:
| Well the sender, receiver and the amounts are all hidden,
| so yes.
|
| 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.
| naivedevops wrote:
| You could convert Monero ou Zcash to Bitcoin at an
| exchange before paying. I don't know which exchanges
| currently allow to do that without verifying your
| identity, though.
| _0ffh wrote:
| If you can acquire BTC anonymously, then you can pay
| anonymously.
| FDSGSG wrote:
| If you can acquire BTC anonymously, then you can acquire
| prepaid virtual credit cards anonymously. Most
| localbitcoins exchangers will happily do bank transfers
| for you without asking any questions either.
|
| There's not many kinds of payments which aren't fairly
| easy to do anonymously.
| walterbell wrote:
| Any recommendation on prepaid virtual credit cards which
| are accepted in EU?
| zeitg3ist wrote:
| I didn't login on Wire for 3 months and "for my security"
| messages that were sent to me during that time were just...
| lost. I think my history was deleted too. This happened 2 or 3
| years ago, but it made me just switch to something else
| (Telegram).
| exciteabletom wrote:
| FWIW Telegram deletes your account if you are away for a
| year, and you cannot disable it.
| oauea wrote:
| So you want them to just hold on to your messages on their
| servers indefinitely? I realize this is the norm nowadays,
| but is this really what you actually want?
| zeitg3ist wrote:
| I think it should be an option, at least.
| [deleted]
| usrusr wrote:
| In a flawed world that deals perfectly with its flaws,
| infinite storage would be a service you can optionally buy
| from an open market of third parties, alongside optional
| identity mediation (for those who definitely don't want
| their identity bound to a device or SIM or some other PID
| known to the core network). Bonus points if the
| technological and organizational interface between third
| party and core network is paid, I believe that this would
| be one of the least bad ways imaginable of funding the core
| network.
| deepstack wrote:
| Wire is not for people to leave message unread for 3
| months. Most user can deal with that. And once it is read.
| You can archive your message on to a file (and then put on
| USB). For most users, why use anything else?
|
| For those who like to leave your message unread on the
| server for up to a year, then go with signal or telegram.
| admax88q wrote:
| Yes? I want them to hold to my messages in am encrypted
| form for all time. The NSA has probably logged them
| anyways. I'm done with managing my own backups, my state
| should be persisted "in the cloud" with no effort from me.
| api wrote:
| This is one of those replies that should be put in some kind
| of HN canon. It perfectly shows why there are so few privacy
| or security respecting options. They did the correct thing
| for security and you switched.
|
| 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.
| zeitg3ist wrote:
| That's a bit unfair. I value privacy for some things but
| for other things I value more not losing my message
| history. Telegram is not as secure as other options by
| default, but for me it strikes a good balance between
| convenience/usability and privacy, as I can optionally open
| a self-destroying secret chat when I need it.
| kitkat_new wrote:
| With Matrix you get privacy with message history.
| walterbell wrote:
| For those who want end-to-end encrypted messages, it's a
| feature that the server doesn't have a persistent archive of
| message history. Wire messages are on the server for a few
| weeks, long enough to relay those messages to transiently
| offline devices. Telegram is great at what it does, different
| use case from Wire.
| ajconway wrote:
| Matrix does have end-to-end encrypted persistent history.
| walterbell wrote:
| Yes, it's possible. Depending on your threat model, it
| may or may not be a good idea to have a long-term archive
| of encrypted data be subject to legal process. Matrix has
| plans to support IETF MLS, which is a necessary precursor
| to messenger interoperability.
| Arathorn wrote:
| Matrix lets you configure the history retention on a per-
| server or per-room basis, fwiw:
| https://github.com/matrix-
| org/synapse/blob/develop/docs/mess.... From a metadata
| perspective, we're working on P2P to avoid metadata
| accumulating on servers. In terms of the OP here
| (address-book based contact discovery),
| https://github.com/matrix-org/matrix-doc/blob/hs/hash-
| identi... is how Matrix optionally implements it while
| trying to preserve privacy.
| zeitg3ist wrote:
| Yeah, I guess it's just a different use case, but it was a
| behavior I didn't expect (maybe I didn't read the "fine
| print") and it turned me off using it for long-term stuff.
| It's a pity because I liked the interface and features.
| zibzab wrote:
| I'm actually fine with the wire approach.
|
| But it would be nice if the sender could be notified that
| the message was never delivered.
| walterbell wrote:
| Each Wire message has a user-visible status: Failed, Sent
| or Delivered.
|
| It's not obvious, but if status never changes from
| "Sent", then it wasn't "Delivered".
| ckozlowski wrote:
| There's a new icon now as well with an "eyeball" that
| tells you if the message was viewed. The option for this
| read receipt can be enabled in the options if both
| parties enable it.
| Zambyte wrote:
| Uh, just FYI this is alao a feature on Telegram that can't be
| disabled (only extended up to a year).
| antihero wrote:
| I'm amazed that they still don't have any kind of 2FA after
| nearly four years.
|
| https://github.com/wireapp/wire/issues/85
| tomjen3 wrote:
| I can't seem to find any information about their free version
| on that page.
| lucb1e wrote:
| https://app.wire.com/auth/?hl=en#register
|
| 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.
| ckozlowski wrote:
| I love wire, but this is one of my biggest pet peeves right
| now. I can't tell someone to just "go download Wire" on the
| desktop without giving them navigation instructions
| ("Resources" menu at the top, then "Downloads" because
| there's so much focus on the paid products.)
|
| Not a pro move in my opinion.
| birksherty wrote:
| 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
| remram wrote:
| 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.
| kitkat_new wrote:
| mind explaining how Matrix is not decentralized?
| the_duke wrote:
| 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
| sen wrote:
| Wire is massively underrated in general. It's got a slick UI
| that's easy for non techies, it's got native clients on all
| major platforms, and it has everything you really need from an
| e2e IM without the fluff. I'm surprised it doesn't come up more
| in these discussions and people just "settle" for Signal or
| another service that needs your phone number etc.
| ckozlowski wrote:
| Agreed. I've been using it for years, and much to my surprise
| I've been able to convert most of my extended family into
| using it. The fact that our parents (60s-70s) are using it
| successfully to post and share pictures as well I think is a
| good sign of it's accessibility. The rich media, good
| voice/video support, and ease at making multi-user
| discussions are all excellent. The persistence across devices
| is excellent, and I love that it's just as easy to use on the
| desktop as it is on mobile.
|
| 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.
| lucb1e wrote:
| The clients are not actually native, at least on desktop it's
| just Electron and the mobile clients (Android, iOS) don't
| feel fast either, but frankly rough edges like these are my
| only real complaint.
|
| 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.
| hiq wrote:
| > dumbed-down desktop client
|
| 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.
| lucb1e wrote:
| For metadata you just have to trust them. Sealed sender
| doesn't solve that[1], even if it's better than nothing.
| It's also better than nothing to require no phone number
| in the first place (Wire), or not to require a payment
| (like Threema does) which is roughly as hard to make
| anonymous as getting an anonymous phone number. But
| either way, they can track everything you send, it's a
| matter of wanting to. The only way to avoid that is by
| not sending personal data to semi-/untrusted parties at
| all (Matrix).
|
| 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.
| hiq wrote:
| > The only way to avoid that is by not sending personal
| data to semi-/untrusted parties at all (Matrix).
|
| 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.
| AlexCoventry wrote:
| > SGX. This in itself is its own can of worms, but
| assuming it's secure
|
| 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.
| kitkat_new wrote:
| Element can search encrypted chats, just not yet in the
| browser
| walterbell wrote:
| The Wire iOS native Arm client is fast and can be made
| officially available for M1 Arm-based Macs. Looking forward
| to that, as the Slack iOS Arm client is way faster on my M1
| Macbook than the desktop memory-hogging Slack.
| Nextgrid wrote:
| Did you use unofficial means to install Slack iOS on M1
| (which is now patched if I remember right) or is there
| still a way?
| walterbell wrote:
| I did it before the patch, but the enforcement is now
| being done by Fairplay DRM. There are reports that you
| can extract the iOS app from a jailbroken iPhone, with
| DRM removed. Then the resulting .ipk will work on M1.
| Arathorn wrote:
| Element does encrypted search fine on desktop, fwiw.
| 14 wrote:
| I also like wire and just by chance found it to message my
| kids on their iDevices that don't have a phone number like
| iPads and iPods. It works great and has all the main
| features. I'm even happier now that you guys inform me it's
| secure also.
| mercutio2 wrote:
| If they're Apple devices, why don't you just use iMessage?
| Forbo wrote:
| This is purely speculation into their motivations on my
| part, but it might have to do with Apple backing up
| encryption keys to iCloud.
| hiq wrote:
| > I'm surprised it doesn't come up more in these discussions
| and people just "settle" for Signal
|
| 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).
| ISO-morphism wrote:
| 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 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.
| MrDresden wrote:
| 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.
| ISO-morphism wrote:
| > v11.23.3.36
|
| 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.
| hctaw wrote:
| > There is nothing that can be done from the system's point
| of view for that.
|
| They can ban the app from app stores for using any non-system
| interface to request permissions, like they do for payments.
| juergbi wrote:
| The system could supply an empty contact list.
| dillondoyle wrote:
| I get annoyed by the web version of this for push
| notifications - mostly the ones that copy the specific
| browser UA style.
| 2OEH8eoCRo0 wrote:
| >We as engineers need to say "screw you, never"
|
| 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.
| sneak wrote:
| 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.
| ISO-morphism wrote:
| 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.
| Karrot_Kream wrote:
| The authors have an implementation of an improvement on these
| messengers' contact discovery algorithms at https://contact-
| discovery.github.io/
| lucb1e wrote:
| 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
| jacquesm wrote:
| It didn't take long after the first social graph was created to
| realize that your contacts define you as much or even more than
| your other indicators do. That's why so many companies are
| gunning for this information.
| TeMPOraL wrote:
| A quote I saw on the Internet long ago went, "You're the
| average of the five people spend the most time with". I used to
| interpret it only in its original, prescriptive sense: if you
| want to become a different person, make appropriate changes to
| your social life.
|
| 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.
| _trampeltier wrote:
| I was wondering, what would happen, if I would add all the phone
| numbers from the Facebook leak to my contacts. Did anybody try
| something like this? What is the upper contact limit?
| anthropodie wrote:
| I will criticize how Contacts are implemented on Android for
| this.
|
| 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.
| zibzab wrote:
| That is not correct.
|
| 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.
| Nextgrid wrote:
| The fact that an app can choose to "support" a method is a
| flaw. The app should be completely oblivious to whether what
| it's seeing is the full list of accounts or a carefully
| selected one.
| anthropodie wrote:
| My point remains valid. If OS is handling contacts it should
| have some sort of control over what's getting shared. Theirs
| no point of providing alternate ways if an app can access
| full list of contacts.
| viraptor wrote:
| You need a migration path and backwards compatibility. They
| can't kill all the apps which used the old system.
| MiddleEndian wrote:
| They can just lie to the old apps. Tell them they're
| getting the full list when the API is called.
| lucb1e wrote:
| 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 aside from that it
| would come with no benefits to the main developer of
| Android.
| MiddleEndian wrote:
| 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.
| lucb1e wrote:
| Sure sure, I was just saying that this sort of thing
| already existed in the past (in Cyanogenmod, and that it
| worked well for 99% of apps even without providing wrong
| data) but other vendors or even mainline Android never
| picked it up unfortunately.
| LeifCarrotson wrote:
| "Yep, this user has exactly one contact, and gee, it
| happens to be the one they're calling now, how
| fortuitous! They had a different single contact
| yesterday, but apparently they've deleted that one and
| added this one."
| MiddleEndian wrote:
| If the devs update the code to respond to fake entries,
| then the program is no longer out of date and thus no
| longer in need of backwards compatibility.
| zibzab wrote:
| That is a very odd take away.
|
| The first method is good to have for apps you trust, and
| requires permission from the user.
|
| https://developer.android.com/guide/topics/permissions/over
| v...
|
| 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/evaluati
| n...
| LeifCarrotson wrote:
| 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.
| zibzab wrote:
| 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
| MrDresden wrote:
| 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"
| john2010 wrote:
| ideally true. The issue is common person expects things to
| 'Just Work' - means read/allow contacts.
| sodality2 wrote:
| Android Work Mode has this contact-separating feature:
| https://f-droid.org/packages/net.typeblog.shelter/
| Jonnax wrote:
| 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
| jannes wrote:
| An alternative would be to make it similar to the iOS photo
| gallery permissions:
|
| 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.)
| furyg3 wrote:
| While I agree with you, the current way this functionality
| works is really terrible.
| h0h0h0h0111 wrote:
| Agree - it's a great concept but seems to involve an
| inordinate number of clicks (touches?) all over the screen
| ratww wrote:
| It's indeed terrible in Apps that reimplement the photo
| selecting feature, but in simpler Apps that just use the
| default picker it works quite well and it is transparent.
|
| Popular apps like WhatsApp, Twitter, Facebook, Telegram,
| etc, could just fall back to the default picker when full
| access is not available.
| tgv wrote:
| Or the number of the VD clinic, or the number of the an
| oncology ward, or the number of the pawnbroker, ...
| hansel_der wrote:
| 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.
| strogonoff wrote:
| 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.
| sneak wrote:
| I can't imagine the use case where you want to keep your
| contacts from WhatsApp for privacy, but continue using a
| Facebook service.
| vbezhenar wrote:
| https://wa.me/phonenumber
|
| Very intuitive, I know.
| MauranKilom wrote:
| 404 for me.
| TeMPOraL wrote:
| For people as confused as I was about the above link -
| after spending 5 minutes trying to figure out why
| visiting it gives me a 404 page, I eventually got out my
| phone and tried pushing that link to Android activity
| system, and then I discovered: it's meant to be wa.me/[an
| actual phone number goes here] - like
| wa.me/12345678912345.
|
| Not great indeed.
| ratww wrote:
| If you type _https://wa.me/your_own_phone_number_
| (replace _your_own_phone_number_ with your number) you
| can get into a chat with yourself. Useful for
| misanthropes, introverts, or for having a place to store
| information.
| eythian wrote:
| As far as I can tell, on Android, whatsapp requires adding a
| person to your contacts before you can message them at all. I
| find this very annoying when I'm going to be messaging
| someone for a brief period only. If there's a way to not do
| this, I'd like to know it.
| ffpip wrote:
| You can message a person without adding them to your
| contacts, if you know their phone number.
|
| 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 )
| eythian wrote:
| Thanks, I'll remember that. It's an awkward workaround
| compared to pasting their number from an email into the
| app, but it'll have to do I guess.
|
| 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.
| spitfire wrote:
| 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.
| GrinningFool wrote:
| > 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.
| AshamedCaptain wrote:
| I didn't know that (Blackberry). I would like to know about
| it, if you have any links.
| spitfire wrote:
| That's a good question. We know exactly what technical
| solutions are needed to counter this adversarial activity.
|
| 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.
| de6u99er wrote:
| It would be much smarter if your contacts could chose to allow
| you to share or not share their details.
| MrDresden wrote:
| 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)
| rcMgD2BwE72F wrote:
| Don't forget that on Android, Google will sync all contacts
| with their servers without asking the user to install an
| application (the Play Store have access to all contacts and
| will sync them with the Google account when logging into the
| Play Store... which is inevitable on Android).
|
| The protection must be set higher up (the law, I guess) since
| the operating system has become spyware.
| itg wrote:
| I don't know about other Android phones, but Samsung has a
| Secure Folder with a separate list of Contacts.
| random5634 wrote:
| 100% of signal scrapped - ugh
| Daniel_sk wrote:
| They have been too busy with integrating crypto payments
| instead of fixing long standing issues or planned features
| (allow to register without a phone number). But - to Signal's
| defense - while you can scrape the phone numbers, there is not
| much you can gain from it, you can only tell that a specific
| number is a Signal user. And sometimes you can see the username
| (if the user chooses to not encrypt it).
| walrus01 wrote:
| Given the re-use and re-issuance of phone numbers in very
| busy US area codes (like 212, 202, etc) it also only allows
| discovery that at some unknown point in the past, that number
| has been registered as a Signal user.
| dotandimet wrote:
| Just as insecure as Whatsapp, just far fewer users.
| hiq wrote:
| > Just as insecure as Whatsapp
|
| 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.
| jimkleiber wrote:
| I have thought for a while about creating a contacts app for the
| phone that had much more privacy, almost like a Signal but
| specifically for the address book.
|
| Any thoughts on this?
| wombatmobile wrote:
| The reason this abuse of privacy is so widespread is because
| there are no bad consequences for the perpetrators.
|
| 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.
| Nextgrid wrote:
| And yet people are still bitching about the GDPR. The only
| problem with the GDPR is the lack of enforcement.
|
| 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.
| ryandrake wrote:
| The only people really bitching about GDPR are software
| engineers and lawyers at companies whose privacy practices
| are still questionable after all the time given to clean up
| their act. That's why, if you look at HN comments, everyone
| seems to hate it. Sample bias. None of the remaining 7
| billion people on the planet really know much about it. I bet
| if you summarize the regulation and describe it to a random
| person on the street, they'll nod and think "sure it's kind
| of a good idea" and forget about it in the next 10 seconds.
| captainmuon wrote:
| I think the information who is a contact of whom should not
| reside with the provider, but be distributed among the peers.
|
| 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...)
| hiq wrote:
| > I think the information who is a contact of whom should not
| reside with the provider, but be distributed among the peers.
|
| Signal partially solves this with SGX. Partially because SGX
| will probably never be fully secure.
| tediousdemise wrote:
| Your contact list seems like a pretty unique fingerprint with
| high entropy. It also persists across devices and accounts
| through common synchronization mechanisms.
|
| How many people in the world share the same contact list as you?
| ovi256 wrote:
| In other parts of the world, users share their contact books to
| get access to what others shared, see Bellingcat's extensive use
| of these phone contact book apps, here documented in 2019:
|
| https://www.bellingcat.com/resources/how-tos/2019/04/08/usin...
| jillesvangurp wrote:
| The practical consequence of this is that your phone number +
| name is public information. Almost as if it were listed in a
| phone book. That was pretty much the case already so it's not
| really a new threat. Of course people with unlisted numbers will
| be a bit annoyed by this. Likewise, your email address probably
| is part of numerous databases, including those owned by
| spammers/scammers.
|
| 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.
| elric wrote:
| Yeah ... no. I'm not sure what exactly gets shared with these
| apps, whether it's just the numbers or also the rest of the
| contact information. If names are being shared, that's a
| seriously fucked up nono. These parties are getting insights
| into our lives that are way beyond what is reasonable. Imagine
| I have 555-12345 in my contact list as "Wife" and someone else
| has the same number as "Girlfriend".
| hiq wrote:
| > The practical consequence of this is that your phone number +
| name is public information.
|
| 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.
| gnud wrote:
| My name/number is already pretty much public information, you
| can find it in various public registries if you search.
|
| 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.
| rcMgD2BwE72F wrote:
| An even bigger problem: if you set up an Android phone without a
| Google account and need to access the Play Store (which is
| impossible to do without nowadays), Google will force you to sign
| into a Google account at the OS level and will suck in all your
| devices contacts -- with no opt out. You can disable this sync
| "feature" but *only after*, once Google has collected all your
| contacts (phone number, addresses, emails, birthdays, etc).
|
| 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?
| lofi_lory wrote:
| I use Aurora for the Playstore. It's buggy but does the trick
| for the few apps not in FDroid. No account needed as they
| provide a service for shared credentials.
| gnfargbl wrote:
| The paper claims that stricter rate limits are a possible
| solution to this issue, and that with stricter limits in place
| "crawling entire countries would only be feasible for very
| powerful attackers". I don't think I agree. Take Signal: the
| authors managed to crawl all US phone numbers in 25 days, using
| 100 accounts. Their proposed stricter rate limits force an approx
| 50x slowdown on an attacker (Table V), which seems to imply that
| over the same crawl period an attacker would require 5000
| accounts. If we assume that virtual SMS numbers are around $5
| each, then the attack now costs about $25k, which is about 0.001%
| the GDP of East Timor.
|
| 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.
| hiq wrote:
| From the paper:
|
| > 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).
| blorange wrote:
| "Interestingly, if the number provided by Hushed was previously
| registered by another user, the WhatsApp account is "inherited",
| including group memberships. A non-negligible percentage of the
| accounts we registered had been in active use, with personal
| and/or group messages arriving after account takeover."
|
| Did not know that taking over a WhatsApp account is that easy.
| hiq wrote:
| You can set a pin which I think would reset your account
| eventually if you want to register the same number but fail to
| provide the correct pin, and the previous owner of the phone
| number does not use WhatsApp in some time.
| elyobo wrote:
| Happened with Australia's real time payment system too.
|
| https://www.itnews.com.au/news/monitoring-fail-allowed-westp...
| wombatmobile wrote:
| I didn't know that. Thanks.
|
| I suppose the consequences for Westpac are... nothing.
| elyobo wrote:
| As far as I know, no. I suspect that it wasn't just them.
| deeplowdock wrote:
| Nice to see Telegram imposed strict limits for contact discovery.
| They were only able to scrape 100k numbers over 20 days.
|
| Strange that they keep and return metadata for non-registered
| numbers though.
| [deleted]
| williesleg wrote:
| Surprise!
| [deleted]
| cpach wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=24494505
| upofadown wrote:
| People will complain about the meta-information leakage of email
| but then turn around and suggest we should instead use something
| based on your phone number[1]. I guess this is a reminder that
| phone number based contact discovery has issues as well ...
| perhaps worse ones in practice.
|
| 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....
| blorange wrote:
| The most interesting section for me was "Exposed User Data". My
| takeaway is that an attacker can know whether my phone number is
| registered with Signal and can receive voice and video calls.
| They also get my encrypted name and profile picture but would
| need my explicit consent for that.
| hiq wrote:
| That's my take as well, and I think that's already known by
| most users. So nothing new for Signal users.
|
| 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.
| egberts1 wrote:
| Imagine my surprise when one can actually give up MORE revealing
| information about yourself and your contacts just by installing
| BOTH Telegram and Signal apps.
|
| 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.
| anticensor wrote:
| Matrix: when you are most concerned about losing your message
| history.
| Andrew_nenakhov wrote:
| This scientifically-looking paper could have been written by
| Captain Obvious himself. It is beyond obvious that contact
| discovery in any major messenger or social network is facilitated
| by uploading all contacts from the user's address book, with all
| the implied drawbacks.
|
| 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.
| MattJ100 wrote:
| "They love it" but they often aren't given the choice, nor are
| they fully aware of the consequences (I expect many would
| choose not to accept if the findings in this paper were
| presented to them in a clear understandable way).
|
| 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).
| AshamedCaptain wrote:
| In my experience, even after having made fully sure that they
| understand the risks involved, "the average person" will
| happily switch back to a walled garden IM platform the moment
| the next stupid feature comes in.
|
| 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.
| Ar-Curunir wrote:
| > This scientifically-looking paper could have been written by
| Captain Obvious himself
|
| Why didn't you write it then? It's easy to dismiss the work of
| others, not so easy to do the work yourself.
| aljones wrote:
| Is there a "scientifically-looking" paper that shows that users
| love it?
| christophilus wrote:
| It doesn't show that we love it. I hate it. But it's the cost
| of entry if you want to communicate with a group on any of
| those platforms (which I refuse to do outside of Signal). I
| didn't love giving Signal my contacts list, but I did it.
| kome wrote:
| > It is beyond obvious that contact discovery in any major
| messenger or social network is facilitated by uploading all
| contacts from the user's address book, with all the implied
| drawbacks.
|
| 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).
| duckfang wrote:
| With Signal, it means your friends can rat you out by them
| sharing their address book.
| egberts1 wrote:
| Yeah, associativity remains an issue via Signal but the
| encryted-at-rest message content can be timed out at your
| interval.
| Andrew_nenakhov wrote:
| Actually, the general love for Signal on HN is puzzling to
| me. It's nothing more than yet another centralised silo not
| owned by the users. End-to-end encryption? I'd take
| federation over it any day.
| egberts1 wrote:
| there is always Matrix app.
|
| 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.
| Andrew_nenakhov wrote:
| No, there is always xmpp. Matrix is just an app, and we
| need a federated protocol. I think that Matrix will never
| have an alternative server implementation made by a
| competing party, which makes it's main selling point
| void.
| kitkat_new wrote:
| Matrix is no app. Matrix an open protocol for
| decentralized communication that works through
| federation.
|
| Further, there is a alternative server implementation:
| Conduit.
|
| What main selling point are you talking about?
| egberts1 wrote:
| Manyverse (Sweden) app does Matrix well.
|
| But it's design intent isn't FEDERATION, not at all.
| galbar wrote:
| Matrix is not an app. It is a protocol. You can find the
| specification here: https://matrix.org/docs/spec/
|
| 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/
| Andrew_nenakhov wrote:
| It is not a federated protocol. It is an app that has
| some internally developed protocol, which makes it hardly
| more than an app, really.
|
| As long as one for-profit company decides how it changes
| and evolves, it's nothing more than that.
| galbar wrote:
| Maybe I'm missing something.
|
| 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"
| Andrew_nenakhov wrote:
| by an open federated protocol I understand the likes of
| email or xmpp, or TCP, for that matter. Standardized and
| developed by an independent entity, for better or worse.
| Where the power of any single developer is checked by
| other developers and the standards body. Currently,
| matrix.org owners can unilaterally change the protocol in
| any way they like, upgrading their server that hosts the
| vast majority of users, and all the other independent
| implementations would be left in the dust.
|
| Until this is possible, it is not really a protocol, it's
| more like a private API available on multiple instances.
| galbar wrote:
| So if all goes well, it will become an "open federated
| protocol", according to your definition, in a few years
| when it is more stable, mature and multiple interests
| (companies) are governing its direction?
|
| Sounds like a fair position to have.
___________________________________________________________________
(page generated 2021-04-19 23:00 UTC)