[Deprecation]The 'textprediction' attribute will be removed in the future. Use the 'writingsuggestions' attribute instead.

[Rolf B]

Hallo alle,

diese Meldung bringt mir Edge gerade in den Developer Tools, in der Quelltextansicht, für irgendeinen blöden if. Offenbar wird diese Quelltextansicht per HTML erzeugt und offenbar möchte Edge nicht, dass der Copilot da mitquatscht.

Aber...

textprediction? writingsuggestions? Schon mal gehört?

Das ist offenbar ein neues HTML Attribut in Chromia 124+, mit denen sich ein eventuell vorhandener KI-Copilot auf dem Gerät des Benutzers deaktivieren lässt. Als 'writingsuggestions' hat es sogar seinen Weg in die Spec geschafft.

<label>Ungeholfene Eingabe:
<input type="text" writingsuggestions="false"></label>

Das Böse daran ist, dass der Defaultwert dieses Attributs true ist. Ich habe keine Ahnung von diesen KI Copiloten und weiß darum nicht, ob die rein lokal agieren oder ihre Dünntelligenz von einem Server bekommen. Woraus folgt: Privatsphärenalarm!

Weiß jemand mehr darüber?

Rolf

[Robert B.]

Moin Rolf,

diese Meldung bringt mir Edge gerade in den Developer Tools, in der Quelltextansicht, für irgendeinen blöden if. Offenbar wird diese Quelltextansicht per HTML erzeugt und offenbar möchte Edge nicht, dass der Copilot da mitquatscht.

bedeutet es, dass die dort keinen Quellcode für irgendeinen „Copiloten“ sammeln? Aber da die Fehlermeldung ja vom Browser kommt, sieht man wieder einmal eindrucksvoll, wie gut™ Softwaretests funktionieren 😝

textprediction? writingsuggestions? Schon mal gehört?

Liest sich erst einmal wie fast ein Duplikat von autocomplete.

Das ist offenbar ein neues HTML Attribut in Chromia 124+, mit denen sich ein eventuell vorhandener KI-Copilot auf dem Gerät des Benutzers deaktivieren lässt. Als 'writingsuggestions' hat es sogar seinen Weg in die Spec geschafft.

Das Böse daran ist, dass der Defaultwert dieses Attributs true ist. Ich habe keine Ahnung von diesen KI Copiloten und weiß darum nicht, ob die rein lokal agieren oder ihre Dünntelligenz von einem Server bekommen. Woraus folgt: Privatsphärenalarm!

Für Passwort-Felder, deren type man zum Anzeigen des Passworts umschalten kann, ist der „Schreibvorschlag“ damit ein weiteres Attribut, das man zwingend als Nicht-Default angeben muss 😕

<input type="password" name="bleibtLokal"
    spellcheck="false" autocomplete="off" writingsuggestions="false">

Wer denkt sich so etwas aus?!

Vielen Dank fürs Finden und viele Grüße
Robert

[Rolf B]

Hallo Robert B.,

password

Die Spec sagt, true - unter anderem - wenn:

element is an input element whose type attribute is in either the Text, Search, Telephone, URL, or Email state and is mutable;

Rolf

[Robert B.]

Moin Rolf,

password

Die Spec sagt, true - unter anderem - wenn:

element is an input element whose type attribute is in either the Text, Search, Telephone, URL, or Email state and is mutable;

wenn ich das Passwort anzeigen lassen möchte, wird aus type="password" → type="text" und damit würden die ganzen Späße auf einmal aktiv, sofern man sie nicht schon für das Passwort-Feld abschaltet.

Viele Grüße
Robert

[Gunnar Bittersmann]

@@Robert B.

Das ist offenbar ein neues HTML Attribut in Chromia 124+, […] Das Böse daran ist, dass der Defaultwert dieses Attributs true ist.

Ach du Scheiße! Google ist mal wieder das Web und seine Nutzer scheißegal.

Für Passwort-Felder, deren type man zum Anzeigen des Passworts umschalten kann, ist der „Schreibvorschlag“ damit ein weiteres Attribut, das man zwingend als Nicht-Default angeben muss 😕

Ach du Scheiße! Und solange sich das nicht herumgesprochen hat?

Es wird Zeit, dass die Passwort-anzeigen-Funktion endlich dort implementiert wird, wo sie hingehört: in den Browsern! Das Password muss im Klartext angezeigt werden können, ohne dass der Typ des Eingabefeldes von password auf text geändert wird.

