We have some open questions about LSO UX and permissions. As a temporary measure, we can just keep LSOs in memory and never write them to disk for now. That should make most content work, and get around the UX questions.

Till suggested that we implement in-memory LSOs before enabling on Nightly (Shumway's M3 milestone).

Yury suggested simply moving Shumway LSOs from localStorage to sessionStorage.

As a partial defense against Flash Supercookies, we could store LSOs from ad-like or tracker-like SWFs (e.g. URL with clickTag, 0 or 1 pixel height/width, etc) in cookie jar that is cleared when the page unloads (a shorter lifetime than sessionStorage) or just throw them in the bit bucket immediately.

LSOs do not block M3.

Make bugs with "[shumway-fb2]" whiteboard tag block shumway-fb2 meta bug 1110300.

Till, you said in email that "Shumway is using SessionStorage for LSO's, but that will change to LocalStorage for persistence." Does that mean this bug is the opposite of what we want? Making LSOs persistent sounds like a shumway-1.0 bug, not shumway-m4.

(In reply to Chris Peterson [:cpeterson] from comment #6) > Till, you said in email that "Shumway is using SessionStorage for LSO's, but > that will change to LocalStorage for persistence." Does that mean this bug > is the opposite of what we want? Heh, by now it is, yes. Also, we already did that and are currently using sessionStorage. > Making LSOs persistent sounds like a shumway-1.0 bug, not shumway-m4. I don't think I agree: we want to thoroughly test this. Also, if we want to properly implement the semantics, doing that in localStorage is about the same as doing it in sessionStorage. Re-purposing. Tobias and I just discussed this, and it seems like we can fully implement the correct semantics using localStorage. The only issue with that is that JS from that domain can read the LSOs, regardless of how they're namespaced. (By default, an LSO can only be read by the SWF that created it, but that can be changed.) This difference seems minor, especially compared to the tremendous updates this plan has: localStorage is already handled by Firefox's data management and by addons for managing privacy-relevant data. If we roll our own solution, we have to somehow make it available in those tools, too. There's one snag here: if foo.com/a.swf loads bar.com/b.swf as a child, then b.swf can access its own LSOs. Implementing that isn't entirely straight-forward: we're never creating an iframe or anything similar for bar.com, after all. What we need is an API in chrome-land that can read arbitrary localStorage objects. To prevent abuse, it must check the JS stack of the caller that requests the LSO and ensure that it is from the same domain. We have a mechanism for this inside the player, but not in chrome code. Adding it is probably not hard, though.

Till, Tobias: Yahoo!'s Flash ad guidelines [1] do not permit the use of Shared Objects. (I assume they both Local and Remote Shared Objects.) Can we just disable Shared Objects for M4 and postpone a complete implementation to a later milestone? [1] https://adspecs.yahoo.com/pages/standard-flash/

(In reply to Chris Peterson [:cpeterson] from comment #8) > Can we just disable Shared Objects for M4 and postpone a complete implementation to > a later milestone? While It's commendable that they forbid this, I'm not sure it means much more us. If other popular ad networks allow it, we can't force Yahoo's guidelines on all of them. If we can find conclusive evidence that all somewhat-kosher ad networks forbid this, it'd be ok, I guess, and pretty great in fact. I find that doubtful, though.

(In reply to Till Schneidereit [:till] from comment #9) > While It's commendable that they forbid this, I'm not sure it means much > more us. If other popular ad networks allow it, we can't force Yahoo's > guidelines on all of them. If we can find conclusive evidence that all > somewhat-kosher ad networks forbid this, it'd be ok, I guess, and pretty > great in fact. I find that doubtful, though. AOL's ad specs also forbid LSOs. I wonder if the ad networks are trying to prevent ad publishers from implementing their own user tracking. http://adspecs.aol.com/technical-guidelines/flash-cookies

Yury, does your localStorage implementation of LSOs in bug 1139633 also fix this bug? Till describes some important corner cases in comment 7.

(In reply to Chris Peterson [:cpeterson] from comment #10) > AOL's ad specs also forbid LSOs. I wonder if the ad networks are trying to > prevent ad publishers from implementing their own user tracking. That's a very likely explanation, yes. Also quite encouraging. > Yury, does your localStorage implementation of LSOs in bug 1139633 also fix > this bug? Till describes some important corner cases in comment 7. It doesn't, but it's a step towards fixing this bug. We're now using localStorage and the actual access happens from chrome code, so it's (theoretically, not currently practically) possible to access arbirary site's storage. We have to also implement access management that depends on the currently running code's applicationDomain.

Yury, is this work already done?

see bug 1243870