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

2 68

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

Rolf B
  • datenschutz
  • html
  • ki
  1. 1
    Robert B.
    1. 0
      Rolf B
      1. 0
        Robert B.
    2. 0
      Gunnar Bittersmann
      • browser
      • datenschutz
      • html
      1. 0
        Rolf B
        1. 0
          Robert B.
        2. 0
          Gunnar Bittersmann
          1. 0
            Gunnar Bittersmann
            • browser
            • windows
            1. 0
              Robert B.
      2. 0
        Robert B.
        1. 0
          Gunnar Bittersmann
          • css
          • datenschutz
          • html
          1. 0
            Rolf B
            1. 0
              Gunnar Bittersmann
              1. 0
                Rolf B
                1. 0
                  Gunnar Bittersmann
                  1. 0
                    Camping_RIDER
                    1. 0
                      Gunnar Bittersmann
                      1. 0
                        Camping_RIDER
                        1. 0
                          Gunnar Bittersmann
                          1. 0
                            Rolf B
                            1. 1
                              Gunnar Bittersmann
                        2. 0
                          Robert B.
                          • formulare
                          • html
                          1. 0
                            Camping_RIDER
                  2. 0
                    Robert B.
                    • datenschutz
                    • html
          2. 0
            Robert B.
      3. 0
        Gunnar Bittersmann
        1. 1
          nicht leer
          1. 0
            Gunnar Bittersmann
            • browser
            • design
            • ux
            1. 0
              Robert B.
  2. 0
    Matthias Scharwies
    • datenschutz
    • ki
    1. 0

      Eingabehilfen mit 'writingsuggestions'

      Matthias Scharwies
      • datenschutz
      • formulare
      • ki
      1. 0
        Robert B.
        • sprache
        1. 0
          Matthias Scharwies
      2. 0
        Robert B.
        1. 0
          Matthias Scharwies
      3. 0
        Robert B.
        1. 0
          Matthias Scharwies
    2. 0

      type = "password" - autocomplete="off" wird durch Passwortmanager ausgehebelt

      Matthias Scharwies
      • datenschutz
      • ki
      • sicherheit
      1. 0
        Camping_RIDER
        1. 0
          Matthias Scharwies
      2. 0
        Rolf B
        1. 0
          Matthias Scharwies
          1. 0
            Jonathan Harker
    3. 0

      writingsuggestions="false"

      Matthias Scharwies
  3. 0

    Toggle password display

    Matthias Scharwies
    • browser
    • design
    • ux
    1. 0
      Gunnar Bittersmann
      1. 0
        Matthias Scharwies
    2. 0
      Robert B.
      1. 0
        Gunnar Bittersmann
        1. 0
          Robert B.
          1. 0
            Gunnar Bittersmann
            • betriebssystem
            • browser
            1. 0
              Robert B.
            2. 0
              Gunnar Bittersmann
              • browser
            3. 0
              Gunnar Bittersmann
              • menschelei
  4. 0
    Michael_K
    1. 1

      AI stoppen

      Matthias Scharwies
      1. 0
        Michael_K
        1. 0
          Auge
          • browser
          • datenschutz
          • ki
          1. 0
            Camping_RIDER
            1. 0
              Michael_K
              1. 0
                Rolf B
                1. 0
                  Michael_K
                  1. 0
                    Auge
                    1. 2
                      Rolf B
                      1. 0
                        Auge
                      2. 1
                        Gunnar Bittersmann
                        1. 0
                          Auge

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

