Conversation

Notices

1. Embed this notice
   Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Monday, 03-Mar-2025 11:25:21 JST Lorenzo Ancora :verified:

   GNU Emacs: new critical remote shell injection vulnerability.

   Red Hat discovered a command injection flaw in the text editor Emacs. It allows a remote, unauthenticated attacker to execute any command on your computer. The vulnerability is activated when you visit a malicious website or link.

   https://www.cve.org/CVERecord?id=CVE-2025-1244

   ---

   #news #software #gnu #emacs #security #hacking #terminal #linux #cve #opensource #freesoftware

   ---

   Mitigation: uninstall/update immediately.

   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Monday, 03-Mar-2025 11:25:19 JST Alexandre Oliva

     in reply to
     ironically, the cve website itself also attempts to install and run commands on your computer, and if you don't allow it, it will refuse to let you know about the vulnerability
     
     翠星石 likes this.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 03-Mar-2025 17:09:44 JST 翠星石

     in reply to

     • Alexandre Oliva
     @lxo @LorenzoAncora CVEs are useless as all those are intended to do is to embarrass proprietary software developers to plug a few holes in their Swiss cheese, which would otherwise go unfixed for years or forever.
     
     The bugs have been fixed in Emacs 30.1 and so the relevant page is; https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-30.1
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 03-Mar-2025 17:11:58 JST 翠星石

     in reply to

     • Alexandre Oliva
     @lxo @LorenzoAncora Rather - ironically, the CVE website performs arbitrarily code execution on your computer (a SEVERE vulnerability) and if your web browser doesn't have that severe vulnerability, nothing displays?
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 03-Mar-2025 21:42:38 JST 翠星石

     in reply to
     @LorenzoAncora >cve.org is popular and safe to use.
     You write that, but then I see the following Obfscript;
     https://cmp.osano.com/AzyhULTdPkqmy4aDN/46057d56-0263-4cca-abac-9adddada4f3b/osano.js
     https://www.cve.org/assets/index-mLL8icbW.js
     
     Those are sufficiently large programs that would be quite trivial to slip proprietary malware in and have such go unnoticed.
     
     Any attacker wouldn't even need to compromise the computer cve.org is running on to attack visitors - they could compromise cmp.osano.com instead.
     
     It seems more JavaScript programs are loaded too, although which ones are not revealed until you run proprietary JavaScript (free and nonfree JavaScript are mixed into the same file), which I refuse to do.
     
     >JavaScript is a web standard that helps ensure compliance with EU safety regulations and accessibility requirements.
     JavaScript absolutely destroys accessibility and seems to be primarily used to spy on the user, which doesn't exactly "comply with EU safety regulations".
     
     >It is implemented by 97.69% of web browsers and utilized by 98.3% of all public websites.
     97.69% of web browsers have a SEVERE vulnerability and a little less than 98.3% of public websites attack people with proprietary software and spyware huh?
     
     >its presence on the CVE site is standard practice for modern web functionality.
     Just because attacking the user is standard practice doesn't mean a website that doesn't function without JavaScript is acceptable.
     
     The only JavaScript your website needs and should have is as follows;
     <script>
     /* AGPLv3-or-later */
     document.body.innerHTML = 'We have detected that you have JavaScript enabled in your browser, please disable it to continue. Please be aware that your browser is severely compromised as it is automatically running malicious JavaScript.'
     </script>
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Monday, 03-Mar-2025 21:42:40 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石

     @Suiseiseki cve.org is popular and safe to use. JavaScript is a web standard that helps ensure compliance with EU safety regulations and accessibility requirements. It is implemented by 97.69% of web browsers and utilized by 98.3% of all public websites. Therefore, its presence on the CVE site is standard practice for modern web functionality.

     Please see: https://ieji.de/@LorenzoAncora/114098428234129692

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 03-Mar-2025 21:48:24 JST 翠星石

     in reply to

     • Alexandre Oliva
     @LorenzoAncora @lxo All proprietary software is malware until proven otherwise (I have come to this conclusion after learning that most proprietary software is malware and checking and confirming for myself with many proprietary programs, although there are a few unicorns that don't contain any malicious antifeatures) and the cve.org site appears to distribute proprietary software.
     
     The "ssltrust.com" site loads OBFUSCATED PROPRIETARY MALWARE FROM GOOGLE THAT SPIES ON THE USER; https://www.googletagmanager.com/gtag/js?id=G-F20S2H1H0C so I'm not sure how that site can be trusted to confirm cve.org is safe to use.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Monday, 03-Mar-2025 21:48:25 JST Lorenzo Ancora :verified:

     in reply to

     • Alexandre Oliva

     @lxo Hi Alexandre, nice to read you again. CVE.org is a reputable site that does not distribute malware or execute unsandboxed code. It is safe to use: https://www.ssltrust.com/ssl-tools/website-security-check?domain=www.cve.org

     The website does not and cannot install anything on your computer. JavaScript is used to improve the user experience.

     I apologize for linking a site you can't visit due to self-imposed ethical limitations. I've attached a full-length screenshot of the page. Let me know if I can assist you further.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 03-Mar-2025 22:10:14 JST 翠星石

     in reply to
     @LorenzoAncora I don't believe the virustotal scanner is setup to scan malicious JavaScript and assuming it does, of course it would whitelist all of google's JavaScript.
     
     That virustotal page of course loads obfuscated proprietary malware from google; https://www.recaptcha.net/recaptcha/enterprise.js thus it cannot be trusted to confirm that files aren't malware (although it might still have some use confirming that certain files are malware).
     
     >you've linked to are minified (compressed), not obfuscated.
     The tag manager script I've linked to is both obfuscated and minified, although minification alone is often quite effective obfuscation.
     
     If the source code is also provided and that exactly corresponds with the minified version, the file isn't obfuscated, otherwise it is.
     
     >Almost all websites use compression to improve loading times.
     Yes, many websites use GNU zip (gzip) compression on served files to improve loading times.
     
     Minification doesn't improve loading times unless you want to load 12MiB+ worth of JavaScript.
     
     >You can simply use the auto-format of your text editor to read minified scripts with minimal effort.
     Auto-formatting won't restore meaningful function names and comments.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Monday, 03-Mar-2025 22:10:15 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石

     @Suiseiseki the scripts do not appear to contain malware:
     https://www.virustotal.com/gui/url/0e7795408fa7cc6e918cbb0526bc804fece03f7b7685bebdc971670910088fea

     https://www.virustotal.com/gui/url/b698d39b69b283657a4120248b211baeeb6be9b9f46a0bf873bfbcb5cbf622ac

     All JavaScript files you've linked to are minified (compressed), not obfuscated. Almost all websites use compression to improve loading times. You can simply use the auto-format of your text editor to read minified scripts with minimal effort.

   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Monday, 03-Mar-2025 23:55:29 JST Alexandre Oliva

     in reply to

     • 翠星石
     so you run trojans from two malicious web sites to "prove" that another web site is not malicious. that's as reasonable as asking both coca-cola and pepsi whether their softdrinks are healthy to drink. they don't seem to be affecting only browsers, but also users' brains 😞
     
     that it makes the site completely inaccessible to, per your own numbers, 2.31% of browsers, where web standards recommend graceful degradation instead of big bold red letters stating "don't feel welcome" to those with specific accessibility needs that both major brands of browsers can't tend to, is a big "screw you" to me and others
     
     that it renders computers unusable to access this very site, computers whose manufacturers have abandoned, by refusing to patch known security vulnerabilities that can be exercised with remotely-supplied javascript and refusing to allow owners to patch them by themselves, computers that would still be perfectly usable to visit web sites that actually took the trouble to abide by web standards instead of jumping on the "you must enable javascript" "screw you" mindless bandwagon, adds insult to injury, and more litter to the pile
     
     that a web site that ought to be as security conscious as it goes, and reports vulnerabilities even on browsers, that enable web sites to induce remote execution of arbitrary code on visitors' computers, demands visitors to open up their computers to such risks is not only contradictory to its mission, it's a "screw you" to security education as well.
     
     CC: @Suiseiseki@freesoftwareextremist.com
     
     翠星石 likes this.
   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Tuesday, 04-Mar-2025 00:00:26 JST Alexandre Oliva

     in reply to
     thank you, I suppose. nothing much useful on this page, alas. maybe others would have more interesting materials.
     
     likewise, even if we take for granted your statement that the code currently served by this web site is indeed safe to use (and that's a big if), that doesn't reassure me or anyone else that this will still be the case tomorrow. it's basically playing digital russian roulette. it's been normalized, but that doesn't make it good, it's just a giant pile of poo that has been "democratized", and is force-fed equally into everyone.
     
   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Tuesday, 04-Mar-2025 05:50:08 JST Alexandre Oliva

     in reply to

     • 翠星石
     • Ténno Seremél’
     even if it were still safe now, it is one take-over away from becoming nonsafe, and all the wrong things it's teaching now will become vulnerabilities that the future hostile owner will be able to exploit. it's negligent security malpractice.
     
     CC: @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh
     
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Tuesday, 04-Mar-2025 05:50:09 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Alexandre Oliva

     @lxo you're welcome. If you need the screenshot of something else just ask, I'll gladly use the latest build of Mozilla Firefox on my up-to-date Linux to take a screenshot for you.

     CVE.org is supported by the Cybersecurity and Infrastructure Security Agency (CISA) and by MITRE, a 65 years old corporation specialized in national defense, financial systems and cybersecurity.
     Its staff has 25 years of experience. If this website isn't safe, we're all doomed. 🙂

     CC: @Suiseiseki , @tennoseremel

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Tuesday, 04-Mar-2025 10:49:28 JST 翠星石

     in reply to

     • Ténno Seremél’
     @LorenzoAncora @tennoseremel Minification doesn't just remove unnecessary white space (which can be done while retaining the formatting mostly by replacing each 1-3 space characters with a single space and by replacing each 4 space characters with a tab) - unnecessary white space compresses very well regardless.
     
     Minification strips off any explanatory comments and changes variable and function names to non-meaningful one or two etc character names (i.e. a-z then aa-zz etc), which is extremely effective at hindering the ability to audit the software.
     
     
     If you want to minimize the "carbon footprint" or actually CO₂ emissions, you should avoid JavaScript like the plague, as it's dozens, hundreds or thousands of times less power efficient than HTML.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Tuesday, 04-Mar-2025 10:49:30 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’

     @tennoseremel hi, minification and compression are distinct processes.
     
     Minification removes unnecessary white space while compression reduces file size. They work together in HTTP to improve page load times. Minification helps reduce the file size, making it more efficient for compression to take effect, and ultimately, for the browser to download and render the page. They only improve performance and reduce carbon footprint. Minification cannot hinder experts auditing. 😉

     CC: @Suiseiseki

   • Embed this notice
     Ténno Seremél’ (tennoseremel@lor.sh)'s status on Tuesday, 04-Mar-2025 10:49:31 JST Ténno Seremél’

     in reply to

     • 翠星石

     @LorenzoAncora One does not need minification to compress. And minification is absolutely obfuscation, even if, usually, not intended.

     @Suiseiseki

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Tuesday, 04-Mar-2025 10:55:05 JST 翠星石

     in reply to

     • Ténno Seremél’
     • Alexandre Oliva
     @LorenzoAncora @lxo @tennoseremel If MITRE and CISA was actually carrying out sufficient oversight, they would require that the page work without JavaScript.
     
     Living in irrational trust of webpages that serve malicious software and trying to convince rational people to run such malware isn't healthy.
     
     
     You do not need JavaScript to write an interactive website - rather the best interactive websites don't use JavaScript and instead use HTML5+CSS+fastCGI; https://git.savannah.gnu.org/cgit/
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Tuesday, 04-Mar-2025 10:55:07 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Alexandre Oliva

     @lxo I understand your concerns, but MITRE and CISA's oversight ensures CVE.org's security and integrity. Regular audits, bug reporting programs and frequent updates help mitigate future risks.

     Alexandre, living in irrational fear of interactive webpages isn't healthy. We live only once, mate! 🙂

     I'm currently satisfied and use their services with gratitude. If I had anything to say about their ethics, I would tell them personally.
     I advise you do the same.

     CC: @Suiseiseki @tennoseremel

   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Tuesday, 04-Mar-2025 13:34:24 JST Alexandre Oliva

     in reply to

     • 翠星石
     • Ténno Seremél’
     the oversight has already failed, evidently, to have allowed such a contradictory web site to use their name. everyone is seeing how easy it is to turn a whole country with a quarter-millennium tradition of laic democracy into a self-destructing theocracy. your attitude of blind trust on the good intentions and harmlessness of common malpractice is anachronistic and unfit. your attempts to ridicule concerns that prove right time and again are an irresponsible embarrassment to serious security professionals, and to anyone paying attention to world politics without hiding the head in the sand.
     
     as for living in irrational fear... should I remind you that it was you who brought into my timeline a report of a security problem related with allowing third parties to run arbitrary code on our computers? are you suggesting that nobody should take those reports seriously?
     
     or are you one of those believers that the leopards will never bite your face?
     
     CC: @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh
     
   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Wednesday, 05-Mar-2025 04:16:26 JST Alexandre Oliva

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Yuchen Pei
     heh, I guess this means my assessment that everyone is seeing it is wrong, for at least one person isn't
     
     CC: @Suiseiseki@freesoftwareextremist.com @LorenzoAncora@ieji.de @tennoseremel@lor.sh
     
   • Embed this notice
     Yuchen Pei (quasi@peister.org)'s status on Wednesday, 05-Mar-2025 04:16:27 JST Yuchen Pei

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Alexandre Oliva
     @lxo
     > everyone is seeing how easy it is to turn a whole country with a quarter-millennium tradition of laic democracy into a self-destructing theocracy.
     
     Not sure what this is about.
     @LorenzoAncora @Suiseiseki @tennoseremel
   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Wednesday, 05-Mar-2025 09:16:52 JST Alexandre Oliva

     in reply to
     how nice of you to completely disregard the threat models that others are under. not!
     
     not everyone is an exploited consucker; some people take security seriously. that 98% of the websites expose their exploited consuckers to risks they don't understand on purpose is just something to be expected in the enshittocene. that some participants in their exploitation will minimize the risks is to be expected; likewise, some losers will believe them. I don't care which of these you are, but what you're saying, along the lines of "relax and allow the masters to rule over us all" doesn't appeal to me.
     
     try asking those web site operators whether they'd allow you to upload code to run on their servers, within a VM sandbox even, and see the kind of response you'd get. if you run into someone aware of actual security, they'll teach you about layers of defense and security in depth. relying on a single sandbox barrier for your security against hostile agents would be extremely very naïve. typical consuckers may get away with that (they're already fully compromised anyway), but those who actually wish to keep control over their devices and their computing can't afford to take that kind of risk. it would amount to giving up security and freedom.
     
     CC: @tennoseremel@lor.sh
     
     翠星石 likes this.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Wednesday, 05-Mar-2025 09:16:53 JST Lorenzo Ancora :verified:

     in reply to

     • Ténno Seremél’
     • Alexandre Oliva

     @lxo Alexandre, I will be the one biting faces if you start a religion/politics thread here! 🐺

     Take all security reports seriously but try not to be obsessed about it, you'll just end up reaching uninformed conclusions. Trust the pros, take the mitigation steps and be productive.

     Trust is always optional. But if you're feeling threatened by 98% of websites, its time to reassess your habits: better friends, less work, healthier food, touching grass more often, all helps.

     CC: @tennoseremel

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Wednesday, 05-Mar-2025 20:35:30 JST 翠星石

     in reply to

     • Ténno Seremél’
     @LorenzoAncora @tennoseremel How does one own a website? It's not some physical thing that has a physical place.
     
     It's the website host's decision what license to put their JavaScript under and what other JavaScript to use.
     
     The user having freedom is in the visitors interest and if there is proprietary JavaScript, the user is denied such important interest; https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
     
     
     Merely being able to see and read the source code and check the security is only half of freedom 1
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Wednesday, 05-Mar-2025 20:35:32 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’

     @Suiseiseki unless the website owner publishes the JavaScript code under a FOSS license, full performance optimization is in the visitor's interest and you can't expect to find comments or readability aids.

     In all cases, code quality and security are the webmaster's responsibility, not yours.

     CC: @tennoseremel

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Wednesday, 05-Mar-2025 21:02:31 JST 翠星石

     in reply to

     • Ténno Seremél’
     • Alexandre Oliva
     @LorenzoAncora @tennoseremel @lxo >it lacks the capability to handle events, manipulate the DOM in real-time, or perform asynchronous operations
     You do not need any of those things.
     
     If you wanted things to be asynchronous on the same page for a laugh, there's something called iframe.
     
     >FastCGI, executing server-side, is computationally more expensive because it requires multiple web requests
     JavaScript requires multiple web requests just to load the JavaScript and then continuous web requests to do each operation, so really JavaScript loses again.
     
     FastCGI really only needs a single request back and forth for every operation.
     
     You can hand optimize the software on the FastCGI end with assembly if you want to minimize how computationally expensive each operation is.
     
     Generally sequentially processing operations on one computer in an efficient manner (doing mostly the same operation over and over again is pretty cache efficient) uses less power than doing the operations in an inefficient way across 1000, 10,000 or millions of computers.
     
     JavaScript is a way to just dump the processing onto the client (and as the client is the one who has to pay for the power, usually the JavaScript is left completely unoptimized).
     
     >can be more vulnerable to remote code execution and misconfigurations than client-side JavaScript.
     I'm not sure about the validity of this claim, as fastCGI usually takes user input as POST fields, which is usually properly escaped, unlike a lot of client side JavaScript, which seems to send JavaScript objects, or JSON blobs to the server.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Wednesday, 05-Mar-2025 21:02:33 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Alexandre Oliva

     @Suiseiseki HTML5 alone cannot replace JavaScript because it lacks the capability to handle events, manipulate the DOM in real-time, or perform asynchronous operations, which are essential for creating dynamic, accessible and interactive pages.

     FastCGI, executing server-side, is computationally more expensive because it requires multiple web requests and can be more vulnerable to remote code execution and misconfigurations than client-side JavaScript.

     CC: @tennoseremel @lxo

   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Thursday, 06-Mar-2025 02:47:09 JST Alexandre Oliva

     in reply to

     • Ténno Seremél’
     your mask of fake politeness is transparent to me, but your aggression and insults are very visible to me. but don't worry, I'm not returning in kind.
     
     running code under control of a third party is always a bad move, because it makes you a subject to the third party who controls the code. there's increasing pressure to force users to submit to that control. I, as someone who realizes the harm in this practice, am part of the resistance.
     
     CC: @tennoseremel@lor.sh
     
     翠星石 likes this.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Thursday, 06-Mar-2025 02:47:10 JST Lorenzo Ancora :verified:

     in reply to

     • Ténno Seremél’
     • Alexandre Oliva

     @lxo many trade-offs around in IT security, which requires a layered approach, as servers and clients have much different security requisites.

     JavaScript security is in constant improvement because Web 2.0 needs it, used to much easily publish interactive content, facilitating self-expression, self-hosting and collaboration.

     Note: I'm ignoring your rhetoric techniques, but mind that insults and ad hominem attacks aren't ok. I'm polite, so at least treat people with respect.

     CC: @tennoseremel

   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Thursday, 06-Mar-2025 02:56:57 JST Alexandre Oliva

     in reply to

     • Yuchen Pei
     true. I just think that, if you were seeing it, you'd know what I was alluding to.
     
   • Embed this notice
     Yuchen Pei (quasi@peister.org)'s status on Thursday, 06-Mar-2025 02:56:58 JST Yuchen Pei

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Alexandre Oliva
     @lxo
     Not knowing what you are referring to is not the same as not seeing it
     
     @Suiseiseki @LorenzoAncora @tennoseremel
   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Thursday, 06-Mar-2025 03:05:24 JST Alexandre Oliva

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Yuchen Pei
     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
     
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Thursday, 06-Mar-2025 03:05:25 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Yuchen Pei
     • Alexandre Oliva

     @lxo no Alexander, even saints met opposition.
     When you don't see much opposition, it only means nobody else thought sharing their informed opinions and discuss honestly with you was worth their time. In other words, that nobody else believed in your ability to think rationally, understand different perspectives and thus improve.

     CC: @quasi @Suiseiseki @tennoseremel

   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Thursday, 06-Mar-2025 03:10:12 JST Alexandre Oliva

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Yuchen Pei
     now, your deeper incorrect assumption is that I'd need to debate this with informed professionals. people who are aware of the security implications of running arbitrary third-party code in vulnerable sandboxes do scratch their heads trying to mitigate this poor behavior when it affects them. but most of the time, it's somebody else's problem, none of their concern, lusers be damned.
     
     CC: @quasi@peister.org @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh
     
     翠星石 likes this.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Thursday, 06-Mar-2025 19:57:35 JST 翠星石

     in reply to

     • Ténno Seremél’
     @LorenzoAncora @tennoseremel >I own many digital goods and ownership is generally tied to purchase.
     If you need to run a proprietary program to access such "digital goods", you don't own any of such.
     
     >FOSS is about the rights of software developers and users to modify and distribute desktop and mobile software.
     In fact, "FOSS" is about trying to be neutral between the freedom of free software and bootlicking corporates to get money to fund fast development ("open source").
     
     >Users can choose to visit or avoid a website based on their own free will
     In many countries, the government demands that the citizens visit a website full of proprietary JavaScript to submit taxes or census information etc, thus visiting a website is not always done out of free will.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Thursday, 06-Mar-2025 19:57:37 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’

     @Suiseiseki I own many digital goods and ownership is generally tied to purchase.

     Understand the scope of the free software movement accurately: FOSS is about the rights of software developers and users to modify and distribute desktop and mobile software.

     Never conflate the concept of software freedom with website ownership. Users can choose to visit or avoid a website based on their own free will, regardless of the licensing terms of the JavaScript used on that site.

     CC: @tennoseremel

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Thursday, 06-Mar-2025 20:04:55 JST 翠星石

     in reply to

     • Ténno Seremél’
     • Alexandre Oliva
     @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.
     Alexandre Oliva likes this.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Thursday, 06-Mar-2025 20:04:56 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Alexandre Oliva

     @Suiseiseki iFrames are discouraged by most web dev guidelines, as they can embed malicious remote content, allowing criminals to inject malware, steal information, or conduct fraud, whereas client-side JavaScript is sandboxed within the isolated context of the webpage with same-origin policy restrictions.

     Client-side processing grants improved responsiveness, better privacy and faster loadings, also reducing the carbon footprint by avoiding unnecessary web requests.

     CC: @tennoseremel @lxo

   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Friday, 07-Mar-2025 11:55:08 JST Alexandre Oliva

     in reply to

     • Ténno Seremél’
     you're absolutely correct that, unless the website is yours, you won't be in control. that's the point of the discussion, and of the free software movement: when a program is doing your computing, you should be in control.
     
     of the web apps that you mentioned in another post, some do communication/collective computing, but those that do your computing shouldn't be web apps at all. that they are a tool of oppression and control.
     
     now, this conversation started about a website whose goal is (presumed to be) making security information available to others. it's about publishing, not anyone reader's computing. but the computing that the server wishes to impose on users is not the users' computing either; users should be allowed to reject that abuse of their computing resources. but if that implies that the site won't make the information available to users who make that choice, the site is failing its purpose of making the information available.
     
     now, if the site is a tool of control, sure, it will impose unnecessary and undesirable computing on users and demand them to disable their web firewalls and make themselves vulnerable in order to get access to the security information. see the problem there?
     
     note I'm not saying the site must not offer interactive possibilities using JavaScript. what I'm saying is that the site should degrade gracefully and offer the information, that's what users are after, even if they won't lower their shields. it's not that hard, unless developers are determined to make it impossible. and if they do, we must wonder why they do.
     
     CC: @tennoseremel@lor.sh
     
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Friday, 07-Mar-2025 11:55:10 JST Lorenzo Ancora :verified:

     in reply to

     • Ténno Seremél’
     • Alexandre Oliva

     @lxo unless the website is yours, you will never be in total control. The website owner will always be able to decide what each visitor sees and what each user can do on the company's domains. JavaScript is only an improvement to the user experience, its absence would make our life harder, its presence is almost always helpful has a very marginal effect on our freedom.

     Tip for GNUs: focus on improving yourself rather than bashing others. Choose self-improvement over hate.

     CC: @tennoseremel

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 07-Mar-2025 12:01:36 JST 翠星石

     in reply to

     • Ténno Seremél’
     • Alexandre Oliva
     @LorenzoAncora @tennoseremel @lxo Please put down the proprietary flavor aid.
     
     >images, CSS, documents, most web resources have processing flaws which allow for unsandboxed code execution.
     Yes, in certain cases such parsing libraries can have vulnerabilities, but those vulnerabilities are soon fixed and most exploits usually require JavaScript to successfully pull off, as a sequence of operations a user won't follow are required (while if you have arbitrary remote JavaScript execution, you can easily trigger such steps unnoticed).
     
     I believe such librarians are now sandboxed and you can sandbox such libraries much better than you can sandbox a JavaScript JIT (which requires allowing for runtime machine code generation and then executing that machine code (write & execute), unlike a image processing library that can be fully execute-only).
     
     >iFrame policies can often be bypassed using srcdoc, postMessage and clickjacking exploits.
     srcdoc is not an exploit - it's a way to choose what page is displayed in the iframe.
     
     Without the vulnerability of JavaScript, everything you do in an iframe only goes to the sourced webpage.
     
     postMessage and clickjacking exploits have a hard requirement on JavaScript, as postMessage is a JavaScript function and any HTML link shown is the one you're going to visit.
     
     >With AI, JavaScript will be indispensable to discern humans
     Artificial Stupidity software is now far better at solving captchas and thoughtlessly executing JavaScript, thus I don't see how people can be reliably distinguished with JS.
     
     >respect GDPR & NATO policies on privacy and ecology
     If you don't spy on the user and don't burn copious amounts of electricity, you won't need to worry about your compliance with polices.
     
     You can easily achieve both by not using JavaScript.
     
     
     HTML webpages are fit for all things a webpage is fit for.
     Alexandre Oliva likes this.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Friday, 07-Mar-2025 12:01:38 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Alexandre Oliva

     @Suiseiseki images, CSS, documents, most web resources have processing flaws which allow for unsandboxed code execution.

     iFrame policies can often be bypassed using srcdoc, postMessage and clickjacking exploits. They will be obsoleted (eg. by fencedframes which offer full JavaScript support).

     With AI, JavaScript will be indispensable to discern humans and to respect GDPR & NATO policies on privacy and ecology. HTML-only webpages will become unfit for most purposes.

     CC: @tennoseremel @lxo

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 07-Mar-2025 12:07:09 JST 翠星石

     in reply to

     • Ténno Seremél’
     @LorenzoAncora @tennoseremel >My usage of proprietary apps is minimum, all software I use is at least open source
     That is a massive contradiction, as "apps" are a type of software.
     
     The software you use, including your kernel and BIOS aren't even fully source available either.
     
     I'm using 100% free software myself, which happens to be fully source-available.
     
     >If your nation asks you to use a website to save the planet and reduce bureaucracy, this is a moral obligation.
     Forcing people to visit a website full of proprietary software only increases bureaucracy and is rather forcing people to contribute (negligibly but hey) to destroying the planet via excessive electrical consumption.
     
     Why would going to a location require a car trip? I reckon cycling or walking to somewhere to carry out unless bureaucracy would cause less damage than the electricity wasted by JavaScript.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Friday, 07-Mar-2025 12:07:10 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’

     @Suiseiseki no, I only use open protocols and FOSS apps to access my stuff. 😉

     FOSS is just a term to indicate "Free and Open Source Software", nothing more. My usage of proprietary apps is minimum, all software I use is at least open source. I don't focus on anyone's interests, I just serve higher ideals.

     If your nation asks you to use a website to save the planet and reduce bureaucracy, this is a moral obligation. Here at least JavaScript saves you two car trips! 🤣

     CC: @tennoseremel

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 07-Mar-2025 12:15:13 JST 翠星石

     in reply to

     • Ténno Seremél’
     • Yuchen Pei
     • Alexandre Oliva
     @LorenzoAncora @lxo @quasi @tennoseremel >web apps for real-time collaboration, video conferencing
     That should be native software like GNU Jami.
     
     >social media
     I am posting to the fediverse without JavaScript with BloatFE.
     
     >online banking, trading, auctions, e-commerce
     Most of such sites are static sites, except instead of implementing them in FastCGI, they are implemented worse in JavaScript.
     
     Such sites would be faster and waste less power without JavaScript.
     
     >e-learning
     Static HTML pages with maybe some images and videos are best for learning, as that way there are no distractions.
     
     >all need client-side JavaScript.
     None of them need JavaScript and should NOT have JavaScript.
     
     >It's just a *necessity* to meet the minimum quality standards.
     Working without JavaScript is the minimum acceptable quality standards for any website.
     
     
     If JavaScript-free clients like GNU Social and BloatFE weren't available, the fediverse wouldn't meet my minimum quality standards, but thankfully it does.
     Alexandre Oliva likes this.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Friday, 07-Mar-2025 12:15:14 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Yuchen Pei
     • Alexandre Oliva

     @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. 👋

     CC: @quasi @Suiseiseki @tennoseremel

   • Embed this notice
     LisPi (lispi314@udongein.xyz)'s status on Friday, 07-Mar-2025 13:26:14 JST LisPi

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Yuchen Pei
     • Alexandre Oliva
     @Suiseiseki @lxo @quasi @tennoseremel @LorenzoAncora > That should be native software like GNU Jami.
     Yes.
     
     > I am posting to the fediverse without JavaScript with BloatFE.
     Emacs for me.
     
     > Most of such sites are static sites, except instead of implementing them in FastCGI, they are implemented worse in JavaScript.
     I miss when they weren't Javascript, they were legitimately superior and performed better.
     
     > Static HTML pages with maybe some images and videos are best for learning, as that way there are no distractions.
     There are actually some legitimate use-cases for interactive environments.
     
     Consider Lisp CLIM, Smalltalk & their potential for various things. Computational notebooks are useful educational tools.
     
     Active engagement's positive effects on memorization and learning are well researched by now.
     
     They could also not pretend to be using HTML and could be fully Free/Libre Software (environments) distributed as such, rather than abusing HTML & web-based technology.
     
     > None of them need JavaScript and should NOT have JavaScript.
     Correct. They should be using Lisp.
     
     But most of them also don't need a dynamic interactive code environment at all.
     
     > Working without JavaScript is the minimum acceptable quality standards for any website.
     Yes.
     翠星石 likes this.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 07-Mar-2025 13:48:38 JST 翠星石

     in reply to

     • Ténno Seremél’
     • Yuchen Pei
     • Alexandre Oliva
     @LorenzoAncora @tennoseremel @quasi @lxo >the JS-less approach works well until the number of web requests grows.
     Considering that fastCGI uses less web requests that your typical JavaScript webpage (it gets everything done in one hit fast, rather than keeping a socket open, or multiple to perform each operation), JavaScript scales worse than fastCGI.
     
     >keep the user experience smooth and keep out the bots and AI through PoW captchas.
     Scraping bots can be detected by analyzing the access logs and then you just block them (usually fully automatic, as they hit the server multiple times a second from the same IP or IP block).
     
     PoW captchas written in JavaScript burn a serious amount of electricity and why wouldn't advanced scraping bots just run the JavaScript?
     
     >cloud integration with file hosting
     There is no cloud, there is only someone else's computer.
     
     >Those things only scale well with JavaScript.
     JavaScript doesn't scale well due to its poor efficiency, although most webhosts don't care about dumping the inefficiency onto the suckers.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Friday, 07-Mar-2025 13:48:40 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Yuchen Pei
     • Alexandre Oliva

     @Suiseiseki the JS-less approach works well until the number of web requests grows. It works fine for amateur apps and small websites, but popular ones are forced to use it in order to keep the user experience smooth and keep out the bots and AI through PoW captchas.

     Modern e-learning requires interactive excercises, flash cards, interrogations with supervision, cloud integration with file hosting and so on. Those things only scale well with JavaScript.

     CC: @tennoseremel @quasi @lxo

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 07-Mar-2025 14:06:43 JST 翠星石

     in reply to

     • Ténno Seremél’
     • Alexandre Oliva
     @LorenzoAncora @lxo @tennoseremel You are doom to failure if you try to detect scrapers via software that runs on the scraper.
     
     Some scrapers now just programmatically command standard web browsers, which means you cannot distinguish them from humans that use the same browsers.
     
     More pointless JavaScript executed → more pollution.
     
     
     If you want to detect scrapers, the only effective techniques is server side heuristics, honeypots and tarpits.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Friday, 07-Mar-2025 14:06:44 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Alexandre Oliva

     @Suiseiseki the reason webmasters can't implement graceful degradation is that, with the rise of AI, JS will be indispensable to discern humans through proof-of-work captchas and algorithms, in order to prevent service abuse and to respect GDPR & NATO policies on privacy and ecology (less requests -> less pollution and less MitM attack occasions). Obviously, client-side JavaScript will no longer be an optional dependency. Sad but true.

     𝗧𝗵𝗲 𝗯𝗮𝘁𝘁𝗹𝗲 𝗮𝗴𝗮𝗶𝗻𝘀𝘁 𝗝𝗦 𝗶𝘀 𝗽𝘆𝗿𝗿𝗵𝗶𝗰.

     CC: @lxo @tennoseremel

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Friday, 07-Mar-2025 14:11:55 JST 翠星石

     in reply to

     • Ténno Seremél’
     • Yuchen Pei
     • Alexandre Oliva
     @LorenzoAncora @tennoseremel @quasi @lxo >modern JS frameworks and libraries, such as React and Angular
     Whoops, by using those bloated libraries, you've just burned huge amounts of electricity and caused a massive amount of pollution.
     
     >reduce the number of requests; web sockets and pipelining then minimize the number of connections
     You can't beat a single fast request per operation that fastCGI can do, if each operation takes multiple slow requests, even with pipelining.
     
     >Local processing can be also less risky.
     If the operation can be locally done on the computer, it should be done on the computer using native software, rather than with some server.
     
     >Pure FastCGI apps will almost always waste more bandwidth, requests and computational power.
     In reality it is the opposite - fastCGI uses less bandwidth and computational power than JavaScript "frameworks".
     
     >IP analysis can't detect modern scrapers
     IP range analysis can indeed detect a scraper scraping multiple times a second.
     
     >PoW is always used along with machine learning or behavioral analysis.
     Whoops, that burns a huge amount of electricity and causes a massive amount of pollution.
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Friday, 07-Mar-2025 14:11:56 JST Lorenzo Ancora :verified:

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Yuchen Pei
     • Alexandre Oliva

     @Suiseiseki modern JS frameworks and libraries, such as React and Angular, implement various optimizations to reduce the number of requests; web sockets and pipelining then minimize the number of connections. Local processing can be also less risky.

     Pure FastCGI apps will almost always waste more bandwidth, requests and computational power.

     IP analysis can't detect modern scrapers and AI , so PoW is always used along with machine learning or behavioral analysis.

     CC: @tennoseremel @quasi @lxo

   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Friday, 07-Mar-2025 14:24:04 JST Alexandre Oliva

     in reply to

     • 翠星石
     • Ténno Seremél’
     the battle against scraping is pyrrhic
     
     whenever you place an expensive web page in front of a cheap resource meant to be public, you're not making yourself any favors, unless you enjoy shooting yourself in the feet. it's like blowing up an expensive piece of equipment to protect a fuse
     
     captchas don't require javascript. only some current implementations do, and they do so not because it's needed, but because they wish to normalize and impose poor security and freedom practices
     
     CC: @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh
     
     翠星石 likes this.
   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Friday, 07-Mar-2025 14:34:01 JST Alexandre Oliva

     in reply to

     • 翠星石
     • Ténno Seremél’
     the only thing that captchas do to users is deny them the opportunity to automate interactions on their end. it's creates an asymmetry in which the server is automated but the client can't be. it's ideal for exploitation. it's terrible for user autonomy.
     
     now, there are legitimate reasons to avoid abusive uses of services. with the rise of software that can replicate human's responses to web sites' demands for humans to behave like computers, you're just wasting resources in a fool's errand, and annoying your actual users. way to go! (not)
     
     CC: @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh
     
     翠星石 likes this.
   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Friday, 07-Mar-2025 14:38:16 JST Alexandre Oliva

     in reply to

     • 翠星石
     • Ténno Seremél’
     • Yuchen Pei
     shifting your computing costs onto your users may "scale", but it's abusive without consent. "you must do what I command or else" is not consent.
     
     CC: @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh @quasi@peister.org
     
   • Embed this notice
     Alexandre Oliva (lxo@snac.lx.oliva.nom.br)'s status on Tuesday, 11-Mar-2025 12:18:09 JST Alexandre Oliva

     in reply to

     • Ténno Seremél’
     • Yuchen Pei
     the flip side of what you're saying is that, when no public API is offered, the intent is indeed to control the client. QED
     
     CC: @tennoseremel@lor.sh @quasi@peister.org
     
   • Embed this notice
     Lorenzo Ancora :verified: (lorenzoancora@ieji.de)'s status on Tuesday, 11-Mar-2025 12:18:10 JST Lorenzo Ancora :verified:

     in reply to

     • Ténno Seremél’
     • Yuchen Pei
     • Alexandre Oliva

     @lxo modern webmasters don't "shift" the computing costs, they use client-side processing and caching to avoid transferring redundant data which the user may not really need and that would only hog the service back-end. Here, JavaScript is used to guarantee a fast and smooth service for everyone. 😉

     Websites change frequently, so amateur automations can be dangerous and unreliable. If the webmaster wants to allow automation, then the website will offer public APIs.

     CC: @tennoseremel @quasi