See also: IRC log
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.
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
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.
<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.
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?
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.
<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
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.
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
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
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
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
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
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
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
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.
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!