I was shocked to see the list of partners involved (which is why I assume their logos are big and bold and center).<p>I'm glad to see them participating, but I wonder what their motivation is? Is it truly genuine?<p>I know for example that when we made the reddit API people questioned our motives since "the data was everything" and "how can reddit be willing to make the data so accessible", but we knew that in reality "the community is everything".<p>So I really hope these companies are similarly motivated, knowing that it is the community and their platform that are their true assets.
I'm very suspicious of this. The most dangerous thing here IMO would be if it were to allow these companies to share data among themselves, a data cartel so-to-speak. Currently from the website (emphasis mine) "enabling a seamless, direct, <i>user initiated</i> portability of data". I worry that they might simply remove the "user initiated" part after adoption hits critical mass. I'm now following the development on github [0]...<p>[0] <a href="https://github.com/google/data-transfer-project" rel="nofollow">https://github.com/google/data-transfer-project</a>
Let me repeat this loudly so people in the back can hear:<p>TRANSPORT MECHANISMS ARE NOT DATA STANDARDS!<p>It is great that they want to build on REST and use common authentication standards and what-not: but that's not the hard problem. The hard problem is the data itself (including the critical structure of the data) and getting it to agree.<p>I liken it to someone that wants to build a rail system out of LEGO and then saying it is a 'standard system' because the LEGO are all the same...but they don't say anything about the size of the tracks, the overhead clearance, how the train systems should act in case of junctions or possible collision.<p>This is yet another 'data transfer standard' that hand-waves away the hard part -- the inter-compatible data model.
The linked PDF has more info on what this is about: <a href="https://datatransferproject.dev/dtp-overview.pdf" rel="nofollow">https://datatransferproject.dev/dtp-overview.pdf</a><p>The use cases and data model sections are particularly interesting. My initial thoughts are that this is wildly unrealistic and will lead to the usual N+1 data formats issue that plagues other multi-company initiatives.
GitHub:
<a href="https://github.com/google/data-transfer-project" rel="nofollow">https://github.com/google/data-transfer-project</a><p>Several other companies are working on it in various forms.
Disclaimer: I am working for one of those companies.
The intention of this project is great. But I doubt if it can even work well. The whole project depends on the fact that everything to synchronize can be standardized. But this is almost impossible.<p>Let's say "Birth of Date". Some contact providers support BOD without year. But some support only the whole date. If the companies do no even agree on this tiny little item, how can they agree on larger deviations? Like max number of phone numbers in a contact profile? The size/format of profile image? Address format? and so on
> A user’s decision to move data to another service should not result in any loss of transparency or control over that data.<p>> It is worth noting that the Data Transfer Project doesn’t include any automated deletion architecture. Once a user has verified that the desired data is migrated, they would have to delete their data from their original service using that service’s deletion tool if they wanted the data deleted.<p>This project has copy, not move semantics. Therefore, in contrast to the stated purpose of allowing users to control their data, it actually has the opposite consequence of making it simpler to spread users' data around. Without a delete capability, the bias is towards multiple copies of user data.<p>This project normalizes web scraping to export data from non-participating APIs that project partners benefit from asymmetrically by establishing this as an open-source effort. In other words, API providers that do not provide export tools will nonetheless be subject to DTP adapters that exfiltrate data and send it to the (no doubt excellent) DTP importers maintained by DTP partners. This has the effect of creating a partial vacuum, sucking data from non-participants into participants' systems.<p>The economics of maintaining a high-volume bidirectional synchronization pipeline between DTP partners guarantees that these toy DTP adapters will not be the technology used to copy data between DTP partners, but rather, a dedicated pathway will be established instead. In other words, the public open-source DTP effort could be understood as a facade designed to create a plausible reason for why DTP partners have cross-connected their systems.<p>TLDR:<p>- Copy semantics are counterproductive to the goal of providing user control of their data.<p>- The approach of using existing APIs to scrape data from non-participating vendors is a priori hostile.<p>- Economics dictate that the lowest cost option for providing bidirectional synchronization between vendors involve dedicated links and specialized transport schemes that DTP project itself does not provide equally.<p>There is some merit to providing abstract representations of common data formats -- look at EDI, for instance. I'd welcome someone from the project stopping by to explain away my concerns.
What would this actually gain me? Say I transfer my twitter data to facebook what happens? Does it create new posts with all my tweets, or what? Why would I bother? It would be nice to have a simple chat to show what it actually does.
It would be nice to have Apple aboard in this project. As an iPhone user I am thinking to use iCloud BUT if I migrate to an Android phone I will have to migrate all my data manually to google drive or onedrive.
It’s an interesting idea, and at the same time strange that some of the companies listed (eg facebook) would be open to contributing to this... esp given that for them data is their business model.
Data portability is interesting for private data (like the example of photos given in the white paper) but I don't think it's useful for social data. It doesn't solve privacy problems; in fact it would give more companies access to your data. It doesn't solve monopoly problems; when you port data from Facebook to Google you still have a Facebook account.