How would the latest changes announced by Chrome team impact Snowplow tracker? Are there any plans to incorporate the new header, “client hints” and update the fingerprinting enrichment?
@layerfive, Chome changes are addressed in the latest Scala collector. If you are using Clojure collector you are advised to migrate to Scala collector as Clojure collector is being deprecated and is not likely to cater for the changes announced the various browser vendors.
Here’s the post on Scala collector addressing the Chome changes that are expected in February: How to properly configure the Scala Stream Collector v0.16.0.
I think the UA-CH proposal is interesting but at the moment there are some critical decisions that need to be made in the draft spec before an implementation can be started (both in Chrome and within Snowplow).
For something like this I’d like to see the fingerprint enrichment deprecated entirely as parts of it are moot already with privacy changes and it will become even less valid in most browsers as the privacy sandbox rolls out. Instead I think the enrichment should be a ‘client hints’ context instead of a ‘fingerprint’ context per se - given that the intention of CH is to partially mitigate fingerprinting.
In terms of implementation it’s likely that this would need to exist as a:
- configuration change in the collector
- customisable enrichment
- additional non-Iglu central schema (as it’s not possible to make a Iglu Central Schema generic enough to necessarily capture all client hints - though it could include the ones in the spec).
Note: I think @ihor is talking about the SameSite changes which is a different Chrome change.
Thanks, @mike, you are right. I was too quick to reply. Still, my statement about switching to Scala collector stands.
Could you point out to that Chrome team announcement, please?
Some additional points with our thinking towards the UserAgent changes:
It looks pretty certain that useragent string will, over time, become less and less useful for identifying the browser, operating system and device, and this will impact users running the latest versions of the browsers (who are probably some of the most interesting) first
However, it is not clear yet what the best alternative will be to figuring this information out, and whether we’ll need to take a different, browser-specific approach. The Google approach - “Client Hints” may be adopted by others, in which case our focus should be on adding support for using that to fetch this data. But it might not be, so we might have to take a different approach
- If things get really complicated we might have to instead partner with a device identification specialist like Wurfl to use their tech to help us reliably figure what device, OS and browser an end user is running
We don’t use User Agent strings to detect/enable any functionality in the JS Tracker - it is all done via feature detection (i.e. asking the browser if it supports this feature)