3 ms·

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

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.

tpmx 7y ago
(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.
- adrianmonk 7y ago
  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.
jannotti 7y ago
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.)
- pmontra 7y ago
  > 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.
  - jannotti 7y ago
    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.
adrianmonk 7y ago
(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.

tpmx 7y ago

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

adrianmonk 7y ago
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.

jannotti 7y ago

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

pmontra 7y ago
> 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.
- jannotti 7y ago
  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.

adrianmonk 7y ago

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