Support Subresource Integrity
awnumar opened this issue · comments
You're able to ensure the integrity of any scripts you load by making use of SRI:
<script src="https://utteranc.es/client.js"
repo="cryptolosophy/cryptolosophy.org"
issue-term="pathname"
integrity="sha384-DPph3TeQWMfa+DwFjWGnI1hGXuOXw4Kpg3Uk/m+qAlgnQJ0njBscbs8AT11PFwZB" crossorigin="anonymous"
async>
</script>But if the script you're loading changes, then SRI breaks and browsers will refuse to load it completely. I could just host the script locally to ensure that it doesn't change but then I'd lose the benefits of CDN caching and also I don't really understand the intricacies of utterances to be sure that it'd work perfectly that way.
So what do you recommend?
Quick solution: you could generate the hash for https://utteranc.es/client.js using https://www.srihash.org
<script src="https://utteranc.es/client.js"
repo="jdanyow/utterances-demo"
issue-number="15"
async
+ integrity="sha384-Xzvl+Tf9crKsJBG5htkEvAri2XbSYf2jsxOcpHtkZ3xRUJsDvSOdxl78utgsbf1h"
+ crossorigin="anonymous"
+ onerror="insertAdjacentHTML('afterend', 'Error loading utterances. If you are the site owner and have enabled SRI, verify the hash value for https://utteranc.es/client.js at https://www.srihash.org/')">
</script>Running example here: https://jsfiddle.net/jdanyow/8xjse6r1/ (edit the hash value to see the error behavior).
The trouble with this approach (as you know) is utterances will stop working on your site when an update is published that changes the client.js script. That script is not updated very often but indirect changes to things like the transpiler (typescript), bundler (parcel) or minifier (uglify) could cause the hash to change. I imagine this would happen quite often.
A proper solution would involve maintaining versioned builds so that folks wanting to use SRI could opt out of automatic updates. Eg <script src="https://utteranc.es/1.0.1/client.js" integrity="...." ....>. For that to work long term I'd need to manage backwards compat all the way down to the api. Doable but I'm not sure I want to take on the extra work at this time.
Another option would be to create a "release notification" issue that folks could subscribe to where I could give notice of upcoming hash changes. Site owners could subscribe and update their integrity attributes ahead of the release (multiple hashes separated by whitespace are permitted in the integrity attribute). This would ensure the upgrade experience is seamless.
All that said, it's probably pointless to use SRI with the current utterances architecture. The utterances widget is sandboxed in an iframe for a couple reasons: 1) prevent host page styles from breaking the widget and visa versa and 2) prevent the host page from accessing the user's github auth token. Unfortunately there's no way to specify an integrity attribute for iframes. Initially iframes were in the working draft of the SRI spec but they never made it to the final draft. I don't think it's worthwhile to check the integrity of https://utteranc.es/client.js if the first thing the script does is create an <iframe src="https://utteranc.es/utterances.html"> element which we cannot verify integrity on.
Does this make sense? Let me know if you have any questions/ideas to improve this.
@jdanyow Good point about the iframe. I was going to suggest hosting it locally as an alternative to versioned hosting, etc. Perhaps in that scenario you'd be able to verify the integrity of every local file using some kind of manifest? Here's a great writeup by CryptPad, who attempted to solve a similar issue.