Google hat mit WebMCP (Web Model Context Protocol) eine neue JavaScript-Schnittstelle vorgestellt, über die KI-Agenten standardisiert mit Websites kommunizieren sollen. Wie Google-Entwickler André Cipriani Bandarra in einem Blogbeitrag erklärt, überträgt WebMCP die Idee des Model Context Protocol auf Websites, sodass KI-Agenten im Browser strukturiert mit Webseiten interagieren können – ohne das DOM der Seite scrapen und sich durch den Code klicken zu müssen.

Über die Schnittstelle können KI-Agenten gezielt Aktionen auf Websites ausführen, beispielsweise Formulare ausfüllen, Produkte suchen und bestellen oder Flüge buchen. „WebMCP zielt darauf ab, einen Standard für strukturierte Tools bereitzustellen, um sicherzustellen, dass KI-Agenten Aktionen mit erhöhter Geschwindigkeit, Zuverlässigkeit und Präzision ausführen können“, sagt Bandarra.

WebMCP erweitert das Navigator-Interface um navigator.modelContext mit Methoden wie registerTool() und provideContext(). Google unterscheidet dabei zwischen einer deklarativen API für einfache Formular-Aktionen und einer imperativen API für komplexe JavaScript-Interaktionen. Jedes registrierte Tool benötigt einen Namen, eine Beschreibung in natürlicher Sprache, ein JSON-Schema für Eingaben sowie eine Execute-Callback-Funktion.

Unterschiede zu Microsofts NLWeb

Microsoft hatte Mitte 2025 mit NLWeb ein eigenes Open-Source-Projekt für das „agentische Web“ vorgestellt. Der zentrale Unterschied: NLWeb ist serverseitig konzipiert und macht Webseiten zu MCP-Servern mit natürlichen Sprachschnittstellen. WebMCP hingegen läuft im Browser im JavaScript-Kontext, ohne separate Backend-Komponenten.

Laut der offiziellen WebMCP-Spezifikation der W3C Web Machine Learning Community Group arbeiten Google und Microsoft mittlerweile gemeinsam an dem WebMCP-Standard. Als Co-Autoren sind neben Google-Entwicklern auch Microsoft-Entwickler gelistet, was auf eine mögliche Konvergenz hindeutet.

WebMCP steht derzeit als Early Preview über Googles Early-Access-Programm für Entwickler bereit und ist in Chrome 146 als DevTrial verfügbar. Google könnte die Schnittstelle künftig in Chrome und seine KI-Dienste wie Gemini integrieren, um Browser-Agenten direkt mit Websites interagieren zu lassen.

(odi)

Die von der Eclipse Foundation gegründete Open Regulatory Compliance Working Group (ORC WG) hat ihr erstes Whitepaper veröffentlicht. Die Arbeitsgruppe – zu deren Mitgliedern namhafte Unternehmen wie Microsoft, Siemens, Red Hat und Bosch zählen – entstand durch das Aufkommen des Cyber Resilience Act (CRA), einer EU-Regulierung zur erhöhten Sicherheit von Produkten mit digitalen Elementen.

Das Whitepaper widmet sich offenen Fragen rund um die neue Rolle der im CRA genannten Open Source Software Stewards. Dabei macht die Arbeitsgruppe deutlich, dass das Whitepaper keine juristische Empfehlung ist, sondern ein kollektives Verständnis von Open-Source-Beitragenden widerspiegelt.

Open Source Software Stewards: Verantwortlichkeiten und Verpflichtungen

Wie die ORC WG in ihrem Blog betont, markiert der Cyber Resilience Act einen bedeutenden Wandel der Cybersecurity-Verantwortlichkeiten innerhalb des Softwareentwicklungs-Ökosystems. Open Source Software Stewards werden im CRA erstmals als juristische Akteure genannt und sind eine von Herstellern (Manufacturers) separate Kategorie. Im Gegensatz zu diesen müssen sie beispielsweise keine administrativen Geldstrafen bei Nicht-Compliance leisten. Allerdings wirft die neue Rolle einige Fragen auf, etwa was sie in der Praxis konkret bedeutet und welche genauen Verpflichtungen sie mit sich bringt.

Für das neue Whitepaper haben Mitglieder der ORC-Community den CRA-Text analysiert und interpretiert, um praktische Handlungsanweisungen und Informationen zu bieten. Konkret benennt das Whitepaper beispielsweise, in welchem Verhältnis die Stewards zu ihren unterstützten Projekten stehen und weshalb diese Rolle geschaffen wurde. Ihre Verpflichtungen kommen ebenfalls zur Sprache, und wie sich diese von jenen an Softwarehersteller unterscheiden.

Praktische Beispiele sollen zeigen, wie Open Source Software Stewards in ihren Projekten Cybersicherheitsregeln etablieren und mit Sicherheitslücken sowie deren Offenlegung umgehen können. Das Whitepaper erwähnt darüber hinaus, welche Fragen noch ungeklärt sind, etwa wie man in komplexen Fällen die geeignete Marktüberwachungsbehörde auswählt, und wo weitere regulatorische Anweisungen notwendig sind.