Edge hatte das mal als einziger Browser so implementiert – bevor sie auf Chromium umschwenkten. Es ist ein Jammer, dass sie diese Funktion nicht hinübergerettet haben und damit auch anderen Chromium-Browsern zur Verfügung gestellt haben.

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar,

Edge (126) kann das: .
Das Auge im Inputfeld zeigt das PW an (aber nur, solange man das Feld nicht verlässt) und der Anzeigen-Button daneben ist von der Webseite und schaltet auf type="text" um.

Chrome tut's nicht. Es gibt wohl einen Unterschied zwischen der Rendering-Engine und der Darstellung des gerenderten Ergebnisses. Very Strange. Oder es liegt dran, dass ich auf diesem gemanagten Gerät hier seit ein paar Monaten keine Chrome-Updates mehr hinkriege 😟

Diese freundliche KI-Unterstützung durch einen „Copiloten“ scheint aber eher Microsoft anzulasten zu sein, von denen ist die alte Attributversion wohl gekommen, die jetzt unter anderem Namen standardisiert wurde. Zumindest hatte ich beim Suchen nach den Attributnamen diesen Eindruck.

Rolf

[Robert B.]

Moin Rolf,

Edge (126) kann das: .
Das Auge im Inputfeld zeigt das PW an (aber nur, solange man das Feld nicht verlässt) und der Anzeigen-Button daneben ist von der Webseite und schaltet auf type="text" um.

Chrome tut's nicht. Es gibt wohl einen Unterschied zwischen der Rendering-Engine und der Darstellung des gerenderten Ergebnisses. Very Strange. Oder es liegt dran, dass ich auf diesem gemanagten Gerät hier seit ein paar Monaten keine Chrome-Updates mehr hinkriege 😟

das Symbol im Passwort-Feld scheint von einer UI-Bibliothek von Microsoft zu kommen, denn das gibt es auch an anderen Stellen in Windows bei Passwort-Eingaben. Leider nutzen das die anderen Browser nicht.

Viele Grüße
Robert

[Gunnar Bittersmann]

@@Rolf B

Edge (126) kann das: .

Nö, im Edge 128 auf macOS ist nichts dergleichen.

Microsoft denkt wohl, alle Edge-Nutzer sind auf Windows, und Edge für macOS ist nur ein Abfallprodukt? Vermutlich haben sie damit recht.

Kwakoni Yiquan

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Edge (126) kann das: .

Nö, im Edge 128 auf macOS ist nichts dergleichen.

Microsoft denkt wohl, alle Edge-Nutzer sind auf Windows, und Edge für macOS ist nur ein Abfallprodukt? Vermutlich haben sie damit recht.

Vielleicht nutzt der Edge unter Windows auch eine Betriebssystem-Funktion, die Windows dafür zur Verfügung stellt, andere OS aber nicht? 🤔

Kwakoni Yiquan

[Robert B.]

Moin Gunnar,

Vielleicht nutzt der Edge unter Windows auch eine Betriebssystem-Funktion, die Windows dafür zur Verfügung stellt, andere OS aber nicht? 🤔

anscheinend ist das so.

Viele Grüße
Robert

[Robert B.]

Moin Gunnar,

Ach du Scheiße! Google ist mal wieder das Web und seine Nutzer scheißegal.

hat Google jemals gesagt, für wen »don’t be evil« gelten soll?

Für Passwort-Felder, deren type man zum Anzeigen des Passworts umschalten kann, ist der „Schreibvorschlag“ damit ein weiteres Attribut, das man zwingend als Nicht-Default angeben muss 😕

Ach du Scheiße! Und solange sich das nicht herumgesprochen hat?

Bewusstsein schaffen, solange sich das nicht herumgesprochen hat oder es effektive Lösungen gibt wie:

Es wird Zeit, dass die Passwort-anzeigen-Funktion endlich dort implementiert wird, wo sie hingehört: in den Browsern! Das Password muss im Klartext angezeigt werden können, ohne dass der Typ des Eingabefeldes von password auf text geändert wird.

Alternativ kann man ein output anzeigen und das Passwortfeld verstecken, wie ich gerade ausprobiert habe.

Viele Grüße
Robert

[Gunnar Bittersmann]

@@Robert B.

Es wird Zeit, dass die Passwort-anzeigen-Funktion endlich dort implementiert wird, wo sie hingehört: in den Browsern! Das Password muss im Klartext angezeigt werden können, ohne dass der Typ des Eingabefeldes von password auf text geändert wird.

Alternativ kann man ein output anzeigen und das Passwortfeld verstecken, wie ich gerade ausprobiert habe.

