Frustrated with iCloud, Apple’s developer community speaks up en masse

Some are turning away from iCloud altogether after bad user experiences.

Apple's iCloud is marketed to us end users as a convenient and centralized way to manage data on all of our Macs and iOS devices: sync contacts and bookmarks, re-download music and apps, back up iOS devices, and sync documents and data for third-party apps as MobileMe did. The last item, syncing of documents and data, is one of the least glossy features of iCloud, but it is one of the most important, and it should be among the most straightforward. Right?

Perhaps not. Almost a year after Apple shut down MobileMe for good in favor of iCloud, third-party developers have begun to speak out about the difficulty involved in working with Apple's cloud service. A piece published at The Verge this week highlights many of those complaints, with quotes coming from well-known developers and anonymous sources alike about the challenges faced by the developer community. From data loss and corruption to unexpected Apple ID use cases, developers have seen it all—but are stymied by the persistence of problems that prevent them from shipping products with working iCloud support.

What's the big problem, exactly? According to Bare Bones Software's Rich Siegel, there are a number of moving parts to iCloud that all affect how things come out on the other end.

"In concept, the service is pretty simple. A central iCloud server holds the truth: the canonical version of the user's data for an app. As the user manipulates an app's data, iCloud tracks and reconciles the changes into the central truth and makes sure that all copies of the data, on each computer, are brought up to date," Siegel told Ars. "In order for this to work, though, a lot has to happen behind the scenes. What we casually refer to as iCloud is many parts, each with a role to play."

Indeed, there are multiple ways in which iCloud enables the syncing of data, though both users and developers are kept in the dark when things go wrong. Siegel described scenarios in which iCloud simply declares that a file upload has timed out ("Apart from not being semantically relevant, the message is also unhelpful because it doesn't provide any information that either the user or developer can apply to diagnose and resolve the problem"), or says that corrupted baselines are causing sync problems without making the problem visible, or just plain barfs up an opaque, internal error. This has resulted not just in headaches for developers, but also in inconvenience, confusion, and even anger on the part of end users, who go on to rate applications poorly because of these symptoms.

"When it fails, there's no option to recover—all you can do is try again (and again...) until it finally works. And when it does initialize successfully, it can take an extremely long time," Siegel said. "In some cases, we've seen delays of up to 25 minutes while waiting for the iCloud stack to initialize. There's no discernible consistency or rationale for when it says no and when it finally says yes... you can just keep trying, and eventually it might just work, or not."

Opaque errors are just the beginning—developers are also frustrated with how iCloud handles a user's data if the user chooses to turn off document and data syncing. Doing this, it turns out, completely removes a user's locally stored iCloud data. And signing out of iCloud results in the system moving iCloud data outside of an application's sandbox container, making it impossible for the app to use the data any longer. The assumption here is clear: you're either using iCloud exclusively for data storage or you don't want to use that data at all.

Indeed, Core Data is one of the main parts of iCloud causing headaches for developers. Black Pixel recently mentioned its own Core Data problems in a blog post about the future of NetNewsWire's syncing capabilities. "As far as sync is concerned, we knew we would likely need an alternative to Google Reader as early as last year. At the time, the option that seemed to make the most sense was to embrace iCloud and Core Data as the new sync solution of choice. We spent a considerable amount of time on this effort, but iCloud and Core Data syncing had issues that we simply could not resolve," wrote Black Pixel's Daniel Pasco.

Another developer Michael Göbel wrote in a blog post titled "Why all my iOS Apps are on hold": "Core Data and iCloud sync are still a joke. I can’t count the number of developers and companies that all ran into the same trouble and finally gave up—meaning they dropped iCloud support completely after hundreds of thousands of users lost their data."

Siegel expanded a bit upon some of the problems Core Data presents. "This is where the rubber meets the road for database-backed applications," he said. "Core Data is the application-level database framework supplied by OS X and iOS that provides the means for applications to store items, and data about those items, in a single database."

Returning to the iCloud signout problem, he explained how his company ran into problems dealing with the limitations of Core Data and sandboxing with its product Yojimbo.

