- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Mon, 18 May 2009 08:11:59 -0400
- To: public-webapps <public-webapps@w3.org>
The draft minutes from the May 18 Widgets Security voice conference
are available at the following and copied below:
<http://www.w3.org/2009/05/18-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.
-Regards, Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Widgets Security Model Voice Conf
18 May 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-webapps/
2009AprJun/0535.html
See also: [3]IRC log
[3] http://www.w3.org/2009/05/18-wam-irc
Attendees
Present
Art, Arve, Marcos, Thomas
Regrets
Chair
Art
Scribe
Robin
Contents
* [4]Topics
* [5]Summary of Action Items
_________________________________________________________
<ArtB> Date: 18 May 2009
<ArtB> ScribeNick: ArtB
<tlr> +1 to Art not scribing
<scribe> Scribe: Robin
<scribe> ScribeNick: darobin
AB: agenda a bit vague, but has pointers to previous discussions
... we don't have consensus yet, we need it for LC
... 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
... 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
MC: the first thing we need consensus on is whether we want the
HTML5 model
... if we are going to use the HTML5 model we need some kind of
opt-in or it should be on by default
TLR: It think there is a more nuanced question to ask: which part of
that model we need
... it governs access to cookies, frames, network (XHR and inline),
and storage + other APIs
MC: right
TLR: I think the discussion is largely around network access,
possibly storage
... haven't seen much discussion about the others, but they will
materialise once access is given
... the quesiton is largely around network access
Arve: I don't think it's possible to separate network access as a
boolean from the general model and how you compute origin
TLR: why?
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
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
... 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
Arve: the background is that Opera's implementation used to treat
inlines as they did in HTML4
... however that's not an acceptable model when allowing access to a
phone's address book
... because you have potential information leakage
TLR: that is a fundamental point for the DAP WG's charter
... the quesiton is what is the scope of the question
... can we solve this and reach decision without solving the DAP
WG's problem
Arve: what I'm saying is that you can't make a decisin on one
without making a decision on both
... security is intertwined with the Device API
... I think we should be gathering requirements and use cases, and
figure out where we can go
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
Arve: if you do that I think you'll end up with conforming but not
interoperable
TLR: so is Opera saying that P+C shouldn't enter LC before DAP has
concluded?
Arve: no, I think this is hard to answer
... I don't think we can ship widgets without a security model
TLR: I agree on your meta-meta point that it would have been nice to
do this earlier, but it hasn't happened
... 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?
Arve: I don't think it's possible
... it can be done in a short time, but I don't think we can skim
... if the P+C has syntax that doesn't match the security, it is
meaningless
MC, TLR: agree
MC: the specs are broken apart for editorial, not technical reasons
... we could say as we do for window modes, these are the correct
WMs
... we could have an origin attribute with html5, any, etc and given
that have enough to go on
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
MC: why?
TLR: because if the framework is the html5 model, then any network
resource is accessible
... I woulndn't go there
... we're talking mechanism when we should be talking goals
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
... based on our IRC discussion
AB: if we don't do anything, will OMTP define its own?
RB: yes
AB: and they'll leave it as an implementation model?
RB: the original OMTP model was that everything was closed, and the
access element could be used to open it
TLR: is it a workable compromise to close everything and use access
to open all network? (inline+xhr)
... 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
... we don't want to constrain DAP with a hack
... this WG should not try to solve the entire device API problem
... 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
Arve: you are making one assumption too many
... the html5 model is completely adequate in a few set of cases
... we have two completely different security contexts here
<arve> I'll type here
<arve> 1. Let's say you have a web UA that has "Save as Widget" for
web pages
<arve> for instance on GMail
Arve: in this use case we have a web page converted into a widget
<tlr> why would that use the P&C framework?
Arve: or running widgets on the web, like Google gadgets, that sort
of thing
... those are fine inside the HTML5 security model
... and we need to offer them that option
... case 2 is when you have third-party information available to the
widget (ie device APIs) or limited cross-origin access
... e.g. scraping Google while tlaking to your Yahoo account
... or talking to your Yellow Pages and matching against the phone
book on your device
... there, the HTML5 security model is too thin, information can be
leaked
TLR: you are making one assumption too many about what I said
... 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
... for any network access, restrict the HTML5 model further
Arve: I think I agree with this
... I think we agree on the end result
<tlr> 1. no origin inside the package
<tlr> 2. random origin generated at instantiation time
Arve: I think we need a model that striclty enforces which networks
can be reached
<tlr> 3. use HTML5 mode, *but* cut down on network access, unless
<access> is used to grant network resoruces access
Arve: this is circles all the way down
... any network access within any resources, in addition to the
html5 checks is also subject to what the widget says it can access
TLR: specifically about iframes?
Arve: no, everything
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
... (or img, or script)
... there MUST be an access element that allows that
... then, the communication between the various DOM, and the rest,
is governed by the HTML5 security model
... 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
Arve: if you have recursive inclusion, what rules govern that?
TLR: html5
... if I've granted access to a.com, if they collaborate with
evil.com, then there's nothing I can do anyway
Arve: my point is that an origin on the web might be an origin you
trust
... so I might trust a widget to access my domain
... but if my domain has a security hole that has an XSS issue that
includes an injection from a third-party
... then if <access> prevent third-domain access, I will be
protected against that
TLR: I think that that approach is a very likely recipe for disaster
— because of complexity
... my assymption is that if I'm in an iframe that comes from the
web, it will not have access to device APIs
<arve> 1. Inject script into widget main document
TLR: I'm also assuming that an iframe inside a widget, whatever
access that iframe has follows the traditional sandboxing
... so it gets to the web, not to the APIs
<arve> 2. Read content without legitimate access
<arve> 3. Use hole in widget to inject content (specifically
scripts) into example.com/someurl
<arve> 4. Let injected content point to evil.com/someotherurl
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
Arve: you're making an assymption about implementer complexity
... look at the script inhection above
... that content is injected into your trusted resource
... this is not far-fetched — and it circumvents the access policy
that you describe
... that
bah
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
TLR: what I'm disputing is that we're creating a separate execution
context for web content
... and I think we shouldn't be prepared to go there, it's out of
scope and not the simplest option
... the complexity I'm worrying about is not implementers'
complexity but adding YA secuirty model
... want to keep it as simple as possible
Arve: this doesn't imply increased complexity in the system, only
the runtime has to check that access rules are permitted
TLR: our contention is about the access that an external web app
gets through the network when running inside an iframe inside the
widget
... the increased complexity is likely not written specfiically for
the widget execution context
... and we're changing the way that web app expects to be run
Arve: if an application doesn't expect to be run in a widget, it's
not going to request to run DAs
... my proposal is that a) access to APIs with stricter checks, and
b) the html5 context without such access
... enforcing access only one level down is not going to be
acceptable to operators
<arve> Two models: 1) No extended access, computed http origin,
running without extended access, or awareness of sensitive apis
<arve> 2) Extended access, subject to strict security model
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
... so you say you get a different execution context for iframe
inside a widget and I think that's risky
Arve: the only deviation I propose is that <access> applies all the
way down
... as implementers this is simpler too
TLR: my proposal is if orgin = web then use web model, if origin =
synthetic then use restricted access model
AB: let's summarise agreement
... and see what we can do about disagreement
Arve talks of a former Opera proposal
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
... is that fair?
TLR: I would add that I think we have agreement for anything that
has come through an intermediary — should go through access control
... I think we have disagreement about what happens with inline
context, and what SM should apply there
... I'm saying just web model, and Arve is saying needs further
constraints
<arve>
[6]http://lists.w3.org/Archives/Public/public-appformats/2008Apr/009
6.html
[6] http://lists.w3.org/Archives/Public/public-appformats/
2008Apr/0096.html
<arve> specifically,
[7]http://lists.w3.org/Archives/Public/public-appformats/2008Apr/att
-0096/w3c-security.html
[7] http://lists.w3.org/Archives/Public/public-appformats/
2008Apr/att-0096/w3c-security.html
TLR: I can't join on thursday
... I can do Wednesday same time
<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
AB: I can't but it's okay if you do it without me
Thursday is a public holiday in many places
RB: tomorrow same time?
TLR, AB: fine
AB: homework, take a look at Arve's model and discuss tomorrow
... also think about splitting <access> out of P+C so that P+C could
proceed through LC
Arve: before you read the document, understand asumptions that
externally ref'd documents are still subject to the web SM
<arve> ... with the addition of network restrictions
<arve> ... as enforced by config.xml
TLR: so what's described is what happens in addition to the basic
security model
Arve: yes
TLR: good
<tlr> conference Team_(wa)11:00Z scheduled with code 83261 (TEAM1)
tomorrow at 11:00Z for 60 minutes until 1200Z
<tlr> artb, see above for code for tomorrow
<tlr> it's actually the same as today
<ArtB> AB: Same time tomorrow; same channel; different PIN to be
annouced in this channel
<ArtB> tlr, roger that
<ArtB> AB: meeting ajdourned
Summary of Action Items
[End of minutes]
Received on Monday, 18 May 2009 12:12:44 UTC