--
sumpsi - posui - obstruxi
  1. 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

    1. 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

      --
      sumpsi - posui - obstruxi
      1. 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

    2. @@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

      --
      Ad astra per aspera
      1. 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

        --
        sumpsi - posui - obstruxi
        1. 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

        2. @@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

          --
          Ad astra per aspera
          1. @@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

            --
            Ad astra per aspera
            1. 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

      2. 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

        1. @@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

          --
          Ad astra per aspera
          1. 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

            --
            sumpsi - posui - obstruxi
            1. @@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

              --
              Ad astra per aspera
              1. 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

                --
                sumpsi - posui - obstruxi
                1. @@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

                  --
                  Ad astra per aspera
                  1. 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

                    --
                    Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Albers-Zoller
                    # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                    1. @@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

                      --
                      Ad astra per aspera
                      1. 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

                        --
                        Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Albers-Zoller
                        # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                        1. @@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

                          --
                          Ad astra per aspera
                          1. 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

                            --
                            sumpsi - posui - obstruxi
                            1. @@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

                              --
                              Ad astra per aspera
                        2. 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

                          1. 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

                            --
                            Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Albers-Zoller
                            # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                  2. 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

          2. 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

      3. @@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-securitytype="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

        --
        Ad astra per aspera
        1. (außer Edge unter Windows?)

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

          1. @@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

            --
            Ad astra per aspera
            1. 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

  2. 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

    --
    Das wirksamste Mittel gegen Sonnenbrand
    ist Urlaub am Ostseestrand!

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

    1. 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

      --
      Das wirksamste Mittel gegen Sonnenbrand
      ist Urlaub am Ostseestrand!
      1. 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

        1. 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

          --
          Das wirksamste Mittel gegen Sonnenbrand
          ist Urlaub am Ostseestrand!
      2. 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:
        Firefox auf Android schlägt ein Passwort vor

        Ab welcher Version soll da denn etwas implementiert sein?

        Viele Grüße Robert

        1. Servus!

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

          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

          --
          Das wirksamste Mittel gegen Sonnenbrand
          ist Urlaub am Ostseestrand!
      3. 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

        1. 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

          --
          Das wirksamste Mittel gegen Sonnenbrand
          ist Urlaub am Ostseestrand!
    2. 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

      --
      Das wirksamste Mittel gegen Sonnenbrand
      ist Urlaub am Ostseestrand!
      1. 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

        --
        Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Albers-Zoller
        # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[

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

        1. 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

          --
          Das wirksamste Mittel gegen Sonnenbrand
          ist Urlaub am Ostseestrand!
      2. 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

        --
        sumpsi - posui - obstruxi
        1. 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

          --
          Das wirksamste Mittel gegen Sonnenbrand
          ist Urlaub am Ostseestrand!
          1. „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

            --
            "Ich habe heute ein Elan-Problem und mein Tatenvolumen ist fast aufgebraucht!"
    3. 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

      --
      Das wirksamste Mittel gegen Sonnenbrand
      ist Urlaub am Ostseestrand!
  3. 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

    --
    Das wirksamste Mittel gegen Sonnenbrand
    ist Urlaub am Ostseestrand!
    1. @@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

      --
      Ad astra per aspera
      1. 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

        --
        Das wirksamste Mittel gegen Sonnenbrand
        ist Urlaub am Ostseestrand!
    2. 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

      1. @@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

        --
        Ad astra per aspera
        1. 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:
          Passwort-Eingabe-Feld im Firefox mit der Option um Passworte anzuzeigen und einem zusätzlichen Button zum Umschalten
          Passwort-Eingabe-Feld im Firefox mit angezeigtem Passwort per Browser-Funktion

          Viele Grüße
          Robert

          1. @@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:
            Passwort-Eingabe-Feld im Firefox mit der Option um Passworte anzuzeigen und einem zusätzlichen Button zum Umschalten
            Passwort-Eingabe-Feld im Firefox mit angezeigtem Passwort per Browser-Funktion

            … 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

            --
            Ad astra per aspera
            1. 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

            2. @@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

              --
              Ad astra per aspera
            3. @@Gunnar Bittersmann

              Kein Auge weit und breit.

              Oh, doch. 👁️

              Kwakoni Yiquan

              --
              Ad astra per aspera
  4. 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

    1. 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 :

      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

      --
      Was ist eine Signatur?

      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. ↩︎

      1. 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

        1. 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

          --
          „Habe ich mir das nur eingebildet, oder kann der kleine Hund wirklich sprechen?“ fragte Schnapper. „Er behauptet, nicht dazu imstande zu sein“ erwiderte Victor. Schnapper zögerte (…) „Nun …“ sagte er schließlich, „ich schätze, er muss es am besten wissen.“ Terry Prattchett, Voll im Bilde
          1. 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

            --
            Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Albers-Zoller
            # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
            1. 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

              1. 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

                --
                sumpsi - posui - obstruxi
                1. 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.

                  1. 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

                    --
                    „Habe ich mir das nur eingebildet, oder kann der kleine Hund wirklich sprechen?“ fragte Schnapper. „Er behauptet, nicht dazu imstande zu sein“ erwiderte Victor. Schnapper zögerte (…) „Nun …“ sagte er schließlich, „ich schätze, er muss es am besten wissen.“ Terry Prattchett, Voll im Bilde
                    1. 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

                      --
                      sumpsi - posui - obstruxi
                      1. 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

                        --
                        „Habe ich mir das nur eingebildet, oder kann der kleine Hund wirklich sprechen?“ fragte Schnapper. „Er behauptet, nicht dazu imstande zu sein“ erwiderte Victor. Schnapper zögerte (…) „Nun …“ sagte er schließlich, „ich schätze, er muss es am besten wissen.“ Terry Prattchett, Voll im Bilde
                      2. @@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

                        --
                        Ad astra per aspera
                        1. 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

                          --
                          „Habe ich mir das nur eingebildet, oder kann der kleine Hund wirklich sprechen?“ fragte Schnapper. „Er behauptet, nicht dazu imstande zu sein“ erwiderte Victor. Schnapper zögerte (…) „Nun …“ sagte er schließlich, „ich schätze, er muss es am besten wissen.“ Terry Prattchett, Voll im Bilde