| I definitely see your perspective here, but it also seems like something that isn't likely to be used. There's already good JS ways of detecting ad blockers that don't require nearly as much work. To take advantage of this, you'd need to alter your web application so that it'd do a two-stage rendering. Most web apps don't even stream their content (rather they wait until the whole content is ready, whether HTML or JS, and then send the whole thing). Your app needs to first send the HTTP 103 with the stuff to pre-fetch. Then it has to wait while holding the state and content it wants to push to the user. The longer you're holding that stuff in RAM, the fewer requests you can handle per second. Let's say you can handle 100 simultaneous requests and usually a request takes 10ms. Now you've handled that request and you're holding the response for 500ms to see if they hit the no-adblock-detector before sending the rest of the content. All of your Safari/iPhone users hate your website because every page load takes half a second. Awesome, you've pissed off the richest demographic browsing your website. You're paying more for server resources because you're holding onto state longer instead of getting the response to the user and freeing up that RAM so the requests per second you can handle drops. Ok, maybe you look at user agent and only use this technique for Firefox since that's the only browser it's effective with. In the demo, the DeferredInvoker basically generates a random string and associates it with a request (Map<string, request-response-thing>). Then when a request comes in for the no-adblock-detector, it looks up which request-response-thing is associated with the random string and sends the response to the user. If it doesn't receive a request for a string within a timeout, it'll send the response as adblock-detected. Of course, this only works for a single server since it's an in-memory map. How do we get it to work in a multi-server environment? Ok, we store "ABCDEF123" in a data store and hold the response until we see the request for "ABCDEF123" on the no-adblock-detector. Do we use listen/notify in PostgreSQL? I mean, at some point we're adding a lot of overhead for these requests. I have to store on my server "ABCDEF123" goes with request/response X and then I have to listen to the database to see if another server has received a request for "ABCDEF123" and that other server needs to do a database write. These can't be database writes that can be batched or deferred because the user is literally seeing the page wait to load on this database write. It's not impossible to exploit, but it requires real engineering for any company that has horizontally scaled anything to multiple web servers. You can't just drop it in easily. And while we might hate ads and there are concerning things about ads with respect to privacy and many other things, it isn't a security vulnerability. It's certainly interesting, but I can't see a company putting resources into this. |