-
Notifications
You must be signed in to change notification settings - Fork 78
WebKit's Tracking Prevention Policy #293
Comments
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 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. |
thank for the reply. |
Stepping back a bit, I think it's also fair to say that:
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. |
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 !
The text was updated successfully, but these errors were encountered: