See also: IRC log
<mkwst> Uh oh. No chair === confused Zakim.
<dveditz> we're supposed to be using something else now?
<mkwst> trackbot, prepare teleconf
<dveditz> webex?
<trackbot> Date: 29 June 2015
<JonathanKingston> I'm on via Skype, sorry I couldn't sort a better line for today.
<mkwst> I'm one of those, but no idea which one. :)
<mkwst> dveditz: Anything to add to the agenda?
<dveditz> scribenick: mkwst
<dveditz> http://www.w3.org/2011/webappsec/draft-minutes/2015-06-15-webappsec-minutes.html
dveditz: July 13-14 at
Mozilla.
... Will send out a link to where exactly we'll be heading.
It's on a Wiki somewhere.
<francois> https://www.mozilla.org/en-US/contact/spaces/berlin/
dveditz: Defined set of topics
for that?
... upgrade-insecure-requests, SRI, other specs related to
HTTPS.
<wseltzer> +1 to HTTPS switch
dveditz: Switching to
HTTPS.
... Anything to add to that? Will overlap with the TAG on the
14th.
... Some folks are concerned about breaking sites by migrating,
etc.
mkwst: Good converation for the list over the next two weeks.
wseltzer: Any logistical things to do? Sign in in advance? Check in?
dveditz: I've never been there. francois probably hasn't either.
<wseltzer> https://wiki.mozilla.org/Berlin_Office
dveditz: Regular Mozilla badges don't work there. We're all on our own.
francois: I'll look into it. Think we just need to sign in and go.
dveditz: There's a sticky name
badge. It's exciting.
... Other than that, probably nothing.
... Could be tight. Execs are visiting too.
... Might get bumped to a smaller room.
<dveditz> scribenick: dveditz
mkwst: there hasn't been a lot of
change since the last discussion
... hasn't been something I've been actively working on
lately
<wseltzer> https://w3c.github.io/webappsec/specs/csp-pinning/
mkwst: CSP pinning is a mechanism
by which a site can declare a policy that should be applied to
every page
... we discussed two possible ways -- a default policy that
individual pages could tighten, but not remove
... the other option would be to set a policy that applies only
if there are no policies from the page itself, such as for
error pages
... the spec currently goes with the former -- policy is always
applied -- but there are good arguments on both sides
... what makes sense to me is to have the default be a policy
that applies if no page policy, with an option to make a
blanket policy
... the other open question is the delivery mechanism
... the spec has one mechanism, there are two other ways... 1)
would be a manifest, which fits with the concept of a web
"application"
... but the manifest has a different scope than CSP (which
would be origin-wide) and manifests can also be scoped to @@
which doesn't fit with an origin-wide setting
... a manifest can also sometimes define policy for other
domains (if installed from that domain)
... 2) someone also suggested a file on disk (e.g. under
/.well-known) similar to a manifest, but separate to avoid the
above concerns
... biggest question is whether we can allow this to apply to
more than just one domain -- such as HSTS's includeSubdomains
feature
... but HSTS has a self-verification mechanism (if the site
isn't tls it fails miserably)
wseltzer: I'm interested in
thinking about the "include subdomains" bit... are there places
it could go wrong? clearly there are
... yet it seems useful for sites using subdomains as an
isolation mechanism
mkwst: the question is what
extent we can treat subdomains as the same entity
... in the sense of having administrator control
... we're forced to to some extent due to cookies, but that's a
bad reason
wseltzer: this is related to the
work by dbound at IETF talking about the public suffix
list
... at the highest level "is this a domain delegated by a
registry or by a private entity?"
... if a university sets subdomains for all of its students how
much control should the university have over them?
mkwst: I'd like to stay away from
the PSL discussions as far as possible
... it's a complicated problem. there are areas it works well
and areas it does not
... to take your last example the university has complete
control over those machine (most likely) and if they don't they
certainly have control over the dns
<JonathanKingston> Resold domains match this case, like .co.com domains are not normal domains for example
wseltzer: it would be interesting to describe some of these things in DNS -- same level of granularity-- but previous efforts along those lines have been unsuccessful
<wseltzer> https://tools.ietf.org/wg/dbound/
mkwst: that's about it, but I
haven't worked on it lately and not the top of my priority
list
... have taken feedback to heart and have focused on finishing
other specs first
... if we need to update things for heartbeat requirements I
can push an update
wseltzer: every 3 months is recommended
<wseltzer> http://www.w3.org/2014/Process-20140801/#three-month-rule
mkwst: ok, then I'll publish a new WD based on what's there right now, but otherwise I think other work in our queue is more important
<mkwst> scribenick:mkwst
<scribe> scribenick: mkwst
deian: Delayed with the COWL spec.
<dveditz> Confinement with Web Origin Labels (COWL)
deian: Getting close to something like a working draft.
deian: Not sure if folks have looked at it yet.
<deian> http://cowl.ws/spec.html
deian: Pushing it out now for
discussion.
... To summarize:
... Want to extend the web model with labels.
... Confidentiality labels and integity labels.
<tanvi> did the call get cut off?
deian: Should associate a label
whenever you share data (postMessage, etc).
... Compliments the existing model, share data, determine with
whom it can be further shared.
... Labels and priviliges are main concepts.
... Once I read data, I'm tainted.
... based on labels.
... Privileges gives you ownership over your own origin,
declassify/endorse data for this origin.
... Because conjunction/disjunction, can delegate
privilege.
... In the current draft, have described the concepts and
interfaces.
... Introduced a new primitive, labeled objects.
... Can send object over, policy is imposed at that
point.
... Anything that's structurally clonable.
... Also a header mechanism.
... Extending XHR/Fetch to return labeled objects.
... Labels are enforced at context boundary. IFrames are a
natural choice.
<JonathanKingston> Mike could you mute your mic please?
deian: Spec also introduces lightweight workers.
(JonathanKingston: Sorry!)
scribe: Can delegate privilege to
the workers.
... Should that concept be part of the spec? Moved to v2?
... All specified now? Rip out bits for draft?
wseltzer: To advance a spec, you
need two independent implementations of all the key
features.
... If things will lag behind, then subsets make sense as a
v1.
... Could be faster than labeling things as "at risk" and
taking them out.
... Easier to wrap hands around a smaller spec.
mkwst: Ditto.
deian: Enforcement. Specified in terms of CSP?
<scribe> ... New directive into CSP.
mkwst: What do you mean by "enforcement"?
deian: We perform the checks
ourselves.
... current context has a label, which could map to a
CSP.
... Say you have "example.com". You can talk to "example.com",
but no one else.
... Still need label checks in the spec, but when contexts talk
to other contexts or to servers, that maps well to CSP.
mkwst: CSP only allows tightening.
deian: Would have to keep track of policy set by COWL vs header. But would want the union.
<wseltzer> mkwst: CSP is already pretty far out of date
<wseltzer> ... with respect to Fetch
<wseltzer> ... so CSP3 will be rewriting a lot
deian: Ok. Will look at fetch
too.
... Will chat with mkwst later.
JonathanKingston: If I load
Stripe on a website, how do I restrict Stripe to sending data
to stripe.com, without restricting the parent page?
... Site shouldn't own the data the user typed in.
deian: Would help to have
lightweight workers. Or an IFrame.
... Set the label of the frame to "stripe.com", it can only
talk to stripe.com without restricting the parent.
JonathanKingston: I'd prefer the embedding site not to see what's put into the Stripe IFrame.
deian: Labeled objects: unless
you inspect the data, it won't taint your context.
... Stripe could give you an object, you could hold onto it. It
won't effect your ability to communicate until you look at the
data.
JonathanKingston: Ok.
deian: will add that as a use case into the spec.
dveditz: Have you given thought to how sites could misuse this for evil?
deian: Yes.
... Navigation source === can't navigate away if you fully
taint your context.
... Not too worried about misuse of the rest.
... Should be using this _in addition to_ everything else,
though.
... Tempting to loosen CORS, for instance, but need to be
careful about doing so.
dveditz: For navigations, maybe
if user agents obey what a user says (address bar, bookmarklet,
etc).
... Some sites will say "paste this!", so that's not a
guarantee.
deian: Bookmarklets are injected
into the page, so maybe they should be governed by
COWL...
... Will further explain the guarantees this provides.
... Question for FPWD.
... How complete does it need to be?
wseltzer: Idea is to have a
scaffolding that's enough to show people what's going to be
there, and for the group to agree that it should go out as an
FPWD.
... When you think it's ready, send a signal, we'll start the
process moving.
deian: Great! Might be ready by the end of the week.
dveditz: Ok. That seems to have
covered the two topics we had for this call.
... Close it up?
<wseltzer> mkwst: CfC on Mixed Content to Proposed Rec. Please send comments/feedback
wseltzer: Looking forward to
talking at the F2F about all the good work we're doing
here.
... Telling the broader story about the things we're doing to
help secure the web.
dveditz: Thanks everyone.
... Next call would have been during the F2F. Maybe we'll have
a call? Will check with Brad.
... May call in for folks. Might be an odd schedule for
that.
... Will send out a mail.
<deian> wseltzer: thanks! :)
wseltzer: Will be bidding farewell to Zakim. Next time, new numbers anyhow.
dveditz: Is there a phone number for the new thing?
wseltzer: Yup. You can dial it from a telephone.
dveditz: See you in Berlin!
<dveditz> ok, thanks
<wseltzer> s/
<dveditz> I don't think I had two spaced in "be handled"
<dveditz> s/wseltzer: does RRSAgent go away at the same time? if so how is IRC logging going to be handled?//
<dveditz> :-) thanks
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/@@?/dbound at IETF/ WARNING: Bad s/// command: s/wseltzer: does RRSAgent go away at the same time? if so how is IRC logging going to be handled? Succeeded: s/wseltzer: does RRSAgent go away at the same time? if so how is IRC logging going to be handled?// Succeeded: s/wseltzer: does RRSAgent go away at the same time? if so how is IRC logging going to be handled?// FAILED: s/wseltzer: does RRSAgent go away at the same time? if so how is IRC logging going to be handled?// Found ScribeNick: mkwst Found ScribeNick: dveditz Found ScribeNick: mkwst Found ScribeNick: mkwst Inferring Scribes: mkwst, dveditz Scribes: mkwst, dveditz ScribeNicks: mkwst, dveditz Default Present: +1.503.712.aaaa, [IPcaller], +1.310.597.aabb, +1.778.785.aacc, +1.831.246.aadd, dveditz, terri, gmaone, +1.646.355.aaee, tanvi, +1.778.785.aaff, deian, francois, Wendy Present: +1.503.712.aaaa [IPcaller] +1.310.597.aabb +1.778.785.aacc +1.831.246.aadd dveditz terri gmaone +1.646.355.aaee tanvi +1.778.785.aaff deian francois Wendy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 29 Jun 2015 Guessing minutes URL: http://www.w3.org/2015/06/29-webappsec-minutes.html People with action items:[End of scribe.perl diagnostic output]