2 ms·
If you serve a full bundle in response to each request then you've given up on caching for the fingerprinting library. If you're ok with giving up on this cach
by jefftk 6y ago
If you serve a full bundle in response to each request then you've given up on caching for the fingerprinting library.
If you're ok with giving up on this caching then you don't need cookies, you can have the server generate random-looking urls that it can later recognize are requests for the fingerprinting library.
- xg15 6y agoYes, I understand that. I think the point is that this part: > that it can later recognize are requests for the fingerprinting library. is made significantly easier to implement by web bundles. (Because with web bundles, the server doesn't need to understand the URLs at all) I agree however that it's questionable how well this technique would fit into real-life situations. I imagine as most ads and tracking scripts are not served locally, you usually wouldn't be able to embed them into a bundle anyway, randomised URLs or not.
- jefftk 6y ago> is made significantly easier to implement by web bundles. (Because with web bundles, the server doesn't need to understand the URLs at all) I agree it's a little easier than what I described because there are no longer separate requests to connect, but it's not much easier. On the other hand, if you're going to give up on caching and bundle everything into one file you could just have your server inline the tracking script. (Or use HTTP2's server push.) Taking a step back, your last paragraph looks right to me. Ad scripts are very rarely served locally because there is an organization boundary between the ad network and the publisher (and a trust boundary), and they're large enough that you do really care about caching.