Web Non-Standards and Other 2020s Headaches

Sunday 2 July 2023
Bob Leggitt
Big Tech's grip on developer resources is so unthinkably tight that simply, new devs do not know how to build websites and apps that won't violate their users' privacy. But yeah, let's all wave our arms and spread the "Privacy is not Dead" meme.
Desktop publishing app after interface revision
The forthcoming content-packager app after reorganisation of the interface. In general aura it feels a bit like posting on an old-school forum, except the live preview is ever-present, and it responds instantly to changes in the Markdown. This view shows an HTML5 image block, which has SEO-viable markup and is inserted via an upload-style dialogue. Alternatively, images can be inserted via a shortcode or standard Markdown.

To keep you up to date on my forthcoming content-packager, whilst simultaneously bemoaning the state of the technological world, I'm stopping off for a quick rant on Web Standards. Far from promoting universal compatibility, as any Standards regime should, Web Standards - or Web Non-Standards, to dub them a little more appropriately - have succeeded only in making exclusion and digital dictatorship the default.

For anyone who doesn't regularly read this blog, I'm in the latter throes of building a radical desktop publishing app, which sits in the gap between a website-builder and a post-Microsoft word-processor, and is designed to take a hardline stance against surveillance giants. I've learned many things along the way, but perhaps more than anything else, I've learned that trying to maintain both competitiveness and compatibility in a piece of web-tech is near impossible. By order of ye interwebz' controlling forces.

COMPATIBILITY: THE KEY TO DIGITAL FREEDOM

Compatibility is incredibly important in re-establishing freedom in the digital world. But try increasing the compatibility of a technological product and you'll find everything stacked against you. You quickly conclude that the Web Standards regime has nothing at all to do with unification, order or inclusivity, and everything to do with making the world evermore reliant on Surveillance Valley corporations.

It is ONLY worth the "privacy tool" gang introducing something if it has access to a tidal wave of data. That's why there are half a million VPNs and no desktop publishing systems.

BLIND 'EM WITH SCIENCE

Everyone in the land of tech development is using different frameworks, libraries and dependencies - all of those technologies co-opted to a greater or lesser extent by Big Tech, and many of them created by Big Tech.

And even within the core programming languages, the goalposts are constantly moving. New developers are being taught all sorts of ridiculously non-standard processes at the whims of the Big Tech funders who subsidise the training courses.

Evidently, the goal is to make the Web so spectacularly volatile and technologically-fragmented, that only unthinkably sophisticated technology controlled by multi-$billion corporations can possibly hope to make sense of it. Result: truly independent browsers cannot meaningfully access the Web, and Surveillance Valley has an unshakeable walled garden that masquerades as a free and open resource.

There is honestly no longer anything free or open about the World Wide Web, and the root of that problem lies in Surveillance Valley's grip on developer resources.

JavaScript has become the most important programming language of our time. But if you're seeking a JavaScript course that teaches you anything other than how to mine data in a brain-fryingly mathematical fashion, forget it.

LEARNING JAVASCRIPT IN 103 LESSONS…

Sign up to the average JavaScript course and it's like… Lesson One: "Hello World"; Lessons 2 to 100: Push Data in and out of increasingly large and deeply-nested key:value pair objects whilst embedding as much Surveillance Valley bullshit into your page as a broadband connection will feasible take.

Lesson 101: "Facebook are actually nice guys and they made this wonderfully over-convoluted thing called ReactJS, which no one actually needs but everyone uses because developer training courses shill the living crap out of the thing"; Lesson 102: "An introduction to Redux, because why do anything but mine data?"; Lesson 103: "Give your email address to Microsoft and put your developer profile online… OR YOU FAIL THE COURSE!!! Obviously.".

There are thousands of things you can do with JavaScript. Big Tech's educational cronies can think of one.

So you're left trawling the search engines for isolated pieces of the jigsaw that might do something other than key-log and mouseflow the shit out of the general public. But even the trawling ground has been monopolised by the usual suspects.

Use a search engine to seek out programming info, and there's less than a 1% chance of you getting your answer from a site that doesn't have $millions in corporate funding behind it. No one builds independently anymore, because there's simply no access to independent learning options. They're invisible.

But to stumble, hoarse from ranting, back onto track… When I started building the offline publisher I've been working on since late February, I knew it would be difficult to insulate it from the grand stalkathon without making it overly difficult to use. I was, however, less focused on psychological factors in the app's design, which have become more prevalent of late.

Content packager Admin screen
The content-packager's posts can be accessed via the Admin screen. The whole project can be output to a consumer-readable Distribution in two clicks.

SUGAR-COATING ALWAYS WINS

I designed the app to produce attractive pages, but they were only compatible with fairly modern browsers, because they were using modern CSS processes for their styling. Finding this unacceptable, I came up with the idea of offering a wide-compatibility output which would support almost any browser. Reverting back to the old table structure protocols of the 1990s was no problem at all, but these super-compatible "Indie" pages looked a lot plainer because the CSS boundaries were much more limited.

The plan was to offer both output options, so people could choose whether to make prettier pages with limited browser compatibility, or plainer pages with wide browser compatibility. But it became pretty obvious when comparing the two output options that nearly everyone using the app would make the prettier pages and sacrifice the wide compatibility. I was doing that! Who the heck wants to make plain-looking pages?

And this would make the app a servant to Big Tech. The software would be doing exactly what Big Tech itself does. Using people's aesthetic preferences to push them towards systems of corporate control (in this case Silicon Valley's most subjugative browsers), and away from freedom.

