Workshop on Security of access to device APIs from the Web

Day 1: 10 December 2008

See also: IRC log


Lucas Adamski (Mozilla Corporation)
Nick Allott (OMTP Limited)
Martin Andrew (Oxford University)
Luis Barriga (ERICSSON)
Arthur Barstow (Nokia Corporation)
Steven Bellovin (Columbia University)
Arve Bersvendsen (Opera Software)
Johansson Björn (Ericsson)
Stewart Brodie (ANT Software Ltd)
Paddy Byers (OMTP Limited)
Marcos Caceres (W3C Invited Experts)
Coimbatore Chandersekaran (CIO Staff US Air Force)
Anil Dhawan (Microsoft Corp)
Paul Downey (BT)
Max Froumentin (Opera Software)
Anselm Garbe (Aplix Corporation)
Philip Hallam-Baker (VeriSign Inc.)
Marcin Hanclik (ACCESS Co., Ltd.)
Dominique Hazaël-Massieux (W3C/ERCIM)
Kai Hendry (Aplix Corporation)
Rainer Hillebrand (Deutsche Telekom AG, T-Com)
Frederick Hirsch (Nokia Corporation)
Adrian Hope-Bailie (dotMobi)
Dowan Kim (SKTelecom)
Ben Laurie (Google)
Stephen Lewontin (Nokia)
Marcus Liwell (Sony Ericsson)
Michael Mahemoff (Osmose/BT)
Fabio Massacci (Università degli Studi di Trento)
Ford Matthew (Internet Society)
Claes Nilsson (Sony Ericsson)
Patrik Persson (Ericsson Research)
Hoschka Philipp (W3C)
Mark Priestley (Vodafone)
Dave Raggett (W3C/ERCIM)
Tim Renouf (Aplix)
Thomas Roessler (W3C/ERCIM)
David Rogers (OMTP Limited)
Anders Rundgren ()
William Simpson (Institute for Defense Analyses)
Doug Turner (Mozilla Foundation)
Matt Womer (W3C/ERCIM)
Mary Ellen Zurko (IBM Corporation)
By phone:
Lee Griffin (IBM Corporation)
Olli Immonen (Nokia)
Nick Allot, Thomas Roessler
Matt Womer, Max Froumentin, Paul Downey, Dominique Hazaël-Massieux, Frederick Hirsch



Security for Access to Device APIs from the Web, Art Barstow, Nokia

See also: Position paper, Slides

Anders: What about OSS? The mobile industry with a few exceptions is going open source.

ArtB: A few ways: the w3c can't get specs to the Recommendation phase until there are...
... two interoperable implementations, so OSS makes a lot of sense.
... with respect to Widgets, there are already some OSS things there.
... on the other hand, there are some movements to not do specs until there's an OSS implementation in existance.

Security Challenges for Internet Technologies on Mobile Devices, Anil Dhawan, Microsoft

See also: Position paper, slides

BenLaurie: Verifiable disclosure, what is that?

Anil: That is making sure the manifest is secure, that no one has tampered with the privileged manifest document.

Frederick: Declarative vs Run-Time, why are those alternatives? Why not have both?

Anil: Those are things to consider from the user perspective. A bunch of checkboxes before running an app,it's not obvious what is going to be done with that.

ArtB: The six items on the last slide (Opps for Standards), are any of those good for being worked on within the w3c?

Anil: Those are some things we think belong in standards bodies, and if we can do that fantastic.

Fabio: What if the widget downloaded does not meet the risk requiremenets, but the user still wants to run it?

Anil: That falls back to policy, Operators know what they want there obviously, but to us it's a policy decision.

<PHB> We really need to start with a risk analysis and then look at where standards can help

Security Assurance for Web Device APIs, Steven M. Bellovin, Columbia University

See also: Position paper, Slides

<PHB> I can't work out what the security requirements are before implementation, so how could a solution be complete?

<PHB> [Actually the users will do the wrong thing when they do understand the circumstances!]

<fjh> users want to get something done and view security as a barrier

<PHB> Accounting needs greater consideration

Fabio: Are you sure it's a good idea to attach the category to the device and not the application?

smb: This may be semantics. When I talk about a device, like a smartphone browsing the Web, it might be microphone input... so I'm not talking about the device as the phone, but the device on the phone, such as the microphone.

PHB: It might be useful to think about the difference between mobile and stationary devices.
... Old computers had accounting.

smb: Where is the high assurance way to turn off data roaming for instance, without malware being able to turn it back on

PHB: <missed>

