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

111–120 of 159 posts

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

#111

Post by tpmx »

chadlavi wrote: post #108
tpmx wrote: post #105

Earlier quoted context omitted.

> Rinse and repeat. How exactly would you as an attacker perform this rinse and repeat action?

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)

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.

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

#112

Post by liveoneggs »

falcolas wrote: post #83
liveoneggs wrote: post #3

Earlier quoted context omitted.

also #fragments aren't sent to the server at all, unless this changes that (a major major change if so)

Does this matter when the server (well, multiple servers when you throw in ads as well) are running their custom Javascript on the client, which has access to not only the viewport coordinates, but the URL itself?

does this add an additional vector to that case?

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

#114

Post by jonny_eh »

rubatuga wrote: post #29

Seems like a useful feature to me. You could just train yourself not to click on hyperlinks with the aforementioned tag. And like another comment says, it shouldn't be a privacy issue unless you are running over HTTP, since the resource URLs are encrypted.

It's in the URL fragment (the stuff after the hash), so it's never even sent to the server.

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

#115

Post by pmontra »

jannotti wrote: post #93
adrianmonk wrote: post #74

Earlier quoted context omitted.

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…

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

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

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

#116

Post by adrianmonk »

adrianmonk wrote: post #74
netsharc wrote: post #9

Earlier quoted context omitted.

Kind of an edge case privacy issue, IMO. Imagine if the page has 10 parts. Part 1 has an image reference hosted on part1.imagehost.xyz, but loaded lazily. Each part has something analogous, an image hosted on a different domain, but loaded lazily (so, no requests before that part of the page is visible). If you open the page and read from the top, the browser will open with part 1, Javascript will fire and tell the b…

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…

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

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

#117

Post by adrianmonk »

tpmx wrote: post #87
adrianmonk wrote: post #74

Earlier quoted context omitted.

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…

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

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.

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

#118

Post by tpmx »

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?

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

#119

Post by maxrmk »

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://docs.google.com/document/u/0/d/1YHcl1-vE_ZnZ0kL2alme...

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

#120

Post by tootie »

bradyd wrote: post #106
tootie wrote: post #88

Earlier quoted context omitted.

You don't send URLs or query parameters to a DNS server. Only a hostname. Also, it's usually cached after the first lookup. Sniffing the network will only requests to that IP. Hostnames, URLs, params and responses are all fully encrypted if they're on https.

Hostnames are not encrypted in HTTPS requests. They are sent in plain text via SNI (Server Name Indication). There is a new way of handling this called ESNI that does encrypt it, but I'm not sure how widely that is supported. Edit: Cloudflare has a page to check if ESNI is supported by your browser. I tested it in the latest version of Firefox, Chrome, and Safari and it failed the test in all three. https://www.cloud…

Ooooh, you're right. I didn't think of SNI.
Post reply on HN