'Spellingscontrole Chrome en Edge stuurt gevoelige inlogdata door naar servers'

De geavanceerde spellingscontrole van Chrome en Edge kan ervoor zorgen dat gevoelige data naar de servers van respectievelijk Google en Microsoft doorgestuurd wordt. Vooral in het geval van inlogformulieren is dit ongewenst, al kunnen ontwikkelaars dit vrij eenvoudig voorkomen.

In beide browsers kunnen gebruikers kiezen tussen een basale en geavanceerde spellingscontrolefunctie en in dat laatste geval wordt alle zichtbare tekst doorgestuurd naar servers van de betreffende bedrijven, zo ontdekken onderzoekers van otto-js. Spellcheck data ChromeTekst wordt in dergelijke gevallen centraal door algoritmes gecontroleerd op spel- en taalfouten. In Chrome heet deze functie Uitgebreide spellingscontrole. In Edge heet dezelfde functie Microsoft Editor. Vorig jaar waarschuwde een privacyexpert in een interview met Tweakers al voor deze functie.

De onderzoekers ontdekten dat in principe alle zichtbare tekst bij een dergelijke spellingscontrole doorgestuurd wordt voor verwerking, wat voor velen geen verrassing zal zijn. Maar daaronder vallen naast generieke teksten, bankgegevens en e-mailadressen dus ook eventueel wachtwoorden wanneer de 'toon wachtwoord'-functie op een inlogpagina gebruikt wordt.

De onderzoekers benadrukken dat het niet duidelijk is in hoeverre de geavanceerde spellingscontrole daarentegen een eventueel extra privacyrisico met zich meebrengt. "Het is niet duidelijk of de data opgeslagen wordt. (...) Het is ook onduidelijk of de data met dezelfde beveiligingsoverwegingen behandeld wordt als welbekende gevoelige data zoals wachtwoorden, of bijvoorbeeld door een productteam als metadata voor het verbeteren van algoritmes."

Het zou voor websitemakers hoe dan ook vrij eenvoudig zijn om de informatiestroom van gevoelige data naar servers van Google of Microsoft te voorkomen. Door de mogelijkheid op spellingscontrole op gevoelige velden uit te schakelen met de html-code spellcheck=false zou het probleem opgelost zijn.

Door Yannick Spinner

Redacteur

19-09-2022 • 20:42

142

Submitter: TheVivaldi

Reacties (142)

142
139
64
3
0
50
Wijzig sortering
Dat klopt.

Zoals bij het aanzetten van deze opt-in feature staat:
Enhanced spell check
Uses the same spell checker that’s used in Google search. Text you type in the browser is sent to Google.
Als je je wachtwoord veld geen wachtwoordveld meer maakt (door bijvoorbeeld je eigen logica te gebruiken om het wachtwoord te tonen) dan is het niet gek dat de browser dat opneemt in je spelchecker, nee. Ook extensies als Grammarly zullen dit doen.
Ze zouden simpel een check kunnen doen of de inhoud van een normale input gelijk is aan de inhoud van een veld dat voorheen een password input was en in dat geval het veld alsnog niet meenemen in de spellingscontrole.
Dat is niet te doen met de wildgroei aan JS oplossingen. Dan zou de browser moeten zien dat een veld pixel-precies op een plek staat waar eerst een <input type="password> stond en dan niets doorsturen. Als de opmaak van de <input type="text"> dan ook maar een beetje verschilt loopt dit mis. Dat is niet robuust te krijgen.
Nee hoor dit is vrij eenvoudig te doen.
Oplossing in:
- Zet een input type veld eroverheen met absolute positioning en een z-order
- Vervang het veld door een ander veld (element.innerHtml=...)
- Zet het paswoord veld op hidden en het text-veld (wal in de dom-tree stond) op enabled
- Pas het input-type van de bestaande <input aan
- Doe kinky CSS dingen met classes aanpassen en een overlay te genereren
- .... (nog 400 creative manieren om dit te doen)

Als jij een oplossing weet die in alle gevallen werkt (ook met de opmerking: de text-input is net iets anders gestyled dan een password input) dan ben je meer dan geniaal.
spellcheck=false zoals in het artikel staat?
Wat dacht je van runtime vervangen van password met text met een matchend id? Kan de browser ze prima linken, verder gewoon het spellcheck attribute inderdaad.
Mijn punt is dat er geen standaard werkwijze is voor dat oogje, dus de browser kan het niet detecteren. Als iedereen op dezelfde wijze zou werken wel, maar dat is niet de realiteit.
Een browser kan prima een aantal oplossingen combineren. Kijk naar een lijst met namen, hashes en ids en je vangt het meeste af.
Als het zo eenvoudig is, dan kun je vast wel even een voorbeeld geven van hoe je het dan moet doen...
De vraag was of een browser dat kan en dus een manier kan vinden om inputs die vervangen zijn te linken aan een password input.