smb: There are a lot of concerns there. Vendors of say, smartphones that have controlled what apps can be downloaded and installed, they also may use that security to make sure that applications don't compete with their own applications.

Nick: What SDOs? What about OSS? Patent land mines? <missed> Installable applications over the Web <?> Trust and code identity?
... Risks and mitigation, how do we value these things? How are we aware of what an application claims it wants to do vs what it does?
... Device discovery and capabilities discovery...
... The user is a major element in this, what have they been trained to do, what role do they play?
... "Fragility", you can design the best theoretical system that you'd like, but we know the problems aren't usually the theoretical systems, but the bad implementations. They should fail gently.

Open Discussion

<fjh> Can view SDO cooperation as well as competition

Nick: Cooperation between SDOs can be difficult, differences in IPR, etc, slows things down.

fjh: Depends on the organizations being considered...

PHB: there are too many people involved to get them all together in one place that you can trust.

<fjh> some number of SDOs form an ecosystem

PHB: Once SDOs get beyond 1000 or so it's hard to know everyone.
... The mobile Web is different in some ways, but not all that different. We don't want to create a whole new platform for mobile devices.
... The Web Consortium needs to serve the Web platform, but once you get to applications there isn't enough bandwidth.

Nick: What is an application then?

PHB: <missed response>

Nick: Role of Open Source in this area?
... Are the Open Source initiatives going to have a role to play with early prototypes, etc?

Kai: I'd argue that the best software should win, whether it's Open Source or not.
... There should be competition.

pauld: We see great value in open source for requirements gathering. In proprietary world, there's lots of stuff out there that claims to be backed by research, etc, but there's no better research than getting it out there.

PaddyByers: I think this relates to Art's question: if we don't get the major players involved, why bother?
... Many of the OS projects are driven by commercial entities.

dougt: How is this different than a commercial company then?

PaddyByers: No different, except open source is a vehicle to get things proliferated as a de facto standard in a way that commercial projects aren't.

dougt: Doesn't matter then if you're closed or open source, it's how many users you have. Commercial vs open source is somewhat orthogonal to security in general.

PaddyByers: An OS implementation that you can use is not enough.

<tlr> I suggest not using Zakim for queue management

<tlr> instead, wave your hands -- the session chair isn't looking at IRC

Nick: Getting the right people involved... because we're talking about accessing device APIs the number of people involved has increased many fold.
... Ooperating System implementors, application developers, and middleware players... this makes collaboration more complicated.

PHB: Are we asking about Open Source because we are afraid there won't be any?
... If the devices are open, regardless of what we decide, then OS will grow.

dougt: What does an open device mean?

PHB: I can write an app and put it on my device, without worrying about it competing with the vendor.

<AndreaT> Greetings. Andrea Trasatti, dotMobi. I hope it's OK, if I quitely read....

David: In the case where there are contractual obligations you have to follow them... <??>

Nick: For instance who has your credit card, or debit card numbers, etc...??

dougt: For instance my cable provider has my credit card number and charges me for bandwidth, but has no control over the applications I use.
... The mobile phone case is slightly different due to subsidies, etc, but...

PHB: Discussing whether open source is going to play a role in developing device APIs etc, doesn't strike me as useful, regardless of the opinion of the people at this table, it's going to happen. So really, this discussion is just a proxy for the openness discussion.

Arve: Open source and openness those two subjects are fundamentally, simply, don't have anything to do with each other..
... You can deliver the greatest open source device in the world and you could still have the device locked down for signed applications.

Nick: Irrespective of whether OSS has a role, there could be a role in testing, etc. ??

pauld: Are you suggesting a reference implementation?

Nick: Well, I've got a particular feeling about it...
... Who are the core players here?

dougt: Geolocation is going to be one of the first implementations of device APIs within browsers.
... It'll be deployed in fennec and fx desktop client.
... In fact, in fx 3.1 the draft spec implementation is there, but with no location provider provided.
... WebKit/Apple will follow.
... If you want to model it, and it's development, then you'll want to follow it.

Nick: You're talking about the companies in that WG then?

dougt: The UAs in that group, sure, not saying they should be the only ones involved, but that's a good thread to watch.

Anil: We've got a great representation across the board, but who is going to build the scenarios we're actually talking about? Where is the developer that we're talking about? Who is representing the next killer app?
... What can we do to bring that voice here?

Nick: I think those people are identifiable.
... They are usually companies who run into the brick wall of being tied to the platform...
... They're identifiable, and should be engaged.

Anil: Build it and they will come vs build it and make sure they come.

Nick: They've hit these problems before really...

