pabs at debian.org
Mon Sep 2 12:10:37 UTC 2013
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
> 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:
> 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  or , 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Pkg-fonts-devel