"The recovery from iCloud signout involves taking the opportunity to migrate all of your Core Data storage from 'Mobile Documents' to the private sandbox container on your Mac. We found, to our dismay, that the practical reality didn't hold up to theory—part of the problem is that you don't get notified until after the data has been made inaccessible, and once in that state, there's no choice but to use Core Data to make a copy of the data that's just been sequestered," Siegel told Ars. "And of course, given a database of sufficient size, the process of using Core Data to relocate the database ties up the application in an unresponsive state, without visible progress, for as long as it takes. (And woe betide you if something goes wrong in the middle of it.)"

These are only some of the issues iCloud has presented to third-party developers, and Apple reportedly has not been effective. Some—including Black Pixel—have begun to create their own syncing services, while others opt to rely on other solutions like Dropbox. Others still are holding out hope that Apple will hear their cries and offer some help. "We and other affected developers are continuing to iterate with Apple regarding the technical problems we've run into. However, if iCloud sync can't be made to work, perhaps another service will do the job," Siegel said.

Jacqui Cheng
Jacqui is an Editor at Large at Ars Technica, where she has spent the last eight years writing about Apple culture, gadgets, social networking, privacy, and more. Emailjacqui@arstechnica.com//Twitter@eJacqui

149 Reader Comments

As an Apple fan that saw all the attempts Apple made to provide online user data repository over the past decade, it is clear that Apple simply hasn't learned much. And since it was already open to developers while Jobs was alive, you can't even blame the fault on his absence.

Excepting the document data syncing, iCloud works acceptably in my experience. I was hoping that the apps would take more advantage of it, but now I see why that wasn't the case. I really have to wonder why it's so difficult for Apple to get this right when other parts basically works as intended.

I have to say, I'm not surprised by the stuff in this article. Apple has never particularly cared about developers. It focuses on users and expects developers to figure things out. Apple has shown particular disdain for developers with its iPhone development policies. First, Apple was going to disallow 3rd party apps; later, Apple allowed them but with many restrictions. At one point Apple even had the gall to tell developers what languages they had to develop in.

I'm also not surprised at the technical issues with iCloud. Apple spends its time creating slick and shiny interfaces and integrating devices and apps with each other, and not so much time on actual back-end engineering. Apple's dearth of engineering talent explains why when Apple focuses on one product line, it lets others languish. So I think Apple simply doesn't have the necessary focus or man-power to develop robust back-end systems.

The correct response in this situation is to use open source standard tools, as Apple did with Mac OS X originally. Apple could build a versioning, syncing cloud on top of a standard VCS like git, possibly customizing it to meet Apple's specific needs. But these days Apple seems to like to go it alone, and as a result, we get a bunch of incompatible and half-baked technology that Apple only cleans up when it starts to blow up in Apple's face.

Yes, not surprised here either. I tend to stick to universal options...meaning solutions that are on multiple platforms such as Dropbox or even Google Drive.

My fear from the beginning is that if I get tied up too much with iCloud, it's only available on their computers/devices for the most part. Also, I could never trust it fully. While it never did anything wrong per-se, I never felt 100% comfortable with it.

It's really too bad. I would love if my video games like Final Fantasy IV saved state to iCloud so I could play on both my iPad and iPhone. I was wondering why gaming companies weren't embracing storing game saves on iCloud so this article makes a lot of sense.

I honestly don't get this. Apple has some of the most talented engineers in the world working for them. They have a mountain of cash higher than Mt Everest. How could they not have innovated or purchased a solution by now? This is a long running problem for them, and if I was an investor I'd want answers.

I honestly don't get this. Apple has some of the most talented engineers in the world working for them. They have a mountain of cash higher than Mt Everest. How could they not have innovated or purchased a solution by now? This is a long running problem for them, and if I was an investor I'd want answers.

Because they don't actually have that many back-end engineers like software developers. It's shocking that Apple hasn't hired more, especially under Tim Cook.

I honestly don't get this. Apple has some of the most talented engineers in the world working for them. They have a mountain of cash higher than Mt Everest. How could they not have innovated or purchased a solution by now? This is a long running problem for them, and if I was an investor I'd want answers.

No, if you were an investor, you'd want profits.

And Apple can provide them by ignoring developer complaints and telling their users that everything's OK.

That's not nice, but it is the easiest and simplest way to make large profits.

That's why developers are trying to use numbers to protect themselves - speaking out en masse means that Apple can't either ignore - or worse punish - an individual.

Apple built a series of huge data centers for iCloud and iTunes but still screws up. I'm sure Microsoft and Google are capable of also screwing up. Proprietary APIs suck

