6 ms·

I avoid Chrome due to privacy concerns, but I actually like this feature ¯\_(ツ)_/¯ Many times I'm looking for an existing anchor for linking to a certain secti

I avoid Chrome due to privacy concerns, but I actually like this feature ¯\_(ツ)_/¯ 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?

JaceLightning 7y ago
> 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.
- internalthief 7y ago
  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".
  - bad_user 7y ago
    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.
ogre_codes 7y ago
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.
- deleted 7y ago
  [deleted]
chias 7y ago
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 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.
- tpmx 7y ago
  > Rinse and repeat. How exactly would you as an attacker perform this rinse and repeat action?
  - chadlavi 7y ago
    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)
    - tpmx 7y ago
      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.
- kllrnohj 7y ago
  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.

JaceLightning 7y ago

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

internalthief 7y ago
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".
- bad_user 7y ago
  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.

ogre_codes 7y ago

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.

deleted 7y ago
[deleted]

chias 7y ago

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

tpmx 7y ago
> Rinse and repeat. How exactly would you as an attacker perform this rinse and repeat action?
- chadlavi 7y ago
  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)
  - tpmx 7y ago
    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.
kllrnohj 7y ago
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.