Web Application Security Working Group Teleconference

16 Nov 2015


See also: IRC log


mkwst, gmaone, jww, ckerschb, tanvi, timeless, dveditz, Brad, Hill, francois, terri, wseltzer
bhill2, dveditz
mkwst, bhill2


<trackbot> Date: 16 November 2015

<bhill2> Meeting: WebAppSec Teleconference 16-Nov-2015

<Zakim> timeless, you wanted to note that I've sent some feedback and will be sending a bit more about things that were sent to CR (sorry about the delay)

<inserted> scribenick: mkwst

Agenda bashing

bhill2: Agenda bashing. Anything anyone wants to add?

everyone: <silence>

Minutes approval

<bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-10-28-webappsec-minutes.html

<bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-10-29-webappsec-minutes.html

bhill2: Minutes from TPAC.
... Objections?

dveditz: None.

bhill2: No objection. Minutes approved.


bhill2: SRI -> CR.
... Congratulations!
... Believe we've satisfied all criteria to have smooth sailing to REC.
... 4 week comment period for CR.
... Will try to keep on schedule.

dveditz: Is PR the last step before REC?

bhill2: CR -> PR -> membership vote (AC) -> REC

dveditz: Ok, so this group takes it to PR, then lobbies to get to REC?

bhill2: Yup.

francois: Is it worth focusing on test suite to make sure we're happy with it?

bhill2: Having a good test suite is always a good thing.
... Think it's unlikely that incremental improvements would make anyone vote for it.
... Don't think it's on the critical path, but if you think something's lacking, then certainly add tests rather than add errata later.

New call time

<bhill2> http://doodle.com/poll/75bif7nd3cuyfqis

bhill2: Sent out a Doodle poll.
... Will give folks here on the call a few minutes if you want to fill it out right now.
... Looks like the leading times are 9:00 PST Tuesday or Wednesday.
... Will be nice to move things into the European workday.
... I had listed Tuesday as "If need be", but looking at my calendar, that's pretty bad actually.
... Wednesday will work better for me.
... How horrible are the "If need be" folks on Wednesday?

dveditz: Related to commuting.

jww: Not great, but not _terrible_.

francois: Fine with Wednesday.

<devd> I would prefer Tuesday

bhill2: Tuesday is officially in the lead, but if I edit my answer...
... Should we go with Wednesday?
... Hearing no objection, going with Wednesday.
... If that turns out to be bad, we could alternate every other call.
... I'll adjust the calendar.


tanvi: When's the next call? December 2nd at 9am?

<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Nov/0037.html

bhill2: Looks right. Also, there's a calendar on the group homepage.
... jww, want to talk about suborigins?

jww: I sent something to the list, got some response.

<dveditz> calendar and other good stuff: http://www.w3.org/2011/webappsec/

jww: Suborigins gives servers the ability to add a namespace for a response that puts the response in a new origin in addition to scheme/host/port.
... Respond with `suborigin: foobar`, now you're in scheme/host/port/foobar
... Experimenting with some ideas in Chrome.
... Latest updates:
... 1. XHR and Fetch would need a preflight on all requests from a suborigin because a suborigin can't know what suborigin the endpoint is in until the response comes in.
... (Should we go over these one by one, or quick summary?)

bhill2: Inclined to pause for questions.

jww: Ok. Let's pause.

devd: Preflights. I don't understand why we insist on a preflight?
... Why not avoid preflight for simple requests?

jww: That sounds reasonable.

<bhill2> mkwst: that's what I thought we agreed on

jww: Great. Let's do that instead!

dveditz: Suborigins have to be treated like origins, but not worse, right?

devd: Right.

jww: Right.

dveditz: Except that the CORS server needs to ack the suborigin.

jww: Right, there would be a CORS header for suborigin, just like origin.
... For `postMessage`, by default the suborigin would be serialized into the origin field, but would create a...

