Big News: Big Internet Platforms Making It Easy To Move Your Data Somewhere Else
from the it's-a-start dept
So, just last week we had a post by Kevin Bankston from the Open Technology Institute arguing for some basic steps towards much greater data portability on social media. The idea was that the internet platforms had to make it much easier to not just download your data (which most of them already do), but to make it useful elsewhere. Bankston’s specific proposal included setting clear technical standards and solving the graph portability project. In talking about standards, Bankston referenced Google’s data transfer project, but that project has taken a big step forward today announcing a plan to let users transfer data automatically between platforms.
The “headline” that most folks are focusing on is that Google, Facebook, Microsoft and Twitter are all involved in the project (along with a few smaller companies), meaning that it should lead to a situation where you could easily transfer data between them. As it stands right now, the various services let you download your data, but getting it into another platform is still a hassle, making the whole “download your data” thing not all that useful beyond “oh, look at everything this company has about me.” Making a system where you can easily transfer all that data to another platform without having to manage the transition yourself or being left with a bunch of useless data is a big step forward — and a huge step towards giving users much more significant control over their data.
But the really important thing that this may lead to is not so much about transferring your data between one of the giant platforms, but hopefully in opening up new businesses which would allow you to retain much greater control over your data, while limiting how much the platforms themselves keep. This is something we’ve talked about in the past concerning the true power of data portability. Rather than having it tied up in silos connected to the services you use, wouldn’t it be much better if I could keep a “data bank” of my data in a place that is secure — and where if and when I want to I can allow various services to access that data in order to provide the services I want?
In other words, for many years I’ve complained about how we’ve lost the promise of cloud computing in just building up giant silos of data connected to the various online services. If we can separate out the data layer from the service layer, then we can get tremendous benefits, including (1) more end-user control over their own data (2) more competitive services and (3) less power to dominate everything by the biggest platforms. Indeed, we could even start to move towards a world of protocols instead of platforms.
Of course, this is only one step in that direction, but it’s a big one. And, yes, it’s notable that the big platforms are all working on this together, since it has the potential to undermine their own powerful position. But it’s absolutely the right thing for them to do, and hopefully we’ll start to see much more interesting services pop up out of this. If it only ends up allowing people to shift between Google and Facebook that will be a failure. If it enables new services and more end user control over data — forcing various services to compete and provide better value in exchange for accessing our data — that would be a huge step forward in how the internet functions.
Filed Under: competition, control, data portability, decentralization, innovation, lock in, privacy, silos
Companies: facebook, google, microsoft, twitter
Comments on “Big News: Big Internet Platforms Making It Easy To Move Your Data Somewhere Else”
Putting your data in a nice shiny package
I am sure that making it easier to transfer all your information would never be put to nefarious use…. At the very least this would make it easier for companies to bypass the part where they have to sit and wait to gather all those tiny details that add up over time.
Re: Putting your data in a nice shiny package
Wait, the chance to transfer your data to a competing social service, or eventually keep your data in a central location and share it where you chose, is bad because now these social media services have all that data they would have already had because it is now all in one place, instead of now where it is…almost all in one place with a few photos not on all services?
Maybe you could go into a bit more detail?
Re: Re: Putting your data in a nice shiny package
It’s not hard to imagine a feature like this being abused, like when sites ask you to type your email password to import contacts. Some people actually type it! If, with that password, a remote party can then transfer all the data out in a standard format, these attacks get easier.
The platforms can’t really win here. It’s a good feature and the linked page shows they considered security and privacy. But if this expands from 7 to hundreds of sites, people will eventually transfer data to one with lax privacy support, and someone will blame the sites that let users copy the data.
Re: Re: Re: Putting your data in a nice shiny package
OK, I agree that such an approach can become an attack vector. But its no different than the current vectors. It was the second sentence I had an issue with. The kind of attack vectors that are at issue with this problem are largely also at issue with Facebook now. I am confused how a single silo Facebook where a single sloppy approval gets all of your data is any worse when we can export our single silo Facebook data allowing a single sloppy export to get all of your data. I am unsure if hij was concerned with Masnick’s proposal, or the current Facebook one. The statement is vague, and hints at a specific concern…that either already exists or is too undefined for me to consider appropriately.
Re: Re: Re:2 Putting your data in a nice shiny package
Why is it different? Because you can put in one service multiple silos. I do not share my pictures with Facebook. I do not share my workplace with them either. This I share with linkedin. But linkedin does not get my facebook posts. Nor my pictures for that matter. I would like to keep it yhat way; but if there is only 1 key to all of it – this is impossible other than having multiple accounts, which makes this whole excercise moot.
Re: Re: Re:3 Putting your data in a nice shiny package
I am going to assume you are referring to Mike’s idea, of one silo serving multiple protocols/platforms. And assuming that it is an all or nothing share. But it is not. I can understand your issue, given the general all or nothing approach taken by apps and social media. But the whole idea of Mike’s personal silo concept is that you control your data and where it goes, and can choose when and where and what to push out to a specific platform. Mike is describing, in my read, a completely different way of interacting with social media.
But in the end, your premise is flawed. He does not suggest you would need to keep only one silo. But that you could. I can certainly imagine, even in his scenario, keeping multiple personal silos. Like someone who performs the Rocky Horror Picture show having a “Real Name” silo and a “Stage Name” silo. They do this often with Facebook profiles in some areas, to cordon off the more ‘risky’ content from their more respectable everyday contacts. In theory you shouldn’t need 2 silos, but there is no reason you couldn’t have two silos. It would also be useful with a small business owner, having multiple business Silos they manage.
TL;DR: your concerns assume WAY too much about a product that is far off.
Re: Putting your data in a nice shiny package
Indeed. I’d like to see encryption added to the contents so the host can’t see what’s there until the owner of the data provides the key. Ie: the data is useless until the user goes to the new service and effectively uses his/her keys. For online storage it would be awesome: your data is out of bounds to the host and you only process it locally. I’m not sure how this could be implemented for shared folders. Maybe Mega has the solution already? But in any case I think encryption should play a major role to avoid such scenario.
Re: Re: Putting your data in a nice shiny package
They already said the data will be encrypted at rest and in transit. The problem is that users will provide the keys, for whatever reason. Like when people give Linkedin their email password and it spams the world on their behalf. Or with Cambridge Analytica—my "friends" shouldn’t have been able to give away my data (that’s Facebook’s fault), but they did choose to give away their own.
Re: Re: Re: Putting your data in a nice shiny package
Yeah but you can’t possibly do anything code-wise against human fails. I’m not entirely sure how this will happen but clearly the current status quo is much less than ideal.
Actually this reminds me of how Troy Hunt implemented the password verification on HIBP. He built a code that hashes the password you entered locally and then only a portion of the hash is transferred. It’s called K-anonymity or something.
https://www.troyhunt.com/were-baking-have-i-been-pwned-into-firefox-and-1password/
I believe it can be done but we’ll need to work on it.
Re: Re: Putting your data in a nice shiny package
How is it supposed to work? Give each "bucket" its own access rights? ugo+rwx? Oh, god, I can imagine how popular with the public that would be. Or there would have to be a lot of work on UI.
Re: Re: Re: Putting your data in a nice shiny package
I don’t know, if I did I’d be working at Google or something, not with chemicals 😉
Re: Re: Re:2 Putting your data in a nice shiny package
🙂
I know how I would approach it: either a dumb container, and all the access rights implemented with cryptography, multiple decryption keys and all the other complex crypto stuff (with a GUI to manage accesses and share keys and whatnot), or an intelligent container (current could solutions would be a starting point) with better access rights (and management GUI). They probably would implement the second option, in which you’d have to trust the cloud provider.
I have often argued that the service and storage layers being conflated in cloud storage is highly frustrating to me. I like iCloud, but need windows too often and dislike its implementation on windows. So I use Dropbox. I’d prefer the pricing of iCloud, but I can’t use it.
Id vary much prefer to have iCloud Storage delivered via the Dropbox protocol. Or use my NAS storage via the Dropbox protocol, and retain some control of the data.
Others might prefer dropbox storage via the OneDrive protocol. Or something similar. As it is, I am stuck. Protocols, not platforms!
Re: Re:
That. If you could easily move your data to other services it would be wonderful.
I also don’t think it undermines their dominance. It all comes to whether they keep innovating and catering to the needs of their users it could be a way to increase their user base taking from others. As Mike said, this is a big step forward. Interoperability is the future.
Re: Re: Re:
Agreed.
I couldn't resist
standards
Ummm, NO..
“some basic steps towards much greater data portability on social media. “
nononononononononooooo
Sending your social media data back and forth..
DATA storage of Data..
Isnt to bad..but wouldnt it be NICE to Download it and CHECK IT WORKS…every once in awhile..
ALSO.. Think of DOTCOM and the BS he is going thru..
ALSO..NEVEr create 1 backup..3 minimum..
Re: Ummm, NO..
Full sentences would greatly enhance understanding of your post. Also, I request you cease your abuse of ellipsis.
Actually, As mike notes, you currently have the ability to download your data. It just isn’t very useful for other services, that’s why the data standard is useful, to create compatibility. I see no reason why we would loose the ability to download our data with this standard in place.
How is the BS related to the US creating a sham criminal case involved in any way with the ability to choose your social media platform?
I mean, sure I could create 3 different copies of the data. But since you dislike cloud storage (I assume from the comment on sending data back and forth), where do you store them? When dealing with personal data, finding a local offsite storage location for physical media isn’t necessarily easy. And a 3rd, non-local physical media storage location you can trust to properly handle your media seems a bit expensive, and likely overkill. And in the end…the article didn’t mention backups. Why are you talking about this?
Re: Re: Ummm, NO..
Lets see a few things first..
How many PUBLIC locations do you wish to store your data..
How many passwords do you wish to create, and have a 1/2 chance forget.
I have a site location that shows TONS of server breakin’s..Want it?
Windows Server..nuff said.
Dot com had a storage system, HOW in hell did the gov. KNOW what was where??
I already know that the Agencies involved assisted in the storage, so you dont have to tell me..
But consider ALL THAT DATA, that is/was not part of this sham..that belonged to others..
when you can see breakin’s to Major Corps like Sony, and terabytes stolen… Its very interesting you are willing to store your data PUBLICLY..
what would it take to store your data locally, AS well as speed on a gigabit lan, in 2 locations..(for safety and security..)
Even if you backup the whole system, downloading it All back is huge time sink. Even if you segment it, into Smaller chucks, and can ID every section.. You are asking a 3rd party to be dependable, and not loose or have your data hacked..
This common data format is due to NSA imposing it.
You kids REALLY believe that mega-corporations got together and agreed for YOUR convenience? — Especially when allows to move away? — HA, HA! Gosh, you kids aren’t even up to naive.
Re: Re:
Gobble that NSA-flavored cock, blue boy. Der Fuhrer Trump depends on your subservience.
Re: Re: Re:
Why was this truth censored?
Re: Re: Re: Re:
Because it A: is intentionally trying to be offensive, and B: by the way its (presumably singular) poster posts much the same thing in nearly any thread where one might guess out_of_the_blue to have a relevant interest, is at least nearly as much trolling as anything out_of_the_blue posts.
(And C: is not actually true in any non-metaphorical sense, at least as far as any meaningful known evidence goes.)