Versionshinweise für Chrome Enterprise und Chrome Education

Zuletzt aktualisiert am 3. März 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.

 

Chrome browser ChromeOS

Übersicht über Chrome-Version 134

 
Änderungen am Chrome-Browser Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Mit Google Lens auf dem Computer und iOS-Geräten auf dem Bildschirm suchen    
Bereich „Sicherheit und Datenschutz“ in Chrome-Entwicklertools  
Verbesserte Erkennung von Passwortformularen mithilfe von ML    
Unterstützung des Kunden durch LLM bei der Behebung von Betrugsfällen    
LLM-gestützte On-Device-Erkennung missbräuchlicher Benachrichtigungen unter Android    
Verwaltete Profile mit benutzerdefiniertem Logo und Label anpassen  
Anmeldedaten für gerätegebundene Sitzungen, google.com-Prototyp    
Passwortänderung    
Vorlesen im Lesemodus in Chrome 134    
Entpackte Erweiterungen auf den Entwicklermodus beschränken    
Einstellungen für KI-Funktionen in der Richtlinie 2 in den Einstellungen anzeigen    
Anpassbares <select>-Element    
Lockerung des HTML-Parsers für <select>    
Nicht standardmäßige getUserMedia-Audioeinschränkungen entfernen    
Änderungen an den Chrome-Anmeldeabläufen für verwaltete Nutzer     
Karten für die Seite „Neuer Tab“ für Microsoft Outlook und SharePoint    
Neue Richtlinien im Chrome-Browser    
Entfernte Richtlinien im Chrome-Browser    
Änderungen bei Chrome Enterprise Core Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Chrome Enterprise Companion    
Unterstützung der Richtlinie „DownloadRestrictions“ auf iOS-Geräten    
Empfohlene Richtlinien (Nutzerüberschreibung)    
Änderungen bei Chrome Enterprise Premium Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Evidence Locker    
Screenshot-Aufnahmen verhindern    
Anstehende Änderungen für den Chrome-Browser Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Ende der Unterstützung von Mutationsereignissen    
Verbesserungen bei Erweiterungen in der Desktopversion von Chrome  
Entfernung von Unternehmensrichtlinien für den privaten Netzwerkzugriff    
ThirdPartyBlockingEnabled-Richtlinie entfernen    
Verbesserungen bei Einstellungen, Website-Verknüpfungen und Designs in Chrome für Computer    
Einstellung des bisherigen Passwortmanagers in Chrome für Android    
Drittanbieter-Cookies sind im Inkognitomodus immer gesperrt    
Blob-URL-Partitionierung: Abrufen/Navigation    
Service Worker-Client erstellen und Service Worker-Controller für srcdoc-iFrame übernehmen    
Getters von Intl Locale Info werden eingestellt    
Partitionieren des Verlaufs der ":visited"-Links    
HSTS-Tracking-Prävention    
Einstellung der veralteten Methode „navigator.xr.supportsSession“    
Strenge Same-Origin-Richtlinie für die Storage Access API    
Anbieter des Bedienungshilfen-Frameworks zur Automatisierung der Benutzeroberfläche unter Windows    
SwiftShader-Fallback entfernen    
Leerzeichen in URL-Hosts, die nicht mit file:// beginnen, sind nicht zulässig    
Migration von der Safe Browsing API v4 zur v5    
Bevorstehende Änderungen bei Chrome Enterprise Core Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Unterstützung für erweiterbares SSO von Apple für Chrome unter macOS  
Isolierte Web-Apps    
Bevorstehende Änderungen bei Chrome Enterprise Premium Sicherheit/Datenschutz Nutzerproduktivität/Apps Verwaltung
Nutzerfreundlichkeit von DLP-Regeln überarbeiten    
URL-Filterung unter iOS und Android    
Berichtsconnector für Mobilgeräte    
Connectors API    

 

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

 

   

  • Mit Google Lens auf dem Computer und iOS-Geräten auf dem Bildschirm suchen back to top

    Administratoren können alle Elemente dieser Funktion über die Richtlinie LensOverlaySettings steuern. Zum Durchführen der Suche wird ein Screenshot des Bildschirms an die Google-Server gesendet. Er ist jedoch mit keinen IDs oder Konten verknüpft, wird von niemandem eingesehen und Daten zum Inhalt werden nicht protokolliert. Um die Suche auf das Dokument oder die Website zu beziehen, das bzw. die vom Nutzer gerade angezeigt wird, werden die PDF-Byte oder der HTML-Code der Website an die Google-Server gesendet. Sie sind jedoch mit keinen IDs oder Konten verknüpft, können von niemandem eingesehen werden und die Daten oder die über den Inhalt generierten Daten werden nicht protokolliert.

     

    Desktop

    Seit Chrome 126 können Nutzer mit Google Lens in allen Bildern oder Texten suchen, die sie auf ihrem Computerbildschirm sehen. Wenn Sie diese Funktion verwenden möchten, rufen Sie eine Website auf und klicken Sie in der Omnibox im Fokus auf den Chip Google Lens oder klicken Sie mit der rechten Maustaste auf ein Bild und wählen Sie Mit Google Lens suchen aus. Nutzer können auf eine beliebige Stelle auf dem Bildschirm klicken, um den Inhalt zu durchsuchen. Außerdem können sie ihre Suche verfeinern, indem sie im Suchfeld Fragen hinzufügen. Ab Chrome 132 können Nutzer auch Fragen zu ganzen Webseiten oder PDF-Dokumenten stellen. Die Antworten beziehen sich dann auf das aktuelle Dokument und das Web. Wenn Sie diese Funktion verwenden möchten, starten Sie wie oben beschrieben die Suche mit Google Lens und geben Sie Suchanfragen in das Suchfeld oben rechts im Chrome-Fenster ein. Auf der rechten Seite des Browserfensters wird eine Seitenleiste mit den Suchergebnissen geöffnet. 

     

    iOS

    Seit Chrome 131 können Nutzer mit Google Lens in allen Bildern oder Texten suchen, die sie auf ihrem iOS-Chrome-Bildschirm sehen. Wenn Sie diese Funktion verwenden möchten, rufen Sie eine Website auf und klicken Sie auf das Dreipunkt-Menü > Mit Google Lens suchen. Ab Chrome 134 können Nutzer diese Funktion auch aufrufen, indem sie links in der Omnibox auf das Symbol Google Lens klicken. Nutzer können auf eine beliebige Stelle auf dem Bildschirm klicken, sie markieren oder sie ziehen, um den Inhalt zu durchsuchen. Außerdem können sie ihre Suche verfeinern, indem sie im Suchfeld Suchbegriffe oder Fragen hinzufügen.

     

    Roll‑out-Details:

    • Chrome 126 für ChromeOS, Linux, macOS und Windows: Roll-out der Funktion auf 1% der stabilen Version
    • Chrome 127 für ChromeOS, Linux, macOS und Windows: Roll-out auf 100 % stabil
    • Chrome 131 für iOS: Roll-out der Funktion bei 1% der stabilen Version
    • Chrome 132 für ChromeOS, Linux, macOS und Windows: Einführung der erweiterten Funktion bei 1% der stabilen Version
    • Chrome 133 für iOS: Roll-out auf 100% stabil
    • Chrome 134 für iOS: Einführung der erweiterten Funktion auf 100% der stabilen Version
     

   

  • Bereich „Sicherheit und Datenschutz“ in Chrome-Entwicklertools back to top

    Ab Chrome 134 können Entwickler mit dem neuen Bereich Sicherheit und Datenschutz in den Chrome DevTools testen, wie sich ihre Website verhält, wenn Drittanbieter-Cookies eingeschränkt sind. Entwickler können Drittanbieter-Cookies vorübergehend einschränken, das Verhalten ihrer Website beobachten und den Status von Drittanbieter-Cookies auf ihrer Website prüfen.

     

     

    Mit dieser Funktion werden keine dauerhaften Änderungen an vorhandenen Unternehmensrichtlinien vorgenommen. Es ist jedoch möglich, Richtlinien zu Drittanbieter-Cookies (BlockThirdPartyCookies und CookiesAllowedForUrls) vorübergehend zu überschreiben, um erweiterte Einschränkungen zu testen. Wenn in Ihrer Unternehmensrichtlinie bereits Drittanbieter-Cookies mithilfe von BlockThirdPartyCookies blockiert werden, ist diese Funktion deaktiviert.

     

    Der neue Bereich Sicherheit und Datenschutz ersetzt den vorhandenen Bereich Sicherheit. Informationen zur TLS-Verbindung und zum Zertifikat sind weiterhin im Menü Sicherheit links im Bereich Sicherheit und Datenschutz verfügbar.

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

   

  • Verbesserte Erkennung von Passwortformularen mit ML back to top

    In Chrome 134 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 134 für Android, iOS, ChromeOS, Linux, macOS und Windows
     

   

  • Unterstützung des Kunden durch das LLM bei der Betrugsprävention back to top

    Nutzer im Web werden täglich mit einer enormen Menge an Betrugsversuchen konfrontiert. Um diese Betrugsversuche zu bekämpfen, nutzt Chrome ein On-Device Large Language Model (LLM), um betrügerische Websites für Nutzer des erweiterten Safe Browsing zu erkennen. Chrome sendet den Seiteninhalt an einen lokalen LLM, um sicherheitsbezogene Signale der Seite abzuleiten und diese Signale serverseitig an Safe Browsing zur endgültigen Entscheidung zu senden. Wenn diese Option aktiviert ist, benötigt Chrome möglicherweise mehr Bandbreite, um die LLM herunterzuladen. 

    Mit der Unternehmensrichtlinie SafeBrowsingProtectionLevel können Sie Safe Browsing und den Modus steuern, in dem es ausgeführt wird.

     
    • Chrome 134 für Linux, MacOS und Windows

      Erfassen Sie den Markennamen und die Intent-Zusammenfassung der Seite, für die die Tastatursperre-API angefordert wurde, um betrügerische Websites zu identifizieren.

     

   

  • LLM-gestützte On-Device-Erkennung missbräuchlicher Benachrichtigungen auf Android-Geräten back to top

    Ziel dieser Neuerung ist es, den Inhalt von Benachrichtigungen auszublenden, die als missbräuchlich eingestuft werden. Der Nutzer hat dann die Möglichkeit, die Benachrichtigung zu schließen, sie anzuzeigen oder das Abo für die Quelle zu kündigen. Diese Erkennung muss durch ein On-Device-Modell erfolgen.

     
    • Chrome 134 für Android
     

   

  • Verwaltete Profile mit benutzerdefiniertem Logo und Label anpassen back to top

    Neue Anpassungen für die Symbolleiste und das Profilmenü, mit denen Nutzer leicht erkennen können, ob ihr Chrome-Profil verwaltet wird und ob sie sich auf einem geschäftlichen oder privaten Gerät befinden. Dies ist besonders nützlich, wenn Mitarbeiter ihre eigenen Geräte mit verwalteten Konten verwenden.

    Wir fügen drei neue Richtlinien hinzu, um die Nutzung zu optimieren:

    • EnterpriseCustomLabel: Hiermit können Sie den Text anpassen, der im Symbolleistenelement angezeigt wird, damit er zum Branding Ihrer Organisation passt.
    • EnterpriseLogoUrl: Fügen Sie dem Profilmenü Ihr Firmenlogo hinzu.
    • EnterpriseProfileBadgeToolbarSettings: Mit dieser Richtlinie kann das Standardlabel für ein verwaltetes Profil in der Chrome-Symbolleiste deaktiviert werden. 

    In Chrome 134 können Sie mit diesen Richtlinien das Logo und das Label anpassen, das in einem verwalteten Profil angezeigt wird. Die Richtlinien werden auf die verwalteten Profile der Nutzer angewendet. 

     

    Ab Chrome 135 wird das Standardverhalten des Profillabels und -symbols, das über dem Konto-Avatar eingeblendet wird, aktualisiert. Bei verwalteten Profilen wird neben dem Profillaufwerk das Label Arbeit oder Schule angezeigt. Im Profilmenü wird über dem Konto-Avatar ein Gebäudesymbol angezeigt. Das erweiterte Profillaufwerk kann über EnterpriseProfileBadgeToolbarSettings deaktiviert werden.

     
    • Chrome 134 für macOS, Windows und Linux

      Richtlinien zum Anpassen des Labels und Symbols der Symbolleiste (im Profilmenü) sind in der Admin-Konsole verfügbar. Wenn bereits Richtlinien festgelegt wurden, sehen Nutzer das benutzerdefinierte Logo und Label.

    • Chrome 135: Start des Roll-outs von Standardeinstellungen, darunter: 
      • 1) Label Arbeit oder Schule in der Symbolleiste neben dem Nutzeravatar 
      • 2) Ein Gebäudesymbol, das im Profilmenü über dem Kontobild des Nutzers eingeblendet wird. Das Label kann über EnterpriseProfileBadgeToolbarSettings deaktiviert werden. Die Einführung beginnt mit 1% und erfolgt dann nach und nach.
     

     

   

  • Anmeldedaten für gerätegebundene Sitzungen, google.com-Prototypback to top

    Mit dem Projekt Device Bound Session Credentials (Gerätegebundene Sitzungsanmeldedaten) soll das Web von langlebigen Inhaberanmeldedaten wie Cookies, die gestohlen und wiederverwendet werden können, auf Anmeldedaten umgestellt werden, die entweder kurzlebig oder kryptografisch an ein Gerät gebunden sind. 

    Die Funktion soll Nutzer vor dem Diebstahl von Anmeldedaten schützen, der in der Regel durch Malware auf dem Gerät des Nutzers ausgeführt wird. 

    Die aktuelle Einführung ist ein Proof-of-Concept, das auf die Website google.com ausgerichtet ist. In Zukunft möchten wir diesen Ansatz auch auf andere Websites und Webbrowser ausweiten.

    Unternehmensadministratoren können den Funktionsstatus mit der booleschen Richtlinie BoundSessionCredentialsEnabled steuern.

    • Chrome 124 für Windows

      Geplante Einführung von 1% der stabilen Chrome-Version für die Cookie-Bindung von google.com für die Allgemeinbevölkerung.

    • Chrome 134 für Windows

      Es wurde eine Bindungsunterstützung für OAuth2.0-Aktualisierungstokens hinzugefügt, die für die Anmeldung in Chrome verwendet werden.

     

   

  • Passwort ändern back to top

    Mit dieser Funktion können Nutzer gehackte Anmeldedaten sofort ändern. Die Funktion kann nur über das Dialogfeld Passwort prüfen ausgelöst werden. Wenn Nutzer eine Warnung für eine berechtigte Website sehen, können sie das Passwort direkt dort ändern. 

     
    • Chrome 134 für Linux, MacOS und Windows
     

     

   

  • Vorlesen im Lesemodus in Chrome 134 back to top

    Der Lesemodus ist eine Seitenleiste, die eine vereinfachte Ansicht von Webseiten mit viel Text bietet. Der Lesemodus enthält jetzt die Funktion Vorlesen, mit der sich der gerade gelesene Text laut vorlesen lässt. Sie können verschiedene natürliche Stimmen und Geschwindigkeiten auswählen und sich visuelle Highlights anzeigen lassen, während der Text gesprochen wird. 

     
    • Chrome 134 für Linux, MacOS und Windows
     

   

  • Entpackte Erweiterungen auf den Entwicklermodus beschränken back to top

    Ab Chrome 134 werden entpackte Erweiterungen, die über die Seite chrome://extensions geladen werden, nur aktiviert, wenn der Schalter für den Entwicklermodus aktiviert ist. Mit dieser Änderung soll die Sicherheit verbessert werden, indem die Risiken, die mit schädlichen entpackten Erweiterungen und Manipulationen im Entwicklermodus verbunden sind, verringert werden. Mit der Unternehmensrichtlinie ExtensionDeveloperModeSettings lässt sich der Schalter für den Entwicklermodus sperren.

     
    • Chrome 134 für ChromeOS, Linux, macOS und Windows
      Die Funktion wird für 100% der Nutzer in Chrome 134 eingeführt.
     

   

  • Unternehmenseinstellungen für KI-Funktionen anzeigen back to top

    Bisher wurden KI-Funktionen in den Einstellungen ausgeblendet, wenn sie durch eine Unternehmensrichtlinie deaktiviert wurden. Die Funktionen werden weiterhin angezeigt und es wird eine Benachrichtigung mit dem Hinweis Von Ihrer Organisation deaktiviert angezeigt, ähnlich wie bei anderen Einstellungen, die aufgrund von Richtlinien deaktiviert sind.

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

   

  • Anpassbares <select>-Element back to top

    Mit dem anpassbaren <select> können Entwickler das Rendern von <select>-Elementen vollständig steuern, indem sie die CSS-Eigenschaft appearance:base-select hinzufügen.

    Diese Funktion basiert auf dem Flag SelectParserRelaxation, das den HTML-Parser so ändert, dass mehr Tags innerhalb des <select>-Tags zulässig sind. Websites, die zusätzliche Tags innerhalb von <select> enthalten, die zuvor entfernt wurden, z. B. <span>-Tags, oder Websites, die eine extrem große Anzahl von <option>-Tags in ihrem <select> enthalten, können von SelectParserRelaxation betroffen sein. Diese Funktion und SelectParserRelaxation können mit der Unternehmensrichtlinie SelectParserRelaxation gesteuert werden. Bei früheren Einführungen von SelectParserRelaxation sind unter anderem Probleme aufgetreten, bei denen <select>-Elemente sehr lange zum Öffnen benötigten oder <option>-Tags nicht mehr angezeigt wurden.

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

   

  • Lockerung des HTML-Parsers für <select> back to top

    In Chrome 134 erlaubt der HTML-Parser neben <option>, <optgroup> und <hr> weitere Tags in <select>.

    Dies unterstützt die anpassbare Funktion <select>, wird aber zuerst eingeführt, da sie separat durchgeführt werden kann und einige Kompatibilitätsrisiken birgt.

    Diese Funktion ist durch die temporäre Richtlinie SelectParserRelaxationEnabled eingeschränkt. Dieser Übergangszeitraum ist vorübergehend. Die Richtlinie funktioniert ab Chrome 141 nicht mehr.

    Weitere Informationen finden Sie im Hilfeartikel Benutzerdefinierbares Auswahlelement (Erläuterung).

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

   

  • Nicht standardmäßige getUserMedia-Audioeinschränkungen entfernen back to top

    In Chrome 134 werden eine Reihe nicht standardmäßiger Einschränkungen mit dem Präfix „goog“ für getUserMedia entfernt, die vor der richtigen Standardisierung von Audioeinschränkungen vorhanden waren.

     

    Die Nutzung ist je nach Einschränkung um etwa 0,000001 % bis 0,0009 % gesunken. Einige davon haben aufgrund von Änderungen am Chromium-Audio-Capture-Stack gar keine Auswirkungen. Aufgrund anderer bevorstehender Änderungen haben bald keine der Einschränkungen mehr Auswirkungen.

     

    Wir gehen nicht davon aus, dass es aufgrund dieser Änderung zu größeren Rückschritten kommt. Anwendungen, die diese Einschränkungen verwenden, funktionieren weiterhin, erhalten aber Audio mit den Standardeinstellungen, als wären keine Einschränkungen übergeben worden. Sie können ganz einfach zu Standardeinschränkungen migriert werden.

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

   

  • Aktualisierungen der Chrome-Anmeldeabläufe für verwaltete Nutzer back to top

    Wenn sich Enterprise-Nutzer im Web oder in Chrome anmelden, werden ihnen jetzt aktualisierte Anmeldeabläufe und Offenlegungen zur Verwaltung angezeigt. Außerdem werden Nutzer möglicherweise aufgefordert, ein neues Profil zu erstellen oder im vorhandenen Profil weiterzuarbeiten. Administratoren können weiterhin BrowserSignIn oder ProfileSeparationSettings verwenden, um ein verwaltetes Profil durchzusetzen.  

     
    • Chrome 134 für Linux, macOS und Windows: Roll-out wird fortgesetzt
       

     

   

  • Karten auf der Seite „Neuer Tab“ für Microsoft Outlook und SharePoint back to top

    Unternehmensnutzer mit Outlook oder Sharepoint können jetzt direkt über die Seite Neuer Tab auf anstehende Besprechungen oder vorgeschlagene Dateien zugreifen. So müssen Sie nicht mehr den Tab wechseln oder Zeit damit verschwenden, nach dem nächsten Termin zu suchen. Sie können sich stattdessen auf das Wesentliche konzentrieren. Administratoren, die diese Funktion testen möchten, können sich als Trusted Tester registrieren.

     
    • Verfügbar für Trusted Tester in Chrome 134 für Windows, macOS und Linux

   

   

  • Entfernte Richtlinien im Chrome-Browser back to top
    Richtlinie Beschreibung
    Keine Richtlinien in Chrome 134 entfernt  
     

   

