WebKit's Tracking Prevention Policy

[vamsiikrishna]

Hello,

I would like to use this issue to discuss the implications of WebKit's Tracking Prevention Policy
on the divolte-collector.

will it be impossible to use divolte.js to implement basic event tracking on webkit powered browsers ?

Thanks !

[friso]

Basic tracking will always work. Divolte is designed as a first party technology, and not developed with third party tracking as a use case in mind. As such, it sets first party cookies.

One caveat is that Divolte sets client side cookies (by writing to document.cookie), which are auto-expired by WebKit after 7 days of inactivity, meaning that users coming back to your property after that timeframe will be identified as new parties.

It might be possible to address the latter concern, by rewriting the client side cookies as server side cookies in the response to the pixel request, but I don't know if this will really fix it and whether it will be prevented by a later version of WebKit ITP. Keep in mind that this can only work if Divolte is hosted on the same domain as your property itself. On top of that, it's not guaranteed to go undetected by future versions of ITP if it even works right now.

[vamsiikrishna]

thank for the reply.

[asnare]

Stepping back a bit, I think it's also fair to say that:

• WebKit's TPP is aimed specifically at preventing third-party tracking. This is not the purpose of Divolte so there's not a conflict here.
• However the TPP does mention some things that may end up as collateral damage and that's too bad. First party tracking is specifically mentioned, so it's reasonable to expect that Divolte may be affected.

Of the ways that Divolte may be affected, the most obvious is the cookie mechanism that @friso mentions. The other area that I can think of is the pixel-image request that we use. Given that this is only used for tracking, I think it's reasonable to speculate that it may end up subject to a countermeasure if the browser folk can devise one.