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

71–80 of 159 posts

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

#71

Post by prophesi »

merrywhether wrote: post #46
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…

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 obviously outweigh the con of a very precise and targeted attack that leaks a predetermined bit of information.

If you've got their DNS records, you've already violated plenty of their privacy to get the information you want. No need for this text fragment "attack."

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

#72

Post by johnmarcus »

merrywhether wrote: post #46
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…

But if it had the anchor 'cancer', couldn't you infer the same from the url alone? These examples seem highly contrived.

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

#73

Post by jcheng »

AlexandrB wrote: post #15

IE6 is back, baby! All that’s left is deep integration with some proprietary Google “standard” (I’m thinking AMP) and it’ll be the early 2000s all over again.

We were in WAY worse shape back then. IE6 was closed source, under-resourced (after they gained market dominance), and MS had every incentive to suppress the progress of web technologies once they ran the table.

I’m not saying we shouldn’t all be rooting for the other players today and keeping a close eye on Google, just saying there is no way for Google to do nearly as much to hold back the web as MS did back then, even if they wanted to.

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

#74

Post by adrianmonk »

netsharc wrote: post #9
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…

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 links?

I can understand that this new mechanism will probably increase how often it can happen, but blocking the new mechanism would only solve part of the problem. To solve the whole problem, you'd have to do something like turn off lazy loading.

Anyway, if the reason the person is visiting the page is to read the section about cancer, aren't they usually going to manually scroll to the section about cancer a lot of the time? So the resource will still be loaded, just a little bit later. The scroll bar is moving to that position either way. The only information leaked is who moved it, the referer or the end user.

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

#75

Post by ocdtrekkie »

DoctorOW wrote: post #18
AlexandrB wrote: post #15

IE6 is back, baby! All that’s left is deep integration with some proprietary Google “standard” (I’m thinking AMP) and it’ll be the early 2000s all over again.

It'll be like the early 2000's if switching to another browser was most likely just IE6 reskinned.

There's only one competing browser engine left, Firefox's, with like 5% market share. Except if you have an Apple device, every other option is skinned Chrome.

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

#76

Post by stickykeys »

speedgoose wrote: post #23
minikites wrote: post #14

Imagine telling someone in 2003 or so that the most popular web browser fifteen years later would be made by DoubleClick and imagine what their reaction might be.

Something like "wow, software development will improve so much! You will make a web browser in a double-click."

The year is 20XX. You return to your slave cube to find what you assume is a PC running "Plan 9 from Microsoft". You are shocked at it's convenient features:

The world's information is merely one click away.

The world's browsers are simply two clicks away.

Dispensing candy is an easy ctrl-triple-click.

Bootstrapping a compiler is just the konami code backwards.

Printing the screen is really simple as hitting PrintSrc and loading your printer with $300 cyan ink cartridges.

However turning the computer off is a week-long process that involves arguing with the built-in HAL9000

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

#77

Post by prophesi »

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.

I agree that it's a useful feature and not a privacy issue, but I will say that it's nigh-impossible to avoid clicking links like these. I already try my best to strip out tracking parameters in query strings, and avoid shortened URLs. But they're simply everywhere, and sites/email try their best to hide them.

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

#78

Post by kemayo »

superkuh wrote: post #49
gnomewascool wrote: post #22

Earlier quoted context omitted.

> 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://git…

Can't say I've noticed it, but then I'm going around with Javascript enabled, so it's not like I would.

That said, the github one is a sort of interesting case, insofar as they're doing it to avoid user-generated content clashing with their page-chrome ids... while still preserving a readable URI that matches what the content creator expects. Which doesn't seem like an unreasonable case, to me.

You'll note that there is a real anchor on that link -- https://github.com/quiet/quiet#user-content-dependencies -- which works without Javascript. It's just rather inaccessible.

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

#79

Post by phillipseamore »

johnmarcus wrote: post #72
merrywhether wrote: post #46

Earlier quoted context omitted.

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…

But if it had the anchor 'cancer', couldn't you infer the same from the url alone? These examples seem highly contrived.

Anything after a hash in an URL is never sent to a server (it's only within the context of the browser).

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

#80

Post by alerighi »

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…

And aren't most browsers (and for sure Chrome) loading the entire page anyway? I mean maybe if you have a slow connection, but for most people with a fast connection it should load everything to avoid that when scrolling down you have something missing.

I really don't see the issue, to me is a useless argument.

Post reply on HN