Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Can Translucency Save Privacy In the Cloud?

timothy posted more than 2 years ago | from the big-ol'-cumulus-clouds-maybe dept.

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

cancel ×

86 comments

Sorry! There are no comments related to the filter you selected.

Hash (4, Funny)

busyqth (2566075) | more than 2 years ago | (#39459411)

All my contacts upload their hash regularly.
Well... mostly on the weekends.

Re:Hash (-1)

Anonymous Coward | more than 2 years ago | (#39459907)

You are venturing forth through the savannah. On the horizon, the sun hangs, bathing everything in a warm, golden glow. You feel relieved that the day is nearly done and welcome the respite that you will soon have from the blistering heat. As you continue on, the path you are walking upon becomes ever more overgrown until it finally disappears in the thick, tell grass.

Will you set up camp here or press onward?

> press onward

You press onward, hoping to get as much travel into the day as possible, for it will be nightfall soon and it will be impossible to navigate the plains, especially with the path enshrouded by the dense foliage. After hiking approximately two more kilometres, you come across an old, dead tree and decide that this will be a good place to set up camp. The tree would be useful, not only for the lean-to, but also because the dried branches would make for excellent firewood.

Just at that moment you hear rustling from behind you. Turning around, you see a NEGROID WARRIOR jump out from behind the brush. What will you do?

> look at negroid warrior

The NEGROID WARRIOR stands before you, his tall, dark body adorned with a large necklace made of various animal teeth. He is clothed in only an animal skin loincloth and he is carrying a sharp, wooden spear. He glares at you menacingly.

> inventory

You are carrying:

Blanket Bottle of beer (40oz) Box of matches
Canvas tarpaulin
Canteen of water
Penknife
Short rope

> give forty to negroid warrior

The NEGROID WARRIOR quickly snaps up the bottle of smooth, refreshing beer and drinks it down greedily. Casting the empty bottle to the ground, he looks to you and speaks, "It works every time!", before running off into the cool twilight of the open plain.

Re:Hash (0)

Anonymous Coward | more than 2 years ago | (#39460063)

bla bla...NEGROID WARRIOR...bla bla bla

Seriously man that's not even that racist, try harder.

Re:Hash (0)

Anonymous Coward | more than 2 years ago | (#39460133)

It wasn't meant to be racist.

Not gonna happen that way. (4, Insightful)

Jens Egon (947467) | more than 2 years ago | (#39459431)

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. (4, Interesting)

MoonFog (586818) | more than 2 years ago | (#39459459)

Actually, I find that people are starting to care a lot more these days. All the scare mongering with Facebook has ment that people take notice and think about what they do online. A bad security record gets more attention in the media as well so to me it's not so clear cut anymore, people do care and you can't get away with everything.

Re:Not gonna happen that way. (1)

Anonymous Coward | more than 2 years ago | (#39459731)

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 violations. There was a larger consumer backlash to NetFlix' split of DVDs and streaming than there ever was with FB's privacy gaffs. There wasn't this mass exodus from FB - folks stuck with them.

Bullshit, market is taking care of this already (4, Insightful)

SuperKendall (25149) | more than 2 years ago | (#39459477)

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:Bullshit, market is taking care of this already (1)

Jens Egon (947467) | more than 2 years ago | (#39459535)

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 (4, Interesting)

martin-boundary (547041) | more than 2 years ago | (#39459583)

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.

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 (1)

SuperKendall (25149) | more than 2 years ago | (#39459733)

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 should anyone?

Let's also bring over the vast array of cameras from the U.K. while w are at it! All of the security nazis wet dreams can come true across the globe, and when you cough I can find out from my command center two continents away!

Re:Not fear of regulation (1)

Jens Egon (947467) | more than 2 years ago | (#39459785)

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:Not fear of regulation (1)

icebraining (1313345) | more than 2 years ago | (#39459973)

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:Not fear of regulation (1)

Windwraith (932426) | more than 2 years ago | (#39460111)

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

Re:Not fear of regulation (1)

icebraining (1313345) | more than 2 years ago | (#39460271)

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:Not fear of regulation (2)

psmears (629712) | more than 2 years ago | (#39462327)

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:Bullshit, market is taking care of this already (1)

Registered Coward v2 (447531) | more than 2 years ago | (#39459851)

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 by giving companies the argument that the government has set the standards for required conduct and they've complied with them. Whether it works is another thing but it's still appoint in their favor.

3 - Regulations can also be used to limit what they need to do - whether it's revealing how the use data, what data they've collected, etc.

Re:Bullshit, market is taking care of this already (1)

msobkow (48369) | more than 2 years ago | (#39460707)

why not harmonize with their [European] laws in America?

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:Bullshit, market is taking care of this already (1)

JaredOfEuropa (526365) | more than 2 years ago | (#39461425)

Is it taking care of itself? Suppose I install a Facebook app (fat chance, but just suppose). My iPhone asks me if I allow the app to access my contact list. Sure, I say... to check if any of my contacts are also my FB friends, or for any other reason that makes my life easier. But not to collect a list of my contacts on the FB server even if they are not my friends, or to sell this data to 3rd parties. There are many apps that have both legitimate and nefarious reasons for accessing your personal data, and Apple's solution does not take the distinction into account.

I recently heard a talk from a guy proposing a system where we can not only specify what data can be accessed by each vendor, but also specify what they can use it for. Of course, enforcing that is a whole different matter; you'll need a legal framework and even then you have no guarantee they'll misuse your data on the sly, but it's better than nothing (which is what we have now).

Re:Not gonna happen that way. (0)

Anonymous Coward | more than 2 years ago | (#39459549)

Customers are not going to stay away just because your security is atrocious

you mean: customers are not going to stay away because they're too dumb to know different.

Re:Not gonna happen that way. (1)

stating_the_obvious (1340413) | more than 2 years ago | (#39460135)

Privacy /= security.

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:Not gonna happen that way. (1)

Jens Egon (947467) | more than 2 years ago | (#39460865)

You are quite right of course.

Do you think that's going to make it happen?

Re:Not gonna happen that way. (0)

Anonymous Coward | more than 2 years ago | (#39461151)

Your post advocates a

( ) technical (X) legislative ( ) market-based ( ) vigilante

approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

(X) Spammers can easily use it to harvest email addresses
(X) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
(X) It will stop spam for two weeks and then we'll be stuck with it
(X) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
(X) Requires too much cooperation from spammers
(X) Requires immediate total cooperation from everybody at once
(X) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business

Specifically, your plan fails to account for

( ) Laws expressly prohibiting it
(X) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
(X) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
(X) Huge existing software investment in SMTP
(X) Susceptibility of protocols other than SMTP to attack
(X) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
(X) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook

and the following philosophical objections may also apply:

( ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
(X) SMTP headers should not be the subject of legislation
( ) Blacklists suck
(X) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
(X) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough

Furthermore, this is what I think about you:

(X) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!

Re:Not gonna happen that way. (1)

pjt33 (739471) | more than 2 years ago | (#39462221)

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 (4, Insightful)

gnapster (1401889) | more than 2 years ago | (#39459441)

Gonna start generating the contact-data rainbow tables right now!

Re:I'll start a service of my own (-1)

Anonymous Coward | more than 2 years ago | (#39459523)

Gonna start generating the contact-data rainbow tables right now!

Sorry, with IP laws the way they are, expect to be sued by Skittles and every gay pride organization out there.

Then again, I'm sure there are a few gay folks who use ,"Come! Taste the Rainbow!" as a pickup line all the time and I haven't heard Skittles suing over that, so you may be in the clear.

Re:I'll start a service of my own (1)

qxcv (2422318) | more than 2 years ago | (#39459591)

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:I'll start a service of my own (0)

Anonymous Coward | more than 2 years ago | (#39459621)

Salting gives different hashes for same inputs by adding a random constant. Here they're looking for matching contacts, so they need same hash for same inputs, so no salt.

Anyways, the outrage was not because someone broke into organisation's database, the problem was that organisation collected the data in the first place.

Hashing helps only marginally against that. Most emails are extracted trivially.

See, if one John Smith, DoB 1989-03-14 registers at the service and his e-mail hash is ae0af6f4002cea6664d5ede4c440fd516ef93a52, there's good chance that it matches (j(ohn)?[-._]?)?smith((19)?89)?@(gmail|hotmail)\.com

Re:I'll start a service of my own (1)

Green Salad (705185) | more than 2 years ago | (#39459689)

"they need same hash for same inputs, so no salt"

Unsalted hash sounds unappetizing. I'll take my NewEgg over "Easy" button.

Re:I'll start a service of my own (0)

Anonymous Coward | more than 2 years ago | (#39459707)

No salt, no, but the structure of the data that goes into the hash may be more complex than a mere hash over the email address. The security then banks on that structure being unknown to outsiders. You can make that structure arbitrarily complex, but need to keep it a shared secret between client and server.

Re:I'll start a service of my own (2)

Cederic (9623) | more than 2 years ago | (#39460089)

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:I'll start a service of my own (0)

Anonymous Coward | more than 2 years ago | (#39459811)

disclaimer... The numbers in this comment are not to be seen as an exact fact... Some numbers might be higher and some lower... it's just to get a pointer to the amount of work needed to be done.

Should not really be a problem..

The hash-database does not really matter of they get a hands on, or if they are able to build rainbow-tables..

For example do a hash on this:
John Doe someone23@gmail.com

You have first name and last name ~ so lets say there are (arbitrary numbers, no idea how accurate they are) 1000 different first names and 1000 different last names. This will then be 1000000 combinations, but in really probably quite a bit higher. Then you have the actual mailaddress. avarage gutfeeling says somewhere like 8-10 characters. sometimes with a dot in the middle.. so lets say 24^8 110075314176 and then you have different hosts, but that adds quite a small number so lets say 5000 domain-names. 110075314176 * 50 = 5503765708800. So for each tried mail-address you would then have to test 1000000 names ie 5503765708800 * 1000000 = 5503765708800000000

Generating a rainbow-table with 5503765708800000000 combinations (with the above values) would be something around 18 + hash-lenght. For sha512 it would mean 18 + 64 bytes per entry = 410462951 Petabytes for a full rainbow-table..

Just to generate this table would take a long time.. From a few web-searches sha512 comes back around 99MiB/s so around so ie ~3-4M hash-generations per second.. ie 5503765708800000000 / 3M ~ 58174 years..

Re:I'll start a service of my own (2)

Cederic (9623) | more than 2 years ago | (#39460163)

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 (1)

sproot (1029676) | more than 2 years ago | (#39459471)

I can see how:
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:Not going to work (1)

Jens Egon (947467) | more than 2 years ago | (#39459491)

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:Not going to work (1)

Dark$ide (732508) | more than 2 years ago | (#39459647)

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 click through on the EULA.

The EU has some much stronger laws on privacy which we have in the UK. I'd love to see what the UK's Info Commision make of the class action against Google, Instagram, Gowalla and others.

Re:Not going to work (1)

way2trivial (601132) | more than 2 years ago | (#39459661)

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 (1)

Anonymous Coward | more than 2 years ago | (#39459499)

apps wouldn't be free - 99c

Honestly (-1, Offtopic)

Osgeld (1900440) | more than 2 years ago | (#39459503)

protecting against piracy in this day and age, is more harmful than pirating

Its not that they were not aware, they were under severe pressure to fight a never ending loosing battle by management overlords who would rather stab their mother in the tit, rather than spend a buck figuring out how to do it right

Congratulations! (0)

Anonymous Coward | more than 2 years ago | (#39459567)

You've unlocked 3rd level achievement in "LOL, Didn't Read!" tier: "Didn't Read The Fucking Title"

Ok but what about my big files? (-1)

Anonymous Coward | more than 2 years ago | (#39459561)

Hashing is fine for indexes or small strings in a database, but what about my huge email inbox or my cloud based home folder with all my private files? Hashing is a bit CPU intensive (read expensive) for that.

Re:Ok but what about my big files? (1)

Jens Egon (947467) | more than 2 years ago | (#39459581)

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?

Wait, what. (0)

Anonymous Coward | more than 2 years ago | (#39459585)

a) There's no salting here - you're looking for matches, after all - so reversing numbers is trivial and reversing e-mails is much easier than reversing unsalted password hashes, as entropy is much lower.

b) And even without reversing you can still build relationship graphs.

So, how exactly does this help privacy?

Re:Wait, what. (1)

allo (1728082) | more than 2 years ago | (#39459669)

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? (2)

lorinc (2470890) | more than 2 years ago | (#39459609)

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? (1)

TheGreatDonkey (779189) | more than 2 years ago | (#39459635)

Almost yearly, I (as do most Americans) get a small little statement/disclaimer entitled "Notice of Disclosures" or something to that affect from various banking, insurance, and other types of institutions I regularly do business with. I believe the only reason they send this is by legal requirement, and it tells me all of the different bits of information they have on me and what they do with it/how they resell it, or excuse me, "share it with valued business partners." Some things I can opt out of, which I eagerly do, while others I simply do not have that option. I've become jaded enough to the point that I am under the impression much of this information is more valuable than my "core" business, such as bank seeing my regular spending habits as well as able to speculate at my income by way of direct deposit tracking. This sort of thing marketers salivate over.

For online companies such as Facebook, the model is hardly different. For companies that give away applications for your tablet or only charge you a small amount of money, this can be an appealing revenue source, whether as a secondary one beyond the $1 they charge you or even the primary one.

Given all this, I tend to question that when building a product such as this, I have a hard time believing Path or any similar companies even remotely care to try and NOT see your information since it blocks them from such sources. Only when the media yanks the covers off do things get more interesting. This lets them assemble a web of contacts which has value, whether for immediate return or as an "asset" for the organization should they ever sell it (and revise their privacy notices).

Lets see how things go once the dust settles and whether they have committed to any of these things.

still no privacy (3, Informative)

allo (1728082) | more than 2 years ago | (#39459663)

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:still no privacy (1)

jcreus (2547928) | more than 2 years ago | (#39459833)

- 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:still no privacy (2, Insightful)

Anonymous Coward | more than 2 years ago | (#39459909)

... Which defeats the purpose that is being able to find someone by said hash.

Re:still no privacy (1)

sdk4777 (1013597) | more than 2 years ago | (#39459887)

What is this, everybody talking about telephone numbers, hash and rainbows?

Re:still no privacy (1)

DriedClexler (814907) | more than 2 years ago | (#39464613)

when you hash a telephone number, a rainbowtable is easily generated

Two words: salt.

Re:still no privacy (1)

allo (1728082) | more than 2 years ago | (#39466779)

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:still no privacy (1)

DriedClexler (814907) | more than 2 years ago | (#39470443)

Ah, good point. I had thought about that one carefully enough.

Wrong problem (1)

gweihir (88907) | more than 2 years ago | (#39459667)

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.

known plaintext attack (1)

tirnacopu (732831) | more than 2 years ago | (#39459691)

Once a provider has a large enough db, they can look for firstname.lastname@gmail.com or, knowing from the contacts distribution the region and language of the users, something like @free.fr or @yahoo.co.jp

Yes, but only if you use a PNG (1)

sl4shd0rk (755837) | more than 2 years ago | (#39459763)

The alpha-channel in JPEG sucks.

Re:Yes, but only if you use a PNG (0)

Anonymous Coward | more than 2 years ago | (#39459949)

I thought we weren't allowed to talk about JPEG's alpha channel... shhht.

I doubt it (1)

koan (80826) | more than 2 years ago | (#39459801)

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.

Hashing doesn't work. (0)

Anonymous Coward | more than 2 years ago | (#39459913)

Especially if they are passed in the clear.

All that has to be done is record lots of hashes from as many phones as possible.

then from a single phone you identify all the hashes. From those hashes you have a phonehash list, which can identify those phones that have missinge elements - yes there will be some duplicates.

All that is necessary then is to go to the server to identify which hash is the owners identification equivalent.

This is an aggregation attack - and it works to identify each person, and without knowing the data that was hashed, but deriving that data from the hash and external information.

They don't only want to know existing contacts... (1)

Lazy Jones (8403) | more than 2 years ago | (#39459963)

Of course they will want to spam people who haven't registered with their "social" service yet, so they need to harvest plaintext e-mail addresses / names and put the blame on you when they send them a spammy invitation. Remember, this is the "you are the product" market, practical solutions are whatever brings in more users/cash, not things that protect privacy as much as possible ...

Why should they? (1)

Anonymous Coward | more than 2 years ago | (#39459975)

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:Why should they? (1)

MadMaverick9 (1470565) | more than 2 years ago | (#39464383)

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.

Why would they? (0)

Anonymous Coward | more than 2 years ago | (#39459985)

It's not that the developer was too overworked or too stupid to come up with a hashing scheme. Quite the opposite. Often these applications exist only for fishing user data. The solution is to assume that all applications are vile and to limit their access to user data the same way they are denied access to other resources.

Completely wrong (1)

aaaaaaargh! (1150173) | more than 2 years ago | (#39460031)

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 possible to make products and sell them to customers to the satisfaction of both parties. It is ridiculous how very few companies, which only have become global players after stockholders have artificially inflated their values, can steer the public discussion about what should be possible for them and what not. We need laws not only to protect our privacy and stop parasitic, advertising-based business models, but also to put an end to frivolous EULAs and the copyright, trademark, and patent nonsense.

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. There are plenty of those, and it's pissing me off that a few black sheeps get all the media attention.

Yours sincerely,

aaaaaaargh!
Slashdot Ranter

Re:Completely wrong (2)

jgrahn (181062) | more than 2 years ago | (#39460357)

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?

A salt can trivially be added... (0)

Anonymous Coward | more than 2 years ago | (#39460049)

Simply generate a (random) salt everytime you want to find common adresses between you and the other person and then send that salt to the other person (through the centralized server). All the server sees here is the salt: the server cannot use rainbow tables.

Then both you and your correspondent send your address book encrypted with the salt to the server and the server can tell which "friends" you have in common. And the server still doesn't know who is who.

Rainbow tables defeated. Plain and simple.

passwords too (3, Interesting)

mcelrath (8027) | more than 2 years ago | (#39460425)

Why are we not doing this for passwords too? Every site on the internet shouldn't need to store a plaintext password. Does there exist an algorithm by which a site owner could send the salt, the user hashes with his password, and the site owner can tell the password is the same, without actually having the password?

the hashed salt+password becomes the password (0)

Anonymous Coward | more than 2 years ago | (#39460487)

the hashed salt+password becomes the password.

And worse - it is sent in plain text.

And salts do not prevent rainbow tables, they just make them bigger.

To have all possible passwords (8+salt) only requires about 3 GB of data.
Disks are now 3/4 TB in size, and soon will be 8/16 TB.

It would take a fair amount of time to generate a rainbow table, but possible.

Re:the hashed salt+password becomes the password (0)

Anonymous Coward | more than 2 years ago | (#39460761)

For this reason you don't use the same salt for all your users, but a salt which depends on another constant, like the row id. Say salt+id+password. That makes rainbows go away and works without problem as long as your row id are constant (ie. no deletions, only marking rows as not used). Also, nobody tells you your ids have to start at zero or can't put the id several times (id+salt+id+password+id).

Re:the hashed salt+password becomes the password (1)

allo (1728082) | more than 2 years ago | (#39466795)

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:the hashed salt+password becomes the password (1)

darkfeline (1890882) | more than 2 years ago | (#39461681)

Why is it sent in plain text? If you're gonna be sending it in plain text, you might as well send it hashed than send the plain text password in plain text right? Although IMO the best method is for the site to store the salt and hash, the user sends the plaintext password via secure/encrypted connection, and the site checks it. Asking the user to hash something and send that to be checked directly means more work on the user's part, and if someone intercepts that, it's no different from having gotten the plaintext password. More work for little increase in security.

Re:passwords too (0)

Anonymous Coward | more than 2 years ago | (#39460821)

Why are we not doing this for passwords too? Every site on the internet shouldn't need to store a plaintext password. Does there exist an algorithm by which a site owner could send the salt, the user hashes with his password, and the site owner can tell the password is the same, without actually having the password?

This already exists and is in common use; it's called challenge-response authentication.

Re:passwords too (1)

allo (1728082) | more than 2 years ago | (#39466811)

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:passwords too (0)

Anonymous Coward | more than 2 years ago | (#39461911)

It is called OpenID.

Re:passwords too (0)

Anonymous Coward | more than 2 years ago | (#39463075)

First, as a sibling pointed out, the hash becomes the password. This isn't actually entirely worthless: if every site uses a different salt then using the same password at different sites becomes not as bad (although still bad because you can still use a password cracker to recover the original password with enough time). On the other hand, what you describe is called challenge-response authentication and is supported by all web browsers using digest access authentication [wikipedia.org] . It is rarely used because the UI for HTTP logins is awful in all browsers so everyone is used to using web forms for logins. (Actually, I don't know how common this is, but on LiveJournal at least if you have Javascript enabled, it will not send your password and instead perform a challenge-response implemented in Javascript.)

Re:passwords too (1)

peawormsworth (1575267) | more than 2 years ago | (#39467915)

"We" are not doing this for Internet passwords because you are not an Internet programmer. If you were an Internet programmer dealing with user logins and such, you would know that unencrypted plain passwords have been gone for over a decade or more. All login passwords are hashed and salted by default. If not, it is because some unexperienced programmer decided to "write their own" without a proper understanding of basic password protection. I have been on lots of servers and I cant recall the last time I actually "saw" a password. That said... I have seen passwords that when we are dumping data to logs during testing. I will tell you that pretty much everyone uses horific passwords and those passwords often match the password to their email account. The biggest problem with user/password systems online is that we still allow users to select the passwords. The biggest security hole in online authentication is YOU. Think about it... I bet the same password you use here to log into slashdot is the same password you use at some other site. And if not YOU... then YOU the next reader.

Re:passwords too (1)

randyleepublic (1286320) | more than 2 years ago | (#39471497)

WTF do I care if someone cracks my slashdot password? Are they going to steal my karma?

I care about my bank account password, and, trust me, that is not used anywhere else.

cloud is still just a mainframe (1)

Dan667 (564390) | more than 2 years ago | (#39460627)

all the problems people had with mainframes you are starting to see with remaining mainframes "the cloud". No on cares about your data as much as you do no matter what they tell you or promise.

Very clever... but not as useful as it appears (1)

russotto (537200) | more than 2 years ago | (#39460883)

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:Very clever... but not as useful as it appears (1)

darkfeline (1890882) | more than 2 years ago | (#39461693)

ideally, every service/company would have it's own set of salts to immediately hash all incoming email addresses, which it would of course protect with its life. You'd have to steal the salts first, and the rainbow tables you make would only work for that one service, until it decides to reset its caches and generate new salts when it finds out someone stole them, which a responsible company should be doing.

Bad programmers making novice mistakes (2)

billcopc (196330) | more than 2 years ago | (#39461051)

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:Bad programmers making novice mistakes (3, Interesting)

darkfeline (1890882) | more than 2 years ago | (#39461729)

Actually, I think leaving the spare keys under your neighbor's welcome mat is a very good and unorthodox backup method. I'm pretty sure someone trying to break in will check your welcome mat and top of door frame, not your neighbor's. Maybe we can extend this analogy to web security? Have sites store their users password hashed on partner sites, and vice versa. Even better, have sites store the hashing salts on another partner site's servers. Quick, you and me patent this before big name companies start doing it!

There are many situations where this can be useful (0)

Anonymous Coward | more than 2 years ago | (#39461831)

I've been thinking along similar lines for around the last 6 months. The thing that got me started thinking about it was the compromise of MtGox. I had an account there with a strong password, and a single-use e-mail address. When they were compromised, my password was fine because it was one of those dozen character random passwords that are getting such a bad rap these days, but it also wasn't shared with any other accounts.

But, the problem was that the e-mail address I used there, which I had white-listed because it was used only on that service, started getting quite a lot of spam.

I started imagining that they could have stored the hash of my address on their publicly accessible systems and if I needed to do a password reset they could still verify that I had the address, and send a message password reset message to it, without having the address stored in their database.

If the service needs to send e-mails as part of the service, you could imagine a second server which is isolated from public access, but has an API for updating e-mail addresses and sending the messages.

Extending this to finding of friends is a pretty good idea. I never do the "look for friends" function because I don't want to give out my address book to these places, it's just too often lead to spam for me and my friends in the past. But, if I could upload hashes of those addresses I'd be more interested in doing it.

No, it won't work. Here's an excellent paper why. (1)

ron_ivi (607351) | more than 2 years ago | (#39463875)

This paper: Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization by Paul Ohm from the University of Colorado Law School is the best summary why it won't work even if people do it: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1450006 [ssrn.com] TL/DR: There are just far too many ways to infer the real meanings from a network of hashes.

It won't work: explained (1)

peawormsworth (1575267) | more than 2 years ago | (#39467847)

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 match, then you know the hash is really the email address you just hashed.

Any cloud service of any size will have many email addresses to run the hashing algorithm against. So any email address within the system can be hashed and checked against the stored hashes. So if two users are using the system and have each other in their contact list then the cloud service will "know" the true email address of these users despite each being a hash of the other in their contact list.

Salt is a mechanism to further obscure the original content. Salt is simply a 'secret work' added to the original unencrypted text (email) prior to hashing. It can be used to prevent such hash comparisons as mentioned above. However, this wont work in this case, as the hashing needs to either be done by the user or the cloud service. If it is done by the user, then the salt needs to be known by all users (in order to make sure the hash output is the same for same email addresses) and therefore is public and no longer a 'secret'. If the salt secret is held by the cloud service, then the service can use this salt at any time to do the lookups described above

Further, if all ur contact email addresses are hashed, then what possible use could there be in sending them ur contacts in the first place? If the service doesnt involve using the email addresses then why would you be sending them to the cloud service in the first place? If the cloud service doesnt require the data you are sending to it in order to provide the service, then it is an unethical service, and you should not be using it.

Hashing algorithms have value for comparing text and binary data. It is like a signature. If you know the hash value for some given data and you know how that hash was created (including the salt)... then u can use the same hashing algorithm to compare the hashes and verify that the data was not changed. Because it is known to be very hard to "fake" a hash. That is, if you know the email input and you know the hash output... it is nearly impossible to create a totally different email address that will produce the same hash output as the initial one. Therefore, hashing is very useful in verifying things to make sure the data was not changed... say for example a piece of code could be checked to make sure no virus was inserted before you run it.

Hashing algorithms are not useful in obscuring data. They are best at verifying that no changes have occurred. They do not provide a good mechanism of getting back to the original data.

I do not know the 'Path' cloud service or iphone app. I dont use it and dont want to bother reading about it. I will just say that it seems apparent that the app was downloading customer's address book in order to collect information that was not required. If the service does not require the data and instead asks the user for permission, then I doubt this the address info is required. If this is true, then it seems that the service was simply collecting as much information from the app user as possible in order to create searchable datamining information that can later be sold to 3rd parties. I suggest you do not use this service. If the app really does require contact information and email addresses to work, then I think PKI encryption is much more appropriate. Where the public and private keys are retained on two separate servers and the users encrypted contact information is on the server with the public key. And the private key is held on a highly secure server which only processes and decrypts information sent to it on the fly in order to provide said service. In this way it is much more difficult to comprimise the user information and requires physical theft of two computers which could be remotely located from one another.

I dont think Matt Gemmell really understands wat a hashing algorithm does or how it is and is not useful.

collision free? (0)

Anonymous Coward | more than 2 years ago | (#39475229)

if it's collision free, it's a one-to-one mapping, and hence theoretically reversible. collisions could result in, well, collisions...

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>