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,
