3 ms·

> Why has nobody reverse-engineered the iCloud API and made a Chrome extension to talk to it? If you can reverse engineer iCloud and bypass its security there

by jonknee 10y ago

> Why has nobody reverse-engineered the iCloud API and made a Chrome extension to talk to it? If you can reverse engineer iCloud and bypass its security there are a lot more lucrative pursuits than making a Chrome extension for your reading list.

derefr 10y ago
Who said anything about bypassing security? I was presuming the extension would just "walk in the front door" by getting the user to log into it with their iCloud credentials, and then passing those to the server. Or are you saying that the iCloud protocols are obfuscated/DRMed above-and-beyond just having regular AAA constraints applied to them?
- jonknee 10y ago
  iCloud is not a free for all, it's meant to share data within your app or within your org's group of apps (e.g. all Google apps). The Reading List data is within Apple's own container and you would not have access to it through conventional tools. This is typically a good thing because syncing is hard enough when you control both ends, having arbitrary programs messing with your data is a recipe for disaster.
  - derefr 10y ago
    Ah, this is what had me confused: I was assuming that the parts of "iCloud" that preceded the creation of the Ubiquity sync protocol (e.g. Safari bookmark sync, Notes and Reminders, Calendars, etc.) just stayed WebDAV-based with their CoreData databases being purely local+ephemeral, rather than migrating over into using full-on Ubiquity-synced CoreData stores. (I swear you can still export e.g. CalDAV calendar URLs from Calendars.app for iCloud calendars, and these CalDAV resources are writable if you want them to be. Or am I misremembering?) Still, even with the way iCloud works, you don't need to directly prod the data. If you want to manipulate Safari's container, you can prod Safari itself into doing so. OSA is no COM, but it works just fine for this sort of thing. (And if you can't manage to make it do so, you can write a Safari plug-in presenting a locally-bound HTTP API that the Chrome extension can talk to.) Now, the real challenge would be doing this syncing as part of some "syncing service" running on a cloud VM somewhere, that doesn't actually want to run thousands of headless copies of Safari. That's what I really want: the ability to sync Chrome with iCloud even if I currently have no active iCloud-attached devices. Probably the simplest way to do this is to write your own Ubiquity+CoreData client libraries and present yourself as another device that wants to sync against the iCloud account. It'd be up to you from there to safely munge the CoreData object hierarchy in a way resembling the official clients, but at least you'd be able to linearize those updates against iCloud messages.

by jonknee 10y ago

derefr 10y ago

Who said anything about bypassing security? I was presuming the extension would just "walk in the front door" by getting the user to log into it with their iCloud credentials, and then passing those to the server. Or are you saying that the iCloud protocols are obfuscated/DRMed above-and-beyond just having regular AAA constraints applied to them?

jonknee 10y ago
iCloud is not a free for all, it's meant to share data within your app or within your org's group of apps (e.g. all Google apps). The Reading List data is within Apple's own container and you would not have access to it through conventional tools. This is typically a good thing because syncing is hard enough when you control both ends, having arbitrary programs messing with your data is a recipe for disaster.
- derefr 10y ago
  Ah, this is what had me confused: I was assuming that the parts of "iCloud" that preceded the creation of the Ubiquity sync protocol (e.g. Safari bookmark sync, Notes and Reminders, Calendars, etc.) just stayed WebDAV-based with their CoreData databases being purely local+ephemeral, rather than migrating over into using full-on Ubiquity-synced CoreData stores. (I swear you can still export e.g. CalDAV calendar URLs from Calendars.app for iCloud calendars, and these CalDAV resources are writable if you want them to be. Or am I misremembering?) Still, even with the way iCloud works, you don't need to directly prod the data. If you want to manipulate Safari's container, you can prod Safari itself into doing so. OSA is no COM, but it works just fine for this sort of thing. (And if you can't manage to make it do so, you can write a Safari plug-in presenting a locally-bound HTTP API that the Chrome extension can talk to.) Now, the real challenge would be doing this syncing as part of some "syncing service" running on a cloud VM somewhere, that doesn't actually want to run thousands of headless copies of Safari. That's what I really want: the ability to sync Chrome with iCloud even if I currently have no active iCloud-attached devices. Probably the simplest way to do this is to write your own Ubiquity+CoreData client libraries and present yourself as another device that wants to sync against the iCloud account. It'd be up to you from there to safely munge the CoreData object hierarchy in a way resembling the official clients, but at least you'd be able to linearize those updates against iCloud messages.