[go: up one dir, main page]

Versionshinweise für Chrome Enterprise und Chrome Education

Zuletzt aktualisiert am 17. Oktober 2025 

Für Administratoren, die den Chrome-Browser oder ChromeOS-Geräte in einem Unternehmen oder einer Bildungseinrichtung verwalten.

 

Wählen Sie den gewünschten Tab aus, um Updates zum Chrome-Browser oder zu ChromeOS zu sehen.

 

Übersicht über Chrome-Version 141

 
Änderungen am Chrome-Browser Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Neues heuristisches Signal für die Übernahme von Suchanfragen in der Telemetrie von Erweiterungen    
Gemini in Chrome    
Fußzeile auf der Seite „Neuer Tab“
Remote-Befehle für Profile mit Drittanbieterauthentifizierung    
An Ursprünge gebundene Prozessisolierung    
Strenge Richtlinie zum gleichen Ursprung für die Storage Access API    
Neue Richtlinien im Chrome-Browser    
Änderungen bei Chrome Enterprise Core Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Unterstützung von registrierten Browsern für die Anpassungen des Chrome Web Store für Unternehmen  
Von Unternehmen verwaltete Verknüpfungen auf der Seite „Neuer Tab“  
Löschen inaktiver Profile in Chrome Enterprise Core  
Änderungen bei Chrome Enterprise Premium Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Wasserzeichen anpassen  
Anstehende Änderungen für den Chrome-Browser Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Einschränkungen für den Zugriff auf lokales Netzwerk    
Unterstützung mehrerer Profile in der Freigabeerweiterung für Chrome unter iOS     
Vereinfachte Anmeldung und Synchronisierung in Chrome für Computer  
Gebündelte Sicherheitseinstellungen    
„window.name“ für websiteübergreifende Seitenaufrufe löschen, bei denen die Gruppe für den Browserkontext gewechselt wird    
Unterstützung des clientseitigen LLM bei der Behebung von Betrugsfällen    
HSTS-Tracking-Schutz    
Interoperable „pointerrawupdate“-Ereignisse werden nur in sicheren Kontexten bereitgestellt    
Ursprungsgebundene Cookies (Standard)    
Post-Quanten-Kryptografie für DTLS in WebRTC    
Nutzeraktivierung bei Navigationen mit demselben Ursprung beibehalten    
Aktualisierung des Designs der Warnung „Kein HTTPS“    
Web-App-Manifest: Algorithmus für die Aktualisierungsberechtigung    
CSS-Pseudo-Elemente für das Hervorheben von Suchergebnissen auf der Seite    
Einstellung von „savedTabGroups“ als individueller Wert in „SyncTypesListDisabled“    
Happy Eyeballs V3  
ServiceWorkerAutoPreload    
Änderung des Early Stable-Einführungszeitplans      
Erzwingen der 2‑Faktor-Authentifizierung für Administratoren    
Verbieten von Leerzeichen in URL-Hosts ohne file://    
Richtlinien zur Drittanbieter-Speicherpartitionierung entfernen    
Migration von Safe Browsing API v4 zu v5    
X25519Kyber768-Schlüsselkapselung für TLS    
Isolierte Web-Apps    
Anbieter des Bedienungshilfen-Frameworks zur Automatisierung der Benutzeroberfläche unter Windows    
Bevorstehende Änderungen bei Chrome Enterprise Core Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Berichterstellung zu Profilen für Chrome unter iOS    
Bevorstehende Änderungen bei Chrome Enterprise Premium Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
UX-Refaktorierung für Chrome-Browserregeln  
Unterstützung größerer Dateien bei DLP-Scans  

 

Versionshinweise herunterladen (PDF)

↑ Zurück nach oben

Die Enterprise-Versionshinweise sind in neun Sprachen verfügbar. Informationen zu Chrome-Updates finden Sie auf Englisch, Deutsch, Französisch, Niederländisch, Spanisch, Portugiesisch, Koreanisch, Indonesisch und Japanisch. Bei manchen Sprachen kann die Übersetzung ein bis zwei Wochen in Anspruch nehmen.

Die Versionshinweise für Chrome Enterprise und Chrome Education werden in Übereinstimmung mit dem Chrome-Veröffentlichungszeitplan am Datum der ersten stabilen Version des Chrome-Browsers veröffentlicht.

 