Kan prima, bijvoorbeeld op id attribute, of naam. Eerder dat bekend als password? Niet checken.

Je name attribuut zal bijna altijd gelijk zijn want forms dus daar kan je op inhaken.

Verder kan een browser natuurlijk nog kijken naar labels die linken naar de password input en de text input.
Inderdaad, het is heel simpel te doen omdat je niet naar de opmaak moet kijken maar naar de inhoud van het veld. Aangezien er niet veel passwordvelden op een pagina staan kan de browser gewoon bij elke toetsaanslag (een hash van) de laatste waarde opslaan. Elke keer dat er daarna een tekstveld exact dezelfde waarde heeft, markeer je dat intern als "zichtbaar wachtwoordveld" en zorg je dat de vertaalfunctie dat veld over slaat.

Zeker omdat alle Chromium extensies geschreven zijn in JavaScript en daarmee toegang heeft tot de DOM en zich kan registreren voor mutatie-events is dit een makkie.
Wat is een tekstveld?
Wie zegt dat indien je gekozen hebt het wachtwoord veld zichtbaar te maken dat er dan altijd een onderliggend veld gemarkeerd als wachtwoordveld gevuld wordt met de waarde die jij in het zichtbare veld invult?
Hoe groot is jouw DOM en hoe krachtig is de processor van het apparaat waarmee de eindgebruiker jouw site bezoekt?
Moet ik hier met de volledige oplossing komen zoals Google 'm in Chrome zou moeten implementeren?

Zoals gezegd kun je vrij simpel luisteren naar mutaties die doorgevoerd worden in de DOM, waarbij je dus ook kunt achterhalen wanneer een password input wordt verborgen of de waarde van een veld wordt ingevuld. Met die twee dingen weet je dus wanneer 1) een passwordveld wordt verborgen, of 2) het passwordveld misschien zichtbaar blijft, maar de waarde ook in een ander element wordt gebruikt.

https://developer.mozilla.../Web/API/MutationObserver

Proefondervindelijk weet ik dat dit amper geheugen of cpu cycles kost. Ik heb deze techniek gebruikt om "live" gecodeerde teksten te decoderen en vice versa met een chrome extensie, om zo versleutelde communicatie over open kanalen toe te staan.
Je kunt wellicht best eenvoudig ALLE wijzigingen bijhouden en wellicht ook bijhouden wanneer er geschoven wordt met de zichtbaarheid van velden. Het wordt alleen moeilijk om met zekerheid vast te kunnen stellen dat het hier gaat om het zichtbaar maken van de input van een wachtwoord veld, daar er hiervoor zeer veel verschillende implementaties zijn.
Klopt, maar in essentie wordt er een element getoond met daarin dezelfde tekst die eerst in een password veld stond.

In gevallen waar de gebruiker direct omschakelt naar het zichtbare veld, zou de spellingscontrole op kunnen houden op het moment dat je waarschijnlijk een wachtwoord typt, omdat er bijvoorbeeld twee niet-lettertekens in een aaneengesloten woord zitten. Ook niet waterdicht, maar weer een stap verder in de juiste richting.
Een tekstveld is een tekstveld, eerlijk gezegd vind ik dit eerder onverantwoordelijk van de ontwikkelaars die op deze manier tekstvelden misbruiken.

Dat ze <input type="email"/> ook spellchecken vind ik wat vreemd, maar de waarschuwing gaat ook wel veel verder dan alleen ongetypeerde invoervelden (insinueert dat alle tekst die je invoert naar Google gaat, wat ook klopt).
Een tekstveld is een tekstveld, eerlijk gezegd vind ik dit eerder onverantwoordelijk van de ontwikkelaars die op deze manier tekstvelden misbruiken
In een tekstveld kunnen ook andere gevoelige gegevens staan die niet naar MS of Google, en/of niet naar de VS gestuurd moeten / mogen worden...
Op telefoons wordt de spellchecker vaak ook gebruikt voor de auto-complete. Dan hoef ik alleen de eerste paar letters van mijn mailadres in te vullen, om hem te auto-completen.
Men zou een nieuw type veld moeten opnemen in de html standaard.

Een custompassword veld oid. Eentje die niks speciaals doet dan aangeven dat er een pwd in getypt wordt.
Ja of gewoon een ‘toon paswoord’ icoontje standaard in de browser verwerken zodat we/ze niet allerlei eigen oplossingen moeten bedenken op het ‘ongemak’ van de eindgebruiker die het oh zo lastig vind om FleurEnJoris2010! ‘Blind’ te typen 😒
Inderdaad - als ze het zouden opnemen in de HTML5 / W3C standaarden dan zijn we van dit specifieke probleem af.

