Chrome highlights text on webpages: how to disable

This blog explains how to stop Chrome's highlighting of text on some webpages you visit after clicking on Google search results snippets. 

The problem: Chrome now scrolls directly to the highlighted text ("text fragments", meant to reflect your search terms) on the webpage in question. It also mangles the URL in the browser so that the web address has, appended to it:
#:~:text=whateverTextFragmentIsToBeHighlightedWhichCanBeVeryLong

For anyone who's managed to escape this new feature, here's a direct example. (Apparently it also does this in Apple's Safari.) Not everyone wants that behaviour in their browser and can even find it annoying and unhelpful. This new Chrome feature was introduced by Google in early June 2020. Websites can opt out, but it's much more difficult for Chrome end users to disable it.

To prevent this happening via Chrome flags is no longer possible. Most people may not be able (or want) to set enterprise policies or mess with their registry (which even stopped Chrome working for one person), or install the Redirector extension with more fiddling.

So, here's my own relatively easy fix, which you can use to change the webpage back to what it should be, rather than preventing or getting rid of the new feature. My solution to this issue:

• "Reverts" you to the webpage you were trying to view, without highlighting the text fragment or scrolling to it.
• Cleans up the URL in the address bar too, removing the # and all the stuff after it.
• (Optional - even copies the "clean" URL to your clipboard for easy sharing.)

It involves setting up a new bookmarklet or favelet with some Javascript, that you can just click (or use a hotkey to access), to sort out the issue quickly. If that description fazes non-coders, not to worry, here's a very simple step by step:

 

Solution to remove unwanted text highlighting

1. Make your bookmarks bar visible in Chrome if it's not already (click top right up arrow > Bookmarks > Show Bookmarks, or press Ctrl-Shift-b).
2. Bookmark any webpage you like (e.g. Ctrl-d and Enter), but drag it so it's visible in the bar.
3. Rightclick the new bookmark in the bar, select Edit.
4. In the Name box, change it to e.g. Cleanup, or even just 1 (I'll explain the latter later), ideally starting with a letter which your existing bookmarks don't start with.
5. In the URL box, clear what's there, and copy and paste the following text in there instead, exactly as is (don't add spaces etc.), then click Save:
   javascript:var url=window.location.href; cleanurl=url.split('#')[0]; window.location.replace(cleanurl); 
6. In future, if you find yourself on a webpage with highlighted text fragments and the long URL after clicking on Google search results, to clean it up just:
1. Click that new bookmark in the bookmarks bar, or
2. (For those who like keyboard shortcuts) Press Alt-e then b then 1 (or whatever was the first letter of the new bookmark's name) then, if necessary, Enter - which has the same effect as clicking it.
7. Optional: if you also want to be able to copy the clean URL automatically to your clipboard for pasting into an email etc. then, in step 5 above, instead of pasting what was shown there just paste the following exactly as is:
   javascript:var url=window.location.href; cleanurl=url.split('#')[0]; var input=document.body.appendChild(document.createElement("input")); input.value=cleanurl; input.focus(); input.select();   document.execCommand('copy'); input.parentNode.removeChild(input); window.location.replace(cleanurl); 

I hope that's helpful.

Schrems II additional safeguards: confidential computing

The highest EU court (CJEU) in the Schrems II ruling said that standard contractual clauses (SCCs) can, in principle, be used to legitimise transfers of personal data outside the EU/EEA, provided "additonal safeguards" are implemented where appropriate (or "supplementary measures", as the European Data Protection Board or EDPB has called them).

I previously blogged about providing additional safeguards through encryption. And indeed Amazon, regarding its AWS cloud service and Privacy Shield's invalidation, emphasised its "technical and physical controls designed to prevent unauthorized access or disclosure of customer and partner content", and "advanced encryption and key management service".

I also noted that data could be encrypted in storage and in transmission ("at rest" and "in transit"), but there were difficulties with operating on encrypted data, although work was proceeding on areas such as homorphic encryption.

I just wanted to expand on that to point out that, in fact, it is a reality today that secure operations on data are possible in practice - without the third party cloud provider or other service provider being able to "spy" on the computing operations or access intelligible data that they could then give to third country intelligence or security agencies.

The main development here is "confidential computing", as it's become known as. This involves protecting data in use, within a "trusted execution environment" (TEE) which safeguards the data from outside viewing or interference. TEEs, or enclaves as they're also termed, can be implemented via hardware, e.g. Intel's SGX (Software Guard Extension) which seeks to protect areas of memory running the relevant application code on the relevant data, or via software. Edited: to clarify, yes, this isn't really working on encrypted data, it's working on unencrypted or decrypted data, but only when (effectively) it's within a secure hardware "box" that the cloud or other service provider can't peek into. This means they can't see what the data in the box is, or what operations are being conducted on that data, so they can't spy on the data or processing or tell any authorities what it is.

What's exciting is that the Confidential Computing Consortium, spearheaded by the Linux Foundation, was formed just last year, in Oct 2019, with members including Alibaba Cloud, Arm, Google, Huawei, Intel, Microsoft and Red Hat and also Baidu, Bytedance, Fortanix, Oasis Labs, Oracle, Swisscom, Tencent and VMWare. By the end of June 2020, it had been joined by companies such as Accenture, AMD, Facebook, NVIDIA, and R3 (see Members list and FAQ, CCC overview and White Paper).

Open source projects under the CCC's umbrella include an SGX SDK for Linux, an Open Enclave SDK to build TEE apps that can run across multiple TEE architectures (Microsoft) and Enarx, a platform for TEEs to create and run “private, fungible, serverless” applications (Red Hat). 

In addition, Microsoft already offers confidential computing on Azure, i.e. in the cloud using SGX, while Google offers (although not under CCC) Asylo, an open source framework for confidential computing. AliCloud uses Fortanix, also mentioning SGX. As we're talking cloud, what about Amazon's AWS, you may ask? Well, interestingly AWS is absent from the CCC membership list, but it too, in Dec 2019, had launched "Nitro enclaves" for customers to create "isolated compute environments" to process "highly sensitive data", initially in preview phase.

UPDATE: after I posted this blog, I found further articles on confidential computing so I want to add the links here: about IBM's offering of confidential computing in its public cloud and its launch of fully homomorphic encryption toolkits, and about the use of its confidential computing services (another article), again in the public cloud, by the likes of Bank of America, Daimler and (for healthcare data) Apple.

Use of technologies like confidential computing should stymy or at least deter third party vendors' and/or third country authorities' attempted monitoring or surveillance of data in use - regardless of where the servers conducting the processing are geographically located, i.e. there's no need for data localization in order to protect personal data (or other sensitive data) properly! Couple the use of confidential computing with strong encryption of data at rest and strong encryption of data in transit, and Roberta's your auntie.

What's the catch? This is all relatively new still, so there might well be teething issues. And no doubt confidential computing will be more expensive than "normal" computing, but costs should come down in future as is common with new technologies. I wonder if the CCC will go for a certification for confidential computing under the GDPR's Arts.42-43 in future? Or even Art.46(2)(e) or (f), codes or certifications enabling transfers? (as I've argued before, there shouldn't be a need for "binding and enforceable commitments of the controller or processor in the third country to apply the appropriate safeguards" if they can't even access the data in question. But Art.46 says what it says...).

(Another area worth considering is secure multiparty computation or MPC, but I didn't want to hold up this blog post while awaiting more info on that. There seems to be an industry consortium there too, the Multi-party Computation Alliance.)