Ja en nee, want kan niet. Installeer no-script en je zult zien dat de helft van de websites niet meer functioneert...

Je noemt 64% aandeel zonder erbij te zeggen in welk geheel. Als je naar websites kijkt denk ik dat je dichter bij de 100% aandeel komt.

Hoe dan ook, met een dergelijk groot gebruik gaat niemand het voor elkaar krijgen om JavaScript af te voeren. We hebben geen wereldwijde programmeertaaldictator die even kan verordonneren dat iedereen wat anders moet gaan gebruiken. En zelfs Google, die nog het dichtst bij die positie komt omdat zoveel browsers tegenwoordig op Chrome gebaseerd zijn, kan zich niet permitteren om JavaScript geforceerd af te bouwen in een relatief korte tijd. Als ze dat zouden proberen zou de wereld niet met ze mee bewegen maar zou Chrome ophouden een aantrekkelijke browser te zijn en gebruiksaandeel verliezen.

Ik denk dat je niet raar moet staan te kijken als JavaScript over 20 of 30 jaar nog steeds heel aanwezig is. We hebben al aan vele talen kunnen zien dat een bestaande code-base ertoe leidt dat er in die taal ontwikkeld blijft worden. Er zijn nog steeds heel veel COBOL-applicaties bij financiële instellingen, bijvoorbeeld. Ik denk ook dat de massa die Java heeft nooit zou ontstaan als Java niet in de jaren 1990 was gelanceerd maar als ze er nu pas mee waren gekomen, want nu zou het een stuk minder indrukwekkend zijn dan het toen was. En daaruit kan je weer concluderen dat ook Java voor een flink deel gebruikt blijft worden omdat nou eenmaal de situatie is ontstaan dat het intensief gebruikt wordt. Programmeertalen sterven niet zo makkelijk.

Er zijn inmiddels wel andere ontwikkelingen. WebAssembly is bedacht, zowel voor performance als om taalonafhankelijk te worden. Maar er zijn inmiddels ook heel wat programmeertalen die naar JavaScript vertaald kunnen worden. Dit is een overzicht van meer dan 50 talen (waaronder een hoop obscure):

https://www.slant.co/topics/101/~best-languages-that-compile-to-javascript

Bijvoorbeeld Nim (een taal die ik mezelf nu aan het aanleren ben) vertaalt niet rechtstreeks naar objectcode maar naar C, C++, ObjectiveC of JavaScript, en voor de eerste drie backends kunnen weer verschillende compilers worden gebruikt om er machinetaal van te maken. De JavaScript-backend genereert JavaScript die je rechtstreeks in een webpagina kan gebruiken. Alles wat aan JavaScript-API's en -libraries beschikbaar is in de webpagina is met simpele declaraties toegankelijk te maken in Nim. Dat is niet waar ik Nim voor gebruik, ik heb er wel even mee gespeeld om te kijken hoe dat eigenlijk werkt, en het was opmerkelijk eenvoudig en krachtig. En Nim is dus niet de enige taal waarmee dat kan, ik zie in die lijst bijvoorbeeld ook Ruby, Haskell, Java, C#, Kotlin, en zelfs C en C++ staan. Er is op dat vlak kennelijk heel wat gaande.

Dat soort mogelijkheden stellen programmeurs in staat om in een (voor hun) betere taal te werken zonder dat JavaScript ervoor afgeschaft moet worden. Je krijgt de voordelen van striktere en krachtigere talen zonder dat JavaScript ervoor moet wijken. Als die benadering aanslaat kan dat er weer toe leiden dat JavaScript een hoog gebruiksaandeel blijft behouden in webpagina's, zelfs als programmeurs hun code in een andere taal schrijven, en dus nog heel lang niet afgebouwd kan worden.

Dus wat ik vind van het afvoeren van JavaScript is dat ik niet denk dat we dat op afzienbare termijn gaan meemaken, maar mogelijk wel dat we gaan meemaken dat steeds vaker code in modernere talen geschreven wordt die naar JavaScript omgezet worden.

En je noemt XSS. Dat probleem verdwijnt niet als je JavaScript door iets anders vervangt, dat blijft bestaan zolang het mogelijk is om codefragmenten in welke taal dan ook in een webpagina te injecteren. En die mogelijkheid blijft bestaan zolang we HTML gebruiken voor webpagina's, want elke HTML-source is tekst, en elke referentie aan code die in die pagina moet worden uitgevoerd is dus ook tekst, en dus per definitie een fragmentje in een script-taal; en zo lang dat erin zit is XSS een risico.

Volgens mij zijn er drie verschillende vragen die je kunt stellen:
1. Is JavaScript een goede scripttaal?
2. Is het een goed idee om zomaar code van een vreemde machine op je lokale PC te draaien?
3. Is JavaScript een geschikte taal om (veilig) in een webbrowser te draaien?
En ik heb nog een vierde vraag
4. Wat is er mis met statische webpagina's?

Eerst even de vierde vraag beantwoorden: Niets, statische pagina's zijn prima in staat informatie over te brengen.

Over vraag 1 wil ik niet veel zeggen, JavaScript werkt, maar heeft ook zijn ruwe kanten.

Vraag twee is interessanter: Het is over het algemeen een slecht idee om zomaar remote code te draaien, maar er zijn mensen die zeggen dat zoiets in een goed beschermde zandbak mogelijk moet zijn. Nu blijkt het lastig om een lekdichte zandbak te bouwen; python en java hebben op dat punt de moed al opgegeven. Over de JavaScript zandbakken in browsers is al een aardige lijst aan CVE's verschenen. Het is ronduit problematisch om untrusted code op een veilige manier te draaien.
Dat brengt ons bij vraag drie: mijn mening is dat dat niet aan JavaScript te wijten is; ook het vervangen van JavaScript door een andere programmeertaal zal tot ontsnappingen uit zandbakken leiden.

bron?

Bedankt voor de reacties van achter de 'scripttafel' zogezegd.

Ik ben een JavaScript error hunter en jullie reacties zijn dus erg waardevol.

Tijd om weer eens via Tampermonkey iets te 'frotten'.

We moeten eigenlijk de maker van NoScript, Giorgio Maine, dankbaar zijn, scriptblokkering op die manier zal ook werken tegen nog niet ontdekte bedreigingen.

JavaScript blijft dus nog wel even dus, zeker nog na de nieuwe Google api restricties ;)

luntrus

JavaScript zal uiteindelijk worden vervangen door WebAssembly https://webassembly.org/ / WASM
WASM modules kan je genereren bijna vanuit elke programmeertaal.

Ik ben zelf een fan van Rust en Rust past heel goed in het WASM plaatje.

https://old.reddit.com/r/rust/comments/xk706q/rust_wasm_safe_and_fast_web_development/
YT: https://www.youtube.com/watch?v=P4LMfkFLRsI

L.S.,

Bij gebruik van Javascript bij websites moeten allerlei toegevoegde beveiligingslaagjes er boven op aangebracht worden
om veel narigheid te kunnen voorkomen. Dat in samenspel tussen de website en de achterliggende website server.

Kijk maar eens bij URL-Haus dot com wat er toch allemaal nog voor ellende door komt en daar gerapporteerd wordt.

Ik doel hierbij op o.m. maatregelen als CSP, Secure Cookies, CORS, HTTP->HTTPS, HPKP, HSTS, SR, XCTO, XFO, XXSSP etc. Dat begon zo al vanaf 2015, tegelijkertijd met het begin van het optreden der ransomware dreigingen.
Toevallig allemaal of toch niet zo verbazingwekkend?

Via linten en fuzzen proberen we nog van alles te ondervangen, reguliere expressies enz. kunnen zeer daarbij helpen.
Technische IT derde jaars weten hier al wel weg mee. Maar de praktijk leert het het snelst.

Het topic is door mij gestart n.a.v. dit bericht:
https://devclass.com/2022/08/04/retire_javascript_says-json-creator-douglas-crockford/?td=rt-9cp

Een bericht, waarin ook ergens die 68% wordt aangegeven.

Elders (op The Register) las ik al wel over dit plan, betreffende het totaal willen afvoeren van JavaScript,
maar bij security.nl was het onderwerp door de redactie nog niet aangeroerd. Vandaar.

Dat waren dus mijn overwegingen. Goed dat codeurs erop springen, ik ben maar een website security analistje en foutenjagertje. Maar na decenia lang dit te hebben gedaan, pretendeer ik wel wat inzichten te bezitten.

Wel jammer dat bijvoorbeeld mensen een gelikte hele veilige website laten optuigen en deze later dan niet goed onderhouden. Als je bijv. eens gaat kiijken naar PHP websites met Word Press wat er nog met user enumeration aan en directory listing 'enabled' draait, schrik je je een hoedje.

Ook een scannetje van een Magento-shop website met de scanner van GWillem, magereport doet je af en toe flink schrikken. "De griebels lopen de scripters bij analyse over de grabbels". Pun intended.

Er zou eigenlijk een keuringsdienst voor websites moeten komen om de ergste verschrikkingen uit de Halls of Shame te kunnen exposen en eventueel beboeten.

Overigens is er op deze site ook nog een jquery bibliotheek gevonden om af tekunnen voeren:
bron: retire.js van Erlend Oftedal.
Erlend is overigens een fijne kerel en ik heb hem verschillende keren via mail contact met hem gehad.

Otto.js geeft dit overigens niet aan, als uMatrix voldoende op de security.nl website blokkeert.

Van dit alles dus akte.

Verder allen hier een fijn weekeind en voor diegene, die dat betreft,
eerdaags opnieuw een nieuw, goed, veilig en gezegend script-jaar.

Mazzal,

luntrus

Zoals anderen al opgemerkt hebben: Cobol en Fortran leven nog steeds en ik durf te voorspellen dat ik eerder met pensioen ga dan JavaScript. Sleutelwoord: "User base."

En WebAssembly lost het fundamentele probleem van "sandboxing" niet op. Iedere sandbox zal gaten bevatten waardoor informatie kan lekken, bijvoorbeeld door timing attacks. Wanneer WASM populairder wordt zullen de CVE's voor de WebAssembly sandboxes in grote getale gaan komen...

Ik snap niet wat "af te voeren bibliotheken" doen in deze discussie. Als bibliotheken niet iets zijn wat een gebruiker zelf
op de computer installeert (of als onderdeel van een browser ofzo) maar iets zijn wat een website meelevert bij het
bezoek, dan hebben bibliotheken en hun vermeende (on)veiligheid helemaal geen status in het gehele plaatje.

Of schadelijke code op de pagina zelf zit of in een bibliotheek die als "include" meegenomen wordt dat boeit helemaal niet!
Als code schadelijk kan zijn dan moet dat worden ondervangen in de javascript engine zelf, niet door "bibliotheken af
te voeren"!

Wat ik nog steeds mis is Flash. Ok, er zaten te veel onveiligheden in. Maar je kon er veeeeel mooiere dingen mee maken dan tegenwoordig met die javascript en css. En zonder dat er de hele tijd je layout van heen en weer sprong, omdat er weer zo een adsense banner niet snel genoeg doorkwam. Of een ander ergens anders gehost script ellende bestand wat laat was met de post. Hoe vaak ik daardoor op dingen heb zitten klikken waar ik helemaal niet op wou klikken! Wat een irritante technologie, door al die irritante techneuten en security puriteinen.

We maken sites voor de gebruikers. Ik wil bezig zijn als maker met wat ik maken wil. Het is maar behelpen en aanklooien met wat er nu is.

Eerlijk gezegd heb ik nog nooit naar Python gekeken. Als dat ook weer van die magere designs is met epileptische paginaweergave, hou het dan maar. Of ik moet me vergissen. Dat kan natuurlijk ook.

Het was van een commerciële leverancier en die heeft besloten ermee te stoppen. Dan houdt het op.

Python is niet ontwikkeld als taal voor gebruik in webpagina's. Het kan wel, als je door de nodige hoepels springt, als ik het goed heb begrepen, maar je moet niet denken dat als je Python installeert je opeens een alternatief voor JavaScript of voor Flash in handen hebt.

Afgaande op de link die je plaatste is het geen plan maar de opmerking dat het het beste is dat we zouden kunnen doen, als antwoord op een vraag in een interview. Het is een uitgesproken gedachte, een idee. Dat is nog lang geen plan, en het is afwachten of hier een plan uit gaat ontstaan. Het is niet zo gek dat de redactie het geen nieuwswaarde vindt hebben.

Dus problemen met bootstrap.js, jquery.js en dus alles wat retire.js aangeeft om af te serveren
of via otto.js o.m. aangegeven om te mitigeren is niet nieuwswaardig.

Dan wil je dus het thema dat de huidige JavaScript usance feitelijke vooruitgang (zeker op het terrein van script-security) hindert, niet ter sprake stellen noch brengen. Want wat boeit dat iemand, niet nieuwswaardig.
Waarom brengt The Register het dan wel als nieuws-item? Dan heeft error-hunten en pentesten ook geen zin.

