[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

[Jonathan Harker]

„Mist, mein Account wurde gehackt!“

„Hattest du ein schlechtes Passwort?“

„Nein, überhaupt nicht! Das Jahr der Heiligsprechung des Heiligen Dominikus durch Papst Gregor den IX!“

„Wann war das?“

„1234.“

---

Bis bald!

Jonathan

[Matthias Scharwies]

Hallo zusammen,

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

Weiß jemand mehr darüber?

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

Formulare/Eingabe von Text

Bei 3.2 writingsuggestions ist alles relativ knapp gehalten.

Ich finde, dass alle Browser nur wenige Wörter unterringeln und Korrekturen vorschlagen.

Ich weiß aber nicht, inwieweit ich dort an den Browser-Einstellungen fummeln kann, bzw. soll und wie das dann in den Wiki-Artikel soll.

Sonderfall type = "password"

@Rolf B Das 1. Beispiel hatte mich mit meinem Passwort-Manager, der für SELFfHTML 12 Logins angeboten hatte, zur Verzweiflung gebracht. Das wird ein Schüler im Computerraum so nicht haben.

Das zweite Beispiel des sichtbar-Machens ist von setAttribute() hierherverschoben und durch writingsuggestions="false" ergänzt.

Ich glaube, dass man da der Spec folgen soll und eben writingsuggestions="false" spellcheck="false" setzen muss. Wenn das noch niemand kennt, ist das eben unsere Aufgabe, das in unseren Tutorials zu empfehlen.

Und diese ganze Irritiation habe ich in den letzten Abschnitt gepackt:

Passwortmanager - Fluch und Segen

Das war mein Damaskus-Erlebnis: Bis jetzt sah ich den Passwortmanager als bequeme Beschleunigung meines Arbeitsprozesses. Erst auf dem Rechner meines Sohnes fragte ich mich, ob das wirklich sinnvoll sei, Passworteingaben derart auszuhebeln.

Und jetzt wird mir klar, warum alle möglichen Webseiten (z.B. github) in der letzten Zeit auf 2FA umgestiegen sind. Es gibt eben keine Passwortsicherheit mehr!

Was mich so konfus macht: Das stand ja schon bei autocomplete (ist dort immer noch) und wird in diesem Abschnitt hoffentlich verständlich erklärt.

Ich habe zusätzlich 2 Cards zu weiterführenden Artikeln angelegt. Da müsste das eigentlich auch noch rein.

Bitte gebt mir ein Feedback, ob das so passt.

Morgen am Discord-Stammtisch werde ich das vorstellen und diskutieren.

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Guten Morgen,

irgendwo in diesem Thread ging es um's Umschalten von type="password", damit man Eingaben sehen könne.

Anscheinend arbeitet(e) Mozilla an einer browsereigenen Lösung:

Toggle password display in Experimental features in Firefox

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Anscheinend arbeitet(e) Mozilla an einer browsereigenen Lösung:

Toggle password display in Experimental features in Firefox

Was daraus wurde, ist sch…ade.

Dabei wurde im Bugtracker die „low discoverability“ (meine Rede) angemerkt – vor 9 Jahren schon!

Ich muss mir den Thread mal durchlesen, um ein Verständnis dafür zu entwickeln, woran es hakt. Oder auch nicht – vielleicht bleibt am Ende nur Kopfschütteln.

Kwakoni Yiquan

[Matthias Scharwies]

Servus!

@@Matthias Scharwies

Anscheinend arbeitet(e) Mozilla an einer browsereigenen Lösung:

Toggle password display in Experimental features in Firefox

include an "eye" icon that can be toggled

Right-clicking on password fields now shows …

Was daraus wurde, ist sch…ade.

Zumindest an deine Antwort kann ich mich jetzt erinnern.

Vielleicht kommt's ja doch irgendwann richtig!

Herzliche Grüße

Matthias Scharwies

[Robert B.]

Moin Matthias,

Anscheinend arbeitet(e) Mozilla an einer browsereigenen Lösung:

Toggle password display in Experimental features in Firefox

zumindest im Kontextmenü eines Passwort-Feldes gibt es die Option zum Anzeigen bereits. Aber schön, dass es auch ein Icon dafür geben wird.

Viele Grüße
Robert

[Gunnar Bittersmann]

@@Robert B.

Anscheinend arbeitet(e) Mozilla an einer browsereigenen Lösung:

Toggle password display in Experimental features in Firefox

zumindest im Kontextmenü eines Passwort-Feldes gibt es die Option zum Anzeigen bereits. Aber schön, dass es auch ein Icon dafür geben wird.

Wo hast du das her?

Aus dem dort (und auch schon hier) verlinkten Thread im Bugtracker sollte hervorgehen, das man sich bislang gegen ein Icon entschieden hat. Warum auch immer.

Kwakoni Yiquan

[Robert B.]

Moin Gunnar,

Toggle password display in Experimental features in Firefox

zumindest im Kontextmenü eines Passwort-Feldes gibt es die Option zum Anzeigen bereits. Aber schön, dass es auch ein Icon dafür geben wird.

Wo hast du das her?

Ich verstehe das oben verlinkte so.

HTML password input elements (<input type="password">) include an "eye" icon that can be toggled to display or obscure the password text (Firefox bug 502258).

… Enabled by default? No

Preference name: layout.forms.reveal-password-button.enabled

In meinem Firefox funktioniert es wie erwartet:

Viele Grüße
Robert

[Gunnar Bittersmann]

@@Robert B.

Preference name: layout.forms.reveal-password-button.enabled

Hab ich auch gleich gesetzt, als ich es gelesen hab …

In meinem Firefox funktioniert es wie erwartet:

… in meinem aber nicht. Kein Auge weit und breit.

Bist du mit Windows unterwegs? Nutzt der Fuchs da auch die OS-Routine wie der Edge? Und deshalb funktioniert das mit dem Passwort-anzeigen-Icon nicht auf macOS und Linux?

Kwakoni Yiquan

[Robert B.]

Moin Gunnar,

Bist du mit Windows unterwegs? Nutzt der Fuchs da auch die OS-Routine wie der Edge? Und deshalb funktioniert das mit dem Passwort-anzeigen-Icon nicht auf macOS und Linux?

an Windows komme ich erst am Montag wieder heran, hier werkelt ein Linux Mint 21.3 mit Firefox 131.0.

Viele Grüße
Robert

[Gunnar Bittersmann]

@@Gunnar Bittersmann

… in meinem aber nicht. Kein Auge weit und breit.

Ah, doch. Aber erst, nachdem man was eingetippt hat. Warum das denn?

Und tastaturbedienbar ist das Ding nicht?

Und warum hinterm Feature-Flag?

Kwakoni Yiquan

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Kein Auge weit und breit.

Oh, doch. 👁️

Kwakoni Yiquan

[Michael_K]

Hallo Rolf,

vielen Dank für die Info! Ich bin regelrecht zusammengezuckt, als ich lesen musste, dass die KI scheinbar den Inhalt automatisch mitliest, wenn man nicht die richtigen Attribute setzt.

In einigen Unterbeiträgen wird auch erwähnt, dass ein editable=true ebenso das Mitlesen der AI triggered. Deshalb meine Frage, gibt es auf selfhtml oder irgendwo sonst eine Zusammenfassung, wann und wie Microsoft die Seiteninhalte mit Edge der KI zuführt? Und ob man irgendwie an einer einzigen Stelle bestimmen kann, ob die Inhalte nicht ausgelesen werden dürfen? Kann man ggfs.auch Server-seitig beim Ausliefern der Webseite headers setzen, dass eine KI nichts auf den Inhalt der Webseite zugreifen darf? Ich vermute, dass ein Service Worker, der die ausgehenden fetch-Anfragen abfängt, auch nicht hilft? Das ist wirklich gruselig und müsste eigentlich schon längst in den (Fach)Medien hoch und runter diskutiert werden.

Gruss Michael

[Matthias Scharwies]

Guten Morgen,

In einigen Unterbeiträgen wird auch erwähnt, dass ein editable=true ebenso das Mitlesen der AI triggered.

Du meinst hier, da geht es um das contenteditable-Attribut, mit dem du „normale“ Elemente editierbar machen kannst.

Deshalb meine Frage, gibt es auf selfhtml oder irgendwo sonst eine Zusammenfassung, wann und wie Microsoft die Seiteninhalte mit Edge der KI zuführt?

Nein, noch nicht. Habe eben grad gesucht - es gab im Mai, Juni einige Blogartikel^[1] drüber - die müsste man auswerten und den Stand der Dinge zusammenfassen.

Und ob man irgendwie an einer einzigen Stelle bestimmen kann, ob die Inhalte nicht ausgelesen werden dürfen? Kann man ggfs.auch Server-seitig beim Ausliefern der Webseite headers setzen, dass eine KI nichts auf den Inhalt der Webseite zugreifen darf?

Robots.txt

Dazu :

• Several AI companies said to be ignoring robots dot txt exclusion, scraping content without permission: report (tomshardware.com)
• Defining best practices for opting out of ML training (openfuture.eu)

Das ist wirklich gruselig und müsste eigentlich schon längst in den (Fach)Medien hoch und runter diskutiert werden.

Ja.

Herzliche Grüße

Matthias Scharwies

---

1. tl;dr
   Das Startup TollBit bietet Webseitenbetreibern an, ihren Content zu lizensieren und künfitg zu monetarisieren. Sie behaupten, dass robots.text umgangen wird und wollen helfen.
   Diese Meldung wurde von Blogs immer wieder nacherzählt. ↩︎

[Michael_K]

Hallo Matthias,

mir geht es insbesondere um die Fragestellung, ob der Edge als Web-Browser von Microsoft etwas nach Hause funkt, wenn die geladenen Webseite im HTML entsprechende Syntax enthalten bzw. nicht enthalten. Es wäre ein sicherheitstechnischer Alptraum, wenn der Edge Inhalte eines Intranets für AI Zwecke ausliest/auswertet.

Gruss Michael

[Auge]

Hallo

mir geht es insbesondere um die Fragestellung, ob der Edge als Web-Browser von Microsoft etwas nach Hause funkt, wenn die geladenen Webseite im HTML entsprechende Syntax enthalten bzw. nicht enthalten. Es wäre ein sicherheitstechnischer Alptraum, wenn der Edge Inhalte eines Intranets für AI Zwecke ausliest/auswertet.

Hier geht es ja speziell um das Auslesen von Passwortfeldern, deren Typ auf „text“ umgeschaltet wurde, was durch das geeignete setzen von Attributen verhindert werden soll. Diese Attribute stehen auch anderen Eingabefeldern zur Verfügung.

Ist es den überhaupt möglich oder sinnvoll, ganze Dokumente (abseits von Formulareingabefeldern) mit diesen Attributen zu versehen, um sie vor dem Auslesen zu schützen? Und verliert man mit dem Kaprizieren auf Microsofts AI nicht aus dem Blick, dass die Seiteninhalte auch für andere Zwecke an externe Dienste übermittelt werden? Mir fällt da zuallererst die Rechtschreibkorrektur von Google ein, für die (zumindest) die Daten aus Eingabefeldern an Google-Server übermittelt werden, was speziell bei den hier diskutierten lesbar gemachten Passwortfeldern kein bisschen unkritischer ist.

Bezüglich „normaler“ Seiteninhalte sollte sowas auf Netzseite geregelt werden, unter Windows vielleicht durch eine Gruppenrichtlinie.

Tschö, Auge

[Camping_RIDER]

Aloha ;)

