W3C

- DRAFT -

Web Application Security Working Group Teleconference

17 Jan 2018

Agenda

Attendees

Present
weiler, mkwst, wseltzer, dveditz, jyasskin, gmaone, PatrickKettner, bhill2, estark, ArturJanc, johnwilander, ckerschb__, jeffh
Regrets
Chair
mkwst, dveditz
Scribe
wseltzer, mkwst

Contents


<estark> is the access code not working?

Agenda Bashing

<mkwst> <crickets>

News

<wseltzer> mkwst: Mozilla's new way of looking at APIs: locking new APIs to secure contexts

<wseltzer> https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/

<mkwst> dveditz: We talked about deprecating HTTP in 2015.

<mkwst> ... This is more of a line in the sand.

<mkwst> ... Nudging things in that direction anyway, just a more formal statement of the state of affairs.

<mkwst> mkwst: Exception process?

<mkwst> dveditz: Right. Exceptions will need to go to dev-platform@ and convince Distinguished Engineers to accept their case.

<mkwst> ... Not terribly formal yet.

<mkwst> mkwst: I read something about explicitly labeling APIs/tests as requiring a non-secure context.

<mkwst> ... WebIDL bugs to that effect.

<mkwst> ... e.g. `[NonsecureContext]`

<mkwst> dveditz: It might be nice to make `[SecureContext]` the default, but it would require a lot of work. Don't see it happening soon.

CSP as exfiltration protection.

<inserted> scribenick: wseltzer

mkwst: pointed to some github issues; worried about thinking about CSP as exfiltration mitigation
... brittle and hard to deploy

<bhill2> +1, CSP is not confinement

mkwst: conversations on gh issues, prefetch

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

mkwst: FF already has distinct behavior around prefetch
... applies policy language from default-src to those requests
... conversation tending toward adding new directive, applying to prefetch and prerender
... what do folks think?

dveditz: prefetch should be covered by *something*
... not necessarily default-src
... e.g. preload as

mkwst: note preload allows an "as" attribute
... can push toward an element covered by policy
... if you don't specify an as, it's treated as fetch
... preload allows developer to explain to browser what it's preloading

ckerschb__: I don't think FF incorporates changes from as

mkwst: we should make tests cover what's in the spec

dveditz: and make prefetch as similar to preload as we can

mkwst: but prefetch has no mechanism for specifying type
... but I've heard difference explained as prefetch is "things user might navigate to"
... and so devs weren't excited to tie that to connect-src
... bug feedback suggests there's desire for some differences
... recommend that folks interested look at the gh issues and PR

dveditz: sounds as though there was some conversation about adding as to prefetch
... otherwise, using prefetch src sounds fine

mkwst: Other pre- things you can put into links, e.g. DNS
...
... preconnect and DNS pre-fetch "warm up" connection
... shouldn't have to list every origin you ever want to talk to
... Yoav's suggestion, allow them if any of the policy would allow

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

mkwst: please give feedback
... one more, webrtc
... conversation on the bug

<mkwst> https://github.com/w3c/webappsec-csp/issues/92

<mkwst> https://github.com/w3c/webappsec-csp/pull/287

mkwst: ^ not baked yet, but reasonable summary
... pls take a look

johnwilander: Another CSP thing

<inserted> scribenick: mkwst

johnwilander: Experimenting with a frozen user agent string.

<wseltzer> ... Frozen UA string in Safari tech preview

johnwilander: Goal is to remove it as a fingerprinting vector.
... CSP3 is not backwards compatible with CSP2.
... Which means the server needs to know on the initial request.
... Using UA sniffing.
... Perhaps a statement in the UA string regarding support for certain features?
... Perhaps servers could send multiple policies in one response?

<wseltzer> mkwst: can you elaborate on the problems?

johnwilander: Feedback on Twitter.
... I only got highlights.

dveditz: One thing that changed was 'strict-dynamic'.
... If you use it, you would also send `'unsafe-inline'`, which you might not want to send to CSP2 browser.
... Recommended solution is to send two policies. One with `'strict-dynamic' 'unsafe-inline'`, another with the list of sites you're going to use.
... That allows a graceful fallback.
... Perhaps add a note to the spec?

johnwilander: That sounds along the lines of our thoughts.
... Send multiple policies, browser picks one.

dveditz: Well, the browser enforces all. But one ends up being a no-op.
... If you knew, you could avoid sending too much data on the wire.

ArturJanc: Google tried very hard to make our policies work even if they're sent to an older user agent.
... But we still do UA sniffing.
... Not so much specification incompatibility, but browser bugs.
... I believe Safari has an issue with sending an enforce-mode and report-only policy together on a single response.
... Not a CSP3 issue, just a browser bug.
... It's hard to get things right. Chrome and Firefox have had similar issues.
... That's one reason freezing the UA string is a problem.
... Also, reports contain a lot of noise.
... Knowing which browsers have known issues allows us to filter that data more effectively.

