Not a code signing?

[sergeych]

Could you illustrate your idea showing the benefits of your approach comparing to code signing? The current model is the code publisher signs the webapp by site's SSL certificate (well it could be fouled, but this is another question). So we trust the site publisher. To whom and to what we would trust in your model and how the merkles genuinity will be provided?

[twiss]

The goal is not to have any single trusted party. Rather, the goal is to provide transparency of the source code being shipped for a web app, and allow this to be checked by any auditor or third party; similar to what Certificate Transparency provides for certificates.
In other words, if any party (e.g. the publisher, or even the transparency log) behaves maliciously, it should be detectable.

[sergeych]

Okay it is interesting. Yet unclear how to use. And I would recommend also some mechanics to let us sign our code somehow. While we can't sign a library the way it will be verifiable in the bundle, we at least can sign the bundles. the thing is I don't like the idea that my code altered with somebody will be then attributed to me by some auditor. Nothing simpler than to steal a webapp, alter it in a malicious way and publish somewhere else or shadow the real resource. I'd love the log would detect it is an updated, not signed work. In this case such distributed control could be very useful.