devd: Wait, go back to 1.
... Something about a * response in the CORS header.
... * doesn't work with credentials.
... How is that going to work with suborigins?

dveditz: Star is star.

devd: Star is an error with credentials set to true.

dveditz: It's ok to say that something is public by responding with star.
... Otherwise it has to specifically acknowledge the requester.
... Shouldn't change the rules for that.
... If it's a public response, you don't need to acknowledge the response.

devd: Let's say /foo requests /foo/bar. I want that to work in older browsers, and not break them to support suborigins.

jww: I'm confused about what you're confused about.

devd: If a completely different domain requests with credentials and the server responds with star...

jww: I understand the issue now. I'm trying to figure out what sounds reasonable. Let's take it offline now that I understand the concern.
... Start a new thread?
... 2. `postMessage`. Serialize the suborigin into the origin field. Could be issues with retrofitting applications, so might want to provide an `unsafe-postmessage-serialization` or something to get the origin without the suborigin, explicitly check the suborigin if you care.
... 3. `localStorage`. Every suborigin gets a fresh jar, could provide an opt out mechanism.
... annevk suggested banning localStorage. Don't know how practical that is.

devd: What does "banning" mean? Throw on access?

jww: I think Anne wants to ban the API as in throw it.

devd: Banning isn't practical, folks use it.
... Use case is things we don't trust and which don't have good practice.
... Need to support those legacy things.

dveditz: Not just `localStorage`, any storage, indexed db, etc.

devd: Anne doesn't like `localStorage` as it's sync and slow.

dveditz: Right, but the question is whether we create new storage or not.

devd: Create new storage. Sandbox solves the case where we want to throw.

jww: My position is that suborigins should be treated as a separate origin to the extent possible. Should get its own storage, just like any other domain.

dveditz: Banning the feature isn't a great idea. It's giving up. It's not what folks expect to happen.

