You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that a fetched resource must match.
– https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
This is a placeholder issue with the current state of things.
In my mind there are three "stages" of SRI support we could think of, and only first one can be done without internal support from browser engines and standards bodies.
🟠 (C) Things bigger than 2MiB run into Large Blocks problem. Supporting bigger assets require browser to also understand and implement dag-pb and UnixFS, and, have access to intermediate blocks with minimal metadata necessary for verifying the root CID does match the DAG.
If the asset was fetched trustlessly, browser already has these blocks. If it was fetched indeserialized form, additional blocks need to be fetched somehow to facilitate verification.
This is a placeholder issue with the current state of things.
In my mind there are three "stages" of SRI support we could think of, and only first one can be done without internal support from browser engines and standards bodies.
🟢 (A) Existing SRIs could be turned to CIDs and payload could be trustlessly fetched and verified from IPFS, e.g. trustless gateway, when possible, instead of
https://
src
:sha256-UTe33acZ78PiBp03/u/vVxeFkmS2rOt9qv3HukgejCg=
→bafy..
(withraw
codec)🟠 (B) Extend
integrity
attribute to support CIDs as-is.cid
needs to be registered at IANA at https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml, as browser specsRef.
The text was updated successfully, but these errors were encountered: