Je hebt een wat raar beeld van de IT werkelijkheid.

Je denkt dat ze daar een dev/design meeting hebben en zitten te overleggen "nou, John, codeer jij een 404 hier als je een scriptloze gezien hebt want dan worden ze wel bang en zetten ze scripts aan" .
En dan maar turen in de logs of ze je al te pakken hebben, en een rondje voor het team als ze weer een scriptloze naar de scrips gepest hebben .

Zo werkt dat echt niet .

Ze kiezen alleen voor het stoppen met testen van scriptloos gebruik, en stoppen met requirements 'moet ook werken zonder scripts'.
Zo'n 404 is dan gewoon een gevolg wat ze niet kan schelen - dat het wel, of half, of niet werkt als je doorklikt .
Het is geen supported omgeving meer , en wat er dan half kapot of zichtbaar (404 ) niet meer helemaal werkt - Het Maakt Niet Uit - voor hen.

Gewoon _unsupported_ - precies dat , het kan nog steeds werken, het kan half werken, het kan kapot zijn : dat is wanneer een leverancier geen moeite meer doet voor een bepaalde situatie/model/client .

Ze zouden in principe de hele dienst kunnen blokkeren als een client een bepaalde check niet haalt, maar waarschijnlijk hebben ze daar meer last (of risico) van dan gewoon geen moeite doen om het nog perfect werkend te houden zonder scripts.
Google heeft het voordeel dat ze voor dit soort dingen geen directe klanten hebben die kosten maken door een helpdesk bezig te houden .

Gegarandeerd zullen daar (en overal) wel een hoop devs gejuiched hebben bij de boodschap "IE6 hoeft niet meer supported te worden" - gewoon omdat het supporten daarvan onzettend veel werk kostte. Waarschijnlijk ook een feetje zelfs bij Microsoft toen het licht uitgedaan mocht worden op IE6.
Als developer heb je gewoon meer werkplezier als je met technisch "goed gereedschap" kunt werken , en lieft ook iets wat op de een of andere manier belangrijk is - zoals een dienst waar veel klanten op zitten.

En wat is er mis met scripts? Om in te loggen gebruiken veel websites JS om je wachtwoord gehashed en gesalten naar de server te sturen. Dan is de inlog zelfs over een http verbinding redelijk beveiligd. Met alleen html code zijn dit soort beveiligingen veel lastiger in te bouwen. Zonder JS zul je dat waarschijnlijk in plain tekst moeten doen.

Op een bepaald moment zijn er zo weinig html-only gebruikers dat je geen tijd meer wilt stoppen in een slecht uitziende pagina weergave.

Zoals andere al aangeven:
JavaScript is soms gewoon nodig

Beste anoniem van 12:36 uur,

Je schrijft: Het is geen supported omgeving meer. Maar dat is niet zo. Eenvoudige html wordt nog steeds volledig en totaal zonder haken en ogen door Google's Gmail ondersteund.
Dus ik snap niet hoe jij zo kan stellen dat deze support deels of misschien wellicht geheel aan het uitvallen is
Hoe heb jij dat geconstateerd?
Bovendien, je kunt eenvoudig testen door eenmaal ingelogd - dan wel in uitgebreide weergave; dus met alle script tierelantijnen en franje :-) naar een Google support-pagina te gaan en daar te kiezen voor eenvoudige html, (1) en dan zien, mits je Gmail van heel vroeg kent - zoals ik - dat alles al vele jaren onveranderd en geheel functioneel is en niets in de layout is veranderd. Sterker: in mijn herinnering ziet het er daar precies zo uit als toen ik ruim 16 jaar geleden voor de eerste keer Gmail gebruikte, uitgezonderd de labelfunctie die later om en nabij 2007 werd toegevoegd.

Het wordt alleen steeds moeilijker automatisch in die eenvoudige html weergave terecht te komen na validatie van je inlog door Google, zoals dat voorheen zonder extra interventie lukte na eenmaal zo te hebben ingesteld al jaren geleden, ik dacht rond 2012. Tot voor enkele weken terug dus, zoals ik al schreef, lukte dat probleemloos zonder omslachtigheid die nu wel nodig is en dat valt mij op.

(1)
Het heeft geen zin die URL hier te posten want die kun je alleen oproepen als je ingelogd bent, maar dan zou je zelf precies kunnen constateren wat ik bedoel.

Wel duh, uit jouw verhaal dat er dingen niet meer werkten, en dat je speciaal bang gemaakt werd met 404 halverwege en zo slim was door te klikken want ze hebben jou nog steeds niet te pakken.

Ze zijn gestopt met moeite doen om alles 'glad en zonder zichtbare fouten' met scriptloos html te laten werken, blijkbaar .

