See also: IRC log
<trackbot> Date: 26 April 2013
<bhill2> gopal, anything you want to add to the agenda?
<bhill2> we can't hear you
<drogersuk> Discussion of component isolation, confinement and encapsulation
<jeffh> does someone have a link for the doc that's on the screen ?
<virginie> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
<drogersuk_> scribenick:drogersuk
<drogersuk_> scribenick:drogersuk_
DG: you can have offset parents as a member of a node
<jeffh> dimitri Glazbov (sp?) is holding forth on Introduction to Web Components (link above)
<jeffh> Dimitri Glazkov
DG: because of the CSS object model.. I'm not sure what the security sensitivity of render time is
... style will leak
... information, whether it is useful or not is a question
... there is a massive thing about inventory targeting
<jeffh> we're looking at section 9 Isolation, Confinement and Encapsulation
DG: when you are in shadow DOM.. it will feel like you moved, outside.. to the user, it won't seem like anything
... (talking about hovering over +1 buttons etc.)
... there have been other approaches proposed
... things like date object are just built out of javascript, with some privileged apis
... could let other people have access to those privileged apis, but not desirable idea
... shadow DOM is not a scripting context.
... all scripting is assumed the same
<abarth> Zakim: aabb is abarth
(DG shows diagram on whiteboard of how boundaries work)
Discussion about where keyboard presses are captured etc.
DG: there is no formal concept of how events are stopped at the shadow DOM boundary
... it is wide open at the moment
... the notion is we don't want to leak any references out of the shadow DOM
... by default, all these things are traversable. You can reach into the shadow DOM
... we don't want to stop them reaching into it, just not accidentally
DV: so we can't jail it off
DG: it is not a capability in the spec right now
... all browsers use shadow DOM now for widgets
<jeffh> Shadow DOM: http://www.w3.org/TR/shadow-dom/
TLR: ..and it can still reach out of that shadow DOM too...?
DV: Yes
(discussion of what security model applies)
scribe: we're concerned about 3rd party javascript
<jeffh> DG: "all i want to do is protect the hosting page from the 3d-party included code"
DG / AB: ..distrust in both directions
DG: I'm fine with a very limited comms model with each other, where there is a 'great wall' - events which are fired within don't reach anything
AB: events are the easier case
TLR asks if the model would create a security boundary between two trees, both of which have the same origin?
DG: I think we should contemplate different origins
TLR: we have places where we expect JS code to do origin checks
(iframe sandbox suggestion)
DG: turns out workers doesn't work across origins
... (whiteboards ideas about link ref) If it is cross-origin it will load in its own scripting reference
... the element is somehow registered in the main document, if someone uses the 'like' tag (it is somehow cloned / cutdown in the main doc)
... some element is created and has some shadow DOM tree that exists in the document
BH: sounds a lot like an iframe
DG: there are advantages, global state and interaction etc
BH: Global state is part of the problem...
DG: it's lifetime will have to match the lifetime of the document too
... most documents only have one like button
(last comment was DV
BH: lots of sites will have more than one like button
Pella: today facebook likes are using <script src="
... if they want all the functionality they have now (when you clicked it etc..) they may want something similar to what they have now
TLR: The advertising guys are building things on top of post message
... they use iframes
... and some shared javascript
... in order to optimise some of the overhead
... some of this may be worth looking at from a CSP perspective too
DG: multiple origins sharing the same state?
TLR: at the time, same origin
BH: at a naive first look, this looks to me to be an advertising model
... the caja guys didn't like this?
DG: they didn't reject it, they're interested in it because they want to encapsulate DOM somehow
... I can go back to these guys and understand what is happening
... they were trying to drop shadow DOM from the standard
BH: that's fine, I was just wondering if there were more details about why it was not workable
<tlr> relevant work:
<tlr> http://www.w3.org/community/custexpdata/
<tlr> http://www.iab.net/safeframe
DG: think it is just too early for them, they haven't really looked at this yet properly
JH: It's just a way of isolating sub-trees?
DG: Yes, encapsulating
... the outer document just explains how they're embedded and where they are. It seems to me that there is a security boundary
... I am going to try and talk to the caja people
... and see what ideas they have. I just want you guys to think about this.
JH: so shadow DOM is a piece of solving the 'like' button problem, but there are requirements beyond this and those need to be defined
BH: directional aspects will have security implications, what can be read etc.
JH: there may be some formal isolation things that need to be fed back to the javascript world
<virginie> D Rgers again off, anyone else willing to scribe ?
<virginie> Dimitri : would it be a good thing to do to progress ?
<virginie> BH : we need use cases to better understand borders
<virginie> Dimitri : will come back with real examples based on +1
<virginie> Dan : who is wokring on it in moz
<virginie> Dimitris (naming names I dont know)
BH: in terms of what security people like to see is what's the boundary, what goes across it etc
... what isolation, data flows, data leaks, directions
DG: I can arrange for that to be done
<drogersuk> DG: please feel free to contact me if you have any questions / suggestions
<bhill2> scribenick: bhill2
drogers: in webcrypto there is a presumption that crypto is "security" in certain camps, another camp positing that "web is insecure" so don't even attempt crypto
... if you do pay attention to documenting and maintaining the web security model, which needs to happen anyway
... but is huge amount of work, and typically written to an audience that already understands it
... needs to bridge the gap to a less security knowledgable audience
... e.g. last topic, developers just include script without understanding the security implications because it's easy
... assume it must be secure or why would people do it
... been working with Doug Schepers, potentially have a home for this at Web Platform Docs
... existing documentation such as Tangled Web, etc.
... want to understand what we should document first, top 5 items
jeffh: as a starting point web platform docs seems a reasonable home for this work
drogers: could be a sisyphean task
bhill: probably discussion should happen on public-web-security@, not public-webappsec@
tlr: the list exists, has a charter, less process to participate
... a writing project were to progress it would need someone other than abarth to serve as a coordinator
abarth: don't have cycles to pay close attention
drogers: willing to drive this project, need support of experts on this
<jeffh> bhill/tlr suggests leveraging: W3C Web Security Interest Group <public-web-security@w3.org>
drogers: can you get resources from your companies, etc.
tlr: should line up a few core folk who are willing to commit, take that to a broader list, w/1st draft, etc.
... to gather others in
... I know that Lieven Desmet is working on something that probably overlaps
jeffh: I have stuff to contribute on terminology, a problem is that it doesn't reflect reality and we need a rosetta stone on this stuff
drogers: could I put on the list and ask what folk think the priorities should be
... e.g. same origin workarounds used by developers, documenting best practices in that sense
... browser implementation inconsistencies
tlr: document them dispassionately
... you are scoping out the documentation equivalent of an open source project
... a wonderful thing, but a very significant effort
jeffh: what Zalewski did is an important subcomponent, but the task you want to accomplish lacks a high level roadmap today
... wouldn't put in the plan at this point to take over what was being done with browser security handbook
... somebody should, but a separate issue
drogers: yes, start small, if successful it will grow
... future topics: web components, web app firewalls, reputation filters... etc.
bhill: avoid web app firewalls as a topic, a tool and product category, not a part of the security model
drogers: developers need to think about network layers
tlr: there are some security considerations that arise out of http behavior and widely deployed intermediaries
... there are others that arise from common flaws of such, there are others from such that violate specs
... focus on those that are part of the platform at the core
bhill2: w3c should NOT write a doc that says, this is how to use a web app firewall to secure your app
drogers: hsts, certificate authorities....
bhill: these should be out of scope - draw boundaries that make task achievable and venue-appropriate
drogers: my work is in mobile- chair the device security group in GSM assn.
<scribe> ... new security considerations from new devices, physical platforms that havent' traditionally used the web as a browser
UNKNOWN_SPEAKER: will become issues for us in the future as the web evolves
... device APIs will bring new classes of attack we haven't thought about
bhill: POV should be from someone writing code to the open web platform
... leave things like how to configure your web server for SSL to organizations like OWASP
virginie: in webcrypto there is traction for this kind of work, accurate documentation will solve problems for us
... we need not just a description of how to use technologies correctly, but also what are the limits of the security model and not to oversell
drogers: ian melven's talk at b-sides vancouver was good: is there a web security model? answer: no
jeffh: there is folklore, we started writing some of it down: new RFCs for web origin concept, cookies ... thank you Adam Barth
... continuing this work may identify other things that can be "specifiable" beyond just being developer docs
<wseltzer> The Web Origin Concept: https://tools.ietf.org/html/rfc6454
<wseltzer> Cookies: https://tools.ietf.org/html/rfc6265
drogers: these RFCs are good examples to start with, and more like this a potential future goal
... Interest Group concept removes many risks of IPR - just documenting already existing concepts
devditz: a spec at what stage? only becomes not an issue after the final Recommendation stage
drogers: maybe we should state we will only talk about specs that have reached CR or similar
dveditz: but then it's too late to have an impact on these specs
bhill: goal here should not be to influence new tech, but to document the already interoperable
wseltzer: once we get the backlog done, we can think about IPR questions for new stuff
bhill: should probably be formally owned by the Security IG, WebAppSec can be liason
<wseltzer> ACTION on tlr to promote the security model documentation project
<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.
<wseltzer> ACTION tlr to promote the security model documentation project
<trackbot> Created ACTION-135 - Promote the security model documentation project [on Thomas Roessler - due 2013-05-03].
<wseltzer> trackbot, end teleconf