[go: up one dir, main page]

Versionshinweise für Chrome Enterprise und Chrome Education

Zuletzt aktualisiert am 11. September 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 140

 
Änderungen am Chrome-Browser Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Automatisierte Passwortänderung ✓    
Kontextbezogene Suchvorschläge in der Chrome-Adressleiste   ✓  
DSE-Prewarming   ✓  
Erweitertes Autofill   ✓  
Chrome mit einem neuen Profil über die Befehlszeile starten ✓   ✓
Angemeldete Nutzer: Autofill und Einstellungen aus dem Google-Konto ✓    
„ServiceWorkerAutoPreload“-Modus     ✓
Geteilte Tabgruppen   ✓  
Aktualisierung der Warnung Kein HTTPS ✓    
Senden des Headers Purpose: prefetch bei Prefetching und Prerendering beenden ✓   ✓
Sonderregeln für die Schriftgröße für H1-Überschriften in bestimmten Elementen werden eingestellt     ✓
SharedWorker übernimmt Controller für Blob-URL     ✓
Neue Richtlinien im Chrome-Browser     ✓
Änderungen bei Chrome Enterprise Core Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Neue Filter auf der Übersichtsseite zu Chrome Enterprise     ✓
Abgedeckte Chrome Enterprise-Daten regionalisieren     ✓
Änderungen bei Chrome Enterprise Premium Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Datenschutzregeln für Kopieren/Einfügen ✓   ✓
DLP-Unterstützung für iFrames ✓   ✓
Anstehende Änderungen für den Chrome-Browser Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Heuristisches Signal für Suchhijacking zur Telemetrie von Erweiterungen hinzufügen ✓    
Fußzeile auf der Seite „Neuer Tab“ ✓ ✓ ✓
Gemini in Chrome   ✓  
Post-Quanten-Kryptografie für DTLS in WebRTC ✓    
CSS-Pseudo-Elemente für das Hervorheben von Suchergebnissen auf der Seite   ✓ ✓
Einschränkungen für den Zugriff auf lokales Netzwerk ✓   ✓
Ursprungsgebundene Cookies (standardmäßig) ✓    
Berechtigungsrichtlinie für die Device Attributes API ✓   ✓
Strenge Richtlinie zum gleichen Ursprung für die Storage Access API ✓    
window.name-Attribut wird bei websiteübergreifenden Navigationen nicht mehr beibehalten  ✓    
savedTabGroups als individuellen Wert in SyncTypesListDisabled wird eingestellt     ✓
Nicht vertrauenswürdiges Klartext-HTTP-Prerendering zulassen ✓    
HSTS-Tracking-Schutz ✓    
Web-App-Manifest: Algorithmus für Aktualisierungsvoraussetzungen    

