Widgets Security Model Voice Conf -- 19 May 2009

<ArtB> ScribeNick: ArtB

<darobin> marcos is in a bad mood :)

Date: 19 May 2009

<Marcos> dialing in..

<scribe> ScribeNick: darobin

Widget Security Model

AB: there has been discussion on the list

<ArtB> AB: new thread was started http://www.w3.org/mid/b21a10670905190218k2645cf5dh5506bdf7be243330@mail.gmail.com

AB: there seems to be agreement between some of TLR and MC, and Vodafone supports TLR's model
... Arve is not happy with either proposal

Arve: I think we have an irreconcialable difference between two app models for the web
... one in which you have the traditional model under the html5 model largely
... 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)
... that model, given how it handles inline content, become useless
... the diff between stealing data from that device whether you allow XD XHR or not is none
... if I read all the phone book
... I can just pass it through an img object
... and send it bit by bit within that secrity model
... you're on your own if you don't restrict that
... we need to restrict that model further the moment you put anything in a feature element
... 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
... but that model can never be used in conjunction with sensitive APIs — which is my entire protest
... 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

AB: trying to understand:

<ArtB> AB: Arve's email http://www.w3.org/mid/op.ut6avtgrbyn2jm@galactica

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
... we need to discuss that too

TLR: what I hear Arve say is that in the moment a widget touches anything feature-enabled, the widget must not access the network

Arve: it must have no entry point to the network that is not declared

TLR: there are two ways to satisfy this requirement
... one is if you have <feature>, access may not occur or implementations decide
... 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

Arve: for any data that is put into the cloud you need to trust who you give it to
... you implicitly trust Google not to do any bad between with your GMail phone book
... the trust between a third party and the user, and not of our concern
... 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
... what I'm trying to ensure is that information from a feature-API should not get anywhere it shouldn't

TLR: are you assuming all those APIs are read-only?

Arve: no
... RW APIs are a different ball park
... we can't ensure that no data destruction happens — simply that it doesn't get into the wrong hands

TLR: if you have an SMS API, you have a potential leak anyway
... could you live with within the scope of the 1.0 spec there is no specified model if both feature and access are present
... IOW if someone uses feature APIs UAs could impose a restriction
... if feature is used, you are not guaranteed any access to the network

<arve> Zakim: q+

TLR: my goal is to not create an almost-html5 model that will then constrain DAP

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
... and that what we do provides a reasonably transition path

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
... it's futile to try to shoehorn them into the same model
... 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
... 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
... we are feature-complete for packaging, we could go ahead with that

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
... 1000s of widgets already written have made use of non-restricted x-domain policy
... it is unfortunate if those cannot be solved within the new model

<tlr> I wasn't even talking about cross-origin, and would note that access actually covers that.

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
... in which case using an API alters the security model of the widget
... 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
... someone will come up with an API that will open up too many things, or incompatible implementations
... as much as I'd like to deal with this later, but in the meantime we'll grow incompatible implementaions

<tlr> darobin: getting slightly confused

<tlr> ... discussion crossing ...

<tlr> ... model as understand it ...

<tlr> ... "anything that comes from the widget is under control of access and feature, anything referenced outside, is under web model" ...

<tlr> ... those things don't communicate that much ...

<tlr> ... perhaps a few issues with script references ...

<tlr> ... don't think this increases attack surface that much ...

<tlr> ... if we restrict original content, then have useful level of security ...

<tlr> ... don't see attacks as being any more important than what we already see today ...

Arve: I would like to point out a collision

<arve> <iframe src="foo?bar=baz"> where iframe body is: <img src="evil/?bar=baz" />

Arve: the content of the iframe is compromised
... you send data to a compromised document, which then sends it on

widget A passes data to iframe B, which it has access to because of <access>

<arve> yes

and B is compromised by C, which gets the data too

<arve> yes

Arve: the essential difference is that you can compromise iframe B's webserver, or you can compromise it with XSS

RB: how is that different from GMail being XSS'ed?

Arve: the difference is that your GMail is compromised — but that's not the same as local to your system

RB: but that is already the case if Flickr or PayPal is compromised

Arve: say C forces the device to perform an action that has direct monetary consequences

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
... 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
... so basically the issue is exactly the same as trusting a website
... 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

AB: would it be useful for us to go through the proposed model

<Marcos> +q

<ArtB> AB: tlr's model is: http://www.w3.org/mid/8273305F-C0A4-465F-83E4-90020C2122C3@w3.org

Arve: I haven't responded to tlr's model yet

AB: we've agreed that we were feature-complete, and we weren't going to define a complete security model
... I'm surprised that Opera is coming back months later with it, and that it should block LC

