<estark> is the access code not working?
<mkwst> <crickets>
<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.
<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
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 :)
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]