Web Application Security Working Group Teleconference

18 May 2015


See also: IRC log


mkwst, manu, dlongley, +1.503.712.aaaa, terri, +1.206.876.aabb, +1.206.348.aacc, +1.418.907.aadd, [Microsoft], francois, +1.310.597.aaee, dveditz, ekr, bhill2, tanvi, +1.617.324.aaff, keiji, vgb, +1.415.857.aagg


<bhill2> wseltzer, I can't find the minutes for the last meeting...

<bhill2> http://www.w3.org/2015/05/04-webappsec-minutes.html

<bhill2> even http://www.w3.org/2015/05/04-webappsec-irc is missing...

<wseltzer> it looks as though rrsagent was never there

<wseltzer> but I have backlog still

<wseltzer> starting part-way through

<wseltzer> http://www.w3.org/2015/05/04-webappsec-irc.txt is what I have

<wseltzer> bhill2, if someone has better logs, I can generate the full minutes

<bhill2> thanks, I'll ask on the call if anyone has scrollback saved

<wseltzer> and using "trackbot, start teleconf" gets all the bots going at once

<wseltzer> trackbot, start teleconf

<trackbot> Date: 18 May 2015

<gmaone> Is zakim@voip.w3.org broken? I get "500 - Service unavailable", while the echo test (123@voip.w3.org) does work.

<tanvi> bhill2: yes, i can send you my irc logs

<bhill2> if anyone has last meeting's IRC logs, I could use them

<tanvi> sent

drx-goog: What is EPR?
... intended to be complementary to CSP against XSS, but also address CSRF

<bhill2> scribenick: mkwst

drx-goog: difficult to implement full locdown CSP
... EPR is another option to address the issues.

<tanvi> a bit hard to hear.

drx-goog: EPR is intended towards self-contained webapps.
... web page admin interface. consequences of compromise are catastrophic.

<dveditz> https://w3c.github.io/webappsec/specs/epr/

<ekr> Is it just me that is having trouble hearing?

drx-goog: How EPR works?
... Each site that wants to opt-in serves a header that says "I support EPR."
... corresponding policy file.
... externally sourced navigation requests to non-entry points have an action defined by the policy.
... "externally sources" === policy doesn't apply for user initiated navigation, same-origin navigation, address bar, bookmarks, etc.
... various actions: blocking outright, redirection, etc.
... applied on a per-policy basis.

<tanvi> so policy works for things like window.open?

drx-goog: That's a quick overview. Questions?

bhill2: I have a few questions. The spec says that the delivery mechanism is specified in terms of Manifest.
... Other parts are hinting at things that don't match up.
... One policy per origin?
... Manifest spec allows multiple manifests per origin on a path basis.
... Intent to allow more than one manifest per origin?

drx: Not today.
... Format would be the same as manifest spec.
... Policy file would be separate.
... No fundamental objections to combining them.
... Multiple policy files per origin? I hadn't accounted for that in the spec. Wasn't intended.

bhill2: Implies that the manifest might come from a different origin.


bhill2: Need to define the algorithm clearly.

dveditz: Manifest specified in a <link> tag in a document.
... Might be in a document without such a tag, not intended to be part of the app?
... Suggest .well-known instead.
... Multiple policies for the same origin isn't workable; in an origin, don't know where you're going.

drx: Agree. Today, would set one policy file in a well-defined location, could make it flexible.
... using the `Link:` HTTP response header field could solve the <link> tag problem.
... Not in the spec, but if interest, we could add it.
... Hardcoded is simplest.

dveditz: Would it be better to use a max-age like HSTS/HPKP in case sites lock themselves into a bad policy?

drx: That was the original idea, now we're just using the default cache header expiration.
... do recognize that problem. Could certainly be the case however one specifies the expiration, if a broken policy is served, etc.

dveditz: Cache might expire things faster than you'd like.

drx: I see. One thing mentioned in the spec is the idea that when a policy takes effect you can decide to issue an async request for the policy file to refresh.

<terri> Caching might also be a bit of an issue if we start talking per-path policy. That could result in a bunch of extra round trips

