Widgets Security Model Voice Conf -- 18 May 2009

<ArtB> Date: 18 May 2009

<ArtB> ScribeNick: ArtB

<tlr> +1 to Art not scribing

<scribe> Scribe: Robin

<scribe> ScribeNick: darobin

AB: agenda a bit vague, but has pointers to previous discussions
... we don't have consensus yet, we need it for LC
... this is the last piece that we need to get nailed down, we're under time pressure to get this out for people to start implementing
... ideally at the end of this meeting we will have consensus about what it is we need to do to get LC out this week

MC: the first thing we need consensus on is whether we want the HTML5 model
... if we are going to use the HTML5 model we need some kind of opt-in or it should be on by default

TLR: It think there is a more nuanced question to ask: which part of that model we need
... it governs access to cookies, frames, network (XHR and inline), and storage + other APIs

MC: right

TLR: I think the discussion is largely around network access, possibly storage
... haven't seen much discussion about the others, but they will materialise once access is given
... the quesiton is largely around network access

Arve: I don't think it's possible to separate network access as a boolean from the general model and how you compute origin

TLR: why?

Arve: because in terms of context for an extended permission model which we have already allowed in existing implementations, you run into the case where resolving a URI in itself and trying to request it is alreay a source of information leakage

TLR: what I was saying was that as far as communication and access within the WRT the only thing I see on the table is the html5 security model
... I think that Opera has a separate model to grant access to URI, but I haven't heard you saying that you are deviating from the HTML5 security model

Arve: the background is that Opera's implementation used to treat inlines as they did in HTML4
... however that's not an acceptable model when allowing access to a phone's address book
... because you have potential information leakage

TLR: that is a fundamental point for the DAP WG's charter
... the quesiton is what is the scope of the question
... can we solve this and reach decision without solving the DAP WG's problem

Arve: what I'm saying is that you can't make a decisin on one without making a decision on both
... security is intertwined with the Device API
... I think we should be gathering requirements and use cases, and figure out where we can go

TLR: do you think it is possible for P+C to enter LC with a minimal security model that another WG can build on within the timeframe of a few weeks

Arve: if you do that I think you'll end up with conforming but not interoperable

TLR: so is Opera saying that P+C shouldn't enter LC before DAP has concluded?

Arve: no, I think this is hard to answer
... I don't think we can ship widgets without a security model

TLR: I agree on your meta-meta point that it would have been nice to do this earlier, but it hasn't happened
... but is there a minimal piece of model that a) needs to be specified, and b) can be specified without solving DAP, and c) can be done in a very short time?

Arve: I don't think it's possible
... it can be done in a short time, but I don't think we can skim
... if the P+C has syntax that doesn't match the security, it is meaningless

MC, TLR: agree

MC: the specs are broken apart for editorial, not technical reasons
... we could say as we do for window modes, these are the correct WMs
... we could have an origin attribute with html5, any, etc and given that have enough to go on

TLR: you want to specify an origin where the value of that element/attribute would not be bound by anything to the widget — I think that would be a disaster

MC: why?

TLR: because if the framework is the html5 model, then any network resource is accessible
... I woulndn't go there
... we're talking mechanism when we should be talking goals

RB: I thought we had some rough path towards consensus using the strictest access as default, some syntax to switch to html5, and a way of using strict+the access mechanism
... based on our IRC discussion

AB: if we don't do anything, will OMTP define its own?

RB: yes

AB: and they'll leave it as an implementation model?

RB: the original OMTP model was that everything was closed, and the access element could be used to open it

TLR: is it a workable compromise to close everything and use access to open all network? (inline+xhr)
... my goal is to a) not hold up things, and b) not devise something ad hoc that will come back to haunt this WG and DAP
... we don't want to constrain DAP with a hack
... this WG should not try to solve the entire device API problem
... but I hear Arve say that the HTML5 model is too flawed, and if that's the case then I don't know how to move this forward

Arve: you are making one assumption too many
... the html5 model is completely adequate in a few set of cases
... we have two completely different security contexts here

<arve> I'll type here

<arve> 1. Let's say you have a web UA that has "Save as Widget" for web pages

<arve> for instance on GMail

Arve: in this use case we have a web page converted into a widget

<tlr> why would that use the P&C framework?

Arve: or running widgets on the web, like Google gadgets, that sort of thing
... those are fine inside the HTML5 security model
... and we need to offer them that option
... case 2 is when you have third-party information available to the widget (ie device APIs) or limited cross-origin access
... e.g. scraping Google while tlaking to your Yahoo account
... or talking to your Yellow Pages and matching against the phone book on your device
... there, the HTML5 security model is too thin, information can be leaked

TLR: you are making one assumption too many about what I said
... I thikn that the HTML5 model should be used for some things (eg inter-frame comm), but cut down on anything that accesses the network
... for any network access, restrict the HTML5 model further

Arve: I think I agree with this
... I think we agree on the end result

<tlr> 1. no origin inside the package

<tlr> 2. random origin generated at instantiation time

Arve: I think we need a model that striclty enforces which networks can be reached

<tlr> 3. use HTML5 mode, *but* cut down on network access, unless <access> is used to grant network resoruces access

