[Proposal] A Generic Gateway to Sensitive Resources

[SUN Haitao]

Hi, All. I have some ideas (and some experimental working code) may be
helpful to safely access sensitive resources in web apps. It bases on
some work which I talked with Jonas Sicking personally last year.
Sorry for my not posting this here earlier (and not posting correctly
nine days ago).

# Problems

To make web apps as powerful as native ones, allowing them to access a
lot of resources is required. Many of those resources are
security-sensitive or privacy-sensitive. Exposing them to random apps
will leads to great crises.

There are some classical solutions to this situation. But:

* Forcing apps to be reviewed is quit expensive.
* Forcing users to (or trust others to) grant apps privileges before
using is like engagement-before-dating.
* If a apps requires multiple sensitive resources, asking for
permission before calling is too annoying.

# Basic Idea

The core of the idea is making all sensitive objects inaccessible
unless booked first.

Whenever a web site/app wants to use some sensitive resources (e.g,
must-have WebTelephony API and optional WebSMS API), it books them
first:

 var [reservedTelApi, reservedSmsApi] = navigator.conductor.book(
   {
     //An URI to indicate what resource to book
     protocol:'https://wiki.mozilla.org/WebAPI/WebTelephony',
   },
   {
     protocol:'https://wiki.mozilla.org/WebAPI/WebSMS',
     //A boolean to indicate whether this resource is required,
default to false
     optional:true
   }
 );

When the book method is called, the use agent show a modal dialog-like
interface (Jonas suggested a asynchronous version, but the right
interface and behavior are a little hard to decide) which list all
demands (and their risk) together to ask for confirmation. If many
resources can fit in a demand (e.g, while booking WebTelephony API on
a dual SIM phone), the user also could select which resource to use
here.

If the user agent thinks all demands are capable and acceptable and
unambiguous (how to tell those if out of scope), it could book the
resources automatically without showing any interface.

If a site/app books all useful resources in the beginning, this
mechanism works like the engagement-before-dating way; If it always
book a resource just before using, the asking-before-calling way.

If all required resource are booked successfully (capable to the
system and accepted by the user), the book method returns an array of
reserve objects (for optional demands not accepted, an 'undefined'
value). Otherwise, an array of 'undefined'.

The site/app calls the take methods of the reserve objects (with an
optional dictionary to pass options), to get the real resource.

 var telApi = reservedTelApi.take();
 var smsApi = reservedSmsApi.take();

The following steps are just like the current way.

# Benefits

* Users can test-drive sites/apps more easily. Especially when only
part of the site/app requires sensitive resources.
* Since users can confirm many demands with just one click,
confirmations is no longer too annoying.
* For the site/app could not tell a failed demand is incapable or not
accepted, silent finger-printing is not possible via this.
* This can be a formal way to introduce new APIs.

# Demos

I've built an extension for Firefox (Windows/Linux version only) to
test this idea which is available at:
 https://addons.mozilla.org/en-US/firefox/addon/conductory/

Currently, only a low-level microphone API, a low-level camera API and
GeoLocation API is supported.

Some demos can be found at:
 http://devtaste.com/extras/conductor/demos/

--
SUN Haitao
sunh...@devtaste.com
http://www.devtaste.com

[Mounir Lamouri]

I'm not sure I get the advantages your proposal has compared to what we
are currently thinking of which is a mix between allowing some APIs
during install time and allowing some others at run-time.
The only difference I see is that you can group multiple requests in one
bucket. Even if that looks like a good idea, doing an UI for that would
be highly complex and that could be used by malicious developers to get
access to a sensitive API while having the user think it is allowing
only un-harmful ones.

--
Mounir

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

[Jonas Sicking]

Hello!

This proposal seems aimed at solving a particular aspect of the
problems we are tackling, how to show an API which asks for permission
to certain sensitive API.

Unfortunately there's a long list of other problems that it doesn't
address. For example, for something like WebTelephony, simply asking
the user for permission to use it would probably not be safe enough.
If you ask 100 000 people for permission to use the phone on their
device, a bunch of them are bound to say yes, without really
understanding the implications of doing this.

Enough people would likely say yes that if you asked that many people
and for everyone that said yes used the phone access to call a pay-for
number, you could likely make a pretty decent amount of money.

So for sensitive APIs like that we need something more secure than
simply asking the user.

Another problem is that we likely don't want to ask users for several
things at the same time. It's very hard to get users to read security
dialogs, so we need to do everything we can to get them to read it.
One good way of doing this is to place text in the actual button which
describe what they are allowing. This is hard when several things are
requested at once.

Additionally, we generally want to ask users for permission to
something at the time when the application actually needs to use the
permission. But it's unlikely that a website needs to use a lot of
things at the same time. Hence we generally will only need to ask for
permission for one thing at a time.

/ Jonas