drx: UAs could implement sane behavior here.
... Perhaps "the first time violation happens in a day, pull down a new copy".
... More questions?

bhill2: If I've seen the header, and downloaded the manifest, covers a resource, and then load that resource that doesn't contain the EPR header, do I apply the policy?
... Given a.html and b.html: a.html has an EPR header. I download the manifest, declares that b.html should be covered.
... I load b.html, not served with an EPR header. Do I apply the policy?

drx: it would apply the policy. interesting point, though.
... lack of EPR header doesn't mean you've opted out of EPR.

bhill2: tricky to say that you can be opted in without sending the header.
... If one resource can set a header which impacts policy elsewhere on the origin, we should be cautious about specifying the behavior.

drx: Not defined today, we should be careful.

bhill2: If I see manifest data, but no EPR header, should I apply it?

drx: No. No header, no EPR.
... Should specify that.

bhill2: Have you thought about interactions with CORS?
... What is the order of operations/rules for omit-credentials in EPR vs credentials in CORS?

drx: Action that allows to omit credentials seemed like a nice-to-have; need to define more clearly to specify interaction.

bhill2: Rename to "omit-credentils"? Better not to mint new concepts, but to reuse names.
... Whatever fetch says.
... "credentials=omit" => "omit-credentials"?

dveditz: Do the redirect URL/reporting URL need to be same-origin?

drx: Should be explicit; should lock to same-origin.

<bhill2> we don't lock CSP reports to same-origin...

dveditz: In the IDL, misusing `sequence`. Only for parameters/return values.
... check with Anne.
... Concerned about regex bit here. Wild west. Flavours, etc.
... Even if we reference JS, it's changed over time.
... Wondering if there's a better way.
... Simpler globbing format, perhaps?

drx: Probably fine. Needs to be finer-grained than a string comparison.
... Implementing this via the prototype, we needed to specify something under a path, for instance.

dveditz: Unix utils; basic/extended regex.
... Would be nice to have a basic version.
... Minor concern, just not well specified yet.

drx: Want to point to something that exists. Don't want to define something new.
... Just need to be a bit more flexible than string comparison.

dveditz: And not just a simple prefix match?

dwalp: Check the apparmour(?) format. It does something similar.

<francois> apparmor, actually

https://wiki.ubuntu.com/AppArmor ?

ccowan: Opensource linux security product.
... Developers on it are at Ubuntu.

<terri> I'd be surprised if there isn't some well-defined implementation of regex we could use somewhere

dveditz: Navigational seems wordy. Perhaps "document" or "page"?

<dlongley> http://www.ecma-international.org/ecma-262/5.1/#sec-15.10

drx: ?

dveditz: Need to type "navigational" pretty often. "document" seems simpler.

drx: "document" would work too, I suppose.

dveditz: The algorithm runs through the rules in order.
... Match one, good to go, don't check anything else.

drx: Yes. Match one, it's an entry point, good to go.
... Then do the default action.
... Unless the UA decides it's exempt, like a bookmark action or etc.

dveditz: Needing to type `allow` is tedious.
... When it's the default on the web, perhaps something else should be the default.
... Don't want a complex policy. Downloading, parsing, etc.

<bhill2> dveditz: time check?

dveditz: allow-data false means that if the request has data it doesn't match, right?

drx: yes. doesn't force the data to be stripped.

dveditz: One more question: has to be a secure request? Only for HTTPS?

drx: Seems reasonable. Don't need to enable for non-secure sites.

dveditz: Something in the middle of the spec. Perhaps should be clear from the beginning that ti's true, or the bit in the middle is confusing.

drx: will pin it down.

dveditz: Section 4.3, step 1.

bhill2: further questions? GitHub issues!
... last words, David?

drx: GitHub issues! Send me email! Chat! Whatever!

<bhill2> scribenick bhill2


Credential Management Level 1

<bhill2> mkwst: a number of issues open, many editorial, some more fundamental

<bhill2> ... summarize first, then turn over to Manu and David for their concerns about extensibility

<bhill2> ... summary of current API

<tanvi> if you are not talking, can you mute

<israelh> +1


bhill2: The part where it says it's applicable to the top-level browsing context.
... Concern is that the user doesn't understand anything other than the address bar.
... Set ofuse cases for collecting credentials in frames.

