I think this paragraph sort-of fills it in:

> "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.

Let me give you an example. It will be contrived for simplicity but there are circumstances that will seem more real-worldish. Lets consider the following scenario:

- 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 are you determining whether or not the resource was requested? If you can hijack my network traffic you've already owned me pretty badly and don't need this silly game in the first place. If you haven't, this doesn't help you get that.

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.

> Rinse and repeat.

How exactly would you as an attacker perform this rinse and repeat action?

and why would a bank site hotlink to an asset owned by someone else?

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)

I think this is the perfect storm.

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.

> 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.

You aren't missing anything. The article is wrong.

The article isn't wrong, by forcing scroll to a certain location and embedding for example images that only load when scrolled into view the web server can know that someone was linked to a particular section of the website with the new deep-linking feature.

This is especially the case if the browser scrolls and doesn't load all prior resources automatically because they were never "in view".

You can already measure where the visitor's view is and notice the sections at which the visitor stares the most.

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.