Live data from Hacker News

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

ndss-symposium.org

171–180 of 206 posts

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

#171
post #127

Earlier quoted context omitted.

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.

mind explaining how Matrix is not decentralized?

What they mean is that there is a client/server separation. Truly decentralised systems don't have this distinction and only have communicating nodes. Though this is coming to Matrix too.

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

#172
post #127

Earlier quoted context omitted.

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.

mind explaining how Matrix is not decentralized?

As I understand it, the consensus is to call multi-server systems "federated" and peer-to-peer systems "decentralized". See https://en.wikipedia.org/wiki/Decentralized_computing for references.

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

#173

Earlier quoted context omitted.

You need a migration path and backwards compatibility. They can't kill all the apps which used the old system.

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

What if the app caches some (or fragments of) entries for some good reason? If you're unaware you're getting only one requested contact each time you may be triggering edge case behaviour. What if you have reasonable time-out behaviour which triggers each time now while user chooses which contact to expose to the app? What if the contract list is polled in the background, or when you receive a message to match it up with the right source?

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

#174
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

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.

To that point, I find it entirely un-amusing that Google is presenting me with a notification on my phone that says: "Account action required: add your birthday" %@$#

A piece of info they very likely can derive, but would really appreciate if I'd help them out and confirm it. Screw them.

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

#175

Earlier quoted context omitted.

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.

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?

If you make a device (say, wireless walkie-talkie) that can communicate with other devices of this type, it is not yet an open standard protocol. It's just your proprietary thingy that you do with some communication properties.

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.

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

#176
post #123

Earlier quoted context omitted.

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 a…

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.

I wouldn't hold my breath for it to happen. Why would the current owner relinquish control to others to govern its direction?

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

#177
post #109

Earlier quoted context omitted.

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.

Any recommendation on prepaid virtual credit cards which are accepted in EU?

Sorry, I have none. I never bothered to try acquiring de-personalised crypto, as I never needed any. The VCC idea sounds neat, but it's practically transparent for state actors. I think the easiest and safest option is directly exchanging cash for crypto at a crypto-ATM, if you can find any where you live. Downsides, you usually get a relatively bad exchange rate and they are often hard to find, if not forbidden. Or you buy privately, preferably from someone you trust not to cheat you, but you'd first have to find that person. The next-best thing might be to buy a relatively private coin like ZCash or Monero and exchange that for whatever else. But don't take that as advice, I'm not an expert. It's probably best you do your own digging.

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

#178
post #131

Earlier quoted context omitted.

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.

Because WhatsApp has a sound e2e implementation enabled by default, is more trustworthy than Telegram and less liable to be influenced by Russian government? Keeping contacts out of it is just hygienic.

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

#179

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, email…

I feel you. Unfortunately, I don't think GDPR will be of much help on that case. A fine of up to 1% of they're revenue will hardly make a dent - it's just another tax. Misbehaviour will be still worth it.

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.

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

#180
post #143

Earlier quoted context omitted.

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.

> 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.

I am not agreeing with it, but they are showing a piece of custom ui that probably links into the settings for you to make changes.

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.

Post reply on HN