Many times I'm looking for an existing anchor for linking to a certain section of the page, because the author did not bother to create a table of contents and many times that anchor ID is missing.
Also — I was under the impression that anything that comes after # is not sent to the server, being a fragment meant to be processed entirely by the client.
What am I missing?
> "Consider a situation where I can view DNS traffic (e.g. company network), and I send a link to the company health portal, with #:~:text=cancer," he wrote. "On certain page layouts, I might be able [to] tell if the employee has cancer by looking for lower-on-the-page resources being requested."
The impression I got was that you'd need a combined hack with javascript reading the page position when you load the page.
- you visit a page at example.com that contains private data about you (e.g. bank account number, medical conditions, what have you)
- this page loads external resources only when they are scrolled into view
- it also hotlinks some image below the fold that a potentially bad actor can see requests to (maybe the image is on their webserver, maybe you're on a corp network and they can see dns resolutions, whatever)
So now I link you to: https://example.com/privatepage#:~:text=Account%201
Did the image get requested? If yes, I know your account number starts with 1; if not, I know it starts with something other than 1. Rinse and repeat.
How exactly would you as an attacker perform this rinse and repeat action?
All the security concerns I've seen for this seem quite contrived to me. And I say that as someone who assiduously avoids google products*
(*alas, except at work, because I can't really choose that)
1) Privacy-conscious browsers are trying to get exposure, so they are stretching an extremely narrow privacy risk into something extreme.
2) (I also believe) media companies are worried this will rob them of ad exposures, so they are incentivized to cover this as something scary.
3) The "bad guy" is Google. This means the amplitude of the story is immediately 10X larger.
Encrypted DNS is a thing, so snooping on those is non-trivial and not at all something you can be assumed to have access to.
You aren't missing anything. The article is wrong.
This is especially the case if the browser scrolls and doesn't load all prior resources automatically because they were never "in view".
The scenario you've given is also very similar to a scenario in which the user opens the web page and then manually searches for "cancer". Or scrolls down rapidly until they notice the word "cancer" and then stops. I do that all the time for example.
So I don't see how excluding such a feature protects the user in any way compared with the status quo.