Chrome deploys deep-linking tech in latest browser build despite privacy concerns 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 …
If I'm correct in the interpretation of the API, one must wonder why such an API was created in the first place.
If the API send the ScrollToTextFragment to the internet source to fulfill, in other words the search engine / server du jour sends back a page at the relevant content.
But why? This could have been handled exclusively *inside* the browser, as ScrollToTextFragment is essentially equal to a Find in Page text search.
There reinvented the wheel and broke it by sending a query outside the user's box for no reason.
This post has been deleted by its author
I can't find any reference to that either, but if the feature was implemented entirely within the browser the how could there be any security issue? I agree though - there is no reason why it shouldn't and couln't be implemented entirely within the browser.
I don't get it either way
It is just in the browser. The supposed security issue are related to timing attacks coupled with JS, but I personally think if that's a thing, this new linking ability is the wrong place to fix it.
We can certainly hope! But people will use the functionality whilst still signed in to their Google accounts - so now Google will know not ONLY what pages you read, but once you share that content with Scroll To, precisely what words and sentences strike you with specifically-high interest.
And then ad double-target you for it.
This is being done in the browser: you identify somewhere on the page and send a link to someone else using the API.
The spying is done by any machine able to read the URL but I think this is only marginally more invasive than knowing the base url. Any spyware will be able to summarise what the page was about.
No. Anchor text is never part of the URL that travels over the network.
The supposed security issues are timing attacks: https://docs.google.com/document/d/1YHcl1-vE_ZnZ0kL2almeikAj2gkwCq8_5xwIae7PVik/edit#heading=h.uoiwg23pt0tx
No problem!
There is more information on the format and syntax here: https://github.com/bokand/ScrollToTextFragment
Other commenters posted before, and I think they track the issue.
It's not security that the problem, it's privacy. If you email a link with embedded Scroll To, the full URL goes through the internet to the server, thereby announcing to said server the true sub-content that you are specifically interested in. Imaging looking up a full text of a day's court precedings but you're really only interested in the trial of the well-endowed pRon performer. The server now knows this if you clicked that Scroll To-embedded link.
However, if it were implemented exclusively in the browser then said browser can strip the Scroll To content out of the URL prior to transmission, only keeping the Scroll To content to itself. It would them act on the Scroll To content when the page was received by using a JS-activated Find In Page function, thereby keeping outside entities out of the Jump To functionality entirely.
But now anyone clicking on a Scroll To-enabled URL is giving away their full intent, not just a general idea, of exactly and precisely the content that interests you. Direct marketing, hidden profile building and user telemetry all get an enhanced hit, thanks to embedded pinpoint scroll to only the sentence you desire
I'll make sure NEVER to click on that type of URL.
It's not security that the problem, it's privacy. If you email a link with embedded Scroll To, the full URL goes through the internet to the server, thereby announcing to said server the true sub-content that you are specifically interested in.
No it doesn't. The browser never sends anything past the "#" to the server. It has no need to anyway - the same page is pulled in regardless of where the users "cursor" is placed, just the same as with traditional anchors.
If a browser does send anything after the "#", it's buggered!
Check the links I've already posted.
Currently the spec requires a web page author to create anchors on their web page. This new functionality will allow a 3rd party, in this case Google, to link to any portion of any existing page. If you have a page containing descriptions of all the albums of a group, say the Beetles, with a paragraph describing each album. If someone searched for 'Abby Road' this feature would allow Google to create a dynamic link that would take the user *directly* to the section on that album. Seems like a _great_ feature, right? Unfortunately it will let Google and other 3rd parties know more about what you are searching for. Hence the privacy issue.
I hope that clears things up.
I'm in general agreement with you – Google already knows what you searched for – but the provider of the link will also know whether you fast-forward to a particular section. Not that this will really tell anyone any more than existing scroll-events would. But there will undoubtedly be unintended consequences of the function.
But why? This could have been handled exclusively *inside* the browser, as ScrollToTextFragment is essentially equal to a Find in Page text search.While the article doen't mention it, the github link (which I have modified using an anchor to the specific page-embedded anchor ;) ) in the article does have Google's explanation, whether I agree with it or not, reproduced below (emphasis mine):
When following a link to read a specific part of a web page, finding the relevant part of the document after navigating can be cumbersome. This is especially true on mobile devices, where it can be difficult to find specific content when scrolling through long pages or using the browser's "find in page" feature. Fewer than 1% of clients use the "Find in Page" feature in Chrome on Android.To enable users to more quickly find the content they're interested in, we propose generalizing the existing support for scrolling to elements based on the fragment identifier. We believe this capability could be used by a variety of websites (e.g. search engine results pages, Wikipedia reference links), as well as by end users when sharing links from a browser.
STTF isn't an API. It's a user-agent (browser) behavior initiated by an extension to the URI syntax.
Personally, I think it's crap; though as WICG ideas go, it's somewhere around median crappiness. I'm hoping Dragon (my choice of Chromium-based browser when I really, really have to use a Chromium-based browser) either doesn't adopt it, or lets me disable it.
(WICG notes that users can just use the browser's find feature to achieve the same result, but that "Fewer than 1% of clients use the 'Find in Page' feature in Chrome on Android". What does that tell me? It tells me there's no great desire in the user base for STTF.)
Wonder what the GDPR implications of this are? Does knowing what your viewers are looking at section by section or word by word imply you are now a data processor and can be sued / fined into oblivion?
If so, this could become a toxic feature only deployed by certain large USA companies. Just the way Google likes it.
https://mobile.reuters.com/article/amp/idUSKBN20D2M3
Google is planning to move its British users' accounts out of the control of European Union privacy regulators, placing them under U.S. jurisdiction instead, sources said.
The shift, prompted by Britain's exit from the EU, will leave the sensitive personal information of tens of millions with less protection and within easier reach of British law enforcement.
An employee familiar with the planned move said that British privacy rules, which at least for now track GDPR, would continue to apply to that government's requests for data from Google's U.S. headquarters.
considering the ICO wrote a large part of GDPR and even wanted it to go further, similar to Health and saftey legislation, I dont see any reason uk.gov will water any of it down any more than it has been.
Anyway, Providing google signed up to the Pan-Atlantic Profits Plaster aka Privacy Shield then its safe as far as DPA18 is concerned.
That was before Prime Minister Cummings took control. They've ALREADY said they are relaxing water quality regulations.
and to hell with the rest of us.
Time that they were taken down a peg or three (like Facebook)
Another reason NOT to let Chrome anywhere near my kit. (As if I needed more than one in the first place... ie. it comes from Google)
All the internet is Google's or so they think.
The article provides a link to the WICG Github repository for the STTF proposal, which has a README.md that explains their rationale, including how STTF differs from fragments and user-initiated searches.
Essentially, it comes down to "we didn't like either of the wheels we already have, so we invented another wheel".
I used to be annoyed by WHAT-WG, but WICG is far worse.
" But because Chrome so dominates the browser market, its unilateral innovations tend to become obligations for competitors, particularly if web developers embrace them."
The 90s called ...
" But because Internet Explorer so dominates the browser market, its unilateral innovations tend to become obligations for competitors, particularly if web developers embrace them."
" But because Chrome so dominates the browser market,
......
" But because Internet Explorer so dominates the browser market, its unilateral innovations tend to become obligations for competitors, particularly if web developers embrace them."
Which is why I refer to GoogleChrome (and the entire quagmire of Chromium in general) as "MSIE6-revisited". It's the same disaster happening all over again.
"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."
Wrong! Wrong! Wrong!
1) DNS traffic has nothing to do with it.
2) If he really means "URLs", then, there is no issue, as the anchor text is never sent as part of the URL (it's dealt with internally)
3) If his scenario was possible, it would be possible with or without this new feature.
No, he's right.
Here's the attack:
1. Find a page that:
1.1. Dynamically loads additional content based on when it scrolls into view. Many sites do this with images, for example. (Yes, it's extremely annoying; but it's common.)
1.2. Has some target content that you want to test for far enough down the page that it won't scroll into view immediately.
2. Put a link to the page with an STTF fragment referring to the target content on a shared site (the "health portal" in this example).
3. Victim is interested in the target content, so clicks on the link.
4. DNS traffic indicates a request to resolve the dynamically-loaded content from the target area of the page from the victim's system.
STTF can activate side channels, such as load-on-scroll content.
If you really must use Google, DuckDuckGo allows the use of bangs: e.g., terms followed or preceded by !g for Google, !gi for Google images, and !w for Wikipedia. This should give some added anonymity. Because I may be paranoid, I tend to run searches through a VPN and a private DNS with an ad-blocker. Funnily enough I see almost no advertising, and the little that does get through appears not to be targeted.
DuckDuckGo user here, too. Very interested in privacy issues & protecting mine. Google, on the other hand, wants to monetize everything they can learn about me. Nature of the beast. Like the government, they ARE NOT there to help us. They exist to protect themselves by increasing their power & control over the populace. A very simple concept enhanced by our high tech world.
We still have choices via organizations who work hard to protect & give us those choices like DuckDuckGo & Firefox. Most sheep stay with the main flock. Like schools of fish who are fed upon by predators constantly. Wolves (Google) feed on the weak, ignorant outliers (95% of browser users). Be fast & try & stay in the middle of the flock/school. :D
Predators also attack each other. Just say'n.
God bless.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
