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

81–90 of 159 posts

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

#81

Post by SahAssar »

alerighi wrote: post #80
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.

A lot of sites do lazy-loading (but even then it's good practice to preconnect to third-party domains) and chrome even implemented native lazy-loading for images and iframes recently.

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

#82

Post by dagenix »

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.

How would W3C stop this?

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

#83

Post by falcolas »

liveoneggs wrote: post #3
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…

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?

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

#84

Post by robertoandred »

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?

Use Firefox, use Safari. Test in Firefox, test in Safari.

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

#85

Post by thewebcount »

ocdtrekkie wrote: post #75
DoctorOW wrote: post #18

Earlier quoted context omitted.

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.

No it isn't. It's skinned Safari which is WebKit. Chromium forked from WebKit years ago and they have diverged. And Apple certainly doesn't include all of the phone-home stuff that's in Chromium. It's not even remotely the same.

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

#86

Post by pas »

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.

True, but since the other parties don't really care much, what could we do really? (The other big corps like Apple and Microsoft - and let's say FB because of their WebView browser. Are all also knee-deep into their own walled gardens. Not likely to take standards and consumer protection seriously. Eg. Apple will just laugh and brand itself as the real privacy option - for those who can afford it. And geeks can ultimately just use a fork of Chrome/Chromium if they want.)

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

#87

Post by tpmx »

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…

(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. It's on-brand (his Chromium fork has a privacy angle), and it is going to get him exposure because the supposed bad guy is Google. Don't get me wrong, they (Google) are not "good guys" by default any longer. This thing though? Not so sure. I think it will make things more good than bad, on average.

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

#88

Post by tootie »

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…

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.

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

#89

Post by tootie »

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…

If it's https, that's all fully encrypted. The network only sees IPs. The hosts and paths are all encrypted headers.

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

#90

Post by derefr »

Amusingly, I built a (private prototype of an) extension for functionality almost exactly like this a while ago. My goal was to be able to bookmark arbitrary long articles (or single-page books) “in the middle”—without the author providing an anchor permalink—and then come back to them where I left off, precisely by embedding my scroll location on the page into the fragment of the bookmarked URL. It worked pretty well, and mostly obviated my need for any service like Instapaper/Pocket.

I always wondered why browser bookmarks don’t just work like this, even if doing so required storing additional metadata outside the URL itself.

One thing that’s interesting about this functionality in Chrome specifically, is that due to the nature of Chrome’s PDF support, these URLs should allow you to deep-link into a PDF from outside it, which hasn’t really been possible before.

Still quite a way from Xanadu transclusions, but it’s a start.

Post reply on HN