Ok - uiteraard ben je dan wel aan de vormgeving van de browser gebonden en dat zal deels ook wel de reden zijn dan webdesigners nu ook eigen oplossingen gebruiken.
Niks staat de HTML5 standaard in de weg om het 'toon wachtwoord' icoontje gewoon stylebaar te maken. Sterker nog, dat is ook het idee achter de HTML/CSS scheiding: html richt zich primair op de semantiek van de getoonde elementen (password veld (met attribuut obfuscated ja/nee)) en laat de exacte opmaak over aan browser-default + webdesigner stylesheets.
In plaats van het niet gek te vinden is het eerder andersom: Het lijkt me verwerpelijk dat bedrijven zich er zo heel makkelijk vanaf maken om allerlei gevoelige gegevens te gaan verwerken.

Google en Microsoft horen namelijk als geen ander te weten dat ze niet zomaar persoonlijke gegevens mogen verwerken. Daarbij zijn veel gegevens niet zomaar geschikt om als bedrijven te gaan verwerken omdat het kan. Een password-veld is namelijk geen grens om te bepalen of de gegevens geschikt zijn. Aangezien alle andere tekst en velden net zo goed gevoelige gegevens kan bevatten, zoals van personen en bedrijven waar de gebruiker die de opt-in heeft gekozen niet zomaar de beslisser over kan zijn.

Het enige redelijke lijkt me dat Google, Microsoft, en al die andere bedrijven die graag gegevens van anderen verwerken expliciet toestemming hebben van de verantwoordelijken, of op zijn minst de persoon die graag van die diensten gebruik maakt. En dus dat het niet met een te simpele opt-in allemaal maar kan, maar dat de gebruiker per keer vooraf heel duidelijk beslist wat die naar Google, Microsoft enz gaat sturen en duidelijk beslist om wat voor soort gegevens het gaat en het echt wel de bedoeling is.
Dit is gewoon dom van Google/Microsoft. Dit zou by default uit moeten staan en een developer moet dit bewust aanzetten.
Dit, want het probleem is veel groter.

Neem bijvoorbeeld webmail of zendesk waarbij je berichten typt in de webbrowser.
Spellcheck is handig om geen fouten te maken, maar in die zelfde omgeving kan je dus ook wachtwoorden en andere privacy informatie.

Of vooral al die dokters die een recept uitschrijven in hun web omgeving...
Nou, dan kan zorgmail ook wel direct worden afgeschaft omdat de dokter het lek is.
En dan heb je mensen in bedrijven die komen vragen waarom Grammarly niet werkt op hun werkpc ...

Ergens verwachten mensen dat het gewoon werkt, zonder bij na te denken hoe het werkt. En blijkbaar zijn er dus ook gewoon developers die niet nadenken bij de mogelijke gevolgen van dat systeem. Waarom je een veld van het type wachtwoord ook maar op enig moment zou doorsturen, is mij een raadsel. Zelfs wanneer je op het oog klikt om de inhoud weer te geven veranderd het type van veld niet op een magische manier.
Lokaal op de machine een woordenboek is geen optie? Firefox en Thunderbird maak daar namelijk gebruik van. LibreOffice ook.
Ook het klassieke office pakket van Microsoft heeft een spelling en grammatica controller die zonder internet werkt.
Lokaal op de machine een woordenboek is geen optie? Firefox en Thunderbird maak daar namelijk gebruik van. LibreOffice ook.
Nee. Want dan kunnen MS en Google geen gegevens van gebruikers verzamelen. De dienst zit doelbewust in de cloud. Dat privacy-gevoelige gegevens dus ook opgesstuurd worden, is een onfortuinlijk (en feitelijk onvermijdelijk !) bijeffect
Ook het klassieke office pakket van Microsoft heeft een spelling en grammatica controller die zonder internet werkt.
Dat zal dan wel niet lang meer zo blijven...
In het artikel staat dat er zowel een lokale als een cloudspelling-en-taalcontrole is.
In beide browsers kunnen gebruikers kiezen tussen een basale en geavanceerde spellingscontrolefunctie en in dat laatste geval wordt alle zichtbare tekst doorgestuurd naar servers van de betreffende bedrijven, zo ontdekken onderzoekers van otto-js.
Het verschil met de lokale en de cloud-variant, is dat de cloudvariant ook contextueletaalondersteuning heeft. Ofwel hij zal “Ik hebben een telefoon” ook rekenen.
Ik vermoed dat dit te complex is voor een browser-plugin om betrouwbaar uit te voeren. (Mogelijk dat mijn voorbeeldzinnetje nog wel te doen is, maar het kan snel best ingewikkeld worden)
Ik vermoed dat het me de nieuwste versie al niet meer is want word zit nu vol met Bing integratie.
Is echt grappig dat Bing.

