Brian Smith wrote:
> Sid Stamm wrote:
>> In the bug, Brendan posted:
>>> 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.
>
> I 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.
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.
> 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.
There are a great number of possible tracking hacks. You've heard about
the personalized document.lastModified hack?
> 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.
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.
>>> 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.
>
> I think this is just a quality-of-implementation issue with the patch. I think this concern can be resolved in a reasonable way.
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?
>>> 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.
>
> 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.
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.
> 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?
Yup.
> Also, do we think that Apple was 100% altruistic in its blocking of third-party cookies?
LOL, who ever said such a thing!
> 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.
See above -- there's a good wall at Google between search and
advertizing. Different eTLD+1 names, different business units.
> 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.
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.
> 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.
Thanks for posting. Have you done any custom telemetry work? Just asking
;-).
/be