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

_______________________________________________
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Reply via email to