Auf der Website der ORC Working Group steht das 25-seitige Whitepaper „Open Source Software Stewards and CRA“ in der Version 1.0 zum Download bereit.

Übergreifende Fragen: Wann ist ein Steward ein Steward?

Dabei richtet sich das Whitepaper lediglich an Open-Source-Projekte, die einen Steward haben. Auf die meisten Projekte trifft das nach Angaben der ORC-Arbeitsgruppe nicht zu. Ein Steward muss eine „juristische Person“ sein, was beispielsweise ein Unternehmen sein kann. Die meisten Open-Source-Projekte werden jedoch nicht von Unternehmen oder Stiftungen unterstützt. Auch dient das Dokument nicht dazu, festzustellen, ob ein Unternehmen als Steward eines Projektes gilt – oder gar als Hersteller. Solche Fragen kommen in den ORC Working Group FAQ zur Sprache.

(mai)

Google hat am vergangenen Freitag die erste Beta von Android 17 veröffentlicht. Im Zuge dessen nannte das Unternehmen vor allem entwicklerseitige Neuerungen. Nicht erwähnt hat der Konzern dabei die neue Funktion für die geräteübergreifende Kontinuität namens Handoff (Übergabe).

Handoff zwischen Android-Geräten

Das neue Feature erwähnt Google derweil in der Dokumentation zu Android 17 im Punkt „Funktionen und APIs“, der noch recht überschaubar ist. Laut Google können App-Entwickler die Funktion in ihre Anwendungen integrieren, um Nutzerinnen und Nutzern „eine geräteübergreifende Kontinuität zu bieten“. Damit können Nutzer eine App-Aktivität auf einem Android-Gerät starten und auf ein anderes Android-Gerät übertragen.

Im Unterschied zu Apples oder Microsofts Lösungen ist Googles also nur auf ein Betriebssystem beschränkt. Für die bald erscheinenden Android-PCs mit Aluminium OS dürfte das Feature – oder zwischen Smartphone und Tablet – durchaus praktisch sein. Apple ermöglicht derweil ein Handoff für einige Apps im eigenen Ökosystem zwischen iPhones, Macs und iPads. Microsoft hat hat die Handoff-Funktion zwischen einigen Android-Apps und Windows mit den Patchday-Updates aus dem Februar erweitert.

Wie Google weiter erklärt, wird die Handoff-Funktion im Hintergrund auf dem Gerät eines Nutzers ausgeführt. Sie zeigt verfügbare Aktivitäten von den anderen Geräten des Nutzers in der Nähe über verschiedene Einstiegspunkte wie den Launcher und die Taskleiste auf dem empfangenden Gerät an.

Apps können die Übergabe-Funktion so festlegen, dass dieselbe native Android-App gestartet wird, wenn sie auf dem empfangenden Gerät installiert und verfügbar ist, heißt es weiter. „In diesem App-zu-App-Ablauf wird der Nutzer per Deeplink zur entsprechenden Aktivität weitergeleitet“, beschreibt Google den Ablauf. Alternativ könne die Übergabe von Apps an das Web als Fallback-Option angeboten oder direkt mit der URL-Übergabe implementiert werden. In der Beta 1 sind noch keine Hinweise auf die Handoff-Funktion zu finden.

Google gibt in der Dokumentation eine kurze Information zur Integration von Handoff in Apps: „Die Handoff-Unterstützung wird auf Basis einzelner Aktivitäten implementiert.“ Um Handoff zu aktivieren, müssen Entwickler die Methode setHandoffEnabled()für die Aktivität aufrufen. „Möglicherweise müssen zusätzliche Daten zusammen mit der Übergabe übermittelt werden, damit die neu erstellte Aktivität auf dem empfangenden Gerät den entsprechenden Status wiederherstellen kann. Implementieren Sie den Rückruf onHandoffActivityRequested(), um ein HandoffActivityData-Objekt zurückzugeben, das Details enthält, die angeben, wie Handoff die Aktivität auf dem empfangenden Gerät verarbeiten und neu erstellen soll.“

Was noch?

Neben Handoff nennt Google als weitere neue Android-17-Funktion unter anderem Optimierungen im Bereich Konnektivität, „damit Apps auch in Satellitennetzwerken mit geringer Bandbreite effektiv funktionieren. Detaillierter geht Google nicht auf die Neuerung ein.

Überdies erweitert Google offenbar den mit Android 16 ins System integrierten „Erweiterten Sicherheitsmodus für Android“ (Android Advanced Protection Mode, AAPM), um eine Schnittstelle für App-Entwickler, um den Status des Modus zu erkennen. „So können Anwendungen automatisch eine verstärkte Sicherheitskonfiguration annehmen oder risikoreiche Funktionen einschränken, wenn ein Nutzer sich dafür entschieden hat“, schreibt Google.

(afl)