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