Waarom ontwikkelde Giorgio Maone dan zijn NoScript extensie?

Het lijkt de regering wel, spaakje in het geprefereerde narratief en we lopen allemaal verontwaardig weg.
Is dat de nieuwe algemene arrogante attitude? Ik blijf wel op "de kleine scriptsteentjes lopen, hoor".

Draai de quick source viewer eens ergens, samen met Ctrl+Shift+I. Of lees je in by stackoverflow.
OK, het boeit de heren niet, de eindgebruikers moeten sluimerend verder script consumeren.

Dan dacht F.R.A.V.I.A. daar destijds toch anders over, maar resource engineering wordt tegenwoordig als misdaad gezien.

JavaScript is een voedingsbodem voor een oneindige hoeveelheid bloat en ellende van het huidige web, afvoeren liever vandaag dan morgen.
Als je ziet wat voor een commercieel gedreven centrale braaksels het web domineert en zodoende 'inspireert' naar een verdere afgrond van ellende, gaat JavaScript in vele onnodige implementaties daar van nog wel even tot essentie verheven blijven. Of browsers moeten dit met een ultimatum naar de grond brengen.

Uitzonderingen daargelaten is het los gezien van de content blijkbaar noodzaak Megabytes aan 3rd party zooi binnen te moeten harken voor een poging een paar luttele alinea's tekst te verminken(zo niet te onthouden van browser functionaliteit wat hoe dan ook is te omzeilen) en/of de gegevens van de bezoeker te verkopen wat toont het het web te zijn geworden, niet een concrete informatie verstrekking voor vermaak kennisvergaring of interactie.

Hoe meer zooi er om de content heen gebakken wordt(ongeacht de intenties) des te ellendiger wordt de ervaring omdat het uit draait tot afhankelijkheden die veelal onnodige complexiteit met zich mee brengen die de bezoeker geen keuze laat(grondslag voor hinder, of dit nou met lokaal noodzakelijk geworden privacy beleid van de cliënt botst of met mogelijke handicap van de bezoeker te maken heeft), voor veelal die paar alinea's tekst met een plaatje.


Niet ter vervanging, maar mochten mensen het gedrocht van een hopeloos verminkte HTTP web even helemaal zat zijn, kun je op "the small internet" aardig vertoeven, bijv. d.m.v protocollen als Gemini, waar het draait om de content, niet de shit show er omheen! Want geen JavaScript, geen Cookies, geen CSS, standaard TLS, en je bepaalt zelf d.m.v browserkeuze de opmaak van de tekstuele content, wat als bijkomstigheid natuurlijkerwijs de toegankelijkheid van de pagina's ten goede komt.

https://gemini.circumlunar.space/ (via gem/http proxy)
Gemini browsers als het populaire Lagrange (CLI/Desktop browser), zullen ook media als afbeeldingen/audio verwerken.

Afgelopen zomer nog hier op MCH2022
https://media.ccc.de/v/mch2022-83-rocking-the-web-bloat-modern-gopher-gemini-and-the-small-internet#l=eng&t=1417

Webrings afstruinen of Zoekmachine?
=> gemini://geminispace.info
Wat koken we vanavond? MOAR (Massive Online Archive of Recipes), uiteraard een SQLite snapshot van te downloaden, want waarom zou je iemand voor verder dan voorzien een totaal onbruikbare frontend implementatie van een DB opleggen als daar geen reden voor is.
=> gopher://tilde.pink:70/1/~bencollver/recipes/by-region/

Bedankt voor je reactie, anoniem van 14:46,

Het boeit toch kennelijk nog een paar puristen wel degelijk, deze geopperde gedachte.
De doorsnee conformist heeft de wereld nog nooit echt vooruitgeholpen, toch?

We gaan hier eens induiken en geven dan onze bevindingen weer.

Al blij met NoScript, zodat ik eventueel een browser met script eventueel tijdelijk kan vertrouwen.
Maar ja dan zit je wel zo af en toe te toggelen en omdat de extensie verlaten werd, gaat het op uMatrix niet meer.

Zal wat leuks worden met die afgeknepen nieuwe Manifest V3 api conforme extensies op Google Chrome en chromium-achtigen. De eindgebruikers komen straks om in de ads en de tracking, vanwege "vested interests of Big Tech", lees Alphabet (Google dus).