Die Idee mit zwei getrennten Feldern gefällt mir. Allerdings sollte man das Passwort nicht nur im Klartext angezeigt bekommen, sondern es auch im Klartext eingeben können.

Ich habe deshalb statt output ein zweites input verwendet; die Eingaben werden zwischen beiden Eingabefeldern synchronisiert.

☞ reveal password, 2 inputs

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar,

äh, warum die Mühe? Wenn Du es jetzt neu machst, dann kannst Du writingsuggestions auf false setzen und bei Bedarf den type zwischen text und password umschalten.

Frage ist, ob man die browserseitige Existenz des Password-Buttons durch eine Feature Query erkennen kann…

Rolf

[Gunnar Bittersmann]

@@Rolf B

äh, warum die Mühe? Wenn Du es jetzt neu machst, dann kannst Du writingsuggestions auf false setzen und bei Bedarf den type zwischen text und password umschalten.

Und wenn Google oder Microsoft die nächste Sau durchs Dorf treibt, muss man wieder ein neues Attribut an seine Passworteingabfelder hängen‽

Ah, wait! Die Attribute müsste man ja auch an das Reveal-Passwort-Eingabefeld hängen?

Aber zumindest ist das nicht the real thing (dessen Wert irgendwie weitergegeben wird). The real thing behält type="password".

Macht es das irgendwie besser?

Frage ist, ob man die browserseitige Existenz des Password-Buttons durch eine Feature Query erkennen kann…

Du meinst, sobald ein Browser das Passwort-Anzeigen implementiert hat, sollte die eigene Implementierung nicht mehr angewandt werden? Ja, schön wär’s.

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar,

Ah, wait! Die Attribute müsste man ja auch an das Reveal-Passwort-Eingabefeld hängen

Plick...

Siehe unten, ein Groschen 😉

Die einzige Chance, sich sicher vom kreativen Wahn der Browserbauer(n) zu distanzieren, ist ein div, das ein input Element imitiert. Würde ich aber nicht wirklich als best practice klassifizieren…

Rolf

[Gunnar Bittersmann]

@@Rolf B

Die einzige Chance, sich sicher vom kreativen Wahn der Browserbauer(n) zu distanzieren, ist ein div

Wieso ein div? output, wie von @Robert B. vorgeschlagen, trifft’s besser.

das ein input Element imitiert.

contenteditable="true".

In der Tat war <output contenteditable="true"> mein erster Gedanke gewesen. Ich hätte mal dabei bleiben sollen.

Muss man halt nur das output-Element wie das input-Element stylen.
(Warum tut es output { appearance: textfield } nicht?)

☞ reveal password, input & output

Kwakoni Yiquan

[Camping_RIDER]

Aloha ;)

☞ reveal password, input & output

Ein kleiner Bug ist noch drin: wenn man den Button klickt bevor man im password-Feld was eingegeben hat (also bei Leerstring) kann man ins output nichts eingeben. Zumindest gelingts mir nicht (Chrome 128 @ Linux).

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

☞ reveal password, input & output

Ein kleiner Bug ist noch drin: wenn man den Button klickt bevor man im password-Feld was eingegeben hat (also bei Leerstring) kann man ins output nichts eingeben. Zumindest gelingts mir nicht (Chrome 128 @ Linux).

Danke für die Meldung. Kann ich auf macOS nachvollziehen. Im Safari auch.

Was ist denn das wieder für ein blöder Webkit-/Chromium-Bug? In Firefox läuft’s wie’s soll.

Kwakoni Yiquan

[Camping_RIDER]

Aloha ;)

Was ist denn das wieder für ein blöder Webkit-/Chromium-Bug? In Firefox läuft’s wie’s soll.

Ich hab keinen blassen Schimmer! Ich hab eben auch ein bissl rumgespielt und mal verschiedene Code-Teile auskommentiert (JS) oder weggelassen / durch Alternativen ersetzt (HTML, z.B. ARIA-Attribute), aber ich schaffe es nicht, das output mit Text zu befüllen wenn es zuvor leer ist - in einem Blanko-Pen mit einem einfachen output geht das allerdings. Da muss sich irgendeine Konstellation ganz doof beißen.

Grüße,

RIDER

[Gunnar Bittersmann]

@@Camping_RIDER

Was ist denn das wieder für ein blöder Webkit-/Chromium-Bug? In Firefox läuft’s wie’s soll.

Da muss sich irgendeine Konstellation ganz doof beißen.

WTF!! @Rolf B hatte vollkommen recht: Nimm div, nicht output – dann geht’s! 😵‍💫

