Versionshinweise für Chrome Enterprise und Chrome Education

Letzte Aktualisierung: 15. April 2026 

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.

 

Important update: Starting March 26th, 2026, the release notes for Chrome browser for Enterprise are moving! Find them exclusively on our website: chromeenterprise.google. Please update your bookmarks. (Note that ChromeOS release notes will continue to be published at this current link and will not move.)

Übersicht über Chrome-Version 147

 
Änderungen am Chrome-Browser Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
KI‑Modus und Lens-Verbesserungen   ✓  
Gemini in Chrome   ✓  
X25519Kyber768-Schlüsselkapselung für TLS ✓    
CSS-Update: Entkopplung der Eigenschaften „Breite“ und „Stil“     ✓
Hintergrund der Seite „Neuer Tab“ in Chrome für iOS anpassen   ✓  
Anmeldedaten für gerätegebundene Sitzung ✓    
Einschränkungen für den Zugriff auf lokales Netzwerk ✓    
Betrug melden ✓    
Vertikale Tabs   ✓  
Anbieter des Bedienungshilfen-Frameworks zur Automatisierung der Benutzeroberfläche unter Windows   ✓  
Neue Richtlinien im Chrome-Browser     ✓
Entfernte Richtlinien im Chrome-Browser     ✓
Änderungen bei Chrome Enterprise Core Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Erweiterungen auf Grundlage von Risikobewertungen von Drittanbietern blockieren ✓   ✓
Erweiterungen anhand von Chrome Web Store-Kategorien blockieren ✓   ✓
Neue Veröffentlichungsoption für Organisationen im Chrome Web Store ✓   ✓
KI-generierte Zusammenfassung der Versionshinweise in der Admin-Konsole   ✓ ✓
Berichte zur Nutzung von generativer KI und SaaS-Anwendungen ✓   ✓
Änderungen bei Chrome Enterprise Premium Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Unterstützung größerer Dateien bei DLP-Scans ✓   ✓
Neue Vorlagen für Regeln zum Schutz vor Datenverlust ✓   ✓
Optimierte Chrome Enterprise-Integration in Google SecOps ✓    
Unterstützung von Zulassungs- und Sperrlisten für Entwicklertools ✓   ✓
Unterstützung von Zulassungs- und Sperrlisten für den Inkognitomodus ✓   ✓
Anstehende Änderungen für den Chrome-Browser Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Chrome-Profil-Bootstrapping über benutzerdefinierten URI ✓ ✓  
Erweitertes Autofill   ✓  
Shared Workers mit verlängerter Lebensdauer     ✓
PWA-Ursprungsmigration   ✓  
Prompt API   ✓ ✓
Chrome für ARM64-Linux-Geräte   ✓  
Aktualisierung der No-HTTPS-Warnung ✓    
Standardmäßig immer verschlüsselte Verbindungen verwenden ✓    
Einstellung und Entfernung von Privacy Sandbox-APIs ✓ ✓  
Isolierte Web-Apps     ✓
Migration von der Safe Browsing API v4 zur v5 ✓    
Ende der Unterstützung von macOS 12 in Chrome     ✓
XSLT einstellen und entfernen ✓ ✓ ✓
Chrome wird auf einen 2‑Wochen-Versionszyklus umgestellt     ✓
Post-Quanten-Kryptografie für DTLS in WebRTC ✓    
Verbieten von Leerzeichen in URL-Hosts ohne file:// ✓    
Bevorstehende Änderungen bei Chrome Enterprise Core Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Unterstützung von Chrome-Clientzertifikaten unter iOS ✓   ✓
Unterstützung für Berichte zu verwalteten Profilen     ✓
Bevorstehende Änderungen bei Chrome Enterprise Premium Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Chrome Enterprise Connectors API ✓   ✓
Drag-and-drop-Unterstützung für Datenkontrollen ✓    
Telemetriedaten zu DOM-Aktivitäten von Erweiterungen für Unternehmen ✓    
Neue Richtlinieneinstellung für DataControlRules ✓   ✓
Schutz vor Manipulation lokaler Richtlinien ✓   ✓

 

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

 

Important update: Starting March 26th, 2026, the release notes for Chrome browser for Enterprise are moving! Find them exclusively on our website: chromeenterprise.google. Please update your bookmarks. (Note that ChromeOS release notes will continue to be published at this current link and will not move.)

