See also: IRC log
rrsagent make minutes
<scribe> Scribe: Brad Hill
<scribe> scribenick: bhill2
<tanvi> mkwst: ping. can http pages set upgrade-insecure-requests? if so, then making it part of mixed makes less sense
<mkwst> tanvi: Yes, as currently specced.
<mkwst> which is why it's called `upgrade-insecure-requests`, and not `upgrade-mixed-content`.
<tanvi> mkwst: was there a resolution on whether it should be part of mixed or a separate spec?
<mkwst> tanvi: Welcome to the call on which I expect people to give their opinion about topics like that one!
:)
<mkwst> tanvi: Because no one uses the list anymore! :)
<tanvi> mkwst: okay great
<tanvi> i'm dialing in in a minute
who's on from Microsoft?
(thanks, Dan!)
<dveditz> http://www.w3.org/2011/webappsec/draft-minutes/2015-02-09-webappsec-minutes.html
dveditz: Any objections to
unanimous consent to approve minutes?
... hearing no objections, minutes adopted unanimously
no agenda bashing
dveditz: webappsec chairs and
wendy had a call with the TAG on the Powerful Features draft
regarding Mozilla's objection
... not all people from Mozilla were on the call,
unfortunately
... the TAG is interested in the concept behind the
document
... they have deferred to this WG to come up with a formal
definition as opposed to a TAG finding
... would like to see that happen
... Powerful Features has 2 parts : defining what a
sufficiently secure context is, and recommendations on how to
tell if you are a powerful feature that should restrict itself
to a secure context
... the algorithm on secure context determiniation is
non-conteroversial
... the objection is to whether there should be a description
at all of how to make the determination whether a feature
should be secure-only
<mkwst> bhill2: Conclusion was the TAG was willing to take on the document as a joint deliverable
bhill2: where we came to, was TAG
was willing to take this on as a joint deliverable
... with idea that description of when to apply would be
non-normative
<mkwst> tanvi: the airport behind Brad. :)
<dveditz> tanvi: it's brad, I'm leading because he's in a noisy place
<tanvi> ah okay
bhill2: and that controversy
about application of the algorithm to a feature would be
resolved by the TAG
... as the elected body representing the W3C Membership
dveditz: other parts of the
objection I think have been resolved
... async decision process
... COWL spec description
... concerns whether it is implementable, but not an objection
to spec or concept
... if it can't be implemented, it won't move to Rec
anyway
... EPR and compatibility with linking
... should be fine so long as final spec respects user
wishes
drx: have heard this feedback,
people are passionate about it
... no immediate solution but we need to take into account as
we develop the spec
... and will be working on it
<JeffH> drx = ?
drx is David Ross (google)
<drx> yes
crispin: about my "privileged" name suggestion...
dveditz: powerful is a poor choice, we should think of a better word
<dveditz> bhill2: we have at least 2 people at Mozilla who object to include more than a few minor examples in the spec
<dveditz> ... and members of the TAG who want a more thorough fleshing out of why features should only be in a secure context
<dveditz> ... don't think we're going to divide the baby any further
<dveditz> ... this group needs to decide whether we have addressed Mozilla's objection as far as we want to and move forward to presenting the response to the director
<dveditz> ... or if we want to change the scope of the spec now
<dveditz> ... I'd like to resolve this now
<dveditz> mkwst: I'd like to move, unsurprisingly, that we continue.
<dveditz> ... the section strongly objected to is no longer normative
<dveditz> ... and I think we can come up with language people are happy with
<dveditz> bhill2: would love to hear from a few other people on the record. thx mike
<dveditz> ... with my hat as an individual I'd like to 2nd mike's point
bhill2: hat=individual, second mike's opinion
<dveditz> wseltzer: with my w3 team contact hat on we can go back to mozilla and ask if these changes satisfy their objection
<dveditz> ... and if they don't remove their objection we can bring it up for consideration by the director that this proceed notwithstanding their objection
+1, yes Mozilla has been helpful and reasonable, just a difference of opinion
<dveditz> ... I'd like to add publicly that Mozilla has been helpful in allowing the objection to be discussed openly, I don't think they are being obstructionist
dveditz: this is a helpful way
forward, we have differing points of view whithin mozilla
... so would be good to go back to David Baron, our AC rep to
get a formal response and remove any sections of the objection
that have been resolved
... and get a reduced objection at least, or possibly remove it
entirely
<wseltzer> ACTION: Wseltzer to ask Mozilla AC rep about the current status of their charter objections [recorded in http://www.w3.org/2015/02/23-webappsec-minutes.html#action01]
<trackbot> Created ACTION-214 - Ask mozilla ac rep about the current status of their charter objections [on Wendy Seltzer - due 2015-03-02].
dveditz: please poke David on that
wseltzer: I will do that
I'm not aware of other open charter issues
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0003.html
mkwst: CSP Pinning spec is
application of pinning concept to CSP
... a certain policy should apply to every page on a host +
subhosts
... some people are interested, some people are not and don't
think it's a good use of group's time
... no real feedback, can take that as positive. Is there
consensus that this is enough?
<wseltzer> +1 I think it's useful
+1, I will also respond on list
<JeffH> you mean essentially an "includeSubDomains" directive for CSP ?
<mkwst> jeffh: https://w3c.github.io/webappsec/specs/csp-pinning/
mkwst: includeSubDomains is one part of the proposal
<JeffH> ok, I'll try to review it
<mkwst> jeffh: I'd appreciate it!
dveditz: no objections, resolved to publish FPWD
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0207.html
+1 strongly support!
mkwst: Brian Smith thinks this
should be part of Mixed Content spec, which explains the
problem domain
... I (mkwst) think that it is complex enough to be best served
in its own document
devd: is disagreement about whether it should be its own spec?
mkwst: haven't seen any disagreement on concept
dveditz: I have elsewhere
devd: only automatically, or is there disagreement when there is explicit opt-in via header?
<JeffH> Also, i have feedback on w3c.github.io/webappsec/specs/mixedcontent/ to write up -- just editorial at this time
devd: don't think it matters where the spec should be, we should defer to the editor's preference
<mkwst> jeffh: that'd be great!
terri: in working with implementers, it is easier to give them one spec than several
<JeffH> this "multiple specs vs a single spec" is very common one in the spec-writing world.
mkwst: would be helpful to have an explainer document for all the specs this group has produced
<JeffH> "explainer doc" == "road map"
mkwst: think it would be more useful than trying to combine everything
terri: I agree this would be useful
jeffh: often referred to as a road map document
I think the most important gate for a FPWD is that people want to move ahead with the concept (for IPR sake) and we can combine later if we need
but no need to delay for now
dveditz: that amounts to consensus to publish, then
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0295.html
deveditz: any issues open if we don't merge upgrade?
mkwst: one open issue is TimBL's
point, but I consider it closed as he has not responded, but
may come up in transition process
... 2nd question is what to do with fetch
... see rsleevi's recent thread on a new fetch mode for media
that bypasses mixed content checking
... starting with a way to lock everything down is the right
way to start
dveditz: any objections to publishing CR of Mixed Content?
<mkwst> (CR, not CR)
<mkwst> (We've been through last call)
dveditz: hearing no objections, resolved to publish Mixed Content as Candidate Recommendation
yay!
<JeffH> wseltzer: have a ptr to the "new process" ?
<wseltzer> JeffH, http://www.w3.org/2014/Process-20140801/
<JeffH> thjx
dveditz: do we have right people on call?
<francois> francois is here too
bhill2: failing closed catches
algorithm typos, etc.
... failing open allows new algorithms to be deployed before
long tail of browsers that don't understand them go away
completely
devd: SRI isn't protecting against typos, failing open is important for forward compat
<JeffH> actually, in reviewing various sources, the terms "fail open" and "fail closed" are used ambiguously and inconsistently, so need to be applied/used in a clearly-defined context
bhill2: we do support multiple algorithms?
devd: at scale, long tail is horrible...
<francois> i think the biggest issue is what do we do on an old SRI-enabled browser that encounters a "sha3-..." integrity attribute?
<JeffH> in an electrical circuit context, fail open means that current doesn't flow.
jww: need to inform developers that their hash is not good, not sure spec is right place to do it
dveditz: don't want to say that spec should never fail closed
devd: if agree it is an informing a developer issue, not a security issue, spec shouldn't say how to inform devleoper
<dveditz> Zakim: who is in the speaker queue
francois: other case is if we
fail closed we could get into a situation where a browser
supports SRI but is older and it encounters an integrity attrib
it doesn't know about
... a really old browser that doesn't support SRI would work,
but an old impl of SRI would fail
<freddyb> I lean towards agreeing with francois
sounds like everyone agrees on fail open, I'll withdraw my typo-related taking of the opposite side
<freddyb> we should encourage security imporvements (e.g. someone moving to SHA-3,4,5,.. :)), which fail-close may not.
<francois> just to be explicit, by "failing open" we mean "not blocking the load"
<freddyb> +1
<JeffH> "fail open" as being used in the context of SRI means, it seems, that the integrity check of the subresource in question is not successful ?
<freddyb> Content-type discussion was @ https://github.com/w3c/webappsec/issues/176
<JeffH> looks like francois and I have different understandings wrt "fail open" ?
<jww> We're specifically discussing "fail open" in the case that a hash algorithm is unknown/considered insecure
<jww> (not that the has value is incorrect)
<dveditz> JeffH: what jww said, we're only talking about unknown (typo'd) algorithms. the author has said "ensure this hash" and the browser doesn't know how
<freddyb> github issue about the content-type discussion is at https://github.com/w3c/webappsec/issues/176
bhill2: could we pass an argument to fetch to say treat as if no-sniff, even if server doesn't send
<dveditz> not talking about cases where the browser knows how, the rest of the spec is clear on that
but say the server says "this is a gif" but doesn't set no-sniff, you should treat it only as a gif, never a jar
I'm ok with leaving this out for v1
devd: fine with allowing it to be specified, but don't want to make it mandatory
francois: currently if you specify a content-type as part of the attribute it will be enforced, if you don't include one then only the hash will be enforced and there will be a devtools warning
dveditz: thought we're not using ni:// url form
francois: correct, there is another way to specify content-type in the new syntax
<JeffH> dveditz: thx
mkwst: deciding the grammar now is important to keep option to move towards cache semantics later
devditz: anyone think we should take it out, even if not mandatory?
I don't object to making it optional
right on time!
I need to get on a plane, thanks, Dan!
wendy - can you handle the end-of-meeting zakim / rrsagent stuff?
<wseltzer> trackbot, end teleconf