I understand the motivation; that doesn't make it acceptable for all sites, especially sites that care about minimizing their vulnerability surface. And since browsers don't currently have any security model for third-party scripts other than "full capabilities of the site that loads them", third-party scripts significantly increase the vulnerability surface of a site.
If browsers had a way to let third-party scripts run in a sandbox separate from the site, so that (for instance) filepicker.io can help with file uploads without having the full permissions of the logged-in users on every site that uses it, I'd have much less objection to third-party scripts.
Yeah, I normally do that when dealing with APIs that want to use third-party scripts. I'd just like to see more APIs that support running with local versions of the scripts, to avoid the need for a separate untrusted domain.
Comments
We currently try to push people towards pointing the script tag to us so that we can more rapidly iterate on the product.
I understand the motivation; that doesn't make it acceptable for all sites, especially sites that care about minimizing their vulnerability surface. And since browsers don't currently have any security model for third-party scripts other than "full capabilities of the site that loads them", third-party scripts significantly increase the vulnerability surface of a site.
If browsers had a way to let third-party scripts run in a sandbox separate from the site, so that (for instance) filepicker.io can help with file uploads without having the full permissions of the logged-in users on every site that uses it, I'd have much less objection to third-party scripts.
You can run their scripts in an iframe, e.g.:
http://www.daemonology.net/blog/2012-08-13-tarsnap-credit-ca...
Yeah, I normally do that when dealing with APIs that want to use third-party scripts. I'd just like to see more APIs that support running with local versions of the scripts, to avoid the need for a separate untrusted domain.