See also: IRC log
<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> http://lists.w3.org/Archives/Public/public-appformats/2008Apr/0096.html
<arve> specifically, 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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/this WG should restrain itself from enforcing its solution/this WG should not try to solve the entire device API problem/ Succeeded: s/network/network resoruces/ Succeeded: s/turtles/circles/ WARNING: No scribe lines found matching ScribeNick pattern: <Robin> ... Found ScribeNick: ArtB Found Scribe: Robin Found ScribeNick: darobin ScribeNicks: ArtB, darobin WARNING: No "Topic:" lines found. Default Present: Art_Barstow, Marcos/Arve, Thomas, darobin Present: Art Arve Marcos Thomas Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0535.html Found Date: 18 May 2009 Guessing minutes URL: http://www.w3.org/2009/05/18-wam-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]