4 ms·

> compared to the kinds of technologies used for copy protection and telemetry in native applications Compared to the damage a logging truck can do to my car,

> compared to the kinds of technologies used for copy protection and telemetry in native applications 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.

Silhouette 10y ago
The threats to privacy posed by JS are severe and constantly evolving. 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.

Silhouette 10y ago

The threats to privacy posed by JS are severe and constantly evolving. 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.