Mir fällt da zuallererst die Rechtschreibkorrektur von Google ein, für die (zumindest) die Daten aus Eingabefeldern an Google-Server übermittelt werden, was speziell bei den hier diskutierten lesbar gemachten Passwortfeldern kein bisschen unkritischer ist.

Richtig. Und da muss man nicht beim Browserhersteller anfangen - auch das Betriebssystem kann prinzipiell alle Daten abgreifen. Wenn man sich Sorgen macht, dass Intranetinhalte von Microsofts Edge an Microsoft verschickt werden könnten, um damit dort KI zu trainieren, dann frage ich mich, warum man sich so sicher ist, dass Microsofts Windows nicht eh das selbe tut. Und vielleicht auch gleich noch der Microsoft-Server, auf dem die Intranetinhalte laufen.

Ich will nicht sagen, dass alles und jedes zwangsläufig nach Hause telefoniert und Daten entführt - nur in Erinnerung rufen, dass man dem Betriebssystemhersteller und dem Browserhersteller und ggf. dem Hardwarehersteller sowieso vertrauen muss - und wenn man dieses Vertrauen nicht aufbringen kann, dann darf man die Software und das Betriebssystem und die Hardware eben nicht benutzen.

(Was nicht heißen soll, dass dieser Thread hier unberechtigt war - im Spezialfall der Passwortfelder macht es viel Sinn, sich Gedanken zu machen, wie man diese besonders sensiblen Daten besonders gut abschirmt - aber weitergehende Gedankenspiele wie "alle Inhalte im Intranet" sind sicher nicht sinnvoll.)

