A bit gleaned from Saul Hansell’s latest on Phorm, one of the ISP-level ad-targeting companies – they’re doing the tracking by piggybacking on other domain’s cookies. The Phorm box at the ISP appends a Phorm ID to the cookies of third-party sites without the third-party’s permission, and then reads it / strips it off without the third-party having any transparency into the process. (Go read the article for a more detailed description.)
This is smart from an infrastructure perspective – no need for a massive user database – but it raises significant questions:
1) Browsers tend to follow RFC 2109 and size-constrain cookies to 4096 bytes. It’s rare that you’ll see a cookie that large but it does happen – say, in the case of impression history for large ad networks, which is used for both frequency capping and conversion tracking. Is Phorm going to actually overwrite some of this information, messing with another ad network’s monetization?
2) Not every site sets a cookie. Does that mean Phorm will start setting cookies in that site’s name, containing only the Phorm ID? How does this mesh with the privacy policies of these sites, which might explicitly say that the site sets no cookies? What happens when a user reports a site in violation of their own privacy policy, due to a Phorm-set cookie?
3) RFC 2109 also calls for a browser to support at least 300 cookies. I believe most support more, but if Phorm is going to drop a cookie for every site any browser that does have limits – like, say, mobile, where space is constrained – is going to hit them rather quickly. Is Phorm’s behavior – a rather tricky way of getting around the twenty cookies per domain restriction – going to overwrite the cookies the user actually wanted to put there? Is Phorm’s behavior going to speed the overwriting of cookies from other ad networks?
Yes, user privacy is an issue, and that’s what’s going to be talked about most, but based on this article it looks like Phorm could very well interfere with the monetization strategies of other online businesses. Before I sent any business their way, I’d want to be damn sure they weren’t about to step on my toes elsewhere.
UPDATE: Thanks to BPT for pointing me to this blog entry and whitepaper on Phorm’s operation.
Note that point 20 on page 3 of the whitepaper makes it sound like this isn’t appending to an existing cookie but actually setting a cookie of its own in the domain’s whitespace. So if that’s the case, this implementation chops a cookie off of the maximum of 20 per domain. I can think of at least one extremely large social network actively interested in advertising optimization that’s not likely to be cool with that.
{ 2 comments… read them below or add one }
greg, refer to this blog to fully understand how Phorm works:
http://www.lightbluetouchpaper.org/2008/04/04/the-phorm-webwise-system/
join the queue of those concerned…
Browsers support *less* cookies.
IE: 20
http://support.microsoft.com/kb/306070
and sometimes 50
http://support.microsoft.com/kb/941495
I can’t google up a better link for the rest
http://en.wikipedia.org/wiki/HTTP_cookie
FF: 50
Opera: 30
And the failure modes are extremely poor. They might just all disappear if you exceed the limit. (This might be size of one, rather than the number of them.)
The RFC says “at least 300 cookies” and “at least 20 cookies per unique host or domain name”. It’s the latter that’s important.
With the tendency to have a session, a ‘remember me’, an ad network or two (probably 3-4 cookies), a tracker (1, 2, more?) it’s actually quite easy to hit that limit today.