<dveditz> eeeeeevil

bhill2: Prevalent in payment, etc.
... Common use case.

<terri> side note: there's scientific evidence that the user doesn't really understand the address bar, even

<bhill2> mkwst: I agree with you on those use cases, not stunningly common but certainly used on the web

<bhill2> ... would prefer to specify something with a more narrow scope and determine how to open it up more safely

<bhill2> ... address bar is only user context, has been core to model that the spec is putting together

<bhill2> ... hard to understand how to make it safe for iframe to request credentials

<dveditz> terri: too true. but if they understand anything it might be the URL bar and the lock. maybe

<bhill2> ... assume PayPal were to do this ... they don't do this now and there is a reason

bhill2: Paypal does have an iframe flow.

<terri> dveditz: the eye-tracking studies on EV certs found that they don't even look at the url bar and lock, even when they claim to, sadly. But I agree that it's still the best bet, it's just kind of a crappy best bet.

bhill2: in response to other payment providers.

<bhill2> ... if browser is going to ask the user and the origin is different from address bar

dev: Should this spec get into that?

<dveditz> yeah. anecdotally I think my family only checks the URL bar if something on the page "looks off"

dev: Invariant across everything we do.
... We can mention the invariant, but shouldn't specify that.
... Verified by Visa, etc.

<bhill2> mkwst: if you can't trust it, we can't expect anyone to trust it

<bhill2> ... user mediation is critical

<bhill2> .. credential info is sensitive, esp from UI perspective

<bhill2> ... means persistent access to a user's data at an origin

<bhill2> ... going to be confused and not able to make a good trust decision when multiple origins in play

<manu> +1 to mkwst

<bhill2> dev: this is a problem with http basic auth, etc. quick redirects can bypass

<bhill2> ... much harder and broader problem, we won't solve it in this spec

<bhill2> mkwst: set the bare minimum bar

<bhill2> ... possible to do more, not les

<bhill2> dev: worry about doing the bare minimum, it's like doing RC4

<bhill2> ... would rather acknowledge the problem

<bhill2> mkwst: how we decrease security by limiting context

bhill2: I don't like iframe flows, but this UI could increase my trust.
... Chooser must indicate the origin.
... That's trusted interaction, perhaps I'll have better understanding of what's going on.
... Origin-locked delivery to the iframe is a reasonable increase in security.
... Iframe can only ask on its own behalf.
... Protecting the credential itself, this ight be safer, assuming the iframe flows exist.

<bhill2> assuming these flows exist, this is a safer way to handle than excluding htem

<bhill2> israel: can we scope to high level with understanding there is more work to do later, easier to expand.

israelh: Why couldn't we start with the top-level, and perhaps extend to nested contexts later?

<manu> Potential Web Payments IG and Credentials CG concerns here: https://lists.w3.org/Archives/Public/public-webappsec/2015May/0101.html

<bhill2> manu: couple of groups interested in credentials work

<bhill2> ... web payments IG, credentials CG working on slightly different type of credentials

<bhill2> ... would like to harmonize these new types of credentials with the api being created here

<bhill2> ... types of credentials these groups talking about are broader: driver's addresses, proofs of age, address, etc.

<bhill2> ... same origin vs. cross-origin credentials

<bhill2> ... is the current API shape extensible enough to handle cross-origin credentials?

<bhill2> vijay: seems there is a more expansive definition of credential, why do feel they must be accomplished by extending this API rather than creating a bigger framework this API can plug into?

<bhill2> manu: our thinking is very similar, so close we feel we would be duplicating work, vs. just making small modifications on extensibility

<bhill2> vijay: seems like you think it should be possible to put a payment instrument into this API

<bhill2> manu: new credentials are associated with an identifier, not a "has a" identifier relationship

<bhill2> ... we are committed to get something to Mike on an extensibility mechanism

<terri> I have a question about usability work in this space, but I'll try to bring it to the mailing list.

<bhill2> .. we have some questions, specifically about what browsers think about this work, data structures, etc.

<terri> +1 to bringing this to PING

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/06/19 18:08:11 $