APIs for Trusted Web Applications -- 31 Oct 2012

Round of introductions

<dsr> Wonsuk explains the background to the launch of the SysApps WG - the emergence of the Web operating system , e.g. ChromeOS and FirefoxOS

<richt> Scribe: richt

dsr: We'll go through a few general points then open the floor for general discussion.
... Web browsers need to take care to protect users
... APIs designed in that environment need to protect the user and mitigate security risks
... this has been done in W3C DAP WG
... If a Contact app wants to access contacts, it offers a picker in the web browser
... but not full access to a contacts database.
... SysApps is about creating system-level applications. e.g. Making a Contacts Manager/Address Book
... That needs a much richer API without nagging the user all the time.
... That needs much more trust for the application.
... There's a whole new breed of these platforms emerging.
... Webinos working on a cross-device platform.
... Tizen, Chrome OS, Firefox OS and also Phonegap.

<paulc> Can someone provide a link to the presentation?

dsr: Using a web stack has many advantages e.g. much easier for developers
... So what is need to trust apps. Is it provenance of the app or signing for example?

TV Raman: Web apps we don't have to install. Click on a link and it works.

scribe: but when we get to the security model we have problems there.

<dsr> slides: http://www.w3.org/wiki/images/0/0c/Sysapps-tpac2012.pdf

<paulc> Thank you.

dsr: It's increasingly common we have lots of devices. TVs, mobiles, computers
... more emerging devices: cars, medical devices, monitors
... how do we let authorization to my services in a simple way
... in Webinos we came up with Personal Zones to solve this problem.
... in SysApps we want to produce APIs that we can run consistently not just client side but also server side.
... so services can run embedded or on the cloud.
... this is the focus of the Webinos project

[dsr shows the SysApps WG charter on the screen]

dsr: Initial focus of the group will be on security models.
... then we have a few 'getting our feet wet' APIs: alarm, contacts, messaging, telephony, raw sockets.
... then we'll move to more complicated APIs.
... NFC has been split off to a separate working group.
... We are in the sign-up period for the SysApps WG and we're looking for initial contributions and spec editors
... we're very much in the initial stages.
... we plan to use Github for spec development.

Wonsuk: We have received some input concerning phase 1 from current members.
... Please get involved on the mailing list with any other comments.

dsr: we received some feedback from Oxford University (John Lyle) re: security model for this group.

[dsr refers to 'Security Model?' slide shared in this session on the screen]

dsr: Regarding the execution model I made a few notes in the slidedeck.

[dsr refers to 'Execution Model?' slide shared in this session and up on the screen]

dsr: At this point we should throw the floor open for discussions.
... Please add a Topic to the IRC channel.

<dsr> agendum+ example topic

example topic

Wonsuk: Thanks dsr.
... we want to freely talk about the items in the slide deck. If you have any questions then it would be good to discuss them now.
... e.g. how many items will be handled in this working group?
... there may be a wide scope.

Alex Morgaut: We are working on implementations. We have a lot of requirements that currently have no answers.

scribe: we are looking for answers to those things. A use case: we really need a lot of new APIs.
... Very open to working here.

Wonsuk: Most important is agreeing on the execution model and security model
... once we have these things we can specify the APIs.
... the APIs have to align with the execution and security model.
... we want to make sure that the APIs are designed to work in that context.
... once we've validated a security/execution model we can build out the API items we produce here.
... in phase 2.
... and we continue to get further feedback on where we head when we get to phase 2.

Alex Morgaut: Looking for things like USB/Bluetooth for example. Will these be available in browsers or in embedded devices for example?

scribe: we're looking for a standard way to do that.

<dsr> toshi: can phase 2 start before phase 1 ends?

<paulc> For WG charter milestones see http://www.w3.org/2012/09/sysapps-wg-charter.html#milestones

Wonsuk: phase 1 and phase 2 does not have a sharp cut-off.

toshi: yes, we don't need to rush but there may be a lot of interest in phase 2.