Änderungen beim Chrome-Browser  

   

  • Verbesserungen im KI‑Modus back to top

    In Chrome 143 werden neue KI-Modus-Funktionen in Chrome für macOS und Windows eingebunden. Nutzer können direkt über die Seite Neuer Tab und die Omnibox auf den KI‑Modus zugreifen und komplexe Fragen stellen, ohne die Seite zu verlassen, auf der sie mit dem Browsen beginnen. Die Einführung beginnt in Chrome 143 für macOS und Windows. Administratoren können diese Funktionen mit der Richtlinie AIModeSettings (Wert 1) oder über die GenAiDefaultSettings (Wert 2) deaktivieren. Weitere Informationen finden Sie im entsprechenden Abschnitt der YouTube-Hilfe.

    In Chrome 144 wird auch die Funktion für den Multi-Tab-Kontext eingeführt. Nutzer können die Inhalte eines oder mehrerer ihrer geöffneten Tabs für den KI-Modus freigeben, um Fragen zu stellen, Informationen zu vergleichen, zusammenzufassen und effizienter zu finden. Administratoren können diese Funktionen mit der Richtlinie SearchContentSharingSettings (Wert 1, verfügbar in Chrome 144) oder über die GenAiDefaultSettings (Wert 2) deaktivieren.

    In Chrome 145 haben wir die Funktion für den Multi-Tab-Kontext für den KI-Modus und Lens eingeführt. Nutzer können die Inhalte eines oder mehrerer ihrer geöffneten Tabs freigeben, um Fragen zu stellen, Informationen zu vergleichen, zusammenzufassen und effizienter zu finden. Administratoren können diese Funktionen mit der Richtlinie SearchContentSharingSettings (Wert 1) oder über die GenAiDefaultSettings (Wert 2) deaktivieren. In Chrome 145 für Android und iOS wurden außerdem neue Funktionen für den KI-Modus in den Chrome-Browser eingebunden.

    In Chrome 146 werden Google Drive-Dateien als Kontext verfügbar. Administratoren können diese Funktionen mit der Richtlinie SearchContentSharingSettings (Wert 1) deaktivieren.

    In Chrome 147 verwenden Administratoren SearchContentSharingSettings, um diese Funktionen zu steuern. Die Google Lens-Richtlinien für LensOverlaySettings, LensDesktopNTPSearchEnabled und LensRegionSearchEnabled werden eingestellt.

   

  • Gemini in Chrome back to top

    Gemini ist jetzt in Chrome für macOS, Windows und ausgewählte ChromeOS-Geräte eingebunden und kann den Inhalt aktueller Seiten analysieren. Nutzer können sich jetzt die wichtigsten Punkte zusammenfassen lassen, Konzepte erklären lassen und Antworten auf ihre Fragen erhalten, ohne ihren Chrome-Tab zu verlassen. Diese Einbindung umfasst sowohl den Chat, bei dem Nutzer über Text mit Gemini interagieren können, als auch Gemini Live, wobei Nutzer über Sprache mit Gemini interagieren können.

    In Chrome 143 wurde 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 über die GenAiDefaultSettings (Wert 2) deaktivieren. Weitere Informationen finden Sie in der Gemini in Chrome-Hilfe oder in diesem Blogpost.

    In Chrome 143 haben wir auch die Funktion für den Multi-Tab-Kontext angekündigt. Gemini in Chrome kann jetzt mehr Ihrer geöffneten Tabs (maximal 10) sehen. So können Sie Fragen zu mehreren Seiten stellen, um Informationen effizienter zu vergleichen und zu finden. Gemini in Chrome kann auch als Produktivitäts-Agent fungieren. Gemini in Chrome verwendet automatisch öffentliche Informationen aus den folgenden Google-Diensten: Google Suche, Google Maps und YouTube. Wenn Sie zustimmen, kann Gemini in Chrome Ihnen helfen, Ihre personenbezogenen Daten und persönlichen Inhalten in Google Workspace-Diensten (Gmail, Drive, Notizen, Kalender und Tasks) zu verbinden.

    In Chrome 144 wurde das automatische Browsen in Gemini in Chrome für einige Nutzer (nicht für Unternehmen) eingeführt. Die Unternehmensrichtlinie GeminiActOnWebSettings ist bei Einführung verfügbar.

    Weitere Informationen finden Sie unten in den Schritten zur Einführung.

    • Chrome 144 für macOS und Windows: Das automatische Browsen in Gemini in Chrome ist für einige Nutzer (nicht für Unternehmen) verfügbar. Die Unternehmensrichtlinie GeminiActOnWebSettings ist bei Einführung verfügbar. Es ist ein Kontextmenüpunkt zum Hochladen von Bildern für Enterprise-Nutzer verfügbar. Die Funktion berücksichtigt Regeln, die über die Richtlinie DataControlsRules und die Einstellungen für OnBulkDataEntryEnterpriseConnector festgelegt wurden.
    • Chrome 144 für macOS und Windows: Mit Gemini in Chrome können einige Drittanbietertools aufgerufen werden, die als Gemini-Erweiterungen verfügbar sind.
    • Chrome 145 für ChromeOS, macOS und Windows: Gemini in Chrome ist jetzt für Nutzer in den USA, Kanada, Neuseeland und Indien in über 50 Sprachen verfügbar. Weitere Informationen finden Sie in diesem Hilfeartikel.
    • Chrome 147 für ChromeOS, macOS und Windows: Bereits ab Chrome 147 für macOS, Windows und ChromeOS ist das automatische Browsen in Gemini in Chrome für Unternehmensnutzer verfügbar. Die Unternehmensrichtlinien GeminiActOnWebSettings, GeminiActOnWebAllowedForURLs und GeminiActOnWebBlockedForURLs sind verfügbar, um das automatische Browsen zu steuern.
    • Chrome 148 für ChromeOS, macOS und Windows: Gemini in Chrome kann mit Genehmigung des Nutzers Chrome Autofill verwenden, um Kreditkarten- und Adressformulare auszufüllen. Dabei werden die Unternehmensrichtlinien AutofillAddressEnabled und AutofillCreditCardEnabled sowie die allgemeinen Richtlinien GeminiActOnWebSettings, GeminiActOnWebAllowedForURLs und GeminiActOnWebBlockedForURLs für agentisches Gemini in Chrome berücksichtigt.

   

  • 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. Sie können das Problem beheben, indem Sie Ihre Middlebox aktualisieren oder den Mechanismus zur Schlüsselkapselung über die temporäre Unternehmensrichtlinie PostQuantumKeyAgreementEnabled deaktivieren, die bis Chrome 145 verfügbar ist. Langfristig werden Post-Quanten-sichere Chiffren jedoch in TLS erforderlich sein und die Unternehmensrichtlinie wird in Chrome 147 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 147 für Linux, MacOS und Windows: Die Unternehmensrichtlinie PostQuantumKeyAgreementEnabled wird entfernt.

   

  • CSS-Update: Entkopplung der Eigenschaften „Breite“ und „Stil“ back to top

    Chrome 147 entspricht den aktualisierten CSS-Spezifikationen für das Verhalten der Eigenschaften border-width, outline-width und column-rule-width. Bisher wurde die berechnete Breite der Properties border-style, outline-style oder column-rule-style auf 0 px festgelegt, wenn sie auf „none“ oder „hidden“ gesetzt waren, unabhängig vom angegebenen Wert.

    Mit dieser Änderung spiegeln die berechneten Werte von border-width, outline-width und column-rule-width immer die vom Autor angegebenen Werte wider, unabhängig von der *-style-Property. Außerdem spiegeln die aufgelösten Werte (die von getComputedStyle() zurückgegeben werden) für outline-width und column-rule-width auch die angegebenen Werte wider.

    Durch die Änderung wird Chrome an Firefox und WebKit angeglichen, in denen dieses Verhalten bereits implementiert ist.

    • Chrome 147 für Windows, macOS, Linux und Android: Kein Roll-out-Schritt.

   

  • Hintergrundanpassung für die Seite „Neuer Tab“ in Chrome für iOS back to top

    In Chrome für iOS können Nutzer jetzt den Hintergrund der Seite Neuer Tab anpassen. Administratoren können NTPCustomBackgroundEnabled auf „True“ oder „False“ setzen, damit Nutzer den Hintergrund der Seite Neuer Tab anpassen können. Der Administrator kann die BrowserThemeColor festlegen, die einen Hexadezimalcode zur Angabe einer Farbe unterstützt. Wenn ein Hexadezimalwert angegeben ist, kann der Nutzer ihn nicht überschreiben. Administratoren können auch einen empfohlenen Hexadezimalwert angeben, den der Nutzer überschreiben kann. Wenn die Funktion vollständig aktiviert ist, können Nutzer auch aus der vorab ausgewählten Galerie in Chrome oder aus den Aufnahmen ihres Smartphones auswählen.

    • Chrome 147 für iOS: Die Funktion wird nach und nach eingeführt. In Chrome 146 für iOS wird die Hintergrundanpassung nach und nach eingeführt. In Chrome 147 für iOS wird die Funktion zum Synchronisieren von Designs nach und nach eingeführt.

   

  • Anmeldedaten für gerätegebundene Sitzung back to top

    Um die Sicherheit der Nutzer zu verbessern und den Diebstahl von Sitzungscookies zu bekämpfen, führt Chrome Anmeldedaten für gerätegebundene Sitzungen (Device Bound Session Credentials, DBSC) ein. Mit dieser Funktion können Websites die Sitzung eines Nutzers an sein bestimmtes Gerät binden. Dadurch wird es deutlich schwieriger, gestohlene Sitzungscookies auf anderen Computern zu verwenden.

    • Chrome 145 für Windows: Die Funktion wird nach und nach eingeführt.
    • Chrome 147 für macOS: Die Funktion wird nach und nach eingeführt.

   

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

    In Chrome 142 wurde die Möglichkeit, Anfragen an das lokale Netzwerk des Nutzers zu senden, eingeschränkt. Sie ist jetzt an eine Berechtigungsanfrage gebunden. 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 erteilt werden, wird die Blockierung von gemischten Inhalten für lokale Netzwerkanfragen 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 das Opt-In lokaler Geräte zu ermöglichen. Weitere Informationen zu dieser Funktion finden Sie unter Website an neue Einschränkungen für den Zugriff auf das lokale Netzwerk in Chrome anpassen.

    In Chrome 145 wurden detailliertere Berechtigungen für Websites eingeführt, die Zugriff auf das lokale Netzwerk eines Nutzers anfordern. Die bisherige einzelne Berechtigung für den Zugriff auf das lokale Netzwerk wird in zwei separate Berechtigungen aufgeteilt:

    • local-network: Gewährt Zugriff auf IP-Adressen im lokalen Netzwerkbereich (z. B. Intranets, interne Geräte).
    • loopback-network: Gewährt Zugriff auf Loopback-IP-Adressen (z. B. localhost, 127.0.0.1).

    Die alte Berechtigung für das lokale Netzwerk bleibt als Alias erhalten, damit vorhandene Konfigurationen und Berechtigungsrichtlinien weiterhin wie erwartet funktionieren. Durch diese Änderung haben sowohl Nutzer als auch Administratoren mehr Kontrolle darüber, wie Websites mit internen Netzwerkressourcen interagieren. Bestehende Unternehmensrichtlinien zur Verwaltung des Zugriffs auf das lokale Netzwerk sind von dieser Änderung nicht betroffen.

    In Chrome 146 werden zwei neue Unternehmensrichtlinien zur Verwaltung von Zugriffseinschränkungen für lokale Netzwerke eingeführt: LocalNetworkAccessIpAddressSpaceOverrides und LocalNetworkAccessPermissionsPolicyDefaultEnabled. Diese Richtlinien können mit benutzerdefinierten Konfigurationen festgelegt werden.

    In Chrome 147 werden die Einschränkungen für den Zugriff auf das lokale Netzwerk auf WebSocket- und WebTransport-Verbindungen ausgeweitet.

    • Chrome 145 für Android, Linux, macOS, Windows und Fuchsia: Die Aufteilung der Berechtigungen wird eingeführt.
    • Chrome 146 für Android, ChromeOS, Linux, macOS, Windows und Fuchsia: Es werden zwei neue Unternehmensrichtlinien zur Verwaltung von Einschränkungen für den Zugriff auf das lokale Netzwerk eingeführt: Mit LocalNetworkAccessIpAddressSpaceOverrides können IPv4- und IPv6-Adressblöcke als öffentlich oder privat gekennzeichnet werden. Bei IP-Bereichen, die als öffentlich behandelt werden, werden beim Zugriff durch andere Seiten keine Berechtigungsaufforderungen angezeigt. Beispiel: CGNAT 100.64.0.0/10 kann als öffentlich gekennzeichnet werden. Das ist bei bestimmten VPN- und Proxy-Konfigurationen nützlich. Wenn Sie 0.0.0.0/0 und ::/0 als öffentlich kennzeichnen, deaktivieren Sie die Einschränkungen für den Zugriff auf das lokale Netzwerk. Mit LocalNetworkAccessPermissionsPolicyDefaultEnabled kann die LNA-Berechtigung automatisch vom übergeordneten Frame an iframes delegiert werden, ohne dass die untergeordneten iframes explizit annotiert werden müssen. Dies ist nützlich, wenn der Zugriff auf das lokale Netzwerk von einem eingebetteten SaaS-Tool innerhalb eines anderen SaaS-Tools erfolgt. Dazu gehören bestimmte lokal gehostete Softwares in den Bereichen Dokumentation und Wissensdatenbanken.
    • Chrome 147 für Android, ChromeOS, Linux, macOS und Windows: Die Einschränkungen für den Zugriff auf das lokale Netzwerk wurden auf WebSocket- und WebTransport-Verbindungen ausgeweitet.
    • Chrome 152 unter Android, ChromeOS, Linux, macOS, Windows: Die Richtlinie LocalNetworkAccessRestrictionsTemporaryOptOut wird entfernt.

   

  • Betrug meldenback to top

    Wenn Safe Browsing aktiviert ist, können Nutzer Webseiten direkt über das Menü Hilfe in Chrome an Safe Browsing melden.
    Administratoren können diese Funktion deaktivieren, indem sie Safe Browsing mit SafeBrowsingProtectionLevel deaktivieren oder Nutzerfeedback mit der Richtlinie UserFeedbackAllowed nicht zulassen.

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

   

  • Vertikale Tabs back to top

    In Chrome für den Desktop wird ein vertikaler Tabstreifen eingeführt, um die Tabverwaltung für Nutzer zu verbessern, die viele Tabs verwenden. Diese Funktion soll das Suchen und Organisieren von Tabs erleichtern, indem vollständige Seitentitel angezeigt werden. Außerdem wird die Verwendung von Tabgruppen verbessert und der vertikale Bildschirmplatz optimiert.

    • Chrome 147 für Linux, macOS und Windows – Die Funktion wird nach und nach eingeführt: Die Funktion wird nach und nach für macOS, Windows und Linux eingeführt.
    • Chrome 148 für ChromeOS: Die Funktion wird nach und nach für ChromeOS eingeführt.

   

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

    Ab Chrome 126 wurde Bedienungshilfen-Clientsoftware, die das Bedienungshilfen-Framework zur Automatisierung der Benutzeroberfläche von Microsoft Windows verwendet, direkt unterstützt. 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 mit der in Chrome 125 eingeführten Unternehmensrichtlinie UiAutomationProviderEnabled entweder die Aktivierung des neuen Anbieters erzwingen (damit alle Nutzer die neuen Funktionen erhalten) oder den neuen Anbieter deaktivieren.

    Diese Richtlinie wird bis Chrome 146 unterstützt und in Chrome 147 entfernt. Dieser einjährige Zeitraum gab Unternehmen genügend Zeit für die Zusammenarbeit mit Drittanbietern, damit sie Inkompatibilitäten beheben konnten, die durch den Wechsel vom Microsoft-Kompatibilitäts-Shim zum Anbieter der Automatisierung der Benutzeroberfläche von Chrome entstanden.

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

    

   

  • Entfernte Richtlinien im Chrome-Browser back to top
    Richtlinie Beschreibung

    UiAutomationProviderEnabled

    Anbieter des Browser-eigenen Bedienungshilfen-Frameworks zur Benutzeroberflächenautomatisierung unter Windows aktivieren

    PostQuantumKeyAgreementEnabled

    Post-Quanten-Algorithmus für Schlüsselvereinbarungen mit TLS aktivieren

 