Arve: the last public WD had the access element — what I'm trying to say is that the access element behaviour is underspecified
... it's within the scope, we're saying what a widget can access
... the access element has always been underspecified in terms of which requirements it is addressing and what an implementation should do
... so it's not about being feature complete, it's about whether we're done with that feature

<Marcos> +q

AB: Marcos says we could defer the SM to the UA, not make it a dependency that we have to solve
... that's the model we've had all along and your proposal seems to change that

Arve: I think it changes one thing: it would apply for two distinct security models to apply to a widget

<Marcos> +q +q +q :)

Arve: I'm not saying that the html5 shouldn't be used, but that it's not useful for all cases
... we can then specify access for an unwebbish SM

AB: do you guys see a compromise here that you could both live with, and could be specified this week

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
... 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
... I don't like that but I could live with it

Arve: I agree that these issues are orthogonal

<Marcos> -q

Arve: there are times when you would want to limit access even when you have no APIs

TLR: the question is how much do we need to cover here

JK: I would say not a lot because anything we do can clash with DAP

Marcos: I had incorrectrly assumed that HTML5 had defined what would apply here, and doesn't consider html attachment as part of its SM

TLR: we can use that model, and define what origin is and that sort of thing
... 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

Arve: compromise: can we have an addition attribute to access to switch between models
... one is origin-based
... ie what HTML UAs use
... the other is access-based network policy
... in which case there is full x-domain capabilities and access is completely restricted arbitrary levels downs
... and constrained by the policy
... it doesn't need to be long to specify, it only needs to specify how access network policy is defined

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

TLR: if that's the proposal, then why do we need an access policy in PC at all
... some of this discussion tastes like leaving access unspec'ed for now

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
... and the variation on that is what Marcos proposed which is to make it part of 2.0
... my concern with the latter is that it has unbounded time

TLR: third proposal is to put it inside DAP, which conceptually I think it belongs

Arve: my main beef is that I fear that they will result in us not having a specified behaviour before 2011

AB: I challenge that — if we want it, and members push it forward rapidly it can start today
... 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
... I don't see any benefit in having PC be blocked by this
... if we want an interoperable market, PC must proceed rapidly

Arve: in principle I agree with this
... it's really*N hard for me to think that leaving this undefined soves problems in any timeframe

AB: I don't think work stops
... other benefit is that it makes it a lot more tractable for others to review
... we all know that for any security realted work we need to broaden the scope of reviewers

<Marcos> +q

Arve: ok, but we need to say something about how network access is derived
... you're proposing to rip access out and put it in its own spec

MC: for me it makes sense to move it out
... the UA doesn't really control network access as defined in PC
... all it does is look at the package — it doesn't do anything at runtime
... it's a dumb piece of code
... if we keep it that way then it's okay to pull it out

Arve: as long as this work can be fast-tracked
... 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

AB: if you look at it form a modularisation POV it doesn't seem to need to say anuything about access
... just like update — same rationale

Arve: fine — but we need something this year

AB: I'm more than happy to support this spec being moved forward quickly

MC: it will make things faster if we move it, that way I can focus on PC
... 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
... it ought to be 4-5 pages at the most

Arve: I'm fine with that

TLR: moving out ok, but the question is whether the work is started here or started in another WG

Arve: I don't support moving it to another WG
... I really think it's within the scope of this WG

AB: I'm willing to support Arve on that
... the reality is that there will be significant overlap between DAP and WebApps so I'm confident that those two groups will work toegther

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
... the practicalities (one or the other WG, TF) can wait

JK: +1

<Marcos> MC: +!

RB: +1

<Marcos> MC: +1 even

RESOLUTION: access is dropped from P+C and moved to its own specification

RESOLUTION: work on the Widget Network Access specification (or other name) is very high priority

AB: editors?

Arve: I am willing to do it if no one else steps up
... I have a lot of bg material we can reuse

TLR: I'm happy with Arve to be an editro, I'm not volunteering

RESOLUTION: the access specification will need to meet both WebApps and DAP requiremetns

MC: moving out the feature element?

AB: fine with me

Arve: I'd like to sleep on it

AB: I'll queue that up for Thursday

Arve: holiday, might not be there

TLR: have partial conflict

AB: we're talking about moving feature to another spec

TLR: in scope for DAP

AB: right

TLR: which WG it happens in or TF, is a question we can handle later

AB: I will include the proposal to move feature into another spec, and leave people 48h to speak up

MC: I'll remove access from the spec today

Arve: but you should say where it can be found

MC: no brainer

AB promises beer all around

ADJOURNED

ArtB: you send out the minutes?

<ArtB> yes, darobin. Thanks Again!

thanks: )

- DRAFT -

Widgets Security Model Voice Conf

19 May 2009

Attendees

Contents

Widget Security Model

Summary of Action Items

Scribe.perl diagnostic output