Pornhub. It could of course be a popup playing a different role (e.g. being part of a "you need to upgrade your vulnerable software naow!1"-scheme) that's only visible if no blockers at all are used.
The main reason why the issue isn't present in Firefox is because their PDF reader (PDF.js) does not have an API to trigger requests (it does execute JS included within the PDF though)
The bug still seems to be present. You can use the testing on our website: navigate a Chrome browser with an ad-blocking extension to e.g. https://wholeftopenthecookiejar.eu/data/extensions/AdBlock/c... and click pdf-iframe-submitForm.
If the result shows cookies, it has not been fixed.
That's not what the fix was. Disable JS on the site, that should prevent the pdf running JS as well. (although it might prevent the pdf loading in the first place...). As kodablah pointed out, it's not a useful fix.
edit to clarify: sorry I thought you thought that fix was trying to fix the bug, but you weren't, so this comment doesn't make much sense.
Attaching cookies to third-party requests is the source of many issues. In a similar demonstration [0], I showed that browser-based timing attacks (which can probably be considered as wont-fix as well) can be used to extract more specific information from social networks (e.g. one's political preference based on who they're following).
The attack on Facebook (or any other website for that matter) works regardless of any Access-Control-Allow-Origin headers. The Fetch API has a mode "no-cors", which does not require CORS. Also: the cache being used is a programmable cache, which is distinct from the regular cache in the sense that any website can place any resource in it, regardless of the headers sent along with the response.
(I'm one of the researchers mentioned in the presentation.)
The email address is used to send you the link where the results for your domain are shown. If you keep track of this URL yourself, feel free to enter a bogus email.
(domain verification is not related to the email address)
For anyone interested in similar issues: here you can find a report for a vulnerability in Phabricator with exactly the same cause (truncation by MySQL), and pretty much the same result: https://hackerone.com/reports/2224
If Bugzilla would allow non-ASCII characters in the email address, MySQL's truncation behaviour with astral symbols (e.g. 𝌆) would probably have lead to a similar vulnerability as well. (It did so in Phabricator: https://hackerone.com/reports/2233)
I guess that 4450 requests/s to one IP, or even spread across multiple IPs, could trigger some alarms if the victim is alert. Unfortunately, I'm not that familiar with IDS/IPS's to answer that with much confidence.
In any case, an attacker has a lot of options. The requests do not need to be made sequentially, so an attacker could basically start and resume his attack whenever he wants, e.g. when the victim is away from keyboard (which he can estimate based on the network traffic someone usually generates). An attacker could also simply slow down the number of requests/s, although this results in a larger number of hours required for a successful attack.
As for energy/CPU consumption, I don't think that'd be a big concern. When the practical attack was performed, the CPU usage went up to around 75%, still allowing one to visit other websites without noticing anything. So unless one would closely monitor the CPU/network usage, I don't think the average victim would notice it.
It's not a line of defense. I'm thinking about less computer literate people. Do you know a friend or family member that would call you and say "My laptop's really hot, loud, and slow, but it's not doing anything!" and ask for advice?