groetjes,

luntrus

Nou maak je er iets heel anders van dan ik schreef. Het punt dat ik maakte is dat in de link die je plaatste er helemaal geen plan wordt gepresenteerd maar gewoon wordt gezegd: eigenlijk zouden we moeten... En zo'n opmerking heeft inderdaad niet veel nieuwswaarde. Als dit een serieus voorstel wordt en uitgewerkt wordt tot een serieus plan dan wordt het allemaal veel concreter en nieuwswaardiger.

Zou je een link naar dat artikel in The Register willen plaatsen? Dan hebben we iets om over mee te praten. Ik heb geprobeerd het te vinden maar vond het niet. Als je niet de moeite neemt ernaar te linken moet je niet verwachten dat mensen het een overtuigend argument vinden.

En nu we het toch over ontbrekende verwijzingen hebben: zou je als je op iemand reageert even de moeite willen nemen om het tekstfragment waarop je reageert te citeren? Daar is de quote-tag voor. Dat is echt heel veel duidelijker dan in een forum een antwoord geven en het aan de lezer over te laten om uit te zoeken op welke andere reactie je eigenlijk reageert. Alvast bedankt.

Dat is niet volledig juist, met enkele lijnen code heb je een server die luistert op poort 80 of gelijk welke andere.
met enkele libs heb je mooiere paginas . Nu als je javascript die toch eerder beperkt is zou vervangen door python om client side ook te draaien is het hek van de dam.De mogelijke gevaren bij javascript ten op zichte van pyhon is pyton*100 gevaarlijkere taal omdat veel mogelijk is.

Tja dat elke website https diende te worden voor het grote gevaar kan je beter chrome niet gebruiken dan http waar geen inlog is omdat het een basis site is. Google is vergane glorie maar dat weten zij zelf nog niet.Het bewijs dat amazon deze speler voorbij stak.Google dringt de scholen binnen en ondergraaft de democratie op linke wijze.

Snap je dat echt niet?
Die libraries dat is gewoon een stukje sourcecode wat included wordt door de browser. Daar staat gewoon javascript
in net als de stukjes code die de websitemaker zelf gemaakt heeft. Als zo'n library iets kan wat gevaarlijk is dan kan
na het afvoeren van die library nog steeds iedereen dat gewoon doen.
Als je iets veiliger wilt maken heeft het geen zin om een library af te voeren, je moet dan in de taal zelf zijn.
Bijvoorbeeld de functie eval() schrappen uit de taal of er een streng beveiligingshek omheen zetten (dat het alleen in
lokaal geinstalleerde scripts mag voorkomen ofzo) en dan die libraries aanpassen dat ze geen eval meer nodig hebben.

Precies hetzelfde geld voor talen als PHP, waar ook die EVIL functie eval() in zit, de bron van heel veel ellende in
pakketten als wordpress en plugins daarvoor. Je kunt wel security updates BLIJVEN installeren, de lekken en de
backdoors blijven maar terugkomen. Een uitschakelbare eval() zou dat veel beter oplossen, en dan gaan die mensen
maar wat betere software maken. json parsen met eval() (in javascript) dat moet je gewoon niet willen.

ls dat zo zou zijn als je zegt, waarom is er dan retire.js ontworpen door Erlend Oftedal en waarom gebruikt men dan Snyk?

Natuurlijk moeten we waken tegen "de knip-en-plak-geest". Veelal is er voor uitgenreid linten, hinten en fuzzen geen tijd.

Tijddruk en de manager, die "lean"moet werken. Het is belangrijker dat hij blijk ervan geeft "super-gliding-woke" te zijn.
En dan zit natuurlijk de rekening van deze verontachtzaming onder in de zak en heeft de eindgebruiker de lusten, maar ook de lasten van e.e.a. Security blijft een last-resort-item.

Trouwens hoe zie je dat dan bij hele complexe website toepassingen en bij het website onderhoud door lieden, die niet of onvoldoende op de hoogte zijn. Er is nog steeds geen Dienst voor Website-Onderhoud zo'n beetje als de Dienst voor het Wegverkeer. Hoeveel websites zouden eigenlijk van Interwebz gesleept kunnen worden als ondeugdelijk en gevaarlijk?

is deprecated, wanneer is eval niet gevaarlijk?

