Can Translucency Save Privacy In the Cloud? 86
MikeatWired writes "Jon Udell writes that when it was recently discovered that some iPhone apps were uploading users' contacts to the cloud, one proposed remedy was to modify iOS to require explicit user approval. But in one typical scenario that's not a choice a user should have to make. A social service that uses contacts to find which of a new user's friends are already members doesn't need cleartext email addresses. If I upload hashes of my contacts, and you upload hashes of yours, the service can match hashes without knowing the email addresses from which they're derived. In the post Hashing for privacy in social apps, Matt Gemmell shows how it can be done." (Read more, below.)
"Why wasn't it? Not for nefarious reasons, Gemmell says, but rather because developers simply weren't aware of the option to uses hashes as a proxy for email addresses. A translucent solution encrypts the sensitive data so that it is hidden even from the operator of the service, while enabling the two parties (parents, babysitters) to rendezvous. How many applications can benefit from translucency? We won't know until we start looking. The translucent approach doesn't lie along the path of least resistance, though. It takes creative thinking and hard work to craft applications that don't unnecessarily require users to disclose, or services to store, personal data. But if you can solve a problem in a translucent way, you should. We can all live without more of those headlines and apologies."
Hash (Score:4, Funny)
Well... mostly on the weekends.
Not gonna happen that way. (Score:4, Insightful)
Hashing is more difficult than not hashing.
Customers are not going to stay away just because your security is atrocious.
So only legislation (or serious liabilty) is left to get this off the ground.
Re:Not gonna happen that way. (Score:5, Interesting)
Re: (Score:1)
All the scare mongering with Facebook has ment that people take notice and think about what they do online.
I think I'm the only one in my family that doesn't have a FB account. When I go down the laundry list of why I don't have one, they shrug their shoulders. When someone posts something - like this twit that posted her friends birth dates and names, there's an initial outcry from a couple of people, but then it died down. The twit said that her page was private and later deleted the information. Everyone concerned thought it was fixed.
Media attention?
I don't see that much reaction against the privacy violatio
Bullshit, market is taking care of this already (Score:5, Insightful)
So only legislation (or serious liabilty) is left to get this off the ground.
You would really rely on legislatures to get the wording of such a law correct and not impede what we can do with mobile devices?
Apple is already changing the system to require user permission when accessing contacts. One of the main apps at fault, Path, has already switched voluntarily to using hashes.
So why go the trouble of crafting regulation to solve a problem taking care of itself already? All you can do is make things more annoying for people.
Re: (Score:2)
So only legislation (or serious liabilty) is left to get this off the ground.
You would really rely on legislatures to get the wording of such a law correct and not impede what we can do with mobile devices?
Who said anything about not impeding? Security does impede what you can do if you care about it at all.
As for the politcos. No, I don't have high hopes. They'll understand and care about these issues shortly after the electorate starts doing so, at best.
Apple is already changing the system to require user permission when accessing contacts. One of the main apps at fault, Path, has already switched voluntarily to using hashes.
So why go the trouble of crafting regulation to solve a problem taking care of itself already? All you can do is make things more annoying for people.
I would argue that Apple is acting more like a legislature here. It's what people are paying them for, after all.
Re:Bullshit, market is taking care of this already (Score:5, Interesting)
The problem isn't taking care of itself. We are seeing Apple, Google and Facebook doing rearguard actions because they are afraid of regulation and lawsuits. Remove that threat, and they'll stop worrying about privacy. It's much better to have a standardized set of laws that spell out the rights of customers than a mish mash of piecemeal solutions that companies have to invent themselves.
Moreover, the Europeans are doing it already, so why not copy^H^H^H harmonize with their laws in America? That'll save American companies a lot of work when they realize that their system must be redesigned anyway if they want European customers.
Not fear of regulation (Score:2)
The problem isn't taking care of itself. We are seeing Apple, Google and Facebook doing rearguard actions because they are afraid of regulation and lawsuits.
Lawsuits perhaps, but they are more afraid of CUSTOMERS. They want to serve CUSTOMERS better (and also avoid lawsuits).
Moreover, the Europeans are doing it already, so why not copy^H^H^H harmonize with their laws in America?
Well that's how we get SOPA. Great plan. Not.
Just because Europeans are willing to submit to tyranny why should the U.S.? Why
Re: (Score:2)
Just because Europeans are willing to submit to tyranny why should the U.S.? Why should anyone?
Let's also bring over the vast array of cameras from the U.K. while w are at it!
We're not the ones submitting to tyranny. Regulation of industry is part of the price we pay for not submitting.
I'll grant you that the Brits seem a bit lax when it comes to protecting themselves from government, though.
Then again, neither do they seem likely to elect quite the same quality of nutters [spreadingsantorum.com] to lead them?
Re: (Score:2)
Well that's how we get SOPA. Great plan. Not.
How exactly did you get from Europe to SOPA? You do know how's sponsoring all that crap? It's the US that has been pressuring Europe to pass those laws, not the other way around.
Let's also bring over the vast array of cameras from the U.K. while w are at it!
Meh, the UK are barely European anyway ;)
Re: (Score:2)
Well, Europe and SOPA can be easily related. We got a SOPA-prototype in Spain, the "Sinde Law". It was approved and started during a change of government, in a very sneaky fashion and after initial resistance when it was attempted to pass for the first time.
Some other reply says that Europeans submit to tyranny...nope, it's imposed on us, that's why it's tyranny!
It might be the US pressuring EU to do this, but I feel like I can rightly blame EU politicians because their will was weak and they submitted way
Re: (Score:2)
Sure, I'm not deflecting the blame from our politicians; no amount of pressure excuses them from enacting terrible laws like those.
I'm just saying that SOPA being pushed through the US Congress had nothing to do with Europe, and all to do with lobbying from their own industries.
Re: (Score:3)
The problem isn't taking care of itself. We are seeing Apple, Google and Facebook doing rearguard actions because they are afraid of regulation and lawsuits.
Lawsuits perhaps, but they are more afraid of CUSTOMERS. They want to serve CUSTOMERS better (and also avoid lawsuits).
There's one small problem there. Who are Google's customers? Who are Facebook's customers? I'll give you a clue: it's not their users, who (by and large) don't pay them any money at all. Their customers are their advertisers, and serving their customers better is usually in direct conflict with preserving the privacy of users.
Re: (Score:2)
The problem isn't taking care of itself. We are seeing Apple, Google and Facebook doing rearguard actions because they are afraid of regulation and lawsuits. Remove that threat, and they'll stop worrying about privacy.
Privacy aside, companies are a lot less afraid of regulation than they say, simply because regulations actually help them in several ways:
1 - The make it difficult for new companies to enter markets because of all the things that must be done, and associated costs, of complying with regulations. This is especially true for internet companies - the more it costs to comply with regulations, the harder it is for a startup to threaten established firms.
2 - Regulations can often provide a shield from lawsuits
Re: (Score:2)
Because they're socialists and communists over there! They can't have any good ideas that don't need to be manipulated, edited, changed, and regurgitated in an "American" version before they can be any good.
What's next? Looking to those damned Canadian socialists for guidance on federal cannabis policy that could lead to a federal medical cannabis regulation? :P
Re: (Score:2)
Re: (Score:2)
The effort to hash and salt contact information to provide a basic level of privacy over cleartext is computationally and programatically inconsequencial. We're locking the screen door, here; not securing Fort Knox.
Re: (Score:2)
You are quite right of course.
Do you think that's going to make it happen?
Re: (Score:2)
More to the point, it's more difficult than not hashing for trivial gain. There's no way the protocol described in the summary could work with salt, so anyone who had any motivation could spend 10 minutes writing a script to build rainbow tables for various combinations of names @gmail, hotmail, etc. and reverse the hash.
I'll start a service of my own (Score:5, Insightful)
Re: (Score:1)
Because of how much more efficient it is to break into an organisation's database of contact hashes, hope like hell the contact hashes are unsalted and then run each of them through your rainbow tables just to get a single email address than it is to write a web crawler in 10 lines of Python which finds emails based on a regex. Your approach is great if you're trying to phish gullible Sony customers but not so great for anything else.
Re: (Score:2)
"they need same hash for same inputs, so no salt"
Unsalted hash sounds unappetizing. I'll take my NewEgg over "Easy" button.
Re: (Score:3)
need to keep it a shared secret between client and server
Two issues. One is that it's the server that you're trying to keep the private information safe from.
The other is that the client is.. a client. Your code is running in an untrusted environment. It is vulnerable. It can be examined and understood. Haven't you heard of reverse engineering?
Re: (Score:3)
58k years is only around $81m on Amazon's compute cloud, and this is highly parallelisable.
Get access to a botnet and it's nearly free. Get access to a thousand Nvidia graphics cards and you can process this in a month.
Not going to work (Score:1)
Uncle Bob 01234 123456
might be smart matched with:
Robert Smith +1 1234 123456
I'll be interested to see the hashing algorithm that will allow the hashes to be matched.
Re: (Score:1)
A setup where uncle bob will only be found if he wants to is not necessarily a step in the wrong direction.
A step backwards to be sure, but that's not always the wrong direction.
Re: (Score:2)
I can see how:
Uncle Bob 01234 123456
might be smart matched with:
Robert Smith +1 1234 123456
Even without a hash you're going to struggle to match those two.There's too much difference even with stuff like soundex() unless you get the geo info so you can turn the "01234 123456" phone number into an international one.
If you get bob.smith@example.com from both as an email address that matches easily.And when you've captured that data item it's only a small step to find that in Google.You can use that matching data item as a tag for all the other stuff you've stolen from the user who has jsut done the
Re: (Score:2)
specification/spesfikSHn/
Noun:
An act of describing or identifying something precisely or of stating a precise requirement.
A detailed description of the design and materials used to make something.
but without all the private data from users (Score:1)
apps wouldn't be free - 99c
Re: (Score:2)
Nevermind, we'll just blame Micro$oft for making your computer slow
More seriously. What are you planning to match all that to? Don't you think just headers/filenames will do?
Re: (Score:1)
salting is only a small advantage. think of a salt-hashed telephone-number. a brute-force attack over all possible numbers (only the valid ones for the region where the contact is from) is done fastly. Okay, its too much when you want to crack each one in this way, but if you're only interested in a few special ones, it can be done.
How do you make money? (Score:2)
How do you make money from free cloud apps, if it's not by selling the private information you extract from your customers files? I thought the cloud efficiency (good service at low cost) came by design from taping into privacy.
Interesting, But Do Companies Care? (Score:2)
still no privacy (Score:3, Informative)
some things to consider:
- when you hash a telephone number, a rainbowtable is easily generated
- even when you have ids, which are real pseudonyms, no option to crack them, then you can correlate "ah, user X knows Y, which is known by Z, too".
So uploading contact data is exposing private things, even when the nodes are ano(pseudo)nymous and only the edges of the social graph are known.
Re: (Score:2)
- when you hash a telephone number, a rainbowtable is easily generated
That's where salts are useful. When you MD5 or SHA1, add a random-but-constant string at the beginning of the to-be-hashed string. Rainbow tables will be far mor difficult, if not impossible. Instead of MD5'ing "slashdot", MD5 "f8ds9a03421314159_$!1337_jc0wikislashdot".
Re: (Score:2, Insightful)
... Which defeats the purpose that is being able to find someone by said hash.
Re: (Score:1)
Re: (Score:2)
when you hash a telephone number, a rainbowtable is easily generated
Two words: salt.
Re: (Score:1)
cannot be used.
imagine, you have a salted hash with random salt for each hash (if the salt stays the same, the rainbow-table is easily generated). Now your phone hashes some telephone-number with a random salt. Try to find it in the db of numbers hashed with random salts. no chance, because a different salt is used.
Re: (Score:2)
Ah, good point. I had thought about that one carefully enough.
Wrong problem (Score:2)
The issue is not how companies that want to preserve privacy can do so. They will find a way and the described solution is rather obvious. The question is how to stop companies that do not care about your privacy at all and _want_ to upload all your data to their own servers.
Re: (Score:1)
Yes, but only if you use a PNG (Score:2)
The alpha-channel in JPEG sucks.
I doubt it (Score:1)
Maybe they knew, maybe they didn't know about this translucency method, but in the end one thing I am fairly certain of is that that "they" want all your information, it's how "they" get valid emails, make money and build profiles.
If your information is obfuscated in any way the reliability of what they want to do is diminished and therefore not worth as much.
They don't only want to know existing contacts... (Score:2)
Why should they? (Score:1)
If Iphone users cared about their privacy, they wouldn't be Iphone users.
And don't tell me companies don't use hashing because they don't know how to implement it. This is deliberate. They want your contacts. Data = money, personal data of real people plus who-knows-whom = more money.
Re: (Score:2)
If Iphone users cared about their privacy, they wouldn't be Iphone users.
this is one of the most insightful comments I've seen on /. for a long time.
why did you post this as ac? i would have modded you up for sure.
Completely wrong (Score:2)
It is time to stop worrying about the 10-20 companies who make their money from violating privacy and selling data to advertisers. Just because Google and Facebook have become popular with this business model during the past decade doesn't mean that we should give up century old principles and that we have to protect this business model in all eternity.
The vast majority of all companies can or could do respectable business without violating privacy. Notwithstanding the software patent nightmare, it is possi
Re: (Score:3)
It is time to stop worrying about the 10-20 companies who make their money from violating privacy and selling data to advertisers. Just because Google and Facebook have become popular with this business model during the past decade doesn't mean that we should give up century old principles and that we have to protect this business model in all eternity. [---] It's time to give the power back to real companies, who actually offer real products and who are interested in sustainable business based on making their customers happy.
If we're going to redistribute power anyway, why not take it back? People instead of corporations, open protocols instead of apps, decentralized instead of centralized solutions?
passwords too (Score:4, Interesting)
Re: (Score:1)
its still just making the rainbowtable bigger. its a table over (telephonnumbers x salts), which is n times m when there are n possible phone-numbers and m possible salts. depending on length of the salt (and charset) its possible with a big HDD.
Re: (Score:1)
Re: (Score:1)
thats the other way round. there the site knows the plaintext password and hashes it with a different salt on each authentication, challenging the user to know the hash of password+provided_salt, too.
Re: (Score:1)
Re: (Score:1)
I care about my bank account password, and, trust me, that is not used anywhere else.
cloud is still just a mainframe (Score:2)
Very clever... but not as useful as it appears (Score:2)
A bad actor could rather easily convert the hashes back to email addresses. All he needs is a good source of email addresses (readily available from the dirtbags who supply spammers), which he can then hash and index. Takes some computer resources, that's all.
A good actor need merely not misuse the email addresses in the first place.
Re: (Score:1)
Bad programmers making novice mistakes (Score:3)
The root of all these problems is that any idiot with a text editor can call themselves a "web developer" these days. The barrier to entry is extremely low, and the result is a very large group of people who have no forethought about what they're actually doing. They take the most naïve path from start to finish and end up creating all these security and privacy holes real programmers have long since learned to avoid.
Case in point: people still store passwords and credit card info in plaintext, typically behind sloppy PHP or Ruby scripts that are vulnerable to SQL injection. Feed that stolen data into a simple script that tests the passwords against a handful of popular services like GMail, Facebook, Hotmail, Paypal etc. Within minutes, you have a few dozen accounts ready to be abused all over the web without the user's knowledge - all because of one idiot who didn't know how to protect his users' info.
All this talk of securing the cloud is futile. It's like putting a dozen deadbolts on your front door, then leaving a spare set of keys under your neighbour's welcome mat.
Re: (Score:3, Interesting)
No, it won't work. Here's an excellent paper why. (Score:2)
It won't work: explained (Score:1)
This is a temporary solution that simply will not work for any large cloud service of significant size. I do program with hashing and other encryption mechanisms and I do know exactly what hashing does.
Hashing is a 1 to 1 algorith. So given any single input (like an email address), the hash output will remain the same. So any hash value can quickly be verified to match a known email address by simply running the hashing algorithm on a known email address and matching it to the existing hash. If you get a ma