paulc: The link I provided show the milestones as documented in the charter.
... that doesn't necessarily mean you can't start the FPWD of a phase 2 doc early.
... that seems to be a model the W3C is encouraging here.

Alex Morgaut: There are some interesting questions here. Things like File System API. We don't want to the app to have access to the full filesystem. Just to a part of it.

dsr: That seems to be a question about the sandboxing.

nwidell: Does SysApps make any assumptions on whether we have e.g. Widgets or AppCache based applications?
... are we making any assumptions here?

dsr: I don't think that has been decided. Up in the air.
... other groups are working on packaging. This is still to be looked at in the context of this WG.

Wonsuk: We can give some info about the permission to access some features.
... in this perspective there are issues related to the packaging format.
... there is work in different working groups. We will need to align.

TV Raman: Two problem here: one is the lifecycle e.g. start/stop. The second problem is the interfaces.

scribe: We can divide this problem. Maybe even split the work with other WGs.
... So e.g. today on Android. I can use Intents and other apps can handle these actions.
... that might be something interesting here. Right now web apps can't call other web apps.

dsr: There is plenty we can learn from existing systems here.
... we've got a lot of input.

nwidell: Another question: Why do we have the Contacts API?
... in the DAP WG there was an assumption we had a native address book in the device.

Wonsuk: richt is the spec editor may have some thoughts on this.
... in SysApps we need to define all of the features of Contacts e.g. write/remove/read/etc.
... in DAP we could only do searching/finding.
... due to the in-browser security issues.

sakari: Isn't this an implementation detail. The API does not dictate where the address book is IIUC.

Alex Morgaut: Could the high-level API be more abstract?

e.g. on a gaming console I have different profiles. Sometimes I'm talking to external contacts, family, friends.

scribe: Is there a way to choose a 'type' of contacts that I get access to as an application.

sakari: I think that's going to be up to the API and its design.

<dsr> richt: we've done this activity a number of times already, my question is what it is different this time?

<dsr> are the companies making the proposal willing to adopt the standards?

<dsr> wonsuk asks richt about the previous efforts.

<dsr> richt: we definitely need to learn from previous work, e.g the experience with policies

<alexandremorgaut> dsr: our company might be interested to bind contact API to a LDAP directory on the server

dan applequist: I think we'll have more implementations. More implementations will mean more examples to point to

scribe: where things work and where things don't work.
... maybe this is the opportunity to get it right.
... and we can learn from directions we've previously tried.

marcin_hanclik: I agree with the point made by richt. Why not take one of the previous proposals and implement this instead of starting and doing the same again?

sakari: DAP may be considered one input. DAP is really primitive due to the browser security model.
... We want to do much more than is possible in these APIs.

dcheng3: It's primitive because it has a well-defined scope.

Wonsuk: This has been a good discussion.
... I want to close the discussion for now.
... We will have a 10 minute break and then re-convene for further discussion.
... Question about working model for this group.
... We will probably have 2-3 f2f meetings per year.
... and we will have regular conference calls.
... Ok. Break.

[Group takes a 10 minute break]

<dsr> scribe: dsr

Security Models

Wonsuk: Jonas will be able to describe the security model used in FirefoxOS.

Jonas: FirefoxOS has a bunch of preinstalled apps. Installing an app takes you through an installation step. We don't believe that installing an app should by default give it wide privileges.

It should be safe to install any app from an appstore you trust.

When you install an app it can do anything web pages do, but not reading files.

To talk to other websites it has to use CORS or CSP.

You get local (sandboxed) storage and limited means to create notifications.

To build more powerful apps you need additional capabilities. Built-in apps have the most privileges. Certified apps have somewhat less privileges.

Some telephony and SMS APIs are restricted to built-in apps.

Also settings e.g. communicating with the SIM card.

Certified apps can access the filestore, camera, and more.

Priviledged apps need to be installed from a certified app store.

Currently, this is limited to the Firefox store.