Lees https://stackoverflow.com/questions/197769/when-is-javascripts-eval-not-evil

Alleen dus als je beseft waarin het gevaar gelegen is en waarom.

Als ik voor de onderhavige website met Hints kijk in Developer Console,
zie ik 40 waarchuwingen betreffende Disallowed HTTP Headers,
1 waarschuwing voor een af te voeren jQuery library (met 6 kwetsbaarheden, zie snyk voor bijzonderheden)
24 waarschuwingen betreffende use 'X-Content-Type-options'.
Vulners geeft er 4. De website hier heeft slechts content en er wordt niets geblokkeerd derhalve.

Waarvan akte,

luntrus

Je praat lekker hip maar ik krijg sterk de indruk dat je knip-en-plak kennis hebt in plaats van inzicht in de materie...

Ik zou een 14 jaar oud topic niet als basis gebruiken voor een dergelijke discussie. In die tijd zijn de inzichten wel veranderd!

Wat mij opvalt, is dat vrijwel overal mensen in eerste instantie emotioneel reageren.

Hoe men zo ver is gebracht, weet ik niet. Het gaat niet meer primair om de inhoud, maar hoe voel ik me hierbij. Ook het op de persoon gaan spelen, is daar een onderdeel van.

Je moet het goed onderzoeken om het te herkennen, want anders ga je er gemakkelijk in mee. Dus waarom niet waarom Babel beter werkt als JS.

https://xkcd.com/386/ ;-)

@luntrus: heb je die link naar het artikel in The Register waar je aan refereert nog kunnen vinden?

Er worden ook nog mooie zaken ontwikkeld, zoals Turnstile, een gebruikersvriendelijke, privacy-besparende oplossing bij captcha's: https://challenges.cloudflare.com/turnstile/v0/7e70c3d1/api.js

De genoemde link was niet van The Register, maar kwam van https://devclass.com en was van 04.08.2022 en de uitspraak was van JSON ontwikkelaar Douglas Crockford., omdat deze vond dat JavaScript vooruitgang zou gaan hinderen.

Een javascript bibliotheek werd geupdate om files van Russische computers te kunnen wipen, via een kwetsbaarheid, bekend als CVE-2022-23812, nieuws dat The Register wel degelijk bracht.

Ieder mag er het zijne van denken,

luntrus

Ja, die link had je al geplaatst, en je vermeldde erbij dat je al op The Register over dit "plan" had gelezen.

Een kwetsbaarheid is geen plan om JavaScript totaal af te voeren. En je laat alweer na een link te plaatsen.

En ook om even te citeren waar je op reageert. Gewoon op "Reageer met quote" drukken, en dan (zeker als het citaat lang is) even weghalen waar je niet op reageert. Het is niet moeilijk.

Ik begin te denken dat The Register helemaal niet over dat plan dat je meende te zien heeft bericht en dat je er nu een beetje vaag omheen probeert te draaien. Je kan ook gewoon zeggen: "oeps, ik had me vergist", weet je? Je lijkt een behoorlijke moeite te hebben met concreet en duidelijk zijn.

Is er een open discussie mogelijk of niet? Moeten er voorwaarden worden gesteld? Brendan Reich en Crockfotd zeggen dat het slechte van JavaScript gebleven is en het betere zelfs nog beter is geworden. Verder gaan of over naar Python?

Ik wil liever horen wat hier substantieel van het beweerde klopt of niet. Moeten bijvoorbeeld allemaal niet bij 0 gaan tellen i.p.v. bij 0 of 1?

Zijn het 'invested interests' dat bij een discussie men direct je op de nek vliegt. Waarom niet, ja dat vind ik ook, vanwege... of daar ben ik het niet mee eens, vanwege zus en zo. Node.js heeft een specifieke positie geeft Crockford zelf aan.

Er zijn ook specifieke bibliotheken die veel meer problemen kennen dan andere. Het is vaak niet de taal, doch ook het gebruik ervan.

De link bij The Register heb ik nog niet teruggevonden. Ik ben ook maar een mens als error-hunter en dus een feilbaar persoon. (my bad).

luntrus

Moet zijn Brendan Eich natuurlijk, slip of the spell checker.

Merk op dat ik geen inhoudelijke voorwaarden aan stelde maar je vroeg om concreet en duidelijk te zijn. Ik denk dat een open discussie daar juist zeer bij gebaat is.

