<tanvi> having trouble with access code
<tanvi> thank you! both the ones i had were wrong
<tanvi> *have to update my calender*
mkwst: agenda-bashing
mkwst: as of chrome 68, all HTTP pages will be marked "not secure"
<jkt> On irc only...
mkwst: estark is on the call if
you have questions
... helpful for others to be aware of
@@: jkt has implemented a couple prefs in firefox
scribe: to do similar things
mkwst: sounds great
... Next note, SRI and signatures
... plans for an origin trial in chrome 66
... let devs interested in experimenting with signaturs
start
... currently implemented basic signature mechanism from
explainer
... not the one jyasskin is proposing for HTTP
... trying to gather info for more informed decision
jyasskin: signature mechanism
implemented does not sign headers or request, just
content
... interested in feedback
mkwst: I believe your proposal signs all headers and URL
jyasskin: it mandates signing headers, gives choice as to URL
mkwst: we want deployer feedback
<jyasskin> The IETF proposal mandates signing the URL, allows the signer to choose the signed set of response headers, and does not support signing request headers.
mkwst: tradeoffs between ease of
deployment and security guarantees
... general agreement that it would be good to deprecate
appcache for non-secure contexts
... discussion over in WHATWG HTML
... think Moz has implemented, and I have on list for
chrome
... believe safari interested
patrick: From edge team, think we're aiming at edge 19 for deprecation
mkwst: any other news?
* `navigate-to`
* `webrtc-src`
* `'wasm-eval'`
andypaicu: navigate-to, new
directive in CSP aims to control navigation
... has source-list, if navigation initiated by document
doesn't match, will be blocked similar to form-action
<scribe> ... new keyword, unsafe allow redirects
UNKNOWN_SPEAKER: 302/301 until
you actually land on a page
... uses existing hooks
... PR against CSP spec
<mkwst> https://github.com/w3c/webappsec-csp/pull/290
UNKNOWN_SPEAKER: welcome
feedback
... if none, I'll push it to the spec
... after some time for review
mkwst: goal to raise awareness of
Andy's PR
... we've heard interest in experimenting, for ads, to reduce
possibility of navigating to places the user wouldn't
want
... we'd like to hear feedback about API contours
dveditz: is goal to cover any new content opened by page?
andypaicu: any navigation
intiated by page, including opening windows
... including window.open, but not another doc operating on
your frame
mkwst: interested folks, look at
https://github.com/w3c/webappsec-csp/pull/290
... some controversy as to whether HTTP is enough, not JS
... webrtc-src
<mkwst> https://github.com/w3c/webappsec-csp/pull/287
mkwst: mechanism to restrict webrtc and points to which you can connect
<scribe> ... new directive on top of connect-src
UNKNOWN_SPEAKER: limit what you can talk to via webrtc APIs
<mkwst> https://github.com/w3c/webappsec-csp/issues/92
UNKNOWN_SPEAKER: debate whether
that's necessary, or it should just be on/off
... hoping others will look at PR, issue 92
... give feedback as to what you'd like it to govern
... I'm happy to write that down
patrick: I'll have the skype team check it out
mkwst: great
<mkwst> https://github.com/w3c/webappsec-csp/pull/293
mkwst: wasm-eval
... some browser conversations
... folks implementing wasm unhappy with lack of granularity in
unsafe-eval
... shouldn't recommend turning on eval, but sometimes required
for wasm
... PR https://github.com/w3c/webappsec-csp/pull/293
defines a new keyword, wasm-eval
... APIs that compile strings or blobs into executable code,
without turning on eval generically
... interested folks please take a look at PR and its
conversations
... longer doc wasm folks put together @@ -- I'll look for
later
dveditz: please take a look, some complex issues
dydz: would be helpful if there
were a matrix of threats for each wasm operation
... to help us understand the threat model
<natasha> +1 editorial
<mkwst> https://github.com/WebAssembly/content-security-policy/issues/1 and https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md were what I was looking for.
mkwst: wasm has some limitations
that js doesn't
... some inputs need to be routed through the page or object
passed to wasm
... hope is that it's significantly more difficult to turn user
input into code execution
... which is what unsafe-eval is designed to mitigate
... talked to some, e.g. Dev from Dropbox, who's unhappy with
all or nothing
dydz: wasm has no capabilities unless you give them? is that correct?
mkwst: yes
dydz: then what's the threat model?
mkwst: I pasted in two links earlier
dydz: needs more description per operation
terri: Intel has an active wasm team, could fill out a table
dydz: e.g., a table showing what each operation can do, what concerns might be
mkwst:
https://github.com/WebAssembly/content-security-policy/issues/1"document
CSP threat model"
... is a good place to add that comment
... encourage us to look at these issues
terri: I think they'd be willing to work with us
dydz: I'll take it to github
mkwst: anything else CSP?
dveditz: Minutes approval
https://www.w3.org/2018/01/17-webappsec-minutes.html
mkwst: any objections?
[none]
mkwst: approved
mkwst: tanvi and emily?
tanvi: emily and chrome folks put
together Mixed Content level 2
... talked at TPAC, then a few of us met yesterday (JohnW,
Emily, FF)
... Mixed content UI warnings are confusing to users
... find ways to show less frequently
... HTTTPS adoption
... We all like idea of automatically upgrading passive
content, test that
... Moz would like to test loading passive content, stripping
metadata (cookies, referrers)
... Emily proposed upgrading active content, FF has had some
issues with timeouts there
... proposals floating around
... haven't discussed whether ther'es a fallback to
auto-upgrade
estark: anything we do to passive
mixed content would come with a developer opt-out
... so devs could say they don't want upgrade
mkwst: e.g. various search engines' image search
dveditz: or a government site as 3d pty access with no budget to upgrade
tanvi: other opinions?
estark: one of the proposals was
to start blocking passive MC
... treated like active
... backburner, doesn't sound as though that's anyone's plan
A
mkwst: if we could block passive
MC without breaking, we'd probably have done so already
... might be worth doing more measurement
<tanvi> summary of proposals 1) upgrade passive content (this looks like the most likely at the moment, firefox experimenting) 2) upgrade active content and passive content (chrome experimenting), 3) strip data from passive content (firefox experimenting), 4) block everything - passive and active. All come with a developer opt out
mkwst: as to what origins are
more likely to rely on mixed content
... e.g. we can fix Google
estark: in my mind, blocking is as likely to break as attempting to upgrade
mkwst: difference between upgrade
and breaking, gives a chance to be correct, but timeout
problems
... easier to just block
... but given amount of MC, it seems likely to break
<mkwst> https://www.chromestatus.com/metrics/feature/timeline/popularity/609
mkwst: `2.9% pageviews have some kind of MC
<mkwst> https://www.chromestatus.com/metrics/feature/timeline/popularity/614
mkwst: about 1.9% pageviews have mixed image content
<mkwst> https://www.chromestatus.com/metrics/feature/timeline/popularity/610
mkwst: often, it's ads
estark: so what users would notice if blocked seems smaller
mkwst: so I'd like more data about how widely distributed the problem is
estark: we can probably get more data
tanvi: data spike?
mkwst: see the note at the bottom
tanvi: should we discuss
fallback?
... we'd rather not have a fallback; try to upgrade, and if it
fails, it fails
mkwst: also my intuition
estark: worried that no fallback could be dealbreaker
mkwst: if fallback exists, doesn't solve one of the problems: what do we do in UI when we fall back?
estark: if we can drive down the frequency
@@: similar to font handling
scribe: CSS has recently added some new features relating to font-handling
mkwst: it would be possible to
implement fallbacks in user-land
... user could indicate
... we wanted to change defaults
tanvi: if we can find those most affected, dev opt out, then blocking all mixed passive content would be much easier
<jkt> Could a fallback add the risk of increasing mixed loads?
mkwst: metric should be how many pages does it cause user visible degradation
tanvi: there are studies where we can ask users to report breakage
estark: also start measuring some heuristics, e.g. small image sizes
mkwst: take this back to email
mkwst: [sorry, scribe missed
intro]
... chrome team decided it was causing developer angst, not
significantly helping, so removed
... John suggested we should reconsider
... 2 examples: analytics accidentally collecting password
data; and malicious tools deliberately gathering
... we'd talked about splitting the spec
... thoughts?
dydz: I'd defer to John
mkwst: interested in more feedback online
[adjourned]
trackbot, end meeting
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) Succeeded: s/M/MC/ Default Present: gmaone, terri, estark, mkwst, tanvi, Daniel, Bates, dveditz, weiler, ArturJanc, jyasskin, jkt, andypaicu Present: gmaone terri estark mkwst tanvi Daniel Bates dveditz weiler ArturJanc jyasskin jkt andypaicu No ScribeNick specified. Guessing ScribeNick: wseltzer Inferring Scribes: wseltzer Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2018Feb/0013.html Found Date: 21 Feb 2018 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.)[End of scribe.perl diagnostic output]