4 ms·

Could you explain what this POC shows?

• dillondoyle 6y ago
  sure. - basic js generates a css file with a random uuid and an example just my name. puts into a css var as a JSON object - sets long term cache headers AND a matching etag (same as uuid) - etag is a classic tracking trick but this is really cool it makes it accessible as state in JS client side - index.html prints/logs the css var - if css file is cached the uuid you see is static. no cookies needed - i was also going to add just an array of recent request domains, last and first session. would help test the chrome cache keying. could even put a jwt in there it's just a cool hack I never thought of. it's really cool how one thing can trigger an 'omg that's so obvious' brain fart. Like even before CSS vars you could have done this just set really specific css width 12.999933/122.3333 or something then measure the div you set or maybe simpler just a random "'uuid_"+the_uuid_var+"'" classname add to body and then read if it exists with js. But I never thought of it until I saw this article!!! Same with just generating a JS file with static var which I've played with but never deployed. though I might guess a css file is cached longer? idk i don't have proof of that just a guess could be wrong could maybe extend this to get around chrome cache keying with cname cloaking *edit actually maybe more likely that doesn't make sense idk i'd have to think about it or just reading their docs last night about their new policy (only a couple months old) it looks like webworkers aren't enforced yet and you can explicitly control & cache a file with JS in a webworker
  • dennisy 6y ago
    Thanks for that!