- From: Baldur Bjarnason <baldur@rebus.foundation>
- Date: Thu, 27 Jul 2017 12:14:30 -0400
- To: Laurent Le Meur <laurent.lemeur@edrlab.org>
- Cc: "public-publ-wg@w3.org" <public-publ-wg@w3.org>
> On 27 Jul 2017, at 11:59, Laurent Le Meur <laurent.lemeur@edrlab.org> wrote: > > Hi Baldur, > > An integrity check on resources is a powerful feature, as "a user agent will refuse to render or execute responses that fail an integrity check". It more powerful than simply checking a date of modification. > What is the use case in which the publication would be declared "broken"? Security is the pre-existing use case. When a resource fails its integrity check it doesn’t get loaded and if it is a vital resource, the parent resource is then pretty broken. This is going to be a pretty important feature for packaged web publications, for example, so if we can build on it, we should. I’m not sure the accessibility use case is one that we can solve beyond just recommending that resources include modification dates and that if an immutable subresource is an absolute necessity, the author should use the integrity attribute so safeguard against unknown versions being used. If you start messing around with immutability, update mechanisms, and resource versioning, you get pretty deep into dark corners of the HTTP ecosystem pretty quickly. - best - Baldur Bjarnason baldur@rebus.foundation > > > >> Le 27 juil. 2017 à 16:18, Baldur Bjarnason <baldur@rebus.foundation> a écrit : >> >> Hi all, >> >> The web community has been dealing with a similar problem for a long time. Namely, you can only make assertions of safety for specific versions of a resource. The solution that browsers are implementing is subresource integrity[1]. The npm community has also settled on the same algorithm as a solution for demonstrating the integrity of packages being installed[2]. >> >> The basic concept is that the referencing resource adds an integrity attribute to the references it makes to subresources. This integrity attribute tells the UA that the reference is intended to be to that specific version of the resource and no longer applies if the subresource has been updated. >> >> As far as updating goes, the web community has for a very long time relied on a combination of various feed formats and PubSubHubbub (now called WebSub[3] in its W3C incarnation) as an update mechanism. I’m pretty sure that update mechanism is utterly and completely out of scope for the Publishing WG and possibly even out of scope for the W3C given that atom is an IETF specification. >> >> [1]: https://www.w3.org/TR/SRI/ >> [2]: https://docs.npmjs.com/files/package-lock.json >> [3]: https://websub.rocks >> >> - best >> - Baldur Bjarnason >> baldur@rebus.foundation >> >
Received on Thursday, 27 July 2017 16:14:55 UTC