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

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

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 19 May 2009 08:23:13 -0400
Message-Id: <3F035E7B-EF39-43DF-AA20-641C0B60268F@nokia.com>
To: public-webapps <public-webapps@w3.org>
The draft minutes from the May 19 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

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] http://www.w3.org/

                                - DRAFT -

                    Widgets Security Model Voice Conf

19 May 2009


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

    See also: [3]IRC log

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


           Art, Thomas, Jere, Robin, Marcos, Arve


           ArtB, darobin


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

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

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

    <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
    ... 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
    ... we are feature-complete for packaging, we could go ahead with

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

    <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
    ... 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/8273305F- 

    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

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

    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

    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

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


    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
Received on Tuesday, 19 May 2009 12:24:22 UTC

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