Secure tracking about condor

[ralphtheninja]

What kind of data are you tracking?

[dominictarr]

@ralphtheninja it's user analytics. links clicked on, how far they scroll down, etc etc.

Idea: in first request, the server detects ip address, and hashes that with user agent, session etc into one token. the token should be deterministic given the data. it would be given to the client and uses as the id in the logs - but also stored in a database. then we know that if it is not in the database then it's not valid. could hash with salt so that it's infeasible to guess a valid id.

[dominictarr]

of course, someone could still get the token off the page and mess with the analytics by writing out funny data. there isn't anyway to stop that. so most of this would come down to validation. maybe rate limiting updates from one connection?

[ralphtheninja]

Sign the data somehow? Too expensive?

[sessa]

Just one thought -- Regardless of if we can sign the data or not there is a need to clean up the data anyways, and if so, can we handle bogus data then, instead of pre-empting it? (Ideally we do both, but perhaps short-term clean-up can handle most use cases and then we can figure out how bad bots or malicious users are abusing the endpoints?)

[heapwolf]

We can have predetermined types and lengths for the data on the receiving servers, maybe even some simple validation schema. This will protect against mal-formed requests.

Anything that originates on the client and isn't passed through the back end of the application is going to be untrusted. But that's not terrible since there aren't really any incentives for attack. This interface isn't (D)DOS-able.

[dominictarr]

signing the data will be quite cpu expensive (on both the client and server) we don't want to affect UX at by something the user is not getting anything out of. agree what we want is mainly filtering.

[will123195]

+1 simple validation schema