Als onderdeel van de discussie vroeg ik op welk Register-artikel je je eigenlijk baseerde, want waar je wel naar linkte bevatte het plan niet waar je het over hebt, alleen een uitgesproken gedachte. In plaats van tot de discussie bij te dragen door die te geven ging je nogal ontwijkend doen. In plaats van mijn reactie daarop als "vested interests" op te vatten zou je tot je door kunnen laten dringen dat dit kritiek is op de manier waarop je de discussie voert en een poging je uit te dagen duidelijk en concreet te worden, zodat er een inhoudelijke discussie is en niet alleen maar wat vaag geouwehoer in de ruimte.

Dank je, nu ben je concreet. Ik hoop dat je hem nog terugvindt en op deze pagina plaatst, want als er inderdaad plannen worden gemaakt om JavaScript door iets anders te vervangen dan ben ik best benieuwd naar wat daar gaande is.

———

Ter lering en vermaak: zie je hoe ik drie delen van je reactie citeer en bij elk deel apart mijn reactie erop geef? Dat doe ik opdat duidelijk is waar elk deel van mijn reactie betrekking op heeft. Dat is veel duidelijker dan wanneer ik, zoals jij vaak doet, zonder enige context aan te geven maar zou gaan schrijven.

Wat ik doe is niets nieuws, dit is conform adviezen die al tientallen jaren gegeven worden voor hoe je duidelijk reageert. Die adviezen zijn ouder dan het world wide web en stammen uit een tijd dat usenet en e-mail grotendeels door academici werden gebruikt die precies en duidelijk wilden zijn in de discussies die ze voerden.

Voorwaarden om een goede discussie te kunnen voeren zijn voorwaarden die in mijn ogen navolging verdienen, het zijn voorwaarden die vrijheid niet beperken maar hem juist vergroten omdat vrijheid goede kennisoverdracht nodig heeft en misverstanden kan missen als kiespijn. Dat is niet de vrijheid om je in vaagheden en misinterpretaties te wentelen maar de veel grotere vrijheid om inzichten op te doen en te delen en zo met zijn allen wijzer te worden. Dat is het soort vrijheid waar vrije meningsuiting zijn waarde aan ontleent. Die vrijheid is gebaat bij de duidelijkheid waar ik je om vroeg.

Ik denk dat het helemaal niet boeit welke taal je gebruikt. De belangrijkste risico's ontstaan door het feit dat je code
uitvoert op het apparaat van de gebruiker die aangeboden wordt vanaf een webserver. Of dat nou Visual Basic of Java of
Javascript of Python is dat verandert niks aan het eigenlijke probleem.

Dank voor al jullie commentaar en ik ben niet eigenwijs, dus ga ik de balans voorzichtig opmaken.

We moeten dan tot de conclusie komen dat de voordelen van JavaScript tot dus verre en wellicht nog geruime tijd ruim opwegen tegen de nadelen (met een paar kanttekeningen uit de praktijk rond website-beveiliging *).

Voordelen zijn o.a. snelheid, eenvoud, zeker ook populariteit en marktaandeel, interoperabiliteit, zorgt voor een verminderde belasting van de (achterliggende) server (ook in de cloud), kent een rijke interface, uitgebreide functionaliteit, is veelzijdig, wordt van de nodige updates voorzien.

Bij de nadelen noemen we client side afhankelijkheid, problemen rond browser ondersteuning. Hierboven werd dit ook reeds door reactanten aangeroerd.

* Waar men wel tegenaan kan lopen is problemen door slecht onderhoud o.a. bij websites. De gelikte website wordt vaak uit valse bezuinigingsoverwegingen of vanwege onwetendheid niet voldoende geupdate, ja ook qua JavaScript bibliotheek versies ontstaan mogelijkheden tot abuse.

Maar dat valt dus de ontwerpers van scripts en de professionele ontwikkelaars van websites niet te verwijten.

Een oorzaak kan zijn dat de eindverantwoordelijken geloven in zogeheten "lean" management, een verkeerde vorm van bezuinigen. En dan blijkt de rekening steeds onder in de zak te zitten en schrikt men hiervoor pas wakker als het goed mis gaat en de website kwetsbaar is gebleken of echt is omgevallen, overgenomen en noem maar op.

Bedankt iedereen voor de kritische kanttekeningen, hierna ga ik met dubbele energie verder met retire.js, webpage behaviour reports, otto.js, hint de onvermijdelijke look-ups via Ctrl+Shift+I.

