W3C

- DRAFT -

Web Application Security Working Group Teleconference

21 Feb 2018

Agenda

Attendees

Present
gmaone, terri, estark, mkwst, tanvi, Daniel, Bates, dveditz, weiler, ArturJanc, jyasskin, jkt, andypaicu
Regrets
Chair
dveditz, mkwst
Scribe
wseltzer

Contents


<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

News

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?

CSP proposals

* `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

Minutes Approval

mkwst: any objections?

[none]

mkwst: approved

Mixed Content Level 2

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

Credential management

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

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/02/21 18:01:42 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]