See also: IRC log
<bhill2> Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2017Feb/0024.html
<deian> zakim is +646-821-1675
<inserted> scribenick: bhill2
no additions
prior meeting minutes approved by unanimous consent: https://www.w3.org/2011/webappsec/draft-minutes/2017-01-25-webappsec-minutes.html
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)
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
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
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
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
mkwst: would like to ship in near future, feedback would be extremely helpful
<wseltzer> https://w3c.github.io/webappsec-csp/embedded/
https://www.w3.org/TR/csp-embedded-enforcement/
mkwst: this is part of this
group, we have a FPWD. incubation didn't exist
... so this group should take a look, if not done, it is very
close
mike also suggests attention to: https://github.com/whatwg/fetch/pull/465
and https://github.com/whatwg/fetch/pull/464
march also starts on a Wednesday, so next regularly scheduled call is on 15-Mar
thanks!
This is scribe.perl Revision: 1.148 of Date: 2016/10/11 12:55:14 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: i/ED is from May 2016/scribenick: mkwst Succeeded: i/things that are relevant to this group are being done by the same people in this group/scribenick: bhill2 Succeeded: i/no additions/scribenick: bhill2 Found ScribeNick: bhill2 Found ScribeNick: mkwst Found ScribeNick: bhill2 Inferring Scribes: bhill2, mkwst Scribes: bhill2, mkwst ScribeNicks: bhill2, mkwst Default Present: mkwst, bhill2, wseltzer, dveditz, gmaone, deian, ccowan Present: mkwst bhill2 wseltzer dveditz gmaone deian ccowan Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2017Feb/0024.html Got date from IRC log name: 21 Feb 2017 Guessing minutes URL: http://www.w3.org/2017/02/21-webappsec-minutes.html People with action items:[End of scribe.perl diagnostic output]