"If you're seeing this message, that means JavaScript has been disabled on your browser.

Please enable JavaScript to make this website work."
techinasia.com/

I'm so sick of websites websites refusing to even display text and images if I don't agree to run their proprietary Javascript on my computer. Isn't it time that browsers started treating requests to run Javascript like requests to use the mic or camera, and asked the user before allowing them? Ideally with crowdsourced info about what the scripts are, and what they do? In other words, make something like #NoScript a standard part of browsers.

@strypey Be careful what you ask for: that would kill the peer web before it started. JavaScript on the client isn’t the enemy. Business logic on the server is the enemy.

@aral that's a fine distinction. As a developer, you're in a better position than I am to know. But you'll need to convince me. Because it seems to me that outsourcing processing work to the user's PC - via JS black boxes - is exactly how #SurveillanceCapitalism achieves massive scale, while claiming that #ThereIsNoAlternative to centralized server infrastructure. A myth they've propagated so effectively that even many developers have started believing it:
signal.org/blog/the-ecosystem-

@strypey

JavaScript isn't a black box, though. You can inspect all the code that's running in your browser.

Some JS is obfuscated, but it can be easily de-obfuscated. All browser-side JavaScript is effectively open source, even if it's not licensed as such.

If your concern is about privacy, it's not the JS running in your browser that should concern you. It's the data sent from the JavaScript to the server.

It would be reasonably simple to disable AJAX, thus preventing data to be sent to/received from the server, but allow all other JavaScript, allowing interactivity to still work.

@aral

@danjones fair points. But privacy is only a subset of a much larger concern, which is about *control*. Putting aside the argument we could have over the "black box" part of my post, the fact remains that:

> outsourcing processing work to the user's PC - via JS - is exactly how #SurveillanceCapitalism achieves massive scale, while claiming that #ThereIsNoAlternative to centralized server infrastructure.
@aral

@danjones There are many possible strategies for redecentralizing, and resolving the *many* problems with JS, some of which are described here:
gnu.org/philosophy/javascript-

I agree with @alcinnz that moving interactive functions back into native apps, leaving the web as a platform for static pages that don't require (or use) JS, is a strategy worth exploring.
@aral

@strypey @danjones @alcinnz Maybe the FSF should worry more about its logo appearing next to Google’s as they sponsor the same events than some ridiculous and ill-informed stance against a programming language that spreads FUD about potential alternatives. Remember that an AGPLv3 licensed app specifically built for drones to send hellfire missiles to little children would get the FSF seal of approval. Free Software is just a component of ethical tech but doesn’t care about ethics of use cases.

@aral I share your concerns about open source events being sponsored by Google, as do FSF, but they can't control this. As for approving of child-killing drone software, that's FUD worthy of Microsoft. FSF have often spoken out about the use of freely-licensed code to do much less anti-social things than that:
fsf.org/blogs/rms/ubuntu-spywa

Perhaps you could respond to the concerns laid out in 'The Javascript Trap' with some substance, rather than resorting to whattaboutism?
@danjones @alcinnz

@aral as for the claim that the FSF's criticisms of Javascript are a ...
> ridiculous and ill-informed stance against a programming language

I note that they're far from alone in seeing JS as a problem. Plenty of experienced engineers have serious problems with it too. A quick selection off the top of my head:
* soc.freedombone.net/objects/20
* hackernoon.com/the-javascript-
* onpon4.github.io/articles/kill
@danjones @alcinnz

Follow

@strypey @danjones @alcinnz Right, and as an experienced engineer (if 35 years of experience in programming counts for anything) who cares deeply about this problem, I’m telling you that a client-side-only JavaScript-based approach is essential to building a bridge from surveillance capitalism to a peerocracy. If you haven’t, please read what I wrote here, where I explain why JS in browser – if not linked to business logic on the server – is not the enemy: ar.al/2019/02/13/on-the-genera

@aral I finished reading this article today, after starting it yesterday, and reposting it so anyone following my account on the birdsite gets it, as well as those on the fediverse. It's a good overview. I didn't say JS is the enemy, I argued that it ought to be opt-in, so that:
a) users can protect themselves from the harms it is already known to do
b) web designers are incentivized to use it only when it's really needed, not use it to add trackers etc to what ought to be static pages

@aral if JS was opt-in, people would opt-in when that made sense in their use case, or use a native app when that made sense. Much less bad JS would be written because it can't be slid in under the door and run in someone's browser without their informed consent. It would be good for users, good for native apps, and good for JS.

@aral @strypey @danjones I thought we agreed the other day that these concerns are orthogonal. I'm not against your webapps, but auto-executing JS is a valid concern.

If you're afraid of lack of JS hurting you, I encourage you to write good <noscript> messages promoting the native apps.

P.S. As you should well know from Better there's plenty of Fear, Uncertainty, and Doubt to be had around what JS is doing.

P.P.S. I have read your blogpost.

Sign in to participate in the conversation
Aral’s Mastodon

This is my personal Mastodon.