[JoshTriplett]

I like the concept of filepicker.io: a standardized widget for providing files that handles local files, remote URLs, and services people use. However, every time I read the phrase "by inserting a few lines into their source code", I think 'yeah, and one of those is a script tag pointing at a third-party server'. And sure enough, looking at the documentation, I see exactly that.

I really wish web services would start providing instructions for self-hosting all scripts.

[ipince]

If you self-hosted the script then it wouldn't be able to communicate with their servers, I think (someone can correct me).

[tagx]

We currently try to push people towards pointing the script tag to us so that we can more rapidly iterate on the product.

[JoshTriplett]

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.

[theotherone]

You can run their scripts in an iframe, e.g.:

http://www.daemonology.net/blog/2012-08-13-tarsnap-credit-ca...

[JoshTriplett]

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.