11:02:40 <RRSAgent> RRSAgent has joined #wam
11:02:40 <RRSAgent> logging to http://www.w3.org/2009/05/19-wam-irc
11:03:40 <ArtB> ScribeNick: ArtB
11:03:44 <ArtB> Chair: Art
11:04:14 <darobin> marcos is in a bad mood :)
11:04:29 <ArtB> Date: 19 May 2009
11:04:42 <ArtB> Meeting: Widgets Security Model Voice Conf
11:04:48 <ArtB> Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0539.html
11:05:02 <Zakim> +??P2
11:05:32 <darobin> Zakim, ??P2 is me
11:05:32 <Zakim> +darobin; got it
11:05:39 <ArtB> Present: Art, Thomas, Jere, Robin
11:05:43 <Marcos> dialing in..
11:05:46 <Zakim> + +47.23.69.aaaa
11:05:54 <arve> zakim, aaaa is me
11:05:54 <Zakim> +arve; got it
11:06:12 <ArtB> Present+ Marcos 
11:06:15 <Marcos> zakim, passcode
11:06:16 <Zakim> I don't understand 'passcode', Marcos
11:06:20 <ArtB> Present+ Arve
11:06:26 <ArtB> ScribeNick: darobin
11:06:26 <Marcos> zakim, passcode?
11:06:26 <Zakim> the conference code is 83261 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), Marcos
11:06:36 <ArtB> Topic: Widget Security Model
11:06:50 <Zakim> +??P4
11:07:01 <Marcos> zakim, ??P4 is me
11:07:01 <Zakim> +Marcos; got it
11:07:56 <darobin> AB: there has been discussion on the list
11:07:57 <ArtB> AB: new thread was started http://www.w3.org/mid/b21a10670905190218k2645cf5dh5506bdf7be243330@mail.gmail.com
11:08:47 <darobin> AB: there seems to be agreement between some of TLR and MC, and Vodafone supports TLR's model
11:08:55 <darobin> AB: Arve is not happy with either proposal
11:09:24 <darobin> Arve: I think we have an irreconcialable difference between two app models for the web
11:09:38 <darobin> Arve: one in which you have the traditional model under the html5 model largely
11:10:13 <darobin> Arve: I'm fine with supporting that model, but that model's security breaks down as soon as you allow access to an extended API (e.g. FS, phone book, anything sensitive)
11:10:27 <darobin> Arve: that model, given how it handles inline content, become useless
11:10:51 <darobin> Arve: the diff between stealing data from that device whether you allow XD XHR or not is none
11:10:58 <darobin> Arve: if I read all the phone book
11:11:07 <darobin> Arve: I can just pass it through an img object
11:11:20 <darobin> Arve: and send it bit by bit within that secrity model
11:11:43 <darobin> Arve: you're on your own if you don't restrict that
11:11:59 <tlr> q+
11:12:03 <darobin> Arve: we need to restrict that model further the moment you put anything in a feature element
11:12:38 <darobin> Arve: in terms of supporting models I see why we want to support the html5 model because then you can synthesise widgets from existing sources — I support that
11:12:55 <darobin> Arve: but that model can never be used in conjunction with sensitive APIs — which is my entire protest
11:13:19 <darobin> Arve: then there's the question of what is the default, and what happens if the widget requires the html5 model and a sensitive API at the same time
11:13:36 <darobin> AB: trying to understand:
11:13:37 <ArtB> AB: Arve's email http://www.w3.org/mid/op.ut6avtgrbyn2jm@galactica
11:14:14 <darobin> AB: you conclude with the strong statement that removign the access element from 1.0 and putting it into 2.0 is something you would not support even if it means delaying
11:14:20 <darobin> AB: we need to discuss that too
11:14:45 <darobin> TLR: what I hear Arve say is that in the moment a widget touches anything feature-enabled, the widget must not access the network
11:14:56 <darobin> Arve: it must have no entry point to the network that is not declared
11:15:22 <darobin> TLR: there are two ways to satisfy this requirement
11:15:45 <darobin> TLR: one is if you have <feature>, access may not occur or implementations decide
11:16:31 <darobin> TLR: the other is the fine grained thing where you're puytting the control of the data under the entity running the widget, and you move the responsibility there
11:17:09 <darobin> Arve: for any data that is put into the cloud you need to trust who you give it to
11:17:26 <darobin> Arve: you implicitly trust Google not to do any bad between with your GMail phone book
11:17:41 <darobin> Arve: the trust between a third party and the user, and not of our concern
11:19:14 <darobin> Arve: it's one thing to inject content that is misinterpreted, and in that case our responsibility is to ensure that when Alice and Bob talk to each other we provide a mechanism to make sure they stay safe
11:19:43 <darobin> Arve: what I'm trying to ensure is that information from a feature-API should not get anywhere it shouldn't
11:19:53 <darobin> TLR: are you assuming all those APIs are read-only?
11:19:55 <darobin> Arve: no
11:20:09 <darobin> Arve: RW APIs are a different ball park
11:20:25 <darobin> Arve: we can't ensure that no data destruction happens — simply that it doesn't get into the wrong hands
11:20:42 <darobin> TLR: if you have an SMS API, you have a potential leak anyway
11:21:04 <darobin> TLR: could you live with within the scope of the 1.0 spec there is no specified model if both feature and access are present
11:21:21 <darobin> TLR: IOW if someone uses feature APIs UAs could impose a restriction
11:21:42 <darobin> TLR: if feature is used, you are not guaranteed any access to the network
11:21:57 <arve> Zakim: q+
11:22:01 <darobin> TLR: my goal is to not create an almost-html5 model that will then constrain DAP
11:22:08 <JereK> q+
11:22:16 <arve> q+
11:22:44 <darobin> AB: I support that kind of proposal, and would like to make sure that we don't take on the work of the DAP WG and solve everything here
11:22:57 <darobin> AB: and that what we do provides a reasonably transition path
11:23:11 <darobin> q+
11:23:33 <tlr> q-
11:24:03 <darobin> JK: looking at the discussion, it seems to me that the access and the feature elements are quite orthogonal, they don't govern the same kind of access
11:24:13 <darobin> JK: it's futile to try to shoehorn them into the same model
11:24:45 <darobin> JK: a device API security model and a generic network access model are orthogonal, it's probably not fruitful to discuss them both at the same time
11:25:19 <darobin> JK: so it's up to DAP to define the further security model for those API, we could farm these things out like we did for the update element
11:25:31 <darobin> JK: we are feature-complete for packaging, we could go ahead with that
11:26:16 <darobin> Arve: going back to the almost-html5 model, the problem with the same-origin policy is that it locks access to already useful API, which is unfortunate
11:26:41 <darobin> Arve: 1000s of widgets already written have made use of non-restricted x-domain policy
11:26:46 <tlr> q+
11:26:54 <darobin> Arve: it is unfortunate if those cannot be solved within the new model
11:26:55 <JereK> q-
11:27:18 <tlr> I wasn't even talking about cross-origin, and would note that access actually covers that.
11:27:46 <darobin> Arve: the other bit is also that while I agree that the security model of APIs v access are orthogonal, there are good reasons to say that a given API would require a different security model
11:27:56 <darobin> Arve: in which case using an API alters the security model of the widget
11:28:29 <darobin> Arve: I'm not sure we want to allow a random resource in an API to alter to SM and leave the SM to that API because it will be misused/misunderstood
11:28:59 <darobin> Arve: someone will come up with an API that will open up too many things, or incompatible implementations
11:29:27 <darobin> Arve: as much as I'd like to deal with this later, but in the meantime we'll grow incompatible implementaions
11:29:32 <tlr> ack a
11:29:33 <tlr> ack d
11:29:33 <arve> q-
11:29:50 <tlr> darobin: getting slightly confused
11:29:59 <tlr> ... discussion crossing ...
11:30:06 <tlr> ... model as understand it ...
11:30:24 <tlr> ... "anything that comes from the widget is under control of access and feature, anything referenced outside, is under web model" ...
11:30:29 <tlr> ... those things don't communicate that much ...
11:30:38 <tlr> ... perhaps a few issues with script references ...
11:30:46 <tlr> ... don't think this increases attack surface that much ...
11:30:48 <arve> q+
11:31:03 <tlr> ... if we restrict original content, then have useful level of security ...
11:31:14 <tlr> ... don't see attacks as being any more important than what we already see today ...
11:31:42 <darobin> Arve: I would like to point out a collision
11:31:46 <arve> <iframe src="foo?bar=baz">  where iframe body is: <img src="evil/?bar=baz" />
11:32:16 <darobin> Arve: the content of the iframe is compromised
11:32:41 <darobin> Arve: you send data to a compromised document, which then sends it on
11:34:10 <darobin> widget A passes data to iframe B, which it has access to because of <access>
11:34:17 <arve> yes
11:34:19 <darobin> and B is compromised by C, which gets the data too
11:34:23 <arve> yes
11:34:56 <arve> q+
11:35:47 <darobin> Arve: the essential difference is that you can compromise iframe B's webserver, or you can compromise it with XSS
11:36:18 <darobin> RB: how is that different from GMail being XSS'ed?
11:36:45 <darobin> Arve: the difference is that your GMail is compromised — but that's not the same as local to your system
11:37:49 <darobin> RB: but that is already the case if Flickr or PayPal is compromised
11:39:06 <darobin> Arve: say C forces the device to perform an action that has direct monetary consequences
11:39:43 <darobin> RB: you don't grant access to B to all APIs in the same way that you don't give all your private info to a single website
11:40:08 <darobin> RB: if you did grant widget B with access to everything, it is exactly like granting a single website with access to all of the same
11:40:19 <darobin> RB: so basically the issue is exactly the same as trusting a website
11:40:36 <darobin> RB: if you give B a lot of power, and it's compromised, then you're screwed in the same way on the web and in a widget
11:41:04 <darobin> AB: would it be useful for us to go through the proposed model
11:41:13 <Marcos> +q
11:41:42 <ArtB> AB: tlr's model is: http://www.w3.org/mid/8273305F-C0A4-465F-83E4-90020C2122C3@w3.org
11:41:45 <darobin> Arve: I haven't responded to tlr's model yet
11:42:23 <darobin> AB: we've agreed that we were feature-complete, and we weren't going to define a complete security model
11:42:38 <darobin> AB: I'm surprised that Opera is coming back months later with it, and that it should block LC
11:43:04 <darobin> Arve: the last public WD had the access element — what I'm trying to say is that the access element behaviour is underspecified
11:43:19 <darobin> Arve: it's within the scope, we're saying what a widget can access
11:44:29 <darobin> Arve: the access element has always been underspecified in terms of which requirements it is addressing and what an implementation should do
11:44:40 <darobin> Arve: so it's not about being feature complete, it's about whether we're done with that feature
11:44:43 <Marcos> +q
11:45:09 <darobin> AB: Marcos says we could defer the SM to the UA, not make it a dependency that we have to solve
11:45:19 <darobin> AB: that's the model we've had all along and your proposal seems to change that
11:45:38 <darobin> Arve: I think it changes one thing: it would apply for two distinct security models to apply to a widget
11:45:51 <Marcos> +q +q +q :)
11:45:56 <darobin> Arve: I'm not saying that the html5 shouldn't be used, but that it's not useful for all cases
11:46:18 <darobin> Arve: we can then specify access for an unwebbish SM
11:46:39 <tlr> ack t
11:46:45 <darobin> AB: do you guys see a compromise here that you could both live with, and could be specified this week
11:47:23 <darobin> TLR: my question to JK is that I realise the orthogonality and agree with the argument, but could you live with a model that says they're orthogonal but we don't knwo what the model will be if we go into that plain
11:47:49 <darobin> TLR: queston to Arve: could you live, for 1.0, with a spec that does not say what happens if you have both access and feature
11:47:56 <darobin> TLR: I don't like that but I could live with it
11:48:05 <darobin> Arve: I agree that these issues are orthogonal
11:48:09 <Marcos> -q
11:48:20 <darobin> Arve: there are times when you would want to limit access even when you have no APIs
11:48:30 <darobin> TLR: the question is how much do we need to cover here
11:48:44 <darobin> JK: I would say not a lot because anything we do can clash with DAP
11:49:45 <darobin> Marcos: I had incorrectrly assumed that HTML5 had defined what would apply here, and doesn't consider html attachment as part of its SM
11:49:57 <darobin> TLR: we can use that model, and define what origin is and that sort of thing
11:50:20 <darobin> TLR: and then for any content FROM THE WEB (iframe) that that one has the HTML SM instead of a custom one — that's the disagreement
11:50:45 <darobin> Arve: compromise: can we have an addition attribute to access to switch between models
11:50:51 <darobin> Arve: one is origin-based
11:50:59 <darobin> Arve: ie what HTML UAs use
11:51:08 <darobin> Arve: the other is access-based network policy
11:51:37 <darobin> Arve: in which case there is full x-domain capabilities and access is completely restricted arbitrary levels downs
11:51:46 <darobin> Arve: and contrained by the policy
11:52:02 <ArtB> s/and contrained/and constrained/
11:52:09 <darobin> Arve: it doesn't need to be long to specify, it only needs to specify how access network policy is defined
11:52:41 <darobin> JK: to expedite PC 1.0, given that access is a runtime issue — not packaging — it should be put into a separate spec so we can finish PC and we can work on security in peace
11:52:56 <darobin> TLR: if that's the proposal, then why do we need an access policy in PC at all
11:53:13 <darobin> TLR: some of this discussion tastes like leaving access unspec'ed for now
11:53:48 <darobin> AB: two variations, one is to move access to a separate spec and break the dependency but still consider it part of 1.0 suite of specs
11:54:02 <darobin> AB: and the variation on that is what Marcos proposed which is to make it part of 2.0
11:54:12 <darobin> AB: my concern with the latter is that it has unbounded time
11:54:26 <darobin> TLR: third proposal is to put it inside DAP, which conceptually I think it belongs
11:54:52 <darobin> Arve: my main beef is that I fear that they will result in us not having a specified behaviour before 2011
11:55:11 <darobin> AB: I challenge that — if we want it, and members push it forward rapidly it can start today
11:55:38 <darobin> AB: I don't at all thikn that the work should stop — but rather we should back up and enumerate requirements, make sure we get it right, rather that do this under time pressure
11:55:49 <darobin> AB: I don't see any benefit in having PC be blocked by this
11:56:04 <darobin> AB: if we want an interoperable market, PC must proceed rapidly
11:56:14 <darobin> Arve: in principle I agree with this
11:56:37 <darobin> Arve: it's really*N hard for me to think that leaving this undefined soves problems in any timeframe
11:56:44 <darobin> AB: I don't think work stops
11:56:56 <darobin> AB: other benefit is that it makes it a lot more tractable for others to review
11:56:59 <darobin> q+
11:57:27 <darobin> AB: we all know that for any security realted work we need to broaden the scope of reviewers
11:57:29 <Marcos> +q
11:57:40 <darobin> Arve: ok, but we need to say something about how network access is derived
11:57:58 <darobin> AB: you're proposing to rip access out and put it in its own spec
11:58:06 <darobin> s/AB/Arve/
11:58:14 <darobin> MC: for me it makes sense to move it out
11:58:28 <darobin> MC: the UA doesn't really control network access as defined in PC
11:58:41 <darobin> MC: all it does is look at the package — it doesn't do anything at runtime
11:58:46 <darobin> MC: it's a dumb piece of code
11:59:04 <darobin> MC: if we keep it that way then it's okay to pull it out
11:59:11 <darobin> Arve: as long as this work can be fast-tracked
11:59:43 <darobin> Arve: we just say that the network access model is unspecified, or that it is not expected to access network at all if there is no access
12:00:04 <darobin> AB: if you look at it form a modularisation POV it doesn't seem to need to say anuything about access
12:00:13 <darobin> AB: just like update — same rationale
12:00:25 <darobin> Arve: fine — but we need something this year
12:00:48 <darobin> AB: I'm more than happy to support this spec being moved forward quickly
12:01:02 <darobin> MC: it will make things faster if we move it, that way I can focus on PC
12:01:27 <darobin> MC: then we can focus all our energy, we have half the text done, there's no reason why we can't have it done quickly
12:01:36 <darobin> MC: it ought to be 4-5 pages at the most
12:01:39 <darobin> Arve: I'm fine with that
12:02:12 <darobin> TLR: moving out ok, but the question is whether the work is started here or started in another WG
12:02:22 <darobin> Arve: I don't support moving it to another WG
12:02:39 <darobin> Arve: I really think it's within the scope of this WG
12:02:48 <darobin> AB: I'm willing to support Arve on that
12:03:17 <darobin> AB: the reality is that there will be significant overlap between DAP and WebApps so I'm confident that those two groups will work toegther
12:03:45 <darobin> TLR: goal wise I think we agree that access should be move out of PC, and that it ought to meet both WG's requirements
12:03:56 <darobin> TLR: the practicalities (one or the other WG, TF) can wait
12:04:06 <darobin> JK: +1
12:04:13 <Marcos> MC: +!
12:04:22 <darobin> RB: +1
12:04:28 <Marcos> MC: +1 even 
12:04:34 <darobin> RESOLUTION: access is dropped from P+C and moved to its own specification
12:04:54 <darobin> RESOLUTION: work on the Widget Network Access specification (or other name) is very high priority
12:05:15 <darobin> AB: editors?
12:05:25 <darobin> Arve: I am willing to do it if no one else steps up
12:05:34 <darobin> Arve: I have a lot of bg material we can reuse
12:05:50 <darobin> TLR: I'm happy with Arve to be an editro, I'm not volunteering
12:06:16 <darobin> RESOLUTION: the access specification will need to meet both WebApps and DAP requiremetns
12:07:45 <darobin> MC: moving out the feature element?
12:07:48 <darobin> AB: fine with me
12:07:56 <darobin> Arve: I'd like to sleep on it
12:08:09 <darobin> AB: I'll queue that up for tomorrow
12:08:28 <darobin> s/tomorrow/Thursday?
12:08:37 <darobin> s/Thursday?/Thursday
12:08:46 <darobin> Arve: holiday, might not be there
12:08:53 <darobin> TLR: have partial conflict 
12:09:07 <darobin> AB: we're talking about moving feature to another spec
12:09:10 <darobin> TLR: in scope for DAP
12:09:13 <darobin> AB: right
12:09:36 <darobin> TLR: which WG it happens in or TF, is a question we can handle later
12:09:58 <darobin> AB: I will include the proposal to move feature into another spec, and leave people 48h to speak up
12:10:12 <darobin> MC: I'll remove access from the spec today
12:10:24 <darobin> Arve: but you should say where it can be found
12:10:27 <darobin> MC: no brainer
12:10:39 <darobin> AB promises beer all around
12:10:50 <darobin> ADJOURNED
12:10:53 <Zakim> -Thomas
12:10:55 <Zakim> -Marcos
12:10:56 <Zakim> -darobin
12:10:57 <Zakim> -arve
12:10:58 <Zakim> -JereK
12:10:59 <Zakim> -Art_Barstow
12:10:59 <Zakim> Team_(wa)11:00Z has ended
12:11:00 <Zakim> Attendees were JereK, Thomas, Art_Barstow, darobin, +47.23.69.aaaa, arve, Marcos
12:11:36 <darobin> ArtB: you send out the minutes?
12:11:46 <ArtB> yes, darobin. Thanks Again!
12:11:51 <darobin> thanks :)
12:11:51 <ArtB> RRSAgent, make minutes
12:11:51 <RRSAgent> I have made the request to generate http://www.w3.org/2009/05/19-wam-minutes.html ArtB
12:12:03 <ArtB> RRSAgent, make log Public
12:12:14 <ArtB> RRSAgent, make minutes
12:12:14 <RRSAgent> I have made the request to generate http://www.w3.org/2009/05/19-wam-minutes.html ArtB
12:23:26 <ArtB> zakim, bye
12:23:26 <Zakim> Zakim has left #wam
12:23:29 <ArtB> rrsagent, bye
12:23:29 <RRSAgent> I see no action items