See also: IRC log
<wseltzer> trackbot, start meeting
<trackbot> Date: 28 October 2015
<wseltzer> Meeting: Web Application Security Working Group F2F, Day 1 (TPAC)
<scribe> Meeting: WebAppSec F2F, TPAC 2015, 29-Oct-2015
<scribe> Agenda: https://docs.google.com/document/d/1h05daW54OA3-lqV2IbPA0otrQbkB9Ua8UXTj9Tm63Dg/edit#
<dveditz> scribe: JeffH
<bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-10-19-webappsec-minutes.html
<bhill2> minutes unanimously approved
WebAppSec WG Update preso by bhill2
<jungkees> https://www.irccloud.com/pastebin/YTSsB2Vl/
<jungkees> Can we add it to the secure context agenda?
<wseltzer> Brad's WebAppSec TPAC2015 update slides
<wseltzer> ^Brad's slides
[ Slide: 3 - Broad Themes ]
[ Slide: 6 - Subresource Integrity (SRI) ]
[ Slide: 7 - Referrer Policy ]
[ Slide: 9 - Upgrade Insecure Requests ]
[ Slide: 10 - User Interface Security ]
[ Slide: 11 - Credential Management Level 1 ]
bhill2: questions?
?: asks about diff btwn "creds mgmt" spec and the work in "creds CG"
bhill2: the latter is about "creds" like driver licenses, not username/pswds which is what creds mgmt spec is about
mkwst: creds mgmt api is extensible and we are working to take into account the creds CG's use cases
<npdoty> Brad's WebAppSec TPAC2015 update slides (world-readable link, per bhill)
mkwst: have secveral specs trying to give websites better functionality to ease migtation to https, eg upgrade insecure requests
<Zakim> npdoty, you wanted to ask about clear-site-data or private browsing
npdoty: curious about clear-site-data
<bhill2> ED: Clear Site Data
mkwst: there is a spec, have
someone impl'g this qtr, will have impl early nxt yr. spec has
been stable.
... some discussion re private browsing mode -- eg webapp
policy to only be loaded in incognito mode -- need to restart
that discussion
francois: wrt private browsing mode aka icognito, went to women's shelter for use case, they didn't think would make sense to require all users of their webapp to use incognito mode
?: they are thinking that having some sort of way for user to "clear all website data" for given site/webapp is better way to go -- mkwst: please chat with Tara et al
<Zakim> deiu, you wanted to ask about error codes (API) when mixed content load errors are triggered
bhill2: webapp is authoritative for its data, but users' browsing history the user is authoratative for it, so would require some sort of user interaction
andrei: is there any kind of api or way to get to the error when a mixed content req fails -- i as dvlpr don't get the info easily, but especially annoying for users, and no
easy way for the webapp devlpr to display meaning ful into to user
mkwst: there's ways to do that now eg leveraging CSP, TimBL was asking last night about a diff status code that comes back on XHR -- but there's limits such as if it is a redirect can't give the webapp access to the target of the redirct -- doing some thing like a status code or firing a mixedcontent event, pls file bug on the spec and make suggestions
dveditz: folks often don't have onError on everything...
mkwst: there's a variety of ways to give developers the info they desire/need
rbarnes: leery of giving folks "timing" apis for priv concerns
mkwst: if u have specific concerns pls talk to web perf folks (they ahve timing apis...)
rbarnes: just want to make sure that if we add anything we do it carefully
<npdoty> I think francois's point was that a more valuable mechanism would be clearing recent history for all sites (so as to remove the search engine results page before you clicked on the particular site, for example) as opposed to private browsing mode for that whole origin, so it would be more like a prompt for browser ui for clearing local history
bhill2: look at what info you get from CSP "default-src: https" -- think about the developer senario cuz it is diff w/XHR.
dveditz: hmm might be other ways to do it...mkwest: pls file bug
keiji: saw something about fido mentioned -- new web authn wg proposed -- what rel will have with cred mgmt api ?
dveditz: cred mgmt api here is extensible and hopefully the web authn wg can use it as basis for its work
mkwest: we want to think about creds sourced by say oauth, and perhaps that gives the creds CG what they need because they are somewhat similar
bihill2: we can discuss this later today
?: pretty much ready to go to CR, have some minor issues to address
need to do a bit more work on test harness
bhill2: we can go to CR with what we have
dveditz: issues are spread across 2 diff repos, we need to move issues?
?: pref would be to move issues
<dveditz> SRI: needs integration with whatwg/html issue-486
dveditz: issues of note
<dveditz> reconcile/cross reference CSP and SRI hash behaviors issue-363
<dveditz> Review the stability of all referenced documents issue-3
<dveditz> Convert to Bikeshed issue-12
?: #486 - planning to do that one, but is in a diff spec so not blocking us
francois: #363: needs more discussion -- bhill had good response to consider
bhill2: devdatta has been asking
questions about this also -- do we need to add explainer text
for the current specs SRI and CSP?
... goals and thread models explained well in each sep spec --
not sure is worth it
mkwst: would be useful to ahve a general explainer doc on how to use the suite of webappsec specs to construct a secure site -- -take this in consideration in CSP3 -- don't want to add to CSP2 which is almost done
ndoty: would be valuable to do overall explanation -- webplatform.org might be place to do some of this
<npdoty> https://www.webplatform.org/
<npdoty> npdoty: +1 to the goal, doesn't and shouldn't be in the specification which has a very different audience
bhill2: better dvlpr doc would be
a good thing, but getting folks signed up to do this work
difficult, but thinks we can close this #363 in terms of its
relation to SRI and CSP2
... <does some changes to issues #363 to reflect
this>
dveditz: the other issue is secretarial -- so will send the transition message for SRI next week
bhill2: We have an implementation report for CSP level 2
<npdoty> Implementation Report for Content Security Policy Level 2
bhill2: have 3 or 4 hundred tests for CSP2 but not everything is covered yet, so could use help in writing test cases
see report linked above to see ones that need to be added
overall status on CSP2 tests in chrome and FF -- see rpt above -- both browsers have CSP2 aspects still to implement
bhill2: would prefer to go to Prop Rec having solid impls and test suite coverage
francois: we will try to do that with SRI also
bhil2: to go to rec need all normative refs at same matiurity level -- there's ways to finess this -- but really want to have assurance of solid normative text when going to PR thus need test suite and impls to be solid
[ BREAK TIME till 1030h local time ]
<dveditz> scribe: dveditz
bhill2: our calls have moved from "covering recent topics" to a rotation featuring a group of specs each meeting, rotating through the many specs we have over several weeks
mkwst: "Secure Contexts" is pretty close to done, a couple of topics worth discussing
<bhill2> Secure Contexts
mkwst: a "Secure Context" needs
to be delivered securely, e.g. over TLS (with some exceptions
such as local file:///, loopbacks etc are considered
secure)
... diagrams showing how different contexts work with each
other
... we saw some "abuse" where inner secure frames fed data back
to insecure frames
... Example 2 (in spec): is a TLS popup from an insecure page a
secure context?
... yes, seems only tangentially related. we see this in the
case of navigations for example.
... would be strange to consider a secure page as not a secure
context because it came from an insecure page.
... however, there's a chance for leakage
... also one could have a handle (window.open/ opener) and can
postMessage() each other
... there can be complicated situations. Talked a little with
Travis from microsoft. he's concerned with this use-case
... we might want to consider a popup as a tainted context
rbarnes: we might want to do what we do with workers, just break the connection. Don't let the insecure context have a handle to the secure one
mkwst: we have a referrer
relation. the page can say "rel=noreferrer" and if we do that
there's no leakage. We can consider it secure in that
case
... I've opened an issue with annevk to create a rel=noopener
because sometimes you _do_ want the referrer and really were
just using it for the noopener side-effect
annevk: That's what makes it
auxiliary, and if you break that then it's no longer an
auxiliary context. No tainting
... are we limiting broadcast channel?
mkwst: there's still a variety of
side-channels (message events, etc)
... trying to make it more difficult to do the kind of shim
Netflix has done. I don't think they would use a popup in this
way
... what Travis didn't like was that this would be difficult to
implement in edge
... he would like it so that if two things are same origin they
have to have the same security context
... we remove window.opener. can null out window returned from
window.open(). can still get a handle by naming it and then
window.open() to the same name. once you have a reference
there's a variety of ways to communicate
... I don't think Chrome has iplemented broadcastMessage() like
Firefox, but even without that there are storage change events
and others
yoav: why would localStorage be hard? couldn't they pass the data by stuffing the answers in localStorage?
<npdoty> what is the threat that we're trying to prevent against? a network attacker modifies an HTTP page, and opens an HTTPS page, and the HTTPS page collaborates with the network attacker?
rbarnes: because they'd have to do so from a popup and we think they wouldn't want the annoyance of a popup
<bhill2> ack
<bhill2> ack document.domain?
jyasskin: do you want to bring up the document.domain question? Do you want to block access from a secure context?
mkwst: yeah, I'd be happy to do that. we already restrict a number of things from secure contexts in chrome
annevk: but secure contexts are not opt in, how would you do that without breaking old sites?
mkwst: I'd do it the other way, touching document.domain turns off the secure context, possibly breaking access to objects the context already has references to
jyasskin or if you do something that requires a secure context (e.g register a service worker) then it turns off document.domain
mkwst: question came up wrt service workers, should things that are not usable securely be invisible, or should they throw?
<Zakim> npdoty, you wanted to understand the threat of the network attacker
npdoty: I'm trying to understand
the threat model here in the embedded iframe
... if something is delivered over http with a link to https,
that's a secure context. It may not be the one intended by the
original author, but it's still secure
... users can't see the origin of a frame, but they can in the
case of a popup
bhill2: I see the threat model
here as asking for permission, if the user sees one thing in
the urlbar and the iframe is a different origin
... everywhere else the context is authoritative for its
origin, it's allowed to leak data if it wants to
rbarnes: if we say feature X is only available to secure contexts then an attacker can frame a secure page and use postMessage to get access to that feature
npdoty: are you worried that the framed site is collaborating with the attacker? you can always collaborate
mkwst: it may not be intentional collaboration, it's just a feature that was found and used in that way
bhill2: we're still not enforcing confinement here. we're stopping an obvious and convenient bypass but there are still other ways available
mkwst: I agree, it's not complete
isolation
... I don't think it's necessary. It would be wonderful to do
that and I'd like to but not sure we can. this seems reasonable
to not break things on the web too much while giving developers
tools to do their jobs
... popups get in the user's face, less likely that it would be
abused.
... what owuld you like to see in the doc (or anywhere) to make
that a reasonable claim to make
<npdoty> I think the unintentional collaboration point is important; if we think it's likely to create a danger where a site will typically make it easy for network attackers to access, that makes sense
<npdoty> +1 "attractive nuisance"
bhill2: sounds like there's not a particular threat model, we're closing down an attractive nuisance
mkwst: we're closing down a practical way to abuse this we've seen in the wild
jyasskin: if someone can find an
iframe that can do what they need then they've won, while with
a popup they can't
... but if the popup is invisible then they still win
mkwst: chrome has put a lot of
work into stopping popunders and other invisible popups. We
dont think there should be invisible popups
... and if there are any it's a bug
... forcing https is less a concern than making sure particular
APIs are not available to things that were delivered
insecurely
bhill2: we should touch on this
again in the context of COWL tomorrow
... can we define this as a kind of restriction? keep this in
mind for tomorrow
mkwst: doc has a section on threat modesl and risks. look it through and see if you can make it better
npdoty: while we're on that
note... should we consider other threat models or say
explicitly we're not considering one.
... part of what we're doing with a network attacker model is
that if users are ask for a permission they can be reasonably
sure which origin is requesting it.
... but there hasn't been a lot of adoption of CSP, so it's
either the obvious origin or it's someone who found an XSS bug
in that origin
rbarnes: or any 3rd party legitimately included by the origin
bhill2: if you have a correct application this helps prevent exploitation; if you have an incorrect application well....
npdoty: discussed this week -- the presence of a CSP that denies inline script is indicator of secure context.
mkwst: but an attacker can inject that CSP after doing its attack
npdoty: it might be valuable to include a clause saying there are other kinds of attacks and that this is not a complete silver bullet
bhill2: we can't make the claim
"this app cannot be exploited"
... not sure it provides much to make the opposite
assertion
<inserted> scribe: bhill2
dveditz: if we assume invisible / popunder windows are impossible, should we specify somewhere that this should not happen?
mkwst: joachim is working on this
and I would love for him to better specify this, e.g. how user
gestures are tracked and consumed in chrome
... would be good to document, but practically speaking we
haven't had time, there are many and it is difficult
... send jochen an email and ask
dveditz: would that be something that would be in this group or in HTML?
mkwst: there is some term in html that has a couple of points but is fairly sparsely defined. expanding on it to be useful for this would be some work
<inserted> scribe: dveditz
mkwst: there's a couple more things that I've worked with annevk on, such as what flags to add to fetch and so on
<JeffH> -> https://github.com/w3c/webappsec-secure-contexts/issues/5 "<iframe sandbox srcdoc='foo'> on a secure page should be secure" issue-5
mkwst: issue number 5: boris
seemed to agree (in a long comment) "but you need a lot of
tests"
... we need to figure out how to advance the spec even though
it concerns things that are not in the version o HTML defined
by the w3c
... I asked web-apps and they pointed at an HTML 5.1 doc that
contains a bunch of things, I'm not convinced that's any more
stable and I'd prefer continuing to reference the WHATWG
specification.
wseltzer: I should speak up on
the normative reference policy -- it is something we'll ahve to
address in the w3c generally
... as more things are produced referencing more outside
things. we are not saying everything has to be done in w3c so
lets find a way to describe when
... things developed elsewhere are sufficiently stable and
develped sufficiently openly to serve as a reference.
... maybe we can chase down some directors while we're here
mkwst: there are some things
still open at this point but they are details. the general
structure and outline seems complete
... the TAG was happy with it last time they looked, @@ was
happy with it. matter of weeks not months to wrap it up
... dveditz filed a bug on the relation between mixed content
and secure contexts
<bhill2> ED: Mixed Content
mkwst: mixed content defines how
content can be loaded into a page delivered over TLS
... secure context defines when content can be loaded into a
secure context
... MIX used to talk about "potential secure origins" -- I've
changed it to URLs and authenticated
... in MIX we can tell by the URL form itself.
"unauthenticated" response is something we can tell based ont
he actual response (deprecated security, or none)
... a question to dveditz: have you had a chance to review the
changes to the document
<bhill2> dveditz: have not had a chance to do more than skim what you said but it seems you made the distinction so the terms are no longer confusingly similar
<bhill2> ... I raised this in behalf of others at mozilla, have to make sure this addresses their concerns as well
<bhill2> mkwst: the reason there is a distinction is that the secure context spec is not only concerned with TLS but also accepts things like file, localhost, 127.0.0.1, etc.
mkwst: the reason there's a
distinction is that secure context is concerned with not only
TLS but things like file:// or loopback
... and we need to define the behaviors for those that are
different from those for mixed content blocking
... other than that I think the mixed content is done. maybe we
have to go back to CR because I changed the definition
... I don't think they are substantive changes, but mayne
someone else will. can we slip this by the director?
... the other issue is whether we want some kind of error
reporting based on mixed content (raised in the session
yesterday)
... now that annevk is here: TBL and others said it would be
nice to know when failures were due to mixed content blocking
as opposed to other kinds of network errors. what's your
opinion on that?
annevk: is it actually a good idea?
mkwst: I think it's reasonable to give developers some idea when things are broken because of something they're doing wrong so they can fix it
annevk: historically we avoid saying much when we block things for security reasons. so mixed content in an iframe -- would we show a different error page?
mkwst: if it's stuff outside your
context then no, but if it's stuff loaded in your own context
and it fails it would help to know about it
... xhr, fetch, javascript
annevk: I think we've gotten by without this for a long time
mkwst: in the recent past we've gotten more strict about mixed content blocking (like xhr). we'd like more people to migrate and giving them better errors might help
annevk: I'm still not convinced
mkwst: things that redirect are a problematic case -- you can't just tell by inspecting your own origin
annevk: if it's just tim I'm still not convinced. it's added complexity.
bhill2: what does this give us
that csp errors don't? are we going to respond right there, or
is it for debugging later?
... if it's debugging then reporting seems good enough
annevk: does CSP report on this?
mkwst: if you set up your CSP to
block mixed content then yes
... tim's concern was associated with doing an xhr, having it
fail, and wanting to do something else whether it's an offline
failure vs mixed content.
rbarnes: I'm baffled, what would you do differently?
mkwst: I'm giving you all the information I know about the use case
<rbarnes> pleased for my bafflement to be immortalized in the minutes
wseltzer: maybe it's a job for the TAG
mnot: I have to be somewhere....
annevk: if it's just the offline thing you can check navigator.online
bhill2: we can have a rule, we have to have two independent requests for a feature
<annevk> navigator.onLine
mkwst: if we can show other ways to do it I think that's sufficient
wseltzer: in all seriousness it could be helpful for the TAG to describe how things could be done securely using new features the director might not know about
npdoty: if we had better docs on webplatform.org then _any_ developer could find out
mkwst: brief context Yan broke the internet, you can do timing attacks using CSP and HSTS.
<npdoty> I hadn't realized the Firefox behavior was intentional, that's good to know
<bhill2> HSTS, mixed content, and priming
<annevk> (FWIW, CORS preflights are cached too)
rbarnes: new topic "hsts
priming", priming the state like cache priming.
... because browsers learn about HSTS through headers behavior
depends on whether a browser had already visited that domain or
not
... proposal: if you have a non-https request that would be
blocked by mixed content, but which HSTS would fix, then do a
lookup (innocuous) to see if the site has HSTS.
... either the site doesn't and the request gets blocked
anyway, or it does and you can safely upgrade it
yoav: is the mixed content
request going out, or blocking the response coming back
in?
... if it's images you still send the insecure request and then
degrade the state
<annevk> mkwst: how does mixed content deal with redirects? Is an <img> fetched as http: that redirects to https: still mixed content?
<mkwst> annevk: Yes.
<mkwst> annevk: Because the redirect is non-confidential, and can't guarantee integrity.
<annevk> mkwst: and https: to http: still renders?
<mkwst> annevk: images render. they simply flag the page as being insecure.
<mkwst> annevk: in both cases you describe, the result would be mixed content.
rbarnes: you can cache "no HSTS"
for a shorter time, such as the lifetime of the document
... we do need to change the order of fetch because mixed
content blocking happens before the HSTS upgrade happens
mkwst: is this worth doing? what
I heard from you was that this affects 1% of all potentially
blocked mixed content in Firefox.
... at what level is it worth doing the work
mnot: not sure that's the right metric. if this helps people switch to https then it's a good thing
<npdoty> I think mnot is saying that it could be a larger percentage, when you consider sites that haven't upgraded to https *because* they saw mixed content failures, but would
rbarnes: the stuff that would be fixed is 0.02% of request, so it's small, but for future sites converting this would help
<bhill2> dveditz: there are two issues: changing the order of rewriting/blocking would help a lot of people
<bhill2> mkwst: but we need to do this priming to be able to do this or we have non-deterministic behavior
mkwst: we need to do priming before switching order to remove indeterminism.
<bhill2> ... and developers will have visited all of the sites they depend on so things will appear to work, but will be broken for users on first visit
mkwst: devs will have visited all the sites, so the page will work for them. users will have a broken site because they will have blocked content
bhill2: where would this live, a modification to fetch?
annevk: we could do it that way. we have a secrion on preflights, we could have a section on this
JeffH: I would expect the priming to be added to the IETF rfc XXXX because if you do this that spec is no longer stand-alone
mkwst: as far as I know no
browser implements 12.4 "Disallow Mixed Security Context Loads"
in the hsts spec
... fetch spec doesn't define how pinning is going to work
rbarnes: the hsts spec defines how you get the hsts information, store it, and use it
annevk: what mkwst means is that there is an upgrade step but there's nothing in fetch that says "handle the response to see if there's hsts"
yoav: would be nice if priming could be async
annevk/rbarnes: you have to block the request
yoav: I want to be able to send these priming requests ahead of time
mkwst: ...as part of the preload phase
JeffH: I should chat with you guys. I'm still concerned about references that should appear in IETF HSTS
annevk: not mentioned here, but in the html spec there's a bit about the websocket requests and hsts
JeffH: we have folklore locked up
in our brain. we need to document this because we're not all
here forever
... a lot of times there are missing linkages
bhill2: adjourning for lunch, resuming at 1:15
<bhill2> scribenick: bhill2
jyasskin:
https://docs.google.com/document/d/1s1k7Xc3YDgbLXwcPdrYvG5ixxVVuGoYNhiZiw7rhiP8/edit
... some potentially interesting questions, if anyone is
interested, here to answer questions
francois: is access to bt restricted to secure origins?
jyasskin: yes
dveditz: does this also apply to USB
jyasskin: these are similar apis,
a bit different based on how devices are attached
... for nfc and usb, new protocols proposed that expose origin
to remote device but block all existing devices, but bluetooth
accepts as-is
... bluetooth also has a blacklist of dangerous services, which
is currently keyboards and mice and FIDO devices
mkwst: based on what?
jyasskin: based on the id of the
service
... no service worker access yet, can only talk when an active
tab, for nfc is "frontmost" tab, which is not well defined in
html spec yet
rbarnes: general concern here is overlap between this and other apis for granting access to hardware, e.g. getUserMedia and geolocation
jyasskin: only doing GATT subset
for now, cameras and most audio doesn't work over this
yet
... is likely that people will start doing audio over GATT,
just not yet. Geolocation is totally a thing. We want that to
be easier user experience than general bluetooth chooser.
... hopefully users interpret "pair" to mean "give full control
of", so the user will be aware of e.g. location functionality
in a device being implicitly granted
... how do we get the list of ids/services in the registry, but
there is an incentive to lie about devices not listed by their
authoritative creator
... this is by device class but for non-standard services is
more per-device; most device makers invent their own id, but
anyone can use them
<npdoty> yeah, it might be nice if we could detect when a bluetooth permission were actually a capability that matched another permission, like geolocation
https://developer.bluetooth.org/gatt/services/Pages/ServicesHome.aspx
<dveditz> bhill2: can bluetooth do things like usb where you plugin in a device and later it changes what it can do?
<dveditz> jyasskin: yes, they can
<npdoty> so that our privacy model is based on capabilities, rather than particular mechanisms
jyasskin: have to trust that
device doesn't change the services it exposes or claimed device
class after attaching
... treating that as OS level bugs that the web platform can't
do anything about
... two ways to trigger prompt: user gesture to show for nearby
devices
... 2nd way is related to physical web effort; a thing can
broadcast a URL and any nearby browser can see that
so could a malicious device advertise itself, connect, then change itself to a keyboard?
jyasskin: going to file a bug about that
dveditz: can a web page learn what devices you have without user knowing?
jyasskin: no, only those you've
paired, can't differentiate between not there and not
allowed
... pretty sure model is same for nfc / usb
... some push for telling document what state the permission
prompt was in when cancelled - either empty or denied
... is there a preference in this group to not do that?
<npdoty> what's the site use case that wants it?
dveditz: I would lean that way unless there's a good reason to do otherwise; it's just fingerprinting info without a compelling use case
jyasskin: come up from dev rel person, but no compelling use case yet. would be nice to respond to failures, but user has seen dialog so they know what they did
dveditz: could offer to "order one if you don't have one yet" if no devices present
annevk: how problematic is it for device to not know origin
jyasskin: very for some devices,
e.g. FIDO, which is why it's blacklisted
... most other devices are not concerned about restricting to
particular sources
... bluetooth group doesn't understand the concern / use case,
but any way to do this would be a new service
dveditz: can same device be paired with multiple origins at the same time?
jyasskin: yes
... blacklist is standardized across all browsers
<rbarnes> i confess that this bluetooth thing doesn't seem like a great security trade-off to me
<dveditz> ED: Credential Management Level 1
mkwst: API is getting stable and
we have feedback from credentials CG that it is generic enough
to accommodate extensions for their use cases
... I am sure there will be detailed questions that come up
with more implementations
... feedback is generally positive and developers like
interacting with the password manager in an imperative
fashion
... not happy with but can live with async form
submisssion
... less happy with necessity to do multipart form submission,
but that's a consequence of how fetch handles opaque
formdata
... if login systems are legacy may be hard to teach it to do
multipart form submission when it only understands urlencoded
form submission
... may be able to get around by transforming to url search
params
... but chrome doesn't implement that yet, curious if there is
a better mechanism
annevk: there are other good reasons to implement that API
mkwst: then that would be another
method hanging off the credential object, have to know that
they have different behaviors
... don't want to go back to first principles and re-evaluate,
but we have to do something
annevk: it's hard to serialize form data in other formats since it contains blobs
mkwst: if right thing is to implement the primitive that already exists
annevk: just firefox implements url search params at this point
mkwst: means we need to define an
opaque variant of url search params
... if a goal is layering on top of existing login systems,
probably makes sense to do this and document why to pick one or
the other
... probably need to do this and file a bug for it
... working about how we allow users to choose to always be
logged in
... experimenting but haven't landed any ui that we're totally
happy with yet
... api is done and you can play with it behind a flag
... some outstanding questions around metadata associated with
the credential, e.g. icon
... currently a URL, anne suggested might be better as a image
bitmap or blob
... maybe a good idea, doesn't give us responsive images
... at this point we need: more implementer feedback, more
developer feedback
annevk: what about issue 2: https://github.com/w3c/webappsec-credential-management/issues/2
mkwst: this (autocomplete) makes
sense for registration cases, e.g adding address info
... not sure it's right thing for autologin
... autocomplete solves some things, but takes away some other
good things.
... model in current spec prevents JS from accessing the
password, this makes it impossible to deny that
annevk: can we upgrade input type=password?
mkwst: that breaks other things
annevk: can we have an opt-in upgrade to a hardened model?
mkwst: proposed a write-only
attribute on form fields a while back, was no interest
expressed at the time
... if there _is_ interest, idea is to add an attribute that
denies read access
annevk: if we don't care about
protecting password fields in general, doesn't make sense to do
this
... seems it would protect against other scenarios
dveditz: how does making form fields opaque if xss can change the target of the form
mkwst: wanted this to be
origin-locked to prevent that, but now that we are doing fetch
integration, we have to rely on developer to do the right
thing
... we could add that
... seems like a layering violation for fetch to know about
this spec, but maybe opaque formdata objects always must submit
same-origin
... opaque fields draft tried to taint data so that mutating
form field type didn't allow an attack
annevk: but attacker could still inject a new, non-opaque field and convince user to type into that instead
mkwst: request autocomplete only deals with one side; allows you to get credentials out but not to store them
dveditz: assume we would restrict autocomplete to opaque fields...
mkwst: not clear it's valuable to
go this route if only solves helps the problem
... if we need imperative storage, why would we use a
completely different api to get that data back
... reason storage is important because password managers in
browsers are huge piles of terrible heuristics to judge
password fields and success
... miss things like XHR based logins or federations based on
redirects
... imperative mechanism allows site to request help from the
browser; this is the core of the value proposal from chrome
password manager
jeffh: higher level, extensible API also can be used in a more smooth and abstract fashion for plugging in stronger authentication
mkwst: yes, hoping that things like FIDO will use this
rbarnes: has any discussion been had about this with the fido folks?
jeffh: we are aware of this doc
yoav: to support the importance
of storing the credentials, have heard of use case where a site
is interested in managing login for users where user doesn't
know password
... interested in sending them a link, storing some random
password on the user's device and have the login work that
way
mkwst: I think storage (and sync)
is a critical feature
... most password managers have a mechanism to just create a
random password
... there is a bug, deferred, for this, we could re-open and
put it in
... but request autocomplete is probably a more reasonable way
to do this
... as you are probably trying to grab more than just a
credential, and and do this all in one request
... a question is whether to care about password complexity
rules at the remote endpoint
... if we need to support that, we need to specify how to
define those restrictions, which I don't want to do
yoav: how can you make sure that
password made it into the manager?
... does user have to agree?
mkwst: yes, of course user has to
agree, this is significantly more persistent than a cookie,
synced across devices, not cleared
... but user prompting is not in this spec because user agents
should do what is right for their users
... what we need are implementations by browsers and
developers, and developers are more important
... talked to some developers who are planning on using it once
it ships
rbarnes: no current plans to do a focused implementation effort but this is broadly a direction we are comfortable with, will send some questions re: federation cases
jeffh: we should make federated identity folks aware of this
mkwst: no feedback from microsoft or apple, opera is interested
axel: followed removal of send(),
not sure if I like the fetch integration, but easier to
implement
... not really that complicated, much of what's needed is
already there in firefox
... discussion about doing some strange crypto stuff to
password before sending it, where did this end?
mkwst: currently we don't do this and don't support the use case.. don't know anyone for whom this is essential
rbarnes: if you're going to do
some processing like this you're changing from an opaque object
to a thing with JS that executes in a secret context that can
access the data
... need to swap that paradigm, might make sense to change
entirely
axel: could install something trusted that can operate on the token and transform it, would fit with how tokenization in payments world works
<JeffH> url search params = https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams ?
mkwst: think the spec is already
too big, and without a concrete use case that maps to one of
the things the spec is trying to do
... will be hard to find time to implement if it's not
something chrome's password manager would do, so prefer not to
put it in spec
<mkwst> JeffH: https://url.spec.whatwg.org/#interface-urlsearchparams
keiji: is there any possibility to have public security review as a process, since this kind of feature is very attractive for attackers, xss is common
mkwst: would love for you to read
through mitigations in the spec and see if they make
sense
... this should be strictly more secure than status quo
... today password manager will just fill a form for you and
you can read the data out
... this is better than that
... have taken this to the TAG for review. they were supportive
of the general direction and api shape
rbarnes: separation between origin and non-origin bound credentials?
mkwst: you need to talk to
credentials CG
... I am skeptical about use cases but have made room for the
non-skeptics' use cases if they can produce them
... some sites will have both user/password or federated
login
... don't know how it will work to do that and other types in
the future
... what it does now is walk up the chain to find common
ancestor below base "credential"
... would like to get rid of that, not sure that I can
rbarnes: seems like a sensible
thing to do
... one thing that was good about webcrypto is it didn't design
any new cross-origin stuff
... origin binding is a good design principle in general
mkwst: agreed
... chrome implementation doesn't have it and doesn't suffer
for it
rbarnes: in a level 2 would be easy to collapse the two types if non-origin bound uses never emerge
mkwst: origin bound might be a
terrible name, could maybe "password manager type"
... picked origin bound as a not so subtle hint about what I
wanted to build
... only place it has any impact is if different kinds of
credentials are picked, do something sane, could hardcode that
instead
... tradeoff between extension points with well-defined
behavior vs. a more streamlined spec
... not entirely happy but does what I want it to do, would
rather not reopen the discussion
... things I find ugly have no practical impact so don't care
enough to remove them
francios: first class of ideas is
support for different types of resources beyond script /
style
... second class is applying it to downloads
<francois> https://github.com/w3c/webappsec/issues/497
mkwst: boris had some issues with the order of applying transfer-encoding
yoav: only know after file is downloaded
francois: we already have the same thing with safe browsing
bhill2: in safe browsing the protection applies regardless of source of link, if this protection is only based on link metadata, user can just paste url into address bar and then there is no protection
francois: there are always overrides even for safe browsing, if user is determined, can use another browser that doesn't implement
bhill2: so maybe is about security considerations suggesting clear warning to users about why download was blocked
annevk: what about encoding it into the link?
dveditz: we tried a long time ago and folks didn't like the idea of messing with urls that way, but yes, you lose the integrity data when copy/pasted
timeless: is there a scheme that just has integrity only?
bhill2: there is this, but we decided against using it: https://tools.ietf.org/html/rfc6920
<annevk> bhill2: so I think that RFC doesn't allow you to embed the address
<annevk> bhill2: the authority field doesn't really tell you where to find it over HTTP
annevk: there is the well-known syntax
<annevk> bhill2: but that's a mapping to HTTP, that doesn't work for legacy download locations?
francois: another type that has been discussed is images
annevk, yes, that's a big limitation
<annevk> quite
francois: progressive rendering
makes image integrity possibly unatttractive
... also lots of ways to express "images"
... progressive rendering might be a showstopper for many
people
yoav: what about video/audio?
annevk: you could use fetch api to get bytes for checking in a streaming-compatible manner
<francois> https://github.com/w3c/webappsec/issues/306
francois: another type is CSS-loaded subresources, if stylesheet loads things, they are not protected
annevk: tab made it so arguments can be reused in CSS in a backward compatible manner, but no usages of that are defined
mkwst: tab is here, we can hammer that out with him before everyone flies home
francois: one thing in v1 removed was iframes. a problem anne pointed out is that iframes can be navigated, need to define what that means if an integrity protected iframe is navigated somewhere else
annevk: maybe navigation should be disabled in such a case
mkwst: use case I was thinking of was advertising where 3rd parties are responsible for serving something, want to verify that document for which you have a hash should also have integrity information
annevk: we don't do that for css
<francois> https://github.com/w3c/webappsec/issues/210
mkwst: was thought of requiring integrity on all elements of a type in a document, but dropped, and wasn't yet a way to for that on embedded content
<francois> https://github.com/w3c/webappsec/issues/16
francois: next is CSP directive
to require integrity
... proposal is to use CSP to attach to a directive to require
integrity for all resources that directive applies to
annevk: an injection could still add integrity, need to be in the header
<francois> https://github.com/w3c/webappsec/issues/449
bhill2: could work in concert with a signature-based approach that included a public key in the header to avoid bloating the policy
francois: which is this issue....
bhill2: there are two forms of
this proposal: annotate each element with signatures (assumes
page knows content in advance) vs. give a key and get a
signature from the server in a header (allows dynamic
content)
... is concerned about what substantial advantage dynamically
signed content from a server provides over existing https
semantics
mkwst: could be signed offline, but client can't tell what it's doing
dveditz: +1
bhill2: one case that has come up with in CSP is DNS, locale-specific names (e.g. google.co.jp) which server-supplied signatures could help with
<francois> https://github.com/w3c/webappsec/issues/504
mnot: are you OK with inserting content originally delivered over http into a secure context from a sharedcache?
dveditz: I like this idea
mkwst: not clear what this gives
you- doesn't solve leakage problems
... no server side
mnot: you can probe with this
mkwst: and all our protections
are origin-based, and you can pretend that a resource is coming
from any origin
... how do we know if a script is cross-origin, if I should
have access to data?
annevk: is this any worse than existing http cache issues?
mkwst: if you are caching content and it is indexed by a hash, what is the origin and how do you know if you should have access or if it should be blocked by csp?
mnot: do you adopt headers of other representation?
dveditz: script mostly doesn't care
bhill2: worker might be delivered with CSP policy
mkwst: might be useful go back to concerns documented in original spec
dveditz: if we expand to iframe, headers become much more of an issue
mkwst: can go back in time on spec to security considerations before the features were removed, and also on mailing list
<francois> https://github.com/w3c/webappsec-subresource-integrity/issues/11
<francois> is the sha3 bug
<inserted> scribe: dveditz
mkwst: csp2 is basically
done
... a couple things left to land in firefox, brad has a great
testsuite ... on track
<JeffH> CSP lvl 3 link?
mkwst: CSP 3 is a complete
rewrite of CSP2 in terms of HTML and fetch. csp2 was a little
handwavy about how things worked, I hope csp3 is clearer
... spec section 4 Integrations: describes how fetch integrates
into csp
<JeffH> Content Security Policy Level 3
mkwst: csp2 written in terms of
requests -- pre service workers. csp3 written in terms of fetch
to cope with service workers
... requests go out, through CSP. service workers can muck with
it, and then the response comes back through CSP
... service worker can have its own CSP
... in the future service workers can ctalk to service
workers
... Integration with fetch also does the policy parsing and
puts the policy on a response object
... this was vague in csp 2, I hope it's better explained
now
... (response has a csp list, we parse the policy, we do
something useful with it)
... 2 hooks: should request be allowed, should response be
allowed (top and bottom of fetch respectively)
... Integration with html -- all the places we have to touch to
make CSP sensible.
... such as inline scripts. I've given annevk patches for some
of these, some are still outstanding
... I hope this all makes the mechanics of csp significantly
more clear than they were
... would be great for folks interested in the details to read
this through and tell me if it makes sense or not
... number of policies that affect the document that have
nothing to do with fetch (e.g baseURI) and those are described
in here too
... It's nowhere near done, but done enough to start getting
feedback
... Current state is "parity with CSP 2". Two new behaviors in
here, but basically nothing different just making things that
were implicit explicit
... one change: no longer possible to lock yourself into an
insecure scheme. "http:" means "http" and "https".
... and 'self' includes websockets (ws/wss)
... the frame-src directive, deprecated in CSP 2, has been
removed. I'm not sure that's a good idea
... One of the big changes is I'd like to throw away all the
report functionality here. Seemed like a great idea, assuming
violations didn't happen often
... but that was insanely optimistic
<schuki> servicewor
mkwst: we'd like to have a single
place where reporting is defined for all kinds of things (CSP,
backoff, cert pinning)
... "Not Just Error Reporting" -- will have a new name
eventually
<inserted> Not Just Error Reporting -- will have a new name eventually
mkwst: https://mikewest.github.io/error-reporting/
... this should simplify CSP, just define the contents of the
report and let this new spec define the mechanism
... so I'd like to remove report-uri. Folks at Google have some
things they'd like to see in reports so I'd like to revisit
these
... most of the things we strip from reports are actually
obtainable from javascript, so people are using alternative
reporting. that's showing brokenness
... other than that the doc is essentially CSP2
... some of the new things we want to do are in _new_
documents
... For example, cookie scoping, something mnot wanted
... http://w3c.github.io/webappsec-csp/cookies/
... I think it makes sense to define new things in new
documents, a single feature set that can be defined and
reasoned about and adopted stand-alone
... I'd like to experiment with drafting all new features this
way. maybe some will move back into the monolithic doc
... you'll see in the CSP3 TOC i've divided the features into
"fetch directives", "grabbag", and reporting directives
<JeffH> what was that other csp spec wrt cookie that we perused ?
JeffH: http://w3c.github.io/webappsec-csp/cookies/
... not clear any of the grabbag justify a separate document,
but I'd like to think about it
... I think making the spec more modular will [improve
eveyone's lives]
... if we can make smaller chunks maybe people will be more
likely to implement some of them even though they can't take on
the whole thing.
... small focused documents are nice, and support "checkbox
oriented development"
... cookies is separate, csp pinning is separate,
... where are those?
mkwst: those are subdirectories of webappsec-csp
timeless: is there a link section in the document to those other documents
mkwst: not currently
... I talked to these lovely gentlement about setting up a
registry for directives at the IETF so that's in progress
[refrencing Barry and mnot]
<mnot> Content Security Policy Directive Registry (IETF Draft, in last call)
scribe: that means the spec will
have an IANA Considerations section, and new specs will have
bits that say "register this new directive over there"
... feedback wanted on the module concept
francois: you said "... if only people would implement nonces and hashes..." have you thought about making CSP3 into CSP1+nonces and hashes
mkwst: maybe? I've told people
those are important but I don't know that this will help?
... these are already in CSP2 so
JeffH: is the intent to leapfrog CSP2?
mkwst: I'm done with csp2 now ... I'm doing this now
bhill2: I hope CSP2 will go to rec, there's not a lot more left to do
mkwst: the testsuite is important, but that's the only part I'm interested in the process of finalizing. As part of Google of course the patent protection is impt, and some people wait for recommendation before implementing so that would be good too
francois: if CSP3 is just CSP2 rewritten then people who implement CSP 2 can also claim CSP3?
mkwst: there's some additional
stuff in there, but sure
... I'm fine with publishing "CSP 2 with better explanations of
the mechanism and better reporting". sure
... I don't want to work on another monolith that will take 5
years to complete
Kepeng: during the break we talked about @@
mkwst: I don't see an issue off the top so maybe we didn't file one. we should do that
<mkwst> https://github.com/w3c/webappsec-csp/issues/new
mkwst: thread starting August 27th "CSP 401 issue"
bhill2: I have a question about
policy combination. has come up in the past
... in modular specs you can have
... we should require modular specs to define an intersection
mechanic
mkwst: whatever directive we
define will set state somewhere, and would have to define that.
and whenever we see a policy we call that algorithm for that
directive
... the policy per directive could be 'ignore those after the
first', some way to combine them, some way to pick the
strictest.
bhill2: what's the semantics of reporting in the new spec?
mkwst: the report applies to the
policy. a violation in a policy goes to the reporting URL
related to that policy
... it would be helpful if this document defined the
considerations that modular CSP specs need to define to be part
of it
... the IANA registration has some of that already
... so what do you think of francois's idea of stripping out
everything unimportant and publish what we can quickly?
<Kepeng> https://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0047.html
mkwst: I will take an action to strip out things from CSP 2 that isn't implemented in other browsers, keep reporting, and then other things can be left to other specs layered on top
Kepeng: what about navigations?
mkwst: I'm skeptical of specs
that block navigations. I've written specs that do that, but
we've seen that when there are ways to stop people from
navigating people use that maliciously
... I worry about things that break interactions for
users
... this would be less bad because users can just open another
tab
... we can talk about it. I'm skeptical but I'm open to use
cases that would be compelling
<Kepeng> https://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0021.html
mkwst: file a bug on github, disuss it there too. all in one place, nice and focused
Kepeng: what about this issue https://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0021.html
mkwst: mostly taken care of in
the current draft
... child-src used to govern opening a new window on an origin,
but we removed it
... I know doubleclick wants this, because they want to
restrict where a popup add can do
... maybe worth considering because there are uses, but it
won't be in child-src
... "csp-embedded-enforcement" -- most directives don't cascade
into frames. would be dangerous in fact
... but if there's cooperation between embeddor and embedee we
could allow it. outer says "only embed this if it complies with
this policy" and then we only load children that match that
policy.
... so cascades, but the potential "victim" site has to opt-in.
Kind of an inverse-CORS
... Current definition in this doc is simple -- we send a
request header and expect the response to match exactly
... originally I tried to be clever and use a "subsumes"
policy, but that was difficult to calculate. maybe simplistic
will work.
... Not currently part of the charter, but I'd like to bring it
to the group.
[general mutterings of interest]
scribe: I'm hopeful this will be
helpful in toning down some of the bad behaviors we see in ad
networks
... any other questions or comments?
<bhill2> dveditz: what are you planning to remove?
<bhill2> mkwst: base-uri, plugin-types, form-action, maybe frame-ancestors
dveditz: what are you proposing to strip from what's in CSP2 as a "core CSP3"?
mkwst: baseuri, form action,
frame-ancestors?
... maybe not much we can throw out, now angry people haven't
imeplemented it
... I'd be happy with "CSP3 Core" that is a "better explained
CSP2" with improved reporting
<bhill2> http://w3c.github.io/webappsec-csp/api/
mkwst: This allows a page to
programmatically add a new policy to a document. Doesn't remove
anything
... people today are creating and applyting <meta> tags
on the fly. This is a less insane equivalent
yoav: with <meta> you know
that things above it won't be covered and things below
will
... and now it will be racy
bhill2: but people are effectively already doing this
?
yoav: as long as it's totally clear that there is a race if you do this
http://w3c.github.io/webappsec-csp/pinning/
mkwst: idea of pinning is to
apply CSP to an origin, even to documents that don't have a
CSP
... Google has been caught by this, for instance on error pages
because they're generated by a separate system
... there are a number of models we could use. pinning,
manifests, policy-uri
... we could revisit because there's better systems for
reducing latency
... they kind of solve different problems
... pinning could specify a "default" -- applied everywhere and
pages can layer on top.
... or pinning could be a fallback, only applied to pages that
don't have a CSP
bhill2: I want this, but only the fallback form
mkwst: Google would want
fallback, too
... youtube wants to move to a single monolith page, but
doesn't want to define a single CSP that would cover all
possible resources it might want to load
... could we have mutable policies
rbarnes: the danger is "surprise", if something changes out from under a dev
bhill2: I want the fallback to be very restrictive. if you didn't specify a policy you're in jail, and you can get out by specifying a policy
rbarnes: I worry people will approach this like CSS, adding just one thing
timeless: having things break right away is good -- then people can fix it
mnot: this is an origin-wide policy, right? couldn't have a different one for different parts of a site
mkwst: correct
mnot: the thing I'm thinking
about would layer on top of this
... somewhat orthogonal to what you're doing here
rbarnes: I would be inclined to simplify. rather than have both just do the one brad likes (fallback)
mkwst: at some point I'll get
time to go back and rework this
... if anyone would like to do any of this I would be
happy
... if there's new stuff it would be good for them to live in
other docs so we can all progress at a different pace without
holding each other up
bhill2: anything else?
annevk: we didn't cover during "Secure Contexts" is the IDL. should it hide, throw?
mkwst: currently it throws/rejects. I like that model but I'm open to being convinced I'm wrong
[heycam webidl issue 65]
<wseltzer> https://github.com/heycam/webidl/pull/65
mkwst: defines a secure attribute
that are applied to methods
... and either rejects promises or throws for non-promises if
they're used in a non-secure context
rbarnes: I have trouble believe that's a well-defined definition
mkwst: lookat the patch, hooks in
right after the security check
... right after we check that you have access to the object at
all we check the context. I think rejecting/throwing is better
than hiding the method
... pretending the document doesn't support this when it
does
annevk: especially with the document.domain thing nuking secure contexts
rbarnes: martin makes two argumentsd in the thread. [??]
mkwst: I think it's an aesthetic question. do you fall into a feature-detection regime or an error situation
annevk: two options for dealing
with document.domain -- either we're a secure context and
trying document.domain will throw
... or setting it destroys the secure context
<timeless> scribe: timeless
dveditz: if there's a TLS page,
we define a secure-context
... how do you know if it's not one
mkwst: their proposal is that
they're mutually exclusive
... do one thing, you're secure context, do the other, you're
stopped
dveditz: what if you're secure
context, then you ...
... oh, you're a potentially secure context
... then if you do something, you become secure context or not
secure context
mkwst: can't know until you're
observed
... as soon as you do one or the other
bhill2: you're a particle or a wave
dveditz: i wouldn't object if the outcome is document.domain goes away
mkwst: i hadn't thought about killing document.domain
dveditz: we'd need to measure
mkwst: i think it's too prevalent
to kill
... but tying it to these features would reduce risk
... if you use document.domain you have risk
... it's totally in line w/ the rest of secure context to
reduce risk
... i think it's totally worth it
yoav: any counters/usage data?
mkwst: maybe
bhill2: how does being a secure
context
... an https origined thing
... that is not a secure context
... affect your ability to reach into the dom of a same-origin
secure context?
<mkwst> ~4.8% of websites: https://www.chromestatus.com/metrics/feature/timeline/popularity/739
bhill2: https://evil.facebook.com,
domain lower to https://facebook.com
... can i reach into the iframe?
mkwst: only if the iframe also
set document.domain to facebook.com
... and we'd stop facebook because they'd want
geolocation
... document.domain has to be set on both sides
dveditz: we explicitly require that because of the Princeton attack in 2001
annevk: port is set to magic value
dveditz: that's why people scratch their heads at document.domain=document.domain
mkwst: let's say 4.8% of secure websites
dveditz: is it secure? perhaps document.domain is a marker of old web site
mkwst: we can find out in 3
months
... we kill at 0.03%
annevk: it won't be that low
mkwst: setting document.domain, being secure context, and secure context mattering, is relatively low
dveditz: makes it more complicated
annevk: not really
dveditz: if we could say "you are an ssl page, document.domain throws"
annevk: usage won't be that low,
we can't do that
... we can set a flag, and document.domain sets a flag, secure
context sets a flag
... idl annotation will have this
... automatic
timeless: and there's testing which should verify it
mkwst: let's explore this
idea
... and firefox and chrome add metrics for this
... document.domain set inside https page
... lower 0.03% then we kill it
rbarnes: +1
mkwst: adding metric in chrome
will be easy, but take some time to get data
... if we can kill it, great
bhill2: SomethingHandling for
more secure redirects
... Containers for Mozilla
... folks might not be here yet
francois: referer policy?
... I'd like to know where we're at
... are we trying to finish off the spec, go w/ what we have
now
... or an opportunity to see two more policies
mkwst: my name is on the spec, i
want to take my name on the spec
... jochen said he wanted to finish it
... if you feel strongly about adding features, talk to
him
... we talked about Referrer Policy
... if people have feedback...
rbarnes: we discussed Timing Attacks, because mkwst fixed it
mkwst: i only fixed one
... there's a paper at the bottom
... it wasn't a timing attack, now it's a timing attack
... if you have ideas of how to fix it, let's implement it
yoav: skimming timing attack
thing
... they're downloading resources, estimating sizes based on
download time
... they only have to do because no one has implemented
Transfer-Body-Size
... which would give them that
... or they could XHR the images and measure
annevk: that won't be exposed
mkwst: only if the endpoint opts in via cors
annevk: read up on same-origin policy
bhill2: they load resource, try
to feed it to <audio> or <video>
... IE/FF fail immediately
... the time it takes to fail gives out size
... similarly scripts, AppCache
... for ServiceWorkers, you can load an opaque thing
cross-origin
yoav: goal is to determine size of object
annevk: not for no cors
yoav: not for third party unless they allow origin
annevk: yes, but this is about that
bhill2: they could make the object uncompressible if they wanted to
<annevk> yoav: I recommend reading through https://annevankesteren.nl/2015/02/same-origin-policy
[ Adjourned until tomorrow ]
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/?: wrt/francois: wrt/ Succeeded: s/andre/andrei/ Succeeded: s/annevk:/jyasskin/ Succeeded: s/joachim/jochen/ Succeeded: s/jog/job/ Succeeded: s/concerned/concerned about references that should appear in IETF HSTS/ Succeeded: s/htis/this/ Succeeded: s|agenda link: https://docs.google.com/document/d/1h05daW54OA3-lqV2IbPA0otrQbkB9Ua8UXTj9Tm63Dg/edit#|| Succeeded: s/BREAK TIME till 1030h local time/[ BREAK TIME till 1030h local time ]/ Succeeded: i|popunder windows are impossible|scribe: bhill2 Succeeded: i|worked with annevk on|scribe: dveditz Succeeded: s/keiji;/keiji:/ Succeeded: s/mkwst: ths// Succeeded: s/thxx// Succeeded: s|agenda: https://docs.google.com/document/d/1h05daW54OA3-lqV2IbPA0otrQbkB9Ua8UXTj9Tm63Dg/edit|| Succeeded: s|https://www.w3.org/2015/10/TPAC/slides/WebAppSec-TPAC2015-Update.pptx|-> https://www.w3.org/2015/10/TPAC/slides/WebAppSec-TPAC2015-Update.pptx Brad's WebAppSec TPAC2015 update slides| Succeeded: s|link to preso?|| Succeeded: s/annevk:/annevk,/ Succeeded: s/on Broad Themes slide #3/[ Slide: 3 - Broad Themes ]/ Succeeded: s/S #6 subresource integrity SRI/[ Slide: 6 - Subresource Integrity (SRI) ]/ Succeeded: s/s 7: Referrer Policy -- fpwd/[ Slide: 7 - Referrer Policy ]/ Succeeded: s/s 9: upgrade insecure requests/[ Slide: 9 - Upgrade Insecure Requests ]/ Succeeded: s/s 10: UI Security/[ Slide: 10 - User Interface Security ]/ Succeeded: s/s 11: Cred mgmt/[ Slide: 11 - Credential Management Level 1 ]/ Succeeded: s/thx// Succeeded: s/thx// Succeeded: s/see above// Succeeded: s|https://w3c.github.io/webappsec/implementation_reports/CSP2_implementation_report.html|-> https://w3c.github.io/webappsec/implementation_reports/CSP2_implementation_report.html Implementation Report for Content Security Policy Level 2| Succeeded: s/have an impl rpt for CSP2/We have an implementation report for CSP level 2/ Succeeded: s/whta/what/ Succeeded: s/Brad's WebAppSec TPAC2015 update slides (world-readable link, per bhill)/"Brad's WebAppSec TPAC2015 update slides" (world-readable link, per bhill)/ Succeeded: s|https://www.w3.org/2015/10/TPAC/slides/WebAppSec-TPAC2015-Update.pptx|-> https://www.w3.org/2015/10/TPAC/slides/WebAppSec-TPAC2015-Update.pptx Brad's WebAppSec TPAC2015 update slides| Succeeded: s/-> -> https:/--> https:/ Succeeded: s|--> https:/|--> https:| Succeeded: s|https://www.w3.org/2015/10/TPAC/slides/WebAppSec-TPAC2015-Update.pptx|-> https://www.w3.org/2015/10/TPAC/slides/WebAppSec-TPAC2015-Update.pptx Brad's WebAppSec TPAC2015 update slides| Succeeded: s|--> https:|-> https:/| Succeeded: s/Brad's WebAppSec TPAC2015 update slides "Brad's WebAppSec TPAC2015 update slides"/"Brad's WebAppSec TPAC2015 update slides"/ Succeeded: s/mikwest/mkwst/ Succeeded: s/dvlprs/developers/ Succeeded: s/mkwst, dveditz:/mkwst:/ Succeeded: i/mkwst: csp2 is basically done/scribe: dveditz Succeeded: s/scribenick: dveditz// Succeeded: s|http://w3c.github.io/webappsec-csp/|-> http://w3c.github.io/webappsec-csp/ Content Security Policy Level 3| Succeeded: s|http://w3c.github.io/webappsec-clear-site-data/|-> http://w3c.github.io/webappsec-clear-site-data/ ED: Clear Site Data| Succeeded: i|error-reporting/|-> https://mikewest.github.io/error-reporting/ "Not Just Error Reporting" -- will have a new name eventually Succeeded: s|http://w3c.github.io/webappsec-secure-contexts/|-> http://w3c.github.io/webappsec-secure-contexts/ Secure Contexts| Succeeded: s|http://w3c.github.io/webappsec-credential-management/|-> https://w3c.github.io/webappsec-credential-management/ ED: Credential Management Level 1| Succeeded: s|https://docs.google.com/document/d/1h05daW54OA3-lqV2IbPA0otrQbkB9Ua8UXTj9Tm63Dg/edit#|| Succeeded: s|https://github.com/w3c/webappsec/issues/486|-> https://github.com/w3c/webappsec/issues/486 "SRI: needs integration with whatwg/html" issue-486| Succeeded: s|https://github.com/w3c/webappsec/issues/363|-> https://github.com/w3c/webappsec/issues/363 " reconcile/cross reference CSP and SRI hash behaviors" issue-363| Succeeded: s|[or maybe s/JeffH/mnot]|| Succeeded: s/JeffH/mnot/ Succeeded: s|https://tools.ietf.org/html/draft-west-webappsec-csp-reg-01|-> https://tools.ietf.org/html/draft-west-webappsec-csp-reg-01 "Content Security Policy Directive Registry" (IETF Draft, in last call)| Succeeded: s|https://github.com/w3c/webappsec-subresource-integrity/issues/3|-> https://github.com/w3c/webappsec-subresource-integrity/issues/3 "Review the stability of all referenced documents" (issue-3)| Succeeded: s|https://github.com/w3c/webappsec-subresource-integrity/issues/12|-> https://github.com/w3c/webappsec-subresource-integrity/issues/12 "Convert to Bikeshed" (issue-12)| Succeeded: s/(issue-12)/issue-12/ Succeeded: s/(issue-3)/issue-3/ Succeeded: s|https://github.com/w3c/webappsec-secure-contexts/issues/5|-> https://github.com/w3c/webappsec-secure-contexts/issues/5 "<iframe sandbox srcdoc='foo'> on a secure page should be secure" issue-5| Succeeded: s|http://w3c.github.io/webappsec-mixed-content/|-> https://w3c.github.io/webappsec-mixed-content/ ED: Mixed Content| Succeeded: s|https://lists.w3.org/Archives/Public/public-webappsec/2015Aug/0095.html|-> https://lists.w3.org/Archives/Public/public-webappsec/2015Aug/0095.html HSTS, mixed content, and priming| FAILED: s/junkees/Kepeng Li/ Succeeded: s/jungkees/Kepeng Li/ Succeeded: s|s/junkees/Kepeng Li/|| Succeeded: s/jungkees(?)/Kepeng/ FAILED: s/Kepeng Li --> Kepeng Li// Succeeded: s/hve/have/ Succeeded: s|s/Kepeng Li --> Kepeng Li//|| Succeeded: s/Kepeng Li/KLi/ Succeeded: s/Kepeng Li/KLi/ Succeeded: s/ --> /_arrow_/ Succeeded: s/KLi _arrow_KLi// Succeeded: s/yohanan/jochen/ Succeeded: s/ZZZ/francois/ Succeeded: s/Timing Attacks/Referrer Policy/ Found Scribe: JeffH Inferring ScribeNick: JeffH Found Scribe: dveditz Inferring ScribeNick: dveditz Found Scribe: bhill2 Inferring ScribeNick: bhill2 Found Scribe: dveditz Inferring ScribeNick: dveditz Found ScribeNick: bhill2 Found Scribe: dveditz Inferring ScribeNick: dveditz Found Scribe: timeless Inferring ScribeNick: timeless Scribes: JeffH, dveditz, bhill2, timeless ScribeNicks: bhill2, JeffH, dveditz, timeless Present: deiu francois wseltzer bhill keiji dveditz twhalen Kepeng mek rbarnes colin cscho4 jyasskin mkwst cscho JeffH npdoty kodonog yoav Barry Leiba Jungkee_Song annevk Agenda: https://docs.google.com/document/d/1h05daW54OA3-lqV2IbPA0otrQbkB9Ua8UXTj9Tm63Dg/edit?usp=sharing Found Date: 28 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/28-webappsec-minutes.html People with action items:[End of scribe.perl diagnostic output]