iDatamining.org

I am looking for projects to work on
Please contact with me at yiyu.jia@iDataMining.org!

Wednesday, March 13, 2013

Blocking Third-Party Cookies may not be such a big deal for online adv industry

It is announced that Firefox will block third-party cookie by default as what Safari have been done so for years. (See blog posts Firefox getting smarter about third-party cookies and the New Firefox Cookie Policy).

This is big news in the online advertisement industry. There are many reports on the internet. As post "Imagining a World Without Cookies" points out, there will be winners and losers if there is no third-party cookies. I pretty much agree with their points. But, before publishers start cheering for this, they need to seriously think about what will be their solution to replace the third-party cookies from giants in the industry. Obviously, publisher should be able to produce solution to collect, store, analyze, secure, and share user behavior data.

But, if publishers are not able to implement such solution. What could happen? I think there are two ways to go at least. Publishers can either license solution from third-party software vendor or host javascript code distributed by traditional cookie collectors. I will call this javascript code as cookie proxy.


Figure 1. Javascript proxy convert third-party cookie to first-party cookie


As shown in Figure 1, current third-party cookie can be easily converted into first-party cookie. The difference/questions are,
  1.  Publishers need to host a third-party cookie Javascript proxy code on their domain. The proxy code expose API for traditional third party cookie generators to call for generate cookies.
  2. In other words, now, it is publisher's right to say if they allow third-party Javascript to be hosted on their domain. 
  3. One interesting questions is, to allow hosting third-party Javascript code, who will take the responsibility to promise the safety of third-party Javascript code. We can see normally, third-party cookie generators have deep dynamical Javascript loading, which make tracing code to be more difficult.
  4. The resource allocated by Web browser for certain domain is limited. So, how much do these resource cost for traditional third-party cookie generator? Will they pay for it? 
  5. Some experiments need to be done in the future to figure out if sub-domain can walk around the limitation of resource allocated for cookies. According to RFC, this may work. 
Anyway, from the technical side, this third-party cookie issue belongs to cross domain script (XSS). I listed several ways for cross domain script in post "seven ways for cross domain script programming". I dont know how Firefox will handle techniques listed there against blocking third-party cookie by default. yet. It will be interesting to explore it. But, one thing should be sure that Javascript loaded from third-party domain is allowed. Otherwise, WWW distributed computing model would be damaged and something wonderful is stopped, for example, CDN etc.

This event clearly determines that our Web is still evolving quickly. WWW obviously has more and more job to do after define HTML5. For example, one thing I observed and post as title "A war to occupy Internet user's Web browser " could be interesting stuff to be solved from the RFC level.

No comments:

Post a Comment