Änderungen bei Chrome Enterprise Core

   

  • Erweiterungen anhand von Risikobewertungen von Drittanbietern blockieren back to top

    Bereits ab Chrome 147 können Administratoren in den Einstellungen für Apps und Erweiterungen in der Admin-Konsole einen Risikoschwellenwert konfigurieren, um Erweiterungen mit Risikobewertungen von Drittanbietern (Spin.Ai und LayerX) automatisch zu blockieren. Diese Funktion vereinfacht die Erweiterungsverwaltung und reduziert den manuellen Aufwand, der für die Bewertung und Blockierung von risikoreichen Erweiterungen erforderlich ist. Erweiterungen, die den konfigurierten Risikoschwellenwert überschreiten, werden clientseitig automatisch deaktiviert und Neuinstallationen werden blockiert. In Chrome 147 ist eine Trusted Tester-Vorschau verfügbar. Die Funktion wird nach und nach in Chrome 148 eingeführt.

    • Chrome 147 für Linux, macOS und Windows: Eine frühe Vorabversion ist für Chrome Enterprise Trusted Tester verfügbar.
    • Chrome 148 für Linux, macOS und Windows: Die Funktion wird nach und nach eingeführt.

   

  • Erweiterungen anhand von Chrome Web Store-Kategorien blockieren back to top

    Bereits in Chrome 147 konnten Administratoren die Sicherheit verbessern, indem sie Chrome-Erweiterungen basierend auf ihren Chrome Web Store-Kategorien automatisch blockierten, z. B. alle Spiele-Erweiterungen. Diese Funktion verhindert, dass Erweiterungen aus blockierten Kategorien installiert werden, und deaktiviert sie, falls sie bereits vorhanden sind. Erweiterungen mit erzwungener Installation und auf der Zulassungsliste bleiben davon unberührt.

    Diese Einstellung ist nur in der Admin-Konsole unter Apps & Erweiterungen > Einstellungen im neuen Abschnitt Erweiterte Blockierung von Erweiterungen verfügbar. Der Name der Einstellung lautet Nach Kategorie blockieren. Sie kann auch über die Chrome Management APIs konfiguriert werden. Diese Einstellung ist für lokal verwaltete Geräte nicht verfügbar.

    In Chrome 147 ist eine Trusted Tester-Vorschau verfügbar. Die Funktion wird nach und nach in Chrome 148 eingeführt.

    • Chrome 147 für Linux, macOS und Windows: Eine frühe Vorabversion ist für Chrome Enterprise Trusted Tester verfügbar.
    • Chrome 148 für Linux, macOS und Windows: Die Funktion wird nach und nach eingeführt.

   

  • Neue Veröffentlichungsoption für Organisationen im Chrome Web Store back to top

    In Chrome 147 wird eine neue Funktion zur Veröffentlichung von B2B-Domains im Chrome Web Store eingeführt, mit der Entwickler Erweiterungen direkt an bestimmte Unternehmensdomains verteilen können. Dies ermöglicht eine sichere, skalierbare Bereitstellung für benutzerdefinierte Unternehmenslösungen und verbessert die Verwaltung dieser Bereitstellungen für Administratoren.

    Bisher konnten Unternehmensentwickler Erweiterungen nur privat für ihr eigenes Unternehmen veröffentlichen. Mit der neuen Option können Entwickler ihre Erweiterungen privat für externe Organisationen bereitstellen, die sie genehmigen. Das ist alles direkt im Store möglich.
    Weitere Informationen zum Einstieg finden Sie im Chrome for Developer-Blog: New enterprise publishing option in the Chrome Web Store: Publish to external organizations.

    • Chrome 147 für ChromeOS, Linux, macOS und Windows.

   

  • KI-generierte Zusammenfassung der Versionshinweise in der Admin-Konsole back to top

    In Chrome 147 wird in der Admin-Konsole eine KI-generierte Zusammenfassung der Versionshinweise für Chrome Enterprise eingeführt. So können Administratoren wichtige Updates im aktuellen Release schnell prüfen.

    Diese neue Karte wurde entwickelt, um die Chrome-Verwaltung zu optimieren. Sie enthält KI-generierte Spotlight-Elemente und empfohlene Aktionen. Sie enthält relevante Informationen für Ihre Domain, z. B. neue Funktionen, Richtlinienänderungen und ‑einstellungen sowie Chrome Enterprise Core-Funktionen. So können Administratoren Zeit sparen und wirkungsvolle Änderungen und empfohlene Maßnahmen leichter erkennen.

    • Chrome 145 für Android, iOS, Linux, macOS und Windows: Eine frühe Vorabversion ist für Chrome Enterprise Trusted Tester verfügbar.
    • Chrome 147 für Android, iOS, ChromeOS, Linux, macOS und Windows: Die Funktion wird nach und nach eingeführt.

   

  • Berichte zur Nutzung von generativer KI und SaaS-Anwendungen back to top

    Bereits ab Chrome 147 haben Administratoren in der Admin-Konsole Zugriff auf eine neue Berichtsfunktion zur Nutzung von generativer KI und SaaS-Apps. Dieser Bericht gibt Aufschluss über die Verwendung von Tools mit generativer KI und SaaS-Websites in der Organisation, sodass Administratoren die Nutzung der IT-Ressourcen des Unternehmens im Blick behalten können.

    Dieser Bericht ist nur für Chrome Enterprise Core (CEC)- und Chrome Enterprise Premium (CEP)-Kunden verfügbar.

    In diesem neuen Bericht wird die Nutzung von 60 vordefinierten Websites (einschließlich X Gen AI-Websites) erfasst. Er enthält Messwerte zu Besuchen, eindeutigen verwalteten Profilen, eindeutigen verwalteten Browsern und Zugriff auf sensible Ereignisse zur Inhaltsübertragung. Anhand dieser Informationen können Administratoren das Risiko einschätzen und die Nutzung einschränken, indem sie fundierte Lizenzierungsentscheidungen treffen oder Nutzungsbeschränkungen wie DLP-Regeln (Data Loss Prevention, Schutz vor Datenverlust) erstellen.
    In Chrome 147 ist eine Trusted Tester-Vorschau verfügbar. Die Funktion wird nach und nach in Chrome 149 eingeführt.

    • Chrome 147 für Linux, macOS und Windows: Eine frühe Vorabversion ist für Chrome Enterprise Trusted Tester verfügbar.
    • Chrome 149 für Linux, macOS und Windows: Die Funktion wird nach und nach eingeführt.