Änderungen bei Chrome Enterprise Core

   

  • Chrome Enterprise Companion back to top

    Chrome Enterprise Companion ist ein neues Verwaltungs-Binärprogramm, das automatisch mit Chrome-Browsern installiert wird, die in Chrome Enterprise Core oder Chrome Enterprise Premium registriert sind. Es soll Anwendungsfälle, Richtlinien und Berichte für Unternehmen unterstützen. 

     
    • Chrome 134 für Windows und macOS
     

   

  • Unterstützung der Richtlinie „DownloadRestrictions“ unter iOS back to top

    DownloadRestrictions ist eine universelle Richtlinie, die Chrome Enterprise Core-Nutzern auf Desktop-Plattformen und unter Android zur Verfügung steht. Die Richtlinie DownloadRestrictions wird jetzt auf iOS-Geräten unterstützt. So können Administratoren alle Downloads in der mobilen Chrome-Version für iOS blockieren. 

     
    • Chrome 135 für iOS
     

   

Änderungen bei Chrome Enterprise Premium

 

   

  • Evidence Locker back to top

    Mit Evidence Locker können Chrome Enterprise Premium-Administratoren Dateien speichern und prüfen, die als Malware gekennzeichnet wurden oder gegen eine Datenschutzregel verstoßen. Eine Kopie der Datei wird im Google Cloud Storage-Bucket gespeichert, der der Organisation gehört und von ihr angegeben wurde. Der Sicherheitsadministrator kann die Vorfälle mit dem Sicherheits-Prüftool untersuchen und die Dateien, die den Vorfall ausgelöst haben, zur weiteren Analyse herunterladen. Weitere Informationen finden Sie im Hilfeartikel Verdächtige Dateien prüfen und Maßnahmen ergreifen.

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

   

  • Screenshot-Aufnahmen verhindern back to top

    In Chrome 134 wurde die Funktion zum Verhindern von Screenshots verbessert. Die Blockierung der Bildschirmfreigabe wurde auf Konferenz-Apps wie Google Meet, Zoom, Teams und Slack ausgeweitet. Mit diesem Update bauen wir auf der erfolgreichen Einführung der Datenschutzeinstellungen auf, indem wir wichtige Funktionen hinzufügen und Lücken schließen sowie Nutzerfeedback berücksichtigen.

     
    • Chrome 134 für Windows und macOS

 

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

 

    

  • 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 134 verwendet werden.
    • Die Unternehmensrichtlinie MutationEventsEnabled kann ebenfalls über Chrome 134 zu demselben Zweck verwendet werden.
    • Chrome 135 für Android, Linux, macOS und Windows: Die Unternehmensrichtlinie MutationEventsEnabled wird eingestellt.

    

  • Verbesserungen bei Erweiterungen in der Chrome-Desktopversion 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. 

     
    • Chrome 135 für Linux, MacOS und Windows

    

  • Entfernung von Unternehmensrichtlinien für den privaten Netzwerkzugriff 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 inkompatibel 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 die Einführung dieses Ansatzes viel einfacher 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.

    Die Richtlinien InsecurePrivateNetworkRequestsAllowedForUrls und InsecurePrivateNetworkRequestsAllowed, die die Einschränkungen von PNA 1.0 lockern, werden in Chrome 135 entfernt. 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.

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

     
    • Chrome 135 für Linux, MacOS und Windows

    

  • Einstellung des bisherigen Passwortmanagers in Chrome auf Android 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, nicht für den Inkognitomodus. 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

    

  • 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“ bei vom Renderer initiierten Navigationen der obersten Ebene zu Blob-URLs, bei denen die entsprechende Website seitenübergreifend zur 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 135 für Windows, macOS und Linux

    

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

    Srcdoc-Kontextdokumente sind derzeit keine Service Worker-Clients und werden nicht vom Service Worker der übergeordneten Seite abgedeckt. Dies führt 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. Wir möchten die Abweichungen beheben, indem wir Service Worker-Clients für srcdoc-iFrames erstellen und sie den Service Worker-Controller der übergeordneten Seite übernehmen lassen.

    • Chrome 135 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 müssen die veralteten Getter entfernen und die umbenannten Funktionen neu starten.

    • Chrome 135 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 gekennzeichnet, wenn sie zuvor von dieser Website und diesem Frame-Ursprung aus angeklickt wurden. Auf Browserseite bedeutet das, dass die Hashtabelle „VisitedLinks“ jetzt durch Dreifachschlüsselpartitionierung 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 Selbstlinks. Links zu den eigenen Seiten einer Website können als :visited formatiert werden, auch wenn sie auf genau dieser Website und in genau diesem Frame-Ursprung noch nie angeklickt wurden. Diese Ausnahme gilt nur für Frames oder Unterframes der obersten Ebene, 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 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. Bereits in Chrome 135 wird das HSTS-Tracking-Verhinderungssystem das Nutzer-Tracking durch Drittanbieter mithilfe des HSTS-Caches einschränken. 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 Erläuterung zur HSTS-Tracking-Prävention auf GitHub.

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

    

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

    navigator.xr.supportsSession 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

    

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

    In Chrome 135 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 (nicht an die Website) des Iframes 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 135 für Windows, MacOS, Linux und Android

    

  • 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 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 136 lässt es sich vorübergehend deaktivieren.
    • Chrome 137 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.

 

    

  • 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. Die Nutzerfreundlichkeit ist schlecht, wenn von einer leistungsstarken GPU-gestützten WebGL-Implementierung auf eine CPU-gestützte Implementierung umgestellt wird. 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

 

    

  • Leerzeichen in URLs, die nicht mit „file://“ beginnen, sind nicht zulässig 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 mehrere Tests nicht besteht, die in den Interop2024-HTTPS-URLs für WebSocket und den Fokusbereichen für URLs enthalten sind.

    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

    

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

 

 

Bevorstehende Änderungen bei Chrome Enterprise Core

    

  • Unterstützung für erweiterbares SSO 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 SSO-Erweiterung (Single Sign-On) aktiviert sind. Bei dieser ersten Version können sich Endnutzer in verwalteten 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 Identitätsanbieter werden möglicherweise in naher Zukunft unterstützt.

    • Ab Chrome 135 für 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 von Unternehmen verwalteten Browserkonfigurationen unter Windows hinzugefügt.

 

 

Bevorstehende Änderungen bei Chrome Enterprise Premium

 

   

  • 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 135 für Windows, MacOS, Linux und ChromeOS
     

   

  • 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 137 für Android und iOS
     

   

  • 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 136 für Android
    • Chrome 137 für 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 Unternehmen 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 

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?
7471331436603505679
true
Suchen in der Hilfe
true
true
true
true
true
410864
Suche
Suche löschen
Suche schließen
Hauptmenü
false
false
false