Jean-Marc Desperrier a écrit :
[...]
So what is needed IMO :
- Find a way to not ask the user at all
To get that :
- don't give the application access to no-GUI API layer that they can abuse
- give them access to an entry point that controls the GUI of the
sensible part
- allows an application to call an interface with a GUI only when it has
focus
- opaque elements are a good pivot to make this work. They can render
safe something that would be very dangerous if not opaque.
[...]
I'll try to illustrate this with a few concrete possibilities.
Let's first try to figure more in detail how to make this work for the
basic contacts *access* module :
- It's a module that allows to *access* contacts, and whose interface is
safe enough that any application can use it
(even if it may have to list it in it's description)
- It allows the application only to obtain an opaque contact element.
After being called, the module takes care of displaying the list of
contact, letting the user select one (or enter the data for a new one),
with an input option that says if several contact can be selected.
* the received contact will be opaque and the application will have no
idea about what it contains
* the application will have to tell before calling the module what it
intends to do with the contact, send SMS, send email, make a phone call.
It both allows to properly filter the contact list, and inform the user
about what he selects a contact for
* we need several other APIs to be able to take the opaque contact as
input :
- SMS sending API
- Mail sending API
- phone call API
In fact I think they should *only* allow opaque contact, and *not* let
the application send an SMS, make a phone call to a phone number, mail
address that has not been explicitly selected by the user. For mail we
need to think about the case where the app needs to be able to "phone
home", but even "phoning home" is a sensible operation (it's easy to use
"home" just as a gateway to go anywhere else).
* We may decide to taint the opaque contact after use.
Either it can be used only once, and the user will be asked to one again
the next time, or the "xxx sending" API will use that tainting to know
they need to not transparently use the contact the next time.
However as said earlier, the confirmation pop-up model needs to be
avoided as much as possible. It may be that the best solution is to
provide a control element that can be integrated inside the GUI of the
app, loaded with the opaque contact information, and that the user has
to interact with to allow the action.
The purpose here is to avoid the model where the user first select
something in the application and then gets a pop-up.
So we provide that element whose selection will imply the consent of the
user, but this means that the application must not have a full control
of what it looks like. We are actually here very near the <input
type="file"> model, where the web page only includes that tag, and can
not fully control how it will look, and also just like a native app does
not fully control the appearance of the interface's native control elements.
Obviously that security model is a really demanding model for the
interface/API designer. It replaces the usual way of providing a list of
low level API call, and getting away with the security problem by just
saying the user will have to approve the app to use them, with something
that requires very significant effort from the API designer to be smart
enough to provide something that's both secure, but also versatile
enough to cover all the actual use case, not forgetting any of them.
However it's not really surprising that a good solution is hard, and
it's better if it's hard at the initial step, for the designer of the
solution, than if it's hard for the user. Or even, that if it's quite
obviously very broken for the suer.
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