Jij ziet er een bewuste sturing in, en ik zie alleen maar 'gestopt met (extra) moeite doen voor scriptloos html' .

Die sites doen dat dan fout.

Attack: pass the hash (een passieve afluisteraar kan daarmee opnieuw inloggen zonder jouw wachtwoord te kennen of te hoeven "kraken"). Maar sowieso kan een actieve MitM dan in de huidige sessie alles doen wat jij kan. En het session-cookie blijven gebruiken als jij denkt dat je bent uitgelogd. Bovendien kan een MitM de door de server verzonden Javascript hashfunctie eruitslopen en zo jouw plain-text wachtwoord in handen krijgen.

Ten slotte zou je iets als Argon2 of PBKDF2 moeten gebruiken, maar als je dat soort bewust "langzame" (resource intensive) algoritmes in Javascript implementeert (uitgevoerd door browsers) wordt dat extreem traag.

Je zou "vóór-hashen" in browsers kunnen overwegen, maar dat is niet zonder risico's (zie "Pre-Hashing Passwords" in https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html). En feitelijk schiet je er niks mee op, want een onverhoopte MitM (bijv. een phishing site met een lijkt-op domeinnaam), en wellicht een hacker van de echte server, kan die Javascript functie verplaatsen naar server-side en zo toch jouw plain-text wachtwoord in handen krijgen - zonder dat je er iets van hoeft te merken.

Ohnee wat vervelend.

Wat heeft dit te maken met security? Helemaal niks.

Naar mijn mening is er wel degelijk security verband en is mijn hoofdreden om net als TS zonder javascript gmail (en andere mail) te gebruiken. Gebruik ik webmail met javascript geactiveerd dan biedt dat via rotte mailcontent (meer) mogelijkheden.
Daarnaast is mailclient en mailcontent veel rustgevender zonder alle poespas javascript.
Mijn jaren geleden begonnen werkwijze en ervarene met gmail komen overeen met die van TS.

Ha Anoniem, je verhaal klinkt plausibel. Dat gezegd hebbende, Het lijkt er op (https://support.google.com/mail/answer/15049?hl=en) dat HTML View gewoon nog ondersteund wordt.

"Bovendien, je kunt eenvoudig testen door eenmaal ingelogd "

Nou, submit een bugreport, fixen ze het. Ze zullen het niet lezen op dit forum in ieder geval en die dev die ergens een typo heeft gemaakt zal het waarschijnlijk nu niet weten, anders was het niet in productie gekomen.

Ik had niet voor niets het woord 'redelijk' in mijn bewering gezet. Het beschermt tegen de veel afluisteraars, niet tegen professionals.
Maar het ging mij vooral om het idee dat JS ook ingezet kan worden om een verbinding juist te beveiligen omdat je veel complexere opdrachten kunt schrijven dan in html alleen.

Herkenbaar verhaal, lay-out van Gmail was zo waardeloos geworden dat je wel html moest gebruiken. Haal Gmail op via pop3 en sporadisch log ik in om de spam te checken, kan goed alweer jaar geleden zijn.
Nog wel, met de kennis van nu gaat Gmail de deur uit. Proton veel prettiger, betaal er zelfs voor. Dat doe ik niet snel.

Goed dat je scripts blokt, zou iedereen moeten doen. uMatrix kun je eenmalig instellen dat deze overal scripts (en meer) blokt. Dan per site eventueel (tijdelijk) toestaan. Gros werkt prima zonder.

Mee eens javascript is een zwarte vlek op beveiliging.
Maar veel mail content van mails is even slecht of onveilig . zoals het virus in haatbook afbeelding

Hier TS,

Precies. Dat zeg ik ook.
En het lijkt er niet op.
Het is gewoon zo.

Raar dat daarover zo'n twijfel heerst in dit topic van mij. Ik ben dan misschien wel een IT dumbo maar ook weer geen digibeet. ;-)

Hier het bewijs. Mijn geanonimiseerde Gmailbox:

https://i.postimg.cc/VNc4PxC0/Gmailbox.jpg


p.s. De omgekeerde kleurweergave wordt veroorzaakt door de Extensie: Dark Reader

Ik vermoed dat Google best problemen wil oplossen met html-only; die versie wordt namelijk ook aangeboden, als je een extreem trage verbinding hebt.

Het is verwonderlijk dat de google deepstate het levensbeloop van de topicstarter nog niet gescript neeft naar een een perpetual "doen of doem" scenario van blinde obedience...

Disclaimer. Deze reactie is humor en niet gebaseerd op werkelijkheid.


Of niet ;)

Very dark.... ;)