Als je Uyghur zoekt dan krijg je geen resultaten, maar als je Uygur of zelfs yghur zoekt krijg je wel resultaten.

Ik snap alleen niet waarom specifiek Uyghur geblockt wordt via een niet-Chinese ip-adres. Er is gewoon geen goed excuus ervoor. Dat China bang is, is voor hunzelf, maar waarom mag ik buiten China niet opzoeken wat Uyghur is?
Heb je een Chinees virus op je computer ofzo? Hier geen enkel probleem met "Uygur" op Bing. Meerdere pagina's met resultaten, en een uitgebreide lijst met autocomplete voorstellen.
Hier geen enkel probleem met "Uygur" op Bing.
Als je Uyghur zoekt dan krijg je geen resultaten, maar als je Uygur of zelfs yghur zoekt krijg je wel resultaten.
Met alle respect, maar ik heb het dus letterlijk in hetzelfde zin verteld :D . Uygur werkt, maar Uyghur werkt niet.

Ik heb het zowel mobiel/pc/laptop met verschillende IP en vpn's gebruikt met hetzelfde resultaat op Bing:
Met je huidige instelling voor Bing - Veilig zoeken worden mogelijke resultaten van inhoud voor volwassenen uitgefilterd. Als je dergelijke resultaten ook wilt weergeven, moet je de instelling voor Bing - Veilig zoeken aanpassen
Mijn verontschuldigen, ik had inderdaad het verkeerde woord gekopieerd.
Het resultaat wat jij zie is inderdaad gevolg van een slecht geconfigureerde Safesearch bij Bing. Overigens alleen als je die zelf op "strikt" hebt gezet. (Niet bij de standaard gematigde.)

Ik zie dat zelfs "Uyghurs" (dus met "'s") niet gefilterd wordt.
Het oogje is een blubber javascript om de input om te vormen naar een regulier veld. Native HTML heeft geen oogje.
Het oogje is een blubber javascript om de input om te vormen naar een regulier veld. Native HTML heeft geen oogje.
Het 'oogje' is een built-in feature in sommige browsers op input velden van het type password. Daar hoef je geen regel JavaScript voor te schrijven.
Niet mijn browser. Linkje?
https://learn.microsoft.c...-platform/password-reveal

In Edge kan de webontwikkelaar het per veld aan- en uitzetten, of zelfs een ander icoontje geven.
MDN kent het niet als standaard attribuut, dus is het een vendor extensie en moet zowiezo genegeerd worden tenzij we weer IE6 willen.
MDN kent het niet als standaard attribuut, dus is het een vendor extensie en moet zowiezo genegeerd worden tenzij we weer IE6 willen.
https://developer.mozilla...bal_attributes/spellcheck
Ah, ik bedoelde het oogje is geen standaard. De spellcheck uiteraard wel.
Ok. Ik was even in de war. Maar inderdaad: het oogje is geen standaard.
(Zou het eigenlijk wel moeten worden. Zijn we tenminste af van die verschrikkelijke bad practice waar mensen met JavaScript het type van een input element omzetten van password naar text.)
LangueTool is wat dat betreft een goed alternatief voor Grammarly: https://languagetool.org

Werkt op hetzelfde principe, maar de gehele infrastructuur is ook zelf te hosten. https://dev.languagetool.org/http-server
I heb hem even bekeken, maar die dienst gaat niet goed om met koppelwoorden.

Geslotenjeugdzorgmedewerker accepteert hij bijvoorbeeld niet terwijl het toch gewoon een goed Nederlands woord is. (De spellingcontrole op m’n telefoon accepteert dat woord wel overigens)
De meeste spelling- en grammaticacontroles accepteren dat soort woorden niet. Helaas zijn spelling- en grammaticacontroles net als boeren: wat ze niet kennen...... ;)

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 14:44]

Ik heb even een steekproef genomen:

M'n telefoon (iPhone) accepteert het wel
MS-Word op m'n desktop accepteert het niet
spelling.nu accepteert het niet (als 'mogelijke' spellingsfout)
Spelcheck.nl accepteert het wel
Spellboy.com accepteert het niet (als 'mogelijke' spellingsfout)


