Versionshinweise für Chrome Enterprise und Chrome Education

Letzte Aktualisierung: 23. April 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 Chrome- oder ChromeOS-Updates zu sehen.

 

Übersicht über Chrome-Version 136

 
Änderungen am Chrome-Browser Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Aktualisierungen bei der Präsentation von Google Lens-Ergebnissen   ✓  
Prüfung auf schädliche APK-Downloads (nur Telemetrie) ✓    
Proaktive Benachrichtigungen für Chrome-Tipps unter iOS   ✓  
Benutzerdefiniertes Datenverzeichnis für das Remote-Debugging erforderlich  ✓    
Partitionieren des Verlaufs der :visited-Links ✓    
Den attr()-Typ string in raw-string umbenennen ✓    
ProgressEvent so aktualisieren, dass für loaded und total der Typ „double“ verwendet wird ✓    
Neue Richtlinien im Chrome-Browser     ✓
Entfernte Richtlinien im Chrome-Browser     ✓
Änderungen bei Chrome Enterprise Core Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
WebAuthn-Unterstützung für Remote-Desktop-Clients auf verwalteten Geräten ✓   ✓
Änderungen bei Chrome Enterprise Premium Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Neuer Berichtsconnector: CrowdStrike Falcon-SIEM der nächsten Generation ✓   ✓
URL-Filterfunktionen unter Android ✓   ✓
Anstehende Änderungen für den Chrome-Browser Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Entfernung von Unternehmensrichtlinien für den privaten Netzwerkzugriff ✓    
Entfernen des Befehlszeilenschalters --load-extension  ✓    
SwiftShader-Fallback entfernen ✓    
Fehlertyp ausrichten, der beim Erstellen von WebAuthn-Anmeldedaten für Zahlungen auftritt: SecurityError => NotAllowedError ✓    
Blob-URL-Partitionierung: Abrufen/Navigation ✓    
Web Serial over Bluetooth unter Android ✓    
Happy Eyeballs V3 ✓    
Strenge Richtlinie zum gleichen Ursprung für die Storage Access API ✓    
Web-App-Manifest: update_token und Aktualisierungsfähigkeit ✓    
Migration von Erweiterungen zu Manifest V3 vor Juni 2025 ✓ ✓ ✓
Chrome unterstützt macOS 11 nicht mehr     ✓
Isolierte Web-Apps ✓   ✓
Leerzeichen in nicht file://-URL-Hosts nicht zulassen ✓    
Migration von der Safe Browsing API v4 zur v5 ✓    
Anbieter des Bedienungshilfen-Frameworks zur Automatisierung der Benutzeroberfläche unter Windows   ✓  
Bevorstehende Änderungen an Chrome Enterprise Core Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Protokolle und Berichte für IP-Adressen ✓    
Löschen inaktiver Profile in Chrome Enterprise Core ✓   ✓
Unterstützung mehrerer Identitäten unter iOS   ✓  
Google Agentspace-Empfehlungen in der Chrome-Omnibox   ✓ ✓
Bevorstehende Änderungen an Chrome Enterprise Premium Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
URL-Filterfunktionen unter iOS ✓   ✓

 

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 am Chrome-Browser

 

   

  • Registrierung von Drittanbieterprofilen wird zum OIDC-Autorisierungscode-Vorgang migriert back to top

    In Chrome 135 wird die Landingpage für die Profilregistrierung von der Marketing-Website auf eine dynamische Website migriert. Bei diesem Update wird auch der implizite OpenID Connect-Flow (OIDC) zu einem Authentifizierungscode-Flow migriert. Dadurch sollen sowohl die Sicherheit als auch die Nutzerfreundlichkeit für von Drittanbietern verwaltete Profile verbessert werden.

    • Chrome 135 für Windows

   

  • Automatisches Löschen von Downloads für Chrome auf iOS-Geräten back to top

    Nutzer des Chrome-Browsers auf iOS können jetzt festlegen, dass ihre Browserdownloads automatisch nach einem Zeitplan gelöscht werden.

    Diese Funktion wird wahrscheinlich sowohl die Geräteleistung im Zusammenhang mit der Speicherkapazität als auch den Datenschutz verbessern, da das Löschen von Dateien, die Nutzer sonst möglicherweise selbst vergessen würden, automatisiert wird.

    • Chrome 135 für iOS
      Erster Test bei 1% in 135 nur für Chrome für iOS. Für andere Plattformen ist keine Einführung geplant.
      " "

   

  • Verbesserte Erkennung von Passwortformularen mit ML back to top

    In Chrome 135 wird ein neues clientseitiges Modell für maschinelles Lernen (ML) eingeführt, mit dem Passwortformulare im Web besser geparst werden können, um die Erkennungs- und Ausfüllgenauigkeit zu verbessern. Diese Funktion kann mit der Richtlinie PasswordManagerEnabled gesteuert werden.

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

   

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

    Nutzer im Web werden täglich mit einer großen Anzahl und Vielfalt von Betrug konfrontiert. Um diese Betrugsversuche zu bekämpfen, werden in Chrome 135 On-Device-LLMs (Large Language Models) verwendet, um betrügerische Websites zu identifizieren und Nutzern einen erweiterten Schutz zu bieten. Chrome sendet den Seiteninhalt an einen lokalen LLM, um Sicherheitssignale für diese Seite abzuleiten. Chrome sendet diese Signale dann serverseitig an Safe Browsing, um eine endgültige Entscheidung zu treffen. Wenn diese Option aktiviert ist, benötigt Chrome möglicherweise mehr Bandbreite, um das LLM herunterzuladen.

    • Chrome 134 für Linux, macOS und Windows
      Der Markenname und die Zusammenfassung der Absicht der Seite, für die die Tastatursperre-API angefordert wurde, werden erfasst, um betrügerische Websites zu identifizieren.
    • Chrome 135 für Linux, macOS und Windows
      Warnungen werden dem Nutzer basierend auf dem Serverurteil angezeigt, das die Zusammenfassung der Marke und Absicht der Seite verwendet, für die die Tastatursperre-API angefordert wurde.
     

   

  • Ende der Unterstützung von Mutationsereignissen back to top

    Synchrone Mutationsereignisse, u. a. DOMSubtreeModified, DOMNodeInserted, DOMNodeRemoved, DOMNodeRemovedFromDocument, DOMNodeInsertedIntoDocument und DOMCharacterDataModified, beeinträchtigen die Seitenleistung und erhöhen außerdem die Komplexität beim Hinzufügen neuer Funktionen im Web erheblich. Diese APIs wurden 2011 aus der Spezifikation entfernt und 2012 durch die Mutation Observer API ersetzt, die ein viel besseres Verhalten hat. Die veralteten Mutationsereignisse müssen entfernt oder zu Mutation Observer migriert werden. 

    Seit Chrome 124 ist die temporäre Unternehmensrichtlinie MutationEventsEnabled verfügbar, mit der eingestellte oder entfernte Mutationsereignisse wieder aktiviert werden können. Weitere Informationen finden Sie in diesem Blogpost Chrome für Entwickler. Falls Probleme auftreten, können Sie einen Chromium-Fehler melden.

    Die Unterstützung für Mutationsereignisse ist seit Chrome 127 (ca. 30. Juli 2024) standardmäßig deaktiviert. Code sollte vor diesem Datum migriert worden sein, um Websitefehler zu vermeiden. Wenn Sie mehr Zeit benötigen, haben Sie verschiedene Möglichkeiten:

    • Mit dem Test zur Einstellung von Mutationsereignissen kann die Funktion auf einer bestimmten Website für einen begrenzten Zeitraum wieder aktiviert werden. Diese Funktion kann bis zum 25. März 2025 über Chrome 135 verwendet werden.
    • Die Unternehmensrichtlinie MutationEventsEnabled kann ebenfalls über Chrome 135 zu demselben Zweck verwendet werden.
    • Chrome 135 für Android, Linux, macOS und Windows: Die Unternehmensrichtlinie MutationEventsEnabled wird eingestellt.

   

   

  • Verbesserungen bei Erweiterungen in der Desktopversion von Chrome back to top

    In Chrome 135 für Computer können einige Nutzer, die sich bei der Installation einer neuen Erweiterung in Chrome anmelden, Erweiterungen jetzt in ihrem Google-Konto verwenden und speichern. 

    Relevante Unternehmensrichtlinien für Erweiterungen sowie BrowserSignin, SyncDisabled oder SyncTypesListDisabled funktionieren weiterhin wie gewohnt. Administratoren können damit konfigurieren, ob Nutzer Elemente in ihrem Google-Konto verwenden und speichern dürfen.

    Weitere Informationen zur Verwendung von Erweiterungen auf einem beliebigen Computer finden Sie in der Chrome Web Store-Hilfe unter Erweiterungen installieren und verwalten.

    Hinweis: Diese Änderung ist eine Folge der Einführung des neuen Identitätsmodells in Chrome für Computer. Weitere Informationen finden Sie unter Anmelden und in Chrome synchronisieren.

    • Chrome 135 für Linux, MacOS und Windows

   

  • Generischer Connector für vertrauenswürdige Geräte back to top

    Mithilfe von Integrationen, die über den Device Trust Connector erstellt wurden, können Kunden detaillierte Zugriffssteuerungen für die Authentifizierung in Unternehmensressourcen wie SaaS-Apps oder das Intranet des Unternehmens implementieren. Diese Steuerungen basieren auf den Eigenschaften des Geräts und der Browserinstanz des Endnutzers, die von Chrome gesendet werden. Weitere Informationen finden Sie im Hilfeartikel Trust-Connectors für Chrome Enterprise-Geräte verwalten. 

    • Chrome 135 für Windows

   

  • Unternehmensrichtlinien für den Zugriff auf private Netzwerke entfernen back to top

    Der private Netzwerkzugriff (Private Network Access, PNA 1.0) ist eine nicht bereitgestellte Sicherheitsfunktion, die den Websitezugriff auf lokale Netzwerke beschränken soll. Aufgrund von Problemen mit der Bereitstellung konnte PNA 1.0 nie standardmäßig bereitgestellt werden, da es mit zu vielen vorhandenen Geräten nicht kompatibel war.

    PNA 1.0 erforderte Änderungen an Geräten in lokalen Netzwerken. Stattdessen wird in Chrome ein aktualisierter Vorschlag implementiert: Private Network Access 2.0 (PNA 2.0). Bei PNA 2.0 sind nur Änderungen an Websites erforderlich, die auf das lokale Netzwerk zugreifen müssen, nicht an Geräten im lokalen Netzwerk. Websites lassen sich viel einfacher aktualisieren als Geräte. Daher sollte dieser Ansatz viel einfacher zu implementieren sein. 

    Die einzige Möglichkeit, PNA 1.0 durchzusetzen, ist eine Unternehmensrichtlinie. Um eine Verschlechterung der Sicherheit für Enterprise-Kunden zu vermeiden, die PNA 1.0 aktivieren, bevor PNA 2.0 eingeführt wird, behalten wir die Richtlinie PrivateNetworkAccessRestrictionsEnabled bei. Dadurch sendet Chrome spezielle Preflight-Nachrichten, bis sie mit PNA 2.0 inkompatibel wird.

    In Chrome 135 werden die Richtlinien InsecurePrivateNetworkRequestsAllowedForUrls und InsecurePrivateNetworkRequestsAllowed entfernt, wodurch die Einschränkungen für PNA 1.0 gelockert werden. Diese Richtlinien haben derzeit keine Auswirkungen, da PNA 1.0 nicht ausgeliefert wird. Sie haben auch keine Bedeutung mehr, sobald PNA 1.0 entfernt wurde.

    PNA 2.0 wird in dieser Erläuterung auf GitHub beschrieben.

   

   

  • Verbesserungen bei Einstellungen, Website-Verknüpfungen und Designs in der Desktopversion von Chrome back to top

    In Chrome 135 für Desktop-Computer werden für Nutzer, die sich neu in Chrome anmelden oder die Synchronisierung aktiviert haben, die mit ihrem Google-Konto synchronisierten Einstellungen, Website-Verknüpfungen und Themen jetzt getrennt von den lokalen Einstellungen gespeichert, also von den Einstellungen, die gelten, wenn sie abgemeldet sind oder die Synchronisierung deaktiviert ist.

    Dadurch wird die Datenweitergabe deutlich reduziert: Lokale Einstellungen werden nicht mehr automatisch hochgeladen, wenn sich Nutzer anmelden oder die Synchronisierung aktivieren. Außerdem bleiben keine Einstellungen des Kontos auf dem Gerät, wenn die Synchronisierung deaktiviert wird.

    Die bestehenden Unternehmensrichtlinien SyncDisabled und SyncTypesListDisabled gelten weiterhin. Administratoren können die Synchronisierungsfunktion also bei Bedarf einschränken oder deaktivieren. Weitere Informationen finden Sie unter Festlegen, wer Browsereinstellungen synchronisieren darf.

    Hinweis: Diese Änderung ist eine Folge der Einführung des neuen Identitätsmodells in Chrome für Computer. 

    • Chrome 135 für Linux, MacOS und Windows

   

  • Einstellung des bisherigen Passwortmanagers in Chrome auf Android-Geräten back to top

    Nutzer mit alten Versionen von Google Play-Diensten können den Passwortmanager in Chrome nicht mehr verwenden. Dies ist ein Schritt in Richtung Einstellung des bisherigen Passwortmanagers in Chrome auf Android-Geräten. Diese Nutzer können eine CSV-Datei mit ihren Passwörtern aus den Chrome-Einstellungen herunterladen und in ihren bevorzugten Passwortmanager importieren. Der neue Google Passwortmanager ist auf Geräten mit einer aktuellen Version der Google Play-Dienste verfügbar.

    • Chrome 135 für Android
     

   

  • Drittanbieter-Cookies sind im Inkognitomodus immer gesperrt back to top

    Ab Chrome 135 werden Drittanbieter-Cookies im Inkognitomodus blockiert und können nicht mehr global reaktiviert werden. Die Einstellungen auf Websiteebene zum Zulassen von Drittanbieter-Cookies werden nicht geändert. 

    Nach der Einführung gilt die Richtlinie BlockThirdPartyCookies nur für den normalen Modus, wenn sie auf „false“ gesetzt ist. Für den Inkognitomodus gilt sie nicht. Wenn die Richtlinie auf „true“ gesetzt oder nicht konfiguriert ist, ändert sich nichts. Auch die Richtlinie CookieAllowedForUrls bleibt unverändert. Sie gilt sowohl im regulären als auch im Inkognitomodus, da sie auf Websiteebene und nicht global angewendet wird.

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

   

  • Service Worker-Client erstellen und Service Worker-Controller für srcdoc-iFrame übernehmen back to top

    Srcdoc-Kontextdokumente waren bisher keine Service Worker-Clients und wurden nicht vom Service Worker der übergeordneten Seite abgedeckt. Dies führte zu einigen Abweichungen. Beispielsweise werden in den Berichten zu den Ressourcenzeitangaben die URLs aufgeführt, die diese Dokumente laden, aber nicht vom Service Worker abgefangen werden. 

    Um diese Abweichungen zu beheben, werden in Chrome 135 Service Worker-Clients für srcdoc-iFrames erstellt, die den Service Worker-Controller der übergeordneten Seite übernehmen.

    • Chrome 135 für Windows, MacOS, Linux und Android

   

  • HSTS-Tracking-Prävention back to top

    Mit HTTP Strict Transport Security (HSTS) können Websites festlegen, dass sie nur über sichere Verbindungen zugänglich sind. 

    In Chrome 135 wird durch die HSTS-Tracking-Prävention das Nutzer-Tracking durch Drittanbieter mithilfe des HSTS-Caches eingeschränkt. Es erlaubt nur HSTS-Upgrades für Navigationen auf oberster Ebene und blockiert HSTS-Upgrades für Anfragen zu untergeordneten Ressourcen. So wird verhindert, dass Drittanbieter-Websites den HSTS-Cache verwenden, um Nutzer im Web zu verfolgen. Weitere Informationen finden Sie in der HSTS-Erläuterung zur Tracking-Verhinderung auf GitHub.

    • Chrome 135 für Windows, MacOS, Linux und Android

   

  • Einstellung der veralteten Methode „navigator.xr.supportsSession“ back to top

    In Chrome 135 wird die Methode navigator.xr.supportsSession entfernt. Sie wurde in der WebXR-Spezifikation im September 2019 durch die Methode navigator.xr.isSessionSupported ersetzt, nachdem wir Feedback zur API-Form vom TAG erhalten hatten. Seitdem wird sie in Chromium als eingestellt gekennzeichnet. In der Konsole wird eine Warnung angezeigt, die Entwickler zur aktualisierten API weiterleitet.

    Die Nutzung des Aufrufs ist sehr gering, wie die Nutzungsmesswerte für Chrome-Status zeigen. Außerdem wurde bestätigt, dass alle wichtigen Frameworks, die zum Erstellen von WebXR-Inhalten verwendet werden, auf den neueren Aufruf aktualisiert wurden.

    • Chrome 135 für Windows, MacOS, Linux und Android

   

  • Entfernen der Befehlszeilenoption „–load-extension“ in Google Chrome back to top

    Ab Chrome 137 wird die Möglichkeit, Erweiterungen über das Befehlszeilen-Flag --load-extension zu laden, in offiziellen Chrome-Builds eingestellt. Damit möchten wir die Sicherheit und Stabilität des Chrome-Browsers für unsere Nutzer verbessern. Mit dieser Änderung sollen die Risiken, die mit schädlichen und unerwünschten Erweiterungen verbunden sind, minimiert werden. 

    Wenn der Entwicklermodus aktiviert ist, können Sie entpackte Erweiterungen über die Schaltfläche Entpackt laden auf der Seite zur Erweiterungsverwaltung (chrome://extensions/) laden. Entwickler können den Schalter load-extension weiterhin in nicht gekennzeichneten Builds wie Chromium und Chrome For Testing verwenden. 

    • Chrome 135 für Windows, MacOS, Linux und ChromeOS

   

   

   

Änderungen bei Chrome Enterprise Core

   

  • Unterstützung für erweiterbare SSO-Funktionen von Apple für Chrome unter macOS back to top

    Chrome 135 für macOS ermöglicht eine nahtlose Authentifizierung für Identitätsanbieter, die über eine vom Betriebssystem konfigurierte Enterprise SSO-Erweiterung (Single Sign-On, Einmalanmeldung) aktiviert sind. In dieser ersten Version können sich Endnutzer in verwalteten Chrome-Browsern in allen mit Microsoft Entra authentifizierten Ressourcen anmelden, ohne Anmeldedaten eingeben zu müssen. Das erweiterbare SSO muss in Ihrer Umgebung vorkonfiguriert und mit der entsprechenden Lösung für die Geräteverwaltung in Unternehmen bereitgestellt werden. Weitere Informationen finden Sie unter Unterstützung für die erweiterbare Einmalanmeldung von Apple in Chrome verwenden.

     
    • Ab Chrome 135 für macOS
     

   

  • Neue Inhalte auf der Chrome Web Store-Seite „Entdecken“ für verwaltete Nutzer back to top

    Im Chrome Web Store werden auf der Discover-Seite für verwaltete Nutzer jetzt neue ausgewählte Sammlungen zu Produktivität, Projektmanagement und Zusammenarbeit angezeigt. Ziel ist es, Endnutzern zu helfen, nützliche und relevantere arbeitsbezogene Erweiterungen schneller zu finden.

    Als Administrator können Sie die Anzeige des Chrome Web Store für Ihre verwalteten Nutzer über die Einstellungen für den Chrome Web Store steuern (zuvor in Chrome 132 angekündigt).

     

    • Chrome 135: schrittweise Einführung ab dem 1. April 2025

 

Änderungen bei Chrome Enterprise Premium

 

Es gibt keine Updates für Chrome Enterprise Premium in Chrome 135.

 

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

 

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

 

    

  • Anforderung an das benutzerdefinierte Datenverzeichnis für den Remote-Debugging-Port back to top

    Das Remote-Debugging über einen TCP-Port oder eine Pipe ist in Google Chrome mit dem Standarddatenverzeichnis unter Windows, Linux und macOS nicht mehr möglich.

    Wenn Sie die Optionen --remote-debugging-pipe oder --remote-debugging-port verwenden, müssen Sie ein benutzerdefiniertes Datenverzeichnis angeben, um Google Chrome per Fernzugriff mit der Option --user-data-dir zu debuggen.

    Diese Änderung ist erforderlich, da diese Schalter für Remote-Debugging von Infodieben und Malware missbraucht werden, um Daten aus Google Chrome zu extrahieren. Für ein benutzerdefiniertes Nutzerdatenverzeichnis wird ein anderer Verschlüsselungsschlüssel verwendet. So ist es Malware nicht mehr möglich, verschlüsselte Daten wie Cookies zu stehlen.

    Diese Änderung hat keine Auswirkungen auf Chrome for Testing und Chromium.

     
    • Chrome 136 für Linux, MacOS und Windows

    

  • Blob-URL-Partitionierung: Abrufen/Navigation back to top

    Als Fortsetzung der Speicherpartitionierung implementiert Chromium die Partitionierung des Blob-URL-Zugriffs nach Speicherschlüssel (Website der obersten Ebene, Frame-Ursprung und das boolesche has-cross-site-ancestor-Attribut), mit Ausnahme von Navigationen der obersten Ebene, die nur nach Frame-Ursprung partitioniert bleiben. Dieses Verhalten ähnelt dem, was derzeit sowohl in Firefox als auch in Safari implementiert ist, und gleicht die Verwendung von Blob-URLs mit dem Partitionierungsschema ab, das von anderen Speicher-APIs im Rahmen der Speicherpartitionierung verwendet wird. Außerdem erzwingt Chromium „noopener“ für vom Renderer initiierte Navigationen der obersten Ebene zu Blob-URLs, bei denen die entsprechende Website websiteübergreifend mit der Website der obersten Ebene ist, die die Navigation ausführt. Damit entspricht Chromium dem Verhalten in Safari. Die entsprechenden Spezifikationen wurden entsprechend aktualisiert. 

    Diese Änderung kann vorübergehend rückgängig gemacht werden, indem Sie die Richtlinie PartitionedBlobURLUsage festlegen. Die Richtlinie wird eingestellt, wenn die anderen speicherpartitionsbezogenen Unternehmensrichtlinien eingestellt werden.

    • Chrome 136 für Windows, MacOS, Linux und Android

    

  • Getters der Intl Locale Info API werden eingestellt back to top

    Die Intl Locale Info API ist ein ECMAScript-TC39-Vorschlag der 3. Phase, mit dem das Intl.Locale-Objekt durch die Bereitstellung von Informationen zur Sprache und Region erweitert wird. Dazu gehören Wochendaten (erster Tag in der Woche, Wochenendstarttag, Wochenendendtag, Mindesttag in der ersten Woche) und der in der Sprache und Region verwendete Stundenzyklus für die Textrichtung.

    Wir haben unsere Implementierung in Chrome 99 veröffentlicht, aber später wurden einige Änderungen an der Version 3 des Vorschlags vorgenommen und mehrere Getter in Funktionen verschoben. Wir planen, die veralteten Getter zu entfernen und die umbenannten Funktionen neu zu starten.

    • Chrome 136 für Windows, MacOS, Linux und Android

    

  • FedCM-Updates back to top

    Ab Chrome 136 kann die Federated Credential Management API (FedCM) mehrere Identitätsanbieter im selben Dialogfeld anzeigen. So haben Entwickler eine praktische Möglichkeit, Nutzern alle unterstützten Identitätsanbieter zu präsentieren. Wir planen, zuerst den einfachen Fall zu behandeln, bei dem alle Anbieter im selben get()-Aufruf enthalten sind.

    Wir planen, die Unterstützung für das Hinzufügen eines weiteren Kontos im passiven FedCM-Modus einzustellen. Mit dieser Funktion kann in der Auswahl neben anderen Konten von Identitätsanbietern die Schaltfläche Anderes Konto verwenden angezeigt werden. Die Funktion wird derzeit nicht verwendet und UX-Gespräche haben gezeigt, dass die Unterstützung dieser Funktion zu einem komplizierteren Ablauf ohne großen Nutzen führt. Diese Funktion funktioniert weiterhin im aktiven FedCM-Modus.

    • Chrome 136 für Windows, MacOS, Linux und Android

    

  • Partitionieren des Verlaufs der ":visited"-Links back to top

    Um Datenlecks im Browserverlauf von Nutzern zu vermeiden, werden Ankerelemente nur dann als :visited formatiert, wenn sie von dieser Website und diesem Frame-Ursprung aus zuvor angeklickt wurden. Auf Browserseite bedeutet das, dass die Hashtabelle „VisitedLinks“ jetzt durch Dreifachverschlüsselung oder durch Speichern der folgenden Informationen für jeden besuchten Link partitioniert wird: <Link-URL, Website der obersten Ebene, Frame-Ursprung>. Da nur Links mit Stilelementen versehen werden, die auf dieser Website und in diesem Frame bereits angeklickt wurden, sind die vielen Seitenkanalangriffe, die entwickelt wurden, um Informationen zum Stil von :visited-Links zu erhalten, jetzt obsolet, da sie Websites keine neuen Informationen über Nutzer mehr liefern. 

    Eine Ausnahme gilt für Self-Links, bei denen Links zu den eigenen Seiten einer Website als :visited formatiert werden können, auch wenn sie auf genau dieser Website und in genau diesem Frame-Ursprung noch nie angeklickt wurden. Diese Ausnahme gilt nur für Frames der obersten Ebene oder Unterframes, die mit dem Frame der obersten Ebene denselben Ursprung haben. Die oben genannten Datenschutzvorteile werden weiterhin erreicht, da Websites bereits wissen, welche ihrer Unterseiten ein Nutzer besucht hat. Es werden also keine neuen Informationen offengelegt. Diese Ausnahme wurde von der Community angefragt und verbessert auch die Nutzerfreundlichkeit.

    • Chrome 136 für Windows, MacOS, Linux und Android

    

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

    In Chrome 136 wird die Semantik der Storage Access API angepasst, um die Richtlinie zum gleichen Ursprung strikt einzuhalten und die Sicherheit zu erhöhen. Wenn Sie document.requestStorageAccess() in einem Frame verwenden, werden standardmäßig nur Cookies an Anfragen an den Ursprung des iFrames (nicht an die Website) angehängt.

    Hinweis: Die Richtlinie CookiesAllowedForUrls oder die Header für den Speicherzugriff können weiterhin verwendet werden, um websiteübergreifende Cookies zu entsperren.

    • Chrome 136 für Windows, MacOS, Linux und Android

    

  • SwiftShader-Fallback entfernen back to top

    Bereits ab Chrome 137 wird das automatische Fallback auf WebGL, der von SwiftShader unterstützt wird, eingestellt. Das Erstellen eines WebGL-Kontexts schlägt fehl, anstatt auf SwiftShader umzustellen. Wir planen, das SwiftShader-Fallback aus zwei Hauptgründen zu entfernen:

    1. SwiftShader stellt ein hohes Sicherheitsrisiko dar, da JIT-Code im GPU-Prozess von Chromium ausgeführt wird.
    2. Wenn Nutzer von einer leistungsstarken GPU-gestützten WebGL-Implementierung zu einer CPU-gestützten Implementierung wechseln, ist die Nutzererfahrung schlecht. Nutzer haben keine Kontrolle über dieses Verhalten und es ist schwierig, es in Fehlerberichten zu beschreiben.

    SwiftShader ist ein nützliches Tool für Webentwickler, um ihre Websites auf Systemen zu testen, die monitorlos sind oder keine unterstützte GPU haben. Dieser Anwendungsfall wird weiterhin unterstützt, wenn Sie ihn aktivieren, ist aber nicht für das Ausführen nicht vertrauenswürdiger Inhalte vorgesehen.

    Wenn Sie die Sicherheitsgarantien verringern und SwiftShader für WebGL zulassen möchten, führen Sie die ausführbare Chrome-Datei mit dem Befehlszeilenschalter --enable-unsafe-swiftshader aus.

    Während der Einstellungsphase wird in der JavaScript-Konsole eine Warnung angezeigt, wenn ein WebGL-Kontext erstellt und von SwiftShader unterstützt wird. Wenn Sie --enable-unsafe-swiftshader übergeben, wird diese Warnung entfernt.

    Chromium und andere Browser können die Verfügbarkeit von WebGL nicht garantieren. Sie können Fehler beim Erstellen des WebGL-Kontexts testen und bearbeiten und auf andere Web-APIs wie Canvas2D oder eine entsprechende Nachricht an den Nutzer zurückgreifen.

    • Chrome 137 für Windows, MacOS, Linux und Android

    

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

    Gemäß der WhatWG.org-Spezifikation dürfen URL-Hosts kein Leerzeichen enthalten. Derzeit sind im URL-Parsing in Chromium jedoch Leerzeichen im Host zulässig.

    Dies führt dazu, dass Chromium in mehreren Tests der Interop2024-Kategorie „HTTPS-URLs für WebSockets“ und den Fokusbereichen für URLs 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 (siehe Diskussion auf GitHub).

    Diese Funktion ist Teil der laufenden Arbeit, um Chromium an die Spezifikationen anzupassen, indem Leerzeichen nur in nicht-dateibasierten URLs verboten werden.

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

 

    

  • Chrome unterstützt macOS 11 nicht mehr back to top

    Chrome 138 ist die letzte Version, die macOS 11 unterstützt. Chrome 139 und höher unterstützen macOS 11 nicht mehr, da diese Version außerhalb des Supportfensters von Apple liegt. Zur Aufrechterhaltung der Sicherheit ist die Ausführung eines unterstützten Betriebssystems unerlässlich.

    Auf Macs mit macOS 11 funktioniert Chrome weiterhin und zeigt eine Warninfoleiste an, wird aber nicht mehr aktualisiert. Wenn ein Nutzer Chrome aktualisieren möchte, muss er seinen Computer auf eine unterstützte macOS-Version aktualisieren.

    Für neue Installationen von Chrome 139 oder höher ist macOS 12 oder höher erforderlich.

    • Chrome 139 für Windows und macOS

    

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

    Anstatt auf Live-Webservern gehostet und über HTTPS abgerufen zu werden, werden diese Anwendungen in Web-Bundles verpackt, vom Entwickler signiert und über eine oder mehrere der in Einstieg in isolierte Web-Apps beschriebenen Methoden an Endnutzer verteilt.

    In der ersten Version können IWAs nur über eine Richtlinie auf unternehmensverwalteten ChromeOS-Geräten installiert werden.

    • Chrome 140 für Windows

      Durch dieses Roll-out wird die Unterstützung für isolierte Web-Apps in unternehmensverwalteten 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 Version 4 und Version 5.

    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.

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

      Die Einführung erfolgt schrittweise.

    

  • 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. Mit dieser Änderung möchten wir 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 136 unterstützt und in Chrome 137 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 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 136 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 Änderungen an Chrome Enterprise Core

    

  • Verbesserte Berichtsleistung und Skalierbarkeit der Admin-Konsole für große Kunden back to top

    Mit Chrome Enterprise Core werden Änderungen an der Softwareinfrastruktur eingeführt, die die Leistung, Genauigkeit und Skalierbarkeit vieler Seiten und Berichte in der Admin-Konsole verbessern sollen. Zu den betroffenen Seiten und Berichten in der Admin-Konsole gehören unter anderem: 

    • Versionsverlauf
    • Nutzungsbericht zu Apps und Erweiterungen
    • Seite „Erweiterungsdetails“
    • Seite „Statistiken“ für Chrome-Browser
     

    Die Änderungen werden voraussichtlich zwischen April und Juli 2025 schrittweise eingeführt.

    • Ab April 2025 bis Juli 2025

    

  • Neue Remote-Befehle und CSV-Export für die Liste der verwalteten Profile back to top

    Wir planen, der Liste der verwalteten Profile die Aktion CSV-Export sowie die Remote-Befehle Cache leeren und Cookies löschen hinzuzufügen. Sie können ein oder mehrere Profile auswählen und einen Remote-Befehl ausführen.

    • CSV-Export: Ab Chrome 135 für Android, Linux, macOS und Windows
    • Remote-Befehle: Ab Chrome 136 für Linux, macOS und Windows

    

  • Neue Übersichtsseite für Chrome Enterprise Core back to top

    Diese neue Übersichtsseite befindet sich im Abschnitt „Chrome-Browser“ der Admin-Konsole. Sie enthält nützliche Informationen zu Ihrer Bereitstellung, z. B. eine Zusammenfassung der Bereitstellung von Browsern und Profilen sowie eine Zusammenfassung der gemeldeten Chrome-Versionen und installierten Erweiterungen. So können Sie beispielsweise schnell inaktive Browser und Browser mit ausstehendem Update erkennen. Außerdem können Sie sich schnell die Warteschlange mit Erweiterungsanfragen ansehen und konfigurierte Erweiterungen überprüfen.

    • Ab Chrome 135 für Vorabzugriff durch Trusted Tester

    

  • Protokolle und Berichte für IP-Adressen back to top

    Chrome Enterprise verbessert die Funktionen für die Sicherheitsüberwachung und Reaktion auf Vorfälle, indem lokale und Remote-IP-Adressen erfasst und gemeldet und an die Sicherheitsprüfprotokolle (Security Investigation Logs, SIT) gesendet werden. Außerdem können Administratoren in Chrome Enterprise die IP-Adressen optional über den Chrome Enterprise-Connector für die Berichterstellung an interne und externe SIEM-Anbieter (Security Information and Event Management) senden.

    Diese Funktion ist für Chrome Enterprise Core-Kunden verfügbar. 

    • Chrome 136 für Windows, macOS und Linux

    

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

    Im April 2025 (Chrome 136) wird der Zeitraum der Inaktivität für die Richtlinie zum Löschen von Profilen eingeführt. Ab Juni 2025 (Chrome 138) werden durch die Richtlinie automatisch verwaltete Profile in der Admin-Konsole gelöscht, die über den festgelegten Inaktivitätszeitraum hinaus inaktiv waren. Beim Veröffentlichen der Richtlinie hat der Inaktivitätszeitraum einen Standardwert von 90 Tagen. Das bedeutet, dass standardmäßig alle verwalteten Profile, die länger als 90 Tage inaktiv waren, aus Ihrem Konto gelöscht werden. Administratoren können den Wert für den inaktiven Zeitraum mithilfe dieser Richtlinie ändern. Der Inaktivitätszeitraum des Profils beträgt maximal 730 Tage, der Mindestwert 28 Tage.

    Wenn Sie den festgelegten Richtlinienwert senken, 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 wieder aktiviert wird, wird es in der Console wieder angezeigt.

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

      Die Richtlinie wird im April (Chrome 136) eingeführt. Das Löschen beginnt im Juni (Chrome 138) und die erste Welle des Löschens wird bis Ende Juli (Chrome 139) abgeschlossen sein. Nach der ersten Einführung des Löschens werden inaktive Profile weiterhin gelöscht, sobald der Zeitraum der Inaktivität abgelaufen ist.

 

Bevorstehende Änderungen bei Chrome Enterprise Premium

 

   

  • URL-Filterung unter iOS und Android back to top

    Wir erweitern die vorhandenen URL-Filterfunktionen von Desktop- auf mobile Plattformen. So können Organisationen bestimmte URLs oder URL-Kategorien prüfen, blockieren oder Warnungen ausgeben, damit sie nicht in verwalteten Chrome-Browsern oder verwalteten Nutzerprofilen auf Mobilgeräten geladen werden. Dazu gehört auch, dass die Funktion nahtlos mit dem kontextsensitiven Zugriff funktioniert. So können Administratoren Zugriffsrichtlinien basierend auf dem Nutzerkontext (z. B. Nutzerrolle, Standort) und dem Gerätestatus (z. B. verwaltetes Gerät, Einhaltung der Sicherheitsanforderungen) festlegen.

    • Chrome 136 für Android 
    • Chrome 137 für Android und iOS

   

  • Nutzerfreundlichkeit von DLP-Regeln überarbeiten  back to top

    Wir möchten eine nutzerfreundlichere und effizientere Oberfläche für Chrome-spezifische DLP-Regeln schaffen. Dazu wird der Workflow zum Erstellen von Regeln in der Admin-Konsole neu gestaltet, um bestehende und zukünftige Sicherheitsfunktionen für Chrome Enterprise Premium-Kunden besser zu berücksichtigen.

     
    • Chrome 137 für Windows, MacOS, Linux und ChromeOS
      

   

  • Connector für die Berichterstellung für Mobilgeräte back to top

    Wir arbeiten daran, die Funktionen der Desktopversion auf Mobilgeräten verfügbar zu machen, damit Organisationen Sicherheitsereignisse wie das Aufrufen unsicherer Websites und potenzielle Versuche zur Datenextraktion überwachen und darauf reagieren können. So wird eine einheitliche Sicherheit und Richtliniendurchsetzung auf verschiedenen Plattformen ermöglicht.

     
    • Chrome 137 für Android und iOS
     

   

  • Connectors API back to top

    Wir planen, den Einrichtungsprozess für Sicherheits-Connectors von Drittanbietern zu vereinfachen und es Anbietern zu ermöglichen, Konfigurationen direkt über ihre eigene Benutzeroberfläche zu verwalten. So soll es Organisationen leichter fallen, ihre bevorzugten Sicherheitstools und ‑dienste in Chrome zu integrieren und so die Sicherheit und Verwaltung auf verschiedenen Plattformen zu verbessern.

     
    • Chrome 137 für Windows, MacOS, Linux und ChromeOS

↑ 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 135: 26. März 2025
Chrome 134: 26. Februar 2025
Chrome 133: 29. Januar 2025
Chrome 132: 8. Januar 2025
Frühere Versionshinweise  →

Weitere Informationen

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ü
13462780702431774931
true
Suchen in der Hilfe
true
true
true
true
true
410864
false
false
false
false