luntrus

@luntrus 22:27:

Het grote beveiligingsvoordeel van cliënt-side code voor de gebruikers van deze code (website bouwers en beheersers) is dat de server geen last heeft van de beveiligingsgaten in de cliënt code, de nare gevolgen zijn voornamelijk voor de bezoekers van de website. Een goedkope oplossing voor de website(-wan-)beheerders.
Ik laat het bij deze cynische constatering, wil hier de discussie over winstmaximalisatie en lasten afschuiven op de maatschappij niet voeren.

Ja lekker cynisch maar ook zo totaal fout.
De reden om client-side code te draaien is niet wat je daar schrijft, maar om de gebruiker client-side functionaliteit te
bieden. Die was er niet in de tijd dat alle webpagina's nog statisch waren en de gebruiker op een link moest klikken
of een form moest submitten en dan weer wachten op het antwoord van de server daarop.
De gebruikers (behalve een groepje hier dan) wilden dat graag anders zien en daarvoor was er client-side code
nodig. Eerst in Visual Basic en Java, daarna in Flash, daarna in Javascript.
Niet als goedkope oplossing (want het ontwikkelen van die code kostte zeker meer geld dan statische pagina's) maar
om de gebruikers functionaliteit te bieden.

Wie maken er hier allemaal gebruik van subresource integriteitshashes?

TLS kan wel garanderen dat een connectie tussen browser en server veilig is,
maar de resource zelf kan door een aanvaller worden aangepast en wel aan de serverkant.

Maak dan gebruik van een SRI Hash Generator. https://www.srihash.org/ #app
Dan weet men, dat men in ieder geval met de code van de real McCoy te doen heeft.

@ anoniem van 19:37 heden, dank voor je waardevolle info.

De discussie, die men niet wil voeren, gaat echter wel over een van de hoofd-oorzaken van een groot gedeelte van de website onveiligheid online. Ik zie overigens ook niet hoe zo'n grondhouding (snel) veranderd zou moeten worden.

Een cursusje naast hun management- en business-opleiding zal daar wel geen verandering in kunnen brengen, vrees ik.
Van Big Tech zal in ieder geval dit fundamentele initiatief niet uitgaan, daar waar het dwars staat op hun giga-verdienmodel.
Maar met initiatieven als https-only, virustotal, header security e.d. laten ze het zeker ook niet helemaal liggen.

Zeker niet en er zijn ook browser-ontwikkelaars, die hun best doen bij het bestrijden van althans een flink gedeelte van de overkill aan dat-tracking, -fingerprinting e.d. Dus de geinteresseerde eindgebruiker zou eigenlijk beter moeten weten, hoe niet alle private data gelijk het browser raam hoeven uit te vliegen. Maar ik geef toe het wordt hen steeds ongemakkelijker gemaakt.

Om de haverklap zie ik een update van de nieuwste beta definities van de Adguard extensie in de browser en dat scheelt wel een "slok op een ad- en tracking-borrel".

Mijn persoonlijke situatie heeft het voordeel dat ik inmiddels een leeftijd bereikt heb, waar ik me niet meer druk hoef te maken over de private mening van een baas of manager of de company-policies. Ook in adviserende rol doe ik dat nog niet en blijf het liefst bij een onafhankelijke mening (zoals dat een vrije burger in het redelijke betaamt, dat weer wel natuurlijk).

Ben o.a. benieuwd naar de voorstellen van iemand als een Mike Shema in die richting. O.a. t.a.v. de komende restrictieve blokkering-extensie voorstellen van Google voor in Chrome en chromium-achtige browsers.

"When the going gets narrow, keep an eye on the sparrow".

luntrus

Begrijpend lezen is lastig, dat weet ik.
Ik weet dat client side scripting (zoals JavaScript) extra functionaliteit biedt, die zowel "goed" als "fout" gebruikt kan worden. Ik irriteer me aan sites die traag laden omdat JavaScript eerst alle elementen moet laden en dan de layout moet doen. Geef mij maar een statische startpagina.
Zijn het echt de eindgebruikers (lezers) die daarom vragen of wordt dat voor de gebruikers besloten door de aanbieders? Hebben deze eindgebruikers voldoende kennis van computerbeveiliging om weloverwogen voor- en nadelen te kunnen afwegen?