> Something is very wrong with how web developers think about threat models

Yes.

We have pretty much the same problem with the web, as we had with macro-viruses an office suites -- because we're solving the same problems in the same way, without learning from past mistakes. It might actually be worse, because if you tell people you don't run macros in untrusted office documents, most people will applaud you for being wise -- while if you say you use noscript people will dismiss you as a paranoid Luddite.

Runable code created by random people, from random sources, in one address space with access to all your user data -- what could go wrong?

>It might actually be worse, because if you tell people you don't run macros in untrusted office documents, most people will applaud you for being wise -- while if you say you use noscript people will dismiss you as a paranoid Luddite.

Maybe because macros are a BS add-on functionality that does nothing for 99.9% of Office users, whereas JS is a key component of the modern, dynamic, web.

>Runable code created by random people, from random sources, in one address space with access to all your user data -- what could go wrong?

Yeah, it's not like we have a security model for JS, sandboxed environments, and even each tab running as a separate process.

> Yeah, it's not like we have a security model for JS, sandboxed environments, and even each tab running as a separate process.

Sandboxed environments containing user data that web developers voluntarily compromise by then inserting 3rd-party controlled code.

Precisely. I'm glad my comment didn't pass over everyone's head.

A little disappointed that it's teacup50 that pours cold water on coldtea, and not the other way around. If only I had a biscuit-themed nick, to go with this little sub-thread.

I maintain the polyfill service. I'm very much aware of this issue, and we have tried to take steps to mitigate these concerns:

1. You can easily run the service yourself, just download it from the github repo

2. The hosted version is hosted by the FT and sponsored by Fastly, so you're not importing code from some random unknown entity. Those corporations practice good security awareness (in the FT's case it dramatically improved about 2 years ago), but if you don't believe us, see point 1.

Would you trust the FT and Fastly to have access to all local data all your desktop applications?

That's what you're building for the web. #1 doesn't absolve you of the culpability of promoting such a fundamentally flawed tool.

As our web applications get ever more complex, and as a side result less secure (on the premise that complex sites are harder to secure than simple ones, and more likely to use features like this which further complicate security), I think we're going to see more and more of a divide between the 'secure' web and modern rich applications.

One of the reasons that I'm such a big fan of Chrome's End-to-End project[0] is that it looks like it may provide a good way to bring real security to modern rich applications. In the current incantation it's not going to be suitable for use in every site out there, but it appears to be a really solid step in the right direction.

[0]: https://code.google.com/p/end-to-end/

This was actually a major security issue on some gov't websites point out a while back. Something about obama's blog's admin page using 3rd party google analytics...

I can understand something like cloudflare or other major vendor like google's cdn being more trustworthy, but even then there would need to be some sort of signature to verify the content (like they do on mega) before it could truely be trusted as not being compromised. That removes the speed benefits of a CDN since the preexisting file will need to be loaded and checked everytime.

You would be correct, if that were the case here. But Mozilla as a browser vendor is far from remote to the vendor/customer relationship. That is like writing a Linux application and being concerned because arbitrary code of the kernel is called.