Page MenuHomePhabricator

Consider disabling Chrome Lite pages for Wikipedia on Chrome on mobile with Cache-Control: no-transform
Open, Needs TriagePublic

Description

With Chrome 73, which was just released, Google enables a new feature called "Chrome Lite Pages" for Chrome users on Android phones. If you enable the Data Saver (you get prompted to do that at least on Chrome Beta on Android) the pages you visit will be a Lite version, if Chrome think they are slow (see the public announcement https://blog.chromium.org/2019/03/chrome-lite-pages-for-faster-leaner.html). More info about the feature can be found at https://www.chromestatus.com/feature/5148050062311424 (but it is still pretty vague).

When the Lite page is served, Chrome sends back the full URL the user tries to access to Google that then will get the page in a proxy and send back a "massaged" version of the page. All of this with the browser hiding the fact that the lite page is served from a Google server instead of our own.

We can disable this by setting no-transform in a cache-control HTTP header.

This seems like a privacy concern, because unlike other Chrome features like "Sync" that send all the URLs people visit to Google, it's very unclear in this case that something like this is happening. To an end-user, it might look like we are responsible for the lite version of the website (after all, the URL displayed in the browser is ours).

Overall, enabling no-transform is probably a good thing regardless of Chrome Lite, as it's a signal to all proxies that we are against any transformation (eg. injecting ads...): https://tools.ietf.org/html/rfc7234#section-5.2.1.6

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 18 2019, 10:49 PM
Gilles renamed this task from Disable Chrome Lite pages for Wikipedia on Chrome on mobile to Consider disabling Chrome Lite pages for Wikipedia on Chrome on mobile with Cache-Control: no-transform.Mar 19 2019, 8:27 AM
Gilles added a project: Security-Team.
Gilles updated the task description. (Show Details)
Gilles updated the task description. (Show Details)
Gilles added a project: Performance-Team.

I don't have my Android device handy, but this is not applying Google Web Light, correct? Would it be possible for someone to post screenshots of the resultant treatment for our pages?

If I understand correctly, users need to actively enable this feature and it sounds like the hope is that the UI in Chrome settings would be clearer about the interception of the request.

Looping in @JKatzWMF and @atgo, as we've been looking at Google Web Light trends. Active disablement of data saver by the no-transform rule would probably have the side effect of disabling Google Web Light, plus potentially affecting Android Go users.

We should probably meet as a group to discuss further to figure out potential options.

Krinkle added a comment.EditedMar 20 2019, 5:25 PM

@dr0ptp4kt Ha, comment clash.

Indeed, this is not the same thing. Chrome Lite is a transparent transformation Chrome applies to any URL you're browsing if the user qualifies (right now I believe the qualification is you have enabled "Data Saver" mode or are on effectively 2g-slow connection).

The address bar url does not change, there is no redirect. It's not correlated with Google search results linking to something different (afaik).

Its output and visual appearance are also different.

Google Web Light has its own brand and layout that always looks the same (hamburger menu, first-level domain name, info button, then plain content extracted somehow without styling, and low-res images).

Chrome Lite appears to mostly keep the original layout and styles in-tact, but strip a bunch of scripts and styles it considers optional, and makes images clickable placeholders.

Compare:

Google Web LightChrome Lite

@Peter can probably provide a screenshot of the settings where this is enabled, where it’s indeed not mentioned anywhere that enabling it means Google gets to intercept full URLs of everything you visit. In fact Google misleads the user into thinking that we served the request, since our domain is displayed in the URL bar, not Google’s.

Peter added a comment.EditedMar 21 2019, 8:22 AM

For me it looks like this, the popup happens when I force 2g connections, so not sure when it happens for real users:

Also they fixed the missing search/navigation in Timos screenshot after I tweeted about it. The documentations says they can apply different rules on different places, so not sure the behavior is the same for everyone as on my phone. As in the documentation in the description: some changes happens browser side, some server side (but showing our URL).

They actually added a small popup too now first time you visit a "Lite page":

I've updated to stable 73 today since it become available in Play store.

Maybe we can work our way out of this by telling Google that they can't display our URL for content that comes from their servers without our approval? There might be legal grounds for this, even.

It seems like in the screenshot from @Peter it's now fairly clear about the proxying. Obviously the visual nudge is to actually turn on the feature, but it seems like the terminology is pretty clear. In this regard, this makes it more on par with something like Opera.

I would prefer if the wording "Lite page provided by" gets changed to "Lite page served via". The introduction of the clear brand identifier was intentional, which I suspect has partly helped users distinguish their browsing context, and so it would be helpful to ensure that people don't get confused about the actual content provider.

One thing I would like to understand is if we can measure this access in our web logs. It would be problematic to not be able to understand the impact of the traffic. Ideally it would be nice to know how often users are hitting this condition, as it potentially suggests that we should figure out an intervention in our serving approach.

Gilles added a comment.EditedMar 21 2019, 12:04 PM

We could ensure that people aren't confused with a survey aimed at users who have this turned on. But I suspect that Google's reprocessing removes all of our javascript, seeing how extreme it looks. And we need a way to detect when it's Google's proxy making the request. As it stands it's unclear whether they use a different Google bot for this, or if they repurpose the HTML they already index for their search engine (the latter would mean we can't even inject HTML for the Lite case).

The ability to serve a custom message to Lite pageviews would be critical if the outcome of such a survey is that a majority people have no idea that their full browsing history is being recorded by Google as a result of this feature. While the messages that Peter has shown makes the data pipeline clear to us, it requires a certain level of computer literacy to figure that out, particularly when the URL you see is a Wikipedia one. It's not like the feature constantly reminds you of the privacy implications of the setting you turned on once upon a time.

The Reporting API is simple to use, what needs building is an ingestion point for it. For Feature Policy Reporting: T209572 my plan was to feed those (other types of reports, also using the Reporting API) to logstash, but you probably want to send it elsewhere for what constitutes a different kind of pageview.

kchapman moved this task from Inbox to Radar on the Performance-Team board.Mar 25 2019, 8:55 PM
kchapman edited projects, added Performance-Team (Radar); removed Performance-Team.
Bawolff added a subscriber: Bawolff.Apr 2 2019, 3:10 PM

Hmm, I enabled it again today to test it out and now the "Lite" bubble is removed and there's nothing signal that I'm using a Lite page. I could see that I'm on a Lite page though since no images is loading. Have we seen any drop in traffic since it was released?

We got feedback in the upstream issue that there's no way to test today but they will add a flag: https://bugs.chromium.org/p/chromium/issues/detail?id=956685#c13

In Chrome 77 it will be possible to "try" it out again: https://cs.chromium.org/chromium/src/components/previews/README