Sunday, September 28, 2008

Tag caching and progress slider

First, what's the tag cache?  s3mp is, at least for now, almost entirely client-side, so to get the meta data (artist, song title) of an mp3, it downloads a small initial chunk and a smaller final chunk from the file, looks for tags, and if it finds them, stores them.  The process of looking takes a while, but if all the tags are already stored in a handful of files, the process is a lot faster.

I changed how tag caching is handled.  Instead of letting the user choose a bucket to store tags in, s3mp now (once this beta is released) automatically stores a tag cache (with intentionally obvious names like .s3mp_tag_cache.0.xml.z) for the all mp3s in a given bucket in that same bucket.  I had an ugly dilemma to sort through on this one.  A tag cache for each bucket is easy for both me and the user, and loading a single bucket, or making it public to share, works as expected.  The problem is in how it's handled when the user doesn't have permission to write in that bucket.  All of the solutions put a strange burden on the user to pick, with foresight, where to put the tags.

For now, if you want to use the tag cache, make sure you have write access on the bucket.

The Progress Slider is making a lot of, um, progress.  The UI basically works, it just needs keyboard support, and the progress portion already indicates progress downloading a song.

Wednesday, September 10, 2008

Google Chrome, s3mp, and security

Seeing that Chrome was just released, I decided to make sure it works with s3mp, and I'm pleased to say that it does (see screenshot). That said, when playing with s3mp in Incognito mode, I found a disturbing security hole that allows "cookies" to not only be retained between Incognito sessions, but leak from a regular session to Incognito.

I said cookies, but I meant Flash SharedObjects. They're basically a way for Flash applets to store information locally (s3mp uses them to store "Local Settings"). Unlike cookies, Chrome doesn't flush these from Incognito mode or sandbox them.

Aside: Adobe has a knowledge base entry on how to manage and disable shared objects.

I made a proof-of-concept that logs what web pages the user visits using a Flash SharedObject to escape the Incognito sandbox.
Using it's easy; go to the main page, then some random combination of Chrom'd pages (page 1, page 2, etc.), then back to the main page, and the main page will display the history. The "Clear" button removes the cookie from your computer.

To break out of Incognito mode, go to the Chrom'd main page in an Incognito session. Browse a few pages, then close the session (or all of Chrome). Browse to the Chrom'd main page, again, and the Incognito browsing (only Chrom'd pages) history will be shown. Even better: since SharedObjects are shared across browsers, fire up up IE or explore your way to Firefox and load the page.

Putting on my black hat, what could be done with this hole? Nothing that isn't already a problem on other browsers. One of the more clever applications would be to couple SharedObjects with cookies as a means of detecting whether a user is frequently browses a web page Incognito, then display security related ads to paranoid users.

Chrome might offer some security features, but history, cache, and cookies are only part of security. As plugins become required for the web experience, without plugin-aware security, Chrome will be one step behind web developers, and further behind black hats.

Now... Where did they hide the "disable flash" button?