johnwilander: As for bugs, they might be in any particular version of the browser. Might regress, etc.
... If the server needs to know that on the first request, we'd need versioning in the UA string.
... Which reintroduces the fingerprinting vector.
... Hard to reconcile.
... Might add something to the UA string which expresses overall support.

mkwst: Lots of features, developer feedback might bring lots of them into the UA string.

johnwilander: only those that the server needs on the first request.
... The rest would be feature-detected.

dveditz: If it's not `'strict-dynamic'`, we'd love to get details on what shifted.

johnwilander: `child-src`? Workers.

dveditz: Ah. Yes. That's a mess.

mkwst: Not sure it's 100% backwards incompatible. But it's 100% confusing.

johnwilander: Considered versioning the header?

<wseltzer> mkwst: if we're going to version the headers, I'd like to nuke it and start better

<wseltzer> ... I'd be reluctant to introduce new header versioning info if we don't really need to

Storage Access API

johnwilander: Sent out a proposal to public-webappsec.
... Currently a discussion on whatwg's HTML spec.

https://www.irccloud.com/pastebin/BgtqjYD9/

johnwilander: Introduces two methods on document.
... `hasStorageAccess()` which returns a `Promise<bool>` which tells you whether you have access to your first-party storage.
... `requestStorageAccess()` which allows you to ask for access to your first-party storage.
... `allow-storage-access-by-user-activation` sandbox token.
... We partition all kinds of user storage.
... This only addresses cookies right now, as that's the most recent change we've made.
... But for other vendors that block access to storage, this might be a reasonable opt-in policy.
... API could cover other kinds of storage if the vendor thought that was reasonable.

<wseltzer> mkwst: should this go to TAG design review?

johnwilander: Will consider that!
... We put it on `Document` because it affects `document.cookie`.
... Access is also scoped to the document. When the document dies, access dies.

mkwst: Are those baked into the API?

<wseltzer> mkwst: is that implicit in API, or vendor-variable?

johnwilander: If we hear from other vendors, that might be a reason to move it somewhere that implies a wider scope.
... We'll probably ship this as-is because we have developers that want the ability to do what this API does.
... Will deal with deprecation if standards folks decide it should be elsewhere.

<dveditz> https://w3c.github.io/permissions/

dveditz: Would it make sense to add this to permissions instead?
... Rather than a one-off?

johnwilander: I think the permissions part comes down to first-party vs third-party thing.
... This is scoped to a particular iframe.
... Not delegated to the third-party.
... Prompt would have to involve the third-party in some way.
... "Do I want to have my social media ID used on this site."

<wseltzer> mkwst: modeling as permission still gives flexibility

<wseltzer> ... permissions API doesn't bake in origin-based model

<wseltzer> johnwilander: Thought there was some language re only first party can prompt user

<wseltzer> mkwst: possibly

<wseltzer> jyasskin: sounds like a bug

<jeffh> or in the spec at all

<wseltzer> ... if you can point that out, I'd like to fix it

jyasskin: If you can point that language out to me, I'd like to fix it.

<wseltzer> mkwst: encourage you to discuss with TAG

johnwilander: Any other vendor interested in implementing?
... I believe we all have opt-in mechanisms for blocking storage.

<wseltzer> mkwst: want to continue the conversation. probably more interest in chromium than chrome

dveditz: We've wanted to ship blocking by default, this might be a reasonable path towards doing so.
... Couldn't do it before because of the kinds of things that break without third-party cookies.
... If we could block third-party cookies more broadly, that would be interesting.
... "Cautiously interested" in the concept.

<PatrickKettner> My mic appears to not be working, but Edge status would be similar to mozilla. interested, but no immediate plans

<PatrickKettner> I'd say youre welcome for the feedback, but see above issue

<PatrickKettner> cheers all

<wseltzer> [adjourned]

<jeffh> adios :)

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/01/17 17:56:28 $

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/Hi! Can't log in to W3 (as usual) and the meeting code I have is not valid.//
Succeeded: i/pointed to some github/scribenick: wseltzer
Succeeded: i/Experimenting with a frozen/scribenick: mkwst
Present: weiler mkwst wseltzer dveditz jyasskin gmaone PatrickKettner bhill2 estark ArturJanc johnwilander ckerschb__ jeffh
Found ScribeNick: wseltzer
Found ScribeNick: mkwst
Inferring Scribes: wseltzer, mkwst
Scribes: wseltzer, mkwst
ScribeNicks: wseltzer, mkwst
Agenda: https://lists.w3.org/Archives/Public/public-webappsec/2018Jan/0016.html
Found Date: 17 Jan 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]