I'm keeping my data on services with libre foundations like Owncloud. If anything happens, I can pull it out using Webdav, Caldav etc. and move it to another provider. Convenience is one thing, having my data forever locked in to Apple/Google/MS infrastructure isn't worth it.

Arguably, this is a situation where Apple's ingrained tendency toward control-freakery made it bungle what could have been a very useful abstraction layer.

Consider the analogy of email: Apple ships a mail client on iDevices, because access to email is obviously something that people want; but they weren't nearly foolish or hubristic enough to assume that everyone would only use The One Blessed Apple Email Service. Their mail client, realistically, supports more or less anybody who speaks a vaguely modern mail protocol, and the user's mail experience(in terms of attachment limits, account size limits, uptime, and general competence) is largely between them and their provider.

With 'iCloud', Apple could have been in the position to establish the first(actually dominant and supported, not just a design doc or something that an Android-toting linux guru hacked together with git for his own use) major conceptual and API update to mobile device synchronization since Palm's 'conduits'(which kicked ass; but are fundamentally designed around devices without network connections of their own). Given their marketshare, had they defined something that was essentially what 'iCloud' is from the app side; but allowed users to plug in the backend service provider of their choice, the market would be rotten with options of different power and price, harried IT minions would be forced to add support next to the mailserver, and so forth.