☞ reveal password, input & div

Und da dann natürlich textContent statt value. Nett, dass du fragst: mit output und textValue geht’s auch nicht.

Welche Konstellation sich da nun beißt, hab ich auch noch nicht rausgefunden. Wie du auch schon festgestellt hast , funktioniert ein etwas abgespecktes Beispiel (auch mit hidden, das per JS entfernt wird) ja.

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar Bittersmann,

hat Dir eigentlich schon jemand verraten, dass contenteditable="true" die AI-Bestie ebenfalls weckt? Zumindest steht das so in der Spec.

§ 6.8.6 Writing suggestions
User agents offer writing suggestions as users type into editable regions, either in form controls (e.g., the textarea element) or in elements in an editing host.

contenteditable="true" erzeugt einen editing host.

Es gab eine guten Grund, weshalb ich davon sprach, dass man die Eingabe komplett emulieren müsste. Wenn der Browser spürt, dass das ein Eingabeelement ist, packt er den Copiloten aus. Es sei denn, du meldest Dich von den writingsuggestions ab.

Rolf

[Gunnar Bittersmann]

@@Rolf B

hat Dir eigentlich schon jemand verraten, dass contenteditable="true" die AI-Bestie ebenfalls weckt?

Och Menno, Spielverderber!

Das heißt, wir bleiben dabei, input type zu ändern und dreiundzwölfzig Attribute anzuhängen. Wobei man immer auf der Hut sein muss, was man alles so anhängen muss. Und wenn man was Neues erfährt, ist es eigentlich schon zu spät, weil man’s bereits angehangen haben musste.

Die gute Nachricht ist: Man muss sich um diesen Webkit-/Chromium-Bug nicht weiter kümmern.

Kwakoni Yiquan

[Robert B.]

Moin,

Was ist denn das wieder für ein blöder Webkit-/Chromium-Bug? In Firefox läuft’s wie’s soll.

Ich hab keinen blassen Schimmer! Ich hab eben auch ein bissl rumgespielt und mal verschiedene Code-Teile auskommentiert (JS) oder weggelassen / durch Alternativen ersetzt (HTML, z.B. ARIA-Attribute), aber ich schaffe es nicht, das output mit Text zu befüllen wenn es zuvor leer ist - in einem Blanko-Pen mit einem einfachen output geht das allerdings. Da muss sich irgendeine Konstellation ganz doof beißen.

meiner Erfahrung nach kann es helfen, das output initial mit einem geschützten Leerzeichen zu füllen.

Viele Grüße
Robert

[Camping_RIDER]

Aloha ;)

Das ist in diesem Fall imho nicht zielführend - auch ein geschütztes Leerzeichen ist ein Zeichen, das vom Feld mit type password übernommen würde, was hier unerwünscht ist.

Man müsste da böse Winkelzüge fahren - z.B. beim Synchronisieren immer nur einen Substring übertragen und in die andere Richtung das Platzhalterzeichen forcieren. Denkbar, aber maximal unhübsch, und potenziell dann problematisch, wenn eins der beiden Felder mit Strg+A markiert und dann für Copy oder Paste verwendet wird, weil das leere Output nur leer aussieht, aber nicht leer ist.

Grüße,

RIDER

[Robert B.]

Moin,

Die einzige Chance, sich sicher vom kreativen Wahn der Browserbauer(n) zu distanzieren, ist ein div

Wieso ein div? output, wie von @Robert B. vorgeschlagen, trifft’s besser.

das ein input Element imitiert.

contenteditable="true".

In der Tat war <output contenteditable="true"> mein erster Gedanke gewesen. Ich hätte mal dabei bleiben sollen.

besser doch nicht: Ich habe meine Testseite im Chrome geladen, einen Proxy dazwischen geschaltet und geschaut, welche Round-Trips „nebenbei“ noch geschehen: Für contenteditable bietet Chrome nicht nur die erweiterte Rechtschreibprüfung/enhanced spell-check an, sondern verwendet diese auch und sendet die Eingabe an einen Service von Google.

Mit anderen Worten: Vom Aspekt der (Un-) Sicherheit sind

• input type="text"
• output contenteditable

identisch.

Viele Grüße
Robert

[Robert B.]

Moin Gunnar,

Alternativ kann man ein output anzeigen und das Passwortfeld verstecken, wie ich gerade ausprobiert habe.

Die Idee mit zwei getrennten Feldern gefällt mir. Allerdings sollte man das Passwort nicht nur im Klartext angezeigt bekommen, sondern es auch im Klartext eingeben können.

