On Monday, February 25, 2013 3:38:38 AM UTC-8, Jonas Sicking wrote: > On Sun, Feb 24, 2013 at 2:17 PM, Brian Smith <***> wrote: > > > [+sicking] > > > > > > Brian Smith wrote: > > >> Sid Stamm wrote: > > >> > > 6. What about localStorage and friends? > > >> > > > >> > * Brian brought up the idea that we should fix *all* state tools > > >> > and > > >> > cookies in one fell swoop. I think that, while we should get to it > > >> > eventually, we should chomp off one bite at first and then consider > > >> > doing the others next or we risk scope creep and never shipping > > >> > anything. > > >> > > >> I didn't mean to suggest that it all has to happen at once. I would > > >> say that it might actually be useful to delay doing this for a while > > >> to see how many sites switch to localStorage-based hacks. We may > > >> learn something interesting. But, I think we should have a bug to > > >> track this. I am not sure if "block localStorage in third-party > > >> iframes from sites I haven't visited" is the right scope. Is it? > > > > > > From a little browser, these two pages seem to be the leading authorities > > on bypassing Safari's third-party cookie blocking: > > > > > > http://stackoverflow.com/questions/9930671/safari-3rd-party-cookie-iframe-trick-no-longer-working/10098007 > > > http://log.scalemotion.com/2012/10/how-to-trick-safari-and-set-3rd-party.html > > > > > > "The interesting question is if this method is legal. Znd if next company > > using it will get $22.5 million fine. I'm not a lawyer, but from my common > > sense perspective as Safari settings explicitly says "Block thirdparty > > cookies from third parties and advertisers" and localStorage isn't a > > "cookie" the approach above seems legit." > > > > > > This suggests it might be worth changing the UI so that it doesn't refer > > exclusively to "cookies." I checked in Google Chrome, and their UI for > > cookies always refers to "Cookies and site data" or similar more general > > terms. So, I guess at least three people agree with me that the terminology > > in the UI should be changed. > > > > > > I filed bug 844659 about blocking localStorage in third-party iframes > > (either like we do for cookies, or like we do for IndexedDB). Note that the > > DOM team is working a an improvement on localStorage called "simple > > storage" or something like that, and that would also be impacted by this. > > > > > > After blocking localStorage and similar, I believe that Flash cookies are > > the next most viable/convenient alternative for tracking. I know there are > > various rumors flying around about the lack of development on Flash at > > Adobe, but it is at least worth asking them to change Flash cookie > > mechanism to respect our third-party cookie options, because it would be > > very bad if we indirectly caused an increase in Flash usage on the internet. > > > > I'm worried that simply blocking localStorage in 3rd party iframes > > would break the web. Testing would be needed for sure. > > > > Another option would be if we key localStorage on the > > parent-origin-chain or some such. But that's obviously more > > complicated so would be nice to avoid. > > > > Definitely need help from the privacy team with coming up with ideas > > for what policy we *want* to have, as well as testing if that policy > > would break the web. > > > > / Jonas
Why isn't there any discussion of implementing something like P3P policies so that people who control multiple domains can employ legitimate uses of 3rd party cookies like cross-domain sessionization? _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
