Showing posts with label webkit. Show all posts
Showing posts with label webkit. Show all posts

2012-01-16

Safari's Reading List protocol: CalDAV + XBELs


Safari on desktop and iOS has a feature called "Reading List". It is a way to store URLs in iCloud, synchronize them between Safaris, and mark them as read or not. Somewhat like Instapaper maybe.

I was a bit surprised that there is no Chrome or Firefox extensions for tapping into Safari's Reading List. So I wanted to try poking a bit into the protocol, maybe something interesting would appear or someone could get some headstart from this.

Safari always seem to start contacting p05-bookmarks.icloud.com, which resolves to the Akamai CDN, some p05-bookmarks.icloud.com.akadns.net. Luckily the IP always was the same, and there is no client certificate check, so I could mount a little Man In The Middle via /etc/hosts.

Then, a couple of socats: one to pose as the original SSL server and resend the plaintext; and the second to receive the plaintext and send it to the original IP. The first socat shows everything that goes out of it (in plaintext) thanks to the -vx option.

socat -vx OPENSSL-LISTEN:443,cert=certs/server.pem,verify=0,reuseaddr,fork TCP:localhost:50000 

socat -v TCP-LISTEN:50000,reuseaddr,fork OPENSSL:17.172.100.37:443

I tried tcpflow instead of the -vx, but tcpflow won't show anything when capturing on the loopback interface on OS X. Seems to be a bug.

So now we can see the exchanges between Safari and iCloud. I was half-expecting something encrypted, but it isn't (apart from the SSL connection). It seems to be CalDAV, used to exchange small XBEL files, gzipped; which can be quickly unzipped by copying the hex from the socat dump and pasting into a "xxd -r -p | zcat ". Each XBEL file is a small XML file with an URL and its status.

I expected this to be much quicker, but socat and tcpflow kind of conspired against it. I started expecting to use named pipes and tee's to connect the socats while showing the exchanges, but each update in the Reading List causes between 3 and 5 connections, which needs the socat option fork, which forks new socats for each connection, which won't play nice with the pipes.

I guess I should have switched to some python earlier... next time I will. And at this point anyway, if I wanted to keep going into this protocol, looks like throwing together some small client with Python would be the best way forward.

But I am not currently interested in JavaScript, so I guess I won't be making any extension myself, so I guess I should move on to other things.

So, dear Lazyweb... :)

2009-07-09

Yet Another Nonsensical Javascript Benchmarking of Mostly Unreleased Browsers

After a couple of too-close-together performance-competition-between-browsers thingies, I decided to make my very own quick & dirty benchmark of current browsers. Webkit-based at least, although soon I'd like to at least try again Firefox; it's been months since I abandoned it for Webkit itself, due to a multitude of small problems, some of them caused by myself (much more than a hundred tabs always open, lots of extensions to lessen the load) but magnified by Firefox itself (extensions failing, slowness even when with much more reasonable numbers of tabs, sluggish Flash performance, problematic Java)...
In fact it's a great moment to make this kind of test, since Safari 4.0.2 has just appeared, Stainless 0.6.5 too, and ... well, WebKit has a recent nightly (r45641). Chrome is the available one right now: 3.0.192 (developer release)
A surprise has been to learn that Opera seems to have abandoned the race some time ago (ten times slower, javascript-wise, than any of the webkit-based browsers???). Will be... interesting to throw that to the next one who claims that Opera is holier than thou, blah, blah.
The benchmarks are Google's V8 (version 4) and Webkit's Sunspider.
v8: (bigger is better)
  • webkit: Run it once: 2160. Open new tab, run it again in the new tab: goes down to less than 2050, which is about 5% less. Next tabs hover just over 2050. Closing tabs and starting anew (but w/o restarting Webkit) goes back to 2160. (later I closed everything and retried, and didn't go over 2100)
  • safari: 2080 -> 1980. Same behaviour.
  • stainless: starts at 2064 and with each tab improves up to 2120!
  • chrome: pretty stable around 2950. Wow.
sunspider: (smaller is better)
  • webkit: starts at 787, worsens to 818 after a couple of new tabs with the same V8.
  • safari: from 795 to 805
  • stainless: again, improves from 695 to 680!
  • chrome: again, pretty stable winning at 650...
Interesting: Sunspider continually loads something between each subtest (something substantial). V8 only loads on, well, the first load; afterwards looks like the cache is enough, since every new tab with V8 doesn't cause (a lot of) traffic. BUT, in Stainless V8 seems to be reloaded in every new tab. Maybe Stainless is not sharing cache between the tabs?
And it looks like tabs are sometimes slow and sometimes fast: open tab, load V8, let it run. Let's say it gets a lowish score, 2050. Make new tab, load V8, let run. Let's say this one gets a somewhat high score, 2150. Now, run both tests again. The "slow" tab keeps being slow, and the "fast" tab keeps being fast... Strange.
(and looks like the first tab created in every window is "slow", and the next are "faster")
And with this, I forbid myself to keep wasting time benchmarking unreleased browsers. (But I sure will keep an eye on Stainless and chrome....if they had session saving, maybe I would switch right now! but at least they will be an interesting debugger...)
The machine used was a 2007 white macbook Core2Duo 2.16 GHz, with 3 GB RAM and about 5% of background CPU load.