Retro/fringe OS communities as an oppurtunity for more ethical Webcraft

Hi folks. As discussed briefly on Mastodon, I have lately been thinking about, and playing with a rough implementation of, a web server which enforces some of these ethical webcraft / web as document ideas. My plan is to offer free web hosting powered by this to interested people.
I am under no delusions that such a server would ever become widely used, this is mostly an experiment for the sake of curiosity and making a statement.

The current prototype returns a “403 Conscientious objection” error when asked to serve:

  • Any file larger than 1MiB in size (maybe even this is too big?)
  • Any file with the extension .js or .swf, or which file(1) identifies as being Javascript- or Flash-related regardless of extension
  • Any HTML file containing an <applet>, <canvas>, <embed>, <iframe> or <script> file
  • Any HTML file containing an<audio> or <video> tag with an autoplay attribute
  • Any HTML file which nests elements deeper than 10 levels

At the moment it serves static files only, but I plan to add CGI support with the restrictions that:

  • Cookies, Referers and client IPs will not be passed via the environment
  • Cookies and etags generated by the program will not be sent

At the moment it just does HTTP over port 80 but I plan for the released version to be HTTPS only.

I am really interested in getting ideas for additional “objections” of this kind, especially from people who know HTML5/CSS3 better than me, which is not hard.

trashHeap has suggested disallowing loading of remote resources like images, stylesheets, fonts, etc. as these are often hosted by surveillance companies like Google, which I think is a good idea.

Maybe there should be a limit on the number of external resources a HTML file needs the browser to load in order to render?

At the moment it does not inspect CSS files for objectionable content like it does HTML files. Are there things in CSS3 which are worth trying to block?

2 Likes

Instead of banning specific tags, maybe move to a whitelist model? I more than concede that is a pain in the ass at the beginning but the Core HTML 5 Markup specification is kind of fixed and the W3C keeps layering on modules which are mostly hostile. It seems like you just want to allow the core (with some exceptions) and the audio video module, and then ban most other (and future modules). This should keep you more future proof for the life of HTML5 I think. See this illustration for what im talking about: HTML5 - Wikipedia

CSS3 is known to be turring complete. So it is potentially toxic. I am not well versed enough to know what should be stripped out of it; or if its too costly to just limit things to CSS2 (or how to easily detect CSS versions of target code for that matter.)

1 Like

Why limit the filesize? Is the idea here to shift downloads to a better/more appropriate protocol such as ftp?

Seems like you run the risk hurting seemingly benign uses cases like photo galleries and such.

I did think about the whitelist option, and I guess I have to agree it is the right way to do things (although it wouldn’t be very robust to typos). The only reason I didn’t change to it immediately was because the obvious blacklist seemed short so it was quicker.

Re: limiting to CSS2, I’m trying (but maybe it’s futile) to avoid this coming across as an explicitly “retro”/nostalgic project, more of an “excising the evil” project, so I’m reluctant to outright reject all of CSS3. But without knowing more about the capabilities of CSS3 I can’t say for sure that this won’t be necessary.

Ah, figured out the quoting.

This was mostly a response to reading this delightful talk on website obesity. Limiting filesize is not a surefire solution to this kind of nonsense, of course, as a large number of small files still adds up.

That is very true, and I suppose I was taking it for granted that this server would not necessarily be applicable to all possible applications. Maybe that’s a bad idea.

Regarding CSS, I don’t have time to comment right now, but I think we can grab a core part of CSS3. I wanted to signal we can do neat stuff there. :slight_smile:

I’ll do a big ol’ reply this evening.

1 Like

Maybe exclude non html/css files form the filesize limit? Or just make them configurable indipedent of binary files and leave both up to the server admin? If your letting in the video and audio tags people will blow through 1mb pretty quick.

Also my thinking is, you want it flexible enough that users surprise you with their creations; but not so flexible enough it lets bad stuffs in.

Right you’d need to do your own parser capable of catching malformed html.

It may not be worth doing on second thought; as far as I can tell a lot of the higher modules/layers are somewhat useless without javascript OR are purely javascript.

It has pretty quickly become clear to me that I need to make a clear decision about exactly what I want this server to be, or else it will be very hard to make decisions about what kind of restrictions to put in place. Already the “specs” are quite contradictory. Allowing non-autoplaying audio and video whilst imposing a 1MiB filesize limit does not really make any sense.

I suppose my ideas so far have been guided by the intended first usage, which is to offer free hosting in a pubnix environment, specifically at circumlunar space. A big part of the identify of CS is that it is a kind of refuge/haven from the web’s bloat, surveillance and commercialisation, so it makes no sense to offer its inhabitants an unrestrained web server. A server like the one in question lets me offer that service without corrupting the soul of the place. I am also very excited about just handing a highly constrained web server to talented and dedicated people and seeing what they do with it. I want to be surprised by their creations, like trashHeap said. I heavily believe that constraints breed creativity. I want to see people push the limits of this kind of hackery. Finally, it would be nice if there was no risk of this project blowing through a cheap VPS’s small bandwidth allocation.

This is a narrow application and would demand (or rather, permit) much stricter limits than something which was supposed to support general usage, e.g. photo or video galleries.

One option of course is just to make all these “conscientious objections” user controllable, so admins can lock sites down as tightly or as loosely as possible. I don’t think I’m opposed to this idea, but I worry that if it is possible to relax the settings too far then the server looses some of its identity. That said, presumably nobody would run it “wide open”, as you would get a much more professional, reliable and performant wide open server using nginx or whatever.

Something else to keep in mind is that if somebody wants to run an “ethical photo gallery”, they don’t need a magic server for that. You could do it with nginx or apache. If you’re setting up your own site you can just not use HTML features you consider evil even if your server would let you. One could argue that a restricted server is a nice aid in keeping yourself honest and in making sure nothing sneaks in unnoticed - but I would argue that a better tool for that would be some kind of validator client (side note: something else I’ve dreamed of building is a site like those old-fashioned W3C web standard validation apps, but instead it gives you an “evilness score” or something). A locked down server like this really makes the most sense when an admin wants to offer webspace to a group of other people that they have no direct control over, e.g in a pubnix context. In light of this perhaps it doesn’t make sense to think too much about general applicability?

1 Like