Grüße,

RIDER

[Michael_K]

Hallo,

ich glaube, dass dein/Ihr Beitrag etwas am Thema vorbeizielt. Es geht nicht um das allgemeine Vertrauen eines Betriebssystems oder des Browsers, außerhalb der Spezifikation Informationen des Webinhalts unbefugt, d.h. strafbewährt, nach aussen zu kommunizieren. Vielmehr geht es um die Fragestellung und Bedenken, wenn ein Browser auf Basis von Spezifikationssystax berechtigt ist, Webinhalte auszulesen.

Und mir geht es nicht um input[type=text]. Mir stellt sich die Frage, was der Edge Browser macht, wenn z.B. das Attribute @contenteditable=true gesetzt ist. Contenteditable ist nach meinem Verständnis ein allgemeines Attribute und man kann es an jedes Element im Document-Body setzen.

Ganz konkret gefragt: Was passiert im Edge, wenn z.B. ein Mitarbeiter in seinem Browser über den DOM-Inspektor das Attribute contenteditable="true" auf den sensiblen Inhalt einer Intranetseite setzt? Es wäre ein sicherheitstechnischer Alptraum, wenn hierdurch Edge den Inhalt legitim auslesen und an irgendeinen Server schicken dürfte, um tolle KI-Vorschläge zu unterbreiten.

