11:00:13 <RRSAgent> RRSAgent has joined #wam
11:00:14 <RRSAgent> logging to http://www.w3.org/2009/05/18-wam-irc
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> +Thomas
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> +??P2
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> Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0535.html
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> s/turtles/circles/
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 a.com, 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 a.com, if they collaborate with evil.com, 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 example.com/someurl
11:43:00 <arve> 4. Let injected content point to evil.com/someotherurl
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> bah
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> http://lists.w3.org/Archives/Public/public-appformats/2008Apr/0096.html
11:59:23 <arve> specifically, http://lists.w3.org/Archives/Public/public-appformats/2008Apr/att-0096/w3c-security.html
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> q+
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> q-
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> -Thomas
12:03:40 <ArtB> RRSAgent, make minutes
12:03:40 <RRSAgent> I have made the request to generate http://www.w3.org/2009/05/18-wam-minutes.html ArtB
12:03:41 <Zakim> -Marcos/Arve
12:03:49 <Zakim> -darobin
12:03:53 <Zakim> -Art_Barstow
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 http://www.w3.org/2009/05/18-wam-minutes.html 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