Änderungen beim Chrome-Browser  

   

  • Neues heuristisches Signal für die Übernahme von Suchanfragen in der Telemetrie von Erweiterungen back to top

    Schädliche Chrome-Erweiterungen fangen Suchanfragen aus der Omnibox und der Realbox (dem Suchfeld auf der Seite Neuer Tab) auf der Suchmaschinenergebnisseite (SERP) ab und leiten sie an eine vom Angreifer kontrollierte URL weiter. Mit dieser Funktion wird eine clientseitige Heuristik hinzugefügt, um solche Suchmanipulationen zu erkennen. Die Grundidee besteht darin, von Nutzern initiierte Suchanfragen mit erfolgreichen SERP-Landungen zu vergleichen. Eine erhebliche Diskrepanz im Zeitverlauf deutet stark auf Hijacking-Aktivitäten hin. Mit dieser Heuristik wird ein neues Signal generiert, das über den vorhandenen Erweiterungs-Telemetriedienst in Chrome auf den Safe Browsing CRX-Telemetrieserver hochgeladen wird. Durch die serverseitige Analyse von Signaldaten aus mehreren Chrome-Browsern kann dann ein potenzielles Such-Hijacking erkannt werden.

    • Chrome 141 für ChromeOS, Linux, macOS und Windows

   

  • Gemini in Chrome back to top

    Gemini ist jetzt in Chrome unter macOS und Windows integriert und kann den Inhalt Ihrer aktuellen Seite verstehen. Nutzer können sich jetzt nahtlos die wichtigsten Punkte zusammenfassen lassen, Konzepte klären und Antworten finden, ohne ihren Chrome-Tab zu verlassen. Diese Integration umfasst sowohl den Chat, in dem Nutzer über Text mit Gemini interagieren können, als auch Gemini Live, mit dem Nutzer über Sprache mit Gemini interagieren können.

    In Chrome 141 wird Gemini in Chrome für die meisten Google Workspace-Nutzer mit Zugriff auf die Gemini App in den USA eingeführt. Administratoren können diese Funktion mit der Richtlinie GeminiSettings (Wert 1) oder mit der Richtlinie GenAiDefaultSettings (Wert 2) deaktivieren. Weitere Informationen finden Sie in der Gemini in Chrome-Hilfe oder in diesem Blogpost

    • Chrome 137 für macOS und Windows: Die Funktion ist für einige Google AI Pro- und Ultra-Abonnenten in den USA und in den Vorabversionen (Entwickler, Canary, Beta) in den USA verfügbar.
    • Chrome 141 für iOS, macOS und Windows: Die Funktion wird nach und nach in der stabilen Version für die meisten Google Workspace-Nutzer mit Zugriff auf die Gemini App in den USA eingeführt.
    • Chrome 143 für macOS und Windows: Einführung von Agent-Funktionen für Gemini in Chrome. Unternehmensrichtlinien werden zur Markteinführung verfügbar sein.
     

   

  • Fußzeile auf der Seite „Neuer Tab“ back to top

    Die Seite Neuer Tab wurde aktualisiert und enthält nun eine neue Fußzeile, die Nutzern mehr Transparenz und Kontrolle über die Nutzung von Chrome bietet.

     
    • Chrome 138 für ChromeOS, Linux, macOS und Windows: Die Attribution von Erweiterungen wird im NTP angezeigt. Wenn eine Erweiterung Ihre Standardseite Neuer Tab geändert hat, wird jetzt eine Meldung in der Fußzeile angezeigt, die diese Änderung der entsprechenden Erweiterung zuordnet. Diese Meldung enthält oft einen direkten Link zur Erweiterung im Chrome Web Store, sodass unerwünschte Erweiterungen leichter identifiziert und verwaltet werden können. Als Administrator können Sie diese Quellenangabe mit der Richtlinie NTPFooterExtensionAttributionEnabled deaktivieren.
     
    • Chrome 139 für Linux, macOS und Windows: Die Offenlegung der Browserverwaltung wird angezeigt, wenn eine der Richtlinien zum Anpassen der Fußzeile von einem Unternehmensadministrator festgelegt wird. Für Nutzer, deren Chrome-Browser von einer vertrauenswürdigen Quelle verwaltet wird, wird in der Fußzeile der Seite Neuer Tab jetzt ein Hinweis zur Verwaltung angezeigt. So können Sie nachvollziehen, wie Ihr Browser verwaltet wird. Administratoren können diese Benachrichtigung mit der Richtlinie NTPFooterManagementNoticeEnabled deaktivieren. Außerdem können Organisationen das Erscheinungsbild der Fußzeile mit den Richtlinien EnterpriseLogoUrlForBrowser und EnterpriseCustomLabelForBrowser anpassen, um ein benutzerdefiniertes Logo und Label anzuzeigen.
     
    • Chrome 141 für Linux, macOS und Windows: In der Fußzeile der Seite Neuer Tab wird für alle verwalteten Browser ein Standardhinweis (Wird von <domain name> verwaltet) angezeigt. Die Sichtbarkeit kann mit der Richtlinie NTPFooterManagementNoticeEnabled gesteuert werden. 
     
       

   

  • Remotebefehle für Profile mit Drittanbieterauthentifizierung back to top

    Mit dieser Funktion werden administrative Remote-Befehle wie das Löschen von Cache und Cookies für Chrome-Profile eingeführt, die über Drittanbieter-Identitätsanbieter authentifiziert werden. Durch diese Erweiterung können Administratoren jetzt auch diese neu unterstützten Profile verwalten und so eine größere Anzahl von Nutzerkonten per Remote-Zugriff verwalten.

     
    • Chrome 141 für Linux, macOS und Windows: Unterstützung von Remote-Befehlen für Profile mit Drittanbieterauthentifizierung 
       

   

  • An Ursprünge gebundene Prozessisolierung back to top

    Um die Sicherheit weiter zu verbessern, wechselt Chrome zu einem detaillierteren Prozessisolierungsmodell namens Ursprungsisolierung. Bisher hat Chrome die Website-Isolierung verwendet, bei der verschiedene Ursprünge derselben Website (z. B. a.beispiel.de und b.beispiel.de) in einem einzelnen Renderer-Prozess zusammengefasst wurden.

    Bei der Ursprungsisolation wird jeder einzelne Ursprung (z. B. https://foo.beispiel.de) in einem eigenen Renderer-Prozess isoliert. Diese Änderung stärkt die Sicherheitsarchitektur von Chrome, indem die Prozessgrenzen besser an das grundlegende ursprungsbasierte Sicherheitsmodell des Webs angepasst werden. So wird ein besserer Schutz vor potenziellen Sicherheitslücken auf Websites geboten. Die einzelnen Prozesse sind zwar kleiner, aber die höhere Prozessgranularität kann zu einer insgesamt höheren Arbeitsspeicher- und CPU-Auslastung führen. Um Sicherheit und Leistung in Einklang zu bringen, wird die Ursprungsisolation standardmäßig nur auf Geräten mit mindestens 4 GB RAM aktiviert.

    Administratoren können diese Funktion mit der Richtlinie OriginKeyedProcessesEnabled steuern.

     
    • Chrome 141 für Windows, macOS und Linux: Die Funktion wird nach und nach eingeführt.
       

   

  • Strenge Richtlinie zum gleichen Ursprung für die Storage Access API back to top

    In Chrome 141 folgen die Semantik der Storage Access API jetzt streng der Richtlinie zum gleichen Ursprung, um die Sicherheit zu erhöhen. Wenn Sie document.requestStorageAccess() in einem Frame verwenden, werden standardmäßig nur Anfragen an die Quelle des Iframes (nicht an die Website) mit Cookies versehen. Die Richtlinie CookiesAllowedForUrls oder Storage Access Headers können weiterhin verwendet werden, um websiteübergreifende Cookies zu entsperren.

     
    • Chrome 141 für Windows, macOS, Linux und Android
       

   

  • Neue Richtlinien im Chrome-Browser back to top
    Richtlinie Beschreibung
    NTPShortcuts Eine Liste von Verknüpfungen auf der Seite Neuer Tab konfigurieren 
    GloballyScopeHTTPAuthCacheEnabled Konfigurieren, ob der HTTP-Authentifizierungs-Cache auf eine Top-Level-Website oder einen Browser-Tab beschränkt ist 
      

Änderungen bei Chrome Enterprise Core

   

  • Unterstützung für Anpassungen des Enterprise Chrome Web Store in registrierten Browsern back to top

    Der personalisierte Chrome Web Store unterstützt jetzt verwaltete Browser, die für Chrome Enterprise Core (Cloud-Computereinstellungen) registriert sind. So können Administratoren den Chrome Web Store anpassen, ohne dass sich Nutzer anmelden müssen. Die Anpassungen umfassen:

    • Unternehmenslogos hinzufügen
    • Hero-Banner und benutzerdefinierte Ankündigungen hinzufügen
    • Erweiterungssammlungen kuratieren
    • Erweiterungskategorien ausblenden
     

    Die Einstellungen für die Anpassung des Chrome Web Store wurden bereits in Chrome 132 eingeführt, unterstützten aber nur Nutzerrichtlinien (für angemeldete Nutzer). Ab Chrome 140 ist diese Funktion für Trusted Tester von Chrome Enterprise Core verfügbar.

     
    • Chrome 141 für Linux, macOS und Windows: Diese Funktion wird bereits mit Chrome 141 allgemein verfügbar sein.
     

   

  • Von Unternehmen verwaltete Verknüpfungen auf der Seite „Neuer Tab“ back to top

    Verknüpfungen auf der Seite Neuer Tab können schnellen Zugriff auf interne Ressourcen und Anwendungen ermöglichen. Administratoren können mit der Richtlinie NTPShortcuts bis zu 10 Verknüpfungen auf der Seite Neuer Tab des Nutzers einrichten. Ab Chrome 141 ist diese Funktion für Trusted Tester von Chrome Enterprise Core verfügbar.

     
    • Chrome 141 für ChromeOS, Linux, macOS und Windows: Eine Vorabversion der Richtlinie ist für Trusted Tester verfügbar. Administratoren können bis zu 10 Verknüpfungen einrichten. Nutzer können zu den Verknüpfungen ihrer Organisation wechseln, indem sie zu Chrome anpassen gehen.
    • Chrome 143 für ChromeOS, Linux, macOS und Windows: Die Richtlinie ist allgemein verfügbar. Von Administratoren festgelegte Verknüpfungen werden zusätzlich zu den von Nutzern festgelegten Verknüpfungen („Meine Verknüpfungen“ oder „Am häufigsten besuchte Websites“) angezeigt. Nutzer können die Sichtbarkeit von Verknüpfungen im Bereich Chrome anpassen steuern.
     

   

  • Löschen inaktiver Profile in Chrome Enterprise Core back to top

    Im Juni 2025 wurde die Einstellung „Zeitraum von Inaktivität, nach dem das Profil gelöscht wird“, eingeführt. Ab September 2025 werden durch die Einstellung automatisch verwaltete Profile in der Admin-Konsole gelöscht, die über den festgelegten Inaktivitätszeitraum hinaus inaktiv waren. Beim Veröffentlichen der Einstellung hat der Inaktivitätszeitraum einen Standardwert von 90 Tagen. Das bedeutet, dass standardmäßig alle verwalteten Profile, die seit mehr als 90 Tagen inaktiv sind, aus Ihrem Konto gelöscht werden. 

    Administratoren können den Wert für den inaktiven Zeitraum mithilfe dieser Einstellung ändern. 

    • Der Höchstwert ist 730 Tage. 
    • Der Mindestwert beträgt 28 Tage.
     

    Wenn der festgelegte Wert gesenkt wird, kann sich das global auf alle derzeit verwalteten Profile auswirken. Alle betroffenen Profile werden als inaktiv betrachtet und daher gelöscht. Das Nutzerkonto wird dadurch nicht gelöscht. Wenn ein inaktives Profil auf einem Gerät reaktiviert wird, wird es wieder in der Konsole angezeigt.

     
    • Chrome 141 für Android, ChromeOS, Linux, macOS und Windows : Die Richtlinie wurde im Juni eingeführt. Das Löschen beginnt im September und die erste Welle wird bis Ende Oktober abgeschlossen sein. Nach dem ersten Löschvorgang werden inaktive Profile weiterhin gelöscht, sobald sie den Zeitraum der Inaktivität erreicht haben.
     

Änderungen bei Chrome Enterprise Premium

Weitere Informationen zu den Unterschieden zwischen Chrome Enterprise Core und Chrome Enterprise Premium

   

  • Wasserzeichen anpassen back to top  

    Mit Chrome Enterprise Premium können Administratoren jetzt das Aussehen von Wasserzeichen anpassen. Diese Verbesserung soll die Nutzerfreundlichkeit erhöhen und Probleme wie Augenbelastung und Lesbarkeit auf Seiten mit vorhandenen Wasserzeichen beheben.

    Administratoren können das Erscheinungsbild des Wasserzeichens über die neue Richtlinie WatermarkStyle steuern. In dieser Richtlinie können Administratoren Folgendes konfigurieren:

    • font_size: Legt die Schriftgröße des Texts in Pixel fest. 
    • fill_opacity: Legt die Fülldeckkraft des Texts fest, von 0 (transparent) bis 100 (undurchsichtig). 
    • outline_opacity: Legt die Konturdeckkraft des Texts von 0 (transparent) bis 100 (undurchsichtig) fest. 

    So haben Administratoren mehr Flexibilität, Sicherheitsanforderungen und Nutzerproduktivität in Einklang zu bringen.

    • Chrome 140 für ChromeOS, Linux, macOS und Windows: Mit dieser Version können Administratoren die Schriftgröße und Deckkraft von Wasserzeichen über die neue Richtlinie WatermarkStyle in der Admin-Konsole anpassen.

↑ Zurück nach oben  

Demnächst

Hinweis: Die unten aufgeführten Änderungen sind experimentelle oder geplante Updates. Sie können sich vor der Einführung der stabilen Version ändern, verzögern oder ganz entfernt werden.

 

Anstehende Änderungen für den Chrome-Browser

   

  • Einschränkungen für den Zugriff auf lokales Netzwerk back to top

    In Chrome 142 wird die Möglichkeit, Anfragen an das lokale Netzwerk des Nutzers zu senden, eingeschränkt. Dies ist nur noch mit einer Berechtigungsaufforderung möglich. Eine lokale Netzwerkanfrage ist eine Anfrage von einer öffentlichen Website an eine lokale IP-Adresse oder einen Loopback oder von einer lokalen Website (z. B. Intranet) an einen Loopback. Wenn Websites diese Anfragen nur mit einer Berechtigung ausführen können, wird das Risiko von Fälschungsangriffen bei websiteübergreifenden Anfrage gegen lokale Netzwerkgeräte wie Router verringert. Außerdem wird die Möglichkeit von Websites eingeschränkt, diese Anfragen zu verwenden, um das lokale Netzwerk des Nutzers zu identifizieren.

    Diese Berechtigung ist auf sichere Kontexte beschränkt. Wenn die Berechtigungen gewährt werden, wird die Blockierung von gemischten Inhalten für Anfragen an das lokale Netzwerk zusätzlich gelockert, da viele lokale Geräte aus verschiedenen Gründen keine öffentlich vertrauenswürdigen TLS-Zertifikate erhalten können.

    Diese Arbeit ersetzt eine frühere Initiative namens Zugriff auf private Netzwerke, bei der Preflight-Anfragen verwendet wurden, um lokale Geräte zu aktivieren. Unternehmen, die die Berechtigung deaktivieren oder automatisch gewähren möchten, können dies mit den Richtlinien LocalNetworkAccessAllowedForUrls und LocalNetworkAccessBlockedForUrls tun. Mit dem Wert „*“ kann der Zugriff über das lokale Netzwerk auf alle URLs zugelassen werden. Das entspricht dem Verhalten vor der Einführung der Einschränkungen.

     
    • Chrome 142 für Windows, macOS, Linux und Android
       

    

  • Unterstützung mehrerer Profile in der Freigabeerweiterung für Chrome unter iOS back to top

    Bereits ab Chrome 142 für iOS können Nutzer in der Chrome Share-Erweiterung das aktuell verwendete Profil sehen und es ändern, bevor sie eine URL in Chrome öffnen oder nach Text oder Bildern suchen. Wenn Nutzer mehrere Profile aktiviert haben und eine URL teilen oder Text oder ein Bild auswählen und dann Chrome auswählen, sehen sie die Chrome Share-Erweiterung mit einem Konto-Avatar. Wenn Nutzer nichts unternehmen, wird der Intent zum Teilen im ausgewählten Profil geöffnet.

    Wenn Nutzer das Profil über die Chrome Share-Erweiterung ändern möchten, klicken sie darauf und wählen das gewünschte Profil aus. Chrome wechselt dann entsprechend das Profil. Wenn Arbeitsprofile durch die Unternehmensrichtlinie zugelassen sind, können Nutzer das Profil für Widgets festlegen. Wenn nur private oder nur Unternehmensprofile zulässig sind und die Unterstützung mehrerer Profile nicht aktiviert ist, funktionieren Widgets weiterhin wie bisher.

     
    • Chrome 142 für iOS
     

    

  • Vereinfachte Anmeldung und Synchronisierung in Chrome für Computer back to top

    Chrome führt eine vereinfachte und konsolidierte Version der Anmeldung und Synchronisierung in Chrome für Windows, Mac und Linux ein. Die Chrome-Synchronisierung wird nicht mehr als separate Funktion in den Einstellungen oder an anderer Stelle angezeigt. Stattdessen können sich Nutzer gemäß den entsprechenden Unternehmensrichtlinien in Chrome anmelden, um Daten wie Passwörter und Lesezeichen in ihrem Google-Konto zu verwenden und zu speichern. Außerdem können Nutzer, die in Chrome angemeldet sind, auch die Synchronisierung ihrer Tabs und ihres Browserverlaufs in ihrem Google-Konto aktivieren. Auch hier gelten die entsprechenden Unternehmensrichtlinien.

    Wie bisher kann die Funktion zum Speichern und Aufrufen von Chrome-Daten im Google-Konto, die früher Teil der Chrome-Synchronisierung war, über SyncDisabled und SyncTypesListDisabled deaktiviert werden. Die Anmeldung in Chrome kann wie bisher über BrowserSignin deaktiviert werden.

    Die Änderungen haben keine Auswirkungen auf die Möglichkeiten der Nutzer, sich in Google-Diensten im Web (z. B. Gmail) anzumelden, ohne sich in Chrome anzumelden, ihre Möglichkeiten, Chrome auch ohne Anmeldung zu nutzen, oder festzulegen, welche Informationen mit ihrem Google-Konto synchronisiert werden sollen.

    Diese Änderungen ähneln der vereinfachten Anmeldung und Synchronisierung, die in Version 117 für iOS und in Version 127 für Android eingeführt wurde.

     
    • Chrome 142 für Linux, macOS und Windows: schrittweise Einführung
     

    

  • Gebündelte Sicherheitseinstellungen back to top

    Mit dieser Funktion können Nutzer gebündelte Sicherheitsoptionen verwenden, um Sicherheitseinstellungen entsprechend dem gewünschten Schutz beim Verwenden von Chrome zu konfigurieren. Nutzer können zwischen „Erweitert“ für das höchste Sicherheitsniveau und „Standard“ für den standardmäßigen ausgewogenen Schutz wählen. Nutzer können weiterhin benutzerdefinierte Werte für die Einstellungen festlegen. Das vereinfacht die Nutzung und ermöglicht es Nutzern, das gewünschte Schutzniveau zu erhalten, ohne sich mit erweiterten Konfigurationsoptionen auseinandersetzen zu müssen.

    Bestehende Unternehmensrichtlinien haben Vorrang vor der Auswahl von Endnutzer-Bundles. Wenn eine vorhandene Richtlinie für Sicherheitseinstellungen konfiguriert ist, werden die Werte nicht durch die Auswahl eines Sicherheitsbündels durch einen Nutzer überschrieben.

     
    • Chrome 142 für ChromeOS, Linux, macOS und Windows
     

    

  • Fenstername für websiteübergreifende Seitenaufrufe löschen, bei denen die Gruppe für den Browserkontext gewechselt wird back to top

    Der Wert der Eigenschaft window.name bleibt derzeit während der gesamten Lebensdauer eines Tabs erhalten, auch bei der Navigation, bei der die Browserkontextgruppen gewechselt werden. Dadurch können Informationen preisgegeben und möglicherweise als Tracking-Vektor verwendet werden. Bereits in Chrome 142 wird das Attribut „window.name“ in diesem Fall nicht mehr beibehalten, wodurch dieses Problem behoben wird. 

    Mit diesem Update wird eine neue temporäre Unternehmensrichtlinie eingeführt: ClearWindowNameCrossSiteBrowsing. Sie funktioniert ab Chrome 146 nicht mehr.

     
    • Chrome 142 für Windows, macOS, Linux, Android und iOS: Unternehmensrichtlinie ist verfügbar
    • Chrome 146 für Windows, macOS, Linux, Android und iOS: Unternehmensrichtlinie wird entfernt
     

    

  • Unterstützung des clientseitigen LLM bei der Behebung von Betrugsfällen back to top

    Nutzer im Web werden täglich mit einer erheblichen Menge verschiedenster Betrugsversuche konfrontiert. Um diese Betrugsversuche zu bekämpfen, werden in Chrome On-Device-LLMs (Large Language Models) verwendet, um für Nutzer mit erweitertem Safe Browsing (ESB) betrügerische Websites zu identifizieren. Chrome sendet den Seiteninhalt an ein LLM auf dem Gerät, um sicherheitsbezogene Signale der Seite abzuleiten und diese Signale serverseitig zur endgültigen Entscheidung an Safe Browsing zu senden. Wenn diese Option aktiviert ist, benötigt Chrome möglicherweise mehr Bandbreite zum Herunterladen des LLM.

     
    • Chrome 134 für Linux, macOS und Windows: Der Markenname und die Intent-Zusammenfassung der Seite, die die Tastatursperre auslöst, werden erfasst, um betrügerische Websites zu identifizieren.
    • Chrome 135 für Linux, macOS und Windows: Warnungen werden Nutzern basierend auf dem Serverurteil angezeigt. Dabei werden die Marke und der Intent der Seite berücksichtigt, die die Tastatursperre ausgelöst hat.
    • Chrome 137 für Linux, macOS und Windows: Zusammenfassung der Marke und Intent der Seite basierend auf dem Bewertungssystem für den Serverruf.
    • Chrome 138 für Linux, macOS und Windows: Warnungen werden Nutzern basierend auf dem Serverurteil angezeigt. Dabei werden die Marke und der Intent der Seiten berücksichtigt, die vom System für den Serverruf bewertet wurden.
    • Chrome 142 für Android
     

    

  • HSTS-Tracking-Schutz back to top

    Durch dieses Update wird die Nachverfolgung von Nutzern durch Drittanbieter über den HTTP Strict Transport Security (HSTS)-Cache eingeschränkt. Diese Funktion erlaubt nur HSTS-Upgrades für Navigationen auf oberster Ebene und blockiert HSTS-Upgrades für Anfragen zu untergeordneten Ressourcen. Dadurch wird es für Drittanbieter-Websites unmöglich, den HSTS-Cache zu verwenden, um Nutzer im Web zu tracken.

     
    • Chrome 142 für Windows, macOS, Linux und Android
     

    

  • Interoperable „pointerrawupdate“-Ereignisse nur in sicheren Kontexten verfügbar back to top

     

    In der PointerEvents-Spezifikation wurde pointerrawupdate 2020 auf sichere Kontexte beschränkt. Dadurch werden sowohl das Auslösen des Ereignisses als auch die globalen Ereignis-Listener in unsicheren Kontexten verborgen. Durch diese Funktion entspricht Chrome der aktualisierten Spezifikation und ist mit anderen gängigen Browsern interoperabel.

     
    • Chrome 142 für Windows, macOS, Linux und Android
     

    

  • Ursprungsgebundene Cookies (Standardeinstellung) back to top

    In Chrome 142 sind Cookies standardmäßig an ihren Einstellungsursprung gebunden, sodass sie nur über diesen Ursprung zugänglich sind, d. h. bei einer Anfrage gesendet oder über document.cookie sichtbar. Cookies können die Einschränkungen für die Bindung von Host und Port durch die Verwendung des Domain-Attributs aufheben, aber alle Cookies sind an ihr Einstellungsschema gebunden.

    Die temporären Enterprise-Richtlinien LegacyCookieScopeEnabled und LegacyCookieScopeEnabledForDomainList sind verfügbar, um diese Änderung rückgängig zu machen. Diese Richtlinien funktionieren ab Chrome 150 nicht mehr.

     
    • Chrome 142 für Android, iOS, Linux, macOS und Windows: Unternehmensrichtlinien werden verfügbar sein
    • Chrome 150 für Android, iOS, Linux, macOS und Windows: Unternehmensrichtlinien werden entfernt
     

    

  • Post-Quanten-Kryptografie für DTLS in WebRTC back to top

    Diese Funktion ermöglicht die Verwendung von Post-Quanten-Kryptografie (PQC) mit WebRTC-Verbindungen. Der Grund für PQC ist, den WebRTC-Media-Traffic auf den neuesten Stand der Kryptografieprotokolle zu bringen und Harvest Now to Crack Later-Szenarien zu verhindern. 

    Administratoren können diese Funktion über die Unternehmensrichtlinie WebRtcPostQuantumKeyAgreementEnabled steuern, damit Unternehmensnutzer PQC deaktivieren können. Die Richtlinie gilt nur vorübergehend und wird voraussichtlich in Chrome 152 entfernt.

    • Chrome 142 für Android, ChromeOS, Linux, macOS und Windows
    • Chrome 152 für Android, ChromeOS, Linux, macOS, Windows und Fuchsia: Unternehmensrichtlinie wird entfernt
     

    

  • Persistente Nutzeraktivierung bei Navigationen mit demselben Ursprung back to top

     

    Mit dieser Funktion bleibt der Status der klebrigen Nutzeraktivierung erhalten, nachdem eine Seite zu einer anderen Seite mit demselben Ursprung navigiert wurde. Das Fehlen der Nutzeraktivierung auf der Seite nach der Navigation verhindert einige Anwendungsfälle, z. B. die Anzeige virtueller Tastaturen bei Autofokus. Dies war ein Hindernis für Entwickler, die mehrseitige Anwendungen (MPAs) anstelle von Single-Page-Anwendungen (SPAs) erstellen möchten.

     
    • Chrome 142 für Windows, macOS, Linux und Android
     

    

  • Ändern der WarnungKein HTTPS  back to top

    In Chrome 140 wurde die Warnung, die angezeigt wird, wenn ein Nutzer die Einstellung Immer sichere Verbindungen verwenden unter chrome://settings/security über ein Interstitial aktiviert, in ein Dialogfeld geändert. Das Symbol für die Inhaltsicherheit der URL in der Warnung ändert sich von einem Sternchen zu einem aufgebrochenen Schloss. Das Laden der gesamten Seite bleibt jedoch blockiert und die Funktionalität unverändert. Einige Nutzer sehen diese Warnung möglicherweise automatisch, wenn sie HTTP-Websites aufrufen. Nutzer können die Warnung unter chrome://settings/security aktivieren.

     
    • Chrome 140 für ChromeOS, Linux, macOS und Windows: Neues Warnungsdesign auf Desktop-Plattformen
    • Chrome 142 für Android: Neues Warnungsdesign für Android

    

  • Web-App-Manifest: Algorithmus für die Aktualisierungsberechtigung back to top

    Bereits in Chrome 142 wird im Web-App-Manifest ein Algorithmus für die Aktualisierungsvoraussetzung angegeben. Dadurch wird der Updateprozess deterministischer und vorhersehbarer. Entwickler haben mehr Kontrolle darüber, ob und wann Updates auf bestehende Installationen angewendet werden sollen. Außerdem kann die Drosselung der Updateprüfung entfernt werden, die User-Agents derzeit implementieren müssen, um keine Netzwerkressourcen zu verschwenden.

    • Chrome 142 für Windows, macOS und Linux
    • Chrome 143 für Android
     

    

  • CSS-Pseudo-Elemente für das Hervorheben von Suchergebnissen auf der Seite back to top

    Mit dieser Funktion wird das Styling von Auf Seite suchen-Suchergebnissen für Autoren als Highlight-Pseudoelement wie Auswahl und Rechtschreibfehler verfügbar gemacht. So können Autoren die Vorder- und Hintergrundfarben ändern oder Textformatierungen hinzufügen, was besonders nützlich sein kann, wenn die Browserstandardeinstellungen nicht ausreichend Kontrast zu den Seitenfarben bieten oder anderweitig ungeeignet sind.

    • Chrome 143 für Windows, macOS, Linux und Android
     

    

  • Einstellung von „savedTabGroups“ als Einzelwert in „SyncTypesListDisabled“ back to top

    Derzeit können Administratoren mit der Unternehmensrichtlinie SyncTypesListDisabled die Synchronisierung des Datentyps savedTabGroups auf Desktop-Plattformen deaktivieren. Auf mobilen Plattformen wird die Synchronisierung von Tabgruppen jedoch bereits über den Datentyp „Tabs“ verwaltet. Um das Verhalten auf dem Desktop an das Verhalten auf Mobilgeräten anzugleichen und die Synchronisierungsverwaltung zu vereinfachen, wird der einzelne Datentyp savedTabGroups eingestellt. Er ist dann kein individuell anpassbarer Wert mehr in der Richtlinie SyncTypesListDisabled.

    Erforderliche Maßnahmen von Administratoren: 

    Ab Chrome 143 werden sowohl Tabs als auch savedTabGroups als deaktiviert betrachtet, wenn die Richtlinie SyncTypesListDisabled einen der beiden Datentypen deaktiviert. Wenn Sie Tabs deaktivieren, werden also auch gespeicherte Tabgruppen deaktiviert und umgekehrt. Der Wert savedTabGroups wird vollständig aus der Liste der unterstützten Datentypen für diese Richtlinie entfernt. Administratoren, die gespeicherte Tabgruppen deaktiviert haben und dies beibehalten möchten, müssen den Datentyp „Tabs“ explizit deaktivieren. So wird das gewünschte Verhalten sichergestellt, bevor der Wert savedTabGroups vollständig entfernt wird.

     
    • Chrome 143 für Windows, macOS und Linux
     

    

  • Happy Eyeballs V3 back to top

    Diese Einführung ist eine interne Optimierung in Chrome, bei der Happy Eyeballs V3 implementiert wird, um eine bessere Nebenläufigkeit von Netzwerkverbindungen zu erreichen. Bei Happy Eyeballs V3 werden DNS-Auflösungen asynchron ausgeführt und Verbindungsversuche mit bevorzugten Protokollen (H3/H2/H1) und Adressfamilien (IPv6 oder IPv4) gestaffelt, um die für Nutzer sichtbare Verzögerung bei der Netzwerkverbindung zu verringern. Diese Funktion wird durch die temporäre Richtlinie HappyEyeballsV3Enabled gesteuert.

     
    • Chrome 144 für Android, ChromeOS, Linux, macOS und Windows
     

    

  • „ServiceWorkerAutoPreload“-Modus back to top

    ServiceWorkerAutoPreload ist ein Modus, in dem der Browser die Netzwerkanfrage parallel zum ServiceWorker-Bootstrap ausgibt und das Ergebnis der Netzwerkanfrage im Fetch-Handler verwendet, wenn der Fetch-Handler die Antwort mit respondWith() zurückgibt. Wenn das Ergebnis des Fetch-Handlers ein Fallback ist, wird die Netzwerkantwort direkt an den Browser übergeben. ServiceWorkerAutoPreload ist eine optionale Browseroptimierung, die das vorhandene Service Worker-Verhalten ändert. Administratoren können diese Funktion über die Unternehmensrichtlinie ServiceWorkerAutoPreloadEnabled steuern.

       

    

  • Änderung des Zeitplans für die Einführung von Early Stable back to top

    Ab Chrome 145 wird Chrome eine Woche früher als bisher kommuniziert im Early Stable-Channel eingeführt. So ist beispielsweise die Einführung der ersten stabilen Chrome 145-Version vom 4. Februar 2026 auf den 28. Januar 2026 vorgezogen worden. An der Veröffentlichung der stabilen Version ändert sich nichts. Die neuen geplanten Termine für die Early Stable-Versionen finden Sie im aktualisierten Release-Zeitplan

    • Chrome 145 für Android, iOS, macOS und Windows: Chrome wird eine Woche früher im Early Stable-Channel eingeführt.

    

  • Erzwingen der 2‑Faktor-Authentifizierung für Administratoren back to top

    Um die Daten Ihrer Organisation besser zu schützen, erfordert Google bald die Aktivierung der Bestätigung in zwei Schritten für alle Konten mit Zugriff auf admin.google.com. Als Google Workspace-Administrator müssen Sie Ihre Identität mit der 2‑Faktor-Authentifizierung bestätigen. Dazu benötigen Sie Ihr Passwort und etwas Zusätzliches, z. B. Ihr Smartphone oder einen Sicherheitsschlüssel.

    Die Erzwingung erfolgt in den kommenden Monaten schrittweise. Sie sollten die Bestätigung in zwei Schritten für die Administratorkonten in Ihrer Organisation aktivieren, bevor sie von Google durchgesetzt wird. Weitere Informationen finden Sie unter 2‑Faktor-Authentifizierung für Administratoren erzwingen.

     
    • Chrome 137 für ChromeOS, Linux, macOS und Windows: Erzwingen der 2‑Faktor-Authentifizierung beginnt
    • Chrome 145 für ChromeOS, Linux, macOS und Windows: 2FA erforderlich
     

    

  • Leerzeichen in nicht file://-URL-Hosts nicht zulassen back to top

    Gemäß der URL-Standardspezifikation dürfen URL-Hosts kein Leerzeichen enthalten. Derzeit lässt die URL-Analyse in Chromium jedoch Leerzeichen im Host zu. Dies führt dazu, dass Chromium in den Bereichen Interop2024 HTTPS URLs for WebSocket und URL-Fokus mehrere Tests nicht besteht. Um Chromium an die Spezifikationen anzupassen, möchten wir Lücken aus URL-Hosts entfernen. Das Problem dabei ist, dass sie im Hostteil von Windows-file://-URLs verwendet werden (Github).

    • Chrome 145 für Android, ChromeOS, LaCrOS, Linux, MacOS, Windows und Fuchsia
     

    

    

  • Migration von der Safe Browsing API v4 zur v5 back to top

    Chrome-Aufrufe der SafeBrowsing v4 API werden stattdessen zum Aufrufen von v5 API migriert. Auch die Methodennamen unterscheiden sich zwischen v4 und v5. Wenn Administratoren eine v4-spezifische Zulassungsliste für URLs haben, um Netzwerkanfragen an https://safebrowsing.googleapis.com/v4* zuzulassen, sollten diese so geändert werden, dass stattdessen Netzwerkanfragen an die gesamte Domain zugelassen werden: safebrowsing.googleapis.com. Andernfalls führen abgelehnte Netzwerkanfragen an die v5 API zu Rückschritten bei der Sicherheit für Nutzer. Weitere Informationen finden Sie unter Migration von V4 – Safe Browsing

     
    • Chrome 145 für Android, iOS, ChromeOS, Linux, macOS und Windows: Die Funktion wird nach und nach eingeführt. 
     

    

  • X25519Kyber768-Schlüsselkapselung für TLS back to top

    In Chrome 124 wurde auf allen Desktopplattformen standardmäßig der neue Post-Quanten-Mechanismus zur sicheren TLS-Schlüsselkapselung X25519Kyber768 aktiviert, der auf einem NIST-Standard (ML-KEM) basiert. So wird der Netzwerkverkehr von Chrome mit Servern, die ebenfalls ML-KEM unterstützen, vor der Entschlüsselung durch einen zukünftigen Quantencomputer geschützt. Diese Änderung sollte für Serverbetreiber transparent sein. Diese Chiffre wird sowohl für TLS 1.3- als auch für QUIC-Verbindungen verwendet.

    Einige TLS-Midboxes sind jedoch möglicherweise nicht auf die Größe einer Kyber-Schlüsselkapselung (ML-KEM) oder einen neuen TLS-ClientHello-Chiffre-Codepunkt vorbereitet. Dies führt zu unterbrochenen oder hängenden Verbindungen. Dies lässt sich beheben, indem Sie Ihre Middlebox aktualisieren oder den Mechanismus zur Schlüsselkapselung über die temporäre Unternehmensrichtlinie PostQuantumKeyAgreementEnabled deaktivieren, die bis Ende 2024 verfügbar ist. Langfristig werden Post-Quanten-sichere Chiffren jedoch in TLS erforderlich sein und die Unternehmensrichtlinie wird entfernt. Für CSNA 2.0 ist Post-Quanten-Kryptografie erforderlich. Weitere Informationen finden Sie unter Chrome-Traffic mit Hybrid Kyber KEM schützen.

     
    • Chrome 131 für Linux, macOS und Windows: Chrome stellt den Schlüsselkapselungsmechanismus auf die endgültige Standardversion ML-KEM um.
    • Chrome 145 für Linux, macOS und Windows: Unternehmensrichtlinie wird entfernt
     

    

  • Isolierte Web-Apps back to top

    Isolierte Web-Apps (IWAs) sind eine Erweiterung der bestehenden Arbeit an der PWA-Installation und dem Web Packaging, die einen besseren Schutz vor Manipulation von Servern und anderen Manipulationen bieten – erforderlich für Entwickler von sicherheitsrelevanten Anwendungen. Diese Anwendungen werden nicht auf Live-Webservern gehostet und über HTTPS abgerufen, sondern in Web-Bundles verpackt, vom Entwickler signiert und über eine oder mehrere der in dieser Erklärung beschriebenen Methoden an Endnutzer verteilt. 

    In der ersten Version können IWAs nur über eine Administratorrichtlinie auf von Unternehmen verwalteten ChromeOS-Geräten installiert werden.

     
    • Chrome 146 für Windows: Mit diesem Roll-out wird die Unterstützung für isolierte Webanwendungen in von Unternehmen verwalteten Browserkonfigurationen unter Windows hinzugefügt.
     

    

  • Anbieter des Bedienungshilfen-Frameworks zur Automatisierung der Benutzeroberfläche unter Windows back to top

    Ab Chrome 126 unterstützt Chrome Bedienungshilfen-Client-Software, die das Bedienungshilfen-Framework zur Benutzeroberflächenautomatisierung von Microsoft Windows verwendet. Vor dieser Änderung arbeitete diese Software in Microsoft Windows über einen Kompatibilitäts-Shim mit Chrome zusammen. Diese Änderung soll die Barrierefreiheit für viele Nutzer verbessern. Die App bietet vollständige Unterstützung für Sprecher, Lupe und Voice Access. Außerdem werden wir Drittanbieter-Apps verbessern, die das Bedienungshilfen-Framework zur Benutzeroberflächenautomatisierung nutzen. Für Nutzer von Chrome ist die Arbeitsspeichernutzung und der Verarbeitungsaufwand geringer, wenn sie Bedienungshilfen verwenden. Außerdem wird die Entwicklung von Software mit Hilfstechnologien erleichtert.

    Administratoren können die Unternehmensrichtlinie UiAutomationProviderEnabled ab Chrome 125 verwenden, um entweder die Aktivierung des neuen Anbieters zu erzwingen, damit alle Nutzer die neue Funktion erhalten, oder den neuen Anbieter zu deaktivieren. Diese Richtlinie wird bis Chrome 146 unterstützt und in Chrome 147 entfernt. Dieser einjährige Zeitraum soll Unternehmen genügend Zeit für die Zusammenarbeit mit Drittanbietern geben, damit sie Inkompatibilitäten beheben können, die durch den Wechsel vom Microsoft-Kompatibilitäts-Shim zum Anbieter der Benutzeroberflächenautomatisierung von Chrome entstehen.

     
    • Chrome 125 für Windows: Die Richtlinie UiAutomationProviderEnabled wird eingeführt, damit Administratoren den Anbieter des Bedienungshilfen-Frameworks zur Automatisierung der Benutzeroberfläche von Chrome aktivieren und prüfen können, ob Bedienungshilfen von Drittanbietern weiterhin funktionieren.
    • Chrome 126 für Windows: Das Framework für Chrome-Varianten wird verwendet, um Anbieter des Bedienungshilfen-Frameworks zur Benutzeroberflächenautomatisierung von Chrome für Nutzer zu aktivieren. Die Funktion wird nach und nach für alle stabilen Versionen aktiviert. Bei Bedarf werden allerdings auch Pausen eingelegt, um Kompatibilitätsprobleme zu beheben, wo dies in Chrome möglich ist. Unternehmensadministratoren können die Richtlinie UiAutomationProviderEnabled weiterhin verwenden, um das neue Verhalten frühzeitig zu aktivieren. In Chrome 146 lässt es sich vorübergehend deaktivieren.
    • Chrome 147 für Windows: Die Richtlinie UiAutomationProviderEnabled wird aus Chrome entfernt. Alle Clients verwenden den Anbieter für das Bedienungshilfen-Framework zur Automatisierung der Benutzeroberfläche im Browser.

 

Bevorstehende Updates für Chrome Enterprise Core

 

    

  • Berichterstellung zu Profilen für Chrome unter iOS back to top

    Mit Chrome Enterprise Core wird die Berichterstellung zu Cloudprofilen für Chrome unter iOS eingeführt. Wenn IT-Administratoren die Profilberichterstellung unter iOS aktivieren möchten, müssen sie in der Google Admin-Konsole im Bereich Chrome-Browser > Einstellungen die Richtlinie „Berichterstellung für verwaltete Profile“ aktivieren. Wenn Sie die Berichterstellung für verwaltete Profile bereits aktiviert haben, erhalten Sie automatisch Profilberichte für Chrome unter iOS. Administratoren können die Funktion über die Richtlinie LensOverlaySettings steuern. 

    Die Berichtsdaten für Profile finden Sie in der Google Admin-Konsole > Chrome-Browser > Verwaltete Profile. Die Berichtsdaten umfassen Profilinformationen, Browserinformationen (Browserversionen, Betriebssystem, Channel usw.), die angewendeten Richtlinien und mehr.

    • Chrome 142 für iOS: Die Funktion wird nach und nach eingeführt.

 

Bevorstehende Änderungen bei Chrome Enterprise Premium

   

  • UX-Refaktorierung für Chrome-Browserregeln back to top

    Um die Erstellung von Regeln zum Schutz vor Datenverlust zu vereinfachen, wird die Admin-Konsole aktualisiert. Administratoren können dann Richtlinien für verschiedene Anwendungen wie Chrome und Workspace einfacher definieren. Zuerst werden sich gegenseitig ausschließende Anwendungsgruppen eingeführt. Das bedeutet, dass eine einzelne DLP-Regel jeweils nur auf eine Anwendungsgruppe ausgerichtet sein kann: entweder auf Workspace-Apps (z. B. Drive, Gmail), auf Chrome-Browser-Trigger (z. B. Dateiupload, besuchte URL) oder auf ChromeOS-Trigger. Diese Änderung vereinfacht die Regelkonfiguration, beseitigt potenzielle Konflikte durch sich überschneidende App-Auswahl und schafft die Grundlage für spezialisiertere und nutzerfreundlichere Workflows, die auf die Anforderungen der einzelnen Plattformen zugeschnitten sind.

    Administratoren sehen eine aktualisierte Auswahloberfläche für Apps mit Optionsfeldern, über die diese Einzelgruppenauswahl für neue Regeln erzwungen werden kann. Bestehende Regeln, die zuvor Anwendungen aus mehreren Gruppen kombiniert haben, werden vom System transparent in separate, konforme Regeln für eine einzelne Plattform migriert, um für einen kontinuierlichen Schutz und einen reibungslosen Übergang zu sorgen. In der Admin-Konsole werden Banner mit Informationen zu diesen Änderungen und zum Migrationsprozess angezeigt. Mit diesem Update werden keine neuen Unternehmensrichtlinien eingeführt. Die Änderungen betreffen die Benutzeroberfläche für die Regelkonfiguration. Weitere Informationen finden Sie unter Was sind ChromeOS-Datenkontrollen? – Chrome Enterprise- und Education-Hilfe..

     
    • Chrome 141 für ChromeOS, Linux, macOS und Windows: Es wird eine sich gegenseitig ausschließende App-Auswahl für die Konfiguration von DLP-Regeln in der Admin-Konsole ermöglicht.


     

   

  • Unterstützung für größere Dateien bei DLP-Scans back to top

    Die Funktionen zum Schutz vor Datenverlust (Data Loss Prevention, DLP) und zum Scannen auf Malware in Chrome Enterprise Premium werden jetzt auf große und verschlüsselte Dateien ausgeweitet. Bisher wurden Dateien, die größer als 50 MB waren, und alle verschlüsselten Dateien beim Scannen von Inhalten übersprungen. Mit diesem Update wird diese kritische Sicherheitslücke geschlossen. Bei Richtlinien, die so konfiguriert sind, dass Beweise gespeichert werden, können jetzt Dateien mit einer Größe von bis zu 2 GB an den Evidence Locker gesendet werden. Administratoren erhalten so mehr Transparenz und Kontrolle, wodurch das Risiko der Daten-Exfiltration durch große Dateiübertragungen erheblich verringert wird.

    Zum Aktivieren dieses Features ist keine neue Richtlinie erforderlich. Sie wird automatisch durch die vorhandenen Konfigurationen der DLP-Regeln in der Google Admin-Konsole gesteuert. Wenn Administratoren Regeln für das Hochladen, Herunterladen oder Drucken von Dateien haben, gelten diese jetzt auch für große und verschlüsselte Dateien. Weitere Informationen finden Sie unter Was sind ChromeOS-Datenkontrollen? – Chrome Enterprise- und Education-Hilfe.

    • Chrome 145 für Linux, macOS und Windows: In dieser Phase können große (>50 MB) und verschlüsselte Dateien für den Beweisspeicher gesammelt werden, wodurch eine wichtige DLP-Sicherheitslücke geschlossen wird.

↑ Zurück nach oben  

 Für E‑Mails zu zukünftigen Versionen anmelden

FRÜHERE VERSIONSHINWEISE 

Veröffentlichungsdatum für die Chrome-Version und die geplante stabile Version

Chrome 140: 27. August 2025
Chrome 139: 30. Juli 2025
Chrome 138: 18. Juni 2025
Chrome 137: 20. Mai 2025
Frühere Versionshinweise  →

Zusätzliche Ressourcen

Sie haben noch Fragen?

Google sowie zugehörige Marken und Logos sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen sind Marken der jeweiligen Unternehmen.

War das hilfreich?

Wie können wir die Seite verbessern?
Suche
Suche löschen
Suche schließen
Hauptmenü
14738918755087371577
true
Suchen in der Hilfe
false
true
true
true
true
true
410864
false
false
false
false