Eigenlijk is het raar dat die woorden niet gewoon geaccepteerd worden. In het Nederlands hebben we koppelwoorden. Dat is eenmaal zo. Als je de woorden los schrijft, krijgen zinnen een andere betekenis.
Met klassieke voorbeelden:
langeafstandsloper (iemand die lange afstanden loopt)
lange afstandsloper (een afstandsloper die lang is)
rodewijnglazen (glazen voor rode wijn)
rode wijnglazen (wijnglazen die rood zijn)
Of zoals mijn voorbeeld:
Geslotenjeugdzorgmedewerker Een medewerker van de gesloten jeugdzorg
Gesloten jeugdzorgmedewerker (een jeugdzorgmedewerker die gesloten is)
(Voor hen die geïnteresseerd zijn: SOS heeft omtrent dit onderwerp een site gemaakt en heeft ook de regels duidelijk beschreven)
Eigenlijk is het raar dat die woorden niet gewoon geaccepteerd worden. In het Nederlands hebben we koppelwoorden. Dat is eenmaal zo. Als je de woorden los schrijft, krijgen zinnen een andere betekenis.
Met klassieke voorbeelden:
langeafstandsloper (iemand die lange afstanden loopt)
lange afstandsloper (een afstandsloper die lang is)
rodewijnglazen (glazen voor rode wijn)
rode wijnglazen (wijnglazen die rood zijn)
Of zoals mijn voorbeeld:
Geslotenjeugdzorgmedewerker Een medewerker van de gesloten jeugdzorg
Gesloten jeugdzorgmedewerker (een jeugdzorgmedewerker die gesloten is)
(Voor hen die geïnteresseerd zijn: SOS heeft omtrent dit onderwerp een site gemaakt en heeft ook de regels duidelijk beschreven)
Dat hoef je mij als Neerlandicus niet uit te leggen. ;)

Maar inderdaad zouden álle spellingcontroles gewoon beter moeten kijken naar wat er lokaal juist is in plaats van vast te houden aan een standaardlijstje waar een hoop woorden ontbreken en dus fout worden gerekend.
Heb ook even de vraag bij LanguageTool neergelegd of er sprake is van Spell-Jacking en kreeg als antwoord:
“Thanks for your message. LanguageTool checks multi-line fields only, so usernames etc. are typically skipped.”
Moet alleen nog even vragen wat dan tyically precies betekend.
Het is mogelijk om via het rechtermuisknopmenu alsnog de tekst in een dergelijk veld te laten checken in de LanguageTool editor. Heeft dus een uitdrukkelijke user actie nodig, maar misschien doelen ze daar op.

Het is iig niet mogelijk om het in de instellingen standaard aan te zetten zover ik kan zien.
Ik kwam wel tegen dat je de tool voor specifieke websites kan uitzetten, dus dat zorgt er ook voor dat voor websites waar je absoluut geen ingetypte data van wil versturen je het uit kan schakelen.

Overigens is bij het zelf hosten het versturen van de data dus minder een issue.
En blijkbaar zijn er dus ook gewoon developers die niet nadenken bij de mogelijke gevolgen van dat systeem.
Die developer moet het ten eerste weten en ten tweede moeten partijen als Google en Microsoft ophouden opties aan en uitzetten bij updates ed.

Steeds vaker zie je dat zogeheten “developers” relatief weinig doen en met software werken met standaard phrases met het concept WYSIWYG. Achterliggende kennis is steeds minder aanwezig.
En blijkbaar zijn er dus ook gewoon developers die niet nadenken bij de mogelijke gevolgen van dat systeem
Ja, want alle developers zijn hoogopgeleid, en grondig getraind... NOT.
Echt nog nooit van Grammarly gehoord, ook nog nooit iemand op werk gehad die er naar vroeg.
Dat er niet naar gevraagd is zou kunnen, maar dat je er nooit van gehoord hebt is wel opmerkelijk, want het is een van de bekendste hulpmiddelen.

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 14:44]

De bekendste is gewoon woordenboek in de browser zelf, of deze in Office.
Ik werk zelf in bedrijf voor de IT en tussen de 400/450 medewerkers, totale bedrijf zelf veel groter iets van 330 duizend medewerkers.
Ik werk er nu al 8 jaar en nog nooit Grammarly voorbij zien komen.

Bekendste manieren zijn gewoon Google translate, woordenboek in de browser zoals dit artikel, of de spellingscontrole in Office.

[Reactie gewijzigd door Carlos0_0 op 22 juli 2024 14:44]

Dat zou een offline api moeten worden zodat het lokaal blijft
Zelfs wanneer je op het oog klikt om de inhoud weer te geven veranderd het type van veld niet op een magische manier.
https://www.w3schools.com/howto/howto_js_toggle_password.asp
Achterhaalde bad practice sinds browsers standaard een 'toon wachtwoord' widget zijn gaan bieden, ingebakken in de native UI van het <input> element.

Verbaasd me dan ook niets dat deze content nog steeds op w3schools te vinden is.
Het is tenslotte hèt afvalputje van webdev naslag-sites.

[Reactie gewijzigd door R4gnax op 22 juli 2024 14:44]