Instead? The interface between the client storage mechanism and 'the cloud' is totally opaque, and Apple operates the only implementation that is ever supposed to exist(and it isn't all that great). I wouldn't necessarily expect that they could provide adequate resources for a service without ongoing subscription costs(without imposing serious limitations, or imposing ad-hoc rationing by just breaking a lot); but by not even allowing anybody else to try doing better, they brought all the consequences of their own failure down on themselves.

They would be foolish to give up on sync entirely(both since having all sync happening through 3rd parties like dropbox makes it easier for people to move cross-platform, and because having per-app roll-your-own sync is ugly as hell); but they seem similarly foolish to be attempting to own 100% of the synchronization process(including the unpleasant and thankless server-side which they apparently aren't pulling off well enough) rather than using their power as the platform owner to define the platform's sync capabilities without tying them to ongoing server costs forever.

It's worth repeating that iCloud Document Sync works perfectly fine. This is the same type of service as Dropbox. It's CoreData and syncing relational databases that is having issues. Dropbox, BTW, can't be used for this purpose either.

Apple's Trailers app, though, uses a relational CoreData database to track user favorites. This app is constantly losing track of favorites. It speaks to the woes of relying on CoreData sync via iCloud. Even Apple can't get it right in their own apps.

iCloud Document Sync == Similar to DropboxiCloud CoreData Sync == There is no similar service to this, it's not interchangeable with Dropbox or G.Drive

Is anyone doing a good job with what Apple is attempting? It has alot of moving parts as said. Just pushing a button to back up a drive or files is much different than consistently backing up with multiple computers in environments.

Very good article. All information about issue except technical ( logic ) but troubleshoot : they must be on an upgrade and lost parts of data. After restoration, the upgrade slow the traffic or works on the backup.

Apple is the first in line with this technology and I think, better than been angry, tease or whining to work with Apple to solve the issue. But Apple direction is just enough open to be confident to work with external (?). I want to say, just enough to be confident no patent will be stolen.

This makes no sense to me, what does stealing patents have to do with this? iCloud isn't anything particularly revolutionary, other cloud solutions manage to do data back-up and restore fairly, I would have thought that only the sandbox requires some custom tailoring, and even that isn't particuarly novel.

Both this issue and Google's Reader shutdown point to the fact that building a business on someone else's closed infrastructure is always going to be risky, either it may shutdown, and with it your business, or you're dependent on the controlling company to fix bugs and make sure it functions, while your customers and users naturally blame you.

Not every developer can afford their own sync solution, and even if they could, the user would certainly not want to deal with a multitude of different accounts for each app. But there are other ways than a locked down central solution, esp. one which as many problems as iCloud. I prefer apps giving me an option to tie in with different services, Dropbox is pretty popular, Drive is gaining ground and there are plenty of others like Sugar etc. The first to offer easy integration for developers, i.e. without cluttering up the users home directory in the cloud service, would be onto a winner frankly.

I gave up on icloud when I tried a simple variation on the sample code for document syncing and couldn't get an ipad and an iphone to agree on the contents. there was no useful feedback, there were no apparent problems, and the document was clearly in storage as it synced to another device just fine. that spoke to me immediately as "not ready for prime time." I didn't bother trying a more complicated test, I just moved to a different solution entirely.

also it's pretty clear a lot of commenters on this article have no development experience and don't really understand the issues at hand. it brings a smile to my face, seeing that lack of knowledge is no impediment to sharing an opinion. go team humanity!

Is anyone doing a good job with what Apple is attempting? It has alot of moving parts as said. Just pushing a button to back up a drive or files is much different than consistently backing up with multiple computers in environments.

OmniGroup's database sync (backs onto WebDAV, used in OmniFocus) is bullet-proof. TICoreDataSync (backs onto DropBox, used in MoneyWell and others) is also fairly good — while I won't say it's never had errors, the errors are recoverable unlike iCloud.

There's a bunch I haven't tried too, including some that have their own server-side counterpart.

To be clear, iCloud has abysmal performance and reliability for everything related to Core Data, but straight document syncing works like a charm. The Verge's article reflects this: the main complaint is on the Core Data + iCloud affair.

When I got this message I totally freaked. What was Apple thinking? That just because I didn't want to use iCloud anymore that I didn't still want my data? This is why the only thing I use iCloud for is to sync calendars.

It's worth repeating that iCloud Document Sync works perfectly fine. This is the same type of service as Dropbox. It's CoreData and syncing relational databases that is having issues. Dropbox, BTW, can't be used for this purpose either.

Right.

Syncing two relational databases that have diverged under transient network connectivity is hard, and there's really no right way to do it in many cases.

The first mistake was selling users on the idea that it could be done automagically if developers only flipped a switch, and then not providing those developers with any means to solve the corner cases. The second was pushing it heavily with those developers when Apple knows better than to use CoreData sync in their own apps.

It's worth repeating that iCloud Document Sync works perfectly fine. This is the same type of service as Dropbox. It's CoreData and syncing relational databases that is having issues. Dropbox, BTW, can't be used for this purpose either.

Apple's Trailers app, though, uses a relational CoreData database to track user favorites. This app is constantly losing track of favorites. It speaks to the woes of relying on CoreData sync via iCloud. Even Apple can't get it right in their own apps.

iCloud Document Sync == Similar to DropboxiCloud CoreData Sync == There is no similar service to this, it's not interchangeable with Dropbox or G.Drive

It's too strong to say that the *only* problem is with Core Data syncing. Core Data syncing is the only part of iCloud that essentially never works, but there are significant issues with the rest as well. The article quotes Rich Seigel as having seen 25 minute wait times for the iCloud stack to spin up -- that's not exclusive to Core Data. The problems with what happens to user data when they sign out of iCloud are not Core Data related.

Core Data sync needs to be fixed in order for anyone, even Apple, to honestly claim that iCloud works. However, there are deep-rooted problems with the entire approach they've taken -- that users shall have no visibility to anything inside of iCloud. Even if Apple "fixes" Core Data sync, they'll never cover all the myriad corner cases and possibilities by which data can be put into some weird state, and the insistence upon having no direct access to iCloud prevents recovery.

The difference is that Dropbox is so good at just syncing files that you can throw a sqlite file on it and get a better database.

No. No you can't.Sure, you can throw a database in there.But you really can't have two clients change that database (simultaneously or under transient data connectivity) and not have data loss.

True, but there are two major differences. One, Dropbox doesn't try to successfully do this, while iCloud does (obviously with Core Data rather than arbitrary SQLite databases, but the principle is the same). Ideally you wouldn't make promises that you can't keep, which is sort of what Core Data sync is doing, but at the same time, they're trying something hard, and maybe some growing pains are to be expected.

The second, and far larger, problem is that if you try this with Dropbox, the failure mode is that you end up with two different databases in your Dropbox, and you can manually recover if necessary. I trust that Dropbox data is safe, because in the worst case, it's sitting in a folder on my computer, there are multiple backups I can access via the web, and I can just get my data and rebuild it if necessary. iCloud takes the position that users shouldn't (and can't) see what's happening inside of iCloud. If iCloud fails merging two databases, you get whatever the result of the failure was. If you're lucky, you had a Time Machine or iTunes backup, but you can't go into iCloud and tell it, "OK, here's what I wanted to happen. Now incorporate my fix for the problem and go on."

The difference is that Dropbox is so good at just syncing files that you can throw a sqlite file on it and get a better database.

No. No you can't.Sure, you can throw a database in there.But you really can't have two clients change that database (simultaneously or under transient data connectivity) and not have data loss.

Dropbox at least has more ability to recognize a conflict is happening, and even provide a "Time Machine" to an older file version. iCloud OTOH still manages to mix crap up when "concurrent" means I put down my iPhone, make dinner, and then pick up my iPad. Losing data to a second's window of read/modify/write on a device is closer to good than whatever the hell iCloud is doing.

Edit: If Dropbox were to extend that a tiny bit with real SQL connections to recognized database files in a special folder, that would be insanely great.

Just the add a little info to this story, iCloud is three different services- key value storage which works fine, document storage (like DropBox) which works fine except for some cases having to do with turning in on and off, and Core Data syncing which is a disaster right now.

Core Data syncing involves syncing a sql database not by putting the database itself in the could, but rather by syncing a list of changes. So if you change a 1 kB entry in a 500MB database, only 1 kB is synced across all devices. It is also advertised to be able to merge conflicting changes made on different devices, though it doesn't seem to give developers enough control to do that properly in all cases. Finally, iCloud sync is designed to be CPU efficient- you don't have to run through every entry in your database to see what's changed, it automatically uploads change logs of changed items.

There are certainly many people who've implemented their own version of SQL syncing. Some of them may be geniuses that pulled it off better than Apple. But, for the most part people are either syncing the whole database (not network efficient, not conflict safe), or they have an implementation that uses a lot of CPU cycles (ok for a grocery list app, not ok for a 10 million entry database). To my knowledge, nobody else is is offering iOS developers a low bandwidth, conflict safe, CPU cycle sparing sql merging system equivalent to Core Data. So this is not a case of Apple not being able to do what others (competitors, open source community) are doing, and it isn't really a case of Apple going it alone on proprietary tech (they are basically trying to make SQLite work). It is a case of Apple not documenting their tech properly for developers and advertising a product as working when it is really in a beta state at best (like Maps).

The difference is that Dropbox is so good at just syncing files that you can throw a sqlite file on it and get a better database.

No. No you can't.Sure, you can throw a database in there.But you really can't have two clients change that database (simultaneously or under transient data connectivity) and not have data loss.

Dropbox at least has more ability to recognize a conflict is happening, and even provide a "Time Machine" to an older file version. iCloud OTOH still manages to mix crap up when "concurrent" means I put down my iPhone, make dinner, and then pick up my iPad. Losing data to a second's window of read/modify/write on a device is closer to good than whatever the hell iCloud is doing.

Edit: If Dropbox were to extend that a tiny bit with real SQL connections to recognized database files in a special folder, that would be insanely great.

DropBox absolutely cannot merge changed made to an SQL database, which is what Core Data claims to do. You can put a 100MB sqlite file on DropBox, make a 1 kB change to it, and sync the entire file if you want to, but that is totally different from Core Data.

You are talking about document syncing, of which the two are actually similar and if you are having problems it is probably your developer's fault. iCloud certainly does allow for the presentation of the conflicting versions to the users to let them decide the truth. By default iCloud document storage stores all conflicting versions uploaded until they are marked as conflict resolved by the app.

Arguably, this is a situation where Apple's ingrained tendency toward control-freakery made it bungle what could have been a very useful abstraction layer.

Consider the analogy of email: Apple ships a mail client on iDevices, because access to email is obviously something that people want; but they weren't nearly foolish or hubristic enough to assume that everyone would only use The One Blessed Apple Email Service. Their mail client, realistically, supports more or less anybody who speaks a vaguely modern mail protocol, and the user's mail experience(in terms of attachment limits, account size limits, uptime, and general competence) is largely between them and their provider.

With 'iCloud', Apple could have been in the position to establish the first(actually dominant and supported, not just a design doc or something that an Android-toting linux guru hacked together with git for his own use) major conceptual and API update to mobile device synchronization since Palm's 'conduits'(which kicked ass; but are fundamentally designed around devices without network connections of their own). Given their marketshare, had they defined something that was essentially what 'iCloud' is from the app side; but allowed users to plug in the backend service provider of their choice, the market would be rotten with options of different power and price, harried IT minions would be forced to add support next to the mailserver, and so forth.

Instead? The interface between the client storage mechanism and 'the cloud' is totally opaque, and Apple operates the only implementation that is ever supposed to exist(and it isn't all that great). I wouldn't necessarily expect that they could provide adequate resources for a service without ongoing subscription costs(without imposing serious limitations, or imposing ad-hoc rationing by just breaking a lot); but by not even allowing anybody else to try doing better, they brought all the consequences of their own failure down on themselves.

They would be foolish to give up on sync entirely(both since having all sync happening through 3rd parties like dropbox makes it easier for people to move cross-platform, and because having per-app roll-your-own sync is ugly as hell); but they seem similarly foolish to be attempting to own 100% of the synchronization process(including the unpleasant and thankless server-side which they apparently aren't pulling off well enough) rather than using their power as the platform owner to define the platform's sync capabilities without tying them to ongoing server costs forever.

DropBox absolutely cannot merge changed made to an SQL database, which is what Core Data claims to do. You can put a 100MB sqlite file on DropBox, make a 1 kB change to it, and sync the entire file if you want to, but that is totally different from Core Data.

Just a nitpick, because otherwise you're right.

Dropbox's desktop clients are able to do pretty efficient differential synchronization. The whole file does not need to be uploaded/downloaded. For a SQLite database in WAL mode this actually works great (I've used it for a poor man's disaster recovery).

There is still no attempt to merge conflicts (two clients changing the database concurrently), and rightly so, as that is an intractable problem.

The difference is that Dropbox is so good at just syncing files that you can throw a sqlite file on it and get a better database.

No. No you can't.Sure, you can throw a database in there.But you really can't have two clients change that database (simultaneously or under transient data connectivity) and not have data loss.

True, but there are two major differences. One, Dropbox doesn't try to successfully do this, while iCloud does (obviously with Core Data rather than arbitrary SQLite databases, but the principle is the same). Ideally you wouldn't make promises that you can't keep, which is sort of what Core Data sync is doing, but at the same time, they're trying something hard, and maybe some growing pains are to be expected.

The second, and far larger, problem is that if you try this with Dropbox, the failure mode is that you end up with two different databases in your Dropbox, and you can manually recover if necessary. I trust that Dropbox data is safe, because in the worst case, it's sitting in a folder on my computer, there are multiple backups I can access via the web, and I can just get my data and rebuild it if necessary. iCloud takes the position that users shouldn't (and can't) see what's happening inside of iCloud. If iCloud fails merging two databases, you get whatever the result of the failure was. If you're lucky, you had a Time Machine or iTunes backup, but you can't go into iCloud and tell it, "OK, here's what I wanted to happen. Now incorporate my fix for the problem and go on."

So, if you found yourself looking at an iCloud sync'd document that had developed noticeable discrepancies--could you delete the flawed document, recover a previous version from a TimeMachine backup and move it into the file set that iCloud is syncing? I understand that the discrepanices might be subtle enough to resist immediate detection, but once found, what else do you have to do to replace the flawed version with your version of choice?

I honestly don't get this. Apple has some of the most talented engineers in the world working for them. They have a mountain of cash higher than Mt Everest. How could they not have innovated or purchased a solution by now? This is a long running problem for them, and if I was an investor I'd want answers.

People think cash solves all but that is just not true. Time and experience are important. That is the reason apple cannot get Google in cloud services. Its just not their game.

Is anyone doing a good job with what Apple is attempting? It has alot of moving parts as said. Just pushing a button to back up a drive or files is much different than consistently backing up with multiple computers in environments.

Microsoft has been doing "cloud backups" longer than either Apple or Google. They have a lot of experience with maintaining back-end technology and it shows in SkyDrive.

Google has more experience than Apple as well in this regards, but to act as if Apple is just like every other company in this regard is either naive or foolish.

in early Feburary this year, the developers of Outbank, a popular banking application for iOS and Mac in Germany, had realized (after massive negative user feedback), that there was something terribly wrong with iCloud Sync, so they decided to publish an open letter to customers and share it with Apple. It shows the problems and issues you face as a developers when developing apps using iCloud. See full letter here: Outbank Open Letter or read the Google translation here: Outbank Open Letter (Google Translation)