<estark> can someone give me the access code?

<estark> 643678745 isn't working...

<estark> hm that's not working for me either

<estark> sigh

Agenda Bashing

johnwilander: question -- is everything clear on Mixed Content level 2 from last meeting?

estark: I don't think there are any questions left to be answered, but Firefox and Chrome are experimenting on different things
... there's not concrete plans yet
... are there things safari would like to experiment with as well?

johnwilander: absolutely. especially if there's an agreed preferred solution we'd like to test

estark: Let's add this to the agenda

johnwilander: I have another issue -- revising a null proposal where servers can tell browsers to block cross-origin requests in general

dveditz: isolate me?

johnwilander: no. let's talk about it if there's time

terri: Intel is excited to have Kenneth Christiansen nominated for TAG . You may get calls from us urging votes for him

Minutes Approval

https://www.w3.org/2018/02/21-webappsec-minutes.html

approved by consent

News

* Gauging interest in TPAC Lyon October 22-26

* CSP 'navigate-to' added to spec

* CSP 'wasm-eval' and 'webrtc-src' discussions continue

SRI IntegrityCheckFailure event

https://github.com/w3c/webappsec-subresource-integrity/issues/77

dveditz: any interest of comments, or should we leave it to github issues

estark: I'd be interested if Scott's customers want this and what the use cases are

johnwilander: I recall discussions on pages being able to search for a value by loading with different integrity values until they find a match

dveditz: we ended requiring CORS for cross-origin integrity checks, I believe
... that's a concern even without this special-case error

johnwilander: so we have to send an Origin header with <script> requests if there's an integrity attribute?

dveditz: I think so but please check the spec.

renewed interest in unsafe-inline style granularity

https://github.com/w3c/webappsec-csp/issues/45

dveditz: renewed interest in this issue, ability to allow inline style attributes without having to allow <style> tags with arbitrary selectors

terri: sounds like this would enable a lot of web sites who use this, and also solve some problems with <img svg>

dveditz: I'm not sure why inline style in an external SVG is affected by the page's CSP. need to look into that
... sounds like people are cautiously supportive of the concept

Additional Mixed-Content level 2 proposals

estark: I can give more detail about what Chrome is doing
... we plan 2 buckets of things. 1) deeper data analysis to answer questions. Put a tighter upper bound on how much breakage we would cause by blocking all passive
... we think a lot of that is ads and trackers users won't notice so we want better numbers on what actually breaks

<tanvi> (can someone share the access code with me)

estark: 2) try a couple variations of auto-upgrading
... <missed a bit>
... won't have results in the next few weeks, this will go on for a couple months

tanvi: we tried auto-upgrade of passive content but have turned it back off
... we continued to block mixed-active content

estark: what kind of breakage did you see?

<estark> the missed bit above is that we'd really like to be able to implement a fallback to http when autoupgrading fails (for passive mixed content), so we need to investigate if that's feasible to implement

tanvi: I'd have to ask jkt for the details, but enough to get a lot of complaints for a no-opt-in test
... I'll find the bugs and send details to the list

johnwilander: great to hear there are experiments. I'll see what we can experiment with in Safari Preview
... we wrote a blog about breaking HSTS supercookies. we can perhaps use some of that mechanism.
... part of that technique assumes the ability to try loading http: images on https: pages, so an auto-upgrade
... would prevent the attack
... upgrading would prevent the "read" phase of the super-cookie. for all sites not just the ones we've identified as being problematic

tanvi: we have until now not worried about the privacy aspects of HSTS because we haven't seen attacks using it, and the upgrade benefits outweighed the risks. This could be changing now.

estark: does HPKP have a similar issue?

johnwilander: we don't support that so it's not a problem for us.

estark: one more thing, breaking the HSTS supercookie is only accomplished if you block with no fall-back. That's not our current plan because of too much breakage so we don't think our approach will help with the HSTS issue

johnwilander: With ITP we have on-device classification of domains we need to do something about, so we could upgrade and NOT fallback on sites we've identified as problematic

tanvi: from Firefox's perspective we'd like to avoid a fallback

estark: by fallback do you mean automatically re-try with http: or do you include the developers opt-out?

tanvi: we mean the auto-retry. we're interested in the developer opt-out

estark: if we don't have the auto-retry we're making it harder to move to https. It's one more step for sites to change something to avoid breakage.

tanvi: let's wait and see after some experimental results
... john, is safari thinking of testing the auto-upgrade for mixed content

johnwilander: we're very interested. sorry I missed the call last month. we'd very much like to take part
... there are several things in there. https adoptions, avoiding warning fatigue, etc. we believe in joint efforts
... Firefox is trying "passive mixed content auto-upgrade", correct?

tanvi: yes. I think Chrome is upgrading active as well

estark: we're trying several things. one auto upgrades active but we're also looking at just upgrading passive as well

johnwilander: do you think blocking mixed-passive instead of upgrading is better or worse than auto-upgrading, for https adoptions

estark: I think they're about equivalent. we'll need the developer opt-out in either case

<johnwilander> https://www.w3.org/TR/from-origin/

johnwilander: this is an old abandoned spec (2012)
... with spectre there's reason to believe sites might want to block cross-origin loads of their resources.
... sites can use referrer header but that's problematic and discouraged (sites can suppress the referrer)
... we're interested in reviving this proposal

<estark> johnwilander: have you seen https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md?

<estark> disclaimer: I have not really read it yet and it might or might not be relevant to what you're talking about

estark: I'd be happy to connect you with the people working on it who can talk more authoritatively than i can

dveditz: spectre does seem to be one of the threats mentioned in the explainer

<johnwilander> Thanks, all!

see you all next month

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: dveditz terri gmaone estark johnwilander tanvi
Regrets: wseltzer mkwst
No ScribeNick specified.  Guessing ScribeNick: dveditz
Inferring Scribes: dveditz
Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2018Mar/0004.html

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)