On Thu, 2013-08-22 at 08:51 -0700, T.C. Hollingsworth wrote: > 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. We only enable daemons by default when the defaults are reasonable or when a debconf prompt enables enough configuration for them to be started by default. Web assets are different, each domain or even each web app in a domain will need them at different paths and need different assets. > 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. I use a browser plugin that fixes this hole in web browser security. I agree that it doesn't offer much protection but I am reminded of ROP: https://en.wikipedia.org/wiki/Return-oriented_programming > Sometimes web apps never know that their needed CSS/JS dependencies are either. > Who knows what a Rails app is going to need? AFAIK, Rails apps declare their deps in the Gemfile. > 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. Sounds like a nice use-case, but with or without enabling the themes/fonts this would require hand-editing config files wouldn't it? > 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. Agreed both of these are bad. > 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. That would be cool. > 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. How would we know what to put in the script tag? There is no way for an automated system to know which URL is appropriate for that. > 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. I agree that Flash/images are horrible but I don't agree that the benefit was worth the cost. I would prefer for people to make interesting content rather than pretty text, the latter is something for users to choose rather than designers to impose. -- bye, pabs http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part