tlr: The environment we're talking about, JavaScript and DOM. There's a hell of a lot of rope for developers to hang themselves. There are lots of moving parts for these things to be secure..
... We've got things that resemble device APIs, things like the widget platforms. e.g. Google Mail widget, it had to write the subject header of a message.. so it over wrote document.innerhtml... so you could embed HTML and script in there. You could easily write a mail that could take over your computer. It's basically getting access to system(3)
... Anything that displays HTML, most apps don't use their own parser, but the HTML parser given to them by the system. Same problem, slight variant. If there is a cross site scripting problem in a page seen by a widget then it turns into a vulnerability on the computer...
... We need to keep these things in mind, in addition to just API design.
... People have been talking about least privilege capabilities... a widget declares only the capabilities that you need. In the cases that I've just listed, the widget declares that it's going to want system access...
... When talking about least privilege, think about how it will be used, what causes users to escalate privileges?

tlr: One of the reasons people use widget.system they just want to display a growl notification.
... There's a lot of rope being given to people. Conservative design of the APIs will be a very important piece.

<pauld> suggests tag for workshop of #w3cdevices

tlr: A design that lets app developers do what they need to do without shooting themselves.
... I hope the work that goes on in this room will help close the box on these issues.

Lucas: People coding the rich internet applications isn't their problem, but that we are using this stuff to work in a way that it wasn't designed to in the first place.
... The solution is to have the developer declare their intent. But those will fail at the same way, if the pace of the underlying implementation is not keeping up.
... These models have to be flexible enough to keep pace.
... New design patterns have to be supported explicitly.
... Right now we give the developer a grenade and pull the pin.
... You have to write your own parser or do complex escaping, etc.
... Right now the bar is so low that no one bothers going 'up here', when 'down here' there's enough.

Arve: We shot ourself in the foot in 1995 or so, with the introduction of <img>, which allowed off-site content. We can't really fix that.
... We have to work with the broken security model of the Web.
... We've been giving them enough to shoot themselves in the foot, but we have to make sure they don't shoot their legs off in the process.
... So, anything we do has to work with least privileges.

Lucas: We can change the sandboxes...
... Every time you think about giving folks access to things, either new APIs or new sandboxes, then you have a chance to get them to subsribe to a new security model.
... We're looking at this in content security policy...

fjh: I think tlr made a good point: if you want to use say, growl or someone elses work, people will want to do that, but there's no API for it. You can't predict what it would be. You need a way to do this without using a system call.

Lucas: Think of it in services, like here's a notificatin service, tell them what services are available, etc.
... The more generic those APIs... ??

Paddy: On JS sandboxing and eval, my project, supports those compatibly.

Nick: This WS is about device APIs, W3C and secure access. The question we need to keep in mind as we have these discussions: within this domain, what is it we need to standardize?
... There are plenty of companies here that already do these things, all in different ways.
... There are lots of big issues here, we can't do it all in one go, so what needs to be prioritized for standardization in this area?
... So at the end of these two days, we should have figured some of this out.
... So, what are the priorities so far?

??: A lot of the things going on already, specifically widget systems. Widget packages have access to device APIs, with some declaration of their security policy. Some people are talking about Web sites accessing these APIs. What are the priorities of each of these two things?

Nick: Widget vs Web contexts...

Steve: We've had to address this quite a bit, we started with the idea that only device access would come from widgets, but we had problems with that from our content providers.

tlr: If you take the widget examples I just took, most of them fail at the point where they are ??special .
... The two contexts share the environment... it's probably important to look at both at the same time, otherwise you're probably looking at more vulnerabilities. I think it's important that we don't end up diverging, but consider both together.
... If we look 5 years ahead, most interesting things will be on the Web. Making the device APIs different between the two will make it worse.

??: We should look at Widgets and Web Applications at the same time? Does that mean you should find the same security solutions?

tlr: I think we should aim to find the same solutions. There's a large cost to separating these things. The cost might be worth it.
... The cost is high and we shouldn't make the tradeoff just in passing. It needs to be a concious discussion where the two space should converge and it might make sense to separate them, if anywhere at all.

Lucas: They're already convering, right? Why would we want them to be different? You may have to reconcile the differences between the two models. How do you do that?

