It is a bit sad to see something as simple as "you can now take your photos and put them where you want" become a newsworthy article. This is yet another demonstration that Digital Feudalism is alive and well, and just like its ancestor, we need to get rid of it by empowering people to be their own self
Take Gmail as an example. They provided nice way of allowing applications to access your mailbox. Then we got data mining apps which started using this for malicious purposes (with user consent). Now the API is only available for developers willing to go through security audit ($15k-75k).
10 years ago Facebook provided a pretty nice set of APIs and way to grant access to your data (for example photos, messages, friend lists) for 3rd party apps. What we got was 1000 quiz apps using these for data mining - with user consent.
Android is another example. Initially Google put little restrictions for data applications could access - with permission from user. We all know what happened.
I’m not saying we should stop trying to tear down the walled gardens, but this is not trivial problem to solve. Some users might be even better off with their data locked in the garden managed by Apple, Google or Facebook.
You can with a lightning USB drive or a lightning to USB adapter, but it'll only transfer at USB 2.0 speeds on most iPhones, iPads, and iPad Pros with Lightning. Some will apparently do USB3 speeds but you need the right adapter. And if you plug it into your iDevice into your computer with a lighting to USBC or A adapter, it's still just USB 2 speeds. At least as of the last time I looking into it. Apple always made it hard to figure this out. The newer USB-C ones you can transfer faster.
force protocols to be open would just about do it. People would trivially write cross-service applications on top and we could have an internet where people can freely move data around. Apple and Google would be delegated to the backend and users could choose the clients they want. It's honestly so trivial and uninvasive of a regulatory matter it's ridiculous. We're stuck in the 19th century railroad industry.
So, someone (who?) comes out with a standard, and then everyone just freezes capabilities then? Nothing evolves? Or if it does, it does so very unequally? Already in this announcement is the non-transfer of Live Photos because presumably Google doesn't support it. Apparently they also have a 20k per album cap, which at that point you get different behavior than you're expecting. These are just a few examples of where things go wrong.
If we're going to legislate anything, I believe the right way is to force complete data export is made available via a reasonable API/process, which then allows people to independently evolve & progress, and competitors will then need to support (or not) what comes out on the other side. But customers then know they can always extract or simply backup their data themselves if needed.
>and then everyone just freezes capabilities then? Nothing evolves? Or if it does, it does so very unequally?
every client provider can do whatever they want, that'd be the beauty of it. Someone could write a stripped down, privacy respecting Facebook client and charge users five bucks instead of running ads, if that's what users want. Someone could offer a chronological news-feed free of algorithmic meddling, or one that you can fine-tune however you like. That'd would simply be developer and user choice. Just think of RSS-readers or podcast apps or email clients. They're not all equal, but that's a feature, not something gone wrong.
I feel like you're missing his point a bit, which is that sure they can do whatever they want, but it would be within a well-defined and highly regulated system, and would need to conform to an interface that would be difficult to change and evolve.
A bit like how IRC never really got updated with features people like to see in newer IM apps, like conversation history, read receipts, sending images and videos, threading, and so on. Or HTTP. Or email. Federation always leads to ossification.
I think you missed an important link here: opening the API is not the same as making a good standard. The latter tends to take years. The former... Well, Google internal APIs often have minor changes every couple weeks. And the standard of documentation is more or less "go read the code". Opening those would not be useful. I don't know if Facebook is any better. But their motto is "move fast and break things", so I'm skeptical.
don't forget that there will be competition on the protocols as well, I'm not just arguing for protocols as a means for more innovation on the client side, but also more competition on the backend itself. If data becomes portable, which is one side effect of protocols, competition on standards itself intensifies. So if Google and Facebook are bad stewards of their APIs, there is room for competition to emerge. Google does stuff that sucks on their end? Use existing APIs to migrate over to dropbox or whatever, tell your users. In an open market there is an incentive for good standards.
absolutely nothing, it would subject their applications to genuine competition (they could of course still offer their own client) and destroy their walled garden, which is the entire point. The purpose such regulation is to benefit consumers, developers, and the health of the market overall. not Facebook. I assume they would be kicking and screaming.
> it would subject their applications to genuine competition (they could of course still offer their own client) and destroy their walled garden, which is the entire point.
Hmm. At least in the case that the OP was taking about -- third-party Facebook clients -- I don't think it would "destroy their walled garden" any more than third-party Twitter clients did back when those were meaningfully a thing. Standardized APIs aimed at enabling full-featured third-party social network clients wouldn't really contribute to a robust market in competing social networks; they'd just contribute to a robust market in, well, third-party social network clients.
What it seems to me you want is a couple steps beyond data portability, which honestly really isn't enough on its own. What I actually need is a way to import the user's social graph from Facebook or Twitter. That's arguably how Instagram bootstrapped its success initially: if you gave it your Twitter account, it would download all your followers/following info. (And, of course, that's why Twitter shut down that API after that.)
"But doesn't that violate GDPR?" someone is raising their hand to say, and: yes. GDPR as written does help protect privacy, but it's also an incredible boon to social network incumbents: it under it, your social graph can't be treated as your data, because by definition it contains personally identifiable information about all your contacts. For your regulation idea to be meaningful, GDPR and similar privacy regulation around the world would have to be overhauled -- if all the "open API" can do is import/export my personal data sans social graph, it becomes little more than a backup mechanism and a convenient way to fill out registration forms.
Assuming that they're using the Google Photos API for this, maybe the upload media API calls [1] don't trigger whatever handling is needed for Live Photos? The Google Photos app might be doing something undocumented/unavailable-in-the-public-API that triggers the Live Photo behavior, since a Live Photo is two associated pieces of media.
Or Apple might just not be uploading the videos that accompany the photo for some reason.
Just spitballing here: when I copy photos from my iPhone via usb to pc there are two files: the image and a .mov for a Live Photo. My guess is the metadata is lost when exporting to google photos, like usb, so you lose the “Live Photo”.
An interface doesn't necessarily limit what the implementation can do. An implementation can well be a super set of the interface (some open standard it supports), with additional features that's not in the interface.
Forcing the protocol to be open and documented and free for any user that can use the official site/client to connect to doesn’t have to mean forcing a standard. You might want to require o rubies compatibility with old versions and deal with obfuscation or unnecessary changes as anti competitive behaviour, but otherwise just ensuring that anyone can create and sell or give away clients, interoperability and import/export tools, etc. would be an excellent step in the right direction. With no obvious downsides.
>So, someone (who?) comes out with a standard, and then everyone just freezes capabilities then? Nothing evolves?
Hopefully yes. Most "progress" is towards worse services and more user data minining and ads.
But if needed, they can always innovate. But they'd still have to be able to export to the standard format (even if it can hold less than their full features).
>It's honestly so trivial and uninvasive of a regulatory matter it's ridiculous
You can't honestly believe this. Even if one agrees with making some things open protocols, potentialy by law (messenger, social networks), stating "it's trivial" to do such a thing is just the height of hyperbole.
I’m afraid some people really do seem to believe this. Hard to understand, I know. Fixed, regulator defined protocols everyone would be forced to use. Sheesh.
http was open once and technically it is open now. Soon the complexity of the protocol will allow only the major corporations to implement it (and it is unclear whether that complexity helps most people).
There is a lot of secret sauce in protocols. Those decisions can have serious positive/negative implications on performance and features. Making those easily available to everyone could potentially destroy a business.
Don't get me wrong, I've had to reverse engineer my share of proprietary protocols to get behavior I wanted (and would have loved to see them be open), but I don't think I can get onboard with the idea that requiring open protocols is trivial or noninvasive.
But we aren't discussing just these specific APIs/protocols (and I haven't look at them, so I'd have to take your word on that), we are discussing this generally.
Certainly any company that relies on “safe harbor” style protections or sells online services (alone or bundled with software) as a subscription should be required to fully open and document the protocol.
But most SaaS companies don’t make protocols, they make web applications. So I’m not really sure what’s implied by these trivial-to-implement protocols. Having a functional and well documented API isn’t a protocol. An open protocol would be more like a situation where any vendor could implement an “iCloud service”, and any “iCloud client” could connect to any vendors service.
I don’t agree here. A web application API, properly documented and exposed to any client a participant wants to use becomes a protocol for that service, there’s no difference between CalDAV and the Google Calendar web app’s API except that one is documented, rarely changes, and if offer by a service provider would generally allow any client that implements it to connect, and the other is undocumented and it’s probably against the terms of service to build your own clients. The goal should be to force every API for these providers to meet some minimal definition of a protocol, not to define government mandated standard protocols or force interoperability between services.
Your definition removes all distinction between the concept of a protocol, and the concept of an API. Google Calendar doesn't implement the Google Calendar Protocol, there is no standards body involved in determining how Google Calendar works, you're not free to go an implement your own Google Calendar compatible service, and Google can change Google Calendar without consultation with anybody. There is no definition of protocol where a single-service API, designed, implemented and published by a single party is a protocol. Google Calendar implements an API.
If your argument is that companies should be compelled to publish good API documentation, and allow any client to connect to them, then aside from creating a completely unnecessary system of regulatory moats, and aside from using the wrong words to describe this idea, you're likely to run directly into a 1A violation.
I think smaller companies tend to have the most open protocols (to the point that it almost becomes a security risk) because they don't have resources to work on unnecessary obfuscation. The protocols might not be documented anywhere but if a website is able to access a backend endpoint then someone else will be able to access that endpoint too.
Nothing in the parent comment says anything about requiring good documentation or 100% backwards compatibility.
You could always download your entire iCloud Photos library and reupload it anywhere else you wanted, it’s just tedious. The noteworthy thing is Apple will transfer your photos to Google Photos entirely on your behalf, without you having to download a single photo.
Yeah, it's the "lets you" part that ticks me off. That's the reason I have both Google Photos upload and Dropbox Upload enabled. Don't want to wake up one time to find out my photos are gone because some algo had a bad day.
What do you mean by "locks your account"? If you're using Photos on a Mac then everything is stored locally. If you're using iCloud, you still have the option to download all the originals locally. The only people that would really make use of this are those that don't know how to open the Photos library to access the photos directly.
Probably not from their online service, but unless you switch on “optimise local storage”, all of the files are already on your local disk in JPEG or HEIC.
I make a lot of photos and videos, those take up a lot of space. 128GB to store everything locally won't cut it. That's why I have a backup in form of Dropbox.
Additionaly, I plan to amend that with a self-hosted solution. I know, this reeks of tin foil, sure. However, whenever I read a horror story of someone getting locked out of their accounts and loosing access to their data a chill runs down my spine. Everytime I see captach start popping up too often I wonder if I'm suddenly, for some reason getting close to getting banned. This is the same reason why I have a GSuite account under my domain and never use login with Blabla solutions.
It is newsworthy considering that they did this without being forced to do so. Things like telephone number porting weren’t possible until the Federal government forced the issue
Although I do consider "digital feudalism" a legitimate risk, I don't think this is a good example. An increasing number of people don't have laptops but instead just phones and game consoles, so so have no access to normal data-centric affordances.
There is a real risk but it's not that different from the pre cloud era: that of proprietary formats. Google Docs itself is proprietary (if you map the Google Drive files to your local filesystem in the style of Dropbox the actual local data store locally is just a URI). It's worse, but not a huge amount worse than having your files be a proprietary blob, say a Word file.
And there are of course innumerable services that have data that never leaves the cloud from Facebook at one extreme to various services such as Gantt charts that aren't downloadable in any meaningful way.
But as I said I don't think this one case is a good example: In the case of Apple's stuff, I can keep it all current on my laptop: just tell photos, iCloud files, music etc to keep a complete copy on the local disk (i.e. don't treat it as a chache) and then back up normally. Music, photos, etc are stored in normal files (JPEG and mp3). My IMAP client downloads everything (messages and attachments) so if I were willing to use iCloud mail or gmail everything would be backed up; ditto for my calendars and address book. This is the same for many other cloud providers like Dropbox.
My criminal mind says this could be a way for Apple (and Later Google) to benefit more, from the difference in the price of their phones - Thanks to pricing based on Storage. Once they allow these photo storages to duplicate your data, you will need double the storage and phone starting line-up would be 256GB and upwards very soon. I think innovation to make money has saturated, and now it would be quirks like this to make more money per phone.
There are options in the middle - e.g. in M365 Personal, camera uploads are deposited as plain old files in your OneDrive Pictures folder and the Win10 photos app is driven directly by that. I periodically take offline backups by copying my OneDrive to an external drive and sleep easy that I have all my stuff.
Doesn’t that say that Apple has to give you access to your photos in a format where you could then upload the photos/videos to Google? It doesn’t say that Apple has to perform the transfer for you. That’s the novelty here — Apple handling the transfer on their side without any user intervention.
Given the country list, this is being done to likely get ahead of some kind of regulation, but I don’t think this is necessarily due to this specific clause. This is above and beyond what would be minimally required.
But from other comments, it looks like this is the start of other data transfer initiatives between major tech companies. Which would be a good thing, even if it is a result of trying to avoid further regulation.
It wouldn't be under that specific clause, but GDPR gets attached to many situations because people don't have a clear understanding of what it is and the limitations. If you work for a global company you'll find GDPR attached all kinds of customer requests to get extra traction.
This is incorrect. The photos in Apple Photos and iCloud were already portable. Apple is now offering to do this for you which is the only notable thing about this. Nowhere in the GDPR does it say that a company has to move your data for you if requested. They just have to allow you to move it if you choose to do so and that was already the case.