Änderungen bei Chrome Enterprise Premium

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

   

  • Unterstützung größerer 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 auf große und verschlüsselte Dateien ausgeweitet.

    Bisher wurden Dateien, die größer als 50 MB sind, und alle verschlüsselten Dateien beim Scannen von Inhalten übersprungen. Mit diesem Update wird diese kritische Sicherheitslücke geschlossen.

    In Chrome 147 können für Richtlinien, die zum Speichern von Beweisen konfiguriert sind, Dateien bis zu 2 GB an den Beweisspeicher gesendet werden. Administratoren erhalten so mehr Transparenz und Kontrolle, wodurch das Risiko der Daten-Exfiltration durch große Dateiübertragungen erheblich verringert wird.

    Hinweis: Da jetzt größere Dateien gespeichert werden, können bei Kunden höhere Google Cloud Storage-Gebühren für ihren Evidence Locker-Bucket anfallen.

    Für die Aktivierung dieser Funktion 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 147 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.

   

  • Neue Vorlagen für Regeln zum Schutz vor Datenverlust back to top  

    Die Bereitstellung branchenführender Datenschutzfunktionen in Chrome ist jetzt schneller und intuitiver. Chrome Enterprise Premium (CEP) bietet sofort einsatzbereite Vorlagen für Regeln zum Schutz vor Datenverlust (Data Loss Prevention, DLP). Damit können Kunden robuste Datenschutzrichtlinien implementieren und die Vorteile der CEP-Sicherheitssuite mit minimalem Einrichtungsaufwand nutzen.

    Mit diesen Vorlagen können Kunden wichtige DLP-Kontrollen schnell und einfach implementieren, ohne von Grund auf neu beginnen zu müssen. Diese Vorlagen bieten eine Grundlage für gängige DLP-Anwendungsfälle, z. B.:

    • Schutz sensibler Daten wie Kreditkartennummern und Sozialversicherungsnummern vor versehentlichem oder böswilligem Verlust.
    • Das Einfügen auf Websites mit generativer KI prüfen, blockieren oder Kategorien von Websites vollständig blockieren.
    • Bildschirmaufnahmen deaktivieren oder Websites mit vertraulichen Informationen mit Wasserzeichen versehen

    Die neuen Datenschutzvorlagen finden Sie in der Admin-Konsole im linken Navigationsmenü unter Regeln > Vorlagen.

    In Chrome 147 ist eine Trusted Tester-Vorschau verfügbar. Die Funktion wird nach und nach in Chrome 148 eingeführt.

    • Chrome 147 für Android, iOS, ChromeOS, Linux, macOS und Windows : Eine frühe Vorabversion ist für Chrome Enterprise Trusted Tester verfügbar. Der Zugriff für Trusted Tester beginnt bereits im April 2026.
    • Chrome 148 für ChromeOS, Linux, macOS und Windows: Die Funktion wird nach und nach eingeführt.

   

  • Optimierte Integration von Chrome Enterprise in Google SecOps back to top  

    Der neue Chrome Enterprise Connector für Google Security Operations (Google SecOps) ist jetzt allgemein verfügbar.

    Der Connector bietet eine neue Integrationsmöglichkeit, mit der Sie optional empfohlene Chrome Enterprise-Einstellungen konfigurieren können, um Chrome-Daten an Google SecOps weiterzuleiten. Mit dem Connector können Administratoren jetzt zuvor konfigurierte Einstellungen beibehalten. Die Daten aus Chrome Enterprise Premium enthalten zusätzlichen Sicherheitskontext aus Safe Browsing. Administratoren können eine Instanz auswählen, die mit ihrer Organisation verbunden ist, oder ein Einmal-Token (ohne Schlüssel) verwenden, um Daten an eine externe Instanz zu senden. Dieser Connector leitet Chrome-Daten über Google Cloud an Google SecOps weiter.

    Weitere Informationen finden Sie im Hilfeartikel Chrome Enterprise Connectors für Google Security Operations konfigurieren.

    • Chrome 142 für iOS, ChromeOS, Linux, macOS und Windows
    • Chrome 147 für ChromeOS, Linux, macOS und Windows – Die Funktion wird nach und nach eingeführt: Chrome Enterprise Connector für Google Security Operations ist allgemein verfügbar.

   

  • Unterstützung von Zulassungs- und Sperrlisten für Entwicklertools back to top  

    In Chrome werden zwei neue Richtlinien eingeführt: DeveloperToolsAvailabilityAllowlist und DeveloperToolsAvailabilityBlocklist. Mit diesen Richtlinien lässt sich die Verfügbarkeit der Entwicklertools anhand von URL-Mustern detailliert steuern.

    Bisher konnten Administratoren Entwicklertools nur global zulassen oder verbieten. Mit diesen neuen Richtlinien können Administratoren jetzt eine allgemeine Blockierung von Entwicklertools erzwingen, um sensible Unternehmensdaten zu schützen, und gleichzeitig den Zugriff auf bestimmte interne URLs für Entwicklungs- oder Fehlerbehebungszwecke explizit zulassen.

    Diese Einstellungen sind für Windows, Mac, Linux und ChromeOS verfügbar. Wenn diese neuen Richtlinien nicht konfiguriert sind, bleibt das Verhalten der vorhandenen Richtlinie DeveloperToolsAvailability unverändert.

    • Chrome 147 für ChromeOS, Linux, macOS und Windows: Die Funktion wird nach und nach eingeführt. Die Richtlinien DeveloperToolsAvailabilityAllowlist und DeveloperToolsAvailabilityBlocklist werden auf Desktop-Plattformen eingeführt.

   

  • Unterstützung von Zulassungs- und Sperrlisten für den Inkognitomodus back to top  

    In Chrome werden zwei neue Richtlinien eingeführt: IncognitoModeUrlBlocklist und IncognitoModeUrlAllowlist. Damit erhalten Administratoren eine genauere Kontrolle über die Verwendung des Inkognitomodus.

    Im Rahmen dieser Änderung wird in Chrome auch das Standardverhalten von Platzhaltermustern in der vorhandenen Richtlinie URLBlocklist und in der neuen Richtlinie IncognitoModeUrlAllowlist aktualisiert, um die Navigation zu internen chrome://-Seiten zu ermöglichen. Wenn ein Administrator interne chrome://-Seiten blockieren möchte, muss er diese explizit blockieren und kann sich nicht auf den Platzhalter verlassen. Der Zugriff auf interne chrome://-Seiten ist für die ordnungsgemäße Funktion mehrerer Chrome-Funktionen wie Suche, Seite „Neuer Tab“ und Drucken erforderlich.

    Diese neuen Richtlinien funktionieren ähnlich wie die vorhandenen Richtlinien URLBlocklist und URLAllowlist, sind aber speziell für Inkognitositzungen vorgesehen. So können Organisationen den Zugriff auf bestimmte URLs im Inkognitomodus einschränken, um vertrauliche Informationen zu schützen, während die legitime Nutzung auf anderen Websites zulässig ist. Bisher konnten Administratoren den Inkognitomodus nur über die Richtlinie IncognitoModeAvailability vollständig aktivieren oder deaktivieren.

    • Chrome 147 für Android, iOS, ChromeOS, Linux, macOS und Windows: Die Funktion wird nach und nach eingeführt. Die Richtlinien IncognitoModeUrlBlocklist und IncognitoModeUrlAllowlist werden eingeführt.

