On second thought, this doesn’t depend on 409, but the client (piwik.js) needs to know/reconstruct the 3rd party cookie name.

We do need #408 fixed (possibly in conjunction with this ticket).

A first party cookie set by the client is sent as a URL param, eg PK_FPC (we could have a default and allow it to be set, ala cookie_name on the server).

Since first- vs third-party depends on whether Piwik is hosted on the same domain as the site being tracked, I’ll refer to the current implementation as “legacy cookies”.

User stories:
- Legacy client, New visitor: Server sets legacy cookie
- Legacy client, Returning visitor: Client sends legacy cookie. Server reuses cookie.
- New client, New visitor: Client sets FPC. Server adopts FPC.
- New client, Returning Visitor: Client sets FPC and deletes (expires) legacy cookie. Server reuses FPC and clears the legacy cookie if received. (ie some browsers won’t delete cookie until session has ended/browser closed).

Need to add documentation re: P3P policy for IE6+.

Building on the new piwik.js, the implementation stalled on how the client would initialize the fpc (first time). Theoretically, we could implement the JavaScript equivalent of md5(uniqid(rand(), true)) /\* i.e., idvisitor in the current cookie implementation */

See http://phpjs.org for JavaScript equivalents of various PHP functions.

Dependencies:
- #408 allows the server to accept the client generated cookie and add it to the database.
- #409 shortens the cookie to simply contain idvisitor

Rolling in the requirements of this ticket into #409