an dem Punkt war ich auch schon, aber mit der Bearbeitungsmöglichkeit holen wir uns auch wieder die Probleme mit den ganzen Möglichkeiten der Passwort-Abflüsse wieder herein 😕

Ein output synchronisiert von einem input type="password" nebendran wäre auch nicht sonderlich elegant, aber immerhin eine „etwas bessere“ Möglichkeit:

Passwort: [**] [Klartext im output]

Ansonsten bleibt wohl wirklich nichts Anderes übrig als Browserhersteller oder die WhatWG zu nerven …

Viele Grüße
Robert

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Bei meiner Recherche stieß ich auf Chris Coyiers Artikel The Options for Password Revealing Inputs (Oktober 2021).

Option 1: Use type="password", then swap it out for type="text" with JavaScript war der Stein des Anstoßes hier im Thread; das wollen wir ja gerade vermeiden.

Option 2: Use -webkit-text-security in CSS sieht trotz Vendor-Präfix vielversprechend aus; das wird von allen gängigen Browsern unterstützt – für Texteingabefelder.

Und jetzt ratet mal, für welche Elemente das kein Browser unterstützt!
Genau! Für Passworteingabefelder! 🤔😫🤮

☞ reveal password, -webkit-text-security – type="text" gesetzt: die Umschaltung funktioniert. Für type="password": nö, nirgends. Es ist mir auch nicht gelungen, den Browserdefault zu überschreiben – weder mit !important noch mit @layer noch durch Setzen der CSS-Eigenschaft direkt mit JavaScript.

Beim einzigen Element, wo man dieses CSS-Feature sinnvoll anwenden könnte, kann man es nicht anwenden. W T F!

Zur Erinnerung: type="text" zu setzen ist ja gerade das, was wir nicht wollen.

Option 3: input-security in CSS ist (fast) dasselbe als Versuch eines Standards; Browserunterstützung: keine. Wird wohl auch nicht kommen, denn wie im aktuellen Editor’s Draft zu lesen steht: “The CSS-WG has agreed that while be believe that providing this piece of functionality to users is important, doing it via CSS+JS is the wrong approach, and that instead it should be built into user agents.”

Ähm, sag ich doch:

Es wird Zeit, dass die Passwort-anzeigen-Funktion endlich dort implementiert wird, wo sie hingehört: in den Browsern! Das Password muss im Klartext angezeigt werden können, ohne dass der Typ des Eingabefeldes von password auf text geändert wird.

Dort verlinkt: ein Github-Issue zum Entfernen von input-security aus dem Standard. Darin eine Diskussion vom Januar 2022. Was hat sich seitdem getan? input-security steht immer noch im Workung Draft und Passwort anzeigen wurde immer noch nicht in Browsern implementiert (außer Edge unter Windows?).

Wenn’s um developer experience geht, sind die Browserentwickler schnell. Aber hier geht’s ja nur um user experience …

Kwakoni Yiquan

[nicht leer]

(außer Edge unter Windows?)

Firefox: Rechtsklick auf type="password"; aus dem Kontextmenu „Passwort anzeigen“ wählen. Wurde mit Version 112.0 eingeführt.

[Gunnar Bittersmann]

@@nicht leer

Firefox: Rechtsklick auf type="password"; aus dem Kontextmenu „Passwort anzeigen“ wählen. Wurde mit Version 112.0 eingeführt.

Ah! Warum sagt einem das keiner? (Wer liest schon release notes?)

Warum verstecken die das im Kontextmenü, wo man – wenn überhaupt – mal zufällig drauf stößt, anstatt einen clickbaren Button ins Passworteingabefeld zu platzieren?

Kwakoni Yiquan

[Robert B.]

Moin,

Firefox: Rechtsklick auf type="password"; aus dem Kontextmenu „Passwort anzeigen“ wählen. Wurde mit Version 112.0 eingeführt.

Ah! Warum sagt einem das keiner? (Wer liest schon release notes?)

User sind nicht unbeding Developer (und vice versa).

Warum verstecken die das im Kontextmenü, wo man – wenn überhaupt – mal zufällig drauf stößt, anstatt einen clickbaren Button ins Passworteingabefeld zu platzieren?

weil der mobile Firefox (auf Android) eh auch kein Kontextmenü hat. Dort gibt es eine vergleichbare Funktion nur, wenn der Firefox ein Passwort automatisch generieren und im Browser speichern darf – dafür wird das aber jedes Mal angezeigt, wenn man ins Passwort-Feld tippt. Was für ein Erlebnis!

