Kind of an edge case privacy issue, IMO.

Imagine if the page has 10 parts. Part 1 has an image reference hosted on part1.imagehost.xyz, but loaded lazily. Each part has something analogous, an image hosted on a different domain, but loaded lazily (so, no requests before that part of the page is visible).

If you open the page and read from the top, the browser will open with part 1, Javascript will fire and tell the browser to load part1.imagehost.xyz/image1.jpg, causing a DNS lookup, HTTP(S) connection, and a request. And so on for each part (interestingly this way you can do a timing to see how fast the user is scrolling past each part).

But if the browser directly loads part 8 (the part with cancer in the example), and the Javascript only asks to load part8.imagehost.xyz/image8.jpg, the fact that the browser only asks the DNS for this hostname will reveal to the DNS admin that the reader followed a link straight there.

But if it's some health portal under the evil company's control, it seems like it'd be easier to write Javascript to fire an event to do server-side logging/send an email alert to HR if someone spends a lot of time reading the cancer section...

The privacy risk makes some logical sense, but I don't see why it doesn't also apply to regular old anchors that have been around for forever. That is, the same sort of information leak has already been possible for decades on sites that allow the URL to just have #cancer.

If this is really an issue worth solving, doesn't it need to be solved for all cases, both traditional #foo links and also these new pattern-style links?

I can understand that this new mechanism will probably increase how often it can happen, but blocking the new mechanism would only solve part of the problem. To solve the whole problem, you'd have to do something like turn off lazy loading.

Anyway, if the reason the person is visiting the page is to read the section about cancer, aren't they usually going to manually scroll to the section about cancer a lot of the time? So the resource will still be loaded, just a little bit later. The scroll bar is moving to that position either way. The only information leaked is who moved it, the referer or the end user.

(Most insightful comment so far.)

I've really been missing this kind of functionality. Modern sites are built by people who apparently don't know or care about HTML name anchors. There is still a need to link to specific parts of pages, particularly in online discussions.

The privacy aspect seems insanely overblown to me, for the reasons you outlined.

I do understand why Brendan is using this moment to criticize this. It's on-brand (his Chromium fork has a privacy angle), and it is going to get him exposure because the supposed bad guy is Google. Don't get me wrong, they (Google) are not "good guys" by default any longer. This thing though? Not so sure. I think it will make things more good than bad, on average.

Yeah, I agree that even assuming someone is making the right decision, it doesn't necessarily make you feel good about the fact that it's theirs to make.

One difference is that today's page anchors are only put there by the page author, so, since all authors are cracker-jack security experts, they would not have made an anchor available in such a sensitive part of the document, since it opens their readers up to this risk.

As you can tell, I think that the difference is a real, technically true difference, but the implication is a bit dumb, since authors do not have this kind of thing in mind when deciding whether to anchor. You might as well be mad about lazy image loading too. If a browser is smart enough to only load images near an anchor, then this same risk would have been opened up when that was introduced. (The author wrote the anchor before lazy loading, so they correctly perceived no risk, then lazy loading turned it into a risk.)

> One difference is that today's page anchors are only put there by the page author,

AFAIK we can link to any id in the page, not only to anchors. Strictly speaking you're still right because the author creates those ids but some of them are automatically created by frontend or backend frameworks.

That's true, though I often forget it. But surely those cracker-jack security expert HTML writers don't forget! Or use such privacy insensitive tools as the ones you've mentioned.

(Too late to edit, so replying to myself instead.)

I'm going to backpedal a bit on my point about manual scrolling being the same thing as automatically scrolling directly there via anchor.

The scrollbar can be at various positions, and if an anchor takes you there automatically, it jumps to position N, never passing through 0 .. N-1. Whereas if you manually scroll, you pass through all of 0 .. N. So whatever resources are above the target position would not necessarily be loaded with an anchor but probably would with manually scrolling. So the externally observable wire behavior (DNS, IP addresses you connect to, etc.) may still be different.

So if you manually scroll, the adversary can infer that there's something significant about scrollbar position N. It might just be that there's where you lost interest, or it could be that that's what you found interesting, but it's not giving away as direct a clue as jumping straight to position N.

I read it as the opposite, where the evil party doesn't control the browser but they can sniff traffic on the network and now they can see which part of a page you requested instead of merely which page.

I am not a web dev so I'd love to hear someone with more knowledge spell out some other privacy concerns.

That's also how I understand it. It requires a very specific and uncommon set of circumstances, but it could leak info to someone observing.

But also I think the main issue "pes10k" has is that it is adding a new attack vector in a backwards-incompatible way. So a sensitive website which is doing these JS lazy-loading things was "safe" last week, but now can potentially leak information in a way it couldn't have with earlier chrome versions.

In practice though it's hard (for me) to think of a website working this way. I understand the idea of a network admin sending the CEO a link with the text-fragment "cancer" in it. And if that fires off related requests unusually, I can assume it auto-scrolled to "cancer", and the CEO has cancer and sell all my shares. But what sort of website will dynamically contain the word "cancer" for patients that have cancer and is also doing fancy lazy-loading stuff? I'm not a security expert though and I know people can are much cleverer than me when it comes to exploits.