Gruss

[Rolf B]

Hallo Michael,

Unternehmen sollten für Edge ein Entra-Konto nutzen.

Inwieweit man das umgehen kann und wie es in anderen Chromia handhabt, weiß ich nicht.

Rolf

[Michael_K]

Oh man, das wird ja immer komplizierter. Jetzt verhält sich ein Browser unterschiedlich in Abhängigkeit vom Nutzerkonto. Gibt es da keine Möglichkeit, den Browser an einer Stelle zu sagen "Du darfst nichts von dieser Webseite verwenden".

Wir haben so viele Extra-Super-Duper Features in HTML, aber eine einfache Syntax zum Schutz vor unberechtigter Weitergabe/Auslesen von Inhalten gibt es nicht? Im HTML-Kopfbereich is genug Platz. Natürlich kann sich eine Browser-Hersteller dem verweigern, aber dann wäre ein "name and shame" viel einfacher durchzuführen, d.h. als nicht standardkonform zu deklarieren. Ich sehe hier zwingenden Handlungsbedarf vom W3C.

[Auge]

Hallo

Gibt es da keine Möglichkeit, den Browser an einer Stelle zu sagen "Du darfst nichts von dieser Webseite verwenden".

Wir haben so viele Extra-Super-Duper Features in HTML, aber eine einfache Syntax zum Schutz vor unberechtigter Weitergabe/Auslesen von Inhalten gibt es nicht? Im HTML-Kopfbereich is genug Platz. Natürlich kann sich eine Browser-Hersteller dem verweigern, aber dann wäre ein "name and shame" viel einfacher durchzuführen, d.h. als nicht standardkonform zu deklarieren.