✓
Happy Eyeballs V3 ✓   ✓
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
Unterstützung registrierter Browser für Anpassungen des Enterprise Chrome Web Store   ✓  
Löschen inaktiver Profile in Chrome Enterprise Core ✓   ✓
Bevorstehende Änderungen bei Chrome Enterprise Premium Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
UX-Refaktorierung für Chrome-Browserregeln ✓   ✓
Unterstützung größerer Dateien für DLP-Scans ✓   ✓
Wasserzeichen anpassen ✓   ✓

 

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  

   

  • Automatisierte Passwortänderung back to top

    Wenn Chrome erkennt, dass ein Nutzer sich mit einem bekannten gehackten Passwort auf einer Website angemeldet hat, wird ihm jetzt angeboten, das Passwort automatisch zu ändern. Diese Funktion ist auf einer Reihe von berechtigten Websites verfügbar. Für die Funktion wird KI verwendet. Administratoren können sie über die Unternehmensrichtlinie AutomatedPasswordChangeSettings steuern.

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

   

  • Kontextbezogene Suchvorschläge in der Chrome-Adressleiste back to top

    Mit dieser Funktion können Sie direkt im Kontext Fragen zur aktuellen Seite stellen. Basierend auf der bestehenden Suchgewohnheit der Adressleiste können Nutzer mit Google Lens Fragen stellen, indem sie etwas auf dem Bildschirm auswählen oder eine Frage stellen. Eine Google Lens-Aktion in der Adressleiste und kontextbezogene Vorschläge führen Nutzer zu der Funktion, wenn sie am hilfreichsten ist. Administratoren können diese Funktion mit der bestehenden Richtlinie LensOverlaySettings steuern.

     
    • Chrome 138 für ChromeOS, Linux, macOS und Windows: Einführung der Funktion
    • Chrome 140 für ChromeOS, Linux, macOS und Windows: Wenn die Richtlinie LensOverlaySettings nicht festgelegt ist, wird diese Funktion gemäß der Richtlinie GenAiDefaultSettings ausgeführt, sofern diese vorhanden ist.

 

   

  • DSE-Prewarming back to top

    Durch DSE Prewarming wird die Integration des Standardsuchanbieters in die Omnibox optimiert. Wenn die Omnibox den Fokus erhält, beginnt Chrome mit dem Pre-Rendering der Prewarm-Seite, auf der die für die Suchergebnisseite erforderlichen Ressourcen vorab geladen werden. Die Ressourcen werden wiederverwendet, um die Navigation zur Suchergebnisseite bei der nächsten Anfrage zu beschleunigen. Administratoren können diese Funktion mit der Unternehmensrichtlinie NetworkPredictionOptions steuern.

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

   

  • Erweitertes Autofill back to top

    Ab Chrome 137 können einige Nutzer Autofill mit KI aktivieren. Diese neue Funktion hilft Nutzern, Onlineformulare einfacher auszufüllen. 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
    • Chrome 140 für ChromeOS, Linux, macOS und Windows: Die vorhandene Funktion Autofill mit KI wird in Erweitertes Autofill 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 mit einem neuen Profil über die Befehlszeile starten back to top

    Diese Funktion wurde für unsere Unternehmenspartner und Administratoren entwickelt, die Webanwendungen aus ihren nativen App-Katalogen direkt in einem bestimmten verwalteten Chrome-Profil über die Chrome-Befehlszeile starten müssen. Wenn das angegebene Profil derzeit nicht vorhanden ist, wird in Chrome standardmäßig das zuletzt verwendete Profil verwendet, was zu einer uneinheitlichen Nutzererfahrung führt. Wenn ein angegebenes Profil nicht gefunden wird, startet Chrome mit dieser neuen Funktion den vorhandenen Profilerstellungsablauf und füllt die E-Mail-Adresse des Nutzers vorab aus, um die Einrichtung zu vereinfachen. Dies ist eine wichtige technische Voraussetzung für Administratoren, die ihre Unternehmensnutzer über verwaltete Profile in Chrome Enterprise einbinden möchten.

    • Chrome 140 für Linux, macOS und Windows
     

   

  • Angemeldete Nutzer: Autofill und Einstellungen aus dem Google-Konto back to top

    Im Rahmen unserer Bemühungen, das Identitätsmodell von Chrome auf dem Computer zu optimieren, können verwaltete Konten, die ursprünglich implizit in Chrome angemeldet wurden, indem sie sich in einer Google-Web-Property angemeldet haben, und die sich in einem verwalteten Profil mit Nutzerrichtlinien befinden, jetzt AutoFill-Daten, Einstellungen und Designs aus ihrem Google-Konto speichern und verwenden, während sie angemeldet sind. Bestehende Nutzerrichtlinien funktionieren weiterhin wie gewohnt, einschließlich SyncDisabled, SyncTypesListDisabled, BrowserSignin, AutofillAddressEnabled, AutofillCreditCardEnabled und PasswordManagerEnabled.

     
    • Chrome 140 für 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.

       

   

  • Geteilte Tabgruppen back to top

    Nutzer können jetzt mit der Funktion „Geteilte Tabgruppen“ gemeinsam an Tabs arbeiten. Mit dieser Funktion können Nutzer auf ihrem Computer oder Mobilgerät eine Reihe von Tabs erstellen und verwenden. Ihre Mitbearbeiter können dieselben Tabs auf ihren Geräten aufrufen. Wenn eine Person einen Tab in der Gruppe ändert, werden die Änderungen in den Browsern aller Nutzer in der Gruppe übernommen. Administratoren können diese Funktion in Chrome 140 über die Unternehmensrichtlinie TabGroupSharingSettings steuern.

     
    • Chrome 138 für Android, ChromeOS, Linux, macOS und Windows: Einführung der Möglichkeit, einer geteilten Tabgruppe beizutreten und sie zu verwenden. Nutzer der stabilen Chrome-Version können keine freigegebene Tabgruppe erstellen, da der Einstiegspunkt nicht verfügbar ist. Dieser Teil der Funktion ist in dieser Phase der Einführung nur in der Beta-, Entwickler- und Canary-Version verfügbar. 
    • Chrome 139 für iOS:  Die Unterstützung für iOS wird bereits in Chrome 139 eingeführt.
    • Chrome 140 für Android, iOS, ChromeOS, Linux, macOS und Windows: Die Unternehmensrichtlinie TabGroupSharingSettings ist für den Unternehmensinhaber in der Admin-Konsole verfügbar. Alle Nutzer der stabilen Version können einer geteilten Tabgruppe beitreten und sie verwenden. Die Möglichkeit, eine gemeinsame Tabgruppe zu erstellen, bleibt jedoch Nutzern in Beta-, Dev- und Canary-Versionen vorbehalten. Das bedeutet, dass nur Nutzer in diesen Channels eine Gruppe starten können. Ihre Freunde und Kollegen in der stabilen Version können dann beitreten.
     

   

  • Ändern der WarnungKein HTTPS back to top

    In Chrome 140 wird die Warnung, die angezeigt wird, wenn ein Nutzer die Einstellung Immer verschlüsselte 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 141 für Android: Neues Warnungsdesign für Android 

   

  • Kein Senden mehr von Header Purpose: prefetch über Prefetching und Pre-Rendering back to top

    Da für Prefetching und Prerendering jetzt der Header Sec-Purpose verwendet wird, wird mit dieser Änderung der alte Header Purpose: prefetch entfernt, der derzeit noch übergeben wird. Dieses Update ist hinter einem Feature-Flag oder Kill-Switch verborgen, um Kompatibilitätsprobleme zu vermeiden.

    Der Umfang umfasst Prefetch-Regeln für Spekulationen, Prerender-Regeln für Spekulationen, <link rel=prefetch> und das nicht standardmäßige <link rel=prerender> von Chromium.

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

   

  • Sonderregeln für die Schriftgröße für H1-Elemente in bestimmten Elementen werden eingestellt back to top

    Die HTML-Spezifikation enthält eine Liste mit Sonderregeln für <h1>-Tags , die in <article>-, <aside>-, <nav>- oder <section>-Tags verschachtelt sind. In Chrome 140 werden diese speziellen Regeln eingestellt, da sie zu Problemen bei der Barrierefreiheit führen können. Beispielsweise kann die Schriftgröße für verschachtelte <h1>-Tags visuell reduziert werden, sodass sie wie <h2>-Tags aussehen. Im Barrierefreiheitsbaum wird diese Herabstufung jedoch nicht berücksichtigt.

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

   

  • SharedWorker übernimmt Controller für Blob-URL back to top

    Gemäß Worker client case (github) sollten Worker Controller für die Blob-URL übernehmen. Basierend auf dem vorhandenen Code kann der Controller aber nur von DedicatedWorker übernommen werden. Shared-Worker übernehmen den Controller nicht. Mit dieser Korrektur wird das Chromium-Verhalten an die Spezifikation angepasst. Diese Funktion kann über die Unternehmensrichtlinie SharedWorkerBlobURLFixEnabled gesteuert werden.

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

   