Viele Grüße
Robert

[Matthias Scharwies]

Servus!

Hallo alle,

... Als 'writingsuggestions' hat es sogar seinen Weg in die Spec geschafft.

<label>Ungeholfene Eingabe:
<input type="text" writingsuggestions="false"></label>

Ich habe es mal angelegt: HTML/Attribute/writingsuggestions

Weiß jemand mehr darüber?

Nein, und dieser Thread ist schon das 4. Suchergebnis.^[1]

Ich vermute aber, dass die KI im Browser bleibt und der Unterschied zu autocomplete ist, dass sich dieses auf feste Angaben bezieht, während writingsuggestions eher rät. Kein Wunder, dass die Browser mittlerweile mehr CPU-Power brauchen als Videobearbeitung.

Ich beobachte das mal und aktualisiere - wenn ich was gefunden habe - das entsprechende Tutorial.

Herzliche Grüße

Matthias Scharwies

---

1. Grad gefunden: https://en.wikipedia.org/wiki/Autocomplete
   sehr ausführlich ↩︎

[Matthias Scharwies]

Guten Morgen,

Ich beobachte das mal und aktualisiere - wenn ich was gefunden habe - das entsprechende Tutorial.

Schaut mal bitte hier: Formulare/Eingabe von Text

Der erste Abschnitt stellt die verschiedenen Typen vor.

Neu ist der Abschnitt Eingabehilfen

Dazu einige Fragen/Bitten:

• Wer könnte auf einem Android-Gerät einen Screenshot des autocomplete-Beispiels mit autocomplete="new-password" machen?

• Wie sieht das writingsuggestions Beispiel bei Euch aus? (Nur Chromium-Browser)
  Bei mir wird im Satz: "Es war einmal ein Mächen, das durch den Wald ging" nur das Wort Mächen rot unterringelt und mit 3 Textvorschlägen ergänzt; das falsche das wird nicht bemängelt.

• Wie soll der weitere Aufbau laufen? password jetzt schon erklären oder - wie von mir ursprünglich geplant, in einem eigenen Abschnitt?

Herzliche Grüße

Matthias Scharwies

[Robert B.]

Moin Matthias,

Dazu einige Fragen/Bitten:

• Wie sieht das writingsuggestions Beispiel bei Euch aus? (Nur Chromium-Browser)
  Bei mir wird im Satz: "Es war einmal ein Mächen, das durch den Wald ging" nur das Wort Mächen rot unterringelt und mit 3 Textvorschlägen ergänzt; das falsche das wird nicht bemängelt.

welche „falsche ‚das‘“? Das ist hier doch ein Relativsatz. (Oder vermutest Du, dass die „KI“ mit gängigen Texten aus dem „Internetz“ trainiert worden ist? 😉).

Viele Grüße
Robert

[Matthias Scharwies]

Servus!

Moin Matthias,

Dazu einige Fragen/Bitten:

welche „falsche ‚das‘“? Das ist hier doch ein Relativsatz. (Oder vermutest Du, dass die „KI“ mit gängigen Texten aus dem „Internetz“ trainiert worden ist? 😉).

Oh Gott - ich wollte das noch kurz vor Arbeitsbeginn fertigstellen und da kommt so wass raus! 😀

Könntest Du mal testen und gucken, ob bei Dir was auffällt, was man im Tutorial hinzufügen könnte.

Herzliche Grüße

Matthias Scharwies

[Robert B.]

Moin Matthias,

Neu ist der Abschnitt Eingabehilfen

Dazu einige Fragen/Bitten:

• Wer könnte auf einem Android-Gerät einen Screenshot des autocomplete-Beispiels mit autocomplete="new-password" machen?

Chrome auf Android zeigt nichts Besonderes an, allerdings bietet Firefox ein automatisch generiertes Passwort an:

• Wie sieht das writingsuggestions Beispiel bei Euch aus? (Nur Chromium-Browser)

Ab welcher Version soll da denn etwas implementiert sein?

Viele Grüße Robert

[Matthias Scharwies]

Servus!

Chrome auf Android zeigt nichts Besonderes an, allerdings bietet Firefox ein automatisch generiertes Passwort an:

Danke!

Ab welcher Version soll da denn etwas implementiert sein?

https://caniuse.com/mdn-api_htmlelement_writingsuggestions

Chrome 124, Edge 124 und Opera 110.

Herzliche Grüße

Matthias Scharwies

[Robert B.]

Moin Matthias,

