I wonder if this shouldn't question whether we should still allow all websites to run javascript by default.
There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of forms, etc), for the mere convenience of developers and for user hostile activities (tracking, messing with default behavior of the mouse, keyboard, clipboard, scrolling, etc).
This might be an opportunity for revisiting html and making it better. An ecommerce, a newspaper or a blog should have no reason to execute client side code to render. Once we have a good enough markup alternative, executing javascript can become an optional feature requiring user authorisation like accessing your camera or location.
[edit] also at the very least it should lead us to question the chain of trust of javascript. When I visit abc.com I should only execute javascript from abc.com or a subdomain. No script either hosted on a non abc.com domain or appearing in an iframe should be executed.
> I wonder if this shouldn't question whether we should still allow all websites to run javascript by default.
Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages, or not allow anyone to program a GUI unless they can justify the use of canvas space. Yet the web, arguably the most successful and free (as in both beer and freedom) and accessible software platform yet devised, is the only one on which people - erstwhile hackers - say that code should be a considered a privilege and not a right, or that it doesn't really belong on the web at all, despite javascript being on the web for ~20 years now.
What you're describing seems a lot like adding Windows UAC prompts to the web - no one would find that better, particularly given that anyone can simply turn javascript off in their browser already. This isn't even a javascript problem per se - you could erase javascript from the universe and make the web as plain as you like and Spectre and Meltdown would still exist.
> also at the very least it should lead us to question the chain of trust of javascript. When I visit abc.com I should only execute javascript from abc.com or a subdomain. No script either hosted on a non abc.com domain or appearing in an iframe should be executed.
That seems reasonable, and I would be willing to bet, possible to configure with modern tools. But pretending javascript is a second-class citizen on the web isn't the answer.
Random, unexpected, untrusted c/c++ written code doesn't execute on my machine every time I browse a website. The only c/c++ code is code I downloaded and installed or that my OS vendor trusted to include in the OS. It's quite different from javascript where the code is literally executing uninvited, often by 3rd or 4th or 5th parties of the website I visit.
No. Unless the application downloads and executes new code from third parties neither you nor application author can control every time you launch it, it's absolutely not comparable to most of the websites.
>Random, unexpected, untrusted c/c++ written code doesn't execute on my machine every time I browse a website.
It does every time you run a native application, for the same values of "random, unexpected and untrusted."
>It's quite different from javascript where the code is literally executing uninvited, often by 3rd or 4th or 5th parties of the website I visit.
Fine. Turn it off then. That's an option you don't really have in any other runtime, so take advantage of it. But just because you don't want javascript on the web doesn't mean it doesn't belong there when authors choose to include it as part of the content they serve.
Also, how exactly does one run "3rd, 4th or 5th party" javascript?
> Also, how exactly does one run "3rd, 4th or 5th party" javascript?
You load a page that includes 3rd party scripts/iframes that themselves load 4th party scripts that themselves load 5th party scripts, etc. You often notice that when you start blocking an ad in your browser and suddenly 10 others disappear at the same time.
>Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages,
That's not remotely a valid comparison. If I run a native app, I had to get that app somehow and install it. I know it can modify my computer (and probably have to give it persmission to do so). A web page can automatically load other pages, even in the background and do who knows what. For most of the existance of the web we've all had the mental model of "sandbox". We never had that for native apps.
Same thing could happen to apps. There was a Baidu app in China that secretly downloaded random videos just to eat up the users' data plan, so they will buy more data.
Again: we've always known that desktop apps were risky and could do anything to our computer (and for years, a lot of "free" windows software installed malware and viruses). We were always told that JavaScript is "sandboxed".
>> Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages
This is not in any way equivalent to browsing an informational site and having arbitrary code execute.
>> Yet the web ... is the only one on which people - erstwhile hackers - say that code should be a considered a privilege and not a right,
Hell no, code execution is a privilege in all situations! I don't just download scores of random executables and run them. Do you?
>> But pretending javascript is a second-class citizen on the web isn't the answer.
Making it one might be an improvement though. There's no way in hell I should be (to give a recent example) browsing a keyboard review and notice that my laptop now sounds like an aircraft about to take off because the site is running something unidentified as fast as it can (likely a coin miner).
>Plenty of harmful things are done with C and C++ but no one is saying we should deactivate native apps written in unsafe languages
Isn't that exactly what a lot of people have been saying ever since Rust started taking off? Every time there's a security vulnerability, someone suggests rewriting the program in Rust, if not some other safe program.
> ...say that code should be a considered a privilege and not a right, or that it doesn't really belong on the web at all, despite javascript being on the web for ~20 years now.
Same could be said about advertising and I'm infringing on all these innocent corporations' natural rights by running an adblocker.
For random code to run on my machine a few (IMHO reasonable) steps need to happen:
1) somehow entice me to click on a link
2) get past AdBlock
3) get past Privacy Badger
Seems like a privilege to me --and I'm not someone who cares all that much about the shenaganians the big webcorps get up to since I have no money so spend on their ad campaigns anyway.
Be aware that Adblock doesn’t block all JavaScript code. It blocks code after people have identified that code X run on website Y does something bad (tracking, ads, etc) and they decided to block it. This works well for visible ads because people see them. For tracking scripts, it still happens because most of them have obvious giveaways (come from a different domain, etc) but chances are that you still run random code because it is better hidden (comes from the same domain and does nothing obvious bad). Just because you use Adblock, malicious code will still be able to run. You are just less likely to notice it because it does nothing obvious so people don’t notice it as quickly and it will not get blocked. If you don’t want to run malicious code at all unless you trust this website, you should probably consider running NoScript.
I get that (and that’s why I use it too) but you made it sound like Adblock is blocking malicious code and thus you do not need to worry about Spectre and meltdown, which is defentily not true (though it does prevent some malicious code).
Javascript is a safe language, but it's powerful enough to exploit Spectre and Meltdown. Rust would be the same. It's not badly-written programs we need to worry about in this context, it's well-written malicious programs exploiting badly-designed hardware.
We don't need apps written in safe programming languages to fix this problem, we need secure browsers, OSes and hardware. (And yes, those bits should be written in safe languages.)
No, drop down menus, pre-validation of forms, adaptive rendering are the daily experience. Javascript is just the way we currently achieve that. I argue that a better html would avoid having to do this in javascript, as these are standard features that are needed everywhere.
And even if Intel comes up with a new design available for sale next month, we will still be stuck for many years with this flaw on all the devices out there. We also need to fix CPUs, but that’s a very long term solution.
> No, drop down menus, pre-validation of forms, adaptive rendering are the daily experience. Javascript is just the way we currently achieve that. I argue that a better html would avoid having to do this in javascript, as these are standard features that are needed everywhere.
You can certainly standardize a certain set of feature and put them in a non-turing-complete language like HTML, but standardizing all the legitimate use-cases of JavaScript is almost impossible, you talked about «drop-down menus, form validation or adaptive rendering», but what about interactive charting, modal view of full-size pictures, auto-completion of search tags ? These are just features I use on my personal blog ! And what about infinite-scrolling ? What about partial content-update ? There are thousands of legitimate use-case for JavaScript: it's not achievable to standardize every single one of them and put it in the HTML, and even if it were possible, do you imagine the nightmare it would be to learn HTML then ?
> but standardizing all the legitimate use-cases of JavaScript is almost impossible
I see the problem of not always having the newest technologies in browsers, but the pain of that problem vanishes the more we already have. One might say that securing JavaScript sandboxes is almost impossible, but still we are working on it. Let's work in the same spirit on advancing the open web :-)
I would be careful about that: It wouldn't suprise me if HTML with CSS (at least with all the new things like animations) is turing complete (it probably is).
‘You can encode Rule 110 in CSS3, so it's Turing-complete so long as you consider an appropriate accompanying HTML file and user interactions to be part of the “execution” of CSS.’
The notion that there are so many users of digital devices and services because we are running untrusted, unaccounted code that is automatically executed is plain wrong.
Hardware advanced in ways we didn't imagine in the past, and interfaces got better. Society learned about computers as they got cheaper and knowledge spread, while better software tools formed, accelerating the growth of the ecosystem. Nothing of that requires running delivered code upon visiting a random website.
HTML (or whatever standard we come up with) can be expanded to add the needed features, and enrich the web that way. JavaScript is used to lock us in, exactly what the web shouldn't do.
I don't think it is possible to have a spec thats always contains all the latest functionality. But that is also not necessary. The better the spec, the more problems we can solve completely.
I don't think we can always support the newest latest advancement to solve the latest obscure problem, but I think it's no problem to wait a period, even if it were months or years, for it to be standardized and supported in browser. The delay is not a nuisance nor a cost without any benefit. We maintain the open trustable web by doing that.
We have already a pretty good idea of what functionality we need. For example, we can look at what common JavaScript frameworks solve, and think about what we should standardized from that. Nobody did that so far, but we totally could, and should.
Waiting months and years for features that your site or app depends on is unacceptable.
> We have already a pretty good idea of what functionality we need. For example, we can look at what common JavaScript frameworks solve, and think about what we should standardized from that. Nobody did that so far, but we totally could, and should.
And once we have captured those concept, what then? Where do we mine the new concepts, designs, behaviours that will need to be introduced to the spec and implemented by each browser vendor individually?
> Waiting months and years for features that your site or app depends on is unacceptable.
If we do a thorough job now on extending the code-less web, I find it hard to think of sites that couldn't be realized then _and_ shouldn't be a native program in the first place.
I simply don't want a web that has place for "apps". For multiple reasons random websites shouldn't have the possibility to make the visitors system execute supplied code. Yes, some people don't agree with that, but they have usually motives for that which I cannot agree with like withholding code or control from users or tracking them. If you have a good reason why there should be apps in the browser, then I'd love to hear it, though.
The _example_ suggestion to look at existing framework is just a shortcut to not redo work, and to use already existing knowledge. If someone has an idea of what functionality should be supported we can discuss and standardize it. We had lots of technology completely independent of JavaScript. There is a lot of movement in the JavaScript ecosystem because a lot of ecosystem needs to be developed and there are big companies pushing for it, because they need it to monetize their users, but thats it. JavaScript isn't that important.
A taxidermist could argue that dead animals are better than living ones : they are indeed more convenient, less dangerous and cheaper to feed. But they aren't animal anymore, are they ?
Absolutely true. However, I'm not also not likely to find my stuffed cat slowed to a crawl and using all my electricity by mining Bitcoin because some 3rd party advertising network got compromised.
> However, I'm not also not likely to find my stuffed cat slowed to a crawl and using all my electricity by mining Bitcoin because some 3rd party advertising network got compromised.
I disable JS by default and only enable it if the website requires it (and it seems good enough). Since I've started doing it, quality of my internet experience have raised significantly. Almost all websites load much faster, are more responsive and less intrusive.
Indeed because auto-complete of recipient address from my contacts is useless, right ? Same could be said for retrieving new emails without reloading the page I guess …
Had JavaScript not existed, the web would be dead a long time ago already.
Both good points (although the second one could be handled through a meta refresh I guess). But I'd like to point out we were discussing where javascript is absolutely needed, not where it's convenient.
It's absolutely needed in the sense that «without it the web wouldn't exist», something else would be there, with the same security issues or worse.
Remember when the web allowed no video playback ? Flash was everywhere ! And Flash was non-standard and closed-source, maintained by a single company without competition. The current state of the web is a massive improvement compared to what it was 10 years ago, especially on the security side.
If you want to create a webmail (or any other web platform) that needs no JavaScript, go ahead. I doubt you'll be successful competing against people using JavaScript, but if the demand for a JavaScript-free web experience is big enough, you could live happily in that niche.
That will only happen if users will stop visiting websites with Javascript enabled. Which will only happen if an actual exploit becomes so widespread that it affects most of them financially.
This whole thread became a big "throw the baby out with the bathwater". Of course there is a long way to a secure web (if that is ever achievable), but disabling javascript is just a lazy alternative, creating a lot more nuisance than whatever damage is being done via javascript lately.
OTOH the "chain of trust" idea looks promising. And increases the responsibility on the visited website, because if it wants third party content to run javascript it'll have to host it itself.
> An ecommerce, a newspaper or a blog should have no reason to execute client side code to render.
The main reason is advertising, which is ultimately how this web content is paid for.
But there could be alternatives. We could create static img elements that could securely and discretely record whether they were viewed by a human (to prevent ad fraud). We could support simple animations and interactivity in a secure, resource-friendly way. And we could allow these to be disabled by user agents (e.g. epileptics).
Could newspapers exist without online advertising? Possibly, but only in specialised niches. Consumers have shown that they will always seek the cheapest, most accessible forms of information - even when provided by highly biased, unreliable sources.
The danger to killing online advertising is that it creates a world where the only people who can afford to publish are those with other interests - plutocrats, politicians, churches - and who will inevitably bankroll news only to further political ends.
> The ad-based web economy had produced the current publishing dystopia in the first place and prevents the development of a sane business model.
Ah, the 'better business model' argument! A curious specimen, men often speak its name, but rarely agree how it looks or its habitat. Is it a donation model? Wait, no, that doesn't work. A paywall? Ah, but you want content for free. Philanthropist support? Oh, you don't like the conflict of interest. Micropayments? I suppose you have some cunning way of mitigating the transaction costs, without computationally expensive solutions like bitcoin.
Here's my proposition: post a model that is known to work, known to scale, for general purpose content, and you will have a startup on your hands. Otherwise - I ask you to withdraw your comment.
But then why haven't "Spotify for Journalism" projects ever worked? How does a business go from $2 per paper to 0.2c per article? Why are so many artists so unhappy with their meagre Spotify royalties? I think this falls under my "proven to scale" condition.
[In reply to the below - as we have reached the thread limit: there will _always_ be free competition. The problem is: without advertising, the only players left will be those with deep pockets, and deep interests to protect - the state, churches, oligarchs and political groups]
Regarding royalties: My understanding from school is that radio royalties are paid out by samplings from radio playlists. If you song was in the sample then you got paid, otherwise, nope!
Don't the current streaming tech pay artists per literal play? If so, wouldn't that mean more money to the artists since all plays are counted?
My understanding is a bit outdated now perhaps, but would like to understand better if someone knows better :-)
>The danger to killing online advertising is that it creates a world where the only people who can afford to publish are those with other interests - plutocrats, politicians, churches - and who will inevitably bankroll news only to further political ends.
You say that as if server space is super expensive, but it isn't, certainly not compared to other forms of media. It's entirely possible to publish to the web without being an elite, people and businesses did it for years before advertising on the web became a thing.
>The people were hobbyists and the businesses had other projects.
Yes, but my point is that publishing to the web doesn't require advertising on the web. Nor does advertising on the web require javascript.
>Relying on "interested members of the public" for news is how people like Alex Jones get started.
It's how a lot of people got started. You seem to be implying some relationship between the presence of political extremism and the absence of advertising, but I don't see any evidence the two are correlated.
For me, making a better HTML/CSS and forcing it on everyone contradicts with the openness and accessibility of the web. It's 2018 and still there is no reasonable support of not-so-popular languages and locales in any browser or OS.
Consider a simple blog whose users are used to Jalali calendar. Blocking JS will only make the web more hard to use for them. It took many years for simple date utilities to land in HTML5 standard, and I bet things like decent global localization support will not be part of any standard in the next ten years.
User hostile activities should be prevented, but it should be done by developing more PrivacyBadger like tools, not limiting everyone to a small subset of available technology.
For many years (decades?) I got downvoted (here and on Reddit) for mentioning that I used NoScript. I even disabled JavaScript completely on Netscape Navigator.
It was in the context of sites that were unusable without JavaScript or security problems that only affected JavaScript in browsers.
Sure, Google and other advertising companies will never stop pushing technologies that are favourable for them, but we don't have to use them. We can always build open and free alternatives.
It doesn't matter. The playing field itself allows for shitty practices, and people/companies engaging in those shitty practices get more profit than those who refrain from it.
As long as shitty practices are supported by the browsers general population uses, nothing will really change.
Money doesn't win every fight. And not every fight is about money. For example, Mozilla is a non-profit organization. It's not about making everybody stop doing the wrong thing, it's about doing the right thing. Having one modern browser ditch JavaScript would already be a huge win, and people who care could use it. If Mozilla pushed the open web, it would already be much better, because all those open projects could use that. Not everybody uses Googles or Facebooks websites.
This fight is about money, because you're going against the entire industry, asking some players in it to self-sacrifice.
> Having one modern browser ditch JavaScript would already be a huge win, and people who care could use it.
For a short while, maybe, but as people making websites don't care about minority browsers, the amount of important websites you wouldn't be able to use through that browser would only grow, until the point that browser becomes useless.
People making money off user-hostile activities won't voluntarily stop making money off user-hostile activities.
It is not about making everybody stop doing user-hostile activites. That is my main point here, it is not about that.
There are people who have a website and don't want to monetize the visitors. I want a standardized web for them. Not everbody has to belong to that group for it to have merit.
I don't expect Microsoft or Google to stop making their online office stuff. Honestly, I couldn't care less what they are doing. I want solutions for those that serve the users, and nobody else.
Not everyone who uses javascript does so to monetize visitors. It's just a scripting language, it can be used for anything - and any user or publisher who doesn't want to use it already has the freedom not to.
I agree, and I think it is a pity that JavaScript is necessary for a lot of useful functionality which could be standardized to be made available without JavaScript, so people who care can browser the web and their sites in a browser that doesn't support JavaScript and still have a rich experience.
The advantage of not supporting programming languages in the browser from content that comes from servers is that one doesn't accidentally fall into that trap.
The functionality in my browser is important. The more the browser is scriptable, the better, but not from the website.
The code on my machine is reviewed, vetted, accounted, maintained and free. That is the big difference.
So you're advocating site developers add elements to their HTML which browser plugins then execute like a scripting language? I may not entirely understand what you're proposing.
If the end result is the same functionality as was being provided by javascript, then if you didn't trust the javascript, you can't trust the (now Turing complete) HTML. The same trust and verification issues exist, just moved to another level of abstraction.
>The code on my machine is reviewed, vetted, accounted, maintained and free. That is the big difference.
Is it? By whom? Not by you personally, not all of it. Blind trust is unavoidable at some point.
No, I'm not advocating for any Plugin, but for extending the standard (or creating a new one) with common acceptable functionality that we now use JavaScript for.
For example, we can do tables in HTML. We need no scripting nor plugin for that. For a contrary example, without JavaScript or plugin we can't serve our website as a torrent that is then loaded by the visitors from other visitors. But we can standardize that functionality and add it to the browser. The code for that functionality would then be developed by the browser developers as a part of the browser, and delivered with the browser. The website would just deliver the torrent file and the necessary meta information for it. That way no code or script from the website would need to be executed to have the desired functionality.
I don't blindly trust developers. I nearly exclusively use packages from my distribution. These programs are maintained and signed by people with recorded track record of their behaviour as a maintainer, and they are vetted for by others. They don't have an interest to track or montized me, and it is a limited set of people I need to trust. Also, I can hold back on updates, and refuse them, if I choose to do so. Programs that come from other sources are carefully looked at by me. there is a big difference to automatically downloaded and executed code from some website.
If that - just that - is your scope, then count me in.
I'd love to have a "standard web" that's entirely focused on providing visitors information in an efficient manner. And by efficient I mean not fighting attempts at providing better UIs or aggregating information through machine methods.
It’s too late until we are facing an unfixable hardware flaw that we will be stuck with for the next 10 years (until users fully retire the current CPU architecture).
This is false. Many websites are using Javascript to render the websites in full to give the users a better experience, such as rendered a SPA (Single-Page-Application) to prevent unneeded amounts of data loaded on each page request and only load exactly what you need, to give a faster, smoother and higher quality experience for the user.
Sure the mom down the street who wants to blog about the her kitchen recipes wont be needing it, but a lot of websites "do"
Websites are only bloated because of the MB of javascript to make them applications (images do not count as they need to be rendered either way and can be cached). Most of the websites I visit every day don’t display that much content. Once gzipped it's a tiny file.
Yeah and if you visit a site everyday, the JS is cached, too. After the initial download, it shouln't be an issue. This is besides the fact that it should not take MBs of JS to make complex applications.
The issue is what people are choosing to do with the tools, not the tools themselves.
HTML can be cached, too. Even if JavaScript permitted some clever way to safe network traffic like for example delivering the site as a torrent that is then downloaded from other visitors [0], then we can standardize that and implement it as a part of HTML or so.
Except that the current trend in webdev is to deploy small incremental changes multiple times per day and cache-bust the assets that change on each of those deploys. So the user is probably actually downloading the JS asset at least once per day Monday through Thursday (because no deploys on Fridays).
Well right now the problem is that the tool is broken. We have a long term non fixable issue (outside of replacing the hardware) with non trusted code running locally.
I would be absolutely astounded if there was any SPA which moved fewer bytes over the network than its plain HTML equivalent. HTML can be written compactly, and the repeated structures compress well; any increase in the size of the data over JSON will be more than made up for by not needing to load megabytes of javascript.
I cannot remember how many times I have visited SPA websites that break the browser url history.
Also, if a SPA fails to load a request for any reason, try reloading it. Ops you start over.
And I am not talking about some people that don't know what they are doing. At times I've had issues with Google's new developer console, gsuite admin, analytics, product hunt and others.
Nonsense. Bad tools are bad tools as evidenced by the fact that literally no one can use properly at scale.
Evangelists of bad technologies always like to trott out the nonsense about "a good carpenter never blames their tools"... well of course they don't: they buy the tools and always buy the appropriate ones. Further, if they did complain the customer would wonder why they bought bad tools in the first place.
A carpenter would never try to build a building with a "JavaScript" equivalent in the first place. They recognize the tool as garbage (perhaps after trying, and failing, to use it) and switch to something more appropriate.
If you took away JS from Facebook and Twitter, they'd literally be a better experience. They'd be forced to give up much of what makes them painful to use. At least Twitter had a character counter, that was a useful JS feature, but they broke even that.
And if you need a diagraming tool, maybe a website isn't the best solution.
Yeah lets all just use bash commands to browse the web, way more secure and sure you can get the information you need... oh wait wasn't that 20 years ago?
And it would still be possible if web standards didn't accrue so many capabilities that allowed people to treat them as a new medium of publishing color magazines (with invasive tracking as a cherry on the cake).
There are websites that genuinely need to run some code, like webmails, online trading platforms, online games, etc. But 99% of the websites have no good reason to do so. Javascript is used to make up for the shortcomings of html/css (different rendering for different screen sizes, lack of local validation of forms, etc), for the mere convenience of developers and for user hostile activities (tracking, messing with default behavior of the mouse, keyboard, clipboard, scrolling, etc).
This might be an opportunity for revisiting html and making it better. An ecommerce, a newspaper or a blog should have no reason to execute client side code to render. Once we have a good enough markup alternative, executing javascript can become an optional feature requiring user authorisation like accessing your camera or location.
[edit] also at the very least it should lead us to question the chain of trust of javascript. When I visit abc.com I should only execute javascript from abc.com or a subdomain. No script either hosted on a non abc.com domain or appearing in an iframe should be executed.