GNU Emacs: new critical remote shell injection vulnerability
-
WTH are you even talking about? what are you making about me? turn this around and see how much opposition you are (not) seeing to the nonsense you're pushing that untrusted JavaScript (download from third parties) can be executed safely, but iFrames (that carry JavaScript also from third parties, for that matter) can. does it follow that, because you're not seeing opposition, it's because (as you put it so fake-politely) nobody else was willing to waste time as I was to share informed opinions and discuss honestly with you, or to believe your ability to think rationally? I see your point, I regret wasting my time with you already. hopefully what I wrote in this thread may have a positive effect on others.
CC: @quasi@peister.org @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh@lxo web apps for real-time collaboration, social media, video conferencing, online banking, trading, e-learning, auctions, e-commerce and so on, all need client-side JavaScript. It's just a *necessity* to meet the minimum quality standards.
Internet offers endless variety: if you don't trust a website, the best thing you can do is not visiting it.
Alex, my social feed stays always open for you, hoping for pleasant conversations in future. Take care.
-
@LorenzoAncora @tennoseremel @lxo >iFrames are discouraged by most web dev guidelines, as they can embed malicious remote content,
So iframes without JavaScript is bad, but a page full of malicious proprietary JavaScript without iframes is good? Huh.
Have you considered that JavaScript is always the "malicious remote content"?
>allowing criminals to inject malware, steal information, or conduct fraud
Exploitation, information exfiltration etc require JavaScript to pull off - meanwhile you cannot do any of that with just HTML.
>whereas client-side JavaScript is sandboxed within the isolated context of the webpage
Have you considered that there's always a sandbox bypass?
>with same-origin policy restrictions.
Last time I checked those can be applied to iframes just as well.
>Client-side processing grants improved responsiveness, better privacy and faster loadings, also reducing the carbon footprint by avoiding unnecessary web requests.
In reality, I find that cgit is far more responsive and loads faster and has better privacy than JavaScript-based git hosts, which are much slower and really hit the CPU hard - increasing electrical consumption substantially.
If you want to reduce COâ‚‚ emissions, one effective move would be to eliminate JavaScript.@Suiseiseki @LorenzoAncora @tennoseremel @lxo There is also zero reason why a first-party site couldn't embed malicious data directly, such as image data malformed specifically to exploit bugs in a codec library used by some common browsers.
There is no reason, either, to assume that iframes cannot be controlled by the same first-party and used to obviate unnecessary JavaScript interactions.
> Exploitation, information exfiltration etc require JavaScript to pull off - meanwhile you cannot do any of that with just HTML.
Technically, other flaws in a browser implementation may permit it. This is the result of unsafe programming practices. -
@lxo web apps for real-time collaboration, social media, video conferencing, online banking, trading, e-learning, auctions, e-commerce and so on, all need client-side JavaScript. It's just a *necessity* to meet the minimum quality standards.
Internet offers endless variety: if you don't trust a website, the best thing you can do is not visiting it.
Alex, my social feed stays always open for you, hoping for pleasant conversations in future. Take care.
@LorenzoAncora @lxo @quasi @Suiseiseki @tennoseremel > It's just a *necessity* to meet the minimum quality standards.
Funny that. I actually consider my bank's site to have actively degraded every single update they made since adding JavaScript to it. The original version was also considerably faster to use. -
@Suiseiseki @LorenzoAncora @tennoseremel @lxo There is also zero reason why a first-party site couldn't embed malicious data directly, such as image data malformed specifically to exploit bugs in a codec library used by some common browsers.
There is no reason, either, to assume that iframes cannot be controlled by the same first-party and used to obviate unnecessary JavaScript interactions.
> Exploitation, information exfiltration etc require JavaScript to pull off - meanwhile you cannot do any of that with just HTML.
Technically, other flaws in a browser implementation may permit it. This is the result of unsafe programming practices.@lispi314 @LorenzoAncora @tennoseremel @lxo >Technically, other flaws in a browser implementation may permit it.
Technically yes, but every single exploit I've seen has used JavaScript. -
@lispi314 @LorenzoAncora @tennoseremel @lxo >Technically, other flaws in a browser implementation may permit it.
Technically yes, but every single exploit I've seen has used JavaScript.@Suiseiseki the exploits you can see and that are published are only a small fraction of the total. Most exploits are sold and then kept secret.
-
@Suiseiseki the exploits you can see and that are published are only a small fraction of the total. Most exploits are sold and then kept secret.
@LorenzoAncora @Suiseiseki @tennoseremel @lxo Which is a good reason to be disappointed by all the C++ browsers with C libraries lacking any formal verification being used.
It is a predictable outcome and yet practices are not being adapted accordingly.
One of the most important would be to constrain unexpected computation the browser may induce (no arbitrary code execution, such as JavaScript), since hardware vulnerabilities of various sorts may defeat even entirely correct programs' security. -
@LorenzoAncora @Suiseiseki @tennoseremel @lxo Which is a good reason to be disappointed by all the C++ browsers with C libraries lacking any formal verification being used.
It is a predictable outcome and yet practices are not being adapted accordingly.
One of the most important would be to constrain unexpected computation the browser may induce (no arbitrary code execution, such as JavaScript), since hardware vulnerabilities of various sorts may defeat even entirely correct programs' security.@lispi314 you can disable JavaScript in your browser if you want, but 98% of public websites worldwide depend on JavaScript and will not work or have reduced functionality if its disabled.
No webmaster likes to do more work, if we use JS, it means its necessary.
-
@LorenzoAncora @lxo @quasi @Suiseiseki @tennoseremel > It's just a *necessity* to meet the minimum quality standards.
Funny that. I actually consider my bank's site to have actively degraded every single update they made since adding JavaScript to it. The original version was also considerably faster to use.@lispi314 most banks are forced to use JS in order to enforce certain verifications and security policies.
Online banking used it for the last decades, in a form or another. You just started to pay more attention to it, like most of us.
-
@lispi314 most banks are forced to use JS in order to enforce certain verifications and security policies.
Online banking used it for the last decades, in a form or another. You just started to pay more attention to it, like most of us.
@LorenzoAncora @lispi314 @tennoseremel @quasi @lxo There is no legal requirement that the "verification" or "security policies" are implemented with JavaScript specifically.
JavaScript is just a cheap way to implement things (as web developers don't know HTML - only JavaScript), even though it is the worst way to implement the vast majority of functionality. -
@LorenzoAncora @lispi314 @tennoseremel @quasi @lxo There is no legal requirement that the "verification" or "security policies" are implemented with JavaScript specifically.
JavaScript is just a cheap way to implement things (as web developers don't know HTML - only JavaScript), even though it is the worst way to implement the vast majority of functionality.@Suiseiseki web developers must know HTML, CSS, JavaScript and sometimes a language like Python, PHP, Perl, ...
The law never imposed a specific language, it is superfluous, as JavaScript is and has always been the only way.
Different solutions would require too much server-side processing and some verifications cannot be implemented server-side, thus requiring JS.
-
@Suiseiseki web developers must know HTML, CSS, JavaScript and sometimes a language like Python, PHP, Perl, ...
The law never imposed a specific language, it is superfluous, as JavaScript is and has always been the only way.
Different solutions would require too much server-side processing and some verifications cannot be implemented server-side, thus requiring JS.
@LorenzoAncora >some verifications cannot be implemented server-side, thus requiring JS.
The only place verification can work is server side - as the client cannot be trusted to follow a protocol.
>as JavaScript is and has always been the only way.
Imagine not even knowing about the previous existence of Flash.
JavaScript certainly isn't the only away - as it's easier to just write a free software client that implements the functionality in a sane language (you don't even need to bother to write one - you just make an API available with some documentation and someone will write one).
Using JavaScript to verify input is like trusting a client to provide a newline-terminated string to the server - the server needs to actually verify a string is newline terminated before processing an operation that expects a newline. -
@LorenzoAncora >some verifications cannot be implemented server-side, thus requiring JS.
The only place verification can work is server side - as the client cannot be trusted to follow a protocol.
>as JavaScript is and has always been the only way.
Imagine not even knowing about the previous existence of Flash.
JavaScript certainly isn't the only away - as it's easier to just write a free software client that implements the functionality in a sane language (you don't even need to bother to write one - you just make an API available with some documentation and someone will write one).
Using JavaScript to verify input is like trusting a client to provide a newline-terminated string to the server - the server needs to actually verify a string is newline terminated before processing an operation that expects a newline.@Suiseiseki verification happens server-side, JavaScript is used for data gathering and preparation. If the JavaScript is maliciously altered by the client, the server simply rejects the request.
-
@Suiseiseki verification happens server-side, JavaScript is used for data gathering and preparation. If the JavaScript is maliciously altered by the client, the server simply rejects the request.
@LorenzoAncora >verification happens server-side,
Then then client-side JavaScript verification is clearly not needed.
>JavaScript is used for data gathering and preparation
HTML5 is perfectly capable of gathering data and preparing it for submission - it can even check the input format without JavaScript.
But instead of using the HTML5 forms, your typical web developer writes up some JavaScript abortion that performs far worse than the built-in forms. -
@LorenzoAncora >verification happens server-side,
Then then client-side JavaScript verification is clearly not needed.
>JavaScript is used for data gathering and preparation
HTML5 is perfectly capable of gathering data and preparing it for submission - it can even check the input format without JavaScript.
But instead of using the HTML5 forms, your typical web developer writes up some JavaScript abortion that performs far worse than the built-in forms.@Suiseiseki maybe I didn't explain myself: the verification of data integrity and correctness happens server-side too, not only client-side.
JavaScript is also needed to guarantee compatibility with older web browsers which don't support all HTML5 features. In addition, HTML5 forms can check the input for syntactical correctness, but cannot process nor alter collected data.
JavaScript exists for a good reason.
-
@Suiseiseki maybe I didn't explain myself: the verification of data integrity and correctness happens server-side too, not only client-side.
JavaScript is also needed to guarantee compatibility with older web browsers which don't support all HTML5 features. In addition, HTML5 forms can check the input for syntactical correctness, but cannot process nor alter collected data.
JavaScript exists for a good reason.
@LorenzoAncora >guarantee compatibility with older web browsers
Proprietary JS site do not support older browsers - those are primarily designed to run only on chrome and sometimes those run on firefox too.
If the browser doesn't support the used HTML5 features, chances are it won't support the execution of the JavaScript framework used either.
>the verification of data integrity and correctness happens server-side too, not only client-side.
It is a waste of electricity to check twice when you only need to check once.
Processing and altering collected data is up to the server.
If the task is processing and altering information for the user, then the user should do such processing on their own computer with free software without involving a server.
JavaScript exists because it was too easy to think that adding cancer in the form of scripting would make things nicer. -
@LorenzoAncora >guarantee compatibility with older web browsers
Proprietary JS site do not support older browsers - those are primarily designed to run only on chrome and sometimes those run on firefox too.
If the browser doesn't support the used HTML5 features, chances are it won't support the execution of the JavaScript framework used either.
>the verification of data integrity and correctness happens server-side too, not only client-side.
It is a waste of electricity to check twice when you only need to check once.
Processing and altering collected data is up to the server.
If the task is processing and altering information for the user, then the user should do such processing on their own computer with free software without involving a server.
JavaScript exists because it was too easy to think that adding cancer in the form of scripting would make things nicer.@Suiseiseki @LorenzoAncora JavaScript interpreter Java applet for older browser compatibility -
R ActivityRelay shared this topic
-
@lispi314 you can disable JavaScript in your browser if you want, but 98% of public websites worldwide depend on JavaScript and will not work or have reduced functionality if its disabled.
No webmaster likes to do more work, if we use JS, it means its necessary.
@LorenzoAncora @lispi314 or maybe that they are lazy and want to use some fancy JS "framework" instead of writing proper HTML? I'm not a web developer myself but for most websites I could imagine HTML versions that do the job just as well. Maybe they don't look as fancy but I personally don't care about that.
-
R AodeRelay shared this topic
