The Difficulty Of Private Contact Discovery • Hacker News Board

Re: The Difficulty Of Private Contact Discovery

#71

Post by mtrimpe » Sat, Jan 04, 2014, 12:36 PM UTC

stormbrew wrote: post #55

mtrimpe wrote: post #15

Earlier quoted context omitted.

Properly implemented rate limiting would be a better way to achieve that though. That is were the 'blinding signature' part comes in: to give the server the possibility to intelligently rate limit.

Rate limiting is a terrible solution to this sort of problem IMO. It just forces the attacker to be patient, but they will eventually get what they want, which is name/phone number pairs of the entire numeric space of phone numbers. His solution is problematic because it distributes the burdain to the user, and anyone who's gotten massive numbers of friend requests on a chat service can attest to how unfriendly that…

We're not necessarily talking about sharing contact information; all we're talking about here is an acknowledgement of existence.

Given that context, due to the nature of the problem, rate limiting is by definition the -only- solution to the problem (if I'm understanding the problem correctly.)

You do have a point that perhaps the question we should be asking should be 'how do we detect mutual connections,' but that's another story altogether.

Re: The Difficulty Of Private Contact Discovery

#72

Post by stormbrew » Sat, Jan 04, 2014, 12:51 PM UTC

mtrimpe wrote: post #71

stormbrew wrote: post #55

Earlier quoted context omitted.

Rate limiting is a terrible solution to this sort of problem IMO. It just forces the attacker to be patient, but they will eventually get what they want, which is name/phone number pairs of the entire numeric space of phone numbers. His solution is problematic because it distributes the burdain to the user, and anyone who's gotten massive numbers of friend requests on a chat service can attest to how unfriendly that…

We're not necessarily talking about sharing contact information; all we're talking about here is an acknowledgement of existence. Given that context, due to the nature of the problem, rate limiting is by definition the -only- solution to the problem (if I'm understanding the problem correctly.) You do have a point that perhaps the question we should be asking should be 'how do we detect mutual connections,' but that'…

Under what circumstances do I want someone who I have not even enough interest in to put in my phone's dialer to be able to ping my phone number and get my name back?

The question of whether services should even be DOING this kind of open book "does this phone number have a user attached and what is their name?" query is more fundamental than any other question, imo. It's not another story, it's a skipped first story.

Re: The Difficulty Of Private Contact Discovery

#73

Post by stormbrew » Sat, Jan 04, 2014, 12:54 PM UTC

ash wrote: post #12

maxerickson wrote: post #3

In a similar discussion, I said something about hashing phone number pairs. The graph has a lot more edges than nodes. Still doesn't stop someone from attacking a single number though.

Interesting idea. But the address book "friends" must be mutual for this to work. You would miss those contacts that don't have you in the their contacts.

And this is bad because...?

If they don't have you in their contacts it's probably for a reason. A lot of times (not all, but more than enough) it's probably because they've basically stalked you.

Re: The Difficulty Of Private Contact Discovery

#74

Post by maxerickson » Sat, Jan 04, 2014, 4:08 PM UTC

napoleond wrote: post #65

ash wrote: post #12

Earlier quoted context omitted.

Interesting idea. But the address book "friends" must be mutual for this to work. You would miss those contacts that don't have you in the their contacts.

It seems to me like that fits somewhere in the space between "small compromise" and "bonus feature". This idea seems like a very good practical solution--I'm very curious what moxie's take on it would be.

If the design goal is to not trust the server, it is still pretty useless.

Say you make the hash take 1 second on a phone. Without trying to really pin it down, I think an attacker would be able to do an area code in hours with minimal investment. They could do the entire phone number space fairly quickly for a modest investment.

(My attacker there is focusing on the pairs for one number. The area code part comes in because phone numbers really are lumpy like that.)

Re: The Difficulty Of Private Contact Discovery

#75

Post by svasan » Sat, Jan 04, 2014, 4:19 PM UTC

danielrhodes wrote: post #67

MagicWishMonkey wrote: post #19

This is great until you realize the average address book is a disgusting mess of spelling errors, wrong values in wrong fields, punctuation in places where punctuation isn't necessary (commas in phone number fields, digits in name fields, etc.) The only field that might be fairly consistent is email address and even that is no guarantee. Sure, it's possible to clean up a contact before hashing, but when you consider…

This times a million. Phone numbers in particular can be a horrid mess to deal with. Some decent libraries have come out to normalize them, but in general it remains difficult. For example: 013811234 +88-1-3811234 3811234 0118813811234 008813811234 are all be the same number. To hash them, you could naively just strip off the area codes and country codes, but that is only if you can know ahead of time they are indeed…

Just a thought - Why not reverse the phone number string and if there is a match in the first N digits of all the above phone numbers, then classify these as the same phone number? N would vary from country to country, no doubt. The intermediate characters like {,, +, -, .,} could also be stripped out from the phone number string to make the original problem less complex.

Re: The Difficulty Of Private Contact Discovery

#76

Post by thatthatis » Sun, Jan 05, 2014, 4:07 AM UTC

maxerickson wrote: post #3

In a similar discussion, I said something about hashing phone number pairs. The graph has a lot more edges than nodes. Still doesn't stop someone from attacking a single number though.

I you treat a pair as a one-direction edge, and only match when you have an edge in both directions, then you could add text message verification to prevent people from both impersonating others and extracting additional information out of the service. It would be reasonably trivial then to notify clients when a new match comes in.

This approach seems to require that you trust the server.