Volgens mij is ons hele epd web based aan de spellingscontrole te zien dus niet alleen de recepten. Alleen vul je nooit de naam van de patiënt want in die omgeving zit je al. Ik zou het toch wel heel kwalijk vinden als het klopt....
Firefox als standard aanbevelen;)
Het lek is in Chrome en Edge ontdekt, maar dat wil niet zeggen dat Firefox veilig is. Misschien is het zo, maar misschien is het ook een kwestie van tijd voordat ze hetzelfde gedrag in Firefox aantreffen. Net als met die kwetsbaarheden in cpu's: iedereen riep dat men bij AMD nooit kwetsbaarheden zou aantreffen zoals bij Intel, maar uiteindelijk zijn er toch ook kwetsbaarheden bij AMD aangetroffen. Dus je weet het nooit: misschien is Firefox ook niet helemaal veilig hierin. Zou me ook niet heel erg verbazen, want ze hebben wel wat dingen geleend bij Google (zoals bijv. WebExtensions).
Firefox gebruikt een offline spelling controle. Vooral bedrijven zouden zich moeten realiseren dat het gebruik van Chrome en Edge bedrijfsgegevens lekt. Onacceptabel zou je toch denken? Gebruik liever Firefox.
De spellingcontrole an sich werkt misschien offline, maar er wordt wel degelijk iets gesynchroniseerd naar je Firefox-account middels services.sync.prefs.sync.layout.spellcheckDefault
Daar kan nog altijd een lek in zitten waardoor invoer naar je account en dus naar Mozilla gedeeld wordt. Nogmaals: ik zeg niet dat het zo is, maar dat het zou kunnen.
ik zeg niet dat het zo is, maar dat het zou kunnen.
Mozilla heeft een hele duidelijke visie natuurlijk. Maar als je daar toch aan twijfelt, Firefox is open-source :) en derhalve kun je controleren wat het wel en niet doet.
Je typt vast wel ergens de volledige naam.
En zeker ook symptomen, diagnose en aandoeningen.
Een arts schrijft geen email voor een recept. Alles gaat rechtstreeks het patiëntendossier in.
We moeten met zijn allen bewust zijn van de gegevenshonger van de grote jongens op internet. Dit soort zaken zijn helemaal niet dom van google/microsoft (en omstreken). Het is naar mijn ideen 'creatief boekhouden' met onze gegevens.

Ooit was het handig dat browsers de formulier-gegevens kon opslaan. Tot we bedachten dat die gegevens dan wel versleuteld moeten worden opgeslagen waarna de tech-giganten dat dan ook maar 'zo snel mogelijk' deden. Helaas kunnen ze daar dan (officiëel) niet meer bij.

Bij deze hebben ze dus een nieuwe route gevonden, naast de online-tekst-verwerkers en dergelijke.
Het is een opt-in feature. Ik gebruik al jaren Chrome en wist niet eens van het bestaan en ik denk het merendeel van de mensen niet. Bovendien moet je het als web developer bijna bewust verpesten wil je wachtwoord doorgestuurd worden.

En in het slechtste geval, als het doorgestuurd wordt zijn het Googles computers die het lezen en gebeurt er nog niks met je wachtwoord.

Typische storm in een glas water dit maar we hebben weer een stok gevonden om mee te slaan.
Het is een opt-in feature
En hoe veel mensen begrijpen alle bijeffecten van die feature ? Jij wel. De meeste mensen niet. Die kunnen dat niet overzien....
Die kunnen dat niet overzien....
Dan moeten ze er van af blijven?

Als het opt-in is, is het de verantwoordelijkheid van degene die actief de keuze maakt.
[...]

En hoe veel mensen begrijpen alle bijeffecten van die feature ? Jij wel. De meeste mensen niet. Die kunnen dat niet overzien....
Sterker nog: dat kan je helemaal niet overzien.
Het is immers niet publiek bekend wat Google en Microsoft met de data doen. Je moet er van uitgaan dat _alles_ wordt bewaard, en tegen je kan worden gebruikt als je bijv. president van de US wilt worden, of een andere belangrijke functie wilt bekleden.
Waarom moet spellingscontrole überhaupt online? Dat kon 25 jaar geleden al makkelijk offline en nu helemaal.
Een centrale plek om alle talen op te slaan. Makkelijker dan miljoenen individuele installaties beheren; dus up-to-date te houden, dynamische eigenschappen van talen bijhouden, etc.

En dat is enkel nog de Nederlandse taal.

Eufemismen, nieuwe woorden, leenwoorden, eigennamen van bedrijven en dat allemaal per taal.
Gelukkig kan een takenpakket door die miljoenen gebruikers van een server worden gedownload, al dan niet automatisch.

[Reactie gewijzigd door Ablaze op 22 juli 2024 14:44]

Rechten tot wijzigen van lokale omgeving, (logische) beperkingen door beheer mbt automatische updates, versies die ondertussen EOL zijn.

