WebAppSec Teleconference 21-FEB-2017 -- 21 Feb 2017

<bhill2> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2017Feb/0024.html

agenda bashing

<deian> zakim is +646-821-1675

<inserted> scribenick: bhill2

no additions

minutes approval

prior meeting minutes approved by unanimous consent: https://www.w3.org/2011/webappsec/draft-minutes/2017-01-25-webappsec-minutes.html

Recharter

wseltzer: draft charter has gone out to Advisory Committee, anyone who can, contact your AC rep and urge support

<wseltzer> https://lists.w3.org/Archives/Public/public-new-work/2017Feb/0014.html

<wseltzer> [[This Working Group will use the W3C Software and Document license for all deliverables.]]

<wseltzer> https://www.w3.org/2011/webappsec/charter-2017.html

wseltzer: we have also updated to use a more permissive creative commons attribution license

mkwst: can we publish all of our new work under that license?

wseltzer: if anyone objects to re-licensing then we may need to discuss, otherwise charter says we will use the new license for all deliverables

mkwst: I would like to interpret it that way

dveditz: how about reach out to editors and see if anyone objects

wseltzer: goal is to make it easy to take excerpts for documentation, code, etc. permits forking but only w3c official version has the patent commitments

<dveditz> (actually I meant send an announcement to the mailing list that this is what we're doing, barring strenuous objections. And reach out to other editors to have them do the same)

Specs from CR -> PR -> REC

email reply on this from mkwst: https://lists.w3.org/Archives/Public/public-webappsec/2017Feb/0025.html

mkwst: will look into HTML deps, but Fetch is more the outstanding question, whether we can make that work in the w3c context
... bz has some clarity and definition comments for Mixed Content. Don't think he wants any normative changes, but restructuring may change words that have normative meaning

dveditz: don't see any open issues on the spec

wseltzer: working with PLH to address Fetch dependency concerns

bhill2: we have also made promises to keep an eye on things and move ahead in the past

wseltzer: we are working to satisfy director that we're doing that
... also re: giving Fetch a forward reference from CORS

mkwst: link shows bz's questions about clarity of optionally blockable
... plan to do that before moving forward
... don't think that any tests will change
... we should be able to make any changes in a non-normative way
... looked at Mixed Content tests in WPT, vast majority look good and is fairly thorough
... a couple have bitrotted
... blink is now importing WPT w/ bi-directional sync
... which is awesome, but also shows that many tests we wrote don't work the way we want
... generally speaking, fairly good agreement between browsers
... UIR is in a very similar situation. test suite in WPT not as robust
... plan to upstream some of the blink tests
... if FF folks also have tests to upstream, would be excellent to cooperate
... three fairly robust implementations
... Secure Contexts - not much normative by itself, defines hooks for other specs
... only normative thing is window secure context attr

dveditz: we have a few issues at Mozilla. Literal localhost secure or not? As long as it resolves. We should just assume that it does.

ccowan: +1 to that

mkwst: section 5.2 says UAs may treat localhost as potentially trustworthy if they follow the local resolution rules

<wseltzer> https://github.com/w3c/webappsec-secure-contexts/issues/43

dveditz: other one is about window.opener, has lead some sites to break unless you refresh or kill the opener

<wseltzer> https://github.com/w3c/webappsec-secure-contexts/issues/42

dveditz: think we need to resolve that issue before
... we advance

shall we do UIR to Proposed Recommendation? 3 impls, no outstanding issues, Fetch integration is high-level

mkwst: will look at test suite upstreaming

bhill2: I will ping Apple re: same

Move UI Security Directives for CSP to NOTE status

https://www.w3.org/TR/upgrade-insecure-requests/

<inserted> scribenick: mkwst

bhill2: The ED is from May 2016, pretty stale.
... Side conversations at TPAC; still interest in the concept, but will likely make progress as part of a v2 of Intersection Observer rather than this particular form.
... In the interest of clearing the slate, I think we should take it to NOTE.
... Then monitor progress of intersection observer.
... If the IPR commitments we've made in this group would be helpful to that effort, we can do a joint deliverable, etc.

dveditz: No luck getting our platform guys interested in this.
... As much as it seems useful from NoScript's implementation.

<bhill2> https://w3c.github.io/webappsec-uisecurity/index.html

gmaone: If we build a mechanism through CSP or something else, we can assume that the page wants to be protected. So the overhead of a ClearClick-style solution is tough to justify.
... Intersection Observer might be a better approach.
... Looking closely at these anyway as a possible helper for a cross-platform solution for NoScript.

bhill2: If you look at the latest draft, it's rewritten to be in the style of Intersection Observers.
... Now that Intersection Observers are final, I think enhancing that is a better route.
... If no one's dying to implement this, then let's take it to NOTE.

<bhill2> sounds like consensus on call is to issue a broader CfC to take to note

Status for COWL

deian: I've been slow on this. There has been some implementation work.
... Refactoring Firefox to deal with [...] iframes.
... After talking to Joel, it seems like the right way to go is to deal with a confined iframe mechanism instead of dealing with WebSockets, etc.
... Refactoring to eliminate access to these APIs.
... I think I can get that done this week to reflect the changes in the implementation.
... If it's possible to give it a little more time, I'd appreciate that.

bhill2: Not in any hurry, just a good time to take stock of where we are, have honest discussions about what's moving and what isn't.
... If there's progress on adoption, we don't have to close the door on it today.
... Joel's no longer at Google. ( :( )
... Might want to talk to evn@, he's also looking at iframe-based isolation.

mkwst: Yeah, conversations are good to have. It's not at the top of our priority list, but it's worth talking about.

<bhill2> http://sirdarckcat.blogspot.com/2017/01/fighting-xss-with-isolated-scripts.html

Call structure for 2017. Back to spec-based calls?

bhill2: wseltzer, are there things you can tell us about other group's structure, process?
... What can we learn from how other folks structure their discussions? What can we learn from incubation model?

wseltzer: WICG is a thing, folks have been using it as a catch-all for new things.
... I can ask the chairs what they're doing to monitor work for incubation.
... W3C team is trying to keep an eye on CGs for things that might be ready to move to REC track work.
... This group is free to pick up anything that fits within the chartered scope.
... We have freedom to pick up interesting things without rechartering.

bhill2: Would it make sense to, as part of structuring call agendas around specific topics, do a check-in with folks working on those interesting things through WICG. CORS-RFC1918, etc.

wseltzer: SGTM. We're asking those communities to give us signals when they think their work is ready for wider review.
... Surface those topics coming from folks we might not be as familiar with.

<bhill2> mkwst, any thoughts on how you would like to see this group interact with things in incubation?

<inserted> scribenick: bhill2

mkwst: things that are relevant to this group are being done by the same people in this group
... only distinction is the technical and legal distinction is that some things are directly covered and others are not
... would find input from this group to be valuable to things I'm working on in WICG

wseltzer: procedural steps most relevant is at time of publishing a FPWD
... we can note things going on elsewhere and discuss under terms of CG process and then bringing onto REC track triggers CfC.

mkwst: good test case is suborigins spec
... we never actually published a FPWD, have a fairly complete implementation in Chrome and want to move forward as an origin trial in relatively near future
... since it hasn't been published; would be in incubation if that had existed, but now it is in limbo
... we should clarify since Joel has left Google
... we should communicate with him what future contributions he could make and on what terms