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

91–100 of 159 posts

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

#91

Post by notatoad »

prophesi wrote: post #71
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…

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…

>I'd like to call myself a privacy advocate, but this is just absurd.

Yeah, my read of this is that it has nothing to do with privacy, people who want to block change for some reason have just learned that "i have privacy concerns about google" is a catchword that will get you some press coverage, and are essentially hijacking the actually valid and important privacy concerns to push forward their unrelated opinions (and promote their browser product).

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

#92

Post by notatoad »

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?

how exactly is linking to a custom location on a document "stealing the web"?

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

#93

Post by jannotti »

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…

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 this kind of thing in mind when deciding whether to anchor. You might as well be mad about lazy image loading too. If a browser is smart enough to only load images near an anchor, then this same risk would have been opened up when that was introduced. (The author wrote the anchor before lazy loading, so they correctly perceived no risk, then lazy loading turned it into a risk.)

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

#94

Post by bad_user »

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 entirely by the client.

What am I missing?

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

#95

Post by JaceLightning »

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…

> Also — I was under the impression that anything that comes after # is not sent to the server, being a fragment meant to be processed entirely by the client.

You aren't missing anything. The article is wrong.

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

#96

Post by squeaky-clean »

ghostpepper wrote: post #67
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…

I read it as the opposite, where the evil party doesn't control the browser but they can sniff traffic on the network and now they can see which part of a page you requested instead of merely which page. I am not a web dev so I'd love to hear someone with more knowledge spell out some other privacy concerns.

That's also how I understand it. It requires a very specific and uncommon set of circumstances, but it could leak info to someone observing.

But also I think the main issue "pes10k" has is that it is adding a new attack vector in a backwards-incompatible way. So a sensitive website which is doing these JS lazy-loading things was "safe" last week, but now can potentially leak information in a way it couldn't have with earlier chrome versions.

In practice though it's hard (for me) to think of a website working this way. I understand the idea of a network admin sending the CEO a link with the text-fragment "cancer" in it. And if that fires off related requests unusually, I can assume it auto-scrolled to "cancer", and the CEO has cancer and sell all my shares. But what sort of website will dynamically contain the word "cancer" for patients that have cancer and is also doing fancy lazy-loading stuff? I'm not a security expert though and I know people can are much cleverer than me when it comes to exploits.

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

#97

Post by bad_user »

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 can't really get the browser vendors to agree on mostly anything a priori, without market validation.

Standardization works as a refinement of already existing work. E.g. Google came with NaCL/PNaCL which was basically their own ActiveX, Mozilla came with Asm.js in response and the end result was Web Assembly, which is objectively better than both and that wouldn't have happened without that prior art.

The W3C doesn't guard what gets implemented in browsers. It never did. And if browser makers willingly participate in the standardization process, we should thank them, because they can always stop doing it. Because really, retreating from the W3C would mean absolutely nothing for computer illiterate people.

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

#99

Post by internalthief »

JaceLightning wrote: post #95
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…

> Also — I was under the impression that anything that comes after # is not sent to the server, being a fragment meant to be processed entirely by the client. You aren't missing anything. The article is wrong.

The article isn't wrong, by forcing scroll to a certain location and embedding for example images that only load when scrolled into view the web server can know that someone was linked to a particular section of the website with the new deep-linking feature.

This is especially the case if the browser scrolls and doesn't load all prior resources automatically because they were never "in view".

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

#100

Post by ogre_codes »

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…

I think this paragraph sort-of fills it in:

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

The impression I got was that you'd need a combined hack with javascript reading the page position when you load the page.

Post reply on HN