So the plainer pages needed to look prettier in order to drive support for independent browsers, whilst the compatibility of the prettier pages was extended further back. I also needed to improve the compatibility of the app itself. When I last wrote about it here, the app itself required a post-2020 browser to run, which meant it couldn't run in Icecat (whose most recent version hails from 2019), which really pissed me off.

I've since re-coded to support Icecat, and I've managed to extend the app's browser compatibility back to the mid twenty tens. That's Firefox thirty-odd, Chromium 49, and the browsers based on those core models. It will now run in Firefox, Chromium, Edge, Opera, Brave, Vivaldi, Slimjet, Waterfox, Light, Icecat, Pale Moon, Midori and more. Broadening this base and supporting older versions has been an important action, I feel. If I stripped out Flexbox, I could probably get it back to 2010-ish and support Windows XP, but let's get the thing finished and publish it before thinking about that.

What seems so contradictory is that in an environment supposedly governed by a Web Standards arbiter, it should be so difficult and time-consuming to support even a modest rewind of the web-tech timeline.

Use a search engine to seek out programming info, and there's less than a 1% chance of you getting your answer from a site that doesn't have $millions in corporate funding behind it.

And the app also needed a number of other concessions to mainstream expectations.

For example, inserting a link in Markdown is too much hassle for most people. So I had to build in a conventional process whereby you can just select the anchor text and paste in the link via a dialogue box. This is much better. I'm familiar with Markdown, but straight away things felt hugely easier for me.

I'd addressed similar issues with image insertion by creating an image shortcode. You'd just type the shortcode and then the image name, and the image would magically appear in the post's live preview pane. This was quicker than using standard Markdown, but there were problems. Images with long filenames would be a pain to type in. And without further complicating the shortcode process it was impossible to generate SEO-viable HTML. Indeed, even Markdown doesn't create a properly SEO-viable image block.

And you could say: "Sod SEO!! Stop pandering to Big Tech". But if you don't give people the means to produce competitive output, they won't use the app. And Big Tech wins anyway.

So I ended up building an image insertion dialogue, which generates a properly formatted HTML block, with alt text, dimension declarations, lazy loading to keep page loads fast, etc.

Then I added a similar insertion system for the Cyberquote "embeds"… By which time there were buttons strewn absolutely everywhere and the interface needed reorganising with a dropdown menu and a compact toolbar.

Then a lot of the output code had to be adjusted to take account of all the changes, and since there are four basic forms of output, that hasn't exactly been a trivial matter.

I'm still not happy that the wide-compatibility pages are aesthetically competitive, and I'm not going to release the app until everything is the best it can be. But I'm now tremendously excited by the prospect of introducing something so radically different from anything else I'm aware of, and I'm totally committed to getting it finished.

The app is not as easy to use as I'd like it to be, and due to the way browsers work in relation to local files, it never will be. But it is acceptably intuitive, and every time I use it, in a firewalled browser, it feels like I'm taking an almost militant stance against the surveillance lords, and winning. If everyone who uses the app gets that same feeling, it will have served its purpose.

Since I've gone down the road of making my own app, two points have been suitably underlined as regards the motley crew of "privacy tool" bullshitters, about whom I've regularly griped on this blog.

The "privacy tool" business is about data. Not privacy.

The first is just how little any of them ever do in terms of conceptual innovation. In concept, their browsers are the same as Big Tech's browsers. Their search engines are the same as Big Tech's search engines. Their email services are the same service-worker bloated hellscapes as Big Tech's email services. Despite their money and resources, all these companies do is spin existing ideas, ride on other people's open source shit, and drape it all in the P-word. That's the entire, sorry formula, and it's achieved nothing. If it had achieved anything I wouldn't be having to design an app that lets writers FIREWALL their browsers.

And the second thing is how completely opposed any of these "privacy" brands are to LETTING THE USER OUT OF THEIR SIGHT. Everything they ever ship is designed to sit across an arterial data flow, over a network. Could it really be true that among all of the brilliant minds in "ethical" technology, it has not occurred to a single one that zero-network technology is the only true way to give users privacy?

Of course it has. But the data they so relentlessly pretend they don't care about, is their primary revenue source. So instead of investing in zero-network solutions, they're investing in propaganda that blasts us with their chronically false "pRiVaCy Is NoT dEaD" meme.

Indeed, in striding into the world of web development, one sees that it could not be more clear how stone solid dead online privacy is. Via their co-opted educational partners, the cybertech powers are teaching new generations of developers methods that necessarily rely on Big Tech, and necessarily embed spyware. Purely and simply, new devs do not know how to build websites and apps that won't violate their users' privacy. But yeah, let's all wave our arms and spread the "pRiVaCy Is NoT dEaD" meme.

Far from shifting things away from network dependency, the "privacy tool" bullshitters are racing towards it. They can't think of sneaky new ways to divert our activity through their servers quickly enough. Thats why they all introduce the same tired products over and over again.

It is ONLY worth them introducing something if it has access to a tidal wave of data, and there's only a very limited range of product designs that max out on data exposure. That's why there are half a million VPNs and no desktop publishing systems. VPN = potentially unlimited £££££££ from intelligence agencies, a fat cut from the research biz, and a closet deal with [insert surveillance giant here]. Desktop publishing system = actual privacy. The "privacy tool" business is about data. Not privacy. If the ratio of VPNs to desktop publishing systems doesn't convince you of that, nothing will.

I want to change the ratio of desktop publishing systems to VPNs. Albeit only by one.

So I'll now get back to work on doing exactly that…