Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page

chromestory.com

Post reply on HN
Print view View original

261–270 of 332 posts

Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page

#261

Post by bokan »

fooyc wrote: post #186

Can this be used to gain some informations about the content of a webpage, with a timing attack ? Searching a phrase on a webpage will be faster when the phrase exists, on average. If this timing is observable, this could be exploited to guess the content of a web page. Someone did this already with selector-based anchors: https://blog.sheddow.xyz/css-timing-attack/

Feature author here.

The CSS timing attack actually influenced the design process heavily. The original design was to use a stripped down CSS selector but we found this too large of an attack surface.

There's definitely still concerns around making sure a 3rd party can't exfiltrate information from the page using this but we think we've found a set of restrictions that should prevent this: https://github.com/bokand/ScrollToTextFragment#security

Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page

#262

Post by bokan »

colordrops wrote: post #8
kumarharsh wrote: post #2

Seems very cool! But the functionality feels like it'd be prone to breakage as new text is added to the document (possible in Wikipedia articles for example). But it'd be super-helpful for search engines as they will have a relatively recent copy of the text, and can auto-generate the links on the backend before showing the search results to the user.

I'd assume a hash of the content would be included with the link, and if the hash changes, then it would make a best-effort guess at the right location, with a different color highlight indicating that it's a guess. At least that's how I would do it.

What would you hash though? Content on a page changes frequently and dynamically so the hash would mismatch very frequently.

Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page

#264

Post by pcwalton »

SquareWheel wrote: post #211
xg15 wrote: post #117

Earlier quoted context omitted.

Yes. After SPDY had already been implemented and shipped in Chrome.

Of course, that's how it works. Chrome is hardly alone in field testing their new feature proposals. You'll note that they're also willing to kill features which are not adopted, like PPAPI.

> You'll note that they're also willing to kill features which are not adopted, like PPAPI.

After adding whitelists for Google properties like Hangouts, of course.

Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page

#265

Post by pcwalton »

izacus wrote: post #144
adrianN wrote: post #57

Earlier quoted context omitted.

That's my point. The web is so complex that browser engines are becoming a monoculture. Even if you forked Chromium now, you'd need hundreds of engineers just to keep up with all the new things that are constantly added.

And yet the fact that the major engine implementation is opensource still allows each vendor to innovate by adding new useful features to the users. We're really far from IE6 era of complete stagnation.

Not really, as far as the core browser engine tech goes. In practice it's too difficult to maintain a Chromium fork that diverges in any significant way other than the front end. Opera and Edge (per announcement) use vanilla upstream Blink.

Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page

#266

Post by amichal »

giornogiovanna wrote: post #236
amichal wrote: post #228

Earlier quoted context omitted.

“#” Fragments aren’t sent to the server at all. They are ONLY used to get to a specific anchor (old school) or processed by JavaScript to do something (often fake navigation by showing and hiding content). This article is adding a 3rd magic use for them.

Yeah, I know. Parent was saying that the History API doesn't need any server support, because you can just serve the same file no matter what the subpath, but my point is that lots of servers don't even have support for that. That's why the fragment is still more useful than the History API in some cases.

Ahh! that make more sense. Thanks

Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page

#267

Post by bokan »

xg15 wrote: post #109

Technical question, apart from the (valid IMO) political arguments: Google's idea to implement this is to append the text fragment to the URL in a "#targetText" pseudo-query-argument in the URL fragment part. This sounds like it would extremely easily break existing web pages who use the fragment part for their own state. In the blog post, there doesn't seem to be anything addressing this (or even just specifying how…

Feature author here.

I'd like to first clarify that this is still in the super-early stage of development; none of this is shipped or finalized yet. The feature hasn't even requested approval to ship at which point these kinds of issues would be brought up. We take web-compat very seriously. If this breaks even a small percentage of pages, it won't ship. Part of the shipping process is ensuring we have at least a draft spec (W3C,WHATWG) at least some support from other vendors.

Sorry, the explainer text came off more dismissive than I intended. I wanted to get something implemented so we could start experimenting and see how this would work in the wild. #targetText= is a a first attempt at syntax, any criticisms or data on how this might break would be appreciated.

From my (limited) understanding of how fragments are used like this today, the way this would break a page is if the page itself was using "targetText=..." and parsing the result. This is something we can and will measure and see if we have a naming collision. For pages that use a "#var=name" type fragment, we could append "&targetText=...".

I'm not tied to any particular syntax here so if I'm missing why this is a monumentally bad idea, please file a bug on the GitHub repo: https://github.com/bokand/ScrollToTextFragment/issues

Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page

#268

Post by bokan »

prepend wrote: post #193
xg15 wrote: post #109

Technical question, apart from the (valid IMO) political arguments: Google's idea to implement this is to append the text fragment to the URL in a "#targetText" pseudo-query-argument in the URL fragment part. This sounds like it would extremely easily break existing web pages who use the fragment part for their own state. In the blog post, there doesn't seem to be anything addressing this (or even just specifying how…

It should only cause a problem for pages using “targetText” as an anchor or id where someone would link to “page#targetText” I would expect that it’s possible for both to work since Chrome’s hack requires the equal sign and its parameters. So with no equal, works as spec. With equal works with hack (that will likely make it into spec). Even when a page has the targetText anchor and receives the text link param, I thi…

The proposal, as currently stated, is to use fragment id processing first. If that fails to find a target, fallback to text matching.

In other words, even if you give an element "id='targetText=something'", this feature wouldn't break that.

Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page

#269

Post by reaperducer »

reaperducer wrote: post #242
tyingq wrote: post #217

Earlier quoted context omitted.

Of course, page anchors are still in wide use, and not just on old pages. https://github.com/facebook/react/blob/master/README.md#inst...

Very wide use. I just finished a large healthcare web site that uses page anchors. Page anchors are recommended by one of the (many) federal web accessibility guidelines. This is so that people with limited motion or poor motor control, or visual impairments don’t have to scroll to find what they’re looking for on a page. It’s also how the “Skip to content” links work, which is Accessibility 101. Sorry, I’m not at wo…

Here's a reference for "Skip to content" for those who have never bothered to make their web sites usable for people who aren't 20-somethings in perfect health (Google):

https://webaim.org/techniques/skipnav/

Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page

#270

Post by jchw »

beatgammit wrote: post #248
jchw wrote: post #43

Earlier quoted context omitted.

I think this is being over thought a bit. Even in it's most primitive form, it could still be quite useful in practice. It's pretty easy to construct cases where it fails, but all such systems will fail either due to changes in content or changes in structure, and many will fail due to ambiguity as well. It's only really useful to compare how this might fare against other approaches. An example would be producing an…

Why not just use fragments? It's pretty easy to place a unique fragment at all places you care to link, except perhaps in the very nice case of reimplementing Ctrl+F, which would need JS anyway, so why not just expose an API call, like window.find[1]? I really don't understand what this brings to the table, besides making people upset. [1] https://developer.mozilla.org/en-US/docs/Web/API/Window/find

Simple, it doesn't depend on requiring the content to have lots of identifiers. While you may convince some web developers to just add more identifiers, you can't convince everyone. And for largely unstructured plain text like mailing list archives, there's not really a logical way to do that anyways.

Re: making people upset. I mean, nearly anything will upset people. One way a search engine could incentivize people to add more usable fragment identifiers is by ranking pages with them higher, but I am certain many wouldn't be thrilled by that.

If this is implemented I don't think it will actually raise serious compatibility issues, and it's not a huge deal to remove it later, it should degrade softly.

Post reply on HN