If it's not Javascript, any functionality that offers access to the hardware (via however many layers) to "apps" from the "cloud" can be exploited this way. Maybe we should disallow hardware access, how will YouTube play videos? Should we all install youtubeplayer.exe ?
It really doesn't. There are severe limits on what JS downloaded from some random site can do via a browser on your local device. A few tricks to detect some environment-based signals and invade privacy might be undesirable, but that intrusion is nothing compared to the kind of stunts native software has pulled over the years, and the major desktop and mobile operating systems are pathetically ineffective at sandboxing that software compared to what browsers do with JS, even taking into account the unwanted side effects of recently expanded capabilities that we're discussing here.
That's missing the point.
With respect to tracking a user, most of those restrictions don't matter. Your browser does download/execute untrusted, unsigned, arbitrary, ephemeral code that can do any kind of tracking it wants.
Yes, the browser executes JS code from untrusted sources, but only if you visit a page that loads scripts from those sources, and always (barring security bugs) within a sandbox that limits their capabilities.
I fail to see how this can possibly be any worse than installing software in other ways such as running a native executable you downloaded from somewhere, or following a "curl | sh" installation process as advocated by plenty of popular OSS tools, or allowing native software that you already installed to install arbitrary automatic updates that it fetches from remote sources.
The argument netsharc made was essentially that turning off JS would disable a lot of useful functionality for a lot of people, and that providing that functionality would still involve similar risks if it were done some other way. The reply from mikegerwitz argued that JS is different, but I still don't see how. The relevant comparison isn't against just turning JS off, it's against turning JS off and implementing the same functionality some other way, and compared to the sandboxed environment of JS, the most likely alternatives with today's technology would be even worse in terms of security and privacy.
Compared to the damage a logging truck can do to my car, a snow plow is very limited. I still don't want to be hit by a snow plow.
The threats to privacy posed by JS are severe and constantly evolving. Being able to profile based on hardware is effectively breaking the sandbox.
> (barring security bugs)
Which are far from uncommon. But you can't predicate a security discussion with the phrase "barring security bugs".
> I fail to see how this can possibly be any worse than installing software in other ways such as running a native executable you downloaded from somewhere, or following a "curl | sh" installation process as advocated by plenty of popular OSS tools, or allowing native software that you already installed to install arbitrary automatic updates that it fetches from remote sources.
Each of these requires explicit user authorization at some point (barring malicious operating systems). In the case of automatic updates, the initial install required user consent.
That isn't the case on the Web when you click on some random link I send you and automatically download and execute a program.
What exactly are the big threats you see here?
Yes, JS can be used to track whether the same computer is being used to visit different web sites. But there are other tracking techniques based on other web technologies that are also very accurate and require no cooperation from JS in the browser. The ultimate risk is the same in both cases: being tracked from one web site to another, and therefore potentially identified in real life if the other data held by those web sites in combination is sufficient to remove anonymity.
As I've said elsewhere in this discussion, I'd be the first to agree that this is undesirable, and that we should try to do something about it by limiting the access that is available by default and now being exploited for unintended purposes. I just don't see that the general risk is unique to JS or that JS is qualitatively worse in the danger than other web or general software technologies.
Each of these requires explicit user authorization at some point (barring malicious operating systems). In the case of automatic updates, the initial install required user consent.
Again, how is this any different to giving a user a link to a web site, which they then choose to follow? If you want to use some interactive functionality, how does it make the slightest bit of difference whether you're trusting JS code that runs directly or indirectly from a web site you voluntarily visit, scripts that run directly or indirectly via a script you curl|sh, or whatever is in some executable that you download and run? There is an inherent element of trust in all of these cases, and unscrupulous actors have betrayed that trust with nasty results in all of these cases. Again, I'm not saying the situation with JS is good, I'm just saying it's not significantly different to the situation with other current technologies that might be used to provide similar functionality in alternative ways.
Javascript is not the only way to provide interactivity. CSS, for example, provides some form validation methods in a declarative style. Sometimes you can do it server-side. Many types of interactivity were possible before the current JS mess.
If there is a type of common interactivity that is not supported without JS, we can always add it as a new browser features, just like we did with everything else in the browser.
> any functionality that offers access to the hardware (via however many layers) to "apps" from the "cloud" can be exploited this way
That's why you don't provide an runtime environment for "apps". Rendering data (a document, an image, video, etc.) does not need arbitrary software. It only needs a way to send a media file to the appropriate renderer. <img> and <video> tags should work fine.
> how will YouTube play videos?
Why is this even a question? They can serve an mp4 (or whatever) at some URL, and reference it in the <video> tag. Video playback doesn't require running arbitrary software, because we already have local video players.
The alternative is cleanly separating web browsing (a passive activity requiring no code execution) and using distributed apps.
I'm not at all against the idea of a common, cross-platform execution environment; I'm 100% against the idea of executing cross-platform code when all I want to do is read an article.
I disagree with the idea that computers == JavaScript, and furthermore with the idea that JavaScript helps me be more productive.
Excel makes me productive. React.js as a service does not.