Presenting Simple Web Policy

You may know that sometime ago I published a fairly uncomplicated manifesto regarding what I consider good for the websites on the internet. In that writing I encouraged people to use as little in-browser JavaScript as possible, instead moving as much responsibility as possible to CSS. At the same time, I stated that creators on the internet should do away with the obsession over how their works look and pay more attention to the content.

For a while now I’ve been using the NoScript addon to Firefox and I have become a happier person, mostly. As I default to blocking scripts, sites load faster without compromising usability. No, they don’t. I mean, they are, like, supposed to? But actually I have to spend more time figuring out what combination of allowed scripts makes sense. [edited 2017-08-15T10:19+0200]

What makes me sad about JavaScript is that we allow websites we visit on the internet to execute whatever code they fancy, and that code often serves to help identify or track users around the web, display advertisements, and it could just as well be used to mine cryptocurrencies.

I believe that NoScript is not enough. A major drawback of the addon is how it only allows me to block and unblock domains or – in more sophisticated cases, such as CloudFront – particular subdomains. What it means is that if I were to identify malicious or unwanted code hosted alongside scripts that the website’s usability suffers terribly without, I wouldn’t be able to lock out the bad code without ruining the whole experience.

I want precise control over what my computer executes. I would like to see the code beforehand and approve or reject it. And in the event that I rejected a something that another script on the site depends on – a library, such as jQuery – the browser should gracefully disable the depending script too.

Proposal

This is what Simple Web Policy is meant to be about. I would like to create a set of addons for popular web browsers requiring review of code before running it. I also seek to define a way for the developer to define relations between scripts and provide basic user-friendly hints for those who want to read the scripts.

Obviously, the mountain of JS has become so big that the task of reviewing all the code is a task far too tiring for one person. But judging from the example of me and my friends, noscripters tend to stick close[citation needed]. That’s why I consider it a good idea for users to be able to sign scripts (or they checksums/hashes, for sanity and storage) and share the signatures. Such system could also be extended with user-generated tags working in a similar manner to the developers’ hints I mentioned earlier. Then it could benefit from community sharing information.

The internet is constantly changing, and that can be seen in the code of our websites just as well. When I was just starting my adventure in web development (putting aside what I had done as a child in WYSIWYG applications), jQuery was all the hype – a library making DOM manipulation and many other things easier and cross-platform in the time when JavaScript wasn’t consistent between browsers. We still have websites that were created back then and haven’t been updated, and those websites’ jQuery-based scripts could now be replaced with CSS 3 transitions and animations and pure vanilla JS. That’s why I think the signature sharing system could be taken even a step further with users suggesting to their friends and followers what to replace the old code with in a compatible way to get an identical or at least a very similar result with smaller and/or more optimal JS.

Important to the proposal is the call for modularity. Instead of concatenating multiple scripts into one huge file, we should keep them apart to have better choices and, for example that will be shown later, to be able to drop libraries we don’t need along with the code that depends on them.

Drawbacks

Sadly, my proposal is not a silver bullet. There are many issues arising from the concept, and I’ll pinpoint the ones I saw as most important:

  • Whenever there is a system based on trusting other users, there is field for malicious misuse, be it by hackers or by the trusted one themself. It hasn’t stopped us from trusting JavaScript from random sites we’ve been looking at for some years now, but it’s still an issue. It could even get worse, assuming the system for replacing bad code with users’ submissions comes into action.
  • There is just too much JavaScript to review, and it can even be created dynamically on per-user basis. There is practically no way to enforce modularity and a form of the Unix way on what JS has become. So far I’ve been in denial regarding this issue. I’d like to try the whole thing out on my friends first and hope that it spreads to bigger players later on, but otherwise I have no way of convincing the really big companies such as Google or Facebook to go out of their ways to cater to the likes of an 18-year-old kid who talks like he’s seen the old internet.
  • There may be ethical issues regarding the concept of replacing somebody’s code. Recently, we’ve seen a DMCA request used to remove a website from ad blocking list, because allegedly/apparently blocking some code on your computer is a copyright infringement. And I suppose there are people other than ad providers who wouldn’t be happy seeing people replace their own code without asking.
  • Finally, this does not solve the problems of news industry and many others. Advertisements will still be hated, whether or not the publishers mark them up or not. Ad blockers will still exist, I guess. And also, I don’t want to kill ads, I think I’d like to keep some ads while shaking them all up a bit, but I don’t know for sure.

Initial syntax idea

I’ve been considering how to integrate my ideas into HTML and this is what I’ve come up with so far.

  • simpleweb:reason attribute on <script /> elements – for developer-provided comma-separated hints on what the script is. Suggested value ideas: library, cosmetic, advert, usability (for important scripts that the site doesn’t work much without?), utility (for not as critical, but still useful scripts).
  • simpleweb:description attribute on <script /> elements – for developer-provided human-readable explanation behind using the script.
  • simpleweb:dependencies attribute on <script /> elements – comma-separated list of CSS selectors that link to other scripts present in the document that are required to run this script.

Let’s consider this case.

<script id="jquery" src="jquery.min.js" simpleweb:reason="library"></script>
<script src="coolscriptfromtehinternet.js" simpleweb:reason="cosmetic" simpleweb:description="nice rounded squares, dunno" simpleweb:dependencies="#jquery"></script>

We know that jQuery here is a library that is needed by the other script, which is a cosmetic script that, perhaps, is something we’re not interested in. We should be able to create a set of rules that would disable all cosmetic scripts and all libraries orphaned by them.

TODO: expand example

Epilogue

I’d love to hear your feedback on this through whichever way you prefer out of ones listed on my website. Thank you for reading.