timeless: (Anne, and the web's) Reason to ban things is to move the web forward. In exchange for shiny new, give up crappy old.

dveditz: Oh, you mean he's suggesting to ban `localStorage` but not indexed db?

devd: Right, but putting crappy code into a suborigin is why we want suborigins. We don't trust the old crappy code, we should support those APIs in suborigins to get the security benefits.

timeless: I don't have a horse in this, but if you keep it, you have to say why you're keeping it.

jww: Sounds good.
... 4. Cookies!
... Apps at Google that want suborigins that would need cookies from the parent origin

<dveditz> jww said explicitly "document.cookies" which is a subset of cookies in general

jww: Mike pointed out that cookie model is somewhat broken as is, ignores scheme, etc.
... Dev has pointed out that readable access to `document.cookie` is dangerous. Takeover suborigin, get access to login cookie.

devd: Network requests still send cookie though, right? So what's the concern about being logged in or not?

jww: Yes. I wrote `document.cookie` but I meant that cookies need to be shared in some respect.

devd: Sure, I'm _just_ talking about `document.cookie`. Let's remove that.

jww: I'm loath to put words in Artur's mouth.

mkwst: I think he was talking about `document.cookie`

jww: Removing `document.cookie` seems like a reasonable default, might need an opt-out for some applications.
... Not sure what the exact behavior should be (throw or empty)?

devd: Might want to separate writes from reads as well. Can discuss offline.

bhill2: Meta concern as chair: we talked about COWL at TPAC and noted that there are some similarities in terms of mechanisms and goals between it and suborigins.
... Sandboxing as well.
... I trust that our editors and authors are all smart and working on real apps with real concerns.
... But it would be great if we had a document looking at these solutions side by side and explaining why choosing one over the other is the right thing to do in particular circumstances.
... It would be a shame if the only documentation of that was in the folklore of reading meeting minutes.

<Zakim> timeless, you wanted to +1 this, since it's useful for authors in the future

bhill2: Should lay out systematically.

<bhill2> http://www.w3.org/TR/COWL/

devd: Is the COWL spec ready? I think I have a reasonable understanding of suborigins.
... Sandbox has a number of limitations that suborigins would solve.

jww: I tried at the top of the draft to compare suborigins and sandboxing. Truthfully, I don't understand COWL well enough yet to compare.

devd: COWL could explain why suborigins and sandbox don't solve?
... Then we could merge into one doc.

bhill2: Regardless of which subset of these specs we proceed with, it would be valuable to compare the possible solutions and outline the authoring concerns that drove us to choose the solution we specified.
... I'd suggest that jww should chat with Deian to talk through the comparison with COWL.
... I know it's a big ask to have another top-level doc, but it would help clarify my thinking on the topic.
... I'd be happy to help.

jww: Ok. Maybe we can arrange something on the mailing list to char.

dveditz: Mozilla devs aren't keen on implementing this. Why is it so much better than an actual subdomain or distinct port? Sites insecure in old browsers anyway?
... Concrete examples would be helpful.

devd: Dropbox wants this. Right now.
... I'll send an email.

dveditz: To the mailing list.

jww: I appreciate the difficulty of implementation.
... UAs that don't implement it failing to protect is true of everything we do.

dveditz: Sure, but in this case, isn't it as easy to create a "real" origin.

devd: Business pressure (SEO, etc) to have everything on a single domain.
... Could imagine every component on subdomains.
... Subdomains aren't as well isolated as suborigins could be (cookies, etc).
... Should do this over email.

bhill2: One other thing: what do we do with CSP and X-Frame-Options?
... I can understand why you wouldn't want to move to a new domain, as things that depend on you would break.
... But maybe that's desirable behavior.
... Maybe we need CSP to apply to subdomains and/or suborigins?
... Something to think about.

UI Security / Visibility API

<bhill2> http://w3c.github.io/webappsec/specs/uisecurity/index.html

bhill2: A few calls ago, Dan joined us and went through his talk from Defcon. Iron Frame.
... Have an existing UI Security spec.
... Based on pixel scraping.
... Performance impact, given modern GPUs, was bigger than any user agent was willing to take on.
... Dan proposed an alternate approach, based on reordering layers.
... Goal of causing layer to be drawn on top of other layers in the compositor.
... I've rewritten UI Security in terms of that mechanism.
... Declarative policy is simplified.
... Can't describe detailed rectangles via DOM selectors, etc.
... Now have an imperative API, which allows us to simplify the declarative API.
... Added visibility API as it's directly related.
... Might model it in terms of mutation observer. Causes events to be fired, giving information about viewport.
... I think the questions around the API are:
... 1. Making API useful for paid content that wants to know whether they're visible.
... Wants the `ancestorOrigin` concept to be part of the visiblity event that's fired.
... Are Firefox/Edge interested in implementing something like that API?

dveditz: I think telling a frame who its parents are violates the SOP.

bhill2: `frame-ancestors` lets you make pretty good guesses.

devd: `frame-ancestors` doesn't leak it, you have to brute force.

bhill2: That's true.
... It's been in Chrome for a pretty long time.
... Are Chrome folks aware of exploitation?

dveditz: How do you get that information in Chrome?

mkwst: It's been in Chrome for a long time.
... I talked with bz about it a while ago. He wasn't interested in implementing it at that point. Might be worth rekindling the conversation.

<timeless> location.ancestorOrigins in WebKit and Chrome before April 17th, 2012

bhill2: Understand that it can be seen as a violation of SOP. With my Facebook and Editor hat on, it seems like it's valuable for abuse protection.
... Another feature not yet written-up: If we know visibility, enables more interesting use cases with embedded documents.
... Has always been the case that typing into an iframe gives you input exclusivity. Parent frames can't sniff keystrokes, etc.
... Could extend the address bar. Could show what origin you're typing into.
... On a scale of "Do it!" to "Absolutely not, that's completely crazy.", where does the group fall?

<wseltzer> +1

<inserted> scribenick: bhill2

mkwst: browsers are skeptical about specifying UI, but we do this in limited ways in the mixed content spec
... would be difficult to explain to users that a page consists of more than one origin
... having one origin in the address bar is valuable
... they have a chance to understand it, but making it more complicated would have to be backed up with user studies and a good way to present it that the spec might now allow

<inserted> scribenick: mkwst

dveditz: Input directive for CSP; appears to only make it difficult if you had multiple ones.
... If you had a few of these items, it might be order dependentl.

bhill2: I think you could do that. Maintains internal state.
... when event delivered to protected element, calculate bounding rec for that element, compare it to the last visibility event on the stack.
... should be possible to add additional elements to be checked.

wseltzer: Extending the address bar is probably necessary to enable pages to give up control of subcomponents, and inform users that they've done so.
... Could be the basis of allowing sites to build a true peer-to-peer experience.
... Useful to start thinking about now, even if it's only a few users who would understand what it's for at first.

mkwst: Intersection Observer is a thing. Would be interesting to see how much of that could be used for this.

bhill2: Thanks folks, bye!

<wseltzer> trackbot, end teleconf

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/11/17 22:13:37 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/both timeless _and_ Josh_Soref are here?//
Succeeded: s/present+ Josh_Soref/present+ timeless/
Succeeded: s/scribenick mkwst//
Succeeded: s/zakim, present+/present+ terri/
Succeeded: s/q+   X-Frame-Options and CSP impacts?/q+ to mention X-Frame-Options and CSP impacts?/
Succeeded: s/Josh_Soref/timeless/G
FAILED: s/scribenick mkwst/scribenick: mkwst/
Succeeded: s/woah .. sorry guys, I need to learn the speaker queue :(//
Succeeded: s/TOPIC: UI Security and Visibility API//
Succeeded: s/No./None./
Succeeded: s/less ambiguous//
Succeeded: s/er, "none" is better I guess//
WARNING: Bad s/// command: s/can someone eating carrots/celery please mute//
Succeeded: s/(can whoever is eating an apple please mute?)//
Succeeded: s/Reason to ban/(Anne, and the web's) Reason to ban/
Succeeded: s/4. Cookies!/4.-Cookies!/
Succeeded: s/4. Cookies!//
Succeeded: s/4.-Cookies!/4. Cookies!/
Succeeded: s/If we know visibility,/Another feature not yet written-up: If we know visibility,/
Succeeded: s/location.ancestorOrigins/"location.ancestorOrigins" April 17th, 2012/
Succeeded: i|Input directive for CSP|scribenick: mkwst
Succeeded: i|mkwst: browsers|scribenick: bhill2
Succeeded: i|bhill2: Agenda bashing|scribenick: mkwst
Succeeded: i|Agenda bashing|topic: Agenda bashing
Succeeded: s/TOPIC: Minutes approval//
Succeeded: i|2015-10-28-webappsec-minutes.html|TOPIC: Minutes approval
Succeeded: s|s/scribenick mkwst/scribenick: mkwst/||
Succeeded: s|s/can someone eating carrots/celery please mute//||
Succeeded: s|can someone eating carrots/celery please mute||
Succeeded: s|April 17th, 2012|in WebKit and Chrome before April 17th, 2012|
Found ScribeNick: mkwst
Found ScribeNick: bhill2
Found ScribeNick: mkwst
Inferring Scribes: mkwst, bhill2
Scribes: mkwst, bhill2
ScribeNicks: mkwst, bhill2
Default Present: mkwst, gmaone, jww, ckerschb, tanvi, timeless, dveditz, Brad, Hill, francois, terri, wseltzer
Present: mkwst gmaone jww ckerschb tanvi timeless dveditz Brad Hill francois terri wseltzer
Regrets: wseltzer
Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2015Nov/0051.html
Found Date: 16 Nov 2015
Guessing minutes URL: http://www.w3.org/2015/11/16-webappsec-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]