You're very right, what is the chance that this set of circumstances occur anywhere on the web? It seems like the person describing the scenario was just pulling a theory out of thin air in hopes to convince someone how terrible this is...

The github issue has more actual examples. The important bit is the "looking for lower-on-the-page resources being requested." bit.

You can't necessarily tell anything from that lone DNS request. But after loading the page, the user's browser will go on to send requests for elements on the page, and anything JS wants to grab based on position, which can be a channel for information.

Example: 99% of your employees' DNS requests to the company health portal are followed by DNS requests to the image CDN a few milliseconds later. However 1 specific request to FakeCompanyHealth.com is immediately followed by a DNS request to MayoClinic.com, because it turns out the web page dynamically loads an iframe to contact the Mayo Clinic once you scroll to the Cancer subsection. You could then assume based on timing that this user clicked a cancer-specific anchor link.

A more realistic example IMO is the twitter friend leak one provided in the Github thread. Send an anchor like "twitter.com#:~:text=@handle" and see if their page-load matches the standard twitter homepage load, or did their browser scroll them halfway down the page and load additional stuff? If so, you can assume these 2 users are friends.,

https://github.com/WICG/ScrollToTextFragment/issues/76

You don't send URLs or query parameters to a DNS server. Only a hostname. Also, it's usually cached after the first lookup. Sniffing the network will only requests to that IP. Hostnames, URLs, params and responses are all fully encrypted if they're on https.

Hostnames are not encrypted in HTTPS requests. They are sent in plain text via SNI (Server Name Indication). There is a new way of handling this called ESNI that does encrypt it, but I'm not sure how widely that is supported.

Edit: Cloudflare has a page to check if ESNI is supported by your browser. I tested it in the latest version of Firefox, Chrome, and Safari and it failed the test in all three.

https://www.cloudflare.com/ssl/encrypted-sni/

Ooooh, you're right. I didn't think of SNI.

Does this require you to intercept their traffic on the network? If not, how do you know what their page load looks like?

> A more realistic example IMO is the twitter friend leak one provided in the Github thread. Send an anchor like "twitter.com#:~:text=@handle" and see if their page-load matches the standard twitter homepage load, or did their browser scroll them halfway down the page and load additional stuff? If so, you can assume these 2 users are friends.,

It's still not realistic at all unless you can already snoop on them in some way.

The starting assumption here is "I assume I already violated someone's privacy in a massive way." Like, ok, sure you can violate it a little more in some situations maybe. But does this introduce any new risks in situations where user privacy hasn't already been so massively hijacked?

And since Chrome, along with others, are moving towards encrypted DNS, the feasibility of getting these DNS lookups is even less plausible than it is today. You need to actually be able to snoop on all the target's network traffic.

A sibling/top-level comment has a link to the security doc: https://docs.google.com/document/d/1YHcl1-vE_ZnZ0kL2almeikAj...

I think what that is saying is that, say evil.com starts embedding some sensitive site. It can't normally see the contents of that site, b/c it would be cross origin. (Or any other context where I can load a resource, but not see the content.) If I want to know whether some content is or is not in that sensitive site, I use the scroll-to-fragment to scroll to that text: either it will find the text, and scroll to it, or it won't; evil.com won't know the result of that directly, but it might be able to measure timing/CPU work done, and from that, infer the result: whether that text was or was not in the page. From there, repeat the attack to start brute forcing the content of the page. W.r.t. DNS, if the scrolling or lack of scrolling initiate two separate sets of DNS requests that I can observe, then that's one possible way to leak the information on the page.

At least, that's how I'm reading that security doc; this is fairly different from how other responses to your remark are interpreting it, but I wonder if they were only looking at TFA, which really was not very clearly explaining anything.

The security doc also mentions "Restrict feature to user-gesture initiated navigations", which would completely stop the iframe attack I've outlined above.

The idea of that quote is that using the anchor would only scroll to that part of the page if the word "cancer" is present, and if the page uses lazy-loading then it would fire off more requests than it would if the word wasn't present. It's a bit of a stretch though.

also #fragments aren't sent to the server at all, unless this changes that (a major major change if so)

The google document being used talks about crossing an origin-boundary.

So website with bad script injected is loaded by the user and is able to make requests to a logged-in banking website with time-based/scrolling attacks.

Does this matter when the server (well, multiple servers when you throw in ads as well) are running their custom Javascript on the client, which has access to not only the viewport coordinates, but the URL itself?

does this add an additional vector to that case?

Right on. This article is bull

And aren't most browsers (and for sure Chrome) loading the entire page anyway? I mean maybe if you have a slow connection, but for most people with a fast connection it should load everything to avoid that when scrolling down you have something missing.

I really don't see the issue, to me is a useless argument.

A lot of sites do lazy-loading (but even then it's good practice to preconnect to third-party domains) and chrome even implemented native lazy-loading for images and iframes recently.

It seems more plausible that I could send you a link to portal.site.example/you-have-cancer-what-now and if you don't have cancer it redirects to portal.site.example/home, if we're willing to consider the infiniverse of possible health care portal designs.

It just seems to me like not that big a concern.

eg on a company network, it would be common to install an SSL cert on all devices on the private network for things like web proxies, CASBs, or other security policy enforcement measures.