Jump to content

JavaScript: Difference between revisions

From Consumer Rights Wiki
Rudxain (talk | contribs)
forgot to finish a sentence
Rudxain (talk | contribs)
mention security risks
Line 15: Line 15:
*[[Personalized Ads|'''Targeted ads''']]: JS makes it harder for [[Ad block|ad-blockers]] to block ads, since it can be used to make overly-dynamic ads. The data collected by malicious JS makes it trivial to serve personalized ads, even across unrelated sites.
*[[Personalized Ads|'''Targeted ads''']]: JS makes it harder for [[Ad block|ad-blockers]] to block ads, since it can be used to make overly-dynamic ads. The data collected by malicious JS makes it trivial to serve personalized ads, even across unrelated sites.
*'''Market control''': JS (alongside [[wikipedia:WebAssembly|Wasm]]) are built into almost every web-browser and UA, including "light-weight" ones (such as [[wikipedia:W3m|w3m]]). Incentivizing companies to use it for everything, since "there's no need to worry about compatibility or portability". Some people say that JS shouldn't even be a Web Standard,<ref>https://daringfireball.net/linked/2017/06/22/navistone-form-data</ref> implying that it should be an [[wikipedia:Browser_extension|extension]] or [[wikipedia:Plug-in_(computing)|plug-in]] (such as Java Applets and [[Adobe]] Flash) the user willingly installs; this would reduce the incentive to use JS, as there's no guarantee the user has it.
*'''Market control''': JS (alongside [[wikipedia:WebAssembly|Wasm]]) are built into almost every web-browser and UA, including "light-weight" ones (such as [[wikipedia:W3m|w3m]]). Incentivizing companies to use it for everything, since "there's no need to worry about compatibility or portability". Some people say that JS shouldn't even be a Web Standard,<ref>https://daringfireball.net/linked/2017/06/22/navistone-form-data</ref> implying that it should be an [[wikipedia:Browser_extension|extension]] or [[wikipedia:Plug-in_(computing)|plug-in]] (such as Java Applets and [[Adobe]] Flash) the user willingly installs; this would reduce the incentive to use JS, as there's no guarantee the user has it.
*'''Security nightmare''': JS is well-known for being a poorly-designed tool.<ref>https://github.com/denysdovhan/wtfjs</ref><ref>https://github.com/brianleroux/wtfjs</ref><ref>https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_because</ref><ref>https://github.com/Rudxain/ideas/blob/aa9a80252a4b7c9c51f32eda5c716e96220ed96e/software/evar/with_bf.js</ref> This leads to programmers and even experienced software-devs to accidentally add vulnerabilities to their code. That, and the fact that JS is [[wikipedia:Turing_completeness|Turing-complete]] (both [https://gavinhoward.com/2024/03/what-computers-cannot-do-the-consequences-of-turing-completeness/#mathematical-vs-practical in practice and in theory]) is a recipe for disaster, as it makes [[wikipedia:Debugging|debugging]] and [[wikipedia:Reverse_engineering|reverse-engineering]] impractical in many cases. The most common vulnerabilities found are:
**[[wikipedia:Cross-site_scripting|XSS]], which [[wikipedia:NoScript|NoScript]] tries to mitigate
**[[wikipedia:Arbitrary_code_execution|Arbitrary code execution]] and [[wikipedia:Code_injection|code injection]]. Typically caused by <code>[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval eval]</code> (part of the ECMAScript spec), but there are Web APIs (such as <code>[https://developer.mozilla.org/en-US/docs/Web/API/Window/setTimeout setTimeout]</code> and <code>[https://developer.mozilla.org/en-US/docs/Web/API/Window/setInterval setInterval]</code>) that can be misused as well.
**Remote code execution. This is used by hackers and crackers to build [[wikipedia:Botnet|bot-nets]] for [[wikipedia:Ddos#Distributed_DoS|DDoS]] or [[wikipedia:Cryptocurrency|crypto]]-mining.
**Sandbox escape.


==Incidents==
==Incidents==

Revision as of 07:23, 18 March 2026

JavaScript
Basic Information
Release Year 1995
Product Type Software
In Production Yes
Official Website https://tc39.es/ecma262/multipage/

JavaScript (JS) is a programming language and core technology of the Web, alongside HTML and CSS. It was created by Brendan Eich in 1995.[1] As of 2025, the overwhelming majority of websites (98.9%) uses JS for client-side webpage behavior.[2] It's even used on the server-side (see Node.js).

Consumer-impact summary

  • Forced requirement: Many webpages (and even entire websites), force the user to keep JS enabled. In 2026, considering the advancements in HTML and CSS technology, there is no technical reason why any website (other than real-time simulations and low-latency gaming) would ever need JS. The only valid justification are legacy code-bases, since those are impractical to migrate to no-JS solutions. That is, newer web-sites have no reason to use JS, let alone mandate it.
  • Excessive tracking: JS is much more capable than HTML and CSS combined to track user behavior, because of its first-class access to user-agent (UA) APIs. JS can communicate with almost any server (only limited by CORS) at any time (limited by connection availability), using a plethora of protocols. JS can get hardware information and compute a fingerprint of the device, user, or both.
  • Targeted ads: JS makes it harder for ad-blockers to block ads, since it can be used to make overly-dynamic ads. The data collected by malicious JS makes it trivial to serve personalized ads, even across unrelated sites.
  • Market control: JS (alongside Wasm) are built into almost every web-browser and UA, including "light-weight" ones (such as w3m). Incentivizing companies to use it for everything, since "there's no need to worry about compatibility or portability". Some people say that JS shouldn't even be a Web Standard,[3] implying that it should be an extension or plug-in (such as Java Applets and Adobe Flash) the user willingly installs; this would reduce the incentive to use JS, as there's no guarantee the user has it.
  • Security nightmare: JS is well-known for being a poorly-designed tool.[4][5][6][7] This leads to programmers and even experienced software-devs to accidentally add vulnerabilities to their code. That, and the fact that JS is Turing-complete (both in practice and in theory) is a recipe for disaster, as it makes debugging and reverse-engineering impractical in many cases. The most common vulnerabilities found are:

Incidents

Add one-paragraph summaries of incidents below in sub-sections, which link to each incident's main article while linking to the main article and including a short summary. It is acceptable to create an incident summary before the main page for an incident has been created. To link to the page use the "Hatnote" or "Main" templates.

If the company has numerous incidents then format them in a table (see Amazon for an example).


Add your text below this box. Once this section is complete, delete this box by clicking on it and pressing backspace.


This is a list of all consumer-protection incidents related to this product. Any incidents not mentioned here can be found in the JavaScript category.

Example incident one (date)

Short summary of the incident (could be the same as the summary preceding the article).

See also

References

  1. https://exploringjs.com/es5/ch04.html
  2. "Usage Statistics of JavaScript as Client-side Programming Language on Websites". W3Techs. Retrieved 2024-02-27.
  3. https://daringfireball.net/linked/2017/06/22/navistone-form-data
  4. https://github.com/denysdovhan/wtfjs
  5. https://github.com/brianleroux/wtfjs
  6. https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_because
  7. https://github.com/Rudxain/ideas/blob/aa9a80252a4b7c9c51f32eda5c716e96220ed96e/software/evar/with_bf.js