[jsprogrammer]

That is all fine and it would cover many cases. However, someone other than you is still able to push code to your users without your acknowledgement (assuming you have trusted a third party key).

If you are already using a CDN, put your updated manifest (index.html) there as well.

[geofft]

> However, someone other than you is still able to push code to your users without your acknowledgement (assuming you have trusted a third party key).

Yes, I want that. I just want to control which third parties I trust. That's why it's called a "trusted third party", not just a "third party."

> If you are already using a CDN, put your updated manifest (index.html) there as well.

I'm not sure how this helps. Wouldn't this leave the index.html in the hands of the CDN, such that they are free to modify it?

[jsprogrammer]

>Yes, I want that. I just want to control which third parties I trust. That's why it's called a "trusted third party", not just a "third party."

I guess I just don't see why I would trust a library developer, but not a CDN. If you don't control the keys, you don't know who has them. (Although, I'd also argue that you don't even really know if you do control the keys)

>I'm not sure how this helps. Wouldn't this leave the index.html in the hands of the CDN, such that they are free to modify it?

I think you are right, as the system currently works index.html would not be safe. Currently you need a more dynamic system where the manifest is protected as well. A sidechannel (WebSockets, WebRTC) could be established to securely deliver updated manifests (which a lightweight client would translate into DOM operations).

[geofft]

> I guess I just don't see why I would trust a library developer, but not a CDN. If you don't control the keys, you don't know who has them. (Although, I'd also argue that you don't even really know if you do control the keys)

I'm not capable of running a CDN myself. So I have to trust someone. I might as well minimize the number of potential someones I trust; I claim that gives me a concrete benefit.

Since I'm not writing jQuery myself, I'm not minimizing it myself, and I'm certainly not minimizing it by hand, I do already have some trust in the jQuery project and their infrastructure. I don't currently have any trust in a CDN. If I'm going to move to using a CDN, I'd like a route with lets me put slightly more trust in the jQuery project (who I already trust to some extent) than in some completely new party.

Alternatively, I don't have to trust jQuery. I can trust someone else who's good at running secure build infrastructure, auditing libraries like jQuery or anything else, and minimizing and signing the result. (This is, loosely, analogous to the role that a Linux distribution plays.) Then I can choose to trust these people or not based solely on how good they are at security, choose my library authors based solely on how good they are at writing libraries, and choose my CDN based solely at how good they are at distributing content. I don't have to conflate the security trust with anyone other than the people I intentionally choose to put security trust in.

[jsprogrammer]

Reducing the number of someones you trust is good. I think the only difference in our approach is what others are trusted to do. In your model, some are trusted to send new code to users. In my model, new code must be acknowledged first, before users can consume it.

I don't think one approach is necessarily worse, but one can provide all of the essential functions of the other, without allowing unseen code to be pushed to users.