• Wie sieht das writingsuggestions Beispiel bei Euch aus? (Nur Chromium-Browser)
  Bei mir wird im Satz: "Es war einmal ein Mächen, das durch den Wald ging" nur das Wort Mächen rot unterringelt und mit 3 Textvorschlägen ergänzt; das falsche das wird nicht bemängelt.

wie sollen denn die Vorschläge genau funktionieren? Gibt es da eine

• bestimmte Browser-Einstellung
• Tastenkombination
• Kontextmenü
• Hardware

die ich verwenden muss?

Viele Grüße
Robert

[Matthias Scharwies]

Hallo zusammen,

wie sollen denn die Vorschläge genau funktionieren? Gibt es da eine

• bestimmte Browser-Einstellung
• Tastenkombination
• Kontextmenü
• Hardware

die ich verwenden muss?

Nein, einfach mal nur was euch auffällt:

Chrome 128 unter Win11

Bei den unterringelten Wörtern werden im Kontextmenü Alternativen angeboten. "welcher" und "Walt" werden nicht angestrichen.

Interessant, dass Word ganz viele Wörter unterringelt, die es einfach nicht im Wörterbuch hatte - der Begriff Hormonröschen (vom Frystyxradio von FFN) von Chrome als ok erkannt oder zumindest nicht bemängelt wird.

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Servus!

Ich habe ein neues Problem:

Hier gibt es ein Beispiel mit autocomplete="new-password":

Formulare/Eingabe von text Sonderfall type = "password"

Selbst autocomplete=off wird bei aktivertem Passwortmanager (Firefox), Google Passwortmananger (Chrome) bzw Microsoft Wallet (Edge) ignoriert und alle bisher je eingegebenen Passwörter zum Einfügen angeboten.

Habt ihr Tipps - außer einer Riesenwarnung, solche Services nur sparsam zu nutzen?

Das ist natürlich für das Tutorial, zu Hause steh ich aber vor einem ähnlichen Problem: Neben der Bank Card kriegt das Kind jetzt Online-Banking - Sollen die Passwörter gespeichert werden (geht ja so einfach), bis dann mal der Kumpel 5min alleine drüber hockt. Ja, ich weiß, Überweisungen müssen erst in der App bestätigt werden. Trotzdem.

Herzliche Grüße

Matthias Scharwies

[Camping_RIDER]

Aloha ;)

Selbst autocomplete=off wird bei aktivertem Passwortmanager (Firefox), Google Passwortmananger (Chrome) bzw Microsoft Wallet (Edge) ignoriert und alle bisher je eingegebenen Passwörter zum Einfügen angeboten.

Ja - das entspricht auch meimer Erfahrung. Dieses Attribut wird bei Passwortfeldern schlicht ignoriert.

Besonders schlimm ist das bei "uneigentlichen" Passwortfeldern - also Passwörtern, die nicht wie ein normales Passwort zum Anmelden verwendet werden.

Zwei Beispiele aus dem Kontext von DAFUK^[1]:

• Eingabe der Antwort auf eine zufällig gestellte Sicherheitsfrage als 2FA: da sich die richtige Antwort jedesmal ändert will man nicht random eine Antwort eingespeichert haben - zumal das fehlende Benutzernamen-Feld in Kombination mit dem existenten Benutzernamenfeld in der vorgelagerten Anmeldemaske sogar dafür sorgt, dass der Passwortmanager dann das korrekterweise gespeicherte Passwort überschreibt

• Eine Einstellungsseite mit IMAP- und SMTP-Zugangsdaten. Auch das sind Anmeldedaten, aber nicht meine, und ich will auch bei leeren Feldern um Gottes willen nicht, dass der Browser hier was voreinfüllt - was er aber tut (in anderen Systemen, z.B. WebUntis und DokuWiki ist das ein riesiges UX-Ärgernis!).

Habt ihr Tipps - außer einer Riesenwarnung, solche Services nur sparsam zu nutzen?

Ich kann zumindest den von mir gewählten alternativen Lösungsweg teilen.

Ich benutze in diesen Fällen, also bei Passwortfeldern für die auf keinen Fall der Passwortmanager einspringen soll, den Input-Type text statt password und erzeuge dann die nötige Abschirmung gegenüber wachsamen über die Schulter blickenden Augen dadurch, dass ich für das Textfeld einen Font verwende, in dem jede Glyphe ein Punkt ist - wie in einem Passwortfeld. Der Passwort-Peeker-Button schaltet dann den fürs Eingabefeld verwendeten Font um. Falls jemand den Font sucht: er heißt text-security-disk.

Grüße,

RIDER

---