Änderungen bei Chrome Enterprise Core

   

  • Neue Filter auf der Übersichtsseite zu Chrome Enterprise back to top

    Die Chrome-Übersichtsseite enthält jetzt neue Filter, mit denen Administratoren Daten nach Datum der letzten Aktivität und Organisationseinheit eingrenzen können. Diese Übersichtsseite wurde ursprünglich in Chrome 137 als Teil des Chrome Enterprise-Bereichs in der Google Admin-Konsole eingeführt.

    • Chrome 140 für Android, iOS, Linux, macOS und Windows : Bereits ab Chrome 140 sind auf der Übersichtsseite neue Filter verfügbar.

   

  • Abgedeckte Chrome Enterprise-Daten regionalisieren back to top

    Mit Chrome 139 haben Administratoren die Möglichkeit erhalten, einen bestimmten geografischen Standort für die Speicherung der abgedeckten Chrome Enterprise-Daten von Nutzern festzulegen. Als Speicherorte können Sie die USA, die Europäische Union (in der Admin-Konsole als Europa angezeigt) oder Keine Präferenz auswählen. Die vollständige Migration wird voraussichtlich bis zum Ende von Chrome 140 abgeschlossen sein. Diese Einstellung kann in der Admin-Konsole unter Daten > Compliance > Speicherorte für Daten > Region > Ruhende Daten konfiguriert werden. Weitere Informationen zu den abgedeckten Datentypen finden Sie in den dienstspezifischen Nutzungsbedingungen für Chrome Enterprise.

     
    • Chrome 139 für Android, iOS, ChromeOS, Linux, macOS und Windows: Der Roll-out beginnt. Administratoren können möglicherweise eine Region festlegen. Die Daten sind jedoch erst nach der Veröffentlichung von Chrome 140 vollständig regionalisiert.
    • Chrome 140 für Android, iOS, ChromeOS, Linux, macOS und Windows: Die erste Migration wird vollständig regionalisiert.

