partial third-party cookie blocking | Sid Stamm | 1/14/13 10:24 AM | Jonathan Mayer has implemented a halfway-block feature for third party
cookies. Right now, Firefox can only block BOTH { setting + getting } of third party cookies, so we can't turn it off by default. At least one other browser has something about half-way that allows the getting of cookies in third party contexts (but blocks setting). The effect is that sites you visit directly can set cookies, but sites you don't visit directly cannot. Anyway, I think we should ship this feature. I think we should ship it enabled by default, but we need to do a few things first: 1. Write the code (almost done) 2. Make sure users know the difference between this and full-strength third-party cookie blocking. 3. Make sure it doesn't cause too much breakage in the web experience. jmayer is working hard on the code. There's a reasonable UI in the bug that teases out accepting cookies "from visited" as a new feature. https://bugzilla.mozilla.org/show_bug.cgi?id=818340 We are working on a test pilot study around cookies that might help us get a good picture of how much is going to break when we turn this on. If anyone out there has some data that can educate this, I'd appreciate it. :) -Sid |
Re: partial third-party cookie blocking | Benjamin Smedberg | 1/14/13 11:57 AM | >* What other browser is doing this? * What is considered "third-party" in this context? e.g. are iframes third-party? * What will the behavior be when this kind of content attempts to set a cookie? Will it silently fail, or throw errors? * I know we tried this once before with some kind of dual-key cookie setup. How is this proposal different and are we confident that we solved the problems that killed the first attempt? You're talking about the 0.1% users? I can't imagine most users care. Do you plan on flipping the default pref immediately after the code lands, or wait a cycle to shake out regressions and flip the default at the beginning of the next cycle? --BDS |
Re: partial third-party cookie blocking | Sid Stamm | 1/14/13 1:42 PM | On 1/14/13 11:57 AM, Benjamin Smedberg wrote:Safari does this for all its users by default (that's suggested by the title of the bug, https://bugzilla.mozilla.org/show_bug.cgi?id=818340). They've been doing it for quite some time now. Same as for our existing cookie stuff. Things that are different origin than the top level document. Silently fail. We could toss an error in the web console, but I'm not convinced we need to add more messages there. To the web server it will seem as if the Set-Cookie header was lost in transmission. This is different. This won't affect cookies for sites that already set a cookie on the browser. For example, I visit a.com (get a cookie), then visit b.com that includes a.com content. a.com is a third party, but since I already have a cookie it gets to set/get cookies in a third party context. If b.com has another third party reference to c.com, but I don't have c.com cookies, get/set cookies doesn't work for c.com. Good point. I guess it would make sense to at least gut-check the UI changes somehow. I'd like to land the code and change the default to this new state at the same time, but if you think we need to let it stew for a while before flipping the pref, we could probably do that too. -Sid |
Re: partial third-party cookie blocking | Sid Stamm | 1/31/13 11:09 AM | In the bug, Brendan posted:
https://bugzilla.mozilla.org/show_bug.cgi?id=818340#c32 > Does anyone know what the effect of this is on the average user? > > Obviously third-party cookie surveillance is a privacy concern -- > Mozilla built Collusion to show how many tracking entities there are, > and how they relate. But the current commerce patterns on the web > depend on cookies, with some user benefits as well as costs and > risks. > > Yes, I'm saying targeted ads based on cookies that this patch would > block are sometimes a new win for some users. Maybe not enough to > justify the downside, but who knows? I do not. I see no one on this > bug trying to assess. > > I personally want us to get to a better, user-centric model that > supports ads and commerce without tracking by parties engaged in > non-transparent business practices. Users ideally should be able to > opt into a self-profiling system, client-based and highly private > (after all, we already keep your history, you trust Firefox to keep > this information private), that can selectively disclose abstracted > or even (depending on to whom) precise/concrete information that > helps give the user more value than today's cookie-based world. > > Given such a system, I'd even want something like: opt into this > better "user profiling" agent and at the same time turn off all > third-party cookies. > > There are tons of ways to track users, of course. See > http://www.businessinsider.com/facebooks-plan-to-kill-the-tracking-cookie-2013-1 > and look past the hype that implies cookies won't work. We don't want > to start an arms race or play whack-a-mole. But in order to move the > debate to a better place, we need innovation. > > Without something innovative, such as the better user agent with > opt-in disclosure to select second parties, we risk "escalation" -- > ultimately to regulators who can't innovate. Regulators under > political pressure tend to simply freeze existing structures, locking > in incumbents. > > Speaking of advantaging the incumbents, this patch won't touch > existing cookie stores chock-full of already-set, long-lived > third-party cookies, right? That doesn't seem great on its face even > if this patch makes life better with respect to third-party cookies > the user might face in the future. > > We need a newsgroup thread or better to discuss this further, unless > I've missed an analysis of what the impact of this patch on Firefox > users in the large, especially loss of useful ads (if such exist), > might be. > > /be |
Re: partial third-party cookie blocking | Sid Stamm | 1/31/13 11:27 AM | Hi Brendan,
I'm not convinced this is entirely about targeted ads. To me it's about opaque profile building without consent or obvious user benefit. I don't mind targeted ads, but I am not comfortable with companies I've never heard of knowing where I browse. In parallel to this work, mmc is developing a test pilot study to better understand how third party cookies are used. I think testing this in nightly to see what breaks is valuable, though from the use cases I've looked at things like SSO and Facebook Connect (when I'm logged in) and the like will all continue to work. Yes, this would be fantastic! I think in the short term, we should try to make our Firefox defaults live up to users expectations. Simply based on how collusion was received, people are frequently shocked at the sheer number of sites that cookie them. This makes me think it's reasonable to believe that users expect cookies from sites they visit and not from sites they don't (because they may not know these sites exist). My opinion is that we're already there; I feel like there's significant pressure to do something about cookies so their use doesn't get specifically regulated. Many people clear cookies regularly because they've been told it's the "safe" thing to do. My mom does this even though I never told her to -- I think she got it from the local news. But you're right, for old profiles, the leftovers minimize benefit. I don't think anyone is suggesting this feature is perfect, but rather fairly simple to implement and a step in the right direction. -Sid |
Re: partial third-party cookie blocking | jduell...@gmail.com | 1/31/13 11:46 AM | On Thursday, January 31, 2013 11:27:09 AM UTC-8, Sid Stamm wrote:Am I correct to think that one effect of this patch would be that it would encourage centralization of the cookie tracking industry into the Big Players (Google/Yahoo/Facebook/etc), who would become the only sites practically capable of setting 3rd party cookies to a near-universal user base? With attendant interesting/ambiguous tradeoffs (fewer players mean it's easier for government to regulate practices, etc). Jason |
Re: partial third-party cookie blocking | Brendan Eich | 1/31/13 1:06 PM | Sid Stamm wrote: > I'm not convinced this is entirely about targeted ads.No "entirely", agreed. But "partially", right? E.g., Doubleclick (Google). Who is in favor of that, when stated that way? Yet that's the web and its commerce-patterns we all use, and "good tracking" and "bad tracking" are muddled (assuming there is "good tracking") because both involve cookies set by sites I've never visited (I have never been to doubleclick.com). How do you know this patch won't regress the net-win outcome for too many users? I simply do not know, hence my concern. That is important to validate. It also seems different from what happened "last time" (three years ago? dwitte's work, but my memory may be failing me). Who will test thoroughly and report back? /be |
Re: partial third-party cookie blocking | lada...@mozilla.com | 1/31/13 4:01 PM | What granularity will be applied to the setting heuristic? What I mean by that is:
a) I visit www.socialnetwork.com, they try to set a cookie from api.socialnetwork.com. Does this succeed? b) I visit www.randomblog.com that includes a +1billion button from api.socialnetwork.com. Does that work, since I never visited api.socialnetwork.com directly? c) What about banking websites that embed 3rd party payment / clearing providers in iframes? You'll never visit those 3rd parties directly, yet they are essential to user interaction on important site. Vis a vis Safari, last time I tried visiting one of these in Safari I got an error that Safari was not a supported browser. :/ Lucas. |
Re: partial third-party cookie blocking | Monica Chew | 1/31/13 5:03 PM | I think it's true that for every counter-measure, there will be
counter-counter-measures attempted, including switching to local storage that's equivalent to cookies but not controlled by cookie prefs, using redirects to bypass the 1st party restrictions, and what you mentioned. Does that mean we should never try partial solutions? I don't think so. Monica |
Re: partial third-party cookie blocking | Jonathan Mayer | 1/31/13 5:17 PM | Jason,
The impact will assuredly vary by an online business's size, sector, and implementation. Google, for example, hosts many of its third- party services from dedicated domains (e.g. doubleclick.net and google- analytics.com). Those services would not get a free pass under the new cookie policy. Facebook, on the other hand, hosts most of its third-party services from facebook.com. It would not be so limited. The aim of this new cookie policy is to better conform to user trust and desired functionality. It's certainly not perfect, and I would be glad to participate in future efforts to both better reflect general preferences and facilitate individual customization. In the interim, I think the new policy is plainly an improvement over the status quo. Best, Jonathan |
Re: partial third-party cookie blocking | Jonathan Mayer | 1/31/13 5:46 PM | > a) I visitwww.socialnetwork.com, they try to set a cookie from api.socialnetwork.com. Does this succeed? Yes. This would succeed under both the old and new cookie blocking features. The test for whether a domain is third-party is a comparison of public suffix + 1 (see mozIThirdPartyUtil). > b) I visitwww.randomblog.comthat includes a +1billion button from api.socialnetwork.com. Does that work, since I never visited api.socialnetwork.com directly? The button should display and click as usual. If the user has never visited socialnetwork.com or any subdomain (to be precise, if the user has never received a cookie from socialnetwork.com or any subdomain), then the button would not be able to set cookies. I haven't come across Safari-incompatible content in years, presumably owing in some measure to the popularity of iOS devices. At any rate, it's certainly true that services that require measures to accomodate Safari would have to extend those measures to Firefox. > Lucas. |
Re: partial third-party cookie blocking | Bil Corry | 2/1/13 12:56 PM | On Feb 1, 2013, at 2:52 AM, "Jonathan Mayer" <jma...@stanford.edu> wrote:What you refer to as "measures to accomodate" was referred to earlier by Monica as "counter-counter-measures". If a website works around the Safari cookie limitation in some manner to make the website usable for Safari users, is the website being accomodating, or is it deploying a counter-counter-measure? - Bil |
Re: partial third-party cookie blocking | Bil Corry | 2/1/13 1:42 PM | The reason Google uses dedicated hosts is to keep content segregated so that a compromise in one service doesn't impact all of them.
Dedicated hosts also allows a company to outsource some portion of their web infrastructure without having to give the vendor control over a sub-domain of the main web property. If Google and others decide, for competitive reasons, to consolidate their services to a single domain, it'll represent a step back in security. I wonder what other trade-offs and long-term consequences there are for adopting the Safari cookie behavior. - Bil |
Re: partial third-party cookie blocking | Brendan Eich | 2/1/13 2:15 PM | On Jan 31, 5:17 pm, Jonathan Mayer <jma...@stanford.edu> wrote:Evidence? This is going to be tough to demonstrate except by large- scale user testing and careful bug-report and support-call screening. It is good to have Safari blazing this trail, but sites do stupid user- agent sniffing and Firefox users could suffer painful loss of service until such server-side code is fixed. That can take a while, since the pain is felt most by the early adopters, whose cohort size is small. /be |
Re: partial third-party cookie blocking | Brian Smith | 2/1/13 3:17 PM | Sid Stamm wrote: > > There are tons of ways to track users, of course. SeeI understand this part as arguing that, basically, cookies are the devil we know, and it's better to deal with the devil we know than the devil we don't know. I think it would be straightforward to say that in any case we block cookies, we must block the localStorage/IndexedDB/etc. counterpart. But, there are several other mechanisms for tracking users including fingerprinting, HTTP ETags, etc. Blocking tracking based on those alternative techniques is difficult and potentially has a lot of collateral damage in the product, such as reduced functionality and/or reduced performance. We've seen that multiple module owners have objected to even having a pref to enable various higher-privacy/worse-functionality settings, for good reasons. I think it makes sense to be concerned that we will end up backing ourselves into a corner by pushing ad networks to use mechanisms that we will never be able to block. I think this is just a quality-of-implementation issue with the patch. I think this concern can be resolved in a reasonable way. I don't know about "useful ads," but I do think that Jason Duell made a very good point in his message. This kind of change gives a huge advantage to Google, Facebook, Twitter, and other giants, because they would become *the* sites that could set cookies. Meanwhile, ad networks like The Deck (http://decknetwork.net/) will be penalized. But, is The Deck really the type of network that people are really concerned about? Aren't people more concerned about Facebook and Google, who not only track them, but know exactly who they are, who they socialize with, the contents of their personal messages, what they've done in the real world, and what they plan to do in the future in the real world? Also, do we think that Apple was 100% altruistic in its blocking of third-party cookies? It seems to me that that choice is also the most financially profitable for them, because it puts Apple more in charge of advertising in Safari and on the iPhone. In fact, Google would also benefit from implementing this policy in Chrome, since they end up loading stuff from Google at startup, so they will nearly always be able to set a first-party cookie right away. Same with Microsoft and Bing. (BTW, Chrome doesn't *directly* implement any special optimizations to make google.com faster than other sites. However, many of the optimizations it does do are most effective for google.com due to the various ways that the Google website is set up to be the default for various things in the browser.) My interpretation of Brendan's comments is that we're about to hit a bunch of sites (often, it seems, the wrong sites) with a big stick, and we should make sure we are willing to deal with the fallout of that before we start swinging. I agree with that. But, also, we cannot be paralyzed by fear of the worst-case scenerios. Sid suggested I post my thoughts here in case others found them to be helpful. but, I haven't researched this issue in enough detail to help make the go/no-go decision here. Please let me know if there is anything I can do to help. Cheers, Brian |
Re: partial third-party cookie blocking | Brendan Eich | 2/1/13 5:06 PM | Brian Smith wrote:No, this was the part where I (started to) argue we need innovation beyond cookies. As stated plainly in the bug comment and here, I simply do not know whether the patch will bite back for enough users that it hurts more than it helps. Do you? See my more recent bug comment, though (https://bugzilla.mozilla.org/show_bug.cgi?id=818340#c37). I'm notionally in favor of the patch, provided we deal with possible problems here if possible, and via telemetry and other monitoring post-landing. There are a great number of possible tracking hacks. You've heard about the personalized document.lastModified hack? That's a good point, and one raised before. How do we know we won't start an arms race, though? I think it's better to provide a peaceful alternative. Client-side (private cloud, if good for back-up) innovation should provide something much better for both users and commercial players that operate transparently and in their customers' interests, generally speaking. My hope is we have enough time to do both: a bit of escalation with the proposed patch, a good chunk of innovation on the user agent side. How can the patch tell, by looking only at the cookie store, whether the user has visited such a site? History may not be reliable. What's the quality-of-impl fix? Google does not set tracking cookies from google.com, rather doubleclick.net or whatever it is. A site I never visit. So I'm not sure what you write here is true, but in general, "escalation" risks incumbents becoming advantaged. Yup. LOL, who ever said such a thing! See above -- there's a good wall at Google between search and advertizing. Different eTLD+1 names, different business units. Agreed. We need data. What we can't get in advance, or via TestPilot, we will have to get via Telemetry, and keep our eyes on. Thanks for posting. Have you done any custom telemetry work? Just asking ;-). /be |
Re: partial third-party cookie blocking | Devdatta Akhawe | 2/1/13 6:11 PM | > See my more recent bug comment, thoughThe first email was about turning this on by default. I suggest landing with default off, and measuring the breakage if we had turned it on by default. This can give us some data on whether we should turn it on. --dev |
Re: partial third-party cookie blocking | Brian Smith | 2/1/13 6:34 PM | Brendan Eich wrote:
> Brian Smith wrote:Yes, I think everybody agrees on this, based on lunch discussions with the people working on anti-tracking features. No, I don't know. That's what I was trying to say at the end of my email. I think we will definitely start an arms race. The only question is the scope of it. Sure. This would require us to consider the needs of advertisers to a similar extent that we consider the needs of other web developers. I suspect this is something that will be easy enough for us to agree to try, but I also suspect that the process will be pretty difficult and painful. The people working on this feature can probably come up with a better fix. But, my off-the-top-of-my-head suggestion is that we could do something like the following: 1. Every cookie already stored in the cookie database defaults to being third-party-only. 2. Every time we visit a site, mark all stored cookies that should be considered first-party for that site as not-third-party-only. 3. Don't add any new third-party-only cookies. 4. At some point in the future, remove all the third-party-only cookies. This relies somewhat on the fact that the internet basically works on the assumption that cookies are ephemeral; every site has to deal with cookies expiring and/or being deleted anyway. The length of time we wait to purge old third-party-only cookies could be very short without destroying the world. But, it would probably be good to have a large window (months?) to make this change as transparent to users as possible. BTW, it is tempting to try to find a way to do this using just by playing with the expiration times of the cookies. An exercise for readers, perhaps. [...] Yes, but let's third-party advertising on the web is eliminated completely by blocking third-party cookies in this way. It would hurt Google but it also helps them, because then advertising on google.com (and Facebook, Twitter, etc.) becomes more of a necessity for advertisers, and thus more valuable/profitable. And, other sites get less revenue and/or incur larger costs for setting up their own first-party ad systems. And, at any time, the big players (Google, et al.) can just change their policies to allow more sharing of information between their business units to enable their own third party ad programs to function as though none of this never happened. I am only one person, but the tracking that bothers me most is this kind of tracking that is so closely linked with my real-world identity, like what the +1, Facebook Like, and Tweet This buttons are doing. And, those are being served generally from the same eTLD+1 as the main properties of those companies. Also, we shouldn't read too much into "same eTLD+1" because two "unrelated" domains can still share information, at least when you visit the main property. I think there are people working on this feature who know how to do the telemetry work already. I will be glad to help them if they need it, though. Cheers, Brian |
Re: partial third-party cookie blocking | Sid Stamm | 2/7/13 8:45 AM | This makes sense if we are convinced it is very likely to cause problems
resulting in it being disabled. I don't think this is the case and we don't gain much by pushing it to nightly and waiting for telemetry numbers to come in. We should just push it to nightly and take the tiny risk that we have to push a two-liner to pref it off. We should still gather telemetry (especially as bsmith says, to gather a baseline), but we can get preliminary/informal testing done NOW while we work on the telemetry patch. This is why we have our multi-channel release model: bake time. Lets use it. -Sid |
Re: partial third-party cookie blocking | Jonathan Mayer | 2/7/13 5:21 PM | In the interest of efficiency, I'm drawing together a few on- and off-list points.
* Doesn't this cookie policy have some false positives and negatives? For sure. Some instances of third-party tracking (e.g. Twitter buttons) aren't always covered, and some unobjectionable practices (e.g. iframed Facebook apps) may be covered. There's plenty of follow-on work to do in evaluating and improving the policy. In the interim, we shouldn't let the perfect be the enemy of the good. * Won't third-party trackers just work around the new cookie policy? Websites that circumvent the new cookie policy may face serious legal consequences, including Federal Trade Commission enforcement and private litigation. * Didn't Apple implement Safari's cookie policy to mess with its competitors? The feature dates back to Safari 1.0, which launched in 2003. It wasn't an anti-Google move. At any rate, I don't think Apple's motives should have much influence on the Mozilla community's decision making :) * What if we land the new policy but disable it by default? Sid addressed this, and I share his views. I would add that one of the very reasons for providing a relaxed cookie policy is to allow enabling it by default. Jonathan |
Re: partial third-party cookie blocking | Corry, Bil | 2/8/13 2:16 AM | While the below appears well-reasoned, the issue is it's framed entirely around privacy.
Developers building a web application rely on cookies to maintain state, and when the browser doesn't appear to work properly, they consider it damage and route around it. What you refer to as "circumvention," developers would call "working around a non-standard browser quirk." That's because cookies were not designed to convey the privacy choice of the user and developers do not expect the absence of a cookie to mean "do not store state for me." When cookies go away, devs may use other methods to store state - their endgoal is to make their app work for the user. A user's privacy choice should be conveyed via DNT, that's what DNT is for. If Mozilla really wants to convey privacy signals using cookies, it should work to update RFC 6265 to specify this behavior so that everyone has the same context and expectation. I have two suggestions if this lands in a future release: 1. Launch an education campaign letting devs know that the cookie behavior is changing and if they work around it, they're on the hook for the legal and financial implications. It'd be cruel to set this trap without any warning to those who will get ensnared. 2. Rather than blocking cookies, make them session cookies. At least the web apps will continue to work and the cookie will evict when the browser is closed. It also mostly avoids the issue of devs working around the behavior without understanding the legal exposure. - Bil > _______________________________________________ > dev-privacy mailing list > dev-p...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-privacy |
Re: partial third-party cookie blocking | Monica Chew | 2/8/13 11:15 AM | >From my point of view, there are two successful outcomes from this discussion.
1) The patch lands and doesn't need to be rolled back. 2) The patch lands and is rolled back due to user complaints, and the bug is resolved WONTFIX. This is a great outcome, because it gives us concrete data about what solutions don't work, doesn't depend on yet another review cycle for the telemetry patch, and it's still progress. The worst possible outcome is that the bug remains opened for years and the patch languishes. I agree with many of the concerns discussed above and in fact argued against writing the patch in the first place in https://bugzilla.mozilla.org/show_bug.cgi?id=818337#c2. However, now that the patch has been written and reviewed by a cookie peer, it seems like a gross misuse of contributors' time and goodwill not to try it out on at least nightly users. If it would make people feel better to test this on nightly users for more than one release cycle, then I suggest wrapping the new default pref in #ifdef RELEASE_BUILD (https://bugzilla.mozilla.org/show_bug.cgi?id=820148). Thanks, Monica |
Re: partial third-party cookie blocking | Sid Stamm | 2/8/13 2:08 PM | Hi Monica,
I think there's a third outcome that we shouldn't discount, though perhaps not as good as the other two: the patch lands, but due to breakage we have to revert the default to today's status quo. This is better than letting the patch sit and languish in a bug, but I think this is the worst-best outcome. I really don't want this to happen, and I doubt if it will. We need to either determine this is productive and useful or build enough data to WONTFIX the patch and I think everyone here agrees that we need closure -- we just don't agree on which.. Hey, this is cool, I didn't know about that #ifdef. Looks like if we land it now, we can ship it to the world on the regular trains (21) and while the functionality would ship in 21 it would automatically be preffed off when it hits Beta -- unless of course we decide to change that before the 21 beta branch date. -Sid |
Re: partial third-party cookie blocking | Sid Stamm | 2/8/13 3:22 PM | Bil,
I'm trying to fully understand your concerns. Can you provide a few use case examples that break under this proposal but not if we make them session cookies? -Sid |
Re: partial third-party cookie blocking | Sid Stamm | 2/8/13 6:29 PM | Hi All,
Okay, we've stirred the pot a little bit and a few questions have bubbled up to the top as needing answers. (I'll reply to my own message with my thoughts on each as bullets after the question.) 1. What if sites start telling Firefox users they don't support the browser (and to use another one)? 2. Won't landing this patch and changing the default accelerate an "arms race" for third-party state storage? 3. We tried things like this before, and they were reversed. Why is this different? 4. Will nightly/aurora be enough time to test this out? 5. Won't this disadvantage the small guys and give the upper hand to big entities like Google and Facebook who have first-party relationships with users too? 6. What about localStorage and friends? 7. Won't this be ineffective since most Firefox users already have these third-party cookies in their profile? Let me know if I missed a concern that's not on the list. My current thinking is that we should land this next week once we've finished hashing these out and then follow-up shortly thereafter with some telemetry measurements and a test-pilot study to measure the effect of this and similar changes. -Sid |
Re: partial third-party cookie blocking | Sid Stamm | 2/8/13 6:35 PM | As promised, here are my thoughts on these questions. I feel comfortable
with most of this but we: * need a good story for #1 and 7, * a plan for #6 (bugs filed), * and Brendan to make a call on three timing and schedule questions: (should it land in 21 or 22? if 21, should we hold it back at the merge? should we revert the default when this goes to beta?). > 1. What if sites start telling Firefox users they don't support the > browser (and to use another one)? * Lucas brought this up, though I'm not aware of any live sites that are currently doing this. ACTION: need someone to find a few examples of sites that do this to one of the major browsers due to cookie handling. Personally, I think the best way to test whether this will happen or not is to land the feature in nightly, socialize it, and get some feedback from web devs. > 2. Won't landing this patch and changing the default accelerate an > "arms race" for third-party state storage? * Yes, this is a risk, so as Brendan pointed out we must also be working on other "peaceful alternatives". This is accelerant. We also need flame retardant. The W3C is proposing a "site-based-exception" API; perhaps we can do something similar for third-party cookies so sites can ask for them back. We have the plumbing to permit third party cookies per-site, but the UI isn't accessible. I don't intend to stop with this patch. > 3. We tried things like this before, and they were reversed. Why is > this different? * Double-keying cookies was a bigger change; it changed the cookie model in a more fundamental way. I liked that more, but try explaining two-key cookies to a non-technical person. It's more complicated to understand. * Previously, we tried to block *all* third party cookies (not just those for unvisited sites). See bug 324397. This breaks much more, and I suspect single sign-on is one of the things. > 4. Will nightly/aurora be enough time to test this out? * Let's assume we land in time for 21. The merge for 21 is really soon, and as Monica pointed out we could tag the code to automatically pref-off when it eventually gets merged to Beta. We can also hold it back in nightly for 22 if necessary. * If we use the #ifdef trick to autopref it off in Beta, we can more quickly push the bits out to everyone without changing the defaults. Then we can more easily ship a test pilot study to moar users (beta users, for example) to test it. This is much easier than packaging the patch up in a test pilot study (which may be next to impossible since this required C++ hacking). I say lets land it and let it ride the train. > 5. Won't this disadvantage the small guys and give the upper hand to big > entities like Google and Facebook who have first-party relationships > with users too? * Possibly, but it will also encourage the small players to cooperate with their first parties for cookies. This is what Google does for analytics (stores the cookies in the first party domain and uses JavaScript to transfer the cookie data into their domain). I don't think this cooperation is a bad thing since IMO the first parties have a duty to pick third parties that are in their users' best interest; requiring them to cooperate more closely means they will probably spend more time considering the effect of using those third parties. > 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. > 7. Won't this be ineffective since most Firefox users already have > these third-party cookies in their profile? * I swear I read a study that suggested a large chunk of people clear cookies at least monthly. I'll try to find it. I think that's good enough. -Sid |
Re: partial third-party cookie blocking | Asa Dotzler | 2/11/13 11:12 AM | On 2/1/2013 12:56 PM, Bil Corry wrote:
> On Feb 1, 2013, at 2:52 AM, "Jonathan Mayer" <jma...@stanford.edu> wrote: > >> I haven't come across Safari-incompatible content in years, presumably >> owing in some measure to the popularity of iOS devices. At any rate, >> it's certainly true that services that require measures to accomodate >> Safari would have to extend those measures to Firefox. > > What you refer to as "measures to accomodate" was referred to earlier by Monica as "counter-counter-measures". > > If a website works around the Safari cookie limitation in some manner to make the website usable for Safari users, is the website being accomodating, or is it deploying a counter-counter-measure? The question this raises for me is "If a website works around the Safari cookie handling, will we get that same workaround or are we expecting those sites to simply break for Firefox users?" - A |
Re: partial third-party cookie blocking | Asa Dotzler | 2/11/13 11:21 AM | On 2/8/2013 6:35 PM, Sid Stamm wrote:I'd like to weigh in on timing and schedule here. We're most of the way through 21 and some of my biggest concerns here are user impact related to changing web platform basics. How much are we going to break the web for our users is top of mind for me. I think we should definitely hold off until the opening of Firefox 22 or land knowing we don't intend to uplift to 21. We should maximize the feedback opportunities we have and I wouldn't be comfortable with anything less than a complete mozilla-central cycle. Agreed. We're not going to find broken websites without enabling this feature for more users. The best chances we have are to maximize the number of pre-release users who have this and watch their feedback very closely. We need to plan for easy mitigation if things don't go well. The design should accommodate the easiest and safest disable mechanisms for each train, all the way up to release. For example, we should be ready with a chemspill plan that can safely flip the switch for release users. - A |
Re: partial third-party cookie blocking | Asa Dotzler | 2/11/13 11:29 AM | On 1/14/2013 10:24 AM, Sid Stamm wrote:
> Jonathan Mayer has implemented a halfway-block feature for third party > cookies. > > Right now, Firefox can only block BOTH { setting + getting } of third > party cookies, so we can't turn it off by default. At least one other > browser has something about half-way that allows the getting of cookies > in third party contexts (but blocks setting). The effect is that sites > you visit directly can set cookies, but sites you don't visit directly > cannot. > > Anyway, I think we should ship this feature. I think we should ship it > enabled by default, but we need to do a few things first: > > 1. Write the code (almost done) > 2. Make sure users know the difference between this and full-strength > third-party cookie blocking. > 3. Make sure it doesn't cause too much breakage in the web experience. > > jmayer is working hard on the code. There's a reasonable UI in the bug > that teases out accepting cookies "from visited" as a new feature. > > https://bugzilla.mozilla.org/show_bug.cgi?id=818340 > > We are working on a test pilot study around cookies that might help us > get a good picture of how much is going to break when we turn this on. > If anyone out there has some data that can educate this, I'd appreciate > it. :) Sid, I'm in favor of moving forward on this, cautiously. As long as we have confidence at each step of the way that we're not breaking significant numbers of users or sites, this is a good move. Assume this spends 6 weeks in mozilla-central. How will we decide if it should be uplifted. What about from Aurora to Beta and to release? I've heard Telemetry and Test Pilot mentioned. What are the plans there? Also, is Support involved? They'll be an early indicator of problems here. Finally, is there any way for us to spider some top sites list and see what kind of cookie setting we're getting and if any of those top sites are using mechanisms that would fail with our changes? - A |
Re: partial third-party cookie blocking | Sid Stamm | 2/11/13 12:37 PM | On 02/11/2013 11:29 AM, Asa Dotzler wrote:Should we just do what we usually do? Put it on the train, monitor telemetry/support channels and pull it off the train (or hold it back) if something comes up? We don't usually have criteria for "advancing" things on the train; instead we need to know what will block it. What type of event/reaction/situation would cause you to advocate holding it back or backing it out? Telemetry bug: https://bugzilla.mozilla.org/show_bug.cgi?id=837326 After this discussion wraps up, I'll start a new one with hope of nailing down what metrics to gather for the questions we need answered. Monica is working on a more robust cookie study in Test Pilot that will uncover more about cookies than just how this one patch affects the web. Yes, I've looped them in and will send them a heads-up when it lands. They'll be working directly with me to ensure we've got inbound concerns spelled out and take any action necessary. Jonathan, have you any data on this kind of thing? I believe Monica's test pilot study was going to measure this "in the wild". -Sid |
Re: partial third-party cookie blocking | mco...@gmail.com | 2/12/13 11:13 AM | On Monday, 11 February 2013 15:37:03 UTC-5, Sid Stamm wrote:I think this is a flaw of the current train model, and we should not follow that model for this feature, or any other change which has obvious potential downsides that would outweigh the benefits of that change. For something of this nature, which has serious real-world implications for how the Web works (especially in terms of how the bills get paid for many sites), I would expect that advancing on the trains requires some measurable success against agreed criteria, and measurable containment of harm. I know we're not great at that now, but I think it's how we have to start thinking as engineers. -- Mike |
Re: partial third-party cookie blocking | Sid Stamm | 2/12/13 7:34 PM | On 2/12/13 11:13 AM, mco...@gmail.com wrote:I can see how that would be useful, but I'm not convinced we need to assume features guilty until proven innocent. I'll make sure when this patch lands we keep it on nightly (at least through the next merge) and we can work out criteria for advancement or back-holding. Often times with security and privacy features it's really hard to measure success -- many of them simply mean that nothing "bad" happens, and we have to try them out to see if the unexpected will happen. Measuring failure is easier, though, as a breach or anomaly means failure. Perhaps what we need is a set of failure criteria and watch for failure/regression as it rides the trains. So telemetry. Yes, we should figure out what we want to know and what constitutes success versus failure -- then measure it. Wanna start that discussion? -Sid |
Re: partial third-party cookie blocking | mco...@gmail.com | 2/12/13 10:55 PM | On Tuesday, 12 February 2013 22:34:59 UTC-5, Sid Stamm wrote:At the least, I feel like there are poorly-defined success criteria for this patch. I don't think it's a matter of guilty until proven innocent, but I will assert that we should not change core functionality without a strong understanding of what we expect as the overall outcome of that change. Perhaps "useless until proven useful" is a fair assessment? This is not an area of code where we can accept anything less than than solidly reasoned changes, even with the noble goal of improving user privacy. To be clear, I'm currently okay with landing (post-merge) on Nightly to get feedback. I'm not convinced we should let this patch ride the trains (regardless of default) until we have a much better story about why this benefits users overall, and why it won't just cause developers to adopt techniques that trivially bypass this protection. Google Analytics is already using first-party cookies (just search on "__utm" to see how widely this is used), so it seems as if this can be trivially bypassed without resorting to the myriad of other ways to track users without cookies. That would mean every tracker is recording data as the first party, making tracking and blocking much more complex. If that happens, we're back where we are now, except that we won't have a useful answer to users who really want to block this type of thing. That's a significant net loss. We should absolutely identify indicators that we're failing hard, but I question the notion that we can't describe success in a way we can measure. That said, I've yet to come up with a success state that doesn't rely on developers doing essentially nothing to evade the restrictions, so I suspect getting to measurable indicators is going to be extra hard here. I'm happy to do what I can to make that work, but I think it will require some deep thought about how this will play out and how we get to where we want to be. -- Mike |
Re: partial third-party cookie blocking | Afowler | 2/13/13 1:34 PM | On Tuesday, February 12, 2013 10:55:48 PM UTC-8, mco...@gmail.com wrote:If the goal here is to stop tracking, then I think your comment is correct. A default change like this may have only short-term value to our users. However, I don't think that should be the goal. We continue to hear from our users that it's the nontransparent, unaccountable nature of third party tracking that gives them concern. While a first party's data handling practices may be complex, there's a direct relationship and an opportunity to learn about and, increasingly, control those practices via various mechanisms. In that context, tracking and personalization become more trustworthy and in the users' direct purview. |
Re: partial third-party cookie blocking | Brian Smith | 2/23/13 8:16 PM | Sid Stamm wrote: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? Did you find the study? IMO, if we're going to do this, it is worth doing it right. In the absence of compelling data indicating otherwise, if we figure that pretty much everybody has a doubleclick tracking cookie already, then I think we have to assume that a marge majority of our users will be tracked by doubleclick in perpetuity unless we fix this aspect of the bug too. I don't want us to have to water down our claims about how well the feature works and I don't want us to unintentionally mislead people about the effectiveness of the feature. Also, I think the plan I outlined earlier in this thread for how to accomplish this would not be difficult to implement, even if it doesn't have immediate effects. So, I think it would be good to get started on fixing this part soon. Cheers, Brian |
Re: partial third-party cookie blocking | Justin Dolske | 2/23/13 8:54 PM | On 2/23/13 8:16 PM, Brian Smith wrote:Could (and should :) we do something like: Add a timestamp for when the last first-party visit was for the site, and if you've not made a first-party visit within X weeks, drop the cookie. The idea being to continue to allow "grandfathered" cookies to work for a while, but drop them if the browser sees that the users behavior wouldn't have actually allowed them to have been set in the first place. Justin |
Re: partial third-party cookie blocking | mark.regi...@gmail.com | 2/23/13 9:00 PM | On Tuesday, January 15, 2013 8:42:13 AM UTC+11, Sid Stamm wrote:
> On 1/14/13 11:57 AM, Benjamin Smedberg wrote: > > * What is considered "third-party" in this context? e.g. are iframes > > > third-party? > > > Same as for our existing cookie stuff. Things that are different origin > > than the top level document. Can anyone clarify the exact situations that will allow a 3rd-party cookie to be set? The FAQ (http://webpolicy.org/2013/02/22/the-new-firefox-cookie-policy/#firefox-cookie-policy-fn3) states: "If a Firefox user appears to have intentionally interacted with your content, take the same approach as for Safari users.4 Examples of content within this category include Facebook apps and comment widgets where a user has typed text. If a user does not seem to have intentionally interacted with your content, or if you’re uncertain, you should ask for permission before setting cookies. Most analytics services, advertising networks, and unclicked social widgets would come within this category." This implies that cookies will not only be set in top-level windows (including pop-up windows), but also in iframes that have received any DOM event (click, touch, key press, or even move). |
Re: partial third-party cookie blocking | Brian Smith | 2/23/13 9:04 PM | Justin Dolske wrote:Brilliant! Cheers, Brian Earlier in the thread, Brian Smith wrote: > Brendan Eich wrote: > > How can the patch tell, by looking only at the cookie store, > > whether > the user has visited such a site? History may not > > be reliable. What's the quality-of-impl fix? > > The people working on this feature can probably come up with a better > fix. But, my off-the-top-of-my-head suggestion is that we could do > something like the following: > > 1. Every cookie already stored in the cookie database defaults to > being third-party-only. > 2. Every time we visit a site, mark all stored cookies that should be > considered first-party for that site as not-third-party-only. > 3. Don't add any new third-party-only cookies. > 4. At some point in the future, remove all the third-party-only > cookies. > > This relies somewhat on the fact that the internet basically works on > the assumption that cookies are ephemeral; every site has to deal > with cookies expiring and/or being deleted anyway. The length of > time we wait to purge old third-party-only cookies could be very > short without destroying the world. But, it would probably be good > to have a large window (months?) to make this change as transparent > to users as possible. > > BTW, it is tempting to try to find a way to do this using just by > playing with the expiration times of the cookies. An exercise for > readers, perhaps. |
Re: partial third-party cookie blocking | joakim....@gmail.com | 2/24/13 8:37 AM | On Monday, January 14, 2013 7:24:23 PM UTC+1, Sid Stamm wrote:> -Sid Many implementations contains a workaround for the mentioned Safari behaviour. A while back they allowed form posting to the 3rd party domain, but that was removed in later Safari versions. The workaround changed to requesting a user interaction like pressing a button to continue on the 3rd party domain. Will this workaround also be applicable to Firefox when this is released? |
Re: partial third-party cookie blocking | Mxx | 2/24/13 10:51 AM | It is my understanding that the dire for this feature is to protect users from tracking and not to break websites' regular functionality. Wasn't DNT header created specifically for that? Is there a proof that DNT failed and things need to be 'escalate' to the next level? It took a lot of effort to get all the browsers and advertising industry on board with that. Why the sudden change in attitude?
Are there browser statistics on what percentage of 3rd party cookies are advertising-related and what percentage are functional? I wouldn't be surprised if it was about equal split. Blocking them by default will piss off advertising/tracking/publishing industry from one end and publishing industry from the other end since it will break their website's functionality. The support channels should be ready for a flood of "stuck in a login loop" and "never ending redirects" complaints. |
Re: partial third-party cookie blocking | kits...@gmail.com | 2/24/13 12:03 PM | How would this affect the rather large amount of Facebook applications that are intentionally iframed thirt-party sites and where the primary content is from a third sites? Currently these applications have no reason to touch their own domain on the top level frame as navigation happens by instructing facebook where to go. I.e.
http://apps.facebook.com/1234567890/index iframes http://example.org/index http://apps.facebook.com/1234567890/test iframes http://example.org/test One issue in early versions of Safari 5 is that their cookie policy blocked cookies being set by iframed third party frames, so we would need to redirect out of Facebook, onto our own domain, set a cookie and then go back. This was the only browser that did so, and it has since stopped with that behaviour, I would very much prefer not to get that back. It seems to me that what would end up happening is that trackers and widget authors that feel they need cookies check for their cookie, if it's missing send the user to a return-to-referrer url and stick one on. Causing seemly random navigations. If the website has multiple widgets installed, this could happen multiple times as third-parties make sure their cookies are being set before the user sees the content they are after. Issues that can be worked around will get worked around by web developers, which in effect defeating the whole purpose of the patch while degrading the user experience. |
Re: partial third-party cookie blocking | Asa Dotzler | 2/24/13 2:11 PM | On 2/24/2013 10:51 AM, Mxx wrote:That is not the driver for this feature. We are not trying to stop tracking with this feature. We are trying to make tracking relationships more obvious to the user. - A |
Re: partial third-party cookie blocking | Asa Dotzler | 2/24/13 2:13 PM | On 2/24/2013 12:03 PM, kits...@gmail.com wrote:This should work just fine for Facebook applications. I've been running with this setting since its first availability and I have experienced no problems with any Facebook applications. If you have specific sites that you can demonstrate break as a result of this change, please let us know. Speculations around catastrophic web breakages aren't particularly helpful without specific examples of actual breakage. - A |
Re: partial third-party cookie blocking | mxx...@gmail.com | 2/24/13 7:01 PM | How is blocking by default going to make it more obvious? Once sites will start nagging users to go into their browser options to turn it off 3rd party cookie blocking? Or will there be a prompt asking user if they want to accept each and every 3rd party cookie?
By blocking cookies by default are you not making that decision for your users without consulting them. This was similar issue with DNT header being enabled by default in IE10. MS made a decision on users behalf without asking for their consent. If Firefox will block 3rd party cookies by default, wouldn't it be helpful to sites if it send a signal that it does that. This way sites right away can adjust their behavior/logic and know at the 1st request time what to do rather than try to set/read cookie action every single time, then perform other redirects and tricks to try to accomplish what it needs to. I can see that having a negative user experience/performance. But this is experience of a single user with a limited number of sites. How will shopping carts work that do multiple redirects to/from paypal, google wallet, amazon merch and similar sites? What about sites that use rpxnow.com and similar for their login/authentication systems? How will this affect RUM services like Torbit, lognormal/soasta and similar? How about Liveperson and similar 'customer engagement/support' applications? |
Re: partial third-party cookie blocking | Dennis Dayman | 2/24/13 7:47 PM | On Sunday, February 24, 2013 9:01:32 PM UTC-6, mxx...@gmail.com wrote: > By blocking cookies by default are you not making that decision for your users without consulting them. This was similar issue with DNT header being enabled by default in IE10. MS made a decision on users behalf without asking for their consent.just tell visiting users you don't support FF and to download Google Chrome... :) I know, that isn't a solution for this, but man its tempting. -Dennis |
RE: partial third-party cookie blocking | Bil Corry | 2/25/13 3:48 AM | I fired up Nightly and set the DNT preference to 0 (aka "Tell sites I want to be tracked"). So even though I said I wanted to be tracked, when I visited a site with third-party content, all third-party cookies were blocked.
This brings up some questions: 1. To me, as a user, this is non-intuitive. Is there a way to harmonize cookie behavior with the DNT preference? 2. What does Mozilla recommend as a best practice for third-parties that have permission to track, but can't because of this new cookie policy? 3. If third-parties can't ever set state on the browser, then what's the point of DNT (since tracking is always blocked)? 4. Mozilla publicly came out against a default choice for tracking[1], yet this new cookie policy runs counter to that position by blocking tracking by default. Does Mozilla still believe tracking is an expressed user preference? Or only for DNT, but not cookies? It's somewhat hollow to say DNT should be a user-expressed preference, then prevent tracking regardless of that preference. - Bil [1] http://blog.mozilla.org/privacy/2012/05/31/do-not-track-its-the-users-voice-that-matters/ |
Re: partial third-party cookie blocking | Sid Stamm | 2/25/13 1:26 PM | On 02/23/2013 08:16 PM, Brian Smith wrote:Not sure if this is the same study. I'm still digging for more examples. http://www.aleecia.com/authors-drafts/tprc-behav-AV.pdf "9% said they never clear cookies, 9% believe they clear cookies themselves annually or less than once a year, 16% a few times a year, 10% monthly, 17% a few times a month, 16% a few times a week, 12% daily, and 8% clear cookies every time they close their browser. This is self-reported data, but about 70% believe they clear cookies at least once a year." So if I read it right, 53% are likely to erase cookies within the first month of encountering this feature. -Sid |
RE: partial third-party cookie blocking | Alexander Hanff | 2/25/13 1:39 PM | I would take that with a very large pinch of salt. Psychology has taught us
for decades that people often tell lies to interviewers and on questionnaires - it is very common for participants to say what they think the researcher wants to hear and there is also the added factor of people who say they do something because they don't want to "look stupid". My experience of working with people in the field is very few "ordinary" users (the vast majority of home PC users) do any sort of housework whatsoever - most of them don't even bother to update their anti-virus let alone clear their cookies. I would be more than a little surprised to find that anything like 53% of the worlds' PC users ever clear their cookies, let alone once a month - I doubt even 25% do. Alexander Hanff _______________________________________________ dev-privacy mailing list dev-p...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-privacy |
Re: partial third-party cookie blocking | Sid Stamm | 2/25/13 1:47 PM | On 02/25/2013 01:39 PM, Alexander Hanff wrote:Agreed, which is why I'm still digging around for other studies that measure, not ask. It's just a data point (better than none). If you've got another study, point it out! My experience has been the opposite; my interactions corroborate what is in that research paper (roughly half do something to clear cookies). This is why I'd like to see research data that measures so we're not relying solely on interview-honesty and gut feelings. -Sid |
Re: partial third-party cookie blocking | lisamo...@gmail.com | 2/25/13 10:23 PM | life is too short
|
Re: partial third-party cookie blocking | Artur Kania | 2/26/13 9:40 AM | Hi
I have different use-case which will be broken if Firefox will block 3rd party cookies. User is visiting a.com - b.com want's to integrate some features to a.com - so it's running some javascript on a.com, also it's using iframes to communicate/authenticate with b.com services using JSONP ( it needs cookies on b.com to authenticate requests ) - it's commonly security pattern for browser that don't support CORS ajax reqeusts. If user never before visited b.com whole flow will be broken - only option is to detect that cookies are blocked, and ask user to visit b.com. What are your thoughts about it? |
Re: partial third-party cookie blocking | Sid Stamm | 2/26/13 9:58 AM | On 2/26/13 9:40 AM, Artur Kania wrote:Is this a common pattern targeted at browsers like Firefox that *do* support CORS ajax requests? Do you have a specific example of a live site that uses this pattern? I'd like to peek at an implementation. -Sid |
Re: partial third-party cookie blocking | kani...@gmail.com | 2/26/13 10:43 AM | > > - it's commonly security pattern for browser that don'tSorry, your right - Firefox supports CORS, bad example - apologize I'm want describe situation when a.com is including code from b.com - as i wrote b.com is creating iframe ( hosted on b.com ) that is communicating with b.com services - it uses cookie that are set on b.com ( don't wont/can't set them on a.com ) to authenticate requests and receive data which is send back to a.com main window. Even when using CORS - we would need to have cookies set on b.com Use-case is - first time user - never before visited b.com - is opening a.com In that case browser will not set cookies on b.com for him. It can be designed in different way ( proxy etc ) Sorry but don't have example of any live site - but still i think it is possible for services that want to include some widgets/features to other pages. |
Re: partial third-party cookie blocking | adechavagn...@gmail.com | 2/26/13 11:53 AM | On Monday, January 14, 2013 7:24:23 PM UTC+1, Sid Stamm wrote:Is this great idea been inspired by google the first contributor to firefox? It will be the only one to be able to put cookie on every firefox user (as it has paid 1Mds$ to be on the first page)... for is own benefit only of course! -Alex |
Re: partial third-party cookie blocking | Sid Stamm | 2/26/13 2:21 PM | On 2/26/13 11:53 AM, adechavagn...@gmail.com wrote:I am pretty sure the default home page in Firefox is "about:home", which is local content (except for some snippets that come from Mozilla). If you do a search from that page, yes, you go to google.com, but not if you don't do a search. -Sid |
RE: partial third-party cookie blocking | Alexander Hanff | 2/26/13 2:30 PM | I mentioned to you yesterday Sid that on a fresh install of Mozilla Firefox
the second you open Firefox for the first time a Google.Com cookie is placed in the sqllite file without ever visiting a web site or doing a search. This immunizes Google from this new policy.
Sent: 26 February 2013 23:21 |
Re: partial third-party cookie blocking | Sid Stamm | 2/26/13 3:02 PM | On 2/26/13 2:30 PM, Alexander Hanff wrote:You're right about the cookies, but those are not search cookies from about:home. Those are for the safebrowsing phishing/malware protection service. We'd like to isolate those cookies from your web cookies so google.com isn't given this elevated status. The idea is to have a separate cookie jar for safebrowsing cookies. If you or someone you know would be interested in writing a patch for this, we could use the help (and I'll help out with it). https://wiki.mozilla.org/Privacy/Features/Multiple_Cookie_Jars -Sid |
Re: partial third-party cookie blocking | let4...@gmail.com | 2/27/13 3:48 AM | Hi,
This is a big mistake to introduce such feature, because FireFox has big auditory. This action will brake advertisement ecosystem quality and targeting. It will block DMP, SSP and DSP business. NAI has an answer for enabling feature "Do Not Track" by default. But this answer relates to this topic too: Why NAI Cannot Support DNT On-by-Default Media coverage related to Microsoft’s recently expressed intent to implement Internet Explorer 10’s ‘Do Not Track’ (DNT) function by default in its next release has compelled thoughtful responses from many stakeholders in the digital advertising and publishing ecosystem and NAI member inquiries. NAI can’t accept a browser mechanism that threatens the health and vitality of the entire online ecosystem. This does not mean we oppose user choice; in fact, we’ve been working at the W3C and elsewhere on standards for browser-based choice mechanisms. The DAA, too, has committed to implement a browser-based choice mechanism based on its guiding principles. But with a default-on mechanism, the impact on small online publishers and third-party technology providers, which are vital to today’s Internet, would be nothing short of catastrophic. Publishers of free content, services, and entertainment may move behind pay walls, or may disappear altogether, if they can’t monetize their content with targeted ads. For many third party companies, which facilitate interest-based ads or personalization, a default-on system jeopardizes their business – meaning no business. I don’t like to inject hyperbole into this discussion, but we are talking about no less than thousands of lost jobs and billions of dollars in lost revenue. Others have raised concerns that the Internet becomes a handful of giant publishers and providers who will develop advertising models that work around Do Not Track altogether. Such an outcome may be OK for some stakeholders in the debate – a reasonable casualty of default Do Not Track — but that is little comfort to the threatened businesses in the NAI who are working hard now to create relevant advertising while respecting consumer privacy. Numerous tools and choice mechanisms (such as browser settings, plug ins, and self-regulatory programs) already exist today for consumers who have privacy concerns about interest-based advertising. A new browser choice mechanism could be beneficial to the Internet, but not if it presents an “off switch” to every online user without explaining the consequences of flipping that switch for the online content they enjoy, and certainly not if that switch is flipped by default by the largest online players. If you have questions about these commitments or our position on DNT being turned on by default, we encourage you to contact us directly. http://www.networkadvertising.org/blog/why-nai-cannot-support-dnt-default |
Re: partial third-party cookie blocking | Tetsuharu OHZEKI [:saneyuki_s] | 2/27/13 8:47 AM | Hi, I have an question.
I feel from Sid or Jonathan's comment, we are testing the new policy & looking for feedbacks about it. However, why have we finished to introduce the telemetry data collection for measuring effect of blocking some third party cookies yet? The bug has already been filed in 2013-02-01. But its comment are is very silent and there is not any patch. https://bugzilla.mozilla.org/show_bug.cgi?id=837326 For testing something & looking for feedback them, I think we should introduce the telemetry for measuring effetct. And it need to introduce immidiately with tested function. It's all the more necessary in this case which may have big impact that we cannot predict well. If there is no measuring, Some people would seems that this test of the new policy has had some of speculation. When will we introduce the telemetry about it? Wil we land it in this week? |
Re: partial third-party cookie blocking | Sid Stamm | 2/27/13 9:48 AM | On 2/27/13 8:47 AM, Tetsuharu OHZEKI [:saneyuki_s] wrote:We landed the feature without telemetry because people can *try* it and *tell* us what breaks. This can be done immediately. But yes, I agree, we need to gather telemetry data too. Probably not this week, but we're hoping very soon. If anyone wants to pitch in and help figure out what questions to answer and then write the telemetry patch (Jono?), please do! -Sid |
Re: partial third-party cookie blocking | Tanvi Vyas | 2/27/13 11:06 AM | On 2/24/13 10:51 AM, Mxx wrote:I have third party cookies blocked all together (and have for probably about a year) so all third parties, regardless of whether they were once a first party, can't read or write cookies. I have been able to complete almost all my tasks with this setting. The only time I had to open a new browser or browser profile was for purchasing something on target.com or logging into citibank.com. I haven't tested what happens on those two sites with the partial third-party cookie block. Clicking "show prices" for hotels on tripadvisor.com also behaves a little differently (new tabs instead of new windows?) but is still fully functional. The best ways to test this new feature and to see if it breaks functionality are 1) download nightly and try it out (maybe clear your cookies first so only actual first parties are allowed in a third party context) and 2) telemetry.
> Could (and should :) we do something like: Add a timestamp for when the> Justin This might not work. Imagine a site that requires a 2-factor-auth cookie but that a user doesn't log into frequently (maybe a bank account or a 401K). Not sure if these 2-factor-auth cookies ever expire, but if they do, some don't expire for more than a month (maybe 90 days?). When the user visits this site after 2 months of having the new pref, it will request the 2nd factor auth data (maybe an account number). This will happen to the user every two months when they want to check their 401K status until we drop the "grandfathered" cookies code. Maybe we are okay with this? Maybe we can account for when the cookie was created, and if it was created after the partial-third party cookie setting was set, then we don't delete the somewhat stale cookies. This way, the user only has to deal with this second factor auth issue once. ~Tanvi |
Re: partial third-party cookie blocking | Jono Xia | 2/27/13 11:43 AM | Yes! It sounds like writing the patch to collect this data is pretty important, and I have at least a vague idea how to do it, so I will volunteer to take that on. I would say the data to collect would be 1. Count of 3rd party cookies that would be blocked under the proposed policy (and maybe their domains, if collecting those domains is copacetic with our privacy policy) 2. Count of 3rd party cookies that would not be blocked under the policy (so we have something to compare to) 3. Timestamps at which the user cleared cookies, so we can answer the question of how frequently they're cleared. (Adding Gregg to the conversation) Hi Gregg, You've been following the discussion about blocking third-party cookies from sites the user hasn't visited, yes? I've been out of the loop on Test Pilot -- does the User Research team have any studies in the pipeline about cookies that would help answer the above questions? I don't want to duplicate work here. Since this is not particularly a user-interface-related study, it seems like Telemetry rather than Test Pilot is probably the way to go -- does everybody agree on that? Thanks, --Jono |
Re: partial third-party cookie blocking | clin...@gmail.com | 2/27/13 7:36 PM | Hi all,
I just wanted to put out a situation. I have used embedded iframes for shopping carts (there are indeed carts which can be placed in an iframe, and cookies set in an iframe are considered third party in my understanding). These shopping carts don't let the viewer of the site to go to the main site where the owner of the page set up his embeddable store. The requirement for this feature to allow third party cookies is to allow it if the person has gone to the actual site. Wouldn't this break this and other similar iframe based plugins? - Clint |
RE: partial third-party cookie blocking | Bil Corry | 2/28/13 12:15 AM | This breaks:
http://www.aboutads.info/choices/ - Bil
|
Re: partial third-party cookie blocking | nigel.ed...@gmail.com | 2/28/13 7:39 AM | On Thursday, 28 February 2013 08:15:02 UTC, Bil Corry wrote:Then this will also break: http://www.youronlinechoices.com/uk/your-ad-choices (This is the Europe-wide self-regulatory initiative for 29 countries that gives individual users the ability to control opt-out/in of OBA - online behavioural advertising.) |
Re: partial third-party cookie blocking | goo...@nartowicz.co.uk | 2/28/13 7:49 AM | I don't see the issue here. Websites to manage tracking cookies don't work because tracking cookies are blocked. Seems like this is the intention of the change rather than a failure. The policy is now opt-in for Firefox users rather than opt-out through a website that just sets more tracking cookies.
--ian |
Re: partial third-party cookie blocking | goo...@nartowicz.co.uk | 2/28/13 7:56 AM | I'm confused about the same-origin policy for iframes.
I have an addon that creates an iframe using javascript, and loads a third party page in it. That page set cookies, in apparent defiance of the preference. The cookies are not for the same origin as the page the frame is nested in and there are no other cookies set with the same origin. Am I wrong? Is an addon somehow a special case? Is this a bug? Is it a known and accepted loophole? --ian |
Re: partial third-party cookie blocking | goo...@nartowicz.co.uk | 2/28/13 7:49 AM | On Thursday, February 28, 2013 3:39:47 PM UTC, nigel.ed...@gmail.com wrote: |
Re: partial third-party cookie blocking | nigel.ed...@gmail.com | 2/28/13 7:39 AM | On Thursday, 28 February 2013 08:15:02 UTC, Bil Corry wrote: > This breaks: |
Re: partial third-party cookie blocking | Jonathan Mayer | 2/28/13 12:19 PM | For discussion of the interplay with self-regulatory opt-out pages like aboutads and youronlinechoices, see https://bugzilla.mozilla.org/show_bug.cgi?id=846159
|
Re: partial third-party cookie blocking | Jonathan Mayer | 2/28/13 12:22 PM | Third-party iframes should be covered by the new policy. If you can confirm an instance where they're not (using ordinary web content), please report it on Bugzilla.
|
Re: partial third-party cookie blocking | Jonathan Mayer | 2/28/13 12:19 PM | On Thursday, February 28, 2013 7:39:47 AM UTC-8, nigel.ed...@gmail.com wrote: |
Re: partial third-party cookie blocking | kani...@gmail.com | 3/5/13 1:01 PM | Hi
I would like to confirm one thing - regarding CORS(+withCredentials) ajax usage with cookies since i could not find any information about this. Will firefox also block setting cookies by CORS request response headers? I found that Safari(6) is doing it which from this new policy perspective is ok. But on the other hand it's making CORS+withCredentials less useful. |
Re: partial third-party cookie blocking | Jonathan Mayer | 3/6/13 10:22 AM | There are bugs open on CORS and JSONP compatibility:
https://bugzilla.mozilla.org/show_bug.cgi?id=844622 https://bugzilla.mozilla.org/show_bug.cgi?id=848437 Could you give a practical use case that you're concerned about? The only possibility that comes to mind is a third-party-only authentication flow. I'm unaware of any major service that's implemented that way, and it would be a bad idea for security reasons (i.e. no HTTPS UI). |
Re: partial third-party cookie blocking | Jonathan Mayer | 3/6/13 11:07 AM | I should add that another possibility is a cookie-free authentication mechanism that's used in a third-party context. (See the CORS bug.) I'm also not aware of any major service implemented this way; real-world use cases welcome.
|
Re: partial third-party cookie blocking | Sid Stamm | 3/6/13 2:56 PM | Hey Jono!
This is a great start at a list. I would recommend pairing research questions with each proposed collection so it's clear what we're gonna try to know. This is a good idea. What we really want to know is, "What kind of sites will not be able to set cookies?" Alexa categorizes sites, perhaps we can measure how many cookies per category are blocked? I'm imagining two histograms where the buckets are each category. One histogram counts blocked cookies per category and the other allowed cookies per category. What do you think? I'm not sure we can collect domains via telemetry, but perhaps we can measure some stats about cookie blockage per domain. I'd like to know both this and: what portion of domains where I send requests are disallowed cookies? There may be a few very persistent domains that try to set cookies frequently. Or it may be spread out. It would be good to know how widespread the blocking will be. Yes. This is important. Perhaps we can measure the timestamp on the oldest cookie in the cookie db and report that as a lower bound on cookie lifetime. Thoughts? -Sid |
Re: partial third-party cookie blocking | sweeney....@gmail.com | 3/11/13 12:24 PM | On Monday, January 14, 2013 1:24:23 PM UTC-5, Sid Stamm wrote:What about 3rd party cookies used in a 1st party context? I know that some technologies (ours included) drop a 3rd party cookie that is solely for use by the visited site. In this case, a cookie is being set by a 3rd party to enable functionality on the visited site that is not used in any way by the 3rd party or any other party. The function of the cookie is no different than that of a 1st party cookie. Is there any possible way to account for such a scenario? -SW |
Re: partial third-party cookie blocking | Jono Xia | 3/11/13 3:57 PM | Hi Sid,
Sorry I haven't finished this yet. I had a deadline for another project and spent all last week on that instead. Anyway, I talked to the telemetry guys about what it would take to implement this. As you said, I don't think we can collect domains via telemetry. It could be done via Test Pilot, though. I put together the following list of pros and cons of Telemetry vs Test Pilot and would like to hear your thoughts about which would be better. Pros of test pilot: - privacy policy, being opt-in, lets us ask for more info about domains where blocking happens/doesn't happen than would be kosher with telemetry - easier to implement (maybe?) since doesn't require landing patch with modifications to cookie manager and telemetry ping. (Also, I could write it much faster, given my Test Pilot experience, than I could implement a telemetry probe, which would be a first-time for me.) Pros of telemetry: - can reach nightly users, whereas test pilot mostly reaches beta/aurora (although some nightly users install the add-on) - start getting results immediately (well, as soon as telemetry ping happens) rather than waiting for experiment time period to complete as with test pilot - get slightly more representative cross-section of users (maybe? they're still nightly users either way) What do you think? --Jono |
Re: partial third-party cookie blocking | Sid Stamm | 3/13/13 10:24 AM | On 3/11/13 3:57 PM, Jono Xia wrote:I think we should do both Telemetry and Test Pilot studies for this. The time to deployment for Telemetry is significantly lower right now, so I think we should start with that and then take on TP studies with remaining queries. I'm more than happy to help you get a telemetry patch landed, if you can take lead and dig in to figure out what we should measure and also how. :) -Sid |
Re: partial third-party cookie blocking | Sid Stamm | 3/13/13 10:26 AM | Hi Sweeney,
Why do you drop a third party cookie when a first party cookie would serve the same purpose? Is it to correlate data across a few distinct domains? -Sid |
Re: partial third-party cookie blocking | Monica Chew | 3/13/13 1:02 PM | Jono, it's awesome that you're working on this. I agree with Sid. More reasons to do telemetry:
- It's the only thing that can give a longitudinal view of how cookie accept/reject behavior changes over time. Test Pilot studies typically last only a week, but telemetry's always on. - Test Pilot demographics are highly skewed towards power users, who almost certainly have different browsing patterns. Telemetry is separable by release channel. - Test Pilot is current disabled (https://bugzilla.mozilla.org/show_bug.cgi?id=832702). Monica |
Re: partial third-party cookie blocking | 3rdcoas...@gmail.com | 3/13/13 5:55 PM | Hey Sid,
You seem active here, and I've been scouring this thread for a bit trying to understand ad tech implications. Would you shed some light on the following scenario as I really dont see it explicitly spelled out: 1) As a consumer I visit target.com: - 1st party cookie set by Target.com 2) Simulatneous to that a bunch of ad tech companies set pixels & cookies as well - these are 3rd party cookies: - Turn (a dsp turn.com) - Dotomi (dotomi,com an ad retargeting company) - quantcast (quantcast.com analytics provider) - doubleclick / google (doubleclick.com / google.com etc) 3) Let's say doubleclick then makes another pixel call to another domain - (someadexchange.com) Are all of the number 2's acceptable (even though they are considered 3rd party), while the 3rd example someadexchange.com would be blocked? Lets leave the whole previous site visit concept out of the equation for now. Thanks |
Re: partial third-party cookie blocking | Sweeney Williams | 3/14/13 6:43 AM | One thing I forgot to add is that in our case, using a 3rd party cookie
allows correlation of data for a distinct company across their various domains and also allows for streamlined deployment. -SW |
Re: partial third-party cookie blocking | Sid Stamm | 3/14/13 9:09 AM | On 03/13/2013 05:55 PM, 3rdcoas...@gmail.com wrote:We can't really ignore the "previous site visit" concept, but we can start with a new install of Firefox and discuss "first visit" situations. Given your scenario, and assuming a fresh cookie store (no cookies), one visit to target.com would only result in target.com cookies. The rest (part 2 and 3) are blocked. If I click on an ad and get redirected through a quantcast page (for example) or the someadexchange.com page, that site can set cookies (they're a first party since they're loading in the top level of the tab). Does this help? Once a domain has set a cookie, it can continue to set cookies or modify them as a third party. -Sid |
Re: partial third-party cookie blocking | Jordan Williams | 3/14/13 5:52 PM | I've just discovered this group today, and I've been reading for the
last few hours. I have a bit of experience in this area, having developed an addon which does all this (cookie proposal) and more. In it's development, we went through the same processes mentioned in this thread: grandfathering in cookies, first parties can set cookies as third parties, limiting cookie lifespan, "click to activate" cookies, disallowing http cookies for non-first parties, etc. We've done tests for beacons, Etags, localStorage, and LSOs as well. Our current work is around a technical categorization of cookies for use in preference rules and exceptions. Basically we're categorizing cookies on the web. Backing up for a moment, "We know what is best for our users", doesn't sound like it should be a Mozilla philosophy. That sounds more like MS or Oracle. To think that tracking is the only functionality that this proposed change will affect is naive; like not believing in global warming. Every broken web service due to this change is a win for Chrome. Of course providing protection for users is important, but are you going to install x-ray passenger scanners in your airports? FF shouldn't be the one to enforce morality/legalities at the expense of user experience. And that's what this is: morality, not security. Whether or not Mozilla should do this is a pointless discussion apparently; it's obvious that you think you should, so I'll not bother arguing it further, I'll just end with "Mozilla should enable the community", not set defaults that break the web. Given that "change is upon us", the focus is rightfully on how to minimize negative impact and maximize user protection. Let me start with some information gleaned from my work: by far the most important cookies for third party service providers are set using document.cookie. And by an equally large margin, advertiser tracking cookies are set using HTTP requests. From the standpoint that blocking all cookies from third parties* is too fascist, the simplest way to stop user tracking while not interfering heavily with third party services is to only block third party HTTP cookies, not third party document-set cookies. Ad publishers are MUCH more picky about what JS they allow on their pages than beacons, so this wouldn't just cause a migration away from HTTP-set cookies. This restriction could even be stricter, but this would induce complications which, in my opinion, detract from the overall simplicity. Not to mention, that blocking third party cookies outright (ie. not doing my proposal) would just force trackers/providers to use localStorage instead - which has less transparency and user awareness. Thanks for the interesting read, looking forward to comments - JOrdan |
Re: partial third-party cookie blocking | 3rdcoas...@gmail.com | 3/15/13 10:44 AM | This is very helpful, thanks Sid. So last question, if someone installs the new Mozilla build does it wipe any of the previously set cookies (3rd party)? I am thinking it does not, and only if the user deletes all existing cookies would numbers 2 & 3 be blocked upon visiting a site for the first time (#1).
thanks |
Re: partial third-party cookie blocking | Sid Stamm | 3/15/13 1:18 PM | On 03/15/2013 10:44 AM, 3rdcoas...@gmail.com wrote:Currently Firefox does nothing with existing cookies. We're looking into how frequently people clear their cookies (it might not be necessary for us to do anything for them). But we're also evaluating other options like expiring cookies that aren't used in a first party context for a while. Nothing concrete yet, do you have some ideas? -Sid |
Re: partial third-party cookie blocking | claude....@gmail.com | 3/25/13 1:57 PM | Hi,
Our web application is a composite one where external apps can be injected in the main content flow. For example a reading activity can embed an assignment. We are naturally using IFrames for that. As the apps that are embedded are usually complex pre-existing apps, they are more often than not relying on session cookies and are originating from another domain. We have kind of ignored the Mac/Safari issue up until now, but with this move, we must be more pro-active as the size of the potentially impacted population is much bigger (and from what I get things that were working will stop suddenly to work when the FF update is pushed). So what I am after is the recommended approach: should the embedded app recognize the cookie set was not honored and fire up a pop-up so set in a main window? Is that the recommended approach? Or is there a less intrusive (I’ve read DOM actions in the IFrame) that could be taken? Any guideline on how our embedded apps could be made ready would be appreciated! Thanks, Claude |
Re: partial third-party cookie blocking | stephane...@gmail.com | 4/9/13 3:21 AM | Hi Claude,
I am more or less in the same situation (actually, more more than less). Did you get make any progress in your research or dis you get any insights from your original post ? Many thanks ! Stephane |
RE: partial third-party cookie blocking | Bil Corry | 4/9/13 3:52 AM | I never saw a response to my inquiry below. The crux of it is this: I'm a third-party site that receives DNT:0, so the user has explicitly chosen to allow me to track them, but Firefox is blocking my cookies with this feature.
What does Mozilla recommend I do to set state on the browser? I can only assume based on how this feature is designed that Mozilla's position is that the user must set DNT:0 AND enable cookies from third-parties. Is that correct? Or will you be providing a playbook of workarounds for sites to use when DNT:0 is received? I did notice on the privacy roadmap[1] that this feature is listed as a P3 under "Not Yet Awesome Enough". Are there plans to also implement the P2 just above it, "Create API so sites can request third-party cookies"? Seems like that one is also needed to move this closer to the stated goal of making "tracking relationships more obvious to the user." As it stands now, Firefox disregards the user's DNT choice to be tracked and silently breaks some sites. Can you provide an explanation of how this feature is making tracking relationships more obvious to the user? Because all I see is a feature that by default silently blocks third-party cookies with the user completely unaware of what is transpiring. Obviously you can ship what you want, but if the expectation is that the user must change two different settings to enable tracking, then that isn't a meaningful choice for the user. You might as well be honest and declare Firefox to be a privacy-only browser; you can default to DNT:1, enable third-party cookie blocking, build in other technological measures to counter "tracking", and be done with it. You can't claim to support user choice[2] if you ship this feature as-is because there isn't any meaningful user choice being offered. - Bil [1] https://wiki.mozilla.org/Privacy/Roadmap/2012 [2] http://blog.mozilla.org/privacy/2012/05/31/do-not-track-its-the-users-voice-that-matters/ -----Original Message----- From: Bil Corry Sent: Monday, February 25, 2013 12:49 PM To: Asa Dotzler; dev-p...@lists.mozilla.org Subject: RE: partial third-party cookie blocking On 2/23/2013 11:11 PM, Asa Dotzler wrote: > On 2/24/2013 10:51 AM, Mxx wrote: > > It is my understanding that the dire for this feature is to protect > users from tracking and not to break websites' regular functionality. > > That is not the driver for this feature. We are not trying to stop > tracking with this feature. We are trying to make tracking > relationships more obvious to the user. I fired up Nightly and set the DNT preference to 0 (aka "Tell sites I want to be tracked"). So even though I said I wanted to be tracked, when I visited a site with third-party content, all third-party cookies were blocked. This brings up some questions: 1. To me, as a user, this is non-intuitive. Is there a way to harmonize cookie behavior with the DNT preference? 2. What does Mozilla recommend as a best practice for third-parties that have permission to track, but can't because of this new cookie policy? 3. If third-parties can't ever set state on the browser, then what's the point of DNT (since tracking is always blocked)? 4. Mozilla publicly came out against a default choice for tracking[1], yet this new cookie policy runs counter to that position by blocking tracking by default. Does Mozilla still believe tracking is an expressed user preference? Or only for DNT, but not cookies? It's somewhat hollow to say DNT should be a user-expressed preference, then prevent tracking regardless of that preference. - Bil [1] http://blog.mozilla.org/privacy/2012/05/31/do-not-track-its-the-users-voice-that-matters/ |
RE: partial third-party cookie blocking | Bil Corry | 4/9/13 4:02 AM | I never saw a response to my inquiry below. The crux of it is this: I'm a third-party site that receives DNT:0, so the user has explicitly chosen to allow me to track them, but Firefox is blocking my cookies with this feature.What does Mozilla recommend I do to set state on the browser? I can only assume, based on how this feature is designed, that Mozilla's position is that the user must set DNT:0 AND enable cookies from third-parties. Is that correct? Or will you be providing a playbook of workarounds for sites to use when DNT:0 is received? |
Re: partial third-party cookie blocking | joeb...@gmail.com | 4/11/13 10:20 PM | Blocking 3rd party cookies by default seems like "censoring" the Internet. I should have the choice by default, not Firefox. If Firefox does this, I will not use it anymore. Futhermore, when it comes to ads, I'd rather get an ad that I'm actually interested in.
|
Re: partial third-party cookie blocking | felix....@gmail.com | 4/12/13 9:24 AM | This implementation doesn't really help the user, it just helps the biggest publishers Google and Facebook. With that implementation you kick smaller companies out of business but still allow the biggest publishers (google, facebook) to track users across the web by using third party cookies.
By the way, why isn't it possible for publishers to decide who is allowed to drop third party cookies on its website? One could introduce a new header <meta allowcookiesfrom="...."> or <meta blockcookiesfrom="..."> . I think it's a good idea to let both the user and the website decide who is allowed to drop and read third party cookies. If the feature stays as it is I see it just as a big, big help for google in building a pure monopoly. |
Re: partial third-party cookie blocking | Sid Stamm | 4/15/13 2:46 PM | You still have the choice; we're not attempting to take that away. You
can turn third party cookies back on, or (in contrast) block all of cookies if you want. You can even pick which sites are allowed to use third-party cookies (though the UI for this is not quite awesome yet). -Sid |
Re: partial third-party cookie blocking | Dennis Dayman | 4/17/13 6:53 AM | Agree that their is choice switch, but the choice seems to be yours (mozilla) and not the consumer which seems like your telling them they are to dumb to do this
Webster define's Choice the act of choosing power of choosing Basically saying the individual makes the choices Why can't Mozilla create a proper set-up wizard like IE that gives the consumer choice at install or upgrade? Seems harmless and not hard vs. you burying this chosen method and them not knowing that have choice. Again, I have no issues with blocking cookies whether first or third, but its how you NOT giving the user ability to choose for themselves. -Dennis |
Re: partial third-party cookie blocking | Sid Stamm | 4/17/13 8:40 AM | On 04/17/2013 06:53 AM, Dennis Dayman wrote:Setup wizards aren't very effective from a user experience point of view. There is a limit to how many things we can ask before people decide "Firefox is annoying me" and never actually use it to browse the web -- and then how do we know what is "most important" to ask? There are literally hundreds of different things users can configure in the Firefox settings pane, and surely we're not going to ask them what they want for each and every one of those! Of course we very well could supply a "cancel" button or "express" configuration in such a wizard, but that very popular option would be chosen by most people and their Firefox would continue to carry the factory defaults -- effectively behaving the same as what we're doing now. Can you help me understand how this isn't providing choice? My impression is that it provides *more* choice than before because we're introducing a new option. Firefox users will always be able to change their cookie settings back to accepting all, blocking third party cookies fully, or blocking all cookies -- all in addition to this new setting which happens to be the new default. They have the power to choose (to put it in Webster's words). -Sid |
Re: partial third-party cookie blocking | alexbl...@gmail.com | 5/9/13 9:19 AM | > This won't affect cookies for sites that already set
> a cookie on the browser for what reason? what is the difference between site i have visited, and site i havent? this makes huge preferences for web-monopolies like Google, Facebook, so on. And it is doesnt seems pretty fair. |
Re: partial third-party cookie blocking | Tetsuharu OHZEKI | 6/20/13 8:16 AM | I read the post of Brendan's latest blog:
https://brendaneich.com/2013/06/the-cookie-clearinghouse/ In the post, I read like that Firefox introduces a exception list (black list or white one) approach as Safe Browsing for blocking 3rd party cookie problem. I understand Mozilla works for online privacy, and cheer its work. But this problem is not like so. I think it is bad approach about introducing exception list based system for blocking 3rd party cookie. Safe Browsing system has very cleary criterion and fair approach. Because its criterion is whether the website spreads the malware, or not. It's very simple and fair. However, the situation of 3rd party cookie is different from Safe Browsing.There is no clear rules to decide whether the website is bad "exception" or not. It's very ambiguity. So how do we decide the website is "exception"? It would be very floating definition by person. Of course, the website which is not respect DNT policy may be good definition. (In some country, Do Not Track approach is not legal definition.) But we cannot inspect in his server, thus we don't have a way to check it perfectly. I think that the "exception list" approach is not good for resolving 3rd party cookies problem. And Safari-like 3rd party cookie policy by default enabled is not resolve any problem. This is not good for web. -- Tetsuharu OHZEKI <saneyuki_s> saneyuk...@gmail.com |
Re: partial third-party cookie blocking | Monica Chew | 6/20/13 3:24 PM | Hello,
This is a valid point. You are right that it is not a perfect solution. In many ways the Cookie Clearinghouse approach reminds me of managing trusted CA lists. In both cases, the policy around who is "trusted" is difficult to specify, can't be enforced technically, can only be audited occasionally, and is rife with trouble. I don't think the question should be whether or not the Cookie Clearinghouse approach (or the trusted CA approach) is perfect, but whether it's better than the nothing. I think it might be. I did not get the sense from Brendan's blog post that the Cookie Clearinghouse approach was the end of the story. Firefox isn't just going to implement something without regard to whether it breaks the web. In fact, Cookie Clearinghouse is an attempt to *not* break the web. We shouldn't let fear prevent us from experimentation, even if that experiment fails. Thanks, Monica |
RE: partial third-party cookie blocking | Bil Corry | 6/21/13 7:30 AM | > I don't think the question should be whether or not the CookieI suppose it depends on which "nothing" you're looking at. If Mozilla simply leaves the cookie policy alone, all sites continue to work and users can still choose to block third-party cookies if they accept its given compatibility challenges. As a user, that's the default setting I want - a browser that works out of the box. I know the thought is to block advertisers from tracking users, but there's two problems with this approach, 1) there are non-advertising use cases that this breaks, and 2) advertisers are already moving to other state mechanisms, which leaves only the non-advertising use cases to bear the brunt of this feature. Granted, the Cookie Clearinghouse will help to some extent, but it's reactive and the earliest we'll see it in Firefox is toward the end of the year. The largest issue with the proposed cookie blocking scheme is that it silently fails, so the user believes the problem is with the website, when in fact the problem is with their (soon-to-be-default) settings. Perhaps the more charitable websites will educate the user on how to make the browser work again, which will require the user to change the cookie setting back to "normal" - what a pain for users and websites, with no net gain. If Mozilla is really going to push out the cookie blocking feature, it should do what NoScript, AdBlockPlus, and similar tools offer - a UI experience that alerts when items are blocked and allows the user to enable those blocked items. At least that gives the user a fighting chance to know what is going wrong. Additionally, the stated goal for this feature is to make cookies more transparent, what better way than to provide a UI that shows all the blocked cookies and allows the user to unblock them. It can work in conjunction with the Cookie Clearinghouse and wouldn't be much different than the IE compatibility view feature where there's a whitelist, but it also offers a UI for the user to override. The other related option to consider is an API so that websites can request an exception to the third-party cookie blocking. It's on the 2012 privacy roadmap, so presumably someone has given it some thought. Can you share the criteria of what constitutes failure for this feature? - Bil |
Re: partial third-party cookie blocking | Monica Chew | 6/21/13 8:39 AM | Hello Bil,
You are right that leaving everything alone means that no browser changes will break the web. However, by now I think it is clear that a substantial minority (11%) of users do care about tracking [1], and further more hardly any users (< 1%), even technological enthusiasts, know about or can manage their cookie settings effectively [2]. Going back to the CA analogy, accepting all CA authorities by default would certainly not break the web in the sense that pages will render effectively, but I am willing to bet that most people on this list would think that enabling all CA authorities by default is not a good idea [3]. I think the point of this effort was to move the ecosystem so that all users benefit, not just technology enthusiasts and privacy geeks. [1] https://dnt-dashboard.mozilla.org/ [2] http://monica-at-mozilla.blogspot.com/2013/02/writing-for-98.html [3] https://www.google.com/search?q=diginotar+revoke The current, experimental policy is only on by default in Nightly and Aurora users (0.1%), and so does not break the web for the vast majority of Firefox users who are on stable or slightly behind [4]. From my reading of Brendan's blog post the plan is to try out the Cookie Clearinghouse before progressing the new policy, so there shouldn't be a time when the false positive case you mention breaks the web for stable Firefox users. [4] http://en.wikipedia.org/wiki/Template:Firefox_usage_share I think that some reasonable success criteria would include: - Cookie Clearinghouse is able to come up with well-defined criteria for the lists and a reasonable way to maintain them - Firefox is able to consume the lists with negligible performance overhead - The lists function as intended (< x% for some small x false positives or negatives for stable Firefox users) - To your point about user confusion, in the case of false positives or false negatives, the UI is sufficiently enlightening for enough people to report the false positive or negative into Cookie Clearinghouse Thanks, Monica |
RE: partial third-party cookie blocking | Bil Corry | 6/22/13 1:48 AM | > You are right that leaving everything alone means that no browser changesI agree that a minority has set the DNT-1 signal, based on the information provided by the DNT Dashboard. It would be interesting if the DNT Dashboard also showed the number of signals received for DNT-0, DNT-unset (missing), and DNT-other (if any). For example, what would it mean if DNT-0 was also 11%? Those numbers could be interesting. Small aside: does the DNT Dashboard count raw requests, that is, could someone just ping the blocklist endpoint repeatedly to up-vote their favorite DNT signal? Expressing one's preference for DNT is not the same as "voting" for third-party cookie blocking. A better metric is to count how many people have actually enabled third-party cookie blocking, at least you'll be comparing apples to apples (i.e. counting people who have enabled cookie blocking to determine if the default should be cookie blocking). The weakness in this method is that for myself, although I have a variety of custom settings, I wouldn't expect Mozilla to make those the defaults for everyone, that is, I wouldn't want my custom setting used by Mozilla as a vote to make it the default. I think this illustrates that the UI needs to be reworked if users can't find or configure the cookie policy settings. I personally had to lookup where the setting was at, despite being a Firefox user for many years. It's definitely non-obvious that it's under "History", which I equate with browsing history, not cookies. But let's say you're right, the DNT-1 setting is a cry for help from 11% of users who can't figure out how to enable blocking third-party cookies, and they are representative of most users, who can't even set the DNT signal. If this is sufficient to enable cookie blocking by default, then surely it's sufficient to enable the DNT-1 signal by default? Or put another way, if 11% of users with DNT-1 enabled is sufficient proof that users don't want to be tracked, then why not default to DNT-1 "so that all users benefit"? I read Brendan's blog post, you're right, it appears this feature is on hold until CCH is available: "The CCH proposal is at an early stage, so we crave feedback. This means we will hold the visited-based cookie-blocking patch in Firefox Aurora while we bring up CCH and its Firefox integration, and test them." (source: https://brendaneich.com/2013/06/the-cookie-clearinghouse/) I guess that explains why Jonathan Mayer is seeing that this feature is being delayed: (https://bugzilla.mozilla.org/show_bug.cgi?id=818340#c103) Thanks for clarifying. - Bil |
Re: partial third-party cookie blocking | Ian Thomas | 6/24/13 3:15 PM | > On Thursday, 28 February 2013 08:15:02 UTC, Bil Corry wrote:
> This breaks: > http://www.aboutads.info/choices/ > On Thursday, February 28, 2013 3:39:47 PM UTC, nigel.ed...@gmail.com wrote: > Then this will also break: > http://www.youronlinechoices.com/uk/your-ad-choices On Thursday, 28 February 2013 15:49:58 UTC, goo...@nartowicz.co.uk wrote: > I don't see the issue here. Websites to manage tracking cookies don't work because tracking cookies are blocked. > Seems like this is the intention of the change rather than a failure. The policy is now opt-in for Firefox users rather than opt-out through a > website that just sets more tracking cookies. It's a subtle difference, but these websites manage your behavioural advertising preference, not your third party cookies preference. That means that a participating ad network could legitimately serve you behavioural advertising (using alternative tracking methods), but you would no longer be able to opt-out because Firefox had disabled their opt-out service. Ian Thomas (thelem) |
Re: partial third-party cookie blocking | Ian Thomas | 6/24/13 3:53 PM | Other than the posts by Bil Corey, the recent discussion on this thread seems to be about the details of the technical implementation. Have we even agreed that this is a good move for the eco system of the web, and especially for people who are privacy sensitive?
If this is implemented (and particularly if the other browser vendors follow Apple/Mozilla's lead) then developers will just switch to using other methods to track users, so in the end it will have zero benefit to privacy. Why suffer the range of problems mentioned in other posts if there's no benefit? It might be possible to convince me that this would be worth enabling for users who have opted out of tracking, but even then I think there are too many downsides. In my opinion it is impossible to prevent a user being tracked from one website to another as there are just too many ways of passing data, each of them serving a useful purpose. If we were to block all of them then the web wouldn't be anything like as powerful as it is today. That's not to say we should give up on privacy, but we should concentrate on the areas where we might succeed: initiatives such as Do Not Track and other more political and educational approaches. You should also not assume that users do not want to be tracked. Millions of people opt-in to having their grocery shopping habits tracked in return for a 1% discount and the occasional money-off coupon. Ian Thomas (thelem) |
Re: partial third-party cookie blocking | Sid Stamm | 6/24/13 4:31 PM | Hey Ian,
Thanks for your thoughts! I don't think we all agree it's the best route, but it's worth trying out. At least as initially conceived (in a way that blocks all unvisited sites) it has user-expectation and accuracy problems. Brendan has written up some of his concerns. https://brendaneich.com/2013/05/c-is-for-cookie/ I wouldn't write it off as impossible, but yeah, it's incredibly hard and would probably greatly degrade the web experience. Why not try both? DNT is not exactly quick to solve the problem, but it's still promising and may eventually be a better solution. Can we make cookies more useful *and* more transparent? Can we drive the fair players away from cookies onto some tech that's more useful for their purposes and also in better control of the users? I think there's lots of room for innovation here. I don't want to assume users hate tracking, but the opt-in rate to DNT is staggering -- higher than any off-by-default feature in Firefox. This means quite a few people want tracking control of some sort. So we should make the choice a fair one. People should have an opportunity to see what's happening and decide what they want for themselves before it has a major impact on their privacy. This behind-the-tech-and-hard-to-explain nature of the problem doesn't really make it fair. Not sure where you're shopping, but my frequent shopper card gives me more like 10%, the card doesn't automatically present itself and I know when the card is used and that it is used by only the grocery store (not the library or parking meters). So it's already far less subtle than cookies. If you track my purchases via swiped credit card without telling me it's for more than payments -- that's more like cookies. [0] Either way, I'm not sure people would be quite as excited about the loyalty cards if they knew more about how the data was used. I believe many people are under the impression that the card is just a reusable coupon with no side-effects ... which is not even close to the whole story. [0] http://www.forbes.com/sites/kashmirhill/2012/02/16/how-target-figured-out-a-teen-girl-was-pregnant-before-her-father-did/ -Sid |
Re: partial third-party cookie blocking | Ian Thomas | 6/24/13 5:44 PM | On Tuesday, 25 June 2013 00:31:11 UTC+1, Sid Stamm wrote:While Brenden's posts make some good progress, they're still trying to solve the implementation problem of "Can we block a high percentage of tracking cookies while allowing a high percentage of non-tracking cookies". I'd like to see more discussion about whether the principle of blocking tracking cookies would actually reduce tracking once the trackers had been given a chance to adapt. > > one website to another. >I think there are three fundamental requirements for a tracking network to operate: 1) You must be able to pass data between parties (e.g. myshop.com and my-analytics.com). This can be done behind the web server, so is impossible to block in the browser. 2) A single site must be able to identify a user as they move from one page to another. This is essential for any stateful website. 3) There must be some mechanism for identifing a user on one website as being the same user on another website. At the moment this is most commonly third party cookies, but there's a huge range of alternatives to use from localStorage through to real name. As far as I can see preventing (1) is absolutely impossible and (2) would break the web beyond recognition. There might be some scope for (3), but even if you managed to remove all the technological means for two websites to identify an individual, as soon as a user starts interacting with a site they're likely to reveal details like their name and email address. Maybe we can, but I don't think these proposals do that. They potentially inconvenience all web developers and would likely cause the services we are worried about to use less visible methods. Agreed, but to me that's an argument for tying any setting to Do Not Track, rather than enabling by default. This could be dumbed-down with some form of low/medium/high privacy slider - expose the intent, not the implementation (except to advanced users). This is heading off-topic, but very quickly 1% is standard in the UK and the same card can be accepted by multiple different businesses (I think the widest acceptance is http://www.nectar.com/collect.points). I don't know if they share data, but if not the technology wouldn't be hard. It is definitely more obvious than cookies though. Which brings me back to (3) above. Ian Thomas (thelem) |
Re: partial third-party cookie blocking | John Jensen | 6/25/13 5:11 PM | For Desktop users, the latest figures are: DNT not set = 89.28% DNT: 0 = 0.03% DNT: 1 = 10.68% Yes, but as of yet there is no evidence of that based on breakdowns of counts by geography, browser version, etc. -- John Jensen | Director, Metrics | Mozilla Corporation |
RE: partial third-party cookie blocking | Bil Corry | 6/26/13 2:09 AM | > > It would be interesting if the DNT Dashboard also showed the number ofThanks John for breaking it out. It's about what I thought it would be, but it's good to have confirmation. - Bil |
RE: partial third-party cookie blocking | frond...@gmail.com | 7/17/14 9:34 PM | All
|