Can I avoid collecting sensitive browser attributes?

For engineers
1

I’d like to avoid collecting certain sensitive browser attributes that may trigger sensitivity for device fingerprinting. For example:

However, much of the webpage context written to atomic.events is super useful! Can I exclude collection (it is not sufficient to remove them after the fact) of a subset without having to fork the browser/javascript tracker?

Thanks!

2

It’s possible to write a plugin (in v3 of the tracker) to remove it before it hits the collector, but this will still be after the data has been requested from the browser. I think if you want to exclude parts of the payload entirely it’ll likely need to be integrated in the tracker directly - this is a nice idea for a feature though (particularly in light of privacy sandbox / budgets).

1 Like
3

Using v3 of the JS Tracker you could do this:

    window.snowplow('newTracker', 'sp', 'http://....', {
      appId: 'my-app-id',
    });

    const plugin = {
      ExamplePlugin: function () {
        return {
          beforeTrack: (payloadBuilder) => {
            const payload = payloadBuilder.getPayload();

            delete payload['cookie'];
            delete payload['cs'];
            delete payload['lang'];
            delete payload['res'];
            delete payload['cd'];
          }
        };
      },
    };
    
    window.snowplow('addPlugin', plugin, 'ExamplePlugin');

However, I recently noticed a slight issue with this approach which I’m looking to fix in the v3.2.0 release next week. You can currently only delete core payload values, like those described above. Any of the properties like vp (viewport size) or ds (document size) that are calculated for each event are not yet in the payload when the beforeTrack plugin function is fired.

As Mike suggests though, this might still trigger anything in the browser that is looking for something which reads these values. I can open an issue to make it easier to configure which values are captured by the tracker.

1 Like
4

Thanks, @mike , @PaulBoocock !

I’m using the browser tracker, but I think the same conclusion applies. I’m equally concerned about the appearance of data collection (e.g. reading browser attributes) as actual data collection (sending the event payload), so I may just see if I can (monkey) patch it out for now.

As an aside, I’m less concerned about vp/ds since these have clear use cases; it’s more things like cd and cookie which aren’t typically consumed except in libraries like FingerprintJS Demo.