Änderungen bei Chrome Enterprise Premium

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

   

  • Datenschutzregeln für Kopieren und Einfügen back to top  

    Damit Organisationen Daten-Exfiltration auf Mobilgeräten besser verhindern können, werden die vorhandenen Steuerelemente für Zwischenablagedaten in Chrome für Desktopcomputer erweitert. Administratoren können jetzt mit der Richtlinie DataControlsRules Regeln festlegen, die Nutzer blockieren oder warnen, wenn sie versuchen, Inhalte zu kopieren oder einzufügen, die gegen Organisationsrichtlinien verstoßen. Mit dieser Funktion können Administratoren Datengrenzen definieren und verhindern, dass vertrauliche Informationen aus einem Arbeitskontext in private Apps oder Websites auf den Mobilgeräten der Mitarbeiter eingefügt werden. Damit wird eine erhebliche Sicherheitslücke geschlossen und eine häufig angefragte Funktion für Unternehmenskunden angeboten, die das Fehlen von Einstellungen für mobile Daten als Problem angaben.

    Um diese Funktion zu verwenden, können Administratoren Einschränkungen für die Zwischenablage in der Richtlinie DataControlsRules konfigurieren. So wird eine einheitliche Verwaltung auf Desktop- und Mobilgeräten ermöglicht, um den allgemeinen Sicherheitsstatus des Unternehmens zu stärken. In diesem Hilfeartikel finden Sie weitere Informationen dazu, wie Administratoren Connectors für die Chrome Enterprise-Berichterstellung konfigurieren und verwalten können, um Browser-Sicherheits- und Datenschutzereignisse zur Analyse an Drittanbieterdienste weiterzuleiten.

     
    • Chrome 140 für Android: Datenschutzregeln zum Kopieren und Einfügen auf Android-Geräten verfügbar 

   

  • DLP-Unterstützung für iFrames back to top  

    Um die Sicherheit zu erhöhen und Daten-Exfiltration zu verhindern, werden in Chrome 140 die Funktionen zum Schutz vor Datenverlust (Data Loss Prevention, DLP) auf Inhalte in iFrames ausgeweitet. Wenn ein Nutzer eine DLP-auslösende Aktion (z. B. das Hochladen einer Datei) auf einer Website ausführt, die in einem iFrame geladen wird, sendet Chrome mit dieser Änderung die gesamte URL-Hierarchie vom Quell-iFrame bis zur Seite der obersten Ebene zur Auswertung anhand aller anwendbaren DLP-Regeln.

    Für diese Funktion sind keine neuen Unternehmensrichtlinien erforderlich. Sie funktioniert mit vorhandenen DLP-Regeln, die über die Connector-Richtlinien konfiguriert werden. Administratoren sollten sich darüber im Klaren sein, dass ihre bestehenden Regeln jetzt auch für iFrame-Kontexte gelten. Das kann dazu führen, dass Nutzeraktionen blockiert werden, die zuvor zulässig waren.

     
    • Chrome 139 für Linux, macOS und Windows: Erste Einführung der Unterstützung für iFrames bei der DLP. In dieser Phase wird die Erzwingung für Dateiupload-Ereignisse hinzugefügt, die aus einem iFrame-Kontext stammen. Sie funktioniert mit vorhandenen DLP-Regeln, die über die Richtlinie OnFileAttachedEnterpriseConnector konfiguriert wurden.
    • Chrome 140 für Linux, macOS und Windows: In dieser erweiterten Phase werden zwei Funktionen eingeführt. Die DLP-iFrame-Unterstützung wird erweitert und umfasst nun die Erzwingung für sowohl Dateidownload- als auch Druckvorgänge.