Hoewel er wel een goed punt is voor lokale installaties (geen internet nodig, consistentie op de langere termijn, kosten?) zijn er wel degelijk voordelen van cloud-oplossingen voor spelling- en grammatica-checkers.

Wat wel een dingetje is, is hoe cloud-based tegenwoordig de standaard is en offline steeds moeilijker lijkt te worden.
Inderdaad, plus dat de data simpelweg veel ruimte inneemt. Als een voorbeeld, ik was aan het kijken naar het zelf hosten van de LanguageTool server (open source alternatief voor grammarly). In de documentatie melden ze dat de dataset voor een specifieke feature al 8gb in beslag neemt.
8 GB is best een hoop voor taalgerelateerde dingen, maar ik mag aannemen dat je server geen 10 GB harde schijf heeft en je dus wel ruimte hebt om dat te hosten. ;)
We hadden het dan ook over de vraag waarom dit niet standaard in browser zit ingebakken...
Klopt, maar jij zei specifiek "ik was aan het kijken naar het zelf hosten van de LanguageTool server"...

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 14:44]

En wat niet relevant is omdat ik dat alleen maar aanhaalde als context waar ik deze informatie tegenkwam. Nergens impliceer ik dat voor een server het teveel aan data is, je reactie is dus echt alleen maar ruis en weinig relevant.

Ik snap dit soort reacties gewoon niet, het komt haast over dat je reageert om te reageren.
Mijn reactie was goedbedoeld. :)

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 14:44]

Omdat offline spellingscontrole geen rekening houdt met de context. Dus een zin als
"Ik lopen doorn het hele straat" wordt goedgekeurd omdat elk woord op zich een goed Nederlands woord is.
Online spellingscontrole kijkt verder en ziet dat o.a. "Ik lopen" geen goede combinatie is en zal er van maken:
"Ik loop door de hele straat"
Tenminste dat hoop ik, want ik heb de functie al jaren uitstaan. Dus kan dit niet bevestigen.
Dat lijkt mij meer grammatica in plaats van spelling. Maar dat is iets dat een programma als Word ook al offline kan sinds 1997 of iets dergelijks.
WP deed dat al onder DOS.
<input type="password"/> valt toch niet onder : "The value of input elements whose type attributes are in the Text, Search, URL, or Email states and that are mutable (i.e. that do not have the readonly attribute specified and that are not disabled)."

https://html.spec.whatwg....tion.html#attr-spellcheck

spellcheck=false is toch een soort van halve oplossing. Dat zou als ik Stackoverflow bekijk ook via javascipt op true gezet kunnen worden. CORS op alleen je eigen origin, alle js sources voorzien van integrity hash. Geen embedding in iframes.
De browser stuurt de request voor de spellcheck, dat gaat verder buiten CORS om.
Veel websites (en ook bijvoorbeeld Edge) bieden de functionaliteit om het wachtwoord zichtbaar te maken, waarna de password-input in een text-input veranderd en de waarde dus mogelijk ‘gespellcheckt’ kan worden.
Er zit hier wel een risico dat wanneer je spellcheck op false hebt staan dat een externe js de spellcheck weer op true zet wanneer je externe js niet voorkomt
Verbaast me niks..

Dat vind ik ook zo mooi aan de vertaalfunctie van Firefox. Hij werkt ook volledig lokaal.

Het werkt niet zo geweldig als die van Google omdat hij geen hele cloud AI achter zich heeft, maar het is privacybewust en werkt goed genoeg.
Inderdaad ga toch op mijn game pc firefox als primary weer gebruiken, doe er niet zoveel mee behalve gamen.
Maar begin toch wel een beetje klaar met Edge te zijn, na alle privacy dingen waarvan ik niet perse wakker lig(Gebruik ook google, Facebook, whatsapp etc).
Maar ook alle nutteloos en irritante toevoegingen, als games, shopping korting codes die niet eens werken al 2 keer geprobeerd, en laatst die irritante sidebar.

Ik blijft maar bezig met dingen uitschakelen wat ik niet wil, zeg het nu al een tijdje. maar van weekend eens even tijd in steken(En Edge als alternatief houden mocht effe iets niet werken door popupblockers etc).
Ja Edge gebruik ik ook niet, behalve op mijn werk omdat Microsoft maandenlang heeft lopen pushen bij de directie om het als 'standaardbrowser' te zetten.

Ik zie gewoon het voordeel niet, het is gewoon Chrome maar dan met een Microsoft sausje erover. Wat ze nooit duidelijk hebben gemaakt is wat er dan zoveel beter aan zou zijn. Ze hebben er een handjevol functies deels veranderd en deels toegevoegd maar vooral is het verschil dat je het ene datahongerige bedrijf inruilt voor het andere.

