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

121–130 of 159 posts

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

#121

Post by kllrnohj »

squeaky-clean wrote: post #41
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' DN…

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

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

#123

Post by kllrnohj »

chias wrote: post #101
bad_user wrote: post #94

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 entire…

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 th…

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.

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

#124

Post by femto113 »

maxrmk wrote: post #119
pkulak wrote: post #113

Wow, what a dumb justification for the privacy concerns. URL hashes aren't even sent to the server, let alone have anything to do with DNS. We already put sensitive stuff in URL hashes, like OAuth tokens.

Yeah -- it's frustrating that the privacy concerns brought up in the article are just blantantly wrong. Especially because there a legitimately interesting issues in the security write-up [1]. On the other hand, I suspect they probably won't get the mitigations for those real issues right the first time. It's a complicated system they're building, and I think someone will find a clever way to break it. [1] https://do…

This sentence from the doc referenced sums it up well I think:

> A naive implementation of this feature may allow an attacker to determine the existence of textual content across an origin boundary.

Security & privacy implications of that seem obvious, e.g. extracting an account number (or other sensitive information) from a page by searching for successive prefixes.

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

#125

Post by joshuamorton »

bad_user wrote: post #97
ghostpepper wrote: post #70

I think a lot of the comments in this thread are trying to evaluate the privacy concerns on merit, which makes sense, but IMHO it's also instructive to look at the fact that other W3C members don't want this included and Google is able to do it anyway. Perhaps that should be the bigger cause for alarm than any one feature.

In Google's defense, and basically because I like this particular feature, I have to point out the obvious ... most new browser features happen before and not after standardization. The standardization process is meant for reaching agreement among browser makers and to provide clear specs for those features. But it isn't meant for exploration. That has always been the case. Even Mozilla does it. And if not, then you…

To elaborate, the process for standardizing browser features today is whatwg managed, not w3c. And it's basically "write a proposal, solicit feedback, implement the feature in one browser, and if it's ever implemented in 3 browsers it's part of the standard".

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

#126

Post by jka »

pkulak wrote: post #113

Wow, what a dumb justification for the privacy concerns. URL hashes aren't even sent to the server, let alone have anything to do with DNS. We already put sensitive stuff in URL hashes, like OAuth tokens.

Quoted from the article:

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

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

#128

Post by paulddraper »

tpmx wrote: post #118
ghostpepper wrote: post #70

I think a lot of the comments in this thread are trying to evaluate the privacy concerns on merit, which makes sense, but IMHO it's also instructive to look at the fact that other W3C members don't want this included and Google is able to do it anyway. Perhaps that should be the bigger cause for alarm than any one feature.

Why do you think the W3C is relevant?

As the article says, ScrollToTextFragment is a W3C spec.

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

#129

Post by prophesi »

merrywhether wrote: post #109
prophesi wrote: post #71

Earlier quoted context omitted.

This is absurdly difficult to pull off with very little payoff. You'd need to be sniffing the traffic of a network. Then craft a URL that contains a unique image near your text fragment query. Then somehow send that URL to the victims on your network. _Then_ check how long it takes for them to load that image upon clicking the URL. I'd like to call myself a privacy advocate, but this is just absurd. The pros obviousl…

For what it’s worth, I wasn’t trying to say that this is an easy attack, just explaining the supposed outline.

Ah, and thank you for that! I had read the article a few times, but I didn't fully understand the attack until I saw your comment.

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

#130

Post by t0mas88 »

pkulak wrote: post #113

Wow, what a dumb justification for the privacy concerns. URL hashes aren't even sent to the server, let alone have anything to do with DNS. We already put sensitive stuff in URL hashes, like OAuth tokens.

Read again. Their point isn't that the fragment is sent to the server or DNS.

Their point is that you can infer the existence of a certain text on a page the user views (even via https) by sending them a link like this and observing the browser loading resources that would be at the bottom of the page. The only reason the browser would do that is if it scrolled to the bottom, confirming the text you put in the link is on the page.

Post reply on HN