DE202013012485U1

DE202013012485U1 - System für Browseridentität

Info

Publication number: DE202013012485U1
Application number: DE202013012485.7U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2012-07-20
Filing date: 2013-06-04
Publication date: 2017-01-20
Anticipated expiration: 2023-06-05
Also published as: CN104737175A; US20140025949A1; US9887965B2; EP2875463A1; CN104737175B; WO2014014565A1; EP2875463B1

Abstract

Ein nicht-flüchtiges computerlesbares Medium, das durch den Prozessor eines Rechners ausführbare Anweisungen enthält, die bei Ausführung durch den Prozessor den Rechner zu Folgendem veranlassen:
Exposition einer Programmierschnittstelle der Browseranwendung gegenüber einer Webanwendung zur Bestätigung und Identifizierung eines Benutzers unter Einsatz von im Browser gespeicherten benutzerspezifischen Identitätsinformationen;
Übertragung kryptographischer Informationen, die mit dem Benutzer assoziiert sind, von der Programmierschnittstelle der Browseranwendung an die Webanwendung; und
Bereitstellung benutzerspezifischer Inhalte für den Benutzer über die Webanwendung, wenn die Webanwendung unter Einsatz der kryptographischen Informationen eine Identität des Benutzers über die Programmierschnittstelle der Browseranwendung bestätigt.

Description