↑ 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

    

  • Heuristisches Signal für Suchanfragen-Hijacking zur Erweiterungstelemetrie hinzufügen 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

    

  • 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 eine Standardbenachrichtigung (Wird von <domain name> verwaltet) angezeigt. Die Sichtbarkeit kann mit der Richtlinie NTPFooterManagementNoticeEnabled geändert werden. 
    Chrome Web Store

 

    

  • 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 Chats, in denen 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 ist Gemini in Chrome für Nutzer verfügbar, die in den USA in Chrome angemeldet sind. 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 Hilfe unter Gemini in Chrome.

    • 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 macOS und Windows: Die Funktion wird nach und nach in der stabilen Version für Nutzer eingeführt, die in den USA in Chrome angemeldet sind.

 

    

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

    Diese Funktion kann über die Unternehmensrichtlinie WebRtcPostQuantumKeyAgreementEnabled gesteuert werden, damit Unternehmensnutzer PQC deaktivieren können. Die Richtlinie gilt nur vorübergehend und wird voraussichtlich in Chrome 151 entfernt.

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

    

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

    Mit dieser Funktion wird das Styling von Suchergebnissen auf der Seite für Autoren als Highlight-Pseudoelement verfügbar gemacht, ähnlich wie bei Auswahl und Rechtschreibfehlern. 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 141 für Windows, macOS, Linux und Android 

    

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

    In Chrome 140 wird die Möglichkeit, Anfragen an das lokale Netzwerk des Nutzers zu senden, eingeschränkt. Dies ist nur nach Erteilung einer Berechtigung 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 erteilen möchten, können dies mit den Richtlinien LocalNetworkAccessAllowedForUrls und LocalNetworkAccessBlockedForUrls tun. Mit dem Wert „*“ kann der Zugriff über das lokale Netzwerk für alle URLs zugelassen werden. Das entspricht dem Verhalten vor der Einführung der Einschränkungen.

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

    

  • Ursprungsgebundene Cookies (standardmäßig)  back to top

    In Chrome 141 sind Cookies standardmäßig an ihren Ursprung 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 Host- und Portbindung durch Verwendung des Domain-Attributs aufheben, aber alle Cookies sind an das Schema ihrer Einstellung 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 141 für Windows, macOS, Linux, Android und iOS:  Richtlinie wird verfügbar gemacht
    • Chrome 150 für Windows, macOS, Linux, Android und iOS:  Richtlinie wird entfernt

    

  • Berechtigungsrichtlinie für die Device Attributes API  back to top

    Mit der neuen Berechtigungsrichtlinie kann der Zugriff auf die Device Attributes API eingeschränkt werden. Diese API ist nur für Kiosk-Web-Apps und isolierte Web-Apps mit Richtlinieninstallation verfügbar, und zwar nur auf verwalteten ChromeOS-Geräten.

    Außerdem wird die Funktion durch Inhaltseinstellungen gesteuert. Es werden zwei neue Richtlinien eingeführt: DeviceAttributesBlockedForOrigins und DefaultDeviceAttributesSetting. Sie ergänzen die bereits eingeführte Richtlinie DeviceAttributesAllowedForOrigins. Die Funktion ist für die oben beschriebenen unterstützten Szenarien standardmäßig aktiviert.

     
    • Chrome 141 für Windows, macOS und Linux

    

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

    Wir planen, die Semantik der Storage Access API anzupassen, damit sie der Richtlinie zum gleichen Ursprung entspricht und die Sicherheit erhöht wird. 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 

    

  • Die window.name-Eigenschaft wird bei websiteübergreifenden Seitenaufrufen nicht mehr beibehalten 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, iOS

    

  • 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 Computer 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 142 gilt Folgendes: Wenn mit der Richtlinie SyncTypesListDisabled entweder Tabs oder gespeicherte Tabgruppen deaktiviert werden, gelten beide Datentypen als 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 142 für Windows, macOS und Linux 

    

  • Nicht vertrauenswürdiges Klartext-HTTP-Pre-Rendering zulassen back to top

    Mit dieser Einführung wird die Möglichkeit geschaffen, nicht vertrauenswürdiges Klartext-HTTP-Prerendering zu unterbinden.

     
    • Chrome 142 für Windows, macOS, Linux und 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 verfolgen.

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

    

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

    Bereits in Chrome 139 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
     

    

  • 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
     

    

  • 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 2FA-Erzwingung für Administratoren.

     
    • 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 ist erforderlich
     

    

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

    Gemäß der URL Standard-Spezifikation 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 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 Safe Browsing API v4 zu 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

    Ab Chrome 124 aktiviert Chrome auf allen Desktopplattformen standardmäßig den neuen Post-Quanten-Mechanismus zur sicheren TLS-Schlüsselkapselung X25519Kyber768, 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 im Explainer beschriebenen Methoden an Endnutzer verteilt. 

    In dieser 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

    

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

    Der personalisierte Chrome Web Store unterstützt verwaltete Browser, die für Chrome Enterprise Core (Cloud-Maschineneinstellungen) 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 in Chrome 141 allgemein verfügbar sein.
     

    

  • Übersichtsseite zu Chrome Enterprise back to top

    In Chrome 137 wurde im Bereich „Chrome-Browser“ der Google Admin-Konsole eine neue Seite Übersicht eingeführt. Auf der Übersichtsseite können IT-Administratoren schnell wichtige Informationen zu ihrer Bereitstellung finden:

    – Aktive und inaktive Profile und registrierte Browser

    – Veraltete Browser mit ausstehenden Updates identifizieren

    – Erweiterungen mit hohem Risiko (gemäß Spin.AI) identifizieren und eine Vorschau der am häufigsten angeforderten Erweiterungen aufrufen

    – Sicherheitsstatistiken (z. B. Uploads oder Downloads sensibler Dateien)

     

    Über die Übersichtsseite können Administratoren auch schnell auf wichtige Aktionen zugreifen, z. B. zum Verwalten von Erweiterungen, zum Aufrufen der Browser- oder Profilliste und zum Festlegen von Aktualisierungsrichtlinien.

     
    • Chrome 137 für Android, iOS, Linux, macOS und Windows: Öffentlich für IT-Administratoren verfügbar
    • Chrome 141 für Android, iOS, Linux, macOS und Windows: Neue Filterung auf der Übersichtsseite für Organisationseinheit und Aktivitätsdatum
     

    

  • 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 Inaktivitätszeitraum des Profils beträgt maximal 730 Tage, der Mindestwert 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 September abgeschlossen sein. Nach dem ersten Löschvorgang werden inaktive Profile weiterhin gelöscht, sobald sie den Zeitraum der Inaktivität erreicht haben.

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 Google 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), Chrome-Browser-Trigger (z. B. Datei-Upload, besuchte URL) oder 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.

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

    • Chrome 140 für Linux, macOS und Windows: Einführung der Funktion
     

   

  • 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 mit der neuen 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üllungsdeckkraft des Texts von 0 (durchsichtig) bis 100 (undurchsichtig) fest. 
    • „outline_opacity“: Legt die Konturdeckkraft des Texts von 0 (durchsichtig) bis 100 (undurchsichtig) fest. 

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

    • Chrome 141 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  

 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 139: 30. Juli 2025
Chrome 138: 18. Juni 2025
Chrome 137: 20. Mai 2025
Chrome 136: 23. April 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
Hauptmenü
12450334418756534196
true
Suchen in der Hilfe
false
true
true
true
true
true
410864
false
false
false
false