Paddy Byers:The distinction, if you have WebKit on the iPhone, the user doesn't know if it's a widget or a web page.
... You want the user at least aware, if not in control of what happens. ...
... The issues you're presenting the user with in those cases aren'[t that different. ...
... Maybe one is a widget install, the other is maybe a bookmark..
... In the widget space, we... <lost>
... Keeping focus on the Web site use cases is important. We're going to have the same issues.
... You may have to do these things different in the two cases, but there's no reason for the APIs to be different.

maxf: I think all of the points made thus far have been in favor of treating them the same, perhaps we all agree?

Nick: We might have to implement them in a different manner, but the intent, I think is a good one. If we could get consensus on that, it'd be good.

Arve: I do not think the same solutions will apply.

Lucas: Ideally, theoretically, the user always makes a trust decision.
... I don't think there will be any difference. i think the user will be making a decision based on a trust model based on origin.
... In the WebApps case it's ssl, in widgets it's ??

PHB: Whenever trust is said, the next thing mentioned is identity. With trust we're really interested in accountability.
... I don't care who I get my code from, I want them to be accountable.
... That's the only reason you have identity there.

A New Approach to Online Location Privacy, John Morris, CDT

See also: slides

John: proposing a new model for location privaccy ...
... user needs to be able to set privacy rules, not the web site ...
... work going on in IETF [geopriv working group] ...

Frederick: there's some work at Liberty Alliance related to that

<matt> [ the group has listed the Liberty Alliance amongst the groups it will liaise with, we'll probably be pursing that once the first draft is published ]

John: generally familiar with it. Location is a particular area that has a particular sensitivity with people...
.. I think that the idea of transmitting rules is tremedous ...

Randy: how do you bind the restriction to the information

John: you send the information as xml along with the data, but there's no techincal binding

??: but you have legal issues, tying the data with its source

<pauld> wonders if FireEagle are involved with / aware of this work

<fjh> Liberty Alliance has work in this area, Identity Governance Framework

<fjh> Application can specify data used and conditions, CARML and service provider can specify how data should be used, profile of XACML

John: true, but the legal enforcement mechanism is going to be on the 10000th case when a particular provider has a pattern of violating the rules. Data commisionners will take action

<fjh> This offers potentialy useful generic approach that leverages some existing standards like XACML

so these rules could be split off, but whoever does it could face legal action

<fjh> Related open source work exists, including some work in Higgins

PHB: on Exif. Cameras are getting GPSs. We could have whatever privacy we like. If the raw data contains wrong geo information, we have a problem

John: the photo can be retransmitted, but it's not necessarily tied to who took it

Art: John, are you aware of any IPR disclosures that have been made for Geopriv?

<fjh> URI for identity governance framework - http://www.projectliberty.org/liberty/strategic_initiatives/identity_governance

<ArtB> John, if any IPR declarations regarding Geopriv have been made, where can I find those declarations?

APIs, Safety, and User Notifications on The Web, Lucas, Mozilla

See also: Position paper, slides

tlr: if you only let top-level content do these things, then it might be worth it standardasing those messages passed

Lucas: suspect that a top-level model won't be enough in the long run

Paddy: we looked at those asynchronous APIs and we ran into problems. ...
... In some circumstances they complete synchonously and it becomes inconvenient ...
... for the programmer to handle both cases and we came to the conclusion that ...
... API wouldn't be convenient

Fabio: do you envisage some way for the site to explain why they need your location?

dougt: in the geolocation spec, we used to have an attribute to synchornously give you the location. ...
... problem is that most devices take time to start, and also you want to ask the user for permission ...
... so we dropped that, and everything is asynchronous, because the user is the decision maker

Lucas: you don't want to block the app, hence asynchronous

psd: asynchronous is good because it empowers the user. Lack of accuracy is a feature. ...
... A bit worried about my wife useing a location device, she would just turn it off

Lucas: you can have tons of information the device asks you

psd: the beauty of fireeagle, for instance, was that I tell the service where I am ...
... a kind of push model.

Geolocation fall-out II: Device APIs in the browser context, by Doug Turner (Mozilla)

<pauld> seems most geolocation use-cases involve alcohol - I'm drunk, need a taxi, pizza, waking up when my train nears the station

<pauld> scribe: pauld

identity/Policy/Trust: Secure access for widgets to resources and privileged APIs by Arve Bersvendsen (Opera Software ASA)

See also: Position paper, slides

Arve: widgets I'm talking about aren't OpenSocial/ iGoogle Web based, rather installed desktop/device software

Lucas: Adobe model is based on signatures, not origin based identity
... most widgets based on signatures?

Arve: not dashboard, Yahoo! is the only other signed widget platform I'm aware of

Randy: an alternative approach is to use registration

Anil: any thoughts on security around the execution of the script itself?

BenLaurie: my project, caja, protects against intermediary attacks

Arve: you can base this from a Web of trust, e.g. foaf, ...
... when it comes to mobile, preferred approach is the trusted vendor - ...
... application, device, network provider ...
... who do you trust enough to allow an application to run without prompts?

Fabio: do you have a notion of the capabilities a good or bad application may exploit?
... are you "just from a noble family" good enough?

Arve: we're more interested in how to deal with bad applications - making calls to premium rate nos, etc

BenLaurie: revoking a signature following an issue

StevenBellovin: it's a reputation thing, a malicious app may have a delayed impact, so. I don't think you get the accountability you really want

Arve: trust comes from assured "identity" - not going to pass on credit card details to someone I don't know

Paddy: we're talking about signatures without understanding what the signatures mean - authenticity, OK, but we shouldn't confuse identity with trust

Arve: the web model is built around certificates

tlr: interesting discussion, let's not go down that rabbit hole, just yet!

Steve: (Nokia) signatures can be used implicitly without having to make them a part of access control - (layered) and a privileged runtime maybe based on where something is installed on the filesystem

Arve: (in reply to John) geoprivacy is different to, say, payments

PHB: bad guys are infinitely capable of generating bad stuff, all data has to be signed - that's cast iron, but how to determine sources of goodness is what we need, and in ways which are compatible with open source. Less interested in "The Web of Trust" than cooperative voting/vouching systems. Web of trust ain't going to defeat the Russian Mafia

<PHB> Separate the decision of who to trust from enforcement, signatures are about enforcement, we need to move to a default deny mode of security, look for goodness, not badness, Signatures allow you to determine that the code is from your previously determined source of goodness. All code must be signed, some users will decide that code must be signed by trusted sources that meet particular criteria.

John: privacy of me isn't critical, privacy of my child might be. I realise geoprivacy not a big a beast as financial security, but can be

<tlr> xkcd.com/501

<Anil> xkcd: classic

StevenBellovin: although people maybe appear not to be trustable, or have reputation, I may still trust them in some cases, e.g. EULA attacks for software such as Kazaa

randy: a signature which is not used is useless

tlr: want to highlight two dimensions wrt to extent of trust
... how can you bring in authentication into the flow of an interaction, then there is the distinction of identity, on the Web the best we seem to have is origin, certificates not transparent or available from the URI location, what is the action the party has to take when trusting code - we're in a general discussion

David: the example of geolocation in jpegs is a slippery slope, where do we stop here? We should be careful of making Geolocation too much of a special case.

PHB: there are a number of methods of finding someone's location beyond the location device, e.g. IP address

DougT: we have a tremendous UI responsibility, and much of this is middleware, surfacing it is hard! Also, we're sending information to sites who have unclear privacy policies, for retention, etc.

lucas: trusted versus trustworthy (runs in a sandbox) is worth highlighting

dom: would the privacy concern be bound not just to the device or service but the location?

John: current location is The most important concern when it comes to privacy

<dom> dom: so problem would be less important if the API was less focused on current location

John: many of the ideas discussed sound good - advice in documents on how devices should behave, but I don't see an incompatibility on transmitting rules along with the data. We want APIs to be implemented, and W3C will lead to adoption of *code* without reading the constraints expressed in a spec, which is why we'd advocate sending rules
... geopriv in the IETF is a set of requirements to be implemented by other WGs, one binary and one XML based already, you can be compliant so long as you transmit the rules, but we don't define the format. One of the specific documents defining a format doesn't currently have extensibility, but the principle does. Most important questions: who gets the info, how long to retain, who to pass info onto

tlr: we should look less at a specific solutions, but more generic principles

BenLaurie: does retention cover logging?

John: obviously there is data which is implicitly providing location, e.g. IP address. We'd say, yes, for privacy you should periodically dump those logs. There is leakage throughout here, and doesn't prevent man in the middle attacks, it's more aimed at the intended recipient

BenLaurie: an attacker could demand you flush your logs!

<dom> Geolocation F2F minutes on Day 1

Dan: we should be careful about how we define "widget" - they are potentially a part of the Web, an extension of the Web. A security mechanism which makes sense for the Web. We (Vodafone) don't think it's true there are separate mobile and non-mobile Webs.

TiddlyWiki - a resuable non-linear personal web notebook (Paul Downey, Osmosoft.com)

See also: Position paper; presentation materials

MaxF: I really liked TiddlyWiki when I started playing with it after reading the paper
... You're talking about specific capabilities of the application - e.g. the fact that a file:// resource can be saved on some browsers
... Do you see room for standardization around this?

PaulD: not around that specifically
... what we are interested in is what the user sees
... There is a lot of variation across browsers on the way the browsers react to these use cases
... we would like more consistency on this
... the Web Security Context WG is working around these topics I believe

Ben: Have you seen the Tahoe version of TiddlyWiki?
... Tahoe is a distributed file system
... and they've integrated tiddlywiki on top of it

Paul: I hadn't heard about it - I'm seeing usage of tiddlywiki in surprising places given how convenient it proves

Usability: Lotus Rich Client Experience and Security Related Device API Requirements

See also: Position paper

Lee: I'm from IBM - presenting the paper wrote by myself and Mary Ellen Zurko
... we couldn't join the workshop physically
... we're seeing areas where standardization could help us
... Mez and I work on the Lotus division; in particular, its mobile version
... various areas where device APIs could be useful
... integrity for the software itself - e.g. to defend against virus
... relatively easy on windows mobile, by requiring signature of software
... at the other end of that, Symbian requires that the software provider gets its software signed off by @@@
... we need write access to the filesystem (e.g. to keep logs), but the operations we're trying to do are on the safe-side - nothing that would incapacitate the phone
... Another complex area is identifying the user
... done today mostly by username/password
devices with biometrics are becoming more popular
... and provide another way for authentication
... We also need the ability for an administrator to look into a device and see various capabilities / settings
... we also need to be able to do things to device - e.g. in case it is lost or stolen
... Carriers face the same pb today
... currently it is specific to the manufacturer / OS
... Finally, we're also very constrained on these devices: there is a trade off between everything and the battery
... the battery life is the focus of the manufacturers
... everything needs to be subset as much as possible so that it works even on 1MB phones where no more than 32K of memory can be allocated

Network impact of Web access to device APIs (ISOC, Mat Ford)

See also: Position paper; slides

Ben: you talked about sharing IP addresses potentially breaking some apps
... we have had a recent good example with wikipedia banning

tlr: you mentioned "further" damages - anything damage you had in mind?

mat: NAT? many other examples

PHB: I want to question the end-to-end principle
... the end of applications are not in the network - they are people, organizations
... the end to end principle has led to not putting the security in the right places

Mat: I don't think I disagree with what you said - I mentioned the end-to-end principle as a background information

Position Paper from ANT Software

See also: Position paper; slides

<PHB> luxury, when I were a lad we didn't have 300MHz, we had 1MHz, and 8-bits too

<PHB> and 16K RAM

<PHB> Tell kids today that, they won't believe you

tlr: it wasn't clear to me of divergence between your system and native apps on PC

stewart: we would like youtube to be able to use a setup box decompression hardware
... we would need to grant specific right to youtube for this

<PHB> well we used to call it RAM, it was really just a big process register, but we called it RAM because it was RAM to us

tlr: have you looked at the <video> tag? this could be answer to that specific question
... it's interesting that you describe the codec as an asset that you would need to grant specific access to

steward: I'm also thinking to things like access to your PVR
... you probably wouldn't want YouTube to upload videos from your PVR

art: do you have concrete solutions to signal security violations?

stewart: two options: simply terminate, or raise an exception

doug: I've never used one of your systems - I imagine it is sort of like TiVo?

stewart: it's more of a platform

doug: it sounds cool to have widgets on a PVR
... why wouldn't you want to allow these widgets to prompt the user for permissions to do some things?
... e.g. it would be great to have ESPN populating my scheduler based on the best sports program
... or go to someone's personal web page and import playlist from that page?

stewart: there are things that the user wants to control, others that the tV operator wants to control
... it comes down to commercial agreements
... in many cases, the operator will answer the questions on behalf of the user

nick: given how complex pvr already are, I can't image adding security-prompt making them more user-friendly :)

stewart: [example of prompt asking for 35% for bandwidth to watch a program]

PHB: this all goes down to the model of the technology provider: are the consumers citizens or subjects?

Lucas: but isn't that similar to administrators on desktops? or DRM on music?

<pauld> along with "trusted platforms" and other ideas guaranteed to die in the marketplace

Arve: we should probably leave the political discussions on DRM to the pub :)

nick: still, the two questions of "who's in control" or usability are key to these discussions

PHB: also, in some cases the user can make the choice to delegate his control to another entity

nick: interesting discussion about user prompting - I'm the only user of my phone, but my children use the TV box and could give different answers than I would to security prompts

NetFront Widgets Security Model (Marcin Hanclik, ACCESS)

See also: Position paper; slides

Fabio: why do you need authenticated widgets? This is just a wrapper - you could only monitor unauthenticated widgets

MH: this relates to our business relationships with widgets providers
... we assume that any widgets can be malicious
... we give access to very sensitive APIs

Arve: take for instance an RSS reader widget - we could sign it as coming from Opera
... but given that it reads content from external sources, it could be victim of attacks by injection of malicious content
... this makes the identification of the vendor fairly useless in this context

MH: in our model, it is possible to set the default permissions for non-authenticated widgets includes geolocation
... but in practice, the actors in the chains are unlikely to allow that
... also, our post-installation process allows to control this after installation

SteveL: One approach to work around the problems of loading external content is to downgrade the permissions if e.g. the widget modifies itself
... have you looked in this?

MH: we haven't dealt with this yet - lacking a good model based on use cases

SteveL: would be worth looking into this - each time the widget modifies what gets rendered, it loses its priviledged status

art: I heard you say you've been working on BONDI on this
... what part of this security model do you see in BONDI vs what might be applicable in the scope of W3C?

MH: my understanding is that the BONDI group wants to contribute it to W3C
... we're open to support changes in the format - we could provide transcoders
... but we want a unique standard

art: would be good to see you involved in the w3c groups

nick: the last two presentations called the case for fine-grained permissions
... they also opened the complex / political issues of policy management
... would like to open the floor on these points
... also, discussions on upfront policy management vs blacklist as highlighted by marcin

Lucas: I think it is good to separate the mechanisms of policy management and @@@
... e.g. an IT department could impose other policies than the ones defined by the operators

PHB: one of my fear is that at the end we don't discuss the concerns around the layer of policy management
... and then the business folks ignore the security questions because the policy layer doesn't match their views
... due to possible "abuse of consumers"

Nick: assuming you have strong permissioning, strong identity, strong policy management
... what to do when the application abuses its rights?

PHB: what do you call abuses? depending on the type of abuses, it might be bound to law enforcement

SMB: hard to decide when to revoke
... find it hard to trust all the police departments on the planet to decide whether or not to ban a given widget / applications
... I could trust some of them, clearly not all of them
... can we revoke the ability to revoke? there is very strong potential for abuse here too

Randy: that's why you would have a strong attribution mechanism
... so that problems that occur can be bound to the persons/devices/softwares responsible
... this leads to needs for tracking information
... but then the question is how to track abuse of this tracking

Lucas: I don't agree that the distinction between malicious and flawed is purely academic
... revoking an application doesn't revoke the damages
... I think the options for malicious applications are simple (delete / disable / @@@)
... it's different for a flawed application

tlr: 3 weeks ago, a politician got a court in Germany to issue an injunction against wikipedia.de
... made it difficult to access for a couple of days - this was revoked soon after
... If we look into 5 years ahead - we're talking about widgets, expandable applications
... it's likely some of these will become critical parts of business operations
... we need to be extremely careful about granting anyone access to supervise and trigger kill-switch for these applications
... we can't take this lightly

<tlr> http://www.techcrunch.com/2008/11/16/german-politician-blocks-local-wikipedia/

Arve: +1 to thomas
... who watches the watchers? how can the user override the watcher?
... we know that there are devices are on the market with remote kill switch

PHB: one of the reasons we set up the CA/browser forum

<tlr> we might not be getting away without *some* sort of kill switch. But we need to think about mitigating the impact of error cases for this beast.

PHB: to increase the level of accountability of certificates
... we have started looking at accountability of the revokation process
... in particular, we need to be able to give much more details on the reasons for revokation in our protocols

Nick: the differences in juridictions makes it extremely difficult to find a legal framework for these revokation systems

<tlr> phb: 'why don't you hire me to deal with that problem'

Lucas: if the service provider controls the platform, no matter what you may decide e.g. as a browser vendor, the platform provider can always override that at the systems level

Caja (Ben Laurie, Google)

See also: Position paper

Javascript compiler in and out of standard javascript with output controlled by containing page

ben_: aimed at gadget scenerio, have trusted page, but want to add gadgets to that page
... compilation enforces policy

<dom> http://www.cajadores.com/demos/testbed

ben_: example of visiting document.location to get possibly evil content
... red line in slides shows what was shown
... doug demoed geolocation api, caja compiler can modify what
... javascript receives allows a transformation as security mechanism
... can be also used for experimentation

lucas: eval is function that executes arbitrary javascript - caja is tool for building own security model

ben_: offer default material in caja
... compile javascript string at server then eval it
... could do client side by writing compiler in javascript

lucas: access to dom is needed

ben_: get access to wrapped dom, no static analysis, run time

lucas: how can good code get needed access when bad code should not

ben_: eval safe from point of view of container

steve b: how does this change javascript

ben_: effectively a whitelist

michael: cajita is smaller subset - is a larger subset possible for static validation

ben_: hard with languages that are not strongly typed

claudio: is this transparent to developer, can you guarantee code will work?

ben_: should be limited to areas that are not safe, can test it

max: how can application use api that user does not want to allow, can have fallback

ben_: yes, with if method available etc
... container can specify accuracy of location to wrap real location api, gadget unaware using wrapped version

dan: what about performance

ben_: less secure version is more expensive
... 100x slower than cajita, 3-5x slower than without wrapper

Kai: can I use on android phone

ben_: not yet
... should be possible, looking into it

tlr: looked at other cases than gadgets?

ben_: other case is clients giving javascript you want to run on server, will look at this

tlr: how about restricting access to device APIs to top-level document, could this work here

ben_: yes, can get rid of iframes, better approach

anil: how different from web sandbox

<tlr> fjh: availability?

ben_: similar, but not as extensive as cajita, have had this out for a year

<maxfroumentin> http://code.google.com/p/google-caja/

ben_: available as open source under apache license, readily available, see url

Blended Crypto (Phill Hallam-Baker, Verisign)

See also: Position paper, slides

phb: small is not beautiful when writing code
... look at device controllers, which are really small etc
... no tcp/ip since memory on order of 368 bytes ram
... in cars for example, tires with pressure sensors
... rfid devices
... anyone can listen and determine id, so can track car
... device costs less than $1, so cannot do public key
... cannot use bigger chip since smaller will get cheaper
... some say we will have rfid on every can of baked beans!
... but can do PKI
... PKI simplifies administration
... SCADA. industrial process system controllers - need security of electricity distribution grid, chemical plants etc
... do public key on device that does not do public key - delegation
... device and control system share secret, yet control system has public key, service does not know symmetric key
... device - control - service
... security context often via cookies, too many, but device authentication different than user

phb asks why not only use device authentication for accessing bank balance , i ask what if your device is stolen and it isn't you holding device?

phb: describes transparent tls crypto, see slides
... can achieve benefits of strong crypto by using hash appropriately to generate shared secret based on appropriate info based on server cert
... regarding need for user authentication relates to relative risk. Making it easier allows more frequent checking of balance, reducing some risks. Weighed against risk of misuse
... have IPR on this, for defensive purposes

need for bilateral end to end strong authentication (William Simpson, IDA)

See also: Position paper 1, slides, Position paper 2, slides

ws: web services, using security token service

ws: need ws enabled browser for this to work
... sp needs appropriate sofware
... notes issue of dealing with multiple CAs and jurisdictions

tlr: Question, particular to geolocation... What does this mean for a Geolocation JavaScript API that uses in-network location?

Randy: We'll be on the user side, and it'd be controlled from a white listing.
... The monitoring software will give us alerts...
... All software on mobile units will be registered and signed.
... it should be easy to find code that's not part of the process. That's in progress.

Fabio: Since this is on the device... We tried with Docomo to try to do Web services security on the device. Do you think this could end up on the mobile?

Randy: We have a much more closed system and a much lower threshold for loses.
... We are going to take more cycles.
... I have applications like two airplanes talking to one another, the cycles are dear.

pauld: It seems like an interesting domain. Difficult constraints and problems to solve. I'm worried that this would be seen as a generic solution, the fat browser bits make me a bit alarmed. Have you seen the MS work on this area?

Randy: One of our solutions is not a fat browser but an appliance
... Trying to fit these things into the commercial space... we realize the closer we move to the commercial space the cheaper it will be.

pauld: In the commercial space I work hard in avoiding central points of control
... there's a mismatch though, I'm concerned that I know the bank is the bank, and not so much worried about the bank knowing I am me.
... MS did a lot of work in the way devices are hooked up to Vista. You should look into it.

Randy: We've got two solution spaces, J2EE and .NET. Also going to have to look at Solaris and Linux.

Wrap Up

tlr: Looking at tomorrow's agenda...
... At the moment there are things about Widgets security policy. We'll hear from Nokia about security models...
... BONDI will be presented... WebVM security policy.
... After that, Sony Ericsson about MIDP based security model for widgets.
... Then Fabio will talk about security by contract.
... Tomorrow afternoon is an open agenda, we'll be working out something
... and trying to figure out what to do next, what useful things we got out of this .etc
... Dinner tonight, not before 7.

DKA: Going to Porter House Pub leaving immediately after.
... it's a five minute walk and Porterhouse is in between.
... About the Web... I hope we focus on that concept somehow during the discussion.
... In terms of what W3C can do, what needs to happen to make it become part of the Web as we know it.

<maxfroumentin> +1

tlr: We're done. Thank you!

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/01/26 11:14:41 $