1. DAFUK - Digitale Anlaufstelle für unterrichtsbezogene Koordination ↩︎

[Matthias Scharwies]

Servus!

Habt ihr Tipps - außer einer Riesenwarnung, solche Services nur sparsam zu nutzen?

Ich kann zumindest den von mir gewählten alternativen Lösungsweg teilen.

Ich benutze in diesen Fällen, also bei Passwortfeldern für die auf keinen Fall der Passwortmanager einspringen soll, den Input-Type text statt password und erzeuge dann die nötige Abschirmung gegenüber wachsamen über die Schulter blickenden Augen dadurch, dass ich für das Textfeld einen Font verwende, in dem jede Glyphe ein Punkt ist - wie in einem Passwortfeld. Der Passwort-Peeker-Button schaltet dann den fürs Eingabefeld verwendeten Font um. Falls jemand den Font sucht: er heißt text-security-disk.

Das klingt sehr gut! Vielen Dank! Ich schaue, dass das den Weg ins Wiki findet.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

ein Passwortmanager sollte eigentlich beim ersten Eingeben des Passworts fragen, ob er sich das merken soll. Und als Antwort anbieten: Ja, Jetzt nicht, Nie. Einmal "Nie" gewählt sollte weitere Angebote dieser Art verstummen lassen.

Ansonsten ist das eine Form der Medienkompetenz, die hier erworben werden muss. Die ersten Onlinebanking-Besuche solltest Du ihn nicht allein machen lassen. Bei der Gelegenheit lässt sich der Passwortmanager in die Schranken weisen.

Im Übrigen sind autocomplete und Passwortmanager zwei sehr unterschiedliche Biester. Die Werte für autocomplete sind über alle Webseiten gleich und sollen die Eingabe von Adressen etc einsparen, während ein Passwortmanager nur Usernamen und Passworte merkt und diese „sicher“ im Kontext des Users speichert. Wird ein PC mit gleichem Login von mehreren Personen benutzt, ist ein Passwortmanager eher nicht ratsam.

Oder habe ich das Problem nicht verstanden?

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

ein Passwortmanager sollte eigentlich beim ersten Eingeben des Passworts fragen, ob er sich das merken soll. Und als Antwort anbieten: Ja, Jetzt nicht, Nie. Einmal "Nie" gewählt sollte weitere Angebote dieser Art verstummen lassen.

Ja, genau! Und jetzt sei mal ehrlich: klickst du auf "Nie" oder wählst du den bequemen Weg?

Ich persönlich muss da mein Verhalten mal zumindest hinterfragen.

Ansonsten ist das eine Form der Medienkompetenz, die hier erworben werden muss. Die ersten Onlinebanking-Besuche solltest Du ihn nicht allein machen lassen. Bei der Gelegenheit lässt sich der Passwortmanager in die Schranken weisen.

Auf jeden Fall. Anscheinend haben alle 12-Jährigen eine Debit-Karte. Wir wollen das jetzt auch ganz langsam angehen lassen. Bis jetzt kriegt er noch nicht mal Taschengeld, weil er von Groß- und Urgroßeltern so viel Cash mit heimnimmt - ist unpädagogisch, aber was kann ich gegen meine Schwiegerleut' ausrichten? 😀

Im Übrigen sind autocomplete und Passwortmanager zwei sehr unterschiedliche Biester. Die Werte für autocomplete sind über alle Webseiten gleich und sollen die Eingabe von Adressen etc einsparen, während ein Passwortmanager nur Usernamen und Passworte merkt und diese „sicher“ im Kontext des Users speichert. Wird ein PC mit gleichem Login von mehreren Personen benutzt, ist ein Passwortmanager eher nicht ratsam.

Genau das muss man in font-size:5em; color:red; jedem hinter die Ohren schreiben. Und da ist mein Desktop-Computer wohl noch ok, mein Dienst-Laptop und das Surface eben eher nicht. Und der Anfänger-Laptop meines Sohnes ist da eben auch kein Single-User-Device.

Oder habe ich das Problem nicht verstanden?

Doch, aber ich eben erst kurz vor Schreiben des Posts. Die Beispiele erhalten vom Passwortmanager Vorschläge zu allen selfhtml-Logins, die ich je hatte, wie blog.selfhtml.org, intern.selfhtml.orgvon 2014 und ebenso forum.de.selfhtml.org - Wahnsinn!

[EDIT] Hab grad den Inkognito-Modus probiert - auch da hilft der Passwortmanager! [/EDIT]

Herzliche Grüße

Matthias Scharwies