The app store needs to review the code of the app and make sure that it won't abuse its privileges.

Apps are signed with the store signature.

At run time, in addition to checking for the app store signature, for the first time, we also ask the user. The user's choice can be remembered for future occasions.

Jonas notes that you wouldn't want to lose 10 years of photos, so the additional checks are worth it.

If a prompt is too hard to explain to a user, we put the responsibility on the app store and don't ask the user.

It is very hard for users to make security decisions without a good context.

Asking the user in the context of the app running provides context (cites example of a game asking for access to your contacts after winning a level)

The app developer has to deal with the user deciding against a request.

Each app has completely separate store for cookies and app specific data.

This is also good for privacy as it makes it hard to track users across apps.

<gmandyam> +q

richt asks jonas if Mozilla will submit their packaging solution?

jonas: yes we plan to do so to webapps wg.

richt: does sysapps need to work on packaging before working on APIs?

jonas: packaging is tightly coupled to the execution and security models.

richt: to what extent can be build upon existing work?

jonas: that's for this group to decide, we may find different opinions across people on the details.

the short answer is that I would prefer not to use widgets, and to rather use something similar to the chrome packaging solution.

richt: the common element is defining privileges in the manifest.

We limit what information we surface to the user, especially at installation time.

Suresh: it makes sense to focus on just what is needed.

Jonas: if we get to the point where everyone is happy with the API, that's the important part.

Some APIs, e.g. alarm, only make sense in a certain run-time environment.

Our alarm API allows us to wake up a particular app.

<gmandyam> q

Jonas: we have a central feature of system messages that can for example wake up apps.
... DOM events may not make sense.

wonsuk: if you want to ask a question, please queue yourself on irc.

gmandyam: are you going to define content handler managers?

jonas: we are basically using web activities. Any app can register to handle a given activities.

gmandyam: adding/removing apps as an example

jonas: we allow anyone to set up an app store. you don't need to be privileged to check if an app is installed.

Our home screen app is relatively unprivileged. It can install, execute and uninstall apps.

gmandyam: there are so many different approaches to app life cycle security that it doesn't make sense to force just one here.

wonsuk: where we agree, we can standardize the approach.

gmandyam: it may depend on the underlying OS.

richt: at some point you can assume that an app has a given set of privileges. This group should take that as an assumption.

jonas: depending on the API we will prompt the user at run-time.

richt: you're saying the privileges can be changed dynamically for a given API?

jonas: yes. The user isn't prompted at installation time for a given privilege, but only the first time it is used at run-time.

paulc: jonas is that setting by app?

jonas: yes.

<Wonsuk> ?

gmandyam: two apps may have different privileges, e.g. one has rw and other other ro, is that correct?

<richt> fwiw, we follow HTML practice. If you don't have permission to access the API, then we don't expose that API on the DOM and you check if it exists or not at runtime as per web best practices.

<richt> ..in Widgets + Extensions.

jonas: essentially, however, to keep the UI simple, we limit how this is configured {yes, no, ask user}

<Zakim> nwidell, you wanted to ask about permission prompts in FF OS

nwidell: have you considered the use of policy languages?

jonas: no. we examined how users would be asked for the various apps for our use cases, and found that we didn't need policies.

For most apps, there will be only one or two questions in practice. we want to avoid annoying the user with questions.

We ask the user mainly in privacy situations and not so much in security situations. I'm not really sure what policy languages are needed for,

nwidell: they are useful when many permissions need to be changed at the same time.

jonas: we would prefer to avoid operator set policies in general, but there could be corporate policies in enterprise scenarios

we've mostly focused on the developers' perspective.

we may get around to policies later where it doesn't really effect the model.

wonsuk: we've run out of time. thanks to jonas.

- DRAFT -

APIs for Trusted Web Applications

31 Oct 2012

Attendees

Contents

Round of introductions

example topic

Security Models

Summary of Action Items

Scribe.perl diagnostic output