↑ 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

   

  • Chrome-Profil-Bootstrapping über benutzerdefinierten URI back to top

    Mit dieser Funktion wird ein neues benutzerdefiniertes URI-Schema (google-chrome://) eingeführt, mit dem externe Anwendungen und Webportale Chrome direkt in einem bestimmten verwalteten Profil starten können. Wenn das angegebene Profil nicht vorhanden ist, wird der Nutzer durch einen optimierten Ablauf zur Profilerstellung geführt, in dem seine Arbeits-E-Mail-Adresse bereits eingetragen ist. So können Nutzer nahtlos von beliebigen Browsern oder integrierten App-Katalogen in eine sichere, verwaltete Chrome-Umgebung wechseln. Administratoren können dieses Verhalten mit der Richtlinie ChromeURILaunchEnabled steuern.

    • Chrome 148 für macOS und Windows: Eine frühe Vorabversion ist für Chrome Enterprise Trusted Tester verfügbar.  

   

  • Erweitertes Autofill back to top

    Ab Chrome 137 können einige Nutzer die erweiterte Autofill-Funktion aktivieren, mit der sich Onlineformulare einfacher ausfüllen lassen. In entsprechenden Formularen kann Chrome KI verwenden, um das Formular besser zu verstehen und Nutzern anzubieten, zuvor gespeicherte Informationen automatisch auszufüllen. Administratoren können die Funktion über die vorhandene Richtlinie GenAiDefaultSettings und die neue Richtlinie AutofillPredictionSettings steuern.

    • Chrome 137 für ChromeOS, Linux, macOS und Windows: Die Funktion wird nach und nach eingeführt.
    • Chrome 140 für ChromeOS, Linux, macOS und Windows: Die vorhandene Funktion „Mit KI automatisch ausfüllen“ wird in „Erweitertes automatisches Ausfüllen“ umbenannt. Nutzer können damit zusätzliche Arten von Informationen speichern und ausfüllen lassen. Außerdem wird die Funktion in weiteren Ländern und Sprachen verfügbar sein.
    • Chrome 148 für Android und iOS: Die verbesserte Autofill-Funktion wird für Nutzer von Chrome für Android und Chrome für iOS verfügbar gemacht.

   

  • SharedWorker mit verlängerter Lebensdauer back to top

    Durch dieses Update wird dem SharedWorker-Konstruktor die neue Option extendedLifetime: true hinzugefügt. Dadurch wird angefordert, dass der Shared Worker auch dann aktiv bleibt, wenn alle aktuellen Clients entladen wurden. Der primäre Anwendungsfall besteht darin, dass Seiten nach dem Entladen asynchrone Aufgaben ausführen können, für die JavaScript erforderlich ist, ohne auf einen Service Worker angewiesen zu sein.

    • Chrome 148 für Windows, macOS, Linux und Android: Kein Roll-out-Schritt.

   

  • Migration von PWA-Ursprüngen back to top

    Wenn ein Nutzer eine progressive Web-App (PWA) installiert, sind ihre Identität und ihr Sicherheitskontext eng an ihren Webursprung gebunden, z. B. app.beispiel.de. Dies stellt eine erhebliche Herausforderung für Entwickler dar, die den Ursprung ihrer PWA aufgrund von Rebranding, Domainrestrukturierung oder technischer Umstrukturierung ändern müssen. Derzeit müssen Nutzer die alte App manuell deinstallieren und die neue App neu installieren. Das ist umständlich und kann zu Nutzerverlusten führen. In Chrome 148 wird ein Mechanismus eingeführt, mit dem Entwickler eine installierte PWA nahtlos zu einem neuen Ursprung auf derselben Website migrieren können, wobei das Vertrauen der Nutzer und die Berechtigungen erhalten bleiben.

    Die Richtlinie WebAppInstallForceList blockiert die Migration. Da Unternehmensrichtlinien für Webanwendungen hauptsächlich auf URLs und Ursprüngen basieren, besteht das Risiko, dass bei einer Migration bestimmte Richtlinien umgangen werden, die ein Administrator konfiguriert hat. Wenn eine App vom Unternehmensadministrator zwangsweise installiert wird, wird dem Nutzer keine Migration angeboten. Stattdessen wird ein Banner mit einer entsprechenden Erklärung angezeigt.

    • Chrome 148 für Windows, macOS und Linux: Kein Roll-out-Schritt.

   

  • Prompt API back to top

    Die Prompt API ist für die Interaktion mit einem KI-Sprachmodell über Text-, Bild- und Audioeingaben konzipiert. Es unterstützt verschiedene Anwendungsfälle, von der Generierung von Bildunterschriften und der Durchführung visueller Suchanfragen bis hin zur Transkription von Audio, der Klassifizierung von Klangereignissen, der Generierung von Text nach bestimmten Anweisungen und dem Extrahieren von Informationen oder Statistiken aus Text. Es unterstützt strukturierte Ausgaben, die dafür sorgen, dass Antworten einem vordefinierten Format entsprechen, das in der Regel als JSON-Schema ausgedrückt wird. Dadurch wird die Konformität der Antworten verbessert und die nahtlose Integration in nachgelagerte Anwendungen, die standardisierte Ausgabeformate erfordern, erleichtert.

    Diese API ist auch in Chrome-Erweiterungen verfügbar. In diesem Feature-Eintrag wird die Sichtbarkeit im Web erfasst. Mit der Unternehmensrichtlinie GenAILocalFoundationalModelSettings kann das Herunterladen des zugrunde liegenden Modells deaktiviert werden. Diese API ist dann nicht mehr verfügbar.

    Protokoll zur Sprachunterstützung:

    • In Chrome M139 und früheren Versionen wurde nur „en“ unterstützt.
    • In Chrome M140 wurde Unterstützung für „es“ und „ja“ hinzugefügt.
    • Chrome 148 für Windows, macOS und Linux: Die Funktion wird nach und nach eingeführt.

   

  • Chrome für ARM64-Linux-Geräte back to top

    Wir freuen uns, Ihnen mitteilen zu können, dass Google im zweiten Quartal 2026 Chrome für ARM64-Linux-Geräte einführen wird. Dies folgt auf die erfolgreiche Erweiterung von Chrome auf Arm-basierte macOS-Geräte im Jahr 2020 und auf Arm-basierte Windows-Geräte im Jahr 2024.

    Durch die Einführung von Chrome für ARM64-Linux-Geräte können mehr Nutzer die nahtlose Integration der nützlichsten Google-Dienste in ihren Browser nutzen. Mit diesem Schritt reagieren wir auf die wachsende Nachfrage nach einem Browser, der die Vorteile des Open-Source-Projekts Chromium mit dem Google-Ökosystem aus Apps und Funktionen kombiniert.

    Weitere Informationen finden Sie in diesem Chromium-Blogpost.

    • Chrome 149 für Linux: Die Funktion wird nach und nach eingeführt. 

   

  • Aktualisierung der No HTTPS-Warnungback to top

    Die Warnung, die angezeigt wird, wenn ein Nutzer die Option Immer sichere Verbindungen verwenden unter chrome://settings/security aktiviert, wird von einer Interstitial-Seite zu einem Dialogfeld geändert. Das vollständige Laden der Seite bleibt blockiert und die Funktionalität bleibt unverändert. Das Symbol für die Sicherheit von URL-Inhalten in der Warnung wird vom Indikator zum aufgebrochenen Schloss geä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 141 für ChromeOS, Linux, macOS und Windows: Neues Warnungsdesign auf Desktop-Plattformen.
    • Chrome 149 für Android: Ähnliches aktualisiertes Warnungsdesign für Android, bei dem anstelle eines vollständigen Interstitials eine Warnblase verwendet wird.

   

  • Standardmäßig „Immer verschlüsselte Verbindungen verwenden“ back to top

    In Chrome 150 wird die Einstellung Immer verschlüsselte Verbindungen verwenden standardmäßig im Modus „Nur öffentliche Websites“ aktiviert. Das bedeutet, dass Chrome die Einwilligung des Nutzers einholt, bevor zum ersten Mal auf eine öffentliche Website ohne HTTPS zugegriffen wird. Öffentliche Websites sind Websites mit einem global eindeutigen Namen. Direkte Aufrufe von RFC 1918-Adressen (192.168.0.1, 10.0.0.0/8 usw.) sowie Kurznamen wie go/ sind ausgeschlossen.

    Bevor die Funktion standardmäßig für alle Nutzer aktiviert wird, wird Immer sichere Verbindungen verwenden für Nutzer aktiviert, die erweiterte Safe Browsing-Schutzfunktionen in Chrome aktiviert haben.

    Wenn Sie Webentwickler oder IT-Experte sind und Nutzer haben, die von dieser Funktion betroffen sein könnten, empfehlen wir Ihnen dringend, die Einstellung „Immer sichere Verbindungen verwenden“ noch heute zu aktivieren, um Websites zu identifizieren, die Sie möglicherweise migrieren müssen. Administratoren können dieses Verhalten mit den Richtlinien HttpAllowlist und HttpsOnlyMode überschreiben.

    Weitere Informationen finden Sie in unserem Leitfaden zur Einführung und im Blogpost zur Ankündigung.

    • Chrome 150 für Android, ChromeOS, Linux, macOS, Windows und Fuchsia: „Immer verschlüsselte Verbindungen verwenden“ für Nutzer aktivieren, die das erweiterte Safe Browsing aktiviert haben.
    • Chrome 154 für Android, ChromeOS, Linux, macOS, Windows und Fuchsia: „Immer verschlüsselte Verbindungen verwenden“ standardmäßig für alle Nutzer aktivieren.

   

  • Einstellung und Entfernung von Privacy Sandbox-APIs  back to top

    Chrome hat vor Kurzem angekündigt, dass der aktuelle Ansatz für Drittanbieter-Cookies beibehalten wird. Entsprechend planen wir, die folgenden APIs einzustellen und zu entfernen.

    • Themen
    • Protected Audience
    • Freigegebener Speicher
    • Attributionsberichte
    • Private Aggregation
    • Ähnliche Websites
    • requestStorageAccessFor

    Im Folgenden sind die Unternehmensrichtlinien aufgeführt, die den oben genannten APIs zugeordnet sind.

    Die Einstellung begann mit Chrome 144 und die Entfernung ist für Chrome 150 geplant. Nach der Einstellung sind die APIs weiterhin vorhanden und die meisten Nutzer werden keine Unterbrechungen feststellen. Bei einigen Nutzern, die auf serverseitige Integrationen angewiesen sind (z. B. K-Anonymitätsserver oder Koordinatoren), kommt es jedoch zu einer Unterbrechung der Dienste. Wir haben uns proaktiv an Nutzer der APIs gewandt, um sie über unsere Pläne zur Einstellung zu informieren. Mit der Entfernung in Chrome 150 werden auch alle mit diesen APIs verknüpften Richtlinien entfernt.

    Keine der APIs ist für Unternehmensnutzer standardmäßig aktiviert. Enterprise-Teams können den Status aller verwalteten Profile in der Admin-Konsole einsehen.

    • Chrome 144 für Android, ChromeOS, Linux, MacOS und Windows: Einführung der Einstellung.
    • Chrome 150 für Android, ChromeOS, Linux, macOS und Windows: APIs und zugehörige Richtlinien werden 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 im Explainer beschriebenen Methoden an Endnutzer verteilt. 

    Bereits ab Chrome 150 können isolierte Web-Apps nur noch über eine Administratorrichtlinie auf von Unternehmen verwalteten ChromeOS-Geräten installiert werden.

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

   

  • 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 150 für Android, iOS, ChromeOS, Linux, macOS und Windows: Die Funktion wird nach und nach eingeführt.

   

  • Ende der Unterstützung von macOS 12 in Chromeback to top

    Chrome 150 ist die letzte Version, die macOS 12 unterstützt. Chrome 151 und höher unterstützen macOS 12 nicht mehr, da diese Version sich außerhalb des Supportzeitraums von Apple befindet. Zur Aufrechterhaltung der Sicherheit ist die Ausführung eines unterstützten Betriebssystems unerlässlich.

    Auf Macs mit macOS 12 funktioniert Chrome weiterhin und es wird eine Warnung in der Infoleiste angezeigt. Chrome wird jedoch nicht mehr aktualisiert. Wenn ein Nutzer Chrome aktualisieren möchte, muss er seinen Computer auf eine unterstützte Version von macOS aktualisieren. 

    Für Neuinstallationen von Chrome 151 oder höher ist macOS 13 oder höher erforderlich.

    • Chrome 151 für Windows, macOS und Linux

   

  • XSLT einstellen und entfernen back to top

    XSLT v1.0, an die sich alle Browser halten, wurde 1999 standardisiert. Inzwischen hat sich XSLT zu Version 2.0 und 3.0 weiterentwickelt und unterscheidet sich von der alten, in Browsern fixierten Version. Diese fehlende Weiterentwicklung in Verbindung mit dem Aufkommen von JavaScript-Bibliotheken und ‑Frameworks, die eine flexiblere und leistungsstärkere DOM-Manipulation ermöglichen, hat zu einem erheblichen Rückgang der Verwendung von clientseitiger XSLT geführt. Ihre Rolle im Webbrowser wurde weitgehend durch JavaScript-basierte Technologien wie JSON+React ersetzt.

    Chromium verwendet die libxslt-Bibliothek, um diese Transformationen zu verarbeiten. libxslt wurde etwa sechs Monate lang im Jahr 2025 nicht gewartet. Libxslt ist eine komplexe, veraltete C-Codebasis, die bekanntermaßen anfällig für Speichersicherheitslücken wie Überläufe des Zwischenspeichers ist, die zur Ausführung von beliebigem Code führen können. Da clientseitige XSLT mittlerweile eine Nischenfunktion ist, die nur selten verwendet wird, werden diese Bibliotheken viel seltener gewartet und auf Sicherheit geprüft als die wichtigsten JavaScript-Engines. Sie stellen jedoch eine direkte, wirksame Angriffsfläche für die Verarbeitung nicht vertrauenswürdiger Webinhalte dar. Tatsächlich ist XSLT die Quelle mehrerer schwerwiegender Sicherheitslücken, die Browsernutzer weiterhin gefährden. Aus diesen Gründen planen Chromium und die anderen Browser-Engines, XSLT von der Webplattform zu entfernen. Weitere Informationen finden Sie in diesem Artikel auf Chrome für Entwickler.

    • Chrome 143 für Android, ChromeOS, Linux, macOS und Windows: Die APIs werden eingestellt, aber nicht entfernt.
    • Chrome 152 für Android, ChromeOS, Linux, macOS und Windows: Der Ursprungstest (Origin Trial, OT) und die Unternehmensrichtlinie werden zu Testzwecken eingeführt. Damit können Websites und Unternehmen Funktionen auch nach dem Entfernen weiterhin verwenden.
    • Chrome 160 für Android, ChromeOS, Linux, MacOS und Windows: XSLT funktioniert in stabilen Versionen für alle Nutzer außer Teilnehmern am Ursprungstest und an der Unternehmensrichtlinie nicht mehr.
    • Chrome 176 für Android, ChromeOS, Linux, macOS und Windows: Ursprungstest und Unternehmensrichtlinie funktionieren nicht mehr. XSLT ist für alle Nutzer deaktiviert.

   

  • PostQuantum-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 WebRtcPostQuantumKeyAgreement 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: Einführung der Funktion
    • Chrome 152 für Android, ChromeOS, Linux, macOS, Windows und Fuchsia: Unternehmensrichtlinie entfernen

   

  • Umstellung auf einen 2‑Wochen-Versionszyklus back to top

    Ab September 2026 (Chrome 153) wird Chrome vom aktuellen vierwöchigen Zyklus auf einen zweiwöchigen Releasezyklus umgestellt. Die Webplattform wird ständig weiterentwickelt. Unser Ziel bei Chrome ist es, Entwicklern und Nutzern sofortigen Zugriff auf die neuesten Funktionen, Fehlerkorrekturen und Leistungsverbesserungen zu ermöglichen. Wir haben unseren Releaseprozess schon immer an die Anforderungen eines modernen Webs angepasst. Jetzt gehen wir einen wichtigen Schritt, um die Entwicklungsgeschwindigkeit weiter zu erhöhen. Die stabile Chrome-Version wird auf einen 2‑Wochen-Versionszyklus umgestellt. Weitere Informationen finden Sie im Chrome for Developers-Blogpost.

    Die erweiterte stabile Version ist für Kunden verfügbar, die Bedenken wegen der Wartungskosten haben. Weitere Informationen zur erweiterten stabilen Version finden Sie in diesem Hilfeartikel. Die Option für 2 Wochen stabile Version ist weiterhin die sicherste Wahl und sollte verwendet werden, wenn Ihnen Sicherheit wichtiger ist als Wartungskosten.

    • Chrome 153 für Android, iOS, Linux, macOS und Windows: Umstellung auf einen 2‑Wochen-Releasezyklus

   

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

    Gemäß der URL-Standardspezifikation dürfen URL-Hosts keine 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 Leerzeichen aus URL-Hosts entfernen. Das Problem dabei ist, dass sie im Hostteil von Windows-file://-URLs verwendet werden. Weitere Informationen finden Sie in dieser GitHub-Diskussion.

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

 

Bevorstehende Updates für Chrome Enterprise Core

   

  • Unterstützung von Chrome-Clientzertifikaten unter iOS back to top

    Die integrierte Unterstützung von Clientzertifikaten in Chrome für iOS ermöglicht es verwalteten Nutzern, sich sicher mit gegenseitigem TLS (mTLS) bei Unternehmensressourcen zu authentifizieren. Bisher wurden iOS-Zertifikate im Systemspeicher isoliert, auf den nur integrierte Apple-Apps zugreifen konnten. Mit dieser Einführung kann Chrome jedoch eigene hardwaregestützte Zertifikate unabhängig bereitstellen und verwalten. Durch die Integration in die iOS Secure Enclave für die Speicherung nicht exportierbarer privater Schlüssel bietet Chrome ein Identitätssignal mit hoher Sicherheit speziell für Zero Trust-Umgebungen mit Microsoft Entra ID und bedingtem Zugriff. Diese Anmeldedaten werden im vom Unternehmen verwalteten Chrome-Profil bereitgestellt und sind für andere Anwendungen oder private Profile auf dem Gerät nicht zugänglich.

    Damit diese Funktion implementiert werden kann, müssen Administratoren in der Admin-Konsole den Ein/Aus-Button Unterstützte Nutzereinstellungen auf Chrome für iOS anwenden aktivieren und die Richtlinien ProvisionManagedClientCertificateForBrowser und ProvisionManagedClientCertificateForUser konfigurieren, um die Ausstellung und Rotation zu starten. Schließlich sollte die Richtlinie AutoSelectCertificateForUrls verwendet werden, um die Zertifikatauswahl für bestimmte Unternehmensdomains zu automatisieren und so einen reibungslosen Authentifizierungsablauf zu ermöglichen.

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

   

  • Unterstützung für Berichte zu verwalteten Profilen back to top

    Mit Chrome Enterprise Core wird in der Admin-Konsole die Unterstützung von Cloud-Profilberichten für den Bericht Nutzung von Apps und Erweiterungen und den Bericht Versionen eingeführt.

    Im Bericht Nutzung von Apps und Erweiterungen sehen Administratoren eine neue Gesamtzahl der Installationen für verwaltete Profile (Arbeitsprofile). Sie können sehen, welche Erweiterungen in allen verwalteten Profilen am häufigsten installiert sind.

    Im Bericht Versionen sehen Administratoren die Gesamtzahl der verwalteten Profile, in denen die einzelnen Chrome-Versionen ausgeführt werden. So können sie beispielsweise sehen, ob in verwalteten Profilen ältere Chrome-Versionen verwendet werden.

    Damit die Cloud-Profilberichterstellung für beide Berichte aktiviert wird, müssen Administratoren die vorhandene Richtlinie CloudProfileReportingEnabled aktivieren. Wenn Sie die Berichte zu verwalteten Profilen bereits aktiviert haben, werden die Daten automatisch in den Berichten erfasst.

    Wo finde ich diese Berichte? Gehen Sie in der Admin-Konsole zu Chrome-Browser > Berichte > Nutzung von Apps und Erweiterungen oder Chrome-Browser > Berichte > Versionen.

    • Chrome 148 für Android, iOS, ChromeOS, Linux, macOS und Windows: Die Profilberichterstellung im Versionsbericht ist für Chrome Enterprise Trusted Tester verfügbar.

 

Bevorstehende Updates für Chrome Enterprise Premium

    

  • Chrome Enterprise Connectors API back to top

    Chrome Enterprise wird die programmatische Verwaltung für Chrome Enterprise Connectors bald ausweiten. Mit diesem Update werden Ressourcen eingeführt, mit denen sich Connector-Konfigurationen definieren und zuweisen lassen. So werden die vorhandenen Connector-Richtlinien ergänzt und Administratoren können den gesamten Lebenszyklus dieser Integrationen im großen Maßstab verwalten.

    Bisher mussten Dienstanbieter manuell in der Google Admin-Konsole konfiguriert werden. Dieses Update ermöglicht die Automatisierung, wodurch manuelle Fehler reduziert und die Effizienz der Verwaltung von Integrationen mit Sicherheitslösungen von Drittanbietern verbessert wird.

    Administratoren können jetzt die Chrome Management API verwenden, um ConnectorConfiguration-Ressourcen (zur Definition des Anbieters) zu verwalten. Die Auswahl des Connectors erfolgt über die Chrome Policy API. So können diese Konfigurationen Organisationseinheiten oder Gruppen zugewiesen werden. Dies funktioniert in Verbindung mit den vorhandenen Policy API-Einstellungen für die Ereignisberichterstellung und Inhaltsanalyse, einschließlich Richtlinien wie OnSecurityEventEnterpriseConnector, OnFileAttachedEnterpriseConnector, OnFileDownloadedEnterpriseConnector, OnBulkDataEntryEnterpriseConnector, OnPrintEnterpriseConnector und EnterpriseRealTimeUrlCheckMode. Technische Details finden Entwickler in der Chrome Management API und der Dokumentation zur Chrome Policy API.

    • Chrome 143 für Android, iOS, Linux, macOS und Windows: Mit diesem Roll-out wird die Unterstützung für die programmatische Verwaltung von Chrome Enterprise-Connectors über eine neue API hinzugefügt.
    • Chrome 148 für Android, iOS, Linux, macOS und Windows: Mit diesem Roll-out werden die Ressourcen „ConnectorConfiguration“ und „ConnectorSelection“ eingeführt, die die Erstellung von Dienstleisterinstanzen und deren Zuweisung zu Organisationseinheiten ermöglichen.

    

  • Unterstützung für Drag-and-drop für Datensteuerungen back to top

    Chrome erweitert das Framework für die Datenkontrolle, indem die Sicherheitsdurchsetzung auf Drag-and-drop-Vorgänge unter Windows, Mac, Linux, ChromeOS und Android ausgeweitet wird, um die Konsistenz mit bestehenden Zwischenablagerichtlinien zu ermöglichen. Administratoren können dieses Verhalten über die Richtlinie DataControlsRules verwalten. WARN-Entscheidungen werden jedoch automatisch zu BLOCK-Entscheidungen eskaliert, um zu verhindern, dass ein Warndialog den interaktiven Drag-Vorgang unterbricht.

    Wenn eine Aktion eingeschränkt ist, sehen Nutzer den neuen Dialog ClipboardDragBlock oder ein modales Android-Dialogfeld zur Blockierung, in dem darauf hingewiesen wird, dass das Ziehen von Inhalten auf der Website nicht zulässig ist. Mit diesem Update wird eine kritische Lücke in Sachen Daten-Exfiltration geschlossen. Dabei wird die lokale Auswertung genutzt, um Leistung und Datenschutz zu gewährleisten. Organisationen sollten diese Regeln mit dem Feature-Flag DataControlsDragEnforcement und der Seite chrome://policy/test testen.

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

    

  • Telemetriedaten für DOM-Aktivitäten von Unternehmenserweiterungen back to top

    Diese Funktion ist nur für Unternehmen verfügbar und bietet Sicherheitsprüfungen für Chrome-Erweiterungen. Dazu wird eine High-Fidelity-Pipeline erstellt, die riskantes Verhalten überwacht. Dabei geht es insbesondere darum, Code-Injection-Risiken (Ausführungsrisiken) und Datenzugriffsrisiken (Diebstahlrisiken) zu erkennen, die zwischen Webseiten und Erweiterungen auftreten. Bestätigte Signale werden gefiltert, damit die Browserleistung nicht beeinträchtigt wird. Sie werden schließlich über die Chrome-Pipeline für Echtzeitberichte zur Analyse durch das SIEM-System (Security Information and Event Management) übertragen.

    • Chrome 148 für ChromeOS, Linux, macOS und Windows: Eine frühe Vorabversion ist für Chrome Enterprise Trusted Tester verfügbar.

    

  • Neue Richtlinieneinstellung für DataControlRules back to top

    Die vorhandene Richtlinie DataControlsRules wird in Chrome durch die neue Einstellung Einschränkungen beim Einfügen über Verwaltungsgrenzen hinweg erweitert. Mit diesem Update erhalten Administratoren einen kontextbasierten Mechanismus, um zu verhindern, dass sensible Webinhalte in oder aus verwalteten Chrome-Profilen eingefügt werden, ohne dass bestimmte Quell- oder Ziel-URLs erforderlich sind.

    Ab Chrome 148 konnten Administratoren in der Admin-Konsole mit einfachen Kästchen Datengrenzen für den Inkognitomodus, andere Chrome-Profile und Anwendungen, die nicht Chrome sind, festlegen. Diese Verbesserung soll den Schutz vor Datenverlust für Chrome Enterprise Premium-Kunden stärken, indem die Exfiltration von Unternehmensdaten in nicht verwaltete Umgebungen verhindert wird. Nutzer erhalten sofortige Benachrichtigungen im Browser, wenn eine Einfügeaktion eingeschränkt wird. So sind sie in Echtzeit über die Sicherheitsrichtlinien der Organisation informiert.

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

    

  • Schutz vor Manipulationen an lokalen Richtlinien back to top

    Lokale Einstellungen auf BYOD-Geräten (Bring Your Own Device) können manchmal mit den Einstellungen für Unternehmensrichtlinien in Konflikt stehen. Um diese potenzielle Sicherheitslücke zu schließen, werden mit Signalen für Richtlinienkonflikte in Chrome jetzt Unternehmensrichtlinien erkannt und gemeldet, die durch lokale Richtlinien überschrieben werden. In Chrome 145 werden diese neuen Richtlinienkonfliktsignale aus dem verwalteten Chrome-Profil in vorhandene Sicherheitsberichte eingebunden, die von der Richtlinie UserSecuritySignalsReporting gesteuert werden.

    Weitere Informationen zur Berichterstellung für Geräte finden Sie im Hilfeartikel Liste und Details von ChromeOS-Geräten aufrufen.

    • Chrome 144 für Linux, MacOS und Windows: Die Erkennung und Meldung von Metadaten zu Richtlinienkonflikten beginnt.
    • Chrome 145 für Linux, macOS und Windows: Über die Devices API sind Signale zur Härtung von Chrome-Richtlinien verfügbar.
    • Chrome 150 für Linux, macOS und Windows: Die Benutzeroberfläche der Admin-Konsole wird aktualisiert und zeigt nun Konfliktsignale an. Außerdem werden Richtlinienwerte gemeldet.

↑ 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 146: 25. Februar 2026
Chrome 145: 28. Januar 2026
Chrome 144: 7. Januar 2026
Chrome 143: 10. Dezember 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?
true
Suche
Suche löschen
Suche schließen
Google-Apps
Hauptmenü
17917649110062890673
true
Suchen in der Hilfe
false
true
true
true
true
true
410864
false
false
false
false