├── README.md └── explainer.md /README.md: -------------------------------------------------------------------------------- 1 | # Source Code Transparency 2 | 3 | Source Code Transparency is a proposed mechanism to publish (the hash 4 | of) the source code of web apps to a transparency log, allowing auditors 5 | to check that no malicious code was deployed for a given web app. 6 | 7 | See the [explainer](explainer.md) for more details. 8 | -------------------------------------------------------------------------------- /explainer.md: -------------------------------------------------------------------------------- 1 | # Source Code Transparency 2 | 3 | ## Problem Statement 4 | 5 | Today, whenever you open a web app, the browser fetches and runs its 6 | source code from the server. This enables the ease of deployment and 7 | iteration that the web is known for, but can also pose security risks. 8 | In particular, for web apps that don't want to trust the server, such 9 | as those using client-side encryption to protect the user's data before 10 | sending it to the server, or those processing the user's data entirely 11 | client-side without sending any sensitive data to the server, the 12 | current security model of the web is insufficient. 13 | 14 | After all, if a web app claims not to send sensitive data to the server, 15 | this is very difficult for users to check, as they would need to read 16 | (and understand) the source every time it's loaded from the server. 17 | Even for security researchers, such a claim is impossible to verify, as 18 | the server could simply serve a different version of the web app to a 19 | user it wants to target than to the security researcher. 20 | 21 | Therefore, we would like to propose a mechanism to enable security 22 | researchers to audit the source code of especially-sensitive web apps 23 | that is (or was) sent to any user, not just to themselves. 24 | 25 | Our goal is only to allow detection rather than prevention of malicious 26 | code, possibly after the fact, as we believe this will still deter 27 | servers from serving malicious code. Additionally, preventing malicious 28 | code from being deployed would require mandating security audits prior 29 | to deploys, which would slow down and fundamentally change the 30 | deployment model of the web. 31 | 32 | ## High-level Proposal 33 | 34 | To accomplish the above, the source code of (a given version of) a web 35 | app should be published to a transparency log, similar to [Certificate 36 | Transparency][1]. Then, when opening a web app, the browser should 37 | check that the fetched source code was received by (and is or will be 38 | included in) the transparency log, and only run it if so. Then, 39 | security researchers can check the transparency log for all published 40 | versions of a given web app, and check that none of them contain any 41 | malicious code. 42 | 43 | To aid the auditing process, web apps may want to employ additional 44 | existing and proposed security mechanisms, such as CSP, SRI, SBOMs, 45 | reproducible builds, etc. These mechanisms, which currently only allow 46 | the developer of web apps to check the security of the web app, would 47 | additionally allow external security researchers to audit a web app, if 48 | it used a mechanism such as Source Code Transparency. 49 | 50 | ## (More) Detailed Proposal 51 | 52 | To simplify the distribution and integrity verification of web apps' 53 | source code, we could make use of [Web Bundles][2], and publish a hash 54 | of the bundle to a transparency log. 55 | 56 | The transparency log could be structured as an append-only chain of 57 | Merkle Trees, each of which serves as a map of `(domain, version)` keys 58 | to `hash(bundle)` values (where the key could be hashed and interpreted 59 | as a binary path in the binary tree, with the value of the final leaf 60 | being the hash of the web bundle). Web apps could submit the hash of 61 | the bundle to the transparency log, which would periodically include 62 | all (existing and new versions of each) web app in the next Merkle Tree. 63 | Auditors could check that the transparency log is behaving consistently 64 | and not changing the hash of old versions of web apps, for example. 65 | 66 | Then, when loading a participating web app, the browser would check the 67 | latest Merkle Tree and verify that the hash of the bundle received is 68 | included in it, and warn the user if not. To still allow instantaneous 69 | deploys, we could allow this check to be done some time after loading 70 | the web app, at the cost of delayed warnings in case of issues. 71 | 72 | To signal to the browser that a given web app is using Source Code 73 | Transparency, we could introduce a X.509 certificate extension, which 74 | would automatically be included in the Certificate Transparency logs, 75 | allowing security researchers to check that all certificates for the 76 | domain of the web app include this extension. Browser would refuse to 77 | load web apps without Source Code Transparency from a domain using a 78 | certificate with this extension. 79 | 80 | [1]: https://certificate.transparency.dev/ 81 | [2]: https://wpack-wg.github.io/bundled-responses/draft-ietf-wpack-bundled-responses.html 82 | --------------------------------------------------------------------------------