Live data from Hacker News

Chrome deploys deep-linking in latest build despite privacy concerns

theregister.co.uk

131–140 of 159 posts

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

#131
post #119

Earlier quoted context omitted.

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.

Just to clarify, I do think there are real privacy concerns with a naive implement of this feature. Allowing sites to search across origin boundaries would be a huge issue!

I just don't think that the DNS query issue mentioned in the article is the thing to be worried about. It's just so much less severe than the fact that DNS isn't encrypted, and requires essentially the same fix.

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

#132
post #118

Earlier quoted context omitted.

Why do you think the W3C is relevant?

As the article says, ScrollToTextFragment is a W3C spec.

It's not.

But that's besides the point. The W3C haven't been in the driver's seat for a very long time now when it comes to web standards.

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

#133
post #132

Earlier quoted context omitted.

As the article says, ScrollToTextFragment is a W3C spec.

It's not. But that's besides the point. The W3C haven't been in the driver's seat for a very long time now when it comes to web standards.

Well, not spec, but proposed spec. [1]

Driven by Google, but under the auspices of W3C.

> The W3C haven't been in the driver's seat for a very long time now when it comes to web standards.

That was exactly ghostpepper's point.

[1] https://github.com/WICG/ScrollToTextFragment

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

#134
Will never use it. Read what Google did with JS websites and recommendation to implement hashbang and escaped fragment to provide prerendered version.

You wont. Because it didnt work and killed SEO. Than after years they silently removed documentation about it. Not providing any way to transition to other ways without damaging SEO ever more and moreover, it was impossible to do anything about it because server does not receive data after hash.

And now Google tries to force new standard that is technically broken. Dont use it. It is a trap. It will hurt your SEO sooner or later!

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

#136
post #126
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."

Yeah, looks like I read it too quickly.

But wow, what an absurd amount of work to almost find something out when you already have access to the entire network, and apparently the WiFi is not secured at all or your targets are all plugged in and on your switch. This is like complaining about a weak combination on a padlock used to secure your screen door.

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

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

Careful about calling something a dumb justification. It's often the simplistic-seeming features that expose unforseen privacy issues, in large part because today's internet is such a complex place. In the end, it may turn out that privacy concerns are unjustified. But dismissing them out-of-hand isn't wise.

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

#138
i don't think you can arrive to any conclusion based on analyzing traffic/dns reqs made alone.

How can you tell a user didn't jitter scroll and caused more content to show up?

What if it was a 404 page.

How's the intruder able to see the query param anyway? if it's non secure all bets are off.

The same argument used revolving around text can be made about words in a domain name.

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

#139

What? A DNS lookup doesn't include anything but the hostname and anything following a hash is never sent with a request from the browser.

I just give a unique key to each user. That user does a lookup of key-.tracking.example.com when they get to that part of the page. As they scroll I gather data via dns.

Source: was my job to track people and what they do.

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

#140

Could someone explain this a bit better? I've read two articles on this this morning and I still don't understand what the privacy concerns are with this feature. Thanks!

The feature in question is the ability to use fragment (# in a URL) to link to matching text rather than just an ID. Here is the key line with the so-called privacy concern. "Consider a situation where I can view DNS traffic (e.g. company network), and I send a link to the company health portal, with [the anchor] #:~:text=cancer. On certain page layouts, I might be able [to] tell if the employee has cancer by looking…

[deleted]
Post reply on HN