VERWEIS
Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
TECHNISCHES GEBIET
Diese Offenlegung bezieht sich allgemein auf Browser-Technologie und im Besonderen auf einen Identifizierungsmechanismus für einen Web-Browser.
HINTERGRUND
Ein Web-Browser kann eine Identität aufrechterhalten und die Identität gegenüber einem Server authentifizieren. Dennoch gibt es kein System, das über verschiedene Webanwendungen hinweg eine gemeinsame Identität bietet. Jedes Mal, wenn ein Benutzer auf eine andere Webanwendung, einen anderen Web-Service oder eine andere Website zugreift, kann es sein, dass er sich separat anmelden muss. Es kann für Benutzer sehr schwierig sein, unterschiedliche Benutzernamen und Kennwörter beizubehalten und sich so viele Male anmelden zu müssen.
Darüber hinaus mögen sich gegenwärtige Identitätslösungen auf eine Server-an-Server-Technologie verlassen, ohne jegliche Hilfe vom Web-Browser. Gegenwärtige Identitätslösungen können sich zudem bei der Implementierung als komplex erweisen und eine mangelhafte Benutzererfahrung mit sich bringen. Zum Beispiel können gegenwärtige Lösungen einen relativ komplexen serverseitigen Code und eine verwirrende Benutzerschnittstelle zur Authentifizierung erfordern, um Informationen wie etwa einen Benutzernamen, E-Mail, Foto oder einen benutzerspezifischen Avatar zu erhalten. Zudem ist die Lebensdauer von Cookies gering, und die Abmeldung aus einem zentralen Konto wie etwa einem E-Mail-Konto kann eine Sitzung im Hinblick auf andere Webanwendungen ungültig machen, was sich für Benutzer als kontraintuitiv erweisen kann. Dementsprechend besteht ein Bedürfnis für Systeme und Methoden, die die Unzulänglichkeiten der gegenwärtigen Technologie angehen und andere, neue und innovative Merkmale bieten.
ZUSAMMENFASSUNG
Im Einklang mit einem allgemeinen Aspekt wird eine Programmierschnittstelle der Browseranwendung gegenüber einer Webanwendung exponiert, um die Identität eines Benutzers mit Hilfe von durch den Browser gespeicherten benutzerspezifischen Informationen zu bestätigen. Mit dem Benutzer assoziierte kryptographische Informationen werden von der Programmierschnittstelle der Browseranwendung an die Webanwendung übertragen. Benutzerspezifischer Inhalt wird dem Benutzer über die Webanwendung geliefert, wenn die Webanwendung mit Hilfe der kryptographischen Informationen eine Identität des Benutzers über die Programmierschnittstelle der Browseranwendung bestätigt.
Die Details einer oder mehrerer Ausführungen sind in den nachstehenden zugehörigen Zeichnungen und der Beschreibung dargelegt. Andere Features anhand der Beschreibung und Zeichnungen sowie anhand der Ansprüche ersichtlich werden.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1A ist ein Blockdiagramm für einen exemplarischen Webbrowser.
1B ist ein Diagramm einer Benutzerschnittstelle, das eine exemplarische Webanwendung illustriert.
2 ist ein Diagramm einer Benutzerschnittstelle, das ein exemplarisches Mitteilungsfenster im Zusammenhang mit einer Webanwendung illustriert.
3 ist das Beispiel einer Manifestdatei im Zusammenhang mit einer Webanwendung oder Erweiterung.
4 ist ein schematisches Blockdiagramm für das Beispiel eines Browseridentitätssystems.
5A ist ein Flussdiagramm für einen Musterprozess beim Einsatz einer Browseridentität, im Einklang mit den Ausführungen, die im Hinblick auf 1–4 beschrieben sind.
5B ist ein Blockdiagramm für einen exemplarischen Austausch kryptographischer Informationen zwischen einem Browser und einer Webanwendung.
6 zeigt das Beispiel eines Computergeräts und eines mobilen Computergeräts, die verwendet werden können, um die hier beschriebenen Techniken zu implementieren.
Gleiche Verweissymbole in den verschiedenen Zeichnungen zeigen gleiche Elemente an.
AUSFÜHRLICHE BESCHREIBUNG
Systeme und Methoden, die hier beschrieben werden, implementieren eine Identität, die zu einem Webbrowser gehört, oder einem Webbrowser, der als Betriebssystem für den Einsatz durch installierte Webanwendungen arbeitet. Mit Zustimmung des Benutzers kann ein Webbrowser ein einzigartiges kryptographisches Schlüsselpaar für jedes Paar (Benutzer, Herkunft) generieren. Der öffentliche Schlüssel kann die Identität des Benutzers für die Herkunft werden (z. B. Webanwendung). Die Schlüsselpaare können zwischen Clients synchronisiert werden, sodass Benutzer nicht jedes Mal, wenn sie eine andere Webanwendung bei anderen Clients nutzen wollen, neue Authentifizierungsreferenzen eingeben müssen (ausgenommen vielleicht eine Browseranmeldung).
1A illustriert eine exemplarische Webbrowseranwendung 101, die eine Benutzerschnittstelle 103 anzeigen kann, einschließlich Tabs 105, 107 und 109. In einer Ausführung kann Tab 105 wählbare Symbole für Webanwendungen 111, 113, 115 und 117 anzeigen. Die hier beschriebenen Systeme und Methoden können zur Aufrechterhaltung und Bereitstellung einer sicheren Browseridentität für einen Benutzer eingesetzt werden und können zum Beispiel mit Webanwendungen (z. B. Webanwendung 111) implementiert werden, die hohe Punktzahlen bei einem Spiel aufrechterhalten und bei Eingabe einer hohen Punktzahl wissen wollen, wer ein Benutzer ist. Als weiteres Beispiel können die beschriebenen Systeme und Methoden für einkaufsbezogene Webanwendungen eingesetzt werden (z. B. Webanwendung 113), um zu vermeiden, dass ein Benutzer der Webbrowseranwendung 101 sich jedes Mal anmelden muss, wenn er mit Hilfe von Webanwendung 113 einen Artikel kaufen will. Als weiteres Beispiel kann der Betreiber einer Blog-Site die beschriebenen Systeme und Methoden benutzen, um Leute, die auf der Blog-Site posten, eindeutig zu identifizieren. Die Besitzer der Blog-Site müssen Benutzernamen und Kennwörter nicht speichern, was sie nicht mögen, denn wenn die Blog-Site gehackt wird, können diese Benutzernamen und Kennwörter zum Einbruch in andere Konten eingesetzt werden, was ein schlechtes Licht auf den Besitzer des Blogs wirft. Ein weiteres Beispiel wiederum ist der mögliche Einsatz einer Benutzeridentität für Website oder Webanwendung 115 zwecks E-Mail-Routing. Die Identität des Benutzers kann in gewisser Weise anonymisiert werden, so dass für einen Benutzer, der eine E-Mail-Nachricht von einer Website empfangen, jedoch vermeiden will, dass die Website seine E-Mail-Adresse erkennt, die beschriebenen Systeme und Methoden der Website die Sendung der E-Mail-Mitteilung an den Benutzer gestatten, ohne dass die Website die tatsächliche Adresse des Benutzers erfährt.
Ein anderer exemplarischer Einsatzfall zusätzlich zu dem Blogbetreiber, der nicht gehackt werden will, und zur Einkaufswebsite usw. besteht in darin, dass es im Allgemeinen schwierig ist, Identitätssysteme zu implementieren. Jeder Entwickler für jede Website muss dies immer wieder tun, und Benutzer mögen es gar nicht, auf jeder Website immer wieder Konten einzurichten. Die hier beschriebenen Systeme und Methoden sparen Entwicklern ebenso wie Benutzern all diese Energie und Belästigung.
Anstelle einer zentralen Kennung (Identifier, ID), mit der ein Benutzer sich anmeldet, und die unter Servern geteilt wird, kann der Benutzer eine Identität per Anwendung haben, und jede Webanwendung (wie Webanwendungen 111, 113, 115 und 117) kann eine eigene, einzigartige, mit ihr assoziierte pseudo-anonyme Identität besitzen, so dass es zwischen Webanwendungen kein Teilen gibt. Solcherart hat ein Benutzer nicht dieselbe Identität, die durch eine Kombination von Benutzernamen/Kennwort bestimmt und mit multiplen verschiedenen Anwendungen assoziiert wird. Diese Art der Identität einer Kombination von Benutzername/Kennwort stellt ein Problem dar, denn sobald eine Identität kompromittiert ist, hat ein Hacker oft Zugriff auf zahlreiche verschiedene Konten des Benutzers, indem er dieselbe Kombination von Benutzername/Kennwort einsetzt, da die Leute oft dasselbe Kennwort für E-Mail wie für viele ihrer anderen Finanz- oder Einkaufswebsites gebrauchen. In einem weiteren Beispiel wiederum können die selbstvervollständigenden Kapazitäten eines Browsers die E-Mail-Adresse, die Anmeldung oder das Kennwort eines Benutzers automatisch ausfüllen, doch wenn eine Website mit solchen Informationen gehackt wird, kann ein Hacker in der Lage sein, dieselben Informationen auf verschiedenen Sites einzusetzen. Die hier beschriebenen Methoden und Systeme bieten daher zusätzliche Sicherheit für Benutzeridentitäten und Benutzerinformationen online.
Weiterhin bieten die hier beschriebenen Methoden und Systeme dem Benutzer Bequemlichkeit, während sie die Sicherheit für Benutzeridentitäten online aufrechterhalten. Ein Benutzer könnte zum Beispiel bestimmte Zahlungsinformationen in ein benutzerspezifisches Identitätscache mit Informationen aufnehmen, die auf einem Client-Gerät gespeichert sind, so dass, wenn sich der Benutzer unter Einsatz einer vertrauenswürdigen Webanwendung für ein monatliches Abonnement des Online-Fernsehens entscheidet, der Browser die Webanwendung automatisch autorisieren kann (mit Berechtigung durch den Benutzer), um das Konto des Benutzers mit einer monatlichen Abonnementgebühr zu belasten, ohne dass der Benutzer komplexe Zahlungsinformationen erneut einzugeben gezwungen ist, wie zum Beispiel in ein kompliziertes Formular zur Kreditkartenautorisierung oder ein Bankleitformular.
Ein Webbrowser wie etwa Webbrowseranwendung 101, die durch ein Client-Gerät realisiert wird, kann einen Code (z. B. einen HTML-Code) von einem Fernserver (z. B. einem Fernserver, der eine Website hostet) empfangen und ist in der Lage, den Empfangscode auf dem Client-Gerät zugunsten eines Benutzers des Client-Gerätes zu realisieren.
In verschiedenen Ausführungen kann die Webanwendung 101 eine oder mehrere Webanwendungen umfassen oder mit diesen assoziiert sein (z. B. Webanwendungen 111, 113, 115 und 117). In diesem Zusammenhang kann eine „Webanwendung” für eine einzige Aufgabe oder multiple Aufgaben für den Benutzer konfiguriert sein. In einer solchen Ausführung kann die Webanwendung so konfiguriert werden, dass sie durch den Webbrowser realisiert oder interpretiert wird. Das wird verglichen mit den nativen Anwendungen, die maschinenausführbaren Code beinhalten und konfiguriert sind, um direkt von einem Prozessor oder durch das Betriebssystem des Client-Gerätes ausgeführt zu werden, wohingegen eine Webanwendung ohne die Hilfe des Webbrowsers zur Ausführung oder Anzeige unfähig sein kann. Folglich, Webanwendungen können innerhalb eines Browsers ausgeführt werden mit einem dedizierten User-Interface, und können Funktionalität und eine Erfahrung verschaffen die reichhaltiger ist und interaktiver als eine eigenständige Website aber weniger umständlich und monolithisch als eine Desktopanwendung sind. Beispiele für Webanwendungen beinhalten Spiele, Foto-Editoren und Videoplayer, die innerhalb des Browsers ausgeführt werden.
Webanwendungen könnten ”gehostete Anwendungen” oder ”verpackte Anwendungen” sein. Gehostete Anwendungen können mindestens einen Teil einer Website umfassen, die ihrerseits wiederum Webseiten enthält, zusätzlich zu einigen Metadaten, die besonders relevant für die Webanwendung oder den Benutzer der Webanwendung sind, um der Webanwendung die Implementierung einer bestimmten Funktionalität für den Benutzer zu gestatten. Gepackte Webanwendungen können als Webanwendungen angesehen werden, deren Code gebündelt ist, sodass der Nutzer den gesamten Content der Webanwendung zur Ausführung durch den Browser herunterladen kann. Eine gepackte Webanwendung benötigt u. U. keinen Netzwerkzugang, um ihre Funktionalität für den Nutzer durchzuführen, und kann stattdessen durch den Browser erfolgreich lokal auf dem Computergerät ohne Zugang zu einem Netzwerk ausgeführt werden. Verpackte Webanwendungen bieten die Option des Einsatzes von APIs (Application Programming Interface, Schnittstelle zur Anwendungsprogrammierung), was den verpackten Webanwendungen gestattet, das Verhalten oder Aussehen eines Browsers zu verändern.
In verschiedenen Ausführungen kann der Webbrowser so konfiguriert werden, dass er mit einer Anzahl an Browsererweiterungen interagiert oder diese umfasst. In diesem Zusammenhang, kann eine „Browser-Erweiterung” eine oder mehrere gepackte oder als ein definierbares Ganzes zusammengefasste Websites beinhalten, und so konfiguriert sein, dass sie die Funktionalität auf den Webbrowser ausdehnt. Solcherart bieten Erweiterungen auch zusätzliche Funktionalität für den Browser, doch hat die durch eine Erweiterung gebotene Funktionalität im Unterschied zu Anwendungen kaum eine oder keine Schnittstellenkomponente. Stattdessen dehnen Weberweiterungen die Funktionalität des Browsers und der dort eingesehenen Websites aus. Weberweiterungen können zum Beispiel die Funktionalität des Browsers durch die Hinzufügung einer neuen Taste auf der Adressleiste ausdehnen, wie etwa einen ständig sichtbaren Währungsrechner. Tasten wie diese können auch für die gegenwärtig eingesehene Website gelten; zum Beispiel kann das Anklicken der Währungsrechnertaste alle für den Benutzer auf der Website angezeigten Preise in eine vom Benutzer gewählte Währung umrechnen. In einem anderen Beispiel kann eine Erweiterung installiert sein, sodass, wenn ein Nutzer mit einem Cursor über ein Vorschaubild fährt, so lange auf einer vom Browser ausgeführten Website eine größere Version des Bildes angezeigt wird, bis der Nutzer den Cursor vom Bild wegbewegt. In einem anderen Beispiel kann eine Erweiterung installiert sein, um einen Button „Dies versenden” neben jedem Link auf jeder Seite einzubetten. Im Vergleich zu Webanwendungen sind Erweiterungen Website- und Webanwendungs-übergreifend. Erweiterungen sind gewöhnlich über alle Websites hinweg wirksam (obwohl manche Site-spezifisch sind). Webanwendungen lassen sich nicht auf diese Weise mit anderen Anwendungen kombinieren. Webanwendungen werden eher als Einzelanwendungen ausgeführt, wie jede reguläre Website.
Webbrowsererweiterungen und Anwendungen können zwecks Installation in einen auf einem Client-Rechner laufenden Browser und die Realisierung durch diesen heruntergeladen werden. Webbrowsererweiterungen und Anwendungen können Anmeldeinformationen erforderlich machen. Wenn multiple Erweiterungen oder Anwendungen in Gebrauch sind, kann es für einen Benutzer schwer sein, solche Anmelde- oder Identitätsinformationen für jede Webanwendung erneut einzugeben. Systeme und Methoden, die mit bestimmten Ausführungen in Einklang stehen, helfen bei der Bereitstellung benutzerspezifischer Identitätsinformationen für installierte Webanwendungen (zum Beispiel unter Einsatz kryptographischer Schlüsselpaare), so dass der Benutzer solche Informationen nicht jedes Mal beim Zugriff auf die Webanwendung erneut eingeben muss. Sobald die Webanwendung installiert und mit dem Schlüsselpaar identifiziert ist, kann sich ein Benutzer in Kombination mit Synchronisierungsfähigkeiten von jedem Gerät auf einem Browser anmelden und die Webanwendung nutzen, ohne für diese die Anmeldedaten erneut einzugeben.
1B ist eine Benutzerschnittstelle, die eine exemplarische Webanwendung illustriert. Die Webanwendung ist in Tab 102 eines Webbrowsers implementiert. In dem in 1B gezeigten Beispiel hat ein Benutzer Tab 102 des Webbrowsers zu einem digitalen Marktplatz oder Webshop navigiert. Der digitale Marktplatz oder Webshop kann ein Standort im Internet sein, der über die Browseranwendung zugänglich wird, von der ein Benutzer Anwendungen herunterladen kann, wie etwa Webanwendungen und Browsererweiterungen, die als Teil der Browseranwendung integriert sind.
In 1B hat der Benutzer Tab 102 zu einem Webshop 104 navigiert, und genauer zu einer Seite des Webshops, die Informationen über eine durch Maps installierbare Webapplikation 106 anzeigt. In diesem Beispiel von Benutzerschnittstelle 100 umfasst die Browseranwendung eine Beschreibung der installierbaren Webanwendung in einem Beschreibungsfeld 108. Das Beschreibungsfeld 108 kann Informationen über die Funktionalität und Fähigkeiten der speziellen Webanwendung liefern. In einer Ausführung kann die Navigation der Browseranwendung zu einer spezifischen Webanwendung innerhalb des Marktplatzes als Aufforderung betrachtet werden, die Webanwendung auf dem Browser eines Geräts zu installieren, auf dem die Browseranwendung läuft. Zum Beispiel kann die Navigation des Benutzers zu der bestimmten Website, die auf 1B illustriert ist, eine Aufforderung anzeigen, die Maps-Webanwendung 106 in der Browseranwendung auf einem Gerät zu installieren, auf dem der Browser läuft. In einigen Ausführungen jedoch kann die Webanwendung nicht tatsächlich installiert werden, bis die Bestätigung durch den Benutzer erhalten wird.
1B illustriert auch ein Mitteilungsfeld 110, das mindestens eine Berechtigung umfasst, die mit dieser Webanwendung assoziiert ist. Das Mitteilungsfeld 110 identifiziert mindestens eine Berechtigung, welche die angegebenen Berechtigungen anzeigt, die von der Webanwendung benutzt werden können. In diesem Beispiel zeigt die Maps-Webanwendung 106 die angegebene Berechtigung an, dass diese bestimmte Anwendung auf den physischen Standort eines Benutzers der Anwendung zugreifen kann. Das Mitteilungsfeld 110 macht dem Benutzer bei der Installation in der Browseranwendung spezifische Mitteilung zu den Berechtigungen, die diese Anwendung nutzen darf. Durch die Bereitstellung der Mitteilung zu den Berechtigungen zur Zeit der Installation der Anwendung kann der Benutzer entweder implizit oder ausdrücklich diese Berechtigungen bestätigen, indem er beschließt, die Installation der Anwendung fortzusetzen. Die Wahl einer Installationstaste 112 zum Beispiel zeigt eine Bestätigung für die Installation der Webanwendung an, wobei die Bestätigung die Erteilung der Berechtigung umfasst. Bei der Wahl der Installationstaste 112 wird die Webanwendung in der Browseranwendung installiert, um die erteilte Berechtigung für den Einsatz durch die Webanwendung zu aktivieren.
Die Berechtigungen können eine Angabe des Zugriffs sein, den die Webanwendung oder Erweiterungsanwendung auf die benutzerspezifischen Identitätsinformationen wünscht (z. B. Name, E-Mail-Adresse, Foto, Avatar, Standort, Alter, Zahlungsinformationen usw.), geräteseitige Informationen, clientbezogene Informationen oder serverseitige Informationen, wie etwa Informationen, die mit einem Benutzer oder Gerät assoziiert sind. Während das obige Beispiel eine einzige Berechtigung demonstriert, können multiple Berechtigungen angegeben und durch den Benutzer als Teil des Installationsvorgangs für die Anwendung erteilt werden. Auf diese Weise geben die Entwickler von Webanwendungen und Erweiterungsanwendungen die gewünschten Berechtigungen und assoziieren die angegebenen Berechtigungen als Teil der Webanwendung. Dies informiert den Benutzer über den Zugriff, der möglicherweise auf spezifische Informationen im Verlauf der Lebensdauer der Anwendung verlangt wird, während sie in der Browseranwendung eines durch den Benutzer kontrollierten Client-Gerätes in Gebrauch ist.
In einer exemplarischen Ausführung ist die Browseranwendung 102 konfiguriert, um die mit der Anwendung assoziierten Berechtigungen durchzusetzen. Auf diese Weise bietet die Browseranwendung einen Mechanismus zur Einschränkung oder Begrenzung der Anwendung auf nur diejenigen Berechtigungen, die vom Entwickler zur Zeit der Installation angegeben und zugelassen wurden. Auf diese Weise kann der Zugriff auf die Funktionalität der Browseranwendung und auf die Informationen auf der Seite des Client-Gerätes sowie auf andere Informationen auf die angegebenen Berechtigungen beschränkt werden, die zur Zeit der Installation ausdrücklich durch den Benutzer bestätigt wurden.
In einer exemplarischen Ausführung kann eine einzige angegebene Berechtigung eine Ansammlung von mehr als einer Berechtigung repräsentieren. Zum Beispiel bedeutet eine angegebene Berechtigung von „Ihr physischer Standort”, dass die Webanwendung auf die geräteseitigen Informationen zugreifen darf, die sich auf den physischen Standort des Benutzers beziehen, darunter auch Informationen zur Ortsbestimmung. Dies kann auch ein bestimmtes Risikoniveau repräsentieren und mit anderen standortmäßigen Informationen in dieser einzelnen Berechtigung gebündelt werden. Auf diese Weise wird eine einzelne Berechtigung, die multiple ähnliche Arten von angegebenen Berechtigungen repräsentiert, in einer einzigen Gruppe gebündelt, so dass der Benutzer keine komplexen Sicherheitsfragen beantworten muss, die seinen normalen Arbeitsfluss unterbrechen. Der Benutzer kann einfach eine vorherige Vertrauenseinschätzung vornehmen, die später jederzeit widerrufen werden kann. Wenn der Benutzer zum Beispiel nicht länger wünscht, der Anwendung die Berechtigungen zu erteilen, kann er die Anwendung einfach deinstallieren. Andere Optionen können den selektiven Widerruf einzelner Berechtigungen umfassen, darunter auch Berechtigungen, die eine Sammelberechtigung darstellen. Wenn der Benutzer Berechtigungen widerruft, ohne die Anwendung zu deinstallieren, kann ein Teil der Funktionalität oder die gesamte Funktionalität herabgesetzt werden. Wenn ein Benutzer zum Beispiel die Berechtigung einer Anwendung für den Zugriff auf benutzerspezifische Identitätsinformationen wie etwa einen Avatar widerruft, kann es sein, dass die Webanwendung den Avatar des Benutzers nicht länger anzeigt.
Es ist möglich, dass eine Webseite, die in einer Browseranwendung operiert, um Berechtigung vom Benutzer nachsuchen muss, bevor sie relativ harmlose Aufgaben durchführt, wie etwa die Anzeige von Mitteilungen, den Einsatz der Zwischenablage oder den Zugriff auf permanente Speicherung. Jedes Mal, wenn die Webseite eine dieser Aufgaben durchführen will, kann sie unterbrechen und den Benutzer auffordern, eine Berechtigung zu erteilen. Dies kann für den Benutzer lästig sein und seine Benutzererfahrung für zufällig besuchte Webseiten herabsetzen, auf die jedes Mal gestolpert wird, wenn der Zugriff auf den Desktop oder auf Desktop-Mitteilungen gefordert wird. Wie oben besprochen, kann die in der Browseranwendung installierte Webanwendung oder Erweiterungsanwendung alle Berechtigungen erteilen, die gebraucht und gewünscht werden, und die von der Anwendung zur Zeit der Installation angegeben wurden. Die erteilten Berechtigungen können in Assoziation mit der Anwendung und dem Benutzer, der die Anwendung installiert hat, entweder lokal oder ferngespeichert werden. Da die Berechtigungen gespeichert wurden, muss der Benutzer dann die Berechtigungen nicht jedes Mal erneut erteilen, wenn er die Webanwendung starten und betreiben will.
Zahlreiche verschiedene Arten von Berechtigungen können von einem Entwickler als Teil der Anwendung angegeben werden, die in einem Browser installiert und betrieben werden soll, der auf einem Client-Gerät läuft. Berechtigungen können zum Beispiel eine Zugriffsberechtigung für die Webanwendung auf die Bookmarks eines Benutzers umfassen, des Weiteren eine Zugriffsberechtigung für die Webanwendung auf die Webbrowser-Historie eines Benutzers, eine Berechtigung für die Webanwendung für den Zugriff auf den geologischen Standort eines Benutzers oder die Bestimmung desselben, eine Zugriffsberechtigung für die Webanwendung auf die URLs oder die Informationen in offenen Tabs des Browsers, eine Berechtigung für die Webanwendung für die Nutzung unbegrenzter lokaler Speicherressourcen auf dem Client-Gerät, eine Berechtigung für die Webanwendung, Informationen aus dem Client-Gerät zu kopieren und einzufügen, eine Berechtigung für den Zugriff auf lokale Dateien auf dem Client-Gerät, das die Webanwendung realisiert, eine Berechtigung festzustellen, wenn die Webanwendung inaktiv ist, eine Berechtigung für die Webanwendung, auf dem Client-Gerät native Codes laufen zu lassen, eine Berechtigung für die Webanwendung, auf die Kennwortinformationen des Benutzers zuzugreifen oder diese zu speichern, eine Zugriffsberechtigung für die Webanwendung auf die lokale Hardware des Client-Gerätes. Die Zugriffsberechtigungen auf Hardware können den Zugriff auf Informationen und/oder Geräte selbst umfassen, darunter auch für den Zugriff auf die Peripherie, den Leistungsstatus, den Batteriestatus oder den Zugriff auf andere ähnliche Hardware-Geräte und verbundene Informationen.
Andere Beispiele für angegebene Berechtigungen umfassen Berechtigungen für Kontextmenüs, Cookies und Management. Ein Übereinstimmungsmuster spezifiziert eine Host-Berechtigung. Ein Übereinstimmungsmuster kann eingesetzt werden, wenn die Erweiterungsanwendung oder Webanwendung mit dem auf den Seiten laufenden Code interagieren will. Zahlreiche Erweiterungsfähigkeiten, wie etwa ein Cross-Origin-XML-http-Request, injizieren programmatisch Inhaltsskripte, und die Cookies-API erfordern Host-Berechtigungen.
In einigen Ausführungsformen, Anwendungen oder Erweiterungen, die eine Schnittstelle mit browserbezogenen Schnittstellen der Anwendungsprogrammierung (APIs) haben, können Berechtigungen einsetzen, die von einer spezifischen API benötigt werden. Eine API kann zum Beispiel den Einsatz des Zugriffs auf die Historie der Browseranwendung erfordern. Wenn die Berechtigung für die Historie erteilt wird, kann die Webanwendung nach der Installation auf die Browser-Historie zugreifen, ohne erneut eine Berechtigung zu beantragen, und ohne den Benutzer erneut aufzufordern.
Die Berechtigung für Bookmarks kann eingesetzt werden, wenn die Webanwendung oder Erweiterungsanwendung die Bookmarks der Browseranwendung und das Modul der Bookmarks dort einsetzt, wo die mit der Browseranwendung verbundenen Bookmarks sich befinden. Die Berechtigung zur Ortsbestimmung kann eingesetzt werden, wenn die Anwendung oder Erweiterung eine API zu benutzen erwartet, ohne den Benutzer zur Berechtigung aufzufordern. Die Ortsbestimmung kann zum Beispiel mit der vorgeschlagenen API der Ortsbestimmung in Hypertext Markup Language (HTML) 1 verbunden sein. Die Berechtigung für Mitteilungen kann mit der vorgeschlagenen API für Mitteilungen in HTML5 verbunden sein, ohne die Notwendigkeit, andere Berechtigungen zu brauchen oder einzusetzen, wie etwa von HTML5 benötigt werden kann. Die Berechtigung für Tabs kann von einer Anwendung oder Erweiterung eingesetzt werden, wenn auf andere, mit der Browseranwendung verbundene Tabs oder Fenster zugegriffen werden muss.
Die Berechtigung für unbegrenzte Webspeicherung kann von der Webanwendung oder Erweiterung eingesetzt werden, um ein unbegrenztes Pensum von clientseitigen Daten zu speichern, wie etwa Datenbanken und lokale Speicherdateien. Auf diese Weise wird jeder benötigte oder gewünschte Speicherraum von der Webanwendung genutzt. Ohne Erhalt dieser Berechtigung könnte die Anwendung oder Erweiterung auf einen bestimmten Umfang der lokalen Speicherung beschränkt sein, wie zum Beispiel etwa fünf Megabytes der lokalen Speicherung.
Die Berechtigung für den Cross-Origin-XML-HttpRequest kann eingesetzt werden, um eine Webanwendung oder eine Erweiterungsanwendung zu aktivieren, um Zugriff auf Fernserver außerhalb seiner Ursprungsadresse anzufordern. Zum Beispiel können Werte der Cross-Origin-Berechtigung voll qualifizierte Host-Namen sein, wie zum Beispiel etwa „http://www.google.com/” oder ”http://www.gmail.com/”. In einem weiteren Beispiel können die Werte der Cross-Origin-Berechtigung Übereinstimmungsmuster wie zum Beispiel ”code.google.com/chrome/.../xhr.html” oder „http://*.google.com/” or http://*/ sein. Ein Übereinstimmungsmuster wie „http://*/” allows http” gestattet Zugriff auf alle erreichbaren Domänen. Wenn eine Anwendung sowohl gesicherten als auch ungesicherten HTTP-Zugriff auf einen bestimmten Host oder einen Satz von Hosts wünscht, dann können diese Berechtigungen in der Manifestdatei separat erteilt werden.
In einer exemplarischen Ausführung kann die Benutzerschnittstelle 100, die in 1 illustriert ist, die einzige Seite sein, die präsentiert wird, um dem Benutzer die Bestätigung der Installation der Anwendung zu gestatten und eine implizierte Erlaubnis der Berechtigungsliste im Mitteilungsfeld 110 zu bieten. In anderen Ausführungen kann die Wahl der Installationstaste 112 eine zusätzliche Bestätigung und Mitteilung zur Einsicht und Auswahl des Benutzers fordern.
2 ist ein Diagramm einer Benutzerschnittstelle, das ein exemplarisches Mitteilungsfenster im Zusammenhang mit einer Webanwendung illustriert. Wie in der Benutzerschnittstelle 200 gezeigt, kann das Mitteilungsfenster 202 den Benutzer auffordern, die Installation einer gewünschten Webanwendung zu bestätigen. In diesem Beispiel wird der Benutzer zu einer endgültigen Bestätigung für die Installation der Maps-Web-Anwendung 106 in der Browseranwendung 102 aufgefordert. Das Mitteilungsfenster 202 kann ein Berechtigungsfeld 204 enthalten, das die angeforderten und gewünschten Berechtigungen für den Einsatz durch die Webanwendung auflistet, die installiert wird. In diesem Beispiel umfasst das Mitteilungsfenster 202 mehr als eine Berechtigung im Berechtigungsfeld 204. Zum Beispiel sind die Berechtigung „Ihr physischer Standort” und die Berechtigung „Identität” im Berechtigungsfeld 204 aufgelistet. Die Identitätsberechtigung kann zum Beispiel alle benutzerspezifischen Identitätsinformationen enthalten, die ein Benutzer in das Identitätsprofil eines Browsers aufgenommen hat (zum Beispiel Name, Foto, Alter, Standort, Avatar, E-Mail-Adresse, Zahlungsinformationen usw.). In einigen Ausführungen jedoch können andere Berechtigungen eingesetzt werden, so dass der Zugriff einer Webanwendung auf eine Identitätsberechtigung nur teilweise erfolgt, zum Beispiel auf der Grundlage einer Liste der Zugriffskontrolle (z. B. eine Berechtigung der „Namensidentität” kann benutzt werden, um nur dem Anmeldenamen eines Benutzers Zugriff auf eine Kreditkarte des Benutzers zu gewähren). In anderen Ausführungen kann eine übergreifende Identitätsberechtigung eingesetzt werden, um jegliche oder alle Identitätsinformationen, die ein Benutzer in ein Browserprofil aufgenommen hat, miteinzubeziehen.
In einigen Fällen kann der Zugriff auf Informationen anders neu gekennzeichnet sein, als der aufgelistete, mit einer API assoziierte Name, der einen spezifischen Zugriff benötigt. Zum Beispiel kann die API Zugriff auf die Berechtigung zur Ortsbestimmung zuweisen, doch kann das Mitteilungsfenster Ortsbestimmungsinformationen neu formulieren, um sie benutzerfreundlicher und verständlicher zu machen und sie als „Ihr physischer Standort” neu formulieren, um es deutlich zu machen, dass die Anwendung auf den physischen Standort der Browseranwendung und das Gerät, auf dem er betrieben wird, zugreifen wird, von dem angenommen wird, dass es sich bei dem Benutzer befindet. Auf diese Weise erfolgt zur Zeit der Installation gegenüber dem Benutzer eine vollständige Offenlegung. Sollte der Benutzer beschließen, keinen Zugriff auf diese Information zu gewähren, kann er die Installation einfach stornieren, und der Zugriff auf die Berechtigungen wird der Webanwendung verweigert. In einigen Ausführungen können Benutzer einen bestimmten Zugriff selektiv gewähren und ihn anderweitig verweigern. Zum Beispiel kann ein Benutzer einer Webanwendung Zugriff auf bestimmte, benutzerspezifische Informationen gewähren (z. B. Name, E-Mail-Adresse), auf andere jedoch nicht (Alter, Standort).
Bei Erhalt der Bestätigung, die Webanwendung zu installieren, kann die Webanwendung in der Browseranwendung installiert werden, und die angegebenen Berechtigungen werden aktiviert. Wenn ein Benutzer zum Beispiel die Installationstaste 206 wählt, erhält die Browseranwendung 102 eine Bestätigung, die Webanwendung zu installieren, wobei die Bestätigung die Gewährung der im Berechtigungsfeld 204 aufgelisteten Berechtigungen umfassen kann. Das Berechtigungsfeld 204 kann auch andere Informationen umfassen, die in den Metadaten enthalten sind, die mit der Webanwendung assoziiert sind (zum Beispiel Rezensionen, Bewertungen, eine Anzahl von Benutzern, die die Anwendung heruntergeladen haben, Sicherheitsangelegenheiten, Warnhinweise usw.).
3 ist das Beispiel einer Manifestdatei im Zusammenhang mit einer Webanwendung oder Erweiterung. Die Manifestdatei 300 kann ein oder mehrere Felder enthalten, die mit der Anwendung verbundene Informationen spezifizieren. Eines der Felder kann ein Berechtigungsfeld 302 enthalten. In dem Berechtigungsfeld 302 spezifiziert ein Entwickler die angegebenen Berechtigungen, die von der Anwendung benutzt werden können. In diesem Beispiel umfassen die angegebenen Berechtigungen auch Berechtigungen zur unbegrenzten Speicherung 304, Mitteilungen 306 und Identitätsberechtigung 308. Wenn keine Berechtigungen angegeben sind, kann das Berechtigungsfeld aus der Manifestdatei 300 weggelassen werden. In anderen Beispielen können in dem Berechtigungsfeld 302 multiple Berechtigungen angegeben werden. Die Manifestdatei 300 ist mit der Anwendung assoziiert und Teil der Anweisungen, die auf dem Marktplatz hochgeladen werden. Das Mitteilungsfenster 202 und/oder das Mitteilungsfeld 110, das die angegebenen Berechtigungen auflistet, kann die Manifestdatei 300 und das Berechtigungsfeld lesen, um diese Fenster auszufüllen.
Die Entwickler von Webanwendungen können die Identitätsberechtigung 308 für den vom Benutzer genehmigten Zugriff auf bestimmte Identitätsinformationen für eine Webanwendung nutzen (wie etwa eine Benutzeridentifizierung bei der Anmeldung, ein Avatar oder bei einigen Ausführungen finanzielle Zahlungsinformationen, wie etwa Kreditkartennummer oder andere benutzerspezifische Informationen). Indem er das tut, kann der Entwickler der Webanwendung vermeiden, dass der Benutzer Kreditkarteninformationen oder Anmeldeinformationen beim ersten Mal oder jedes Mal, wenn der Benutzer die Webanwendung nutzt, erneut eingeben muss. Wenn ein Entwickler die Identitätsberechtigung 308 in einer Webanwendung einsetzt, kann der Browser den Benutzer benachrichtigen, dass die Webanwendung Zugriff auf mindestens einen Teil der Identitätsinformationen des Benutzers haben wird, wie zum Beispiel oben beschrieben im Hinblick auf 1B und 2, wenn der Benutzer etwa die Webanwendung installiert.
Für den Einsatz der Identitätsberechtigung 308 können Entwickler von Webanwendungen ein Verfahren der Signaturbestätigung einsetzen, wie ausführlicher unten beschrieben im Hinblick auf 5A und 5B. Clientseitige APIs können gemeinsam mit einem gesicherten Mechanismus wie die Signaturbestätigung, wie beschrieben in 5B, von Webanwendungen eingesetzt werden, um Einzelheiten zur Benutzeridentität zu erlangen, wie etwa Name, E-Mail-Adresse, Avatar usw. Eine Webanwendung kann zum Beispiel eine Berechtigung für die „Identität” in einer Manifestdatei umfassen, wie beschrieben in 3 und kann JAVASCRIPT API-Anrufe tätigen, um auf die Identitätsinformationen eines Benutzers zuzugreifen. In einigen Ausführungen können HTTP Response Header in der Lage sein, diese Einzelheiten der Benutzeridentität von einem Fernserver zu senden, solange der Benutzer der Webanwendung die entsprechenden Berechtigungen erteilt hat.
Die Identitätsinformationen des Benutzers können bei einigen Ausführungen mit einem Benutzerkonto für einen Webbrowser, einem Benutzerkonto für ein E-Mail-Programm, einem Benutzerkonto für ein Kalenderprogramm oder einem Single-Sign-On Programm datenassoziiert sein, das für einen Webbrowser, ein E-Mail-Programm, ein Kalender-Programm, einen Satz von Webanwendungen usw. genutzt werden kann.
In einigen Fällen kann der Entwickler einer Webanwendung wünschen, weitere Berechtigungen hinzuzufügen, um auf andere geräteseitige Informationen zuzugreifen, die nicht ursprünglich zur Zeit der Installation der Anwendung angegeben wurden. Dies kann als Teil einer Aktualisierung der Webanwendung oder Erweiterung erfolgen oder über den Shop verfügbar gemacht werden, aus dem die Webanwendung oder Erweiterung über die Browseranwendung heruntergeladen wurde.
Die Browseranwendung 102 kann konfiguriert werden, um eine oder mehrere Berechtigungen einzuschränken, die mit einer oder mehreren installierten Webanwendungen assoziiert ist/sind. Wenn zum Beispiel eine bestimmte Berechtigung als zu riskant betrachtet wird oder den Zugriff von Malware ermöglichen könnte, kann sie weiter eingeschränkt werden, und alle bestehenden Erweiterungsanwendungen und Webanwendungen können automatisch eingeschränkt werden, wenn der Browser aktualisiert wird. Wenn zum Beispiel nach einer Freigabe beschlossen wird, dass eine bestimmte Datei nicht nützlich oder zu gefährlich war, dann kann die Berechtigung geändert werden, um zu verlangen, dass Endbenutzer ausdrücklich eine Opt-In-Erklärung abgeben, um die Webanwendung oder Erweiterungsanwendung zur Nutzung dieser Funktion zu ermächtigen.
In einer exemplarischen Ausführung können optionale Berechtigungen von Entwicklern eingesetzt und im Manifest angegeben werden. Dies gestattet Entwicklern, eine Liste von Berechtigungen zu erstellen, die für den normalen Einsatz der Webanwendung nicht unbedingt erforderlich sind. Wenn der Entwickler entscheidet, dass die Benutzung einer dieser Berechtigungen gewünscht wird, kann diese auf Verlangen aufgerufen werden, wodurch sie dann der Liste der Berechtigungen hinzugefügt wird, die der Erweiterung oder Webanwendung erteilt werden. Das kann gegenüber einigen der erforderlichen Berechtigungen die nachstehend aufgeführten zusätzlichen Vorteile zu Folge haben. Wenn eine Erweiterung zum Beispiel eine riskantere Funktion einsetzen will, die wahrscheinlich nur für eine kleine Gruppe von Intensivnutzern zweckdienlich ist, kann sie die Berechtigung optional gestalten und damit nicht alle Benutzer zwingen, ihr den Zugriff auf eine potentiell gefährliche Fähigkeit zu gestatten, der sie möglicherweise nicht vertrauen. Optionale Berechtigungen können auch im Manifest aufgelistet und als solche gekennzeichnet werden. Es kann sein, dass die optionalen Berechtigungen zur Zeit der Installation nicht in den Mitteilungsfenstern erscheinen, da sie optional sind. Die optionalen Berechtigungen können nur auf Aufforderung nach der Installation der Anwendung Zugriff verlangen, zu der Zeit, da Zugriff verlangt wird. Der Benutzer erhält die Option, die optionale Berechtigung zu dem Zeitpunkt, da sie verlangt wird, zu erteilen oder zu verweigern. Wenn der Benutzer die Berechtigung verweigert, dann kann die Berechtigung nicht auf die gewünschten gerätebezogenen Informationen zugreifen. Wenn die Berechtigung durch den Benutzer erteilt wird, dann kann die Erweiterung oder Anwendung auf die gewünschten Informationen zugreifen. Wenn mehr als eine Version der Webanwendung oder Erweiterungsanwendung existiert, mag ein Entwickler eine Funktion in einer Version, jedoch nicht in anderen Versionen nutzen. Optionale Berechtigungen können eingesetzt werden, um Funktionen in eine Version aufzunehmen, die in andere Versionen nicht mit aufgenommen werden. Durch die Auflistung als eine optionale Berechtigung kann die Berechtigung nur Benutzern des Browsers angezeigt werden, welche die Funktion haben, wodurch dem Entwickler das Experimentieren mit der neuen Funktion gestattet wird, während gleichzeitig existierenden Benutzern keine Probleme entstehen und sie nicht unterbrochen werden.
In bestimmten Ausführungen kann eine Erweiterung einen Identitätsservice bieten, so dass benutzerspezifische Identitätsinformationen in Verbindung mit dem Browser gespeichert werden können und dann automatisch Webanwendungen zur Verfügung gestellt werden, die die Zugriffsberechtigung für die benutzerspezifischen Identitätsinformationen haben. Auf diese Weise kann der Benutzer einer Webanwendung eine Berechtigung für einen einmaligen Zugriff auf solche benutzerspezifischen Identitätsinformationen erteilen und mag dann beim zukünftigen Einsatz der Webanwendung die Bereitstellung solcher Identitätsinformationen nicht mehr manuell erledigen oder ihre Bereitstellung autorisieren müssen. So kann ein Benutzer benutzerspezifische Identitätsinformationen speichern und dann zulassen, dass die Informationen von bestimmten Webanwendungen genutzt werden, welche die Berechtigung für den Zugriff auf die Informationen erhalten haben, jedoch nicht zulassen, dass die Informationen von anderen Websites oder Webanwendungen genutzt werden, die keine ausdrückliche Berechtigung für den Zugriff auf die benutzerspezifischen Identitätsinformationen haben. Auf diese Weise kann das hybride Vertrauensmodell einer Webanwendung zum Vorteil des Benutzers eingesetzt werden, denn es kann sein, dass der Benutzer seine benutzerspezifischen Identitätsinformationen nicht auf jeder Website teilen will, die er zufällig besucht, es jedoch für vorteilhaft hält, solche Informationen leicht an Webanwendungen liefern zu können, die installiert sind. In bestimmten Ausführungen kann der Benutzer solche Informationen an alle Webanwendungen liefern, zu denen ein größeres Vertrauen besteht, da sie über einen spezifischen digitalen Marktplatz oder Webshop installiert wurden (z. B. von einem vertrauenswürdigen Unternehmen geliefert wurden), sie von anderen Benutzern erfolgreich eingesetzt und bestätigt oder bis zu einem gewissen Grad von dem Betreiber des Webshops bestätigt wurden.
4 ist ein schematisches Blockdiagramm für das Beispiel eines Browseridentitätssystems. Unter Einsatz von System 400 können benutzerspezifische Identitätsinformationen in Verbindung mit einem Browser gespeichert und an ausgewählte Webanwendungen geleitet werden, die eine Zugriffsberechtigung für die benutzerspezifischen Identitätsinformationen haben, so dass die gewählten Webanwendungen dem Benutzer eine benutzerspezifische Erfahrung der Webanwendung bieten können. In verschiedenen Ausführungen kann System 400 Client-Rechner (z. B. Desktop-Rechner, Notebooks, Netbooks, Tablets, Smartphones usw.) 402A, 402B, 402C umfassen. Ein Client-Rechner 402A kann einen oder mehrere Prozessoren 404 und einen oder mehrere Speicher 406 umfassen. Der Client-Rechner 402A kann ein Betriebssystem 408 und eine Anwendung 410 betreiben, die das Fenster einer Benutzerschnittstelle 412 anzeigen kann. Der Client-Rechner 402A kann eine Installationsmaschine 420 umfassen, die einen Code für eine Webanwendung empfangen kann, die auf dem Client-Gerät 402A von einem Server betrieben werden soll und kann den Code auf dem Client-Gerät installieren, so dass die Anwendung vom Gerät realisiert werden kann.
In einer Ausführung kann der Client-Rechner 402A laufen oder das Betriebssystem 408 veranlassen, eine Anwendung 410 oder ein Fenster 412 zu realisieren. Zu Zwecken der Illustration wird das Fenster 412 als ein Webbrowser bezeichnet. Es wird jedoch davon ausgegangen, dass die obige Darstellung lediglich ein illustratives Beispiel ist, auf das die offengelegte Thematik nicht beschränkt ist. In verschiedenen Ausführungen kann dieses Fenster 412 eine Vielzahl von Bereichen oder Tabs 414A, 414B, 414C umfassen Das Fenster 412 kann ein visueller Bereich sein, der eine Benutzerschnittstelle umfasst. In einer in dem Client-Gerät 402A eingesetzten graphischen Benutzerschnittstelle (Graphic User Interface, GUI) kann das Fenster 412 ein zweidimensionales Objekt sein, das auf einer Ebene der GUI arrangiert ist, die als Desktop bekannt ist. Das Fenster 412 kann andere graphische Objekte enthalten, z. B. eine Menüleiste, Symbolleisten, Kontrollen, Symbole und normalerweise einen Arbeitsbereich, indem ein Dokument, Bilder, Dateiinhalte oder andere größere Objekte angezeigt werden können. Der Arbeitsbereich kann fähig sein, mehr als ein größeres Objekt (z. B. in einer einzelnen Dokumentenschnittstelle) oder mehr als ein größeres Objekt in einer multiplen Dokumentenschnittstelle aufzunehmen. In einigen Anwendungen, insbesondere bei Webbrowsern, können multiple Dokumente in individuellen Tabs 414A, 414B und 414C angezeigt werden. Diese Tabs 414A, 414B, 414C können jeweils einzeln nacheinander angezeigt und über eine Tab-Leiste wählbar sein, die sich oft oberhalb der Inhalte eines individuellen Fensters befindet. Das bedeutet, dass ein gewählter Tab 414A „nach vorn weist” und einem Benutzer in dem Fenster 412 Informationen oder Inhalte anzeigt, während der Inhalt der anderen Tabs 414B, 414C ”verborgen” bleibt.
Die Client-Rechner 402A, 402B und 402C können Online-Inhalte von einem oder mehreren Server-Rechnern 430, 442, 450 und 470 empfangen, die mit dem Client-Gerät 402 über ein Netzwerk 490 verbunden sein können. Jeder der Client-Rechner 402A, 402B, 402C kann mit dem Netzwerk 490 über einen lokalen Internetdienstleister 492 verbunden sein. Der empfangene Online-Inhalt kann verarbeitet und in dem Fenster 412 angezeigt werden (z. B. in einem Tab 414 des Fensters 412).
In einigen Ausführungen können ein oder mehrere Client-Rechner 402A, 402B, 402C so konfiguriert werden, dass ein Webbrowser (wie Anwendung 410) das Betriebssystem des Client-Gerätes betreibt, und es kann sein, dass der Client-Rechner keine weiteren Anwendungen umfasst. In einer solchen Ausführung kann die Anwendung 410 eher als ein mit Tabs versehener Fenstermanager oder als Web-Shell operieren, als eine standardmäßige Browseranwendung. Ein Tab (z. B. Tab 414A) in dem tabulierten Fenstermanager kann auf ähnliche Weise operieren wie die Titelleiste einer Desktop-Anwendung. Ein Rahmen (z. B. wie Fenster 412), der die Tabs enthält, kann als nützlicher Mechanismus für die Handhabung von Anwendungsgruppen dienen. In einigen Ausführungen kann es andere Arten von Tabs geben, die keine Browser-Funktionsleiste hosten. Durch die Kombination von Webanwendungen und standardmäßigen Webseiten in minimalen Tab-Streifen kann die Benutzerschnittstelle des tabulierten Fenstermanagers so wenig wie möglich der Bildschirmfläche nutzen. Während existierende Betriebssysteme Web-Tabs und native Anwendungen in zwei separaten Streifen haben können, kann der tabulierte Fenstermanager diese kombinieren und damit Zugriff auf alles von einem Streifen aus gewähren.
Der Client-Rechner 402A kann mit einem Marktplatz-Server 450 für Webanwendungen und Erweiterungen kommunizieren, der den Client-Rechnern 402A, 402B, 402C einen Marktplatz für Webanwendungen und Erweiterungen bietet. Der Marktplatz-Server 450 kann einen oder mehrere Prozessoren 452 sowie einen oder mehrere Speicher 454 umfassen. Der Marktplatz-Server 450 kann ein Betriebssystem 456 und verschiedene Anwendungen und Dienstleistungen realisieren, um den Client-Rechnern Funktionalität zu bieten. In einer Ausführung zum Beispiel kann der Marktplatz-Server 450 eine Ablage für den Datenbestand von Webanwendungen und Erweiterungen 458 umfassen, und die Webanwendungen und Erweiterungen können von der Ablage an die Client-Rechner geliefert oder darauf heruntergeladen werden. In einer anderen Anwendung können die Webanwendungen und Erweiterungen in einer Ablage gespeichert und von dort an die Client-Rechner geliefert werden, deren Standort vom Marktplatz-Server entfernt ist. Webanwendungen und Erweiterungen könnten zum Beispiel in einzelnen Ablagen, die von Entwicklern von Webanwendungen und Erweiterungen betrieben und kontrolliert werden, gespeichert und von dort an die Client-Rechner geliefert werden, und die Ablage 458 für Webanwendungen und Erweiterungen des Marktplatz-Servers 450 kann lediglich einen Verweis auf die einzelnen, von den Entwicklern betriebenen Ablagen liefern.
Wenn die Webanwendung oder Erweiterung, zum Beispiel eine verpackte Webanwendung, die offline betrieben werden kann (d. h. lokal mit dem Client-Gerät 402A, ohne Zugriff auf das Netzwerk 490), von dem Marktplatz-Server 450 auf das Client-Gerät 402A heruntergeladen wird, kann die Installationsmaschine 420 die heruntergeladene Webanwendung oder Erweiterung empfangen und diese zwecks Realisierung auf dem Client-Gerät installieren. Die Installationsmaschine kann zum Beispiel Anwendungsprogrammierschnittstellen für Browsererweiterungen (APIs) einsetzen, um die Webanwendung in den Browser zu integrieren, so dass die Webanwendung nahtlos innerhalb der Browseranwendung 410 gestartet werden kann. Gehostete Webanwendungen, die online betrieben werden können, die z. B. von einem Online-Server gehostet werden, der die Anwendung realisiert und das Client-Gerät 402A über das Netzwerk 490 mit Inhalten für die Präsentation gegenüber dem Benutzer beliefert, können ebenfalls mit dem Browser installiert werden, indem der gehosteten Webanwendung zunehmende Berechtigungen für lokale Ressourcen auf dem Client-Gerät erteilt werden. Die Installation der gehosteten Anwendung kann zum Beispiel die Erteilung einer Berechtigung an die gehostete Anwendung für den Einsatz von unbegrenzter lokaler Speicherung auf dem Client-Gerät 402A oder den Zugriff auf die Browser-Historie, die Bookmarks usw. des Benutzers umfassen, die auf dem Client-Gerät 402A gespeichert sind. Solche Berechtigungen können als Teil des Installationsvorgangs für die gehostete Webanwendung gespeichert werden, so dass der Benutzer diese Berechtigungen nicht jedes Mal erneut erteilen muss, wenn die gehostete Webanwendung genutzt wird.
Das System 400 kann einen Entwickler-Client 442 umfassen, mit dem ein Entwickler Anwendungen oder Erweiterungen oder andere Webanwendungen und Erweiterungen entwickeln kann, die zu dem Marktplatz-Server 450 zur Präsentation im Marktplatz-Server hochgeladen werden können. Der Entwickler-Client 442 kann einen oder mehrere Prozessoren 443, einen oder mehrere Speicher 445 für die Speicherung von Daten, wie zum Beispiel ausführbare Anweisungen und/oder Inhalte, ein Betriebssystem 444 und eine oder mehrere Anwendungen 446 umfassen, die von einem Entwickler realisiert werden können, um verschiedene Aufgaben auszuführen, wie zum Beispiel die Entwicklung von Webanwendungen und Erweiterungen zur Präsentation auf dem Marktplatz, den Erhalt von Zahlungen von dem Marktplatz-Server 450 usw.
Wie in 4 dargestellt, kann das System 400 einen oder mehrere Server 430 umfassen, die benutzerspezifische Informationen speichern und aufrechterhalten können. Der/die Server 430 können einen oder mehrere Prozessoren 432, einen oder mehrere Speicher 434, ein Betriebssystem 436 und eine oder mehrere Anwendungen 438 umfassen, die dem Benutzer verschiedene Dienstleistungen und/oder Funktionalitäten bieten. In einer Ausführung können die Anwendungen 438 solche Dienstleistungen als einen E-Mail-Service, einen Kalender-Service, einen Blog-Hosting-Service, einen Online-Zahlungsservice, einen Service für die Speicherung und das Management von Inhalt (z. B. für Speicherung und Management von Dokumenten, Fotos usw.) umfassen. Ein Benutzer kann auf diese verschiedenen Dienstleistungen durch die Anmeldung auf einem einzigen, mit diesen Dienstleistungen assoziierten Konto zugreifen. Ein Benutzer kann zum Beispiel auf die Funktionalität multipler Anwendungen durch die Anmeldung auf einem einzigen Konto zugreifen.
In einigen Ausführungen kann der Benutzer auf die verschiedenen Dienstleistungen durch die Anmeldung auf multiple verschiedene Konten zugreifen, die mit den verschiedenen Dienstleistungen assoziiert sind. Der Benutzer kann sich zum Beispiel auf einem Konto anmelden, das mit dem Online-E-Mail-Konto des Benutzers (z. B. Microsoft Hotmail, Yahoo Mail, Google Gmail usw.), dem Online-Konto des sozialen Netzwerks des Benutzers (z. B. Facebook, Twitter usw.), dem Online-Foto-Konto des Benutzers (z. B. Snapfish, Shutterfly, Picasa usw.), Konten auf Content-Websites (z. B. Nachrichten-Websites, Spieleseiten, Unterhaltungswebsites usw.) usw. assoziiert ist. Der Sync Server 470 kann gewährleisten, dass lokale Daten aus einem Rechner (z. B. Gerät 402A, 402B oder 402C) über alle Geräte des Benutzers hinweg oder alle Geräte, die zur Anmeldung des Benutzers auf einem Benutzerkonto eingesetzt werden, synchronisiert werden. Zudem werden Kennwörter traditionell lokal gespeichert, können jedoch mit Hilfe des Sync Servers 470 synchronisiert werden. Darüber hinaus kann der Sync Server 470 alle installierten Webanwendungen, Browsererweiterungen, Browser-Bookmarks, Einstellungen, Profile, Browser-Historien, Themen, Plug-ins, lokale Berechtigungen, benutzerspezifische Identitätsinformationen (wie im Einzelnen im Hinblick auf Cache 418 weiter unten beschrieben) und mit den Webanwendungen und Browsererweiterungen assoziierten Daten für einen Benutzer synchronisieren. Wenn der Benutzer eines Rechners 402A zum Beispiel auf ein Benutzerkonto (zum Beispiel über einen Webbrowser) von einem Rechner 402B zugreift, kann der Sync Server 470 mit den Webanwendungen und Browsererweiterungen assoziierte Einstellungen und Daten (zum Beispiel diejenigen, die der Benutzer für die Synchronisation gewählt hat) aus dem Benutzerkonto auf den Rechner 402B kopieren. Änderungen an Einstellungen auf einem Rechner können automatisch von anderen Computern (z. B. über den Sync Server 470) kopiert werden (zum Beispiel, wenn der Benutzer diese Synchronisationsfunktion aktiviert hat). Synchronisierte Daten können verschlüsselt werden, wenn sie zwischen den Rechnern 402A, 402B ausgetauscht werden, und der Sync Server 470 kann die Informationen sicher aufbewahren und den Datenschutz des Benutzers aufrechterhalten. Zudem können Kennwörter auf den Rechnern 402A, 402B verschlüsselt werden, wobei der Sync Server 470 einen kryptographischen Schlüssel einsetzt.
Der Client-Rechner 402A kann zudem ein Cache 418 mit benutzerspezifischen Identitätsinformationen enthalten. Die benutzerspezifischen Identitätsinformationen können Informationen enthalten, die mit einem Benutzer der Browseranwendung 210 assoziiert sind, zum Beispiel einen Benutzernamen, eine E-Mail-Adresse des Benutzers, einen Avatar, ein von dem Benutzer online eingesetztes Pseudonym, ein Alter oder Geburtsdatum des Benutzers, eine Postadresse des Benutzers, eine Wohnanschrift Benutzers, eine Versandadresse des Benutzers, eine Telefonnummer des Benutzers, mit dem Benutzer assoziierte Kreditkarteninformationen, Freunde oder Kontakte des Benutzers, eine Historie der Websites, die der Benutzer durchstöbert hat, durch den Benutzer getätigte Käufe und/oder Downloads (z. B. Webanwendungen und/oder Erweiterungen, die auf dem digitalen Marktplatz verfügbar sind) usw. Die in dem Cache 418 gespeicherten benutzerspezifischen Identitätsinformationen können auf Opt-In-Grundlage durch den Benutzer gespeichert werden, und der Benutzer kann die speziellen, in dem Cache 418 gespeicherten Informationen kontrollieren.
Die in dem Cache 418 gespeicherten benutzerspezifischen Identitätsinformationen können für den Browser 410 zugänglich sein, und der Browser kann die Informationen für eine oder mehrere Webanwendungen zur Verfügung stellen, die auf dem Browser laufen, wenn dies durch den Benutzer autorisiert wird. Die benutzerspezifischen Identitätsinformationen können nur für den Browser 410 zugänglich sein, wenn der Benutzer dem Browser erfolgreich Anmeldeinformationen zur Verfügung stellt. Der Benutzer kann zum Beispiel aufgefordert werden, auf einer Benutzerschnittstelle einen Benutzernamen und ein Kennwort einzugeben, damit der Browser auf seine Identitätsinformationen zugreifen kann.
Cache 418 kann ein flüchtiger Speicher sein, der benutzerspezifische Identitätsinformationen im Verlauf einer Browser-Session speichert. Die Identitätsinformationen können permanent auf sichere Weise in einem nicht flüchtigen Speicher gespeichert und dann in Cache 418 geladen werden, wenn sich der Benutzer erfolgreich bei dem Browser anmeldet.
In einer anderen Ausführung können benutzerspezifische Identitätsinformationen permanent auf dem Speichergerät (z. B. Speicher 434) eines Online-Servers 430 gespeichert werden. Wenn sich der Benutzer dann auf einem Konto anmeldet, das mit einer Dienstleistung assoziiert ist, die durch den Online-Server 430 erbracht wird, können die benutzerspezifischen Identitätsinformationen von dem Online-Server 430 nach Cache 418 des Client-Gerätes 402A für den Einsatz durch Browser 410 heruntergeladen werden, dies mit Berechtigung durch den Benutzer. Die Identitätsinformationen können unter Einsatz sicherer Verschlüsselungstechniken heruntergeladen werden, welche die Informationen im Verlauf des Herunterladens schützen.
Der Browser 410 kann mit benutzerspezifischen Identitätsinformationen für verschiedene Benutzer oder mit unterschiedlichen Identitätsinformationen für einen einzigen Benutzer assoziiert werden. Zum Beispiel können verschiedene Benutzer über eine durch den Browser zur Verfügung gestellte Schnittstelle Anmeldeinformationen eingeben, so dass der Browser die verschiedenen benutzerspezifischen Identitätsinformationen für die verschiedenen Benutzer abrufen und im Cache ablegen kann. In einer anderen Ausführung kann ein einziger Benutzer verschiedene Identitätsprofile mit unterschiedlichen Identitätsinformationen aufrechterhalten, von denen jedes mit einem anderen Browserkonto assoziiert ist. Alternativ oder zusätzlich können verschiedene Benutzer desselben Client-Gerätes (z. B. Mann und Frau, die denselben Desktop-Computer benutzen) unterschiedliche Identitätsprofile mit unterschiedlichen Identitätsinformationen einrichten und aufrechterhalten, von denen jedes mit einem anderen Browsernutzungskonto assoziiert ist.
Eine Webanwendung, die ein Benutzer herunterlädt und auf dem Client-Gerät 402A installiert, kann eine Berechtigung umfassen, die der Webanwendung den Empfang benutzerspezifischer Identitätsinformationen von dem Browser gestattet, der die Anwendung realisiert. Auf eine solche Berechtigung kann hier als „Identitätsberechtigung” Bezug genommen werden. Wenn der Benutzer also eine Webanwendung herunterlädt und installiert, die eine Identitätsberechtigung umfasst, kann der Benutzer die Webanwendung für den Empfang benutzerspezifischer Identitätsinformationen vom Browser autorisieren. Die speziellen durch den Browser für die Webanwendung bereitgestellten Identitätsinformationen können von der Webanwendung und der Natur der Identitätsberechtigung abhängen. In einer Ausführung kann eine einzige Identitätsberechtigung existieren, die eine Sammlung von benutzerspezifischen Identitätsinformationen (z. B. Name und E-Mail-Adresse) aus dem Client-Browser 410 abzieht. In einer anderen Ausführung können verschiedene Ebenen von Identitätsberechtigungen spezifiziert werden, bei denen die verschiedenen Ebenen unterschiedlichen Arten oder Mengen von Identitätsinformationen entsprechen, die vom Browser auf die Webanwendung abgezogen werden. Eine Identitätsberechtigung zum „Einkaufen” zum Beispiel kann den Zugriff auf Identitätsinformationen fordern, wie etwa auf den Namen, die Kreditkarteninformationen, Rechnungsanschrift, Versandadresse usw. des Benutzers. In einem weiteren Beispiel kann eine Identitätsberechtigung des Typs „Benutzerinteressen” den Zugriff auf solche Identitätsinformationen fordern, wie etwa die Browsing-Historie, die Bestellhistorie, Inhaltsdateien (z. B. Posts auf öffentlichen Blogs) usw.; in einem anderen Beispiel kann eine „soziale” Identitätsberechtigung den Zugriff auf solche Identitätsinformationen fordern, wie etwa die Namen der Freunde eines Benutzers in sozialen Netzwerken, die Kontakte eines Benutzers, die Kalenderinformationen eines Benutzers usw. In einem weiteren Beispiel kann eine „grundlegende” Identitätsberechtigung den Zugriff nur auf grundlegende Identitätsinformationen fordern, wie etwa die E-Mail-Adresse des Benutzers.
Als Teil des Installationsverfahrens der Webanwendung kann ein Benutzer aufgefordert werden, eine Identitätsberechtigung zu autorisieren. Die Webanwendung kann bestimmte benutzerspezifische Identitätsinformationen als Teil der Identitätsberechtigung anfordern oder, wie zuvor beschrieben, sich auf die geforderten bestimmten Informationen mit Hilfe von einem oder mehreren generischen Markern beziehen, wie zum Beispiel etwa „Einkaufsinformationen” „Benutzerinteresseninformationen”, „soziale Informationen” oder „grundlegende Informationen”. Wenn der Benutzer als Teils des Installationsvorgangs die Berechtigung erteilt, dann kann die Webanwendung eine permanente Berechtigung für den Zugriff auf solche Informationen erhalten, es sei denn oder bis der Benutzer eine solche Berechtigung widerruft. Dann wird jedes Mal, wenn die Webanwendung innerhalb einer Browseranwendung 410 gestartet wird, wenn der Benutzer im Browser 410 angemeldet ist, kann die Webanmeldung automatisch die benutzerspezifischen Identitätsinformationen von dem Browser erhalten, ohne dass der Benutzer andere Schritte als den Start der Webanwendung unternehmen muss, um solche Informationen zur Verfügung zu stellen. Auf diese Weise kann der Benutzer bestimmten ausgewählten Webanwendungen leicht gestatten, auf die Identitätsinformationen des Benutzers zuzugreifen und diese zu nutzen, ohne anderen Webanwendungen oder Websites den Zugriff auf die Identitätsinformationen des Benutzers zu erlauben.
Die Webanwendung kann die benutzerspezifischen Identitätsinformationen auf vielfältige Weise einsetzen. So kann die Webanwendung zum Beispiel benutzerspezifischen Inhalt über die Webanwendung bereitstellen, wo der benutzerspezifische Inhalt auf den benutzerspezifischen Identitätsinformationen beruht, die der Webanwendung durch den Browser zur Verfügung gestellt werden. Der benutzerspezifische Inhalt kann Inhalt sein, der speziell auf der Grundlage der Interessen, der demographischen Daten, des Standortes des Benutzers oder anderer solcher benutzerspezifischen Identitätsinformationen ausgewählt wird.
In einem spezifischen Beispiel kann der Benutzer eine Webanwendung für Marvel Comics herunterladen und installieren, so dass der Benutzer auf von Marvel Comics bereitgestellten Inhalt zugreifen und diesen lesen kann. Als Teil der Installation der Webanwendung können mit dem Benutzer assoziierte Identitätsinformationen angefordert werden. Die Webanwendung kann zum Beispiel die E-Mail-Adresse und die Browser-Historie des Benutzers erfahren wollen. Nach Erteilung einer solchen Berechtigung und dem Start der Webanwendung kann die Webanwendung die Identitätsinformationen einsetzen, um dem Benutzer benutzerspezifischen Inhalt zur Verfügung zu stellen.
Die Webanwendung kann zum Beispiel die E-Mail-Adresse des Benutzers mit E-Mail-Adressen vergleichen, die in anderen, mit Marvel Comics assoziierten Datenbanken aufgelistet sind, was anzeigen kann, dass der Benutzer bereits zuvor ein Konto bei Marvel Comics registriert hatte (z. B. auf einer mit der Domäne www.marvel.com assoziierten Website), und dass der Benutzer bereits zuvor bestimmte Inhalte von Marvel Comics durchblättert, heruntergeladen oder erworben hat. Dann kann die Webanwendung den Benutzer der Webanwendung automatisch mit dem Profil des Benutzers mit derselben E-Mail-Adresse assoziieren, der bereits zuvor den Inhalt von Marvel Comics durchblättert, heruntergeladen oder erworben hatte und somit über die Webanwendung dem Benutzer auf der Grundlage der vorherigen Interaktion des Benutzers mit anderen, mit Marvel Comics assoziierten Objekten dann Inhalt vorschlagen oder bereitstellen. In einer anderen Ausführung kann die Webanwendung die Browser-Historie des Benutzers abrufen und analysieren, um die Interessen des Benutzers zu bestimmen und dann über die Webanwendung verfügbaren Inhalt bereitstellen oder vorschlagen, der sich auf die festgestellten Interessen des Benutzers gründet. Vorgeschlagener Inhalt kann zum Beispiel romantische Comics für einen Benutzer umfassen, dessen Browser-Historie auf ein Interesse an romantischen Themen hindeutet, und der vorgeschlagene Inhalt kann Abenteuer-Comics für einen Benutzer umfassen, dessen Browser-Historie auf ein Interesse an Abenteuer-Themen hindeutet.
Der Browser 410 kann von multiplen Benutzern geteilt werden, und jeder Benutzer kann unterschiedliche benutzerspezifische Identitätsinformationen haben. Wenn sich dann unterschiedliche Benutzer auf dem Browser 410 anmelden und die Webanwendung von Marvel Comics innerhalb des Browsers starten, kann die Anwendung unterschiedlichen benutzerspezifischen Inhalt für jeden der verschiedenen Benutzer auf der Grundlage ihrer Identitätsinformationen bereitstellen, der von der Webanwendung für jeden der verschiedenen Benutzer aus dem Browser abgezogen wird. Die Webanwendung kann die benutzerspezifischen Identitätsinformationen zum Beispiel durch einen API-Anruf an den Browser für den Abzug von Informationen aus Cache 418 abziehen.
Die Erteilung einer Identitätsberechtigung für Webanwendungen, die auf einem Browser installiert sind, können einem Benutzer eine bessere Benutzererfahrung bieten, wenn in einem Browser multiple Webanwendungen für einen Benutzer installiert sind. Wie im Einzelnen nachstehend im Hinblick auf 5A und 5B beschrieben, kann der Benutzer im Verlauf der Installation einer jeden Webanwendung den Einsatz von vorgegebenen benutzerspezifischen Identitätsinformationen durch die Webanwendung autorisieren, und während unterschiedliche Webanwendungen gestartet und benutzt werden, können relevante Identitätsinformationen von jeder Webanwendung automatisch vom Browser abgezogen werden, ohne dass der Benutzer weitere Schritte unternehmen muss (z. B. Anmeldung, Kennworteingabe usw.), als den Start der Webanwendung.
Die Informationen, die von einer Anwendung 410, die auf einem Client-Gerät läuft, für den Marktplatz-Server 450 bereitgestellt werden, (z. B. im Hinblick auf die Browser-Historie eines Benutzers usw.), können auf einer Opt-In-Grundlage geliefert werden. Mit anderen Worten können solche Informationen von dem Client-Rechner 402A nur an den Server 450 geliefert werden, wenn der Benutzer des Client-Gerätes die Übertragung solcher Informationen von dem Client an den Server spezifisch autorisiert.
5A illustriert das Flussdiagramm eines exemplarischen Verfahrens 500 für den Einsatz einer Browseridentität, im Einklang mit den zuvor im Zusammenhang mit den 1–4 beschrieben sind. Das Verfahren 500 kann beginnen, wenn ein Benutzer eine Webanwendung auf einem Browser (502) installiert, wie etwa Browser 410, wie in 4 gezeigt. In einigen Ausführungen vor 502 kann eine Webanwendung erklären, dass sie Identitätsinformationen benötigt.
Der Browser informiert den Benutzer, dass die Webanwendung Zugriff auf die Identität oder die Identitätsinformationen des Benutzers (504) haben kann, dies unter Einsatz eines Mitteilungsfensters zum Beispiel, wie das in 2 gezeigte Mitteilungsfenster 202. Wenn ein Benutzer die Webanwendung (506) startet, stellt der Browser fest, ob er einen Schlüssel für die Webanwendung hat (508). Falls ja (508, ja), schreitet das Verfahren zu 512 fort. Wenn nicht (508, nein), kann der Browser ein neues Schlüsselpaar für die Webanwendung generieren (510). Der Browser kann das Schlüsselpaar generieren (z. B. einen öffentlichen und einen privaten Schlüssel), indem er zum Beispiel asymmetrische Schlüssel-Algorithmen-Technologie einsetzt, um einen öffentlichen Codierungsschlüssel und einen privaten Codierungsschlüssel zu generieren. Der Browser kann das Schlüsselpaar innerhalb des Browsers generieren und den privaten Schlüssel in Verbindung mit dem Browser speichern, so dass keine Webanwendung, Website oder andere Anwendung auf den privaten Schlüssel zugreifen kann.
Der Browser kann den öffentlichen Schlüssel an die Webanwendung mit einer durch den privaten Schlüssel bereitgestellten Signatur senden (wie etwa ”X-Chrome-User: <pubkey>: <signature(cookies)>”), und die Webanwendung stellt fest, ob sie den öffentlichen Schlüssel (512) erkennt. Wenn die Webanwendung den öffentlichen Schlüssel (512, ja) erkennt, prüft die Webanwendung die Signatur unter Einsatz des öffentlichen Schlüssels (514).
Die Eingliederung eines solchen Verfahrens der Prüfung der Signatur in Webanwendungen kann für Entwickler nützlich sein. Des Weiteren müssen die Entwickler keine zusätzlichen Aufforderungen zur Benutzerauthentifizierung einrichten.
Wenn die Webanwendung den öffentlichen Schlüssel nicht erkennt (512, nein), kann die Webanwendung ein neues Konto für den Benutzer (516) einrichten, indem sie zum Beispiel eine automatische Aufforderung wie ein Dialogfenster einsetzt. Als Nächstes kann die Webanwendung den Benutzer authentifizieren (518), und das Verfahren kann enden. In einigen Ausführungen, nach 518 zum Beispiel, kann die Webanwendung zusätzliche Identitätsinformationen anfordern und anzeigen, wie etwa einen Namen, ein Foto usw.
Nachdem das Verfahren 500 einer Webanwendung die Authentifizierung eines Benutzers über die Browseridentität gestattet, kann die Webanwendung Einzelheiten anzeigen, wie etwa einen Namen, einen Avatar, ein Foto, eine E-Mail-Adresse oder andere benutzerspezifische Identitätsinformationen, zum Beispiel durch die Abfrage eines Objektes einer clientseitigen Browser-API. In einigen Ausführungen kann die Webanwendung durch die Einbeziehung eines Zeitstempels in ein Cookie gegen Replay-Angriffe schützen. Der Browser kann auch eine Benutzerschnittstelle zur Authentifizierung kontrollieren, um die Benutzererfahrung zu verbessern.
Der private Schlüssel kann nicht verraten werden, weil er den Browser niemals verlässt und bietet damit Sicherheit für Benutzeridentitäten online. Darüber hinaus funktionieren die hier beschriebenen Methoden und Systeme auch gut für Offline-Webanwendungen.
5B ist ein Blockdiagramm für einen exemplarischen Austausch kryptographischer Informationen zwischen einem Browser und einer Webanwendung. 5B umfasst den Browser 520, der den Generator des kryptographischen Schlüssels 521, die Browser-API 530 und die Webanwendungen 540 und 550 umfasst. Der Generator des kryptographischen Schlüssels 521 generiert ein Schlüsselpaar 522, darunter einen öffentlichen Schlüssel 524 und einen privaten Schlüssel 524, die mit einem bestimmten Benutzer von Browser 520 assoziiert werden können. Multiple Benutzer können mit Browser 520 assoziiert werden, doch kann sich im Allgemeinen jeweils nur ein Benutzer zurzeit bei Browser 520 anmelden. Der private Schlüssel 526 verlässt den Browser 520 niemals und wird den Webanwendungen 540 oder 550 oder anderen Websites niemals zur Verfügung gestellt und bietet damit Sicherheit für Benutzeridentitäten online. Eine mit dem öffentlichen Schlüssel 524 des Benutzers verschlüsselte Mitteilung kann jedoch den Webanwendungen 540 und 550 oder anderen Websites mit der Zustimmung des Benutzers zur Verfügung gestellt werden und eliminiert damit die Notwendigkeit für den Benutzer, persönliche Identitätsinformationen (z. B. den Namen, die Anmeldedaten oder sogar finanzielle Informationen) jedes Mal einzugeben, wenn der Benutzer mit Hilfe von Browser 520 auf eine andere Webanwendung zugreifen will.
Browser 520 kann zudem auch mindestens einen öffentlichen Schlüssel 528 speichern, der mit einer bestimmten Website oder Webanwendung assoziiert wird. Der öffentliche Schlüssel 528 kann zum Beispiel ein öffentlicher Schlüssel für die Webanwendung 540 sein, die auf Browser 520 installiert ist.
Wenn eine Website oder Webanwendung 540 die Identität eines bestimmten Benutzers bestätigen will, kann die Webanwendung 540 den Browser 520 herausfordern, die Identität eines bestimmten Benutzers zu bestätigen, wie zum Beispiel unter Einsatz der API 530. Die Webanwendung 540 kann zum Beispiel den öffentlichen Schlüssel eines Benutzers einsetzen, der zuvor von dem Browser 520 bereitgestellt wurde, um eine spezifische Mitteilung zu verschlüsseln, wie etwa Text 532. Die Webanwendung 540 kann den Browser 520 herausfordern, die Mitteilung zu entschlüsseln, um Text 532 zu finden. Wenn der Browser 520 die Mitteilung entschlüsseln kann, um Text 532 zu finden (z. B. unter Einsatz des privaten Schlüssels 526), kann Browser 520 der Webanwendung 540 beweisen, dass der Browser den privaten Schlüssel 526 für den bestimmten Benutzer hat. Die Kommunikation zwischen der Webanwendung 540 und dem Browser 520 kann über eine Browser-API 530 oder mittels anderer Techniken erfolgen.
6 zeigt das Beispiel eines generischen Computergerätes 600 und eines generischen mobilen Computergeräts 650, die mit den hier beschriebenen Techniken verwendet werden können. Computergerät 600 soll verschiedene Formen von Digitalcomputern darstellen, zum Beispiel Laptops, Desktops, Workstations, Personal Digital Assistants, Server, Blade Server, Mainframes und andere geeignete Computer. Computergerät 650 soll verschiedene Formen mobiler Geräte, wie Personal Digital Assistants, Mobiltelefone, Smartphones und andere ähnliche Computergeräte, darstellen. Die hier gezeigten Komponenten, ihre Verbindungen und Beziehungen und ihre Funktionen sollen nur exemplarisch sein und sollen Implementierungen der in diesem Dokument beschriebenen und/oder beanspruchten Erfindungen nicht einschränken.
Das Computergerät 600 beinhaltet einen Prozessor 602, einen Speicher 604, ein Speichergerät 606, eine Hochgeschwindigkeitsschnittstelle 608, die mit dem Speicher 604 und den Hochgeschwindigkeits-Erweiterungsanschlüssen 610 verbunden wird, und eine langsame Schnittstelle 612, die mit einem langsamen Bus 614 und dem Speichergerät 606 verbunden wird. Alle der Komponenten 602, 604, 606, 608, 610 und 612 sind mithilfe verschiedener Busse miteinander verbunden und können an einer gemeinsamen Hauptplatine oder auf andere Weise, wie geeignet, angebracht sein. Der Prozessor 602 kann Anweisungen zur Ausführung innerhalb des Computergeräts 600 verarbeiten, einschließlich Anweisungen, die im Speicher 604 oder auf dem Speichergerät 606 gespeichert sind, um grafische Informationen für eine GUI auf einem externen Eingabe-/Ausgabegerät anzuzeigen, wie Anzeige 616, die an die High-Speed-Schnittstelle 608 gekoppelt ist. In anderen Implementierungen können mehrere Prozessoren und/oder mehrere Busse verwendet sein, wie angemessen, zusammen mit mehreren Speichern und Speichertypen. Außerdem können mehrere Computergeräte 600 verbunden sein, wobei jedes Gerät Teile der nötigen Operationen bereitstellt (z. B. als Serverbank, eine Gruppe von Blade Servern oder ein Multiprozessor-System).
Der Speicher 604 speichert Informationen im Computergerät 600. In einer Implementierung ist der Speicher 604 ein flüchtiges Speichergerät oder flüchtige Speichergeräte. In einer anderen Implementierung, ist der Speicher 604 ein flüchtiges Speichergerät oder flüchtige Speichergeräte. Der Speicher 604 kann auch eine andere Form von computerlesbarem Medium sein, zum Beispiel ein magnetischer oder optischer Datenträger.
Das Speichergerät 606 ist in der Lage, Massenspeicherung für das Computergerät 600 bereitzustellen. In einer Implementierung kann das Speichergerät 606 ein computerlesbares Medium sein oder enthalten, zum Beispiel ein Diskettengerät, ein Festplattengerät, ein optisches Datenträgergerät oder ein Bandgerät, ein Flash-Speicher oder ein anderes ähnliches Solid-State-Speichergerät oder eine Reihe von Geräten, zum Beispiel Geräte in einem Storage Area Network oder anderen Konfigurationen. Ein Computerprogrammprodukt kann konkret in einem Informationsträger ausgeführt sein. Das Computerprogrammprodukt kann auch Anweisungen enthalten, die, wenn sie ausgeführt werden, ein oder mehrere Verfahren ausführen, wie die oben beschriebenen. Der Informationsträger ist ein computer- oder maschinenlesbares Medium, wie der Speicher 604, das Speichergerät 606 oder der Prozessorspeicher 602.
Der Hochgeschwindigkeits-Controller 608 verwaltet bandbreitenintensive Vorgänge für den Rechner 600, während der langsame Controller 612 Vorgänge mit niedrigerer Bandbreite verwaltet. Eine solche Zuordnung von Funktionen ist nur exemplarisch. In einer Implementierung, ist der High-Speed-Controller 608 an den Speicher 604, die Anzeige 616 (z. B. durch einen Grafikprozessor oder -beschleuniger) und an die -Erweiterungsanschlüsse 610 gekoppelt, die verschiedene Erweiterungskarten aufnehmen können (nicht gezeigt). In dieser Anwendung ist der langsame Controller 612 an das Speichergerät 606 und an den langsamen Erweiterungsanschluss 614 gekoppelt. Der Low-Speed-Erweiterungsanschluss, der verschiedene Kommunikationsanschlüsse (z. B. USB, Bluetooth, Ethernet, Funkethernet) beinhalten kann, kann an ein oder mehrere Eingabe-/Ausgabe-Geräte, wie eine Tastatur, ein Zeigegerät, einen Scanner oder ein Netzwerkgerät, wie einen Switch oder Router, z. B. durch einen Netzwerkadapter gekoppelt sein.
Der Rechner 600 kann in einer Reihe verschiedener Formen ausgeführt werden, wie in der Abbildung gezeigt. Zum Beispiel kann es als Standardserver 620, oder mehrmals in einer Gruppe solcher Server implementiert sein. Es kann auch als Teil eines Rackserversystems 624 implementiert sein. Darüber hinaus kann es in einem Personal Computer, wie Laptop-Computer 622, implementiert sein. Alternativ können Komponenten von Computergerät 600 mit anderen Komponenten in einem mobilen Gerät kombiniert sein (nicht dargestellt), z. B. Gerät 650. Jedes dieser Geräte kann eines oder mehrere Computergeräte 600, 650 enthalten, und ein gesamtes System kann aus mehreren Computergeräten 600, 650 bestehen, die miteinander kommunizieren.
Der Rechner 650 umfasst neben anderen Komponenten einen Prozessor 652, einen Speicher 664, ein Eingabe-/Ausgabegerät, wie eine Anzeige 654, eine Kommunikationsschnittstelle 666 und einen Sender-Empfänger 668. Das Gerät 650 kann auch mit einem Speichergerät ausgestattet sein, zum Beispiel einem Microdrive oder einem anderen Gerät, um zusätzlichen Speicher bereitzustellen. Jede der Komponenten 650, 652, 664, 654, 666 und 668 ist mithilfe verschiedener Busse miteinander verbunden, und kann an einer gemeinsamen Hauptplatine oder auf andere Weise, wie geeignet, angebracht sein.
Der Prozessor 652 kann Anweisungen im Rechner 650 ausführen, darunter auch Anweisungen, die in Speicher 664 gespeichert sind. Der Prozessor kann als ein Chipsatz von Chips implementiert werden, die separate und mehrere analoge und digitale Prozessoren beinhalten. Der Prozessor kann zum Beispiel für die Koordination der anderen Komponenten des Geräts 650 sorgen, zum Beispiel die Kontrolle von Benutzeroberflächen, Anwendungen, die vom Gerät 650 ausgeführt werden, und die drahtlose Kommunikation durch Gerät 650.
Prozessor 652 kann mit einem Benutzer über die Steuerschnittstelle 658 und Anzeigenschnittstelle 656 kommunizieren, die mit einer Anzeige 654 gekoppelt ist. Das Display 654 kann zum Beispiel ein TFT-LCD(Thin-Film-Transistor Liquid Crystal Display)- oder ein OLED(organisches Leuchtdioden)-Display oder eine andere angemessene Anzeigetechnologie sein. Die Displayschnittstelle 656 kann eine geeignete Schaltung enthalten, die das Display 654 dazu bringt, einem Benutzer grafische und andere Informationen zu präsentieren. Die Steuerschnittstelle 658 kann Befehle von einem Benutzer empfangen und sie für die Sendung an Prozessor 652 umwandeln. Zusätzlich kann eine externe Schnittstelle 662 Kommunikation mit dem Prozessor 652 bereitstellen, zum Beispiel, um Nahbereichskommunikation des Geräts 650 mit anderen Geräten zu ermöglichen. Die externe Schnittstelle 662 kann zum Beispiel in einigen Implementierungen, eine kabelgebundene Kommunikation bereitstellen, oder in anderen Implementierungen eine drahtlose Kommunikation, und es können auch mehrere Schnittstellen verwendet werden.
Der Speicher 664 speichert Informationen im Rechner 650. Der Speicher 664 kann als eines oder mehrere computerlesbare Medien, flüchtige Speichergeräte oder nicht flüchtige Speichergeräte implementiert sein. Erweiterungsspeicher 674 kann ebenfalls bereitgestellt und mit dem Gerät 650 über Erweiterungsschnittstelle 672 verbunden werden, die zum Beispiel eine SIMM(Single In Line Memory Module)-Kartenschnittstelle umfassen kann. Dieser Erweiterungsspeicher 674 kann zusätzlichen Speicherplatz für Gerät 650 bereitstellen oder er kann auch Anwendungen oder andere Informationen für Gerät 650 speichern. Insbesondere kann Erweiterungsspeicher 674 Anweisungen zum Ausführen oder Ergänzen der oben beschriebenen Prozesse enthalten, und er kann außerdem sichere Informationen enthalten. Somit kann Erweiterungsspeicher 674 zum Beispiel als Sicherheitsmodul für Gerät 650 bereitgestellt werden und er kann mit Anweisungen programmiert sein, die die sichere Verwendung von Gerät 650 erlauben. Zusätzlich dazu können über die SIMM-Cards sichere Anwendungen bereitgestellt werden, zusammen mit zusätzlichen Informationen, wie dem Ablegen von Identifizierungsinformationen auf der SIMM-Card auf eine Weise, die nicht gehackt werden kann.
Der Speicher kann zum Beispiel Flash-Speicher und/oder NVRAM-Speicher beinhalten, wie nachstehend erörtert. In einer Implementierung, ist ein Computerprogrammprodukt konkret in einem Informationsträger ausgeführt. Das Computerprogrammprodukt enthält Anweisungen, die, wenn sie ausgeführt werden, ein oder mehrere Verfahren ausführen, wie die oben beschriebenen. Der Informationsträger ist ein computer- oder maschinenlesbares Medium, wie der Speicher 664, die Speichererweiterung 674 oder der Speicher in Prozessor 652, zu empfangen, zum Beispiel, über den Sender-Empfänger 668 oder die externe Schnittstelle 662.
Das Gerät 650 kann drahtlos über die Verbindungsschnittstelle 666 kommunizieren, die wo erforderlich digitale Signalverarbeitungsschaltkreise beinhalten kann. Die Verbindungsschnittstelle 666 kann Verbindungen mit verschiedenen Kommunikationstypen oder -protokollen aufbauen, darunter u. a. GSM-Sprachanrufe, SMS, EMS, oder MMS-Messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000 oder GPRS. Eine solche Kommunikation kann zum Beispiel über Funkfrequenzempfänger 668 erfolgen. Zusätzlich kann eine Kurzstreckenkommunikation stattfinden, wie etwa unter Verwendung von Bluetooth, WiFi oder eines anderen solchen Sender-Empfängers (nicht gezeigt). Außerdem kann GPS(Global Positioning System)-Empfängermodul 670 zusätzliche navigations- und standortbezogene drahtlose Daten für Gerät 650 bereitstellen, die ggf. von Anwendungen verwendet werden können, die auf Gerät 650 ausgeführt werden.
Das Gerät 650 kann mit Hilfe des Audio-Codec 660 auch akustisch kommunizieren, womit gesprochene Informationen von einem Benutzer empfangen und diese in nutzbare digitale Informationen konvertieren können. Das Audio-Codec 660 kann zudem akustische Töne für einen Benutzer erzeugen, z. B. durch einen Lautsprecher, wie beispielsweise in einem Handgerät von Gerät 650. Diese Töne können Töne von Sprachtelefonanrufen beinhalten, können aufgezeichnete Töne (z. B. Sprachnachrichten, Musikdateien usw.) beinhalten und können auch Töne, die von Anwendungen, welche auf Gerät 650 operieren, beinhalten.
Der Rechner 650 kann in einer Reihe verschiedener Formen ausgeführt werden, wie in der Abbildung gezeigt. Zum Beispiel, kann es als Mobiltelefon 680 implementiert werden. Es kann außerdem als Teil eines Smartphones 682, Personal Digital Assistant (PDA) oder eines anderen ähnlichen Mobilgeräts implementiert sein.
Verschiedene Ausführungen der hier beschriebenen Systeme und Techniken können in digitalen elektronischen Schaltkreisen, integrierten Schaltkreisen, speziell konzipierten ASICs (application-specific integrated circuits, anwendungsorientierten integrierten Schaltkreisen), Computerhardware, Firmware, Software und/oder Kombinationen davon realisiert werden. Diese verschiedenen Implementierungen können eine Implementierung in einem oder mehreren Computerprogrammen beinhalten, die auf einem programmierbaren System ausführbar und/oder interpretierbar sind, das mindestens einen programmierbaren Prozessor beinhaltet, der ein spezieller Prozessor oder ein Prozessor für allgemeine Zwecke sein kann, und der zum Empfangen von Daten und Anweisungen von und zum Übertragen von Daten und Anweisungen an ein Speichersystem, mindestens eine Eingabevorrichtung und mindestens eine Ausgabevorrichtung gekoppelt ist.
Diese Computerprogramme (auch bekannt als Programme, Software, Softwareanwendungen oder Code) beinhalten Maschinenanweisungen für einen programmierbaren Prozessor und können auf hoher Ebene in einer prozeduralen und/oder objektorientierten Programmiersprache und/oder in Assembler-/Maschinensprache implementiert werden. Wie hier verwendet, bezeichnen die Begriffe „maschinenlesbares Medium”, „computerlesbares Medium” ein beliebiges Computerprogrammprodukt, eine beliebige Vorrichtung und/oder ein beliebiges Gerät (z. B. Magnetplatten, optische Platten, Speicher, programmierbare Logikbausteine (Programmable Logic Devices, PLDs), die verwendet werden, um einem programmierbaren Prozessor Maschinenbefehle und/oder Daten bereitzustellen, einschließlich eines maschinenlesbaren Mediums, das Maschinenbefehle als maschinenlesbares Signal empfängt. Der Begriff „maschinenlesbares Signal” bezeichnet ein beliebiges Signal, das verwendet wird, um für einen programmierbaren Prozessor Maschinenbefehle und/oder Daten bereitzustellen.
Zur Interaktion mit einem Benutzer können die hier beschriebenen Systeme und Techniken auf einem Computer mit einem Anzeigegerät (z. B. mit CRT-[cathode ray tube, Kathodenstrahlröhre] oder LCD-[liquid crystal display, Flüssigkristallanzeige]Monitor) implementiert werden, um Informationen für den Benutzer anzuzeigen, und eine Tastatur und ein Zeigegerät (z. B. Maus oder Trackball), mit denen der Benutzer Eingaben in den Computer machen kann. Andere Arten von Geräten können auch verwendet werden, um eine Interaktion mit einem Benutzer bereitzustellen; zum Beispiel kann eine dem Benutzer bereitgestellte Rückmeldung irgendeine Form von Sinnesrückmeldung sein (z. B. visuelle Rückmeldung, auditive Rückmeldung oder Tastrückmeldung); und eine Eingabe vom Benutzer kann in einer beliebigen Form empfangen werden, einschließlich akustischer, Sprach- oder Tasteingaben.
Die hierin beschriebenen Systeme und Techniken können in einem Computersystem implementiert werden, das eine Back-End-Komponente (z. B. als Datenserver), oder eine Middleware-Komponente (z. B. einen Anwendungsserver) oder s eine Front-End-Komponente beinhaltet (z. B. ein Client-Computer mit einer graphischen Benutzerschnittstelle oder einem Webbrowser, über welche ein Benutzer mit einer Ausführung der hier beschriebenen Systeme und Techniken interagieren kann) oder eine jegliche Kombination derartiger Back-End-, Middleware- und Front-End-Komponenten. Die Komponenten des Systems können durch eine beliebige Form oder ein beliebiges Medium von digitaler Datenkommunikation (z. B. ein Kommunikationsnetzwerk) miteinander verbunden sein. Beispiele von Kommunikationsnetzwerken beinhalten ein lokales Netzwerk („LAN”), ein Fernnetz („WAN”) und das Internet.
Das Computersystem kann Client und Server beinhalten. Ein Client und Server befinden sich im Allgemeinen entfernt voneinander und interagieren über ein Kommunikationsnetz. Die Beziehung zwischen Client und Server entsteht aufgrund von Computerprogrammen, die auf den jeweiligen Computern laufen und die eine Client-Server-Beziehung zueinander haben.
Eine Anzahl von Ausführungsformen wurde beschrieben. Trotzdem versteht sich, dass verschiedene Modifikationen durchgeführt werden können, ohne vom Geist und Umfang der Erfindung abzuweichen.
Außerdem erfordern die in den Abbildungen dargestellten logischen Abläufe nicht die bestimmte dargestellte oder sequenzielle Reihenfolge, um wünschenswerte Ergebnisse zu erzielen. Darüber hinaus können andere Schritte vorgesehen oder Schritte aus den beschriebenen Abläufen eliminiert werden und andere Komponenten können zu den beschriebenen Systemen hinzugefügt werden oder von diesen entfernt werden. Dementsprechend liegen andere Ausführungsformen im Umfang der folgenden Ansprüche.

Claims

Ein nicht-flüchtiges computerlesbares Medium, das durch den Prozessor eines Rechners ausführbare Anweisungen enthält, die bei Ausführung durch den Prozessor den Rechner zu Folgendem veranlassen: Exposition einer Programmierschnittstelle der Browseranwendung gegenüber einer Webanwendung zur Bestätigung und Identifizierung eines Benutzers unter Einsatz von im Browser gespeicherten benutzerspezifischen Identitätsinformationen; Übertragung kryptographischer Informationen, die mit dem Benutzer assoziiert sind, von der Programmierschnittstelle der Browseranwendung an die Webanwendung; und Bereitstellung benutzerspezifischer Inhalte für den Benutzer über die Webanwendung, wenn die Webanwendung unter Einsatz der kryptographischen Informationen eine Identität des Benutzers über die Programmierschnittstelle der Browseranwendung bestätigt.
Ein System, welches das Folgende umfasst: einen Speicher; und einen Prozessor, operativ verbunden mit dem Speicher, und so konfiguriert, dass er Code ausführt, um Folgendes zu erreichen: Exposition einer Programmierschnittstelle der Browseranwendung gegenüber einer Webanwendung zur Bestätigung und Identifizierung eines Benutzers unter Einsatz von im Browser gespeicherten benutzerspezifischen Identitätsinformationen; Übertragung kryptographischer Informationen, die mit dem Benutzer assoziiert sind, von der Programmierschnittstelle der Browseranwendung an die Webanwendung; und Bereitstellung benutzerspezifischer Inhalte für den Benutzer über die Webanwendung, wenn die Webanwendung unter Einsatz der kryptographischen Informationen eine Identität des Benutzers über die Programmierschnittstelle der Browseranwendung bestätigt.