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

141–150 of 159 posts

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

#141

Post by wsh »

derefr wrote: post #90

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

these URLs should allow you to deep-link into a PDF from outside it, which hasn’t really been possible before

Chrome and other browsers with built-in PDF viewers have long supported the #page=XXX URL syntax, to go directly to a specific page of a PDF document.

This sometimes works only when the document is first loaded; if it’s already open in the window or tab, adding a #page fragment in the address bar won’t always turn the page.

See this Adobe document for other parameters, which aren’t as widely supported:

https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdf...

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

#142

Post by jka »

pkulak wrote: post #136
jka wrote: post #126

Earlier quoted context omitted.

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.

It sounds like the feature's enabled across all websites - so it could break security & privacy expectations a user has about existing web pages.

It requires that the attacker has DNS request visibility and expects that a user will visit a vulnerable page - not necessarily huge barriers to entry.

This could be exploited by targeting a user with an advert that appears in the footer of a webpage, for example, and then obtaining DNS logs for that user after-the-fact.

It's a useful feature certainly; the concern is mainly around the fact that this has essentially been self-certified by the development team and rolled out.

With more ISPs looking to monetize DNS logs, and the future of DNS infrastructure looking a little uncertain at the moment, there does seem to be risk here given that it could become widely deployed.

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

#143

Post by telotortium »

paulddraper wrote: post #133
tpmx wrote: post #132

Earlier quoted context omitted.

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

The W3C doesn't even try to drive features after one browser has implemented them and other browsers are considering them - that's the job of WHATWG.

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

#144

Post by gnomewascool »

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…

You're right. I was wrong. Sorry!

I had tested linking to specific comments in issue threads, which does work with JS disabled (unless I've completely messed up...), and assumed that linking to parts of documents, as less complex/application-y would obviously work, but as you've pointed out it doesn't.

That's highly disappointing.

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

#145

Post by paulddraper »

telotortium wrote: post #143
paulddraper wrote: post #133

Earlier quoted context omitted.

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

The W3C doesn't even try to drive features after one browser has implemented them and other browsers are considering them - that's the job of WHATWG.

We are in violent agreement.

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

#146

Post by [deleted] »

t0mas88 wrote: post #130
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.

Read again. Their point isn't that the fragment is sent to the server or DNS. Their point is that you can infer the existence of a certain text on a page the user views (even via https) by sending them a link like this and observing the browser loading resources that would be at the bottom of the page. The only reason the browser would do that is if it scrolled to the bottom, confirming the text you put in the link i…

[deleted]

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

#147

Post by tpmx »

paulddraper wrote: post #145
telotortium wrote: post #143

Earlier quoted context omitted.

The W3C doesn't even try to drive features after one browser has implemented them and other browsers are considering them - that's the job of WHATWG.

We are in violent agreement.

With the risk of falling into a loop:

https://news.ycombinator.com/item?id=22386665

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

#148

Post by SahAssar »

joshuamorton wrote: post #125
bad_user wrote: post #97

Earlier quoted context omitted.

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…

To elaborate, the process for standardizing browser features today is whatwg managed, not w3c. And it's basically "write a proposal, solicit feedback, implement the feature in one browser, and if it's ever implemented in 3 browsers it's part of the standard".

WHATWG is mostly HTML and DOM/browser api:s, ECMAscript is by TC39, CSS is still in W3C, URI schemes (which this is about) are in W3C, as seen in this draft being hosted by WICG, which as far as I can tell is a W3C group.

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

#149

Post by SahAssar »

telotortium wrote: post #143
paulddraper wrote: post #133

Earlier quoted context omitted.

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

The W3C doesn't even try to drive features after one browser has implemented them and other browsers are considering them - that's the job of WHATWG.

WHATWG is mostly HTML and DOM/browser api:s, ECMAscript is by TC39, CSS is still in W3C, URI schemes (which this is about) are in W3C, as seen in this draft being hosted by WICG, which as far as I can tell is a W3C group.

At least that has been my understanding of the situation.

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

#150

Post by netsharc »

squeaky-clean wrote: post #96
ghostpepper wrote: post #67

Earlier quoted context omitted.

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…

You're very right, what is the chance that this set of circumstances occur anywhere on the web? It seems like the person describing the scenario was just pulling a theory out of thin air in hopes to convince someone how terrible this is...
Post reply on HN