Cache-Control: no-transform redundant w/ TLS?

[Malvoz]

Is cache-control: no-transform redundant over HTTPS?

Better to focus on https which cannot be modified in flight [...]

https://meta.discourse.org/t/add-cache-control-no-transform-http-header/25152/3

Some mobile providers will compress or alter content, in particular images, to save bandwidth when re-transmitting content over cellular networks. This could break digital signatures in some cases. "no-transform" will prevent that (but again: doesn't matter for SSL [...]

https://isc.sans.edu/forums/diary/The+Security+Impact+of+HTTP+Caching+Headers/17033/

As suggested by some folks in their articles, "payload transformations" aren't possible over HTTPS. This sounds logical, but I am unsuccessful in confirming this.

In https://tools.ietf.org/html/rfc7234#section-5.2.1.6 I'm unable to traverse up to find information on payload transformation in relation to the HTTP/HTTPS protocol.

---

If it is the case that no-transform is redundant over HTTPS, then this:

server-configs-apache/src/web_performance/content_transformation.conf

Line 21 in e12ae05

Header merge Cache-Control "no-transform"

Could be (or only/and with a note stating no need to use if HTTPS?):

Header merge Cache-Control "no-transform" "expr=%{HTTPS} != 'on'"

[LeoColomb]

Good catch.
Actually, does the no-transform still useful?

(Also: https://csswizardry.com/2019/03/cache-control-for-civilians/#no-transform)

[Malvoz]

(Also: https://csswizardry.com/2019/03/cache-control-for-civilians/#no-transform)

If you’re running over HTTPS—which you should be—then intermediaries and proxies can’t modify payloads anyway, so no-transform would be ineffective.

Everyone seems to agree with that statement!

If it is still useful? H5BP doesn't default to TLS configs (which is debatable), but today more than not - developers use TLS for their websites. Which renders no-transform useless as we've established in our extensive reasearch. :)

[LeoColomb]

H5BP doesn't default to TLS configs

I plan to, while working on #1. I did it already for nginx configs. But we can't enable them by default since it require certificates we don't have.

our extensive reasearch

😎

---

@XhmikosR Thoughts?

[LeoColomb]

Side note: if we keep it, the rfc link needs to be updated to https://tools.ietf.org/html/rfc7234#section-5.2.1.6

[XhmikosR]

I don't have an opinion myself since I only use HTTPS in all my projects.

[LeoColomb]

Same for me. I think we can consider dropping it.

[markwoon]

While I'm not advocating reverting this change, I wanted to point out that Google's Lite Mode (previously known as Data Saver) does work on https, and does respect no-transform.

Reference: https://venturebeat.com/2019/04/23/google-kills-chrome-data-saver-extension/

[Malvoz]

Thanks for the information @markwoon.

The IETF RFC 7230, section 5.7.2 on transformations refers to proxies only, and the articles I listed to initially all refers to "proxies cannot modify payloads over HTTPS". However, in comment 8 in https://bugs.chromium.org/p/chromium/issues/detail?id=941948#c8 clarifies: For HTTPS pages, a Lite page does NOT use a proxy. which further suggests Google's Lite Mode is indeed able to transform payloads, even over HTTPS.

This certainly favors keeping https://github.com/h5bp/server-configs-apache/blob/master/src/web_performance/content_transformation.conf as is. Currently, the snippet applies to all content, while the Google Bot only looks for cache-control: no-transform in text/html for opt-outs. I don't think it's necessary to change anything since that's "just" Google.

From what I've read, these transformations may apply to any website really. Not only slow websites, but rather wether the user is on a slow client or not. If you have a Google account, you can use the Transcoder test tool or visit googleweblight.com with your url in the u query string parameter, such as https://googleweblight.com/i?u=https://www.html5boilerplate.com to test the effects of such transformations.

Useful articles:
https://support.google.com/webmasters/answer/6211428?hl=en
https://blog.chromium.org/2019/04/data-saver-is-now-lite-mode.html
https://blog.chromium.org/2019/03/chrome-lite-pages-for-faster-leaner.html
https://source.android.com/devices/tech/connect/data-saver
Older article (before name change from Data Saver to Lite Mode, probably shares many of the heuristics): https://developer.chrome.com/multidevice/data-compression

[LeoColomb]

Thanks for these extensive review guys!

Although I personally am not in favor of using these kind of weird tools, I don't feel confortable advocating against data savers & co usage.
I mean they are build for something useful and can be very relevant in some countries/situations, are we sure we should promote bypassing these technology?

The scenario is very different from the original arguments focusing advertisements or trackers addition.

[markwoon]

I'm going to abstain from what the default should be. I'm on slow connections often enough to know how painful that can be, but I also hate debugging caching problems.

I do vote for this getting documented.

People should decide for themselves how they want their site to behave.

[Malvoz]

@LeoColomb

I don't feel confortable advocating against data savers

While I agree that data saving is important (in fact I proposed a CSS media query allowing developers to serve lighter content based on that preference) I think developers should be wary of the fact that their content may be modified unless having opted out from it, since these transformations may disable scripts, styles and even form submissions.

are we sure we should promote bypassing these technology?

No not promoting it, but more so what @markwoon said. Until yesterday I had no idea my content was subject to transcoding.

But I agree, in most cases content transformation (certainly under Google's Web Light heuristics, e.g.: user is on a 2G connection, Google Bot finds the page will take more than 5 seconds to load) will be useful and developers should be careful opting-out.

[LeoColomb]

developers should be wary

👍

developers should be careful opting-out

That's my main concern. 😉
But let's keep it for now, indeed.