w3c
Consider contact API that does not reveal contact info to the website
I would like to suggest to consider rethinking contacts API more in the form of https://wicg.github.io/web-share/ so that actual contact information is not revealed to the websites, but instead site is allowed to send some data via requested medium (email / sms) to the chosen contact(s).
I think this is a good suggestion that would address some use cases, but not the ones we're trying to address with this proposal. It's important for sites to be able to retrieve some of the contact information in case there's a relationship to establish (e.g. a social network), or when it's the site that provides the communication mechanism (e.g. an e-mail client) in the first place.
Making sure that users don't accidentally share information they didn't mean to share is a key concern for us (Chrome). We plan to experiment with ways of clarifying to the user what will be shared through the user interface.
I think this is a good suggestion that would address some use cases, but not the ones we're trying to address with this proposal. It's important for sites to be able to retrieve some of the contact information in case there's a relationship to establish (e.g. a social network), or when it's the site that provides the communication mechanism (e.g. an e-mail client) in the first place.
Would it make sense to try and address each use case on individual bases, otherwise I fear we'll end up with all or nothing scenario. Meaning you either share all info and get service or do not share and get nothing back.
Making sure that users don't accidentally share information they didn't mean to share is a key concern for us (Chrome). We plan to experiment with ways of clarifying to the user what will be shared through the user interface.
Explaining what is being shared is important, however if only options are to share or not it's going to be not much different from "Agree to our terms of service". That is to say that I think it would be tremendously more useful to have an API that allows user to choose whether to reveal contact info or keep it anonymous (which might mean providing some generate info instead) that actually gives user choice between remaining anonymous or public vs choice of getting service or not.
For example selected contacts could be opaque objects that would have methods to message / email or mention letting user to choose medium. Additionally it might support an option to email / mention with provided medium (itself) prompting user and letting her / him to accept the medium (revealing email / handle to it) or override and choose preferred medium instead.
In fact for some open protocols like email it might be even reasonable to provide oneoff proxy addresses instead of revealing that information.
Contact Picker API is great !
What about going further ?
Contact Discover API
- Ask & Get user's contacts hashed {emails, phones} list.
- So we can compare with PWA's hashed {emails, phones} list.
- If (one or more matches) { Display("Hey! You might know all these people. Do you want to send them a friend request in 1 tap ?") }
Ask & Get user's contacts hashed {emails, phones} list. So we can compare with PWA's hashed {emails, phones} list. If (one or more matches) { Display("Hey! You might know all these people. Do you want to send them a friend request in 1 tap ?") }
This only seems like a good idea on the first glance. On the second glance, (oftentimes 10-digit) phone numbers (and—lesser so, but in practice still—email addresses) are finite, so hashes can be easily pre-calculated.
There are two papers I know of that discuss how this can still be done:
- PIR-PSI: Scaling Private Contact Discovery by Demmler et al. (older)
- Mobile Private Contact Discovery at Scale by Kales et al. (newer)
(oftentimes 10-digit) phone numbers (and—lesser so, but in practice still—email addresses) are finite, so hashes can be easily pre-calculated.
In the Contact Discover API proposal above, hashing was not intended to preserve privacy, but was rather intended to be a convenient lookup key, hiding streamlining and formatting work done upstream by the browser (lowercase, remove dots/spaces, ...etc)
Of course, you can guess a phone number from a hash.
You can even guess a phone number without a hash.
There are even phone number guessing games that currently take place in France, called "Voisins de numero" (Phone number neightboring) https://www.lci.fr/high-tech/et-vous-avez-vous-contacte-votre-voisin-de-numero-ce-petit-jeu-qui-enflamme-twitter-voisindenumero-2128917.html
You can even write a program to generate all phone numbers in the world. Generating phone numbers is far more efficient than asking them to users.
Thanksfully, there are laws against robotcallers.
This not about guessing phones numbers. Because phones numbers are guessable by essence, by construct.
Marketers will tell : A phone number itself has no value. A phone number has a value only if it can be associated with a name.
So if a user leaks phones numbers to a PWA, whether hashed or not hashed, there is no problem. There will be no more threat/annoyance than the current status quo.
These phone numbers will take value only if the PWA is able to associate some of them to an identity coming from its own database.
On PWA's side : The naive approach would be to perform a multi-get from a store, where there is an indexed collection of { phoneOrEmailHash : PWAUserId } It is easily doable with Algolia or Firestore. Then, filter unique PWAUserId (distinct) Then, on user tap, send all friends requests to these PWAUserId list. Names are never leaked.
If there is some apprehension that phoneOrEmailHash might be exposed on Algolia (public access, less secured than Firestore), it is possible to apply some salting/cryptographic operation before the multi-get, so the store would be an indexed collection of { myCustomHash : PWAUserId }, but still, as names are never leaked, it might not even be necessary.
So if a user leaks phones numbers to a PWA, whether hashed or not hashed, there is no problem.
Would you want social-network.example.com to know that you have the French number 01 45 91 55 93 in your address book? And would you want to be friend-matched by an algorithm with someone who also happens to have that number in their address book?
Would you want social-network.example.com to know that you have the French number 01 45 91 55 93 in your address book?
It can be solved by prompting a user permission.
Scenario :
- Page expose consequences on sharing data
- User clicks on a button "Find friends"
- User permission prompt
- Accept
- Access to the API
would you want to be friend-matched by an algorithm with someone who also happens to have that number in their address book?
Initially I was aiming for direct friends. Common friends (aka networking) is also a valid use case.
Example of display :
Here are people you might know: (Because they are both in your contact book and in the PWA) ...and you have these common friends ! (Because we made a double lookup - 1st degre of separation)
Well, usage depends on the product.
Ex 1 : LinkedIn / Networking apps It might make sense at some point (1st degree of separation) or not at all (more than 1st degree of separation often tends to be irrelevant).
Ex 2 : Tinder / Dating apps Consequences in some countries, if attached to sensitive data, and sensitive data disclosed. (xx% of your contacts are related to a certain community = clustering)
Ex 3 : Telegram / Politics & Freedom of speech apps Idem.
I'll say usage depends on :
- PWA business (numbers of lookups / degrees of separation)
- PWA security (ACL, pseudonymization, encryption ... are legal duty through GDPR)
- PWA informs users on consequences of sharing data (legal duty through GDPR)
- User permission (absolutely mandatory)
A Contact Discover API would not be the source of binding identities to phone numbers thus leaking private informations.
Private information leaking already happens every day because users blindly/willingly register to products that are unprotected or literally sell their identities and make business of them. But in exchange, users have access to empowering tools at nearly zero cost. It is part of the business model.
I like the motivation behind the Contact Discover API, but given that the hashing can be reversed, it would be no different than using the Contact Picker API directly.
Private information leaking already happens every day because users blindly/willingly register to products that are unprotected or literally sell their identities and make business of them. But in exchange, users have access to empowering tools at nearly zero cost. It is part of the business model.
Yes users are already being exploited, that doesn’t mean that should be made easier