Arve: this is circles all the way down
... any network access within any resources, in addition to the html5 checks is also subject to what the widget says it can access

TLR: specifically about iframes?

Arve: no, everything

TLR: proposal (for use case 2) get a zip archive, it includes a widget, that widget wants an iframe, in order to get it it needs to access the network
... (or img, or script)
... there MUST be an access element that allows that
... then, the communication between the various DOM, and the rest, is governed by the HTML5 security model
... so to *get* an iframe from a.com, the widget needs an <access> element to let it do that, but then the rest is subject to html5

Arve: if you have recursive inclusion, what rules govern that?

TLR: html5
... if I've granted access to a.com, if they collaborate with evil.com, then there's nothing I can do anyway

Arve: my point is that an origin on the web might be an origin you trust
... so I might trust a widget to access my domain
... but if my domain has a security hole that has an XSS issue that includes an injection from a third-party
... then if <access> prevent third-domain access, I will be protected against that

TLR: I think that that approach is a very likely recipe for disaster — because of complexity
... my assymption is that if I'm in an iframe that comes from the web, it will not have access to device APIs

<arve> 1. Inject script into widget main document

TLR: I'm also assuming that an iframe inside a widget, whatever access that iframe has follows the traditional sandboxing
... so it gets to the web, not to the APIs

<arve> 2. Read content without legitimate access

<arve> 3. Use hole in widget to inject content (specifically scripts) into example.com/someurl

<arve> 4. Let injected content point to evil.com/someotherurl

TLR: all of that will get a lot more complex when we expose device APIs to the web proper — I share the concerns but right now can we try to constrain the model to make clear when the code can do stuff on web and reuse the html5 model

Arve: you're making an assymption about implementer complexity
... look at the script inhection above
... that content is injected into your trusted resource
... this is not far-fetched — and it circumvents the access policy that you describe
... that

bah

Arve: that's why I think that inner resources should not have access to the DA, and that they should all have the same network restrictions

TLR: what I'm disputing is that we're creating a separate execution context for web content
... and I think we shouldn't be prepared to go there, it's out of scope and not the simplest option
... the complexity I'm worrying about is not implementers' complexity but adding YA secuirty model
... want to keep it as simple as possible

Arve: this doesn't imply increased complexity in the system, only the runtime has to check that access rules are permitted

TLR: our contention is about the access that an external web app gets through the network when running inside an iframe inside the widget
... the increased complexity is likely not written specfiically for the widget execution context
... and we're changing the way that web app expects to be run

Arve: if an application doesn't expect to be run in a widget, it's not going to request to run DAs
... my proposal is that a) access to APIs with stricter checks, and b) the html5 context without such access
... enforcing access only one level down is not going to be acceptable to operators

<arve> Two models: 1) No extended access, computed http origin, running without extended access, or awareness of sensitive apis

<arve> 2) Extended access, subject to strict security model

TLR: so you're saying that one level down has access to DA, but I think that concern applies to the same way with any web app that deals with sensitive data and we're accepting it there
... so you say you get a different execution context for iframe inside a widget and I think that's risky

Arve: the only deviation I propose is that <access> applies all the way down
... as implementers this is simpler too

TLR: my proposal is if orgin = web then use web model, if origin = synthetic then use restricted access model

AB: let's summarise agreement
... and see what we can do about disagreement

Arve talks of a former Opera proposal

AB: TLR put forward a proposal that passed the "I can live with" test for LC, whereas Arve seems to require more work which would delay things
... is that fair?

TLR: I would add that I think we have agreement for anything that has come through an intermediary — should go through access control
... I think we have disagreement about what happens with inline context, and what SM should apply there
... I'm saying just web model, and Arve is saying needs further constraints

<arve> http://lists.w3.org/Archives/Public/public-appformats/2008Apr/0096.html

<arve> specifically, http://lists.w3.org/Archives/Public/public-appformats/2008Apr/att-0096/w3c-security.html

TLR: I can't join on thursday
... I can do Wednesday same time

<arve> marcos: you're not entirely aware of what you're asking, because "running a file in a browser" is known to not be cross-browser compatible

AB: I can't but it's okay if you do it without me

Thursday is a public holiday in many places

RB: tomorrow same time?

TLR, AB: fine

AB: homework, take a look at Arve's model and discuss tomorrow
... also think about splitting <access> out of P+C so that P+C could proceed through LC

Arve: before you read the document, understand asumptions that externally ref'd documents are still subject to the web SM

<arve> ... with the addition of network restrictions

<arve> ... as enforced by config.xml

TLR: so what's described is what happens in addition to the basic security model

Arve: yes

TLR: good

<tlr> conference Team_(wa)11:00Z scheduled with code 83261 (TEAM1) tomorrow at 11:00Z for 60 minutes until 1200Z

<tlr> artb, see above for code for tomorrow

<tlr> it's actually the same as today

<ArtB> AB: Same time tomorrow; same channel; different PIN to be annouced in this channel

<ArtB> tlr, roger that

<ArtB> AB: meeting ajdourned

- DRAFT -

Widgets Security Model Voice Conf

18 May 2009

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output