-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There has been some discussion on the W3C TPWG about breaking same-origin to allow cross-domain signalling of consent. This has been now put off to a future DNT2.0 discussion because of the difficulty of getting to a consensus on the compliance spec.
But before we get there DNT could be a gating signal that could give UAs the ability to apply a user's privacy intent, e.g.. if "privacy mode" is selected *and* DNT:1 is set: 1) 3p cookies get blocked or have limited duration (expire after some hours) 2) 3p localStorage gets removed after a similar duration 3) 3p XHRs are blocked (to stop fingerprinting) 4) 3p .swf objects get blocked 5) 3p ETags are deleted after a short duration. Or maybe 3p cache is removed faster. DNT:0 is the consent signal i.e. if a third party obtains consent from the user they can execute the UGE API (or co-opt the 1p to do it for them) which will make all those things come back. If Mozilla community puts this in (it doesn’t have to be by default - though that would be good) it would give a major push to DNT and lend weight to future DNT2.0 discussions. None of these things applies to 1st parties (e.g. co-option of 1st party cookies) but that can be left to law - it already is in the EU, because 1st parties are more visible and can control what they put on their sites. > -----Original Message----- > From: dev-privacy [mailto:dev-privacy- > [email protected]] On Behalf Of > [email protected] > Sent: 10 January 2014 23:25 > To: [email protected] > Subject: Re: localStorage, and Flash cookies (was Re: partial third-party > cookie > blocking) > > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) Comment: Using gpg4o v3.2.34.4474 - http://www.gpg4o.de/ Charset: utf-8 iQEcBAEBAgAGBQJS0I8/AAoJEHMxUy4uXm2JqFYIAKSu6hSsI3FEnsoZy1VXeB4q NE0zgI1PT8Lq+yhlsE0Im6bsOW0r1QxtnPDf3Gy3w+8yaaa4fQdnaNW3r0upLLL9 k2Ptwp0CoW1nsIVYmOmZ1B29jChxdmWGGcGaJLGZ4yOHPXIHuMcwWQrsMfK8iyb7 YkAUvEqBIev3esYBvwApFt+KrI7nrsyCHcTOM5KliSXtZRokoW42BvjsWFHH+DIg nbeRGHFjH51GOeUHUJbeUGKMdOyJbDpBKG1Cr85ceF3SXiuJdGcTEsN2PZzM/A1v MXROp6VlgxQONeC8S74cu7VCrsGdeDNvM67V2hNb37T6vxK/wo1+nukCmM1G0GI= =AxgI -----END PGP SIGNATURE----- _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
