Documentation: Explain why we don't support Subresource Integrity

[chris-griffin]

I would like to suggest implementing Subresource Integrity (SRI) support for Google Fonts. This will inevitably require adding some type of versioning to the stylesheets which I know is at odds with the original intentions of using a non-versioned stylesheet to allow for seamless versioning of the actual .woff2 files. Perhaps using a versioned stylesheet could be an option for sites that require a higher degree of security?

[davelab6]

@chris-griffin good question! I'll circulate this issue with the GF engineering team and see what they say :)

[chris-griffin]

Thanks @davelab6

[tedmiston]

Just here for the +1.

@davelab6 Do you have any feedback from the GF team about SRI support?

[davelab6]

Hmmm.... the CSS returned by the GF API is different for different browsers... Could you be more specific about how you would like the GF API to work?

[chris-griffin]

@davelab6 yes, it is an interesting problem when the response changes depending on the browser/user-agent. A couple questions:

1. Do you know if the dynamic response is for performance or functionality?
2. What happens currently if no user-agent/browser is provided in the request?

If the dynamic css response is for better performance, then I would suggest adding 2 optional GET parameters: dynamic=x and version=x.x. This would ensure a consistent response, and allow high security websites to utilize Google Fonts.

[davelab6]

Do you know if the dynamic response is for performance or functionality?

I personally see both aspects.

Anyone can observe that if you use a Windows UA string, the fonts in the font-face URLs returned contain truetype hints, and if you use a Android/Apple UA string, the font files do no contain hints (which can be up to half the filesize); the latter platforms simply don't use them, so they are not included. I personally see that as performance related.

And similarly, some UA strings return WOFF or WOFF2 urls, and others return TTF or EOT; and some return all subsets with unicode-range data, others return only the subsets requested in the API url. I personally see that as functionality related.

What happens currently if no user-agent/browser is provided in the request?

Anyone can observe that if you use no ua string, you get (non-woff) TTF fonts - which is optimal for almost no browser left today, but still works :)

allow high security websites to utilize Google Fonts

Since all gf fonts are libre licensed, such websites can self-host, losing out on the above optimizations, but getting total control and url-content stability to make SRI easy :)

[chris-griffin]

@davelab6 yup, we are self-hosting currently for sensitive areas. I'm hoping you'll reconsider this issue in the future as SRI gets larger adoption.

[byterip]

Is this issue still being looked into? I really hope it's considered.

[davelab6]

The Fonts API has a dynamic response both for performance or functionality; the suggested action here is to introduce versioned stylesheets as an option for sites that require a higher degree of security, but this would complicate the product, so it won't happen.