User Story: Web application for email
Alice uses a Web application as her email client, and considers it trustable.
Her service provider offers to use a set of advanced features that requires access to off-line storage, addressbook integration, access to a dedicated storage space on her device, and interactions through the microphone.
Rather than being prompted every so often to grant permission to use these features, Alice is offered to approve all these accesses in a batch, as part of an installation procedure that identifies these extra-permissions.
Alice follows that procedure and is no longer prompted for these permissions for this application; she still gets prompted when her email client asks for her geolocation since that permission was not part of the batch approval.
Once a user has established a certain level of trust with a service provider, she is more likely to want to approve permissions as a batch rather than having to respond to prompt every so often that might slow down her work, or might make her miss an additional feature of the application.
Similarly, the user can be offered to validate a set of permissions in a batch when installing a widget, where the permissions can be identified through the
feature element [[WIDGETS]].
To that end, the various permissions that are bound to APIs need to identified.
To establish trust, a few basic parameters may be used, among which:
- identity — ensuring that the privileges are granted to the application from the trusted provider itself, to avoid phishing attacks;
- reputation — if others have reviewed positively an application, the user is more likely to trust it; reputation is itself linked to identity, either as a way to identify the source of the recommandation (e.g. approval from a network operator), or as a way to identify the aggregator of recommendations;
- context — a user is more likely to trust an application that requests permissions that make sense to her use of the said application.
Identity and reputation may be established in different ways; one of the most common being
through a validated signature on the widget or application package,
with a corresponding verification of the trust chain to a trusted root.