Und dann soll man in jedes HTML-Dokument reinschreiben, dass keine Inhalte woandershin übermittelt werden sollen, wohl wissend, dass Browserhersteller das, „name and shame“ hin oder her, ignorieren können/werden?

Ich sehe hier zwingenden Handlungsbedarf vom W3C.

Ich nicht. Das gehört, wenn dann, ins OS (wo es genauso gut ignoriert werden kann). Das gilt insbesondere für geschlossen bleiben sollende Systeme wie ein Firmen- mit Intranet.

Tschö, Auge

[Rolf B]

Hallo Auge,

gerade nochmal nachgelesen: man kann es ins HTML hineinschreiben:

<body writingsuggestions="false">
...
</body>

das gilt dann für die ganze Seite. Das schützt natürlich nicht vor Leuten, die per Inspector das DOM manipulieren und das Attribut wegnehmen. Das kann ein Unternehmen aber per Policy generell verbieten (und sollte es für Developer tunlichst unterlassen…)

Ob ich so ein Business-Konto habe, weiß ich nicht, aber dieser Edge hier bot mir gerade die AI-unterstützte Verbesserung einer Texteingabe an. Nach etwas Suche fand ich dann im Einstellungsabschnitt „Sprachen“ Schalter, um dem Copiloten die Augen zu verbinden. Ob er trotzdem noch blinzelt, weiß natürlich nur der Drahthai. Und warum das in „Sprachen“ und nicht unter „Datenschutz, Suche und Dienste“ steht, mag der Schelm beantworten, der sich das ausgedacht hat.

Rolf

[Auge]

Hallo

Hallo Auge,

gerade nochmal nachgelesen: man kann es ins HTML hineinschreiben:

<body writingsuggestions="false">
...
</body>

das gilt dann für die ganze Seite.

Dass es so funktionieren mag, wollte ich auch nicht in Zweifel ziehen. Vielmehr wollte ich darauf hinweisen, dass das fehleranfällig ist, weil jeder Autor es entweder in jedes Dokument, das im Intranet verfügbar gemacht werden woll, reinschreiben muss oder ausschließlich Systeme zur Dokumenterstellung genutzt werden müssen, die das von sich aus reinschreiben und es nicht zulassen, es manuell zu entfernen.

Ich halte das für ein instabiles System, denn jede Umgehung dieser Regel (egal, ob bewusst oder aus Versehen) führt potentiell zum Datenabfluss. Deshalb mein Verweis auf eine systemweite Einstellung.

Ob ich so ein Business-Konto habe, weiß ich nicht, aber dieser Edge hier bot mir gerade die AI-unterstützte Verbesserung einer Texteingabe an. Nach etwas Suche fand ich dann im Einstellungsabschnitt „Sprachen“ Schalter, um dem Copiloten die Augen zu verbinden.

In einem Firmennetzwerk, wovon bei einem Intranet auszugehen ist, will man das natürlich zentral für alle gemeinsam festlegen.

Und warum das in „Sprachen“ und nicht unter „Datenschutz, Suche und Dienste“ steht, mag der Schelm beantworten, der sich das ausgedacht hat.

Wovon man nichts weiß, …

Tschö, Auge

[Gunnar Bittersmann]

@@Rolf B

Ob er trotzdem noch blinzelt, weiß natürlich nur der Drahthai.

Mal nachfragen? Fragen Sie Microsoft: Trainiert ihr eure KI mit unseren persönlichen Daten? (Petition)

Kwakoni Yiquan

[Auge]

Hallo

Ob er trotzdem noch blinzelt, weiß natürlich nur der Drahthai.

Mal nachfragen? Fragen Sie Microsoft: Trainiert ihr eure KI mit unseren persönlichen Daten? (Petition)

Dumm nur, dass die, die diese Frage stellen, mit dem Stein in der Hand im Glashaus sitzen.

Tschö, Auge