Comment by acabal | Hacker News Reader

Comment by acabal | Hacker News Reader

Sometimes I feel like the only person who doesn't think that data portability is a right. After all, when you willingly hand over your data to a service, say Facebook, you do so with the assumption that you've read their terms and conditions, which probably don't include data portability in your favor. You're exchanging your data for a service they provide--social networking--and is it really your RIGHT to force the business to build special software to then transform your data for export at your whim? Sure, it's icing on the cake if they do so, but I really feel like calling it a "right" is somehow demeaning the word. If you don't want your data stored in Google or FB's servers, just don't use them--just as if you wouldn't use them if you didn't agree with any other part of their TOS.

Take my own business, which is a social network for writers. Imagine someone coming along one day and complaining about their right to export the writing they've posted, and their personal profile, and hey, while we're at it, all of their private messages in a nice XML hierarchy, and why not an annotated list of the critiques they've written, because it's their data dammit! The cost to develop that kind of system because someone has the idea in their head that it's some kind of new-fangled digital Right-with-a-capital-R would put me behind for months. Sure I'll delete your data if you leave, but if you don't want my data stored on only my servers, then don't use my site.

Edit: This could easily be framed as a consumer-damaging argument. I suspect that many of the people who support data portability "rights" are also the sort of people who support anti-DRM campaigns (which I do too, for the record). But if you have the right to demand your data back from a company at any time, why shouldn't the company have the right to demand its own data back from YOU--music, books, movies? Remember the fuss that happened with Amazon deleted some people's purchased Kindle books--which is nothing but data a consumer has licensed--from their devices without warning?

I think the sense of "right" that people are going for here is "inalienable right"—they don't want sites to be able to have such a we-own-your-data clause in their TOS, even if the both the individual and the company agree that that's the best trade to make, because the society writing the laws knows much more about the aggregate welfare of all the individuals who have chosen to make such a trade, while the individual is only aware of the few trades they are offered in their own lifetime.

If data ownership were an inalienable right, companies that currently trade on it would be forced to find some other commodity to exploit, or to fold. That, I imagine, is how data-portability advocates would have things.

> But if you have the right to demand your data back from a company at any time, why shouldn't the company have the right to demand its own data back from YOU--music, books, movies?

Remember though, exporting my data from e.g. Facebook doesn't mean that Facebook doesn't have the data anymore. The same as selling me an mp3 doesn't mean that the record label or Amazon doesn't have one less unit of inventory to sell to someone else.

You're completely right that

> if you don't want my data stored on only my servers, then don't use my site.

and your writer customer is also free to state that he will prefer sites that allow him to export his data.

Also, I'd like to know what you think about the cellphone plan example in the original example? It seems like a good example of an informed customer being able to get a better deal, but there is little incentive for the providers to supply this data. I posit that this is where it crosses the line from "nice to have" into a right.

Why would writing a simple export feature set you back months? Sounds like something that could be done by one person in an afternoon.

Data export is not that easy. I've looked into it for my own project. You have to determine which database fields you need to include in the export, what format those fields should be in, and then format of the export.

After you do all that, you need to code and test the export process. I estimated several days if not a week or two to get a workable system in place.

Edit: This is for a Rails project. If it was PHP, I wouldn't even bother thinking about it.

Not to mention the need to set up the actual page layout, markup, and related code... this is a PHP app so it's not that easy. Since I'm the only developer/everything else guy, my time has to be split between customer support, development of cashflow-generating features, and everything else needed to run a business. Maybe you're the "check out the Turing-test-passing AI I developed in a weekend" kind of programmer, but I'm not that good :)

I don't know about you, but if the requirement is simply "give me my data if I ask," I'm going to do as little as possible to get them that data, and then let them do what they wish with it from there—if it's not in a format they understand, then let them hire a third-party to write a converter; that's not my job. In this case, I think I'd just expose a single API endpoint that just spat out SQL dump statements.

Reply on news.ycombinator.com