Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome deploys deep-linking in latest build despite privacy concerns

theregister.co.uk

Post reply on HN
Print view View original

41–50 of 159 posts

Re: Chrome deploys deep-linking in latest build despite privacy concerns

#41

Post by squeaky-clean »

thinkingemote wrote: post #2

The quote about DNS seems wrong to me ""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."" I thought DNS requests just get the domain, not the hash and not even the page reque…

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

Re: Chrome deploys deep-linking in latest build despite privacy concerns

#42

Post by bastawhiz »

The example that the security researcher gave seems moot: the same thing would happen if the employee simply scrolled down on the page manually, no? And we already have the ability to link to anchors on a page, and that's not considered to be a privacy issue. Can someone explain how this is actually a meaningful privacy issue?

Re: Chrome deploys deep-linking in latest build despite privacy concerns

#43

Post by sincerely »

blakesterz wrote: post #7

The article says the folks at Google have this short docs to address the concerns: Scroll-to-text Fragment Navigation - Security Issues https://docs.google.com/document/d/1YHcl1-vE_ZnZ0kL2almeikAj...

I don't have access to this document, is there a mirror?

Re: Chrome deploys deep-linking in latest build despite privacy concerns

#44

Post by quantummkv »

MentallyRetired wrote: post #16

As a developer, how do I lend my support to stopping google from trying to steal the web? Something actionable, something specific to my semi-unique position as a developer?

Use Firefox. And not only use Firefox, but also promote Firefox. Make sure that all your browser screenshots, presentations, etc show Firefox.

As a developer you, like many of us might be the family tech support. Switch them to firefox.

Re: Chrome deploys deep-linking in latest build despite privacy concerns

#45

Post by M2Ys4U »

MentallyRetired wrote: post #16

As a developer, how do I lend my support to stopping google from trying to steal the web? Something actionable, something specific to my semi-unique position as a developer?

Use Firefox. Try to convince others to use YouTube. Never use features only available in Chrome/chromium browsers.

Re: Chrome deploys deep-linking in latest build despite privacy concerns

#46

Post by merrywhether »

bastawhiz wrote: post #42

The example that the security researcher gave seems moot: the same thing would happen if the employee simply scrolled down on the page manually, no? And we already have the ability to link to anchors on a page, and that's not considered to be a privacy issue. Can someone explain how this is actually a meaningful privacy issue?

Say you have a long page that lists “Pre-existing conditions” at the bottom, and near that section is also a unique image or other external asset. If you click on the link and cancer is in your list, the page will scroll and load the related assets instantly. Without cancer in your list, you’d only load those assets through human scroll, which would most likely look different timing-wise. Thus you can determine with high probability whether your target has cancer listed (if you have access to DNS records, as mentioned in the example, and the target is using a browser that delays offscreen asset loading - like this same latest Chrome).

Whereas anchors tend to be generic (#preexisting-conditions), this new scroll behavior can be used to create an existence check for any user-specific text on the page (in carefully crafted scenarios). There are probably other variations that could be devised on this concept, since it allows indirect page interaction that can bypass authorization walls (since the browser would transmit cookies normally and such).

Re: Chrome deploys deep-linking in latest build despite privacy concerns

#48

Post by _bxg1 »

noahmotion wrote: post #47

Was it wrong of me to be amused when I got to the end of this post on internet privacy concerns and Google, only to see a link at the bottom encouraging me click in order to follow the author on Facebook?

And I couldn't read the article because of my adblocker

Re: Chrome deploys deep-linking in latest build despite privacy concerns

#49

Post by superkuh »

gnomewascool wrote: post #22
superkuh wrote: post #21

No doubt because most large web corporations have completely switched to javascript for their anchors (ie, #) and no longer use HTML spec anchors that actually work. I'm looking at you Microsoft Github.

> I'm looking at you Microsoft Github. Where don't anchors work when javascript is disabled? (With admittedly very brief testing just now, I couldn't find any such cases.)

On every single repo index page that has "anchors" that I've tried over the last year. The markdown is now interpreted different so anchors are class="anchor" and not real anchors. Maybe you didn't fully disable JS? Make sure JS is disabled before you load the page and you've cleared your cache (ctrl-f5 in FF-alikes).

I just went to the most recent github tab in my browser session and found one instantly: https://github.com/quiet/quiet#dependencies

Post reply on HN