IRC log of wam on 2009-05-18

Timestamps are in UTC.

11:00:13 [RRSAgent]
RRSAgent has joined #wam
11:00:14 [RRSAgent]
logging to
11:00:25 [ArtB]
Meeting: Widgets Security Model Voice Conf
11:00:29 [ArtB]
Date: 18 May 2009
11:00:46 [tlr]
zakim, call thomas-781
11:00:46 [Zakim]
ok, tlr; the call is being made
11:00:48 [Zakim]
11:01:20 [ArtB]
ScribeNick: ArtB
11:01:25 [ArtB]
Chair: Art
11:01:30 [tlr]
+1 to Art not scribing
11:01:42 [ArtB]
Present: Art, Arve, Marcos, Thomas
11:02:46 [ArtB]
Scribe: Robin
11:02:51 [ArtB]
ScribeNick: darobin
11:03:01 [ArtB]
RRSAgent, make log Public
11:03:13 [Zakim]
11:03:29 [tlr]
zakim, ??P2 is darobin
11:03:29 [Zakim]
+darobin; got it
11:03:29 [ArtB]
zakim, ??P2 is Robin
11:03:30 [Zakim]
I already had ??P2 as darobin, ArtB
11:04:15 [ArtB]
11:04:46 [darobin]
AB: agenda a bit vague, but has pointers to previous discussions
11:05:16 [darobin]
AB: we don't have consensus yet, we need it for LC
11:05:54 [darobin]
AB: 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
11:06:14 [darobin]
AB: 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
11:07:06 [darobin]
Zakim, mute me
11:07:06 [Zakim]
darobin should now be muted
11:07:28 [darobin]
MC: the first thing we need consensus on is whether we want the HTML5 model
11:07:39 [darobin]
zakim, unmute me
11:07:39 [Zakim]
darobin should no longer be muted
11:08:02 [tlr]
zakim, who is muted?
11:08:02 [Zakim]
I see no one muted
11:08:20 [darobin]
MC: if we are going to use the HTML5 model we need some kind of opt-in or it should be on by default
11:08:41 [darobin]
TLR: It think there is a more nuanced question to ask: which part of that model we need
11:09:03 [darobin]
TLR: it governs access to cookies, frames, network (XHR and inline), and storage + other APIs
11:09:05 [darobin]
MC: right
11:09:24 [darobin]
TLR: I think the discussion is largely around network access, possibly storage
11:09:42 [darobin]
TLR: haven't seen much discussion about the others, but they will materialise once access is given
11:09:54 [darobin]
TLR: the quesiton is largely around network access
11:10:29 [darobin]
Arve: I don't think it's possible to separate network access as a boolean from the general model and how you compute origin
11:10:41 [darobin]
TLR: why?
11:11:28 [darobin]
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
11:12:19 [darobin]
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
11:12:49 [darobin]
TLR: 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
11:13:19 [darobin]
Arve: the background is that Opera's implementation used to treat inlines as they did in HTML4
11:13:43 [darobin]
Arve: however that's not an acceptable model when allowing access to a phone's address book
11:13:54 [darobin]
Arve: because you have potential information leakage
11:14:18 [darobin]
TLR: that is a fundamental point for the DAP WG's charter
11:14:52 [darobin]
TLR: the quesiton is what is the scope of the question
11:15:06 [darobin]
TLR: can we solve this and reach decision without solving the DAP WG's problem
11:15:21 [darobin]
Arve: what I'm saying is that you can't make a decisin on one without making a decision on both
11:15:37 [darobin]
Arve: security is intertwined with the Device API
11:15:51 [darobin]
Arve: I think we should be gathering requirements and use cases, and figure out where we can go
11:16:16 [darobin]
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
11:16:38 [darobin]
Arve: if you do that I think you'll end up with conforming but not interoperable
11:16:56 [darobin]
TLR: so is Opera saying that P+C shouldn't enter LC before DAP has concluded?
11:17:10 [darobin]
Arve: no, I think this is hard to answer
11:17:26 [darobin]
Arve: I don't think we can ship widgets without a security model
11:17:46 [darobin]
TLR: I agree on your meta-meta point that it would have been nice to do this earlier, but it hasn't happened
11:18:15 [darobin]
TLR: 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?
11:18:22 [darobin]
Arve: I don't think it's possible
11:18:33 [darobin]
Arve: it can be done in a short time, but I don't think we can skim
11:19:12 [darobin]
Arve: if the P+C has syntax that doesn't match the security, it is meaningless
11:19:15 [darobin]
MC, TLR: agree
11:19:30 [darobin]
MC: the specs are broken apart for editorial, not technical reasons
11:19:45 [darobin]
MC: we could say as we do for window modes, these are the correct WMs
11:20:05 [darobin]
MC: we could have an origin attribute with html5, any, etc and given that have enough to go on
11:20:53 [darobin]
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
11:20:55 [darobin]
MC: why?
11:21:23 [darobin]
TLR: because if the framework is the html5 model, then any network resource is accessible
11:21:32 [darobin]
TLR: I woulndn't go there
11:22:01 [darobin]
TLR: we're talking mechanism when we should be talking goals
11:23:49 [darobin]
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
11:23:58 [darobin]
RB: based on our IRC discussion
11:24:17 [darobin]
AB: if we don't do anything, will OMTP define its own?
11:24:19 [darobin]
RB: yes
11:24:35 [darobin]
AB: and they'll leave it as an implementation model?
11:25:16 [darobin]
RB: the original OMTP model was that everything was closed, and the access element could be used to open it
11:25:53 [darobin]
TLR: is it a workable compromise to close everything and use access to open all network? (inline+xhr)
11:26:20 [darobin]
TLR: 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
11:26:29 [darobin]
TLR: we don't want to constrain DAP with a hack
11:27:02 [darobin]
TLR: this WG should restrain itself from enforcing its solution
11:27:23 [darobin]
TLR: 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
11:28:23 [tlr]
s/this WG should restrain itself from enforcing its solution/this WG should not try to solve the entire device API problem/
11:28:44 [darobin]
Arve: you are making one assumption too many
11:28:59 [darobin]
Arve: the html5 model is completely adequate in a few set of cases
11:29:25 [darobin]
Arve: we have two completely different security contexts here
11:30:15 [arve]
I'll type here
11:30:29 [arve]
1. Let's say you have a web UA that has "Save as Widget" for web pages
11:30:42 [arve]
for instance on GMail
11:31:11 [arve]
Zakim, who is making noise
11:31:11 [Zakim]
I don't understand 'who is making noise', arve
11:31:14 [arve]
Zakim, who is making noise?
11:31:29 [Zakim]
arve, listening for 15 seconds I heard sound from the following: Marcos/Arve (58%), darobin (2%)
11:31:55 [darobin]
Arve: in this use case we have a web page converted into a widget
11:32:10 [tlr]
why would that use the P&C framework?
11:32:10 [darobin]
Arve: or running widgets on the web, like Google gadgets, that sort of thing
11:32:19 [darobin]
Arve: those are fine inside the HTML5 security model
11:32:26 [darobin]
Arve: and we need to offer them that option
11:32:55 [darobin]
Arve: case 2 is when you have third-party information available to the widget (ie device APIs) or limited cross-origin access
11:33:11 [darobin]
Arve: e.g. scraping Google while tlaking to your Yahoo account
11:33:29 [darobin]
Arve: or talking to your Yellow Pages and matching against the phone book on your device
11:33:53 [darobin]
Arve: there, the HTML5 security model is too thin, information can be leaked
11:34:03 [darobin]
TLR: you are making one assumption too many about what I said
11:34:30 [darobin]
TLR: 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
11:34:43 [darobin]
TLR: for any network access, restrict the HTML5 model further
11:34:57 [darobin]
Arve: I think I agree with this
11:35:06 [darobin]
Arve: I think we agree on the end result
11:35:10 [tlr]
1. no origin inside the package
11:35:24 [tlr]
2. random origin generated at instantiation time
11:35:29 [darobin]
Arve: I think we need a model that striclty enforces which networks can be reached
11:35:38 [tlr]
3. use HTML5 mode, *but* cut down on network access, unless <access> is used to grant network access
11:35:38 [darobin]
Arve: this is turtles all the way down
11:35:44 [darobin]
s/network/network resoruces/
11:35:48 [tlr]
11:36:25 [darobin]
Arve: any network access within any resources, in addition to the html5 checks is also subject to what the widget says it can access
11:36:35 [darobin]
TLR: specifically about iframes?
11:36:41 [darobin]
Arve: no, everything
11:37:15 [hendry]
hendry has joined #wam
11:37:21 [darobin]
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
11:37:28 [darobin]
TLR: (or img, or script)
11:37:38 [darobin]
TLR: there MUST be an access element that allows that
11:38:02 [darobin]
TLR: then, the communication between the various DOM, and the rest, is governed by the HTML5 security model
11:38:34 [darobin]
TLR: so to *get* an iframe from, the widget needs an <access> element to let it do that, but then the rest is subject to html5
11:38:56 [darobin]
Arve: if you have recursive inclusion, what rules govern that?
11:39:00 [darobin]
TLR: html5
11:39:20 [darobin]
TLR: if I've granted access to, if they collaborate with, then there's nothing I can do anyway
11:39:38 [darobin]
Arve: my point is that an origin on the web might be an origin you trust
11:39:51 [darobin]
Arve: so I might trust a widget to access my domain
11:40:13 [darobin]
Arve: but if my domain has a security hole that has an XSS issue that includes an injection from a third-party
11:40:31 [darobin]
Arve: then if <access> prevent third-domain access, I will be protected against that
11:41:20 [darobin]
TLR: I think that that approach is a very likely recipe for disaster — because of complexity
11:41:41 [darobin]
TLR: my assymption is that if I'm in an iframe that comes from the web, it will not have access to device APIs
11:42:07 [arve]
1. Inject script into widget main document
11:42:09 [darobin]
TLR: I'm also assuming that an iframe inside a widget, whatever access that iframe has follows the traditional sandboxing
11:42:19 [darobin]
TLR: so it gets to the web, not to the APIs
11:42:20 [arve]
2. Read content without legitimate access
11:42:40 [arve]
3. Use hole in widget to inject content (specifically scripts) into
11:43:00 [arve]
4. Let injected content point to
11:43:13 [darobin]
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
11:43:32 [darobin]
Arve: you're making an assymption about implementer complexity
11:43:42 [darobin]
Arve: look at the script inhection above
11:44:16 [darobin]
Arve: that content is injected into your trusted resource
11:44:36 [darobin]
Arve: this is not far-fetched — and it circumvents the access policy that you describe
11:44:44 [darobin]
Arve: that
11:44:48 [darobin]
11:45:14 [darobin]
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
11:45:40 [darobin]
TLR: what I'm disputing is that we're creating a separate execution context for web content
11:46:01 [darobin]
TLR: and I think we shouldn't be prepared to go there, it's out of scope and not the simplest option
11:46:21 [darobin]
TLR: the complexity I'm worrying about is not implementers' complexity but adding YA secuirty model
11:46:31 [darobin]
TLR: want to keep it as simple as possible
11:46:59 [darobin]
Arve: this doesn't imply increased complexity in the system, only the runtime has to check that access rules are permitted
11:47:55 [darobin]
TLR: our contention is about the access that an external web app gets through the network when running inside an iframe inside the widget
11:48:20 [darobin]
TLR: the increased complexity is likely not written specfiically for the widget execution context
11:48:37 [darobin]
TLR: and we're changing the way that web app expects to be run
11:49:12 [darobin]
Arve: if an application doesn't expect to be run in a widget, it's not going to request to run DAs
11:49:41 [darobin]
Arve: my proposal is that a) access to APIs with stricter checks, and b) the html5 context without such access
11:50:00 [darobin]
Arve: enforcing access only one level down is not going to be acceptable to operators
11:50:30 [arve]
Two models: 1) No extended access, computed http origin, running without extended access, or awareness of sensitive apis
11:50:39 [arve]
2) Extended access, subject to strict security model
11:50:43 [darobin]
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
11:51:14 [darobin]
TLR: so you say you get a different execution context for iframe inside a widget and I think that's risky
11:51:35 [darobin]
Arve: the only deviation I propose is that <access> applies all the way down
11:51:47 [darobin]
Arve: as implementers this is simpler too
11:52:31 [darobin]
TLR: my proposal is if orgin = web then use web model, if origin = synthetic then use restricted access model
11:53:54 [darobin]
AB: let's summarise agreement
11:54:07 [darobin]
AB: and see what we can do about disagreement
11:55:38 [darobin]
Arve talks of a former Opera proposal
11:57:13 [darobin]
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
11:57:17 [darobin]
AB: is that fair?
11:57:52 [darobin]
TLR: I would add that I think we have agreement for anything that has come through an intermediary — should go through access control
11:58:11 [darobin]
TLR: I think we have disagreement about what happens with inline context, and what SM should apply there
11:58:25 [darobin]
TLR: I'm saying just web model, and Arve is saying needs further constraints
11:58:49 [arve]
11:59:23 [arve]
11:59:26 [darobin]
TLR: I can't join on thursday
11:59:41 [darobin]
TLR: I can do Wednesday same time
11:59:54 [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
12:00:01 [darobin]
AB: I can't but it's okay if you do it without me
12:00:21 [darobin]
Thursday is a public holiday in many places
12:00:35 [darobin]
RB: tomorrow same time?
12:00:38 [darobin]
TLR, AB: fine
12:00:52 [arve]
12:00:56 [darobin]
AB: homework, take a look at Arve's model and discuss tomorrow
12:01:17 [darobin]
AB: also think about splitting <access> out of P+C so that P+C could proceed through LC
12:01:24 [arve]
12:01:55 [darobin]
Arve: before you read the document, understand asumptions that externally ref'd documents are still subject to the web SM
12:02:15 [arve]
... with the addition of network restrictions
12:02:24 [arve]
... as enforced by config.xml
12:02:59 [darobin]
TLR: so what's described is what happens in addition to the basic security model
12:03:03 [darobin]
Arve: yes
12:03:06 [darobin]
TLR: good
12:03:39 [Zakim]
12:03:40 [ArtB]
RRSAgent, make minutes
12:03:40 [RRSAgent]
I have made the request to generate ArtB
12:03:41 [Zakim]
12:03:49 [Zakim]
12:03:53 [Zakim]
12:03:55 [Zakim]
Team_(wa)11:00Z has ended
12:03:56 [Zakim]
Attendees were Art_Barstow, Marcos/Arve, Thomas, darobin
12:04:13 [tlr]
conference Team_(wa)11:00Z scheduled with code 83261 (TEAM1) tomorrow at 11:00Z for 60 minutes until 1200Z
12:04:25 [tlr]
artb, see above for code for tomorrow
12:04:30 [tlr]
it's actually the same as today
12:04:32 [ArtB]
AB: Same time tomorrow; same channel; different PIN to be annouced in this channel
12:04:50 [ArtB]
tlr, roger that
12:05:01 [ArtB]
AB: meeting ajdourned
12:05:05 [ArtB]
RRSAgent, make minutes
12:05:05 [RRSAgent]
I have made the request to generate ArtB
12:05:22 [Marcos]
Marcos has joined #wam
12:06:36 [ArtB]
zakim, bye
12:06:36 [Zakim]
Zakim has left #wam
12:06:41 [ArtB]
rrsagent, bye
12:06:41 [RRSAgent]
I see no action items