It’s not a bug, it’s a feature, explains the Chocolate Factory

src: theregister.co.uk By Thomas Claburn in San Francisco 20 Feb 2020 at 02:07


image src: fossbytes.com

Google has implemented a browser capability in Chrome called ScrollToTextFragment that enables deep links to web documents, but it has done so despite unresolved privacy concerns and lack of support from other browser makers.

Via Twitter on Tuesday, Peter Snyder, privacy researcher at privacy-focused browser maker Brave Software, observed that ScrollToTextFragment shipped earlier this month in Chrome 80 unflagged, meaning it’s active, despite privacy issues that have been raised.

“Imposing privacy and security leaks to existing sites (many of which will never be updated) REALLY should be a ‘don’t break the web,’ never-cross redline,” he wrote. “This spec does that.”

The debate over the feature percolated last year on mailing lists and in GitHub issues posts and picked up in October when the team working on Chrome’s Blink engine declared their intent to implement the specification. The feature rollout serves to illustrate that the consensus-based web standards process doesn’t do much to constrain the technology Google deploys.

ScrollToTextFragment emerged from the W3C’s Web Platform Incubator Community Group (WICG) and the Google software engineers spearheading the initiative have incorporated feedback from developers outside of Google. But the WICG is an incubator for new web platform features rather than a standards-track body, so Google can move ahead with specs when its engineers believe their tech is ready. Standardization may or may not follow.

That may be ideal from Google‘s perspective because it allows technology to evolve and improve without it having to ask anyone for permission. But because Chrome so dominates the browser market, its unilateral innovations tend to become obligations for competitors, particularly if web developers embrace them.

“I think that Google has dramatically more power in web standards than any other party, among other reasons because it knows that other browsers will need implement non-standard Google functionality, or round privacy protections down to meet Google‘s implementation out of web compatibility concern,” Synder said in an email to The Register.

“Some browsers are large enough that they can sometimes say no at important junctures (Apple in particular, others less often) but Google largely sets the web everyone else needs to bend towards or away from.”

A chart posted to Twitter by Brave CEO Brendan Eich offers a visual representation of Google‘s dominance in terms of the number of people it had last year on the WICG compared to other companies.

Also (from last summer, hasn't changed much): pic.twitter.com/bvmjwIDSG0
— BrendanEich (@BrendanEich) February 5, 2020

How did we get here?

ScrollToTextFragment first surfaced in December, but wasn’t active by default. It appeared following four code review endorsements known as LGTM, or Looks Good To Me. Three of its four approvers work for Google.

To understand potential privacy concerns, it helps to understand a bit about the specification. HTML already has an anchor element that, when appended to a link, takes the web site visitor to the corresponding web page and to the specific text marked by the anchor.

But an anchor has to be created by the web page author. ScrollToTextFragment doesn’t require prior declaration. It can be created by anyone providing or entering a link, such as a search engine and anyone sharing a link.

Its syntax piggybacks on the anchor element (#) and contains additional parameters, which can consist of a specific word or several words, and additional modifying directives. This is the format:

html #:~:text=[prefix-,]textStart[,textEnd][,-suffix]

To link to The Register’s About Us section at the bottom of the page, you’d use a URL like this in Chrome 80+:

html https://www.theregister.co.uk/#:~:text=about%20us

It could be quite useful, particularly if you run a search engine and want to offer users more specific page navigation.

Snyder spelled out some worries about the spec back in December in a GitHub issues post, noting that it appears to enable some privacy attacks by exposing new types of information to new types of observers.

“Consider a situation where I can view DNS traffic (e.g. company network), and I send a link to the company health portal, with html #:~: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.”

Mozilla has been equally dubious of the current spec. David Baron, distinguished engineer at Mozilla, observed in December:

“My high-level opinion here is that this a really valuable feature, but it might also be one where all of the possible solutions have major issues/problems. So I think the question we should think about is how the problems of the solution chosen here compare to the problems of other options and how they compare to the value of the feature.”

Google‘s engineers have not ignored worries about the security and privacy risks. To their credit, they’ve gathered them together into a single document and they’ve clearly been engaged in understanding what people are worried about. It’s just that they’ve concluded the concerns aren’t that big a deal or can be dealt with to their satisfaction.

“We discussed this and other issues with our security team and, to summarize, we understand the issue but disagree on the severity so we’re proceeding with allowing this without requiring opt-in (though we are still working on adding an opt in/out),” explained David Bokan, Chromium engineer, in a post on Tuesday, allowing that there are some risks but that people can differ on their severity.

Asked whether Google developers have a different set of assumptions about privacy than those working for other browser makers, Snyder said,

“I wouldn’t feel comfortable guessing anyone’s motives, but unambiguously they’re working from a different set of priorities.”

®