Hello Emily, Ignoring SRI, the distinction seems fairly theoretical to me because the number of users who will actually check a hash is so small. Indeed, last year we conducted a large-scale online survey [1] on that topic. It demonstrated that, although 71% of the respondents declare to download program files from sources where they could be potentially corrupted, only 1.7% check the integrity of these downloads. [1] - https://blog.acolyer.org/2018/11/28/towards-usable-checksums-automating-the-integrity-verification-of-web-downloads-for-the-masses/ I would like to hear from developers if they are distributing downloads that they can reasonably SRI but can't move to HTTPS. I know Mike and others have argued vociferously in the past against allowing SRI to substitute for HTTPS… I think that HTTPS and SRI are complementary and cannot substitute each other: if an attacker gains access to a remote host that serves web downloads over HTTPS, the file could be tempered anyway. Hence, a new version of SRI covering other sub-resources (<img>, <audio>, etc.) and possibly web downloads (<a>) would allow to mitigate this kind of attacks. At the University of Lausanne, we started working on that topic and we plan to propose some revisions of the specification [2]. Regarding the developers who are distributing downloads, a recent (very flowery) release notes by the notepad++ team suggests that the existing solutions are not satisfying [3]. [2] - https://github.com/checksum-lab/checksum-lab.github.io/blob/master/README.markdown [3] - https://notepad-plus-plus.org/news/notepad-7.6.4-released.html - Bertil Chapuis
Received on Friday, 12 April 2019 08:24:45 UTC