On Thu, Aug 22, 2013 at 12:34 AM, Paul Wise <p...@debian.org> wrote:
> Whenever this idea has come up (including the current /javascript
> implementation) I have always thought it was a bad idea, especially
> for JavaScript. Exposing more than absolutely needed for each website
> at minimum is an information leakage.

So my reasoning regarding this is similar to Debian's reasoning regarding the
default enablement of daemons.  Debian starts all daemons by default because if
you don't want to run them, you shouldn't install them in the first place. We
enable HTTP access to web assets by default, because if you don't want to use
them, you shouldn't install them in the first place.

> With JS or CSS it might lead to
> security issues in the web apps on the same domain.

This came up in the Fedora discussion too.

There are no cross-origin restrictions on the loading of CSS or JavaScript in
web browser.  If someone can load arbitrary JavaScript or CSS from your server,
they can just as easily load it from a foreign server under their control or
a public CDN.  Even if there were, if someone had already got this level of
control over your application it would offer little in the way of protection,
since attackers could just `eval()` their evil code instead of loading it from
a server.

> Instead, the
> scripts used for setting up vhosts should reference the needed
> CSS/JS/etc dependencies using the web server or framework
> configuration. In addition, you can never know which URLs a specific
> web app, vhost or instance of a web app will use at runtime, so
> unilaterally taking over a generic path like /javascript, /assets,
> /_assets or /_sysassets is a recipe for annoying our users (social
> contract says no).

Sometimes web apps never know that their needed CSS/JS dependencies are either.
Who knows what a Rails app is going to need?

We'd also like to enable new use cases.  Someone might want to create a little
Debian cloud image for running a blog, as a nice free software alternative to
using hosted services.  They might want to include a bunch of themes and fonts
so users can customize it just as easily as they can with the hosted service,
without requiring a bunch of hand-editing configuration files. This makes such a
thing possible.

Right now the cool thing to do is copy-and-paste some HTML from a CDN like
Google's site.  Then all your requests are tracked, you're at the mercy of
a third-party provider, and if they go rouge they can really mess with your
site.  Or they just `wget` the file and it sits un-updated for eternity.

The only way we can compete with this is to make it dead simple for developers
to use. If the instructions for use involve a lot of hand-editing configuration
files and differing instructions for every web server under the sun, people are
just going to keep using CDNs or local copies of these files.

But, if we could have a simple page like [1] or [2], that says "just run
`apt-get install libjs-jquery` and add this script tag to your page", then
maybe, just maybe we can improve the web a little bit.

Remember, this is just a default, people who want to customize their setups
still will be able to, and they'll have better standards for doing so.

> I also think web fonts (and other recent browser attack-surface bloat)
> are an insane idea for security. They also lead to sites doing stupid
> things like putting icons into the PUA of web fonts. They are yet
> another reason why I'm wishing I could leave the web.

Previously this was done with either Flash or by using images (which is horrible
for accessibility and generally user-hostile).  Web fonts are a massive
improvement in this area.


[1] https://developers.google.com/speed/libraries/devguide
[2] https://www.google.com/fonts

Pkg-javascript-devel mailing list

Reply via email to