That genie is too far gone to put back in the bottle, but that's the real problem with the online advertising 'ecosystem'. JavaScript enabled pop-up ads, it enables tracking, it enables coinminers and other malware.
Along with CSS, cookies, external images and fonts, redirect links, referrer headers, browser caches, and IP addresses that don't change over time and that can be linked to physical locations.
Javascript certainly doesn't have its hands clean, and there have been some frankly stupid decisions in how it was designed -- but stopping dedicated trackers is more complicated than you're making it seem. I don't need Javascript to put a tracking pixel in your email.
Aside from CSS and redirect links, all of these features are fairly straightforward. The consequences of disabling the Referer header, for example, are pretty small and easy to understand: you'll stop sending sites information about what links you used to get to them, but some very picky websites that check the header (e.g. image hosts that try to prevent hotlinking) might not work. This means browsers can provide options to let the user choose their preferred balance of privacy, functionality, performance, and "helping us improve your experience".
With JavaScript, on the other hand, it is very difficult for end-users to tell what a given website is doing. Are those hundred kilobytes of minified code a tracking/fingerprinting script, a crypto-miner, or a Hello World app in the UI framework du jour? It's hard for even an experienced developer to know for sure, and it's basically impossible for browsers. Your options are (1) allow everything, (2) use really crummy heuristics like "what domain is this file being served from", or (3) disable JavaScript and give up on using half the websites on the Internet.
JS has a few stupid design decisions, but the fundamental reason Javascript is hard to run safely is because it's a turing-complete language that exposes a lot of powerful features.
You can argue that the web doesn't need a turing-complete language that exposes a lot of powerful features. Can you argue that phones don't? Can you argue that personal computers don't need that?
All of the tracking that happens on the web right now also happens on mobile phones and desktops. Users have broadly shown that the "only download code you trust" security model doesn't work (see recent articles on both the Android and iOS app store for reference). Even something basic like adblocking on Android is kind of terrible -- the best app I know of is AFWall, and that's maybe half as powerful as something like UMatrix because it's relying on static firewall rules.
You get rid of powerful applications on the web, and users will go back to downloading apps like crazy just so they can order pizza from their phone. Since currently, all of those platforms are pretty terrible for privacy; it is very hard to argue that a world where people could only download native apps would be more private than the world we have now.
We could also keep the web and switch wholesale to a SaaS model for everything, which is broadly bad for consumers, and carries its own privacy risks (there are some computations like password generation that I don't want to be done on a 3rd-party computer). Switching over to using forms and remote computation for everything on the web would also greatly increase the prevalence of 3rd-party cookies, making them much harder to block.
The point I'm getting at is that I don't see a world where Javascript vanishes and privacy gets any better. In fact, it might even have the opposite effect if the deprecation of Javascript means people download more Android apps. Privacy is a really hard, complicated problem and there probably isn't any single solution.
If JavaScript vanished, it would accomplish one huge win for privacy: it would split the "reading content and submitting forms" part of the Web out from the "powerful applications" part.
It is cool that you can use JavaScript to build a collaborative 3D modeling program. It might even be better for privacy than a native app. But it is less cool that Facebook and every news site you read gets access to the exact same capabilities and attack surface as the 3D modeling program.
And personally, I think ordering pizza would land on the "content and forms" side of the divide.
A native app collaborative 3D program could be worse for privacy if it were closed source. If it were open source, then no way. For one thing, unlike a Javascripted one, it wouldn't update behind your back. Its code wouldn't be obfuscated, and wouldn't be dynamically pieced together from the four corners of the world.
On the other hand, I don't think the Open Source argument holds at all. This is pushing for something that just isn't going to happen. Now we need to not only get rid of Javascript, we also need to convince Facebook to Open Source its native app?
I run mostly Open Source native apps, but the only way I can do that is because web-apps take the place of many native apps I would otherwise need to install on my phone or computer.
> For one thing, unlike a Javascripted one, it wouldn't update behind your back.
Most people's phone apps are set to auto-update, and most PC apps have the ability to download and execute additional code on the fly. I like to think I run a pretty tight Linux system, but all of my programs have write permissions to their own personal install directories.
It sounds to me like your problem isn't so much Javascript as it is 3rd-party requests/assets and mutable web-pages. These are also interesting problems to talk about, but they're largely unrelated to Javascript. It would maybe be helpful to see the web move more towards a DAT/IPFS model where webpages could be versioned.
On the Javascript side of things, all of this boils down to the security idea the users should only run code that they trust. Users have broadly rejected that idea -- both on the web and on native platforms like phones. They want the ability to safely run untrusted and semi-trusted code.
We can argue over whether that's a reasonable thing for them to ask, but that's the position we're in. The web is trying to figure out how to let you run untrusted code.
JavaScript is the same. We'd have a cleaner, safer web without it. And only a small fraction of people would be happy with that.
If every browser had done the sane thing from day 1 (no third-party scripts and no cross-domain communication) we wouldn't be in the mess we're in. Sites could still use all the power that comes with scripting, ad networks just wouldn't be feasible.
Sometimes you need a car, but usually an ebike will be more than sufficient. Going on a road trip or doing a large Costco run? You probably want a car. Just picking up some eggs from the grocery store or making a visit to the library? An ebike is probably the best option, and is also likely faster (closer parking, can ride on roads, sidewalks, bike trails, etc).
I use a static site generator for my blog and personal web site, and there's absolutely no JavaScript involved. I use JavaScript with a web framework for webapps because otherwise we would need to build a desktop app, which would limit our reach to those platforms we have the resources to support.
I'm of the opinion that you should use the simplest technology that will get the job done. It's far easier to make a static site secure than a dynamic one. It's far easier for a customer to vet your server-rendered site than your pile of JavaScript (nothing runs locally, so they just vet form actions and HTTP headers).
You might be missing how expectations change after the introduction of a technology. I wouldn’t guess that people would be unhappy about not having cars before the car was even invented.
Isn’t this like saying atoms are to blame for nuclear warfare? Atoms enabled nuclear weapons?
It's certainly possible.
Originally I used NoScript (and Firefox 'View>Page Style>No Style'), now I just tend to use uMatrix, with appropriate media types disabled.
It makes for a faster, and easier to read web, where I still see the occasional ad, but once configured, usually not.
I'd guess that use with Javascript disabled seems to be accepted in part due to Safari on iOS supporing it - possibly it was the default (I can't remember).
If you're a total tech-novice, sure, but as a power user it's fine. I'm blocking ycombinator.com right now. I can still submit this. If something doesn't work, just click the icon and trust its domain. If pictures don't show, trust a CDN. Amazon, Paypal, 99% of sites work with an initial adjustment of trust settings.
Things like React are accelerating that curve. Even for sites that could function without it, they are throwing up hands with "welp, they can't disable it anyway because other sites...so let's not test that use case anymore."
I don't like it, but it is what it is. Technical people aren't going to drive the decision to work without JS. In the end, it's a cost decision, with the usual PHB[1] outcomes.
I found uMatrix easier to use and more configurable than NoScript.
I used noscript until Firefox changed to the new web API and noscript stopped working briefly. I switched to ublock origin in medium mode and haven't looked back. More compatible and practical nowadays.
Something like the unholy child of RSS Feeds / Podcasts / NNTP / Email / Pub-Sub / Gopher / Google Reader
A new language (or two complementary languages) separating content and presentation, limited, possibly not Turing-complete but expressive. Specifically less powerful than modern web browsers.
https://old.reddit.com/r/dredmorbius/comments/6bgowu/what_if...
99% of my web browsing shouldn’t need it. Every site I visit uses it, but almost all of them could be built just fine without it.
There are downsides to everything, but we cant dismiss that positives that came from it.
Yes, it’s great that the web is capable of stuff like Google Docs. But all those capabilities are actually liabilities when it’s a news site.
I think JavaScript should have to request access to use browser APIs, and you should be able to disable access to any of all of them. For example, I should be about to disable:
- network access (disables adding script tags, XMLHttpRequest, fetch) - 2d canvas access - 3d canvas access - WASM
And so on, just like mobile apps, but perhaps more granular. The app should also be able to put a note as to why it needs each specific feature.