RFC: A secure contact import scheme for social networks #4356
Replies: 9 comments 6 replies
|
The phone number recycling algorithm is unclear. Perhaps the example could be rewritten to use pseudocode sooner in the example and more clearly label phone numbers for account A, B, and C and which is the mutual contact (and what the expected failure would look like without the mitigation). |
|
As an overall comment on the RFC: I don't feel that my phone contacts correspond with my social graph in a meaningful way that I would ever willingly use this feature, much like I never did so on Facebook nor Twitter. As long as this feature remains opt-in (because I would never use it) and no additional enrichment data is stored (e.g. phone contact name to act as a prompt for possible matches) I wouldn't have concerns about the algorithms as described. |
|
Overall comment: There needs to be more of an argument for why this feature should be there let alone prioritized over safety features like better moderation tools for the moderators, privating accounts, or ensuring PDS's can actually fully migrate without being effected by a ban on a different app on the protocol. Right now all I'm hearing is "other apps have it!" but...Facebook and Twitter are not to be emulated, nor trusted. The reason they might have this feature is as suspicious as when a mobile game with obnoxious microtransactions wants you to connect your contact list. They want you to pull as many people as possible in, so they can advertise and scam them. It's never been for valid reasons. Additionally, it's just plain dangerous. The double opt in feature if fine...But can blocked contacts find you? What about when you get your manager's number for work but you've left that job years ago and forgot to remove them from your contacts? What about the dozens of people who may be in your contacts but you only want one or two to be able to find you? This isn't even getting into the risk with abusive ex's. I dunno, I just think at best, this should NOT be priority when so much needs to be fixed particularly regarding moderation tools for the moderators, and at WORST users who may not understand all the risks will find themselves in danger. |
|
The blocked-user safety angle is a big risk factor. I think it needs thought through and explained how that would work in the context of storing (or not) matches to opt'd in users. |
|
How would Bluesky (/could others implementing this approach) reduce the risk of users offering phone numbers of people they never wish to match with? Examples:
Though these risks are in some ways beyond the protocol level, I think it’s wise to have protections in place from “poorly thought through opt-in”, as well as smart/fully considered use. |
|
On Apple platforms, there is a platform-level control that requires you to choose whether you're offering all contacts or selected contacts, which you can see here:
More detail: https://developer.apple.com/documentation/contactsui/contactaccessbutton This is also coming to Android 17: https://www.androidauthority.com/android-17-contacts-picker-rumor-3615741/ I'd recommend Bluesky including a modal prompt to users encouraging them not to use the all contacts option unless they're super certain. |
|
It was unclear to me which of the steps would occur on Bluesky machines, and which would occur on my phone. I assume the final HMAC would need to occur on Bluesky servers, but are all previous steps occurring on the number-proving person’s device? |
|
All the hashing steps would occur on Bluesky machines. Otherwise, a malicious user could submit hashes of arbitrary pairs of phone numbers, bypassing the initial phone number verification step. "prove that a hash combines the user's own phone number with one other phone number" sounds like something that could maybe be achieved via ZK proofs - but I don't know how. A possible improvement would be to pre-hash the contact list numbers individually (not in pairs), on-device. However, the hash function used for that would need to be a) fast enough to run ~hundreds of times on a mobile device b) unsalted. Such a hash would be easily cracked via brute-force and/or rainbow tables, and so provides negligible additional security. That said, it is still something we're considering for the final design. |
This should be highlighted as a compromise route alongside database compromise, then, if the bsky servers are going to temporarily have plaintext copies of all phone entries as well as the user's verified phone number. Thinking about it, the proposal doesn't indicate how a verified phone number would be stored securely in the bsky database such that any future syncs can be done, and that deserves a call-out as well. |
|
It might be worth calling out that it’s easy to remove all your contacts even if you’ve changed number. (Eg. I uploaded contacts, I forgot about Bluesky (!), I changed phone number, I want to stop matching with people. I presume this is trivial “delete all hashes that link to your authenticated DID”) |
|
Programmer feedback: As far as I can see this has nothing to do with the AT but with bsky.app As such, proposed secure storage and double reverse matching algorithm seems to be adequate. Caveat here is that one should have concerns about some future expansions of the service with other AT running nodes/groups that might lead to leaks on their side. However as it is proposed, what I read seems to be reliable and secure enough. User feedback: WTF man? I do not need to find anybody by their phone number and I do definitely not want anybody to find me from my phone number. I have 2140 contacts in my online address book, assuming a one-2-one correspondence, that means there are 2k+ potential bsky users who would be able to find me, if I opt-in (intentionally, unintentionally, erroneously (error part being on bsyk)) I would definitely be in deep shit. |
|
One comment is that the RFC doesn’t factor in area and country codes. I may have stored my friend’s phone number without a country code, or without an area code, or with a leading 00 or +. You’d need to either normalise this or store variants of phone numbers, by stripping area codes. Another concern is even having opted in, there might be people in my contact list I explicitly don’t want to be able to find me, an “advanced feature” which would allow a user to preemptively block someone from discovering their bluesky account would be useful in the interests of safety. |
|
Normalizing phone numbers should go without saying, but it's worth saying and specifying the particular format. Presumably E.164 |
|
Following my first quick read this seems reasonable. I notice you don't explicitly mention a round trip to the user phone number to confirm it - perhaps it goes without saying but I say say it anyway. |
Discussion for https://docs.bsky.app/blog/contact-import-rfc
Note that this mechanism is not a feature of AT protocol itself - it will be a feature of the Bluesky app. However, the approach may also be useful in other non-Bluesky apps.