Die dingen als games en shoppingcodes heb ik niet eens gezien, misschien slopen ze die op het werk er uit. Helaas begint Firefox nu ook al met flauwekul dingen zoals nieuws headlines op de nieuwe tab pagina. Nog wel uitschakelbaar gelukkig.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 14:44]

Firefox is met alles ieder ander bedrijf, natuurlijk afhankelijk van inkomsten. Dat ze je vragen of ze met bepaalde optionele diensten een beetje geld mogen verdienen, is legitiem lijkt me.
Het aan- of uitzetten kost eenmalig nog net geen seconde...
Dat nieuws ('via pocket') levert ze volgens mij helemaal geen geld op, en via tracking zouden ze echt geen inkomsten moeten verdienen want dan schieten ze hun laatst overgebleven doelgroep in de voeten. De sponsored shortcuts leveren ze idd wel geld op maar ook dat is iets dat ze voor de doelgroep niet zouden moeten doen. Het is ook vervelend om dat op elk systeem te moeten doen (ik heb er tientallen, desktop, server mobiel alles bij elkaar).

Ik zou wel betalen als ze echt iets bruikbaars zouden leveren. Bijvoorbeeld iets als iCloud Private Relay wat Apple heeft. Firefox heeft de doorverkoop van Mullvad abootjes maar daar heb ik niet zoveel aan, dat is lang niet zo goed als iCloud Private Relay dat continu je IP roteert. Bovendien heb ik mijn mullvad liever direct bij de bron omdat ik het dan ook voor dingen kan gebruiken die niet in de browser werken.

Ik zou ze zelfs direct betalen als dat kon. Maar je kan niet eens direct aan Firefox doneren, alleen aan de mozilla foundation die niet voor firefox is (dat is de corporation). KDE bijv geef ik wel elk jaar een donatie.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 14:44]

Games, shopping codes enzo zie ik op het werk ook niet, ik gebruik hem daar als 2de browser en firefox als main browser wel.
Dus wellicht staan die dingen daar default uitgezet, of het is een speciale bedrijven versie net zoals firefox etc ook heeft zonder die meuk.
Als ik met Edge thuis bijv naar thuisbezorgd gaat zegt die een actie code te hebben, dit komt in de taakbalk te voorschijn.

Welke nieuwe headlines bedoel je dan, ik open firefox thuis nog wel eens maar zie niks nieuws ?
Oh grappig, dat ga ik ff proberen met die codes. Nog niet gezien maar ik gebruik het zelden.

Die headlines zie je met de 'pocket' integratie maar zo te zien is het er nu weer helemaal uit verdwenen. Wellicht vanwege de klachten. Ik heb het destijds gelijk uitgezet.

De sponsored shortcuts zitten er helaas nog wel steeds in.
spellcheck=false Heeft dat ook invloed op lokale spellcheck op mobiel? Het is altijd vrij irritant als je ineens bij zo’n veld komt wat geen spellcheck heeft als je op je mobiel typt.
spellcheck=false schakelt inderdaad elke vorm van spellingscontrole uit. Maar ik heb het gevoel dat jij het hier over text suggestions hebt, en niet over spellcheck?
Het zou voor websitemakers hoe dan ook vrij eenvoudig zijn om de informatiestroom van gevoelige data naar servers van Google of Microsoft te voorkomen. Door de mogelijkheid op spellingscontrole op gevoelige velden uit te schakelen met de html-code spellcheck=false zou het probleem opgelost zijn.
een opt-out is hier niet echt de meeste nette oplossing though
Ha idd.... Je wilt niet dat de spelling/grammatica zich bemoeit met gebruikersnaam en/of wachtwoordvelden.
Ten eerste zeer ongewenst en ten tweede volstrekt nutteloos.
De 'toon wachtwoord' knop kan handig zijn maar moet ten alle tijde lokaal blijven.
Dat is een potentieel groot beveiligingsprobleem. Ik ga toch maar even mijn instellingen nalopen.
In het geval van Edge is dit een losse extentie/addon, als ik het goed zie?

De standaard settings kent deze optie in ieder geval niet, alleen een basale "Enable spellcheck".

Correctie: Blijkbaar heeft de Mac versie van Edge dit niet standaard. Windows 11's Edge wel.

[Reactie gewijzigd door eric.1 op 22 juli 2024 14:44]

Dat is dus ook precies waarom ik die predictive text swiping keyboards van Google en Microsoft niet gebruik. Onderhand genoeg gebeurd dat ik er van uit ga dat de tekst wél (gedeeltelijk) opgeslagen wordt en leesbaar is door bepaalde werknemers - totdat Google en Microsoft het tegendeel bewijzen.

Op dit item kan niet meer gereageerd worden.