W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

[widgets] Draft Minutes from 18 May 2009 Widgets Security VC

From: Arthur Barstow <art.barstow@nokia.com>
Date: Mon, 18 May 2009 08:11:59 -0400
Message-Id: <C894B1E1-12F0-4E59-91DD-0A1C9A636C6C@nokia.com>
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:


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

-Regards, Art Barstow


       [1] http://www.w3.org/

                                - DRAFT -

                    Widgets Security Model Voice Conf

18 May 2009


       [2] http://lists.w3.org/Archives/Public/public-webapps/ 

    See also: [3]IRC log

       [3] http://www.w3.org/2009/05/18-wam-irc


           Art, Arve, Marcos, Thomas




      * [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

    TLR: so is Opera saying that P+C shouldn't enter LC before DAP has

    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

    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
    ... 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

    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
    ... 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
    ... 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


    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

    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
    ... 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


       [6] http://lists.w3.org/Archives/Public/public-appformats/ 

    <arve> specifically,

       [7] http://lists.w3.org/Archives/Public/public-appformats/ 

    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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC