Follow

I'm writing a webserver. Key features: inspects all files with `file(1)` before serving them and refuses to serve anything identified as Javascript or Flash. Refuses to serve any file larger than 1MiB. Inspects HTML files before serving and removes all <script>, <embed> and <iframe> tags. Refuses to serve HTML if div and/or span tags are nested more than 5 tags deep. Suggestions for additional "principles of non-violence" are welcome.

· Claverack · 3 · 3 · 6

@reinboar I'm not sure yet whether I will make this serve static files only, or also support CGI and maybe FastCGI. If it's static only, cookies aren't really a threat anyway (as far as I understand, happy to be corrected). If it supports dynamic content, absolutely, the server will not pass cookies or referers to the applications, and it will not permit the applications to send cookies or eTags (which can be used as a sneaky cookie substitute).

@solderpunk
I can't remember if there's a way for the server to read a browser's cookies or not. I know they get set initially by the server via headers, but past that Idk.

@reinboar The browser automatically sends them along in the headers with any request to the server, based on the domain. The server has no way to request them directly. But a static site has no way to set them in the first place, or to interpret any that somehow got sent along, so until CGI arrives they're a non-threat.

@solderpunk Late reply, but wouldn't a static site be able to set cookies in response to a POST request for a form of some sort or are we ruling that out as static?

@reinboar My definition of "static website" is basically "a bunch of files served from the disk", so there's no way for a static website to process a POST request. That fundamentally requires CGI, FastCGI, or some newfangled work-alike.

@pkotrcka Probably the list will grow! None of this HTML5 local storage nonsense, for example. Not sure yet if it will be easier to have a list of evil things to ban or to just whitelist the harmless ones.

@solderpunk can you scrub embedded images or media if not loaded locally?

@solderpunk I.E. Eliminate tracking people by embedding images from other servers.

@trashHeap That's a good idea, thanks. I wonder if I should impose a blanket local-only policy, so it would also cover e.g. fonts, stylesheets, etc. This is good practice not just for privacy but for reliability. Your website shouldn't break because a third party's server went down.

@solderpunk Id recommend doing it for all external resources. Google tracking people via externally loading their fonts is allready a thing I think.

@trashHeap @maiki Oh, yes! I've had that open in a tab for weeks now, just have never gotten around to reading it. Maiki and I once spoke about this kind of thing, briefly, maybe a year ago. Keen to say the latest thinking along these lines...

@solderpunk @trashHeap You are invited to comment there! I find it a little easier to have these long form discussions there, rather than 500 characters at a time. ^_^

@maiki @trashHeap What exactly is talkgroup.xyz? Something you run yourself?

@trashHeap @solderpunk I've been trying to answer that question for years! The "what exactly is it" part; yeah, I run it. ^_^

It is like forums, except I use it as a public web note api, and it acts a lot like a mailing list. And everything is CC0, except I am literally the laziest sysop on the planet, and haven't written this up yet (talkgroup.xyz/t/meta-quest-cre). T_T

@trashHeap @solderpunk I use it for notes, blogging, pinging my peeps, roleplaying, and a magic quest board. So, like, #YMMV. ^_^

@maiki @trashHeap Okay, thanks. That's enough for me to feel safe creating an account. :)

@trashHeap @solderpunk It is my great shame that I haven't made it more inviting... wow, I literally just remembered I've been displaced until recently. I guess I'll give myself a pass...

@maiki @trashHeap I think you should. :) I've signed up and will comment on the "ethical webcraft" thread tomorrow.

For what it's worth, I wouldn't describe it as "uninviting" as such, but the extensive formalities (terms of service, privacy policy), and especially their use of "we", confused me as to the nature of the place and were hard to reconcile with my assumption, based on you being the latest commenter on most threads, that this was a personal site

@trashHeap @solderpunk haha, I didn't even realize those pages were published! That's default copy from a fresh install. Yep, gotta fix that. ^_^

@trashHeap @solderpunk The funny part is talkgroup.xyz has been online for a little over three years I think. I suppose keeping the default terms in place I've kept it civil all these years. ^_^

@solderpunk I have to say ive been so client focused on these problems, its interesting to contemplate server side solutions.

I hope you do end up supporting server side CGI. I'd like to start writing scheme for a few applications people usually use javascript for; and it would be cool to deploy it using your server.

@trashHeap I've been reading up on CGI and it seems like it would not take too much effort, so maybe I'll do it (with the option to disable it, of course). I will eventually spin up a cheap VPS that runs this server, and give anybody with shell access at the Zaibatsu or Republic the option to host a site there so we can shake out bugs and see how well the idea really works in practice. You'd be welcome to experiment with scheme CGI there!

@solderpunk I had a feeling this would loop back to a Zaibatsu service; id not only use it there but I could see it replacing bozohttpd as my preferred lightweight webserver.

@trashHeap I never used bozohttpd, but I remember being disappointed when NetBSD started bundling it as part of the base system, because I loved NetBSD for its clean and minimal base system. But I'm sure it's a great server, and in general I really love and have a wonderful nostalgic fondness for the old simple webservers, especially the ones from ACME labs.

Sign in to participate in the conversation
tilde.zone

masto instance for the tildeverse