WebAppSec TPAC F2F, day 1 -- 06 Nov 2017

<wseltzer> mkwst: reviewing agenda

<scribe> scribe: dveditz

specs that are almost done

<wseltzer> scribenick: dveditz

Referrer Policy

mkwst: I apologize in advance I didn't get web platform tests running on Edge so I only have data for other browsers
...: RP went to PR in Jan 2017. waiting for implementation of a couple of things
... 6 open issues
... "should ping-from be controlled by RP?"

<wseltzer> https://github.com/w3c/webappsec-referrer-policy/issues/

jochen___: the author put the ping-from on the attribute, if he didn't want the referrer he could also put a referrerpolicy attribute on the element

estark: I agree, RP should control referrers, not things that are not referrers.

mkwst closes the issue
...: #74 editorial/typo --- assign to jochen___
... #82 also editorial, not even sure this is in the document anymore

estark: there's an interesting question here... if you're going from a valid TLS state to a broken one, would we want to strip referrers? Chrome isn't interested in doing that
...: if we don't implement that we may want to just look for the scheme of the origin being https and leave it at that.

mkwst: if no browser has implemented this we should leave it and if we need to add it in v2 we can do that
...: #96 RP attribute missing on script tags -- should fix, everyone assumes it's there
... #108 SVG doesn't say how it loads resources, so no hooks for RP to say how its resources are loaded
... #109 RP of child CSS

jochen___: there's a WPT for that

mkwst: WPT test results. Chrome passing all. Firefox passing a lot but two bugs killed a bunch of tests
...: Safari failing about half, but some are test failures (plus a couple of webkit bugs). would be great if apple folks could point me at folks who could help fix the canvas issues
... I'm hopeful when Firefox fixes their bugs we'll have two interoperable implementations and can proceed

wseltzer: have we gotten "wide review"?

mkwst: ...

<bhill2> the webex link in the agenda is only for the regular concall, so I can't join ("not started")

<bhill2> maybe at the next break, before CredMan, someone could see if an ad-hoc one can be started?

wseltzer: <explanation of who to consider for "wide review" depending on what specs are impacted>

jochen___: ... concerned that feedback at rec time could derail things. Feedback should have come on FPWD

@@: https://www.w3.org/2011/webappsec/webex.html -- TPAC

bhill2: https://www.w3.org/2011/webappsec/webex.html --- TPAC section at bottom

<bhill2> OIC. thx

sangwhan: TAG actually recommends having explainers at early stage for review, to get meaningful feedback

mkwst: I think we're doing a better job on newer specs. E.g. blink requires as part of the "intent to ship" process to send an explainer to the TAG
...: formally we'll send mail out, get no response, and say we got wide review. Two implementations is a better demonstration of wide review

<wseltzer> ACTION: mkwst and dveditz to send call for wide review for Referrer Policy

<trackbot> Created ACTION-218 - And dveditz to send call for wide review for referrer policy [on Mike West - due 2017-11-13].
...: we should be ready (dan and I) to send out for wide review and a transition request

secure contexts

mkwst: CR in Sept 2016
...: two issues, data: edgecases.
... may not be an issue now that Mozilla treats data as an opaque origin in all cases
... next issue is "secure stylesheets" -- will have to cache state when CSS is parsed

<wseltzer> https://github.com/w3c/webappsec-secure-contexts
...: writing tests will be difficult because there aren't any css features restricted to secure contexts yet
... chrome failing some tests (3 bugs) -- missing nested workers, SharedWorker connection, and Worker's document's ancestors
... firefox passes most, single bug "opener" doesn't influence secureness anymore
... safari basically missing the things Chrome is
... should have interoperability very soon

<wseltzer> ACTION: mkwst and dveditz to send call for wide review for Secure Contexts

<trackbot> Created ACTION-219 - And dveditz to send call for wide review for secure contexts [on Mike West - due 2017-11-13].

upgrade-insecure-requests

mkwst: FIrefox has a great implementation, passing everything
...: open issue, need to upstream some language to HTML

<wseltzer> https://github.com/w3c/webappsec-upgrade-insecure-requests/issues
...: issue about Vary header, I'll work on that.
... safari and chrome have an issue with redirects, otherwise fine
... does edge support this?

angelo: we do not

johnwilander: is the order of UIR and HSTS specified, especially with redirects?

mkwst: <brings up fetch spec> yes, well specified

johnwilander: will be hard for us to do redirects and upgrades

mixed-content

...: CR in March 2015, republished Aug 2016
... one open issue. Media is optionally blockable (will be shown) but Tracks are blockable. got a complaint this harms accessibility
... seems reasonable. Do we stop blocking Track, or do we get more aggressive and solve the accessibility problem by also blocking the Media?
... from my POV I'd like to make things stricter rather than loser in general. Given the usage I don't really care -- not used much.
... mixed-content text track is practically indistinguishable from zero, but in theory it's inconsistent

dveditz: the inconsistency is sort of fingernails-on-chalkboard, but I don't really care because it's not used much
...: Fx fails 6 tests because link rel=prefetch considered blockable. but in fact I prefer Firefox's behavior.

<scribe> ACTION: dveditz to file issue on the spec to match Firefox behavior

<trackbot> Created ACTION-220 - File issue on the spec to match firefox behavior [on Daniel Veditz - due 2017-11-13].
...: safari fails a few more tests, some for unrelated things (like error events being fired in particular ways)
... also no support for prefetch and also <picture> and <img srcset

mkwst: the stated goal of the spec is to eventually block all mixed content
...: images are "less dangerous" and "widely used" so they're getting a pass at the moment

danbates: I don't see a lot of value in treating them as blockable other than "can we get away with it"

johnwilander: I think the media stack in mobile is different enough that it might be worth splitting these out. I hope we behave the same on desktop and mobile but we need to check.

danbates: I'd like to hear what edge does

mkwst: me too

credential management

mkwst: specifically want to talk about integration with web authn so we're not blocking them going forward
...: sent a couple questions to public-webappsec

<wseltzer> https://lists.w3.org/Archives/Public/public-webappsec/2017Oct/0016.html
...: AFAIK chrome is the only browser that has implemented the in-browser password management
... doesn't look like password and federated credentials will be able to go to PR and then Rec any time soon because of lack of other implementations
... one option would be to split the spec. Tried it once and got feedback that it made things too complicated (which I agree with), but from a process perspective it could be helpful to split
... wendy, what happens if web authn tries to go to PR referencing our spec that's not implemented

wseltzer: they'd be asked about the stability of the specs they are referencing. Normally expected that a spec entering PR should reference specs in PR, and going to Rec referencing Recs. But not absolute if stability can be shown

mkwst: so the argument would be that web authn is depending on "stable parts" of the spec, as shown by multiple implementations?
...: do folks here have a preference 1) push to CR as is and wait for implementations, or 2) split the spec and push the infrastructure parts to PR

danbates: we've been slow to have a discussion on whether passwords are a useful spec. the usecases don't seem useful to implement. spec says a replacement for browser heuristics, but from our POV the browser heuristics work pretty well and wouldn't give sites an incentive to change what they're doing.
...: is the issue distaste for the browser heuristics?

battre: there are types of login such as XHR in the background where getting the password values programmatically would help

mkwst: for example, NY Times pops up a login form that wasn't there, submits (via XHR) in background and never updates the page, makes it hard for Chrome to know whether the login was successful or not

danbates: if the user types something different in the form, then they want to update the password. I don't see the problem

jochen___: chrome currently asks if you want to update your password (normal form). If user updates their password and doesn't update the password store, and login happens in the background, they don't see the error or know how to update their password.

<tanvi> why did the javascript access restriction go away? I missed that

danbates: I've not heard of any bug reports of complaints about the current behavior. If there are any it can probably be addressed by a new autocomplete attribute or page hint. not a whole new API
...: the bigger issue is the page knowing the password -- that would be a bigger win to sell to web sites. You could XSS that page but that's OK because there's nothing to intercept.

mkwst: you should be looking at what the web authn group is doing then -- they're trying to solve that problem

<battre> the comments about chrome's current password manager behavior were from battre, not me
...: in a slightly different way, but that could be the place for that.

<jochen___> tanvi: did mkwst's talk about web site author's feedback on the CM API answer your question?

mkwst: the current form of the spec was shaped by feedback from web developers that the old version was too complicated, but that they liked the features they got

<tanvi> jochen___: only slightly
...: and it's a stepping stone to using the same API in a similar way to get to a more secure behavior

<tanvi> jochen___: you had to come up with a new system that made it impossible to restrict javascript access?

jeffh_: passwords are not going away immediately, some people can use federated credentials, and some sites are adding authenticators like Google

mkwst: if a site can ask a user for both a password and a security key, the browser can help walk the user through that because the browser knows what the user has used before. NFC key? USB token? the browser knows
...: the code for the site can be common in those scenarios

johnwilander: for web authn we definitely see the value! back to the question, splitting or not....

<jochen___> tanvi: well, the feedback was that folks couldn't change their server side endpoints to consume the opaque passwords
...: what you're hearing from dan is that the password part is not that interesting because heuristics work and exposing the password doesn't offer the site any additional security. the part supporting Web Authn is important

<jochen___> tanvi: giving script access to the passwords made it possible for them to use the spec

<tanvi> jochen___: i see

<tanvi> that is unfortunate

angelo: the federated case is interesting. I can see a case for it, but is anyone pushing to use it?

<jochen___> yeah, that's why I proposed that we could make it some per-origin configuration

jeffh_: using the API users would get a consistent behavior across sites

tanvi: mozilla is in favor of splitting. we have active work on implementing web authn and the parts that requires, but having trouble getting interest in implementing the other parts. Seems like it could be a UX win, but with other priorities not compelling enough yet

<tanvi> well more than that… I don't think the UX win is good enough. I think we need to do more here to make this compelling

mkwst: concrete actions are -- split the spec, we have good idea what the infrastructure is. Look at the password/federated part and see how we can drive interest in that (or if we can) separately

angelo: can we do the split in a short amount of time?

mkwst: we already had it split once, shouldn't take that much time

<tanvi> Along with the UX wins, we need some more security wins

<wseltzer> [break, return in 36 mins]

mkwst: let's take a break now, come back at 11:00 for CSP3

<mkwst> mkwst: Welcome back! ArturJanc is going to talk about CSP @ Google for an hour before lunch.

<mkwst> aaj: [slides]

11: 06 ...: over the last year we've spent time using CSP3 features and can give feedback on what's useful and what's not

CSP 3 part 1

ArturJanc: last year we talked about why we wanted to use nonces instead of whitelists
...: over the last year we've spent time using CSP3 features and can give feedback on what's useful and what's not
... nonce-based policies require: 1) remove inline event handlers and javascript urls. 2) create a random value and add nonce attribute on script tags. 3) send a CSP with strict-dynamic and the nonce (and unsafe-eval for old browsers). 4) roll out in report-only mode to check for broken stuff
..: side note my team runs the web vulnerability reward program and we pay a million (?) a year. 60% of the web vulnerabilities are XSS
...: CSP adoption at google -- gmail, google accounts, google docs/wallet/photos/contacts etc
... high value UIs -- account management applications, cloud admin interfaces, etc
... nonce-based adoption -- over 70 distinct services, enabled for ~50% of HTML responses, req'd for new appls and enabled by default in popular frameworks
... elsewhere -- uber, pinterest, optimizely, atlassian
... CSP wishlist for browser vendors
... strict-dynamic, report-sample, CSP violation events
... report-sample can help distinguish between noise (extensions?) and attacks (snippets of injected script?)
... all of these are in the spec so I don't think they're controversial, but they would really help my life to implement them
... still give rewards even if blocked by CSP because not in all browsers, treat as "defense in depth"
... attacks on nonce-based CSP we've seen or reported elsewhere
... 1) if you have injection, might have exfiltration of values from DOM using scriptless features (<style>script[nonce^=a] {background-image: <url>} etc) -- needs to be able to reload page many times
... 2) hijacking nonces set on existing script element (effective when the injection point is near the start of a script)
... 3) non-platform attacks (behaviors introduced by JS frameworks). e.g. frameworks might eval or otherwise execute stuff based on tag attributes
... CSP wishlist for vendors
... 1) hide nonces from the DOM (WHATWG html pull 2373)

mkwst: shipping in chrome now, think we have aggreement from other browser vendors
...: nonce available to _script_ using the property, but not as an attribute value (e.g. not visible to style)
... lots of back and forth, I think we're comfortable with the outcome. need to add some tests to make sure the WHATWG folks are happy with some edge cases

ArturJanc: second issue is if you have an unclosed attribute it can eat a following opening tag. feature "Is element nonceable"

mkwst: one thing this doesn't cover is repeated attributes. according to spec we throw away a 2nd attribute, so you can override things, like the src=. I'd like to record the fact of duplication and then disallow nonces

@@: would that be specific attributes or just any duplicated ones (is src= special, others?)

mkwst: I think we want to keep it simple and say "if anything is duplicated..."

arturjanc: the feature wishlist and the security wishlist are the most important things for giving security value to CSP deployments
...: remaining CSP pain points...
... we're happy with what we have now in the platform (including spec'd issues only implemented in chrome)
... but there are things that could help other places
... 1) difficult to get rid of inline in existing content. especially inline event handlers. refactoring is tedious, hard tod emonstrate value to devs
... recently ran a google-wide fix-it event to remove inline event handlers. started with ~half a million event handlers. during fix-it we fixed a few thousand of them
... prior to CSP there was not much reason not to do it. CSP is a reason to avoid them now, but large backlog. no automated way to do it (in general)
... 2) static HTML content. often have inline script (event handlers) but can't have nonces (because static). 'unsafe-hashed-attributes' could help
... 3) noise from CSP violation reports. 'report-sample' can help
... 4) increase the power of nonces -- form-action, base-uri, etc
... 5) things on mike's list (disown-opener, navigation-to, ...)
... what should 'unsafe-hashed-attributes' do? problem is it's not backward compatible (earlier CSP versions would still block the inline handlers, so we'd have to UA sniff and serve different content or lax CSP)
... some people are unhappy it weakens the policy -- allows attacker to inject an event handler to a whitelisted function
... the alternative could be no CSP at all ('unsafe-inline')
... without these carveouts there are properties at google that will never get CSP

mkwst: could add a new directive script-hashedattributes that has precedents over script-src, and newer browsers could use that for hashed attributes and old browsers could use the less safe 'unsafe-inline' for attributes

artucjanc: a large number of pages only had a small number of inline event handler hashes. I'd be happy targeting 80 or 90 percent of our documents with such a feature.

mkwst: from my perspective it's significantly better than unsafe-inline. making it easier to deploy would be an improvement. I'd like it to be backward compatible, and the second directive is better than what's in the spec today

devd: I'm concerned about the length of headers. Artur is facing static pages with a small number of hashes, mine have more inline handlers

arturjanc: for applications (like dropbox) that have already deployed CSP one of the preconditions was getting rid of those

devd: is this your (artur's) priority list? I'm in favor of unsafe-hashed-attributes, but not in favor of it at the cost of dropping something else?

mkwst: we've already implemented this at Google, and even if we need to change it it's not that much work.
...: from my POV seems relatively low cost and medium value -- a win

ckerschb__: I agree it looks fairly easy to add, but concerned about the overall complexity and priorities

mkwst: we should look at what we can dump from the spec. I think everything has value, but maybe not enough value
...: after this conversation we should figure out what's in, so we can finish it up, and start a list of valuable features to consider for a later version
... what are opinions about adding a directive vs what's in the spec?

devd: don't like the complexity of another directive

dveditz: oh boy, the opposite for me. if we don't have backwards compatibility people won't use this for years until more browsers implement

danbates: don't feel as strongly, but prefer a new directive that's backward compatible

arturjanc: we did talk about another ugly-but-backwards-compatible approach. invent a new synax for specifying hashes that old browsers didn't recognize but would be seen as event handler hashes

<various> : additional directive clearer than a subtle hash spelling difference

<scribe> ACTION: mkwst to figure out new syntax and send to the list

<trackbot> Created ACTION-221 - Figure out new syntax and send to the list [on Mike West - due 2017-11-13].

mkwst: feedback an others?

devd: liked the idea of nonces on form-action. love form-action but it's not expressive enough

mkwst: are there other cases or is form-action the one you want nonces for?

devd: seems like anywhere you have a whitelist we also want nonces

arturjanc: there was a proposal a decade ago about having tag names that included the nonce. not workable today, but an interesting idea

mkwst: some people have proposed notating the end-tag, so an end tag only closes the intended tag

<wseltzer> [lunch: break for 1:30]

<mkwst> Slight shift in schedule: due to some conflicts later in the afternoon, we're moving suborigins up to after lunch.

<ArturJanc> Suborigins explainer: https://docs.google.com/document/d/1sDVPKmhAdS4aioEguOUOneQkrHoXvZrHUEJEJuWYETI/edit

<wseltzer> [resuming]

<scribe> scribenick: mkwst

ArturJanc: Suborigins!

Suborigins

<wseltzer> https://lists.w3.org/Archives/Public/public-webappsec/2017Nov/0001.html

ArturJanc: https://docs.google.com/document/d/1sDVPKmhAdS4aioEguOUOneQkrHoXvZrHUEJEJuWYETI/edit
... Privilege separation is a useful concept.
... One of the better ways to give useful security properties to applications.
... Web Applications are an instance of a complex software application. Many subcomponents. Listed in the doc.
... Conceptually, these subcomponents are different, but share a security principle.
... These things are philosophically separate, and we could in practice separate them with a mechanism like suborigins without much overhead.
... Unlike `sandbox`, it's possible to put high-value pieces of an application into a suborigins.
... Google had an intern over the summer that implemented a Chrome extension which enabled testing of Chrome's current (behind a flag) implementation of suborigins.
... Simulates suborigin response headers on a number of paths.
... Simulated server-side support (for CORS and etc).
... Logged console error messages, looking for changes that occurred due to suborigin imposition.
... Extension generates a short report: "Hey, you need to modify this endpoint to handle CORS preflights." and the like.
... Not large-scale testing.
... But we see that if we enable suborigins in some small-/medium-sized applications with some of the `unsafe-*` flags, then there isn't that much work on the developer's part to get things running.
... Main work has been CORS support.
... Endpoints need to understand how to handle suborigins correctly. Other than that, experience quite positive.
... Anecdata, but encouraging nonetheless.
... Open questions:
... Overarching question, "Is suborigins a reasonable primitive to add to the platform?"
... Detail questions like "Handling browser permissions?"

dev: From Dropbox's perspective, this is exciting. We'd implement when available.

Brent: GitHub is also interested. Kinks to work out, but the idea itself seems really beneficial.
... /admin endpoint, for example.
... Could be solved with subdomains, but much nicer to solve at an application level.

mkwst: Can you talk about subdomains a little more?

ArturJanc: I addressed this in the doc!
... Migrating to subdomains is very painful.
... URLs break, cookies break, bookmarks break.
... Not a flexible architecture.
... Tying endpoints to DNS architecture.
... Some APIs need to work on an origin basis that are no longer available in a subdomain.

Deian: Don't most of these break with suborigins without `unsafe-*`?

ArturJanc: Depends on the flag.
... `unsafe-cookies` is pretty necessary in the current architecture.
... Might be ok if `HttpOnly`.

Dev: Subdomains don't provide cookie security. Cookies span origins.
... Also, folks _aren't_ migrating to subdomains. Practically, we see that it doesn't work.
... Also, suborigins can be stronger than subdomains.
... Also, this is a different layer: as Brent said, moving to the application layer makes it easier to deploy.
... Much harder to make network-level changes.
... URI changes for the user are also confusing. Shouldn't need to present to users.
... Parallels to HSTS, HPKP.

Deian: Only reason I bring it up is Jackson/Barth's paper : http://w2spconf.com/2008/papers/s2p1.pdf

ArturJanc: Skimmed it earlier today. Seems orthogonal to suborigins.

Dev: My sense of the paper was as a pushback against using the path as a finer-grained origin.
... This spec ties to the existing origin concept.
... Using CORS extensively.
... They're saying "It's not simple." and suborigins aren't simple.

Deian: [scribe missed the point :( ]

JohnWilander: Other kinds of storage beyond cookies?
... Can code switch suborigins?
... Ghost stuff on disk because it was in a suborigin?

ArturJanc: We've thought about this a bit in the past, but it's fairly fluid.
... Right now, storage is scoped to the suborigin, doesn't leak across.
... Can share cookies with the physical origin with a flag.
... Not much different than localstorge with different keys on the same origin. Still wiped along with the origin's data.
... Transparent to the user.
... Delete data from physical origin, clears suborigins as well.

JohnWilander: Switching?

ArturJanc: No, can't dynamically change suborigins right now.
... Proposal for a placeholder suborigin which would put the page into a dynamic suborigin at runtime.
... It would make sense to have all storage mechanisms availale to the suborigin.

JohnWilander: And other APIs? Permissions?

ArturJanc: This is one of the big open questions.
... Depends on how you think about them.
... If they contain XSS, then yeah, inherit permissions.
... If you think about them as segregating applications, then yeah, segregate permissions.

<npdoty> if suborigins are entirely transparent to the end user, will the user ever become confused when it appears to be the same website in the URL bar but has some different functionality?

mkwst: Perhaps layering feature policy in would make sense.

jochen: Should be transparent to the user. Asking permission is hard. Feature policy might be a reasonable approach.

npdoty: For those users who do look at the URL bar, will there be negative side-effects? Confusion?

ArturJanc: It seems like an implementation detail of the application, not something user-visible.

npdoty: Permissions: "I thought this permission was granted. Why is it asking me again?"

dveditz: Trying to protect one part of the origin from another part of the origin.
... Permissions are asking whether the user trusts the physical origin / organization.

npdoty: Seems like the user might get some benefit if permission grant inside a suborigin didn't persist.

Dev: The `/~nick` case seems like a good example.
... Suborigins would prevent the request from the untrusted resource.
... Right now, they all act as the physical origin.
... Should not let the suborigin ask for permissions.
... If it can ask for permission, should grant to physical origin.

[scribe is talking, sorry!]

<npdoty> mkwst: I think the physical origin is hierarchically above the other sub-origins. you have to trust the server in any case. but it is a separate dom environment

<jeffh> tanvi: suborig spec presently protects the origin, but not suborigins

<jeffh> dev: yes

<jeffh> arturjanc: agree

[more talking, sorry!]

tanvi: Have you talked to Yahoo!, etc?

ArturJanc: I asked on Twitter! Heard from GitHub and Dropbox. Haven't heard from other large companies.

Nick: How beneficial is this compartmentalization?

ArturJanc: Depends a lot on where the XSS bugs in your application are.

<dveditz> bhill2: still around? Do you know, if you can say, whether Facebook folks are interested in the suborigins concept?

ArturJanc: Some applications' `/admin` is more vulnerable than the rest, putting it into a suborigin doesn't help.
... Others might have DOM XSS in static pages, so segregating `/admin` is valuable.

Nick: Should take the scary things and reduce their privilege.
... Refactoring pain in deployment?

ArturJanc: Bidirectionality is critical.
... Deployment is critical.
... If it's more than a little bit of work to separate your origin, folks won't do it.
... Ease of adoption is really important.

Dev: Need to segregate the important things for your application.
... For instance, Google can adopt `unsafe-cookie`, Dropbox can't, because the cookie gives you everything.
... Application-dependent challenges to adoption.

ArturJanc: For Google, `www.google.com` has ~200 different applications.
... All served from same origin, but completely different bakends.
... Even with coarse-grained application separation, we'd see benefits.

??: In a world of site-isolation, would suborigins share a process with the physical origin?

ArturJanc: Depends on how we think about them.
... Might be able to separate them? But for me, 99% of the value is XSS, so process isolation isn't important.

John_Hazen: Maybe it's just the name?
... "Origin" has meaning, not sure that "Suborigin" means the same thing.
... Names are hard.

<dveditz> "data-island"

ArturJanc: mkwst mentioned the same thing. Not how browser vendors think about the "origin" concept.

<tanvi> +1 on name issues

ArturJanc: I'm not tied to the name: name it whatever.
... Happy to not imply that it's an "origin". Maybe a "container" or something.

<dveditz> hardly anyone does http auth anymore, can we steal "realm" ?

<dveditz> "facet"

<tanvi> dbates: named-sandbox

<tanvi> deian - reverse-sandbox

<dveditz> boot

[discussion of `sandbox` vs suborigins]

[challenges around inheritance]

[origin attributes]

<npdoty> I didn't think "origin" was used without purpose. it seems like you want all the cross-origin algorithm checks not to have to be changed, because the serialization of the origin will change and then all the same rules (in fetch, html, etc.) will apply

jochen___: If you introduce origin attributes, you still have to change all the specs.

<npdoty> ... but actually it sounds like we accepted that we have to change and revise all the other specs anyway

jochen___: Also, origins have behavior tied to cookies, walking up your DNS labels, stripping ports, etc.
... Also, we have two use cases for origin attributes, which HTML folks didn't feel like was enough for fundamental changes to "origin".

<dveditz> npdoty: that was the hope, for sure. turned out to be naïve

jochen___: Not sure whether origin attributes solve the problem.

scoping down CSP 3

<wseltzer> ACTION: Devd to lead the next iteration of the suborigins spec

<trackbot> Error finding 'Devd'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.

<dveditz> scribenick: dveditz

CPS3 for real now

mkwst: a number of proposals in csp3 -- should we keep them or trim so we can finish?
...: "changes from level 2" is a place to start.
... "works in progress" sections aren't shipping in any browser. other sections are shipping in at least one
... 'unsafe-hashed-attributes' -- talked about that earlier, we can finish up on the list. important to us (google)
... other new features solve problems currently unaddressed anywhere
... 'disown-opener'. If someone opens you they get a handle to you, and can get some info cross origin.
... length of the frames[] array might leak whether someone is logged in, for example
... challenging for the opening relationship because it could be asynchronous, could be after redirects or even navigations. meanwhile the opening page got a window handle as a result of calling the function. hard to reach back in and neuter it later
... I propose changing the HTML algorithm about allowing access rather than actually killing the window handle
... so "disown-opener" may turn out to be a bad way to think of it, changing access checks
... not convinced CSP is the right place (feature policy?)

johnwilander: can we turn it around and kill opener by default? have to add things to CSP "keep my opener"

mkwst: sure, would love to kill opener outright, but people are using it. Are sites that already use CSP among that nuber?

arturjanc: how is it specified now? can you say "disown-opener but allow self?"

mkwst: my colleague Andy suggested that if we implement this as an access check rather than a literal killing opener we could then take a list of allowed domains. (could change the directive name)
...: in that form could then apply to frames , so you don't have to block framing you can just block access (appropriate in some cases like the Facebook like button)
... is this a problem to solve in CSP, or elsewhere?

Patrick: from a web dev background this seems like the wrong place to do this. Could opener be off by default? the problem would be legacy content

mkwst: how would you expect the opt-in to work if opener is off by default? would the on switch be in CSP?

Patrick: yeah, in that case CSP seems like a good place

devd: I think we should make a new header called CSP3 so we can punt on the backwards compatibility issues

mkwst: if we agree opener is bad we could turn it off by default and have an on switch.
...: one use-case I know of is the SSO case, where you need a bidirectional handle

mkwst: we only have a couple of things to work with. Origins, and window proxy objects

john_hazen: putting it in CSP works for us, especially with a domain list of allowed accessors

dveditz: CSP makes sense to me.

mkwst: 'navigation-to' is in the doc, not entirely fleshed out. Our ads team is asking for it, they want to control where an ad can navigate
...: from my interest, preventing malvertising seems like a good case for this
... they'd probably use embedded enforcement.
... from a high level seems clear, but in the details there are a lot of things that look like navigation, and what counts as the navigation being done. meta refresh, redirects, navigations based on scripted timeouts
... I'd like to see this in the platform, so ancestors can control where frames go.
... not clear we'll get agreement in a reasonable timeframe though

<jeffh> dveditz: would this work better as a sandbox attribute ?

<jeffh> mkwst: for the ads context, sandbox would work fine
...: has come up before in the context of exfiltration

jochen___: my impression is this would not only for ???

mkwst: specifying what happens when you click a link is easy. if you want to control what happens after that gets more difficult.

john_hazen: have you considered this becomes a strong signal which frames are ads?

mkwst: it would certainly signal that a frame has a different trust relationship with the parent

ckerschb__: this doesn't make sense as a top-level feature

arturjanc: I agree with christoph because almost every origin has an open redirect, so it would give a false sense of security

mkwst: ok, sounds like people like the concept. is it fleshed out enough to include in CSP 3 or make it later?

john_hazen: we should punt it if you want to get CSP3 out

devd: can it be optional? I would hate to have to wait for everyone to implement this to be able to use other CSP3 stuff

<wseltzer> [15min break]

mkwst: coffee time... come back at 3:30

Storage Access API

<jeffh> scribenick: jeffh

<dveditz> scribenick: jeffh

<inserted> scribenick: mkwst

JohnWilander: [Cookie policy in Safari 11]
... Changed from Safari 10.
... Used to be one-in-all-in: If you have a cookie set in a first-party context, you can have your cookies in third-party contexts.
... changing to a partitioning model named ITP.

<jeffh> scribenick: mkwst

JohnWilander: Categorizes origins as "prevalent"
... Prevalent origins are partitioned in third party contexts based on the last user interaction with the origin as a first-party.
... Storage Access API aims to mitigate some of the fallout of the ITP change.
... [Example of "Example-ID"]

<bhill2> is there a document or slides presented?

JohnWilander: User visits Example-ID, uses it.

<dveditz> bhill2: not currently shared... we'll bug john to post it

<bhill2> thx

JohnWilander: In order to keep state when Example-ID is used a third-party context, ITP forces first-party interaction daily.
... Today: Example-ID doesn't work with third-party cookie blocking, and ITP makes it cumbersome.
... Storage Access API is implemented behind a flag in Safari TP.
... Adds a new `allow-storage-access-something-something-something` to `<iframe sandbox>`, which allows the framed resource to ask for permission to have its cookies.
... via `document.requestStorageAccess()`
... 1. If unique origin, reject.

2. If main frame, resolve.

3. If not sandboxed: reject.

4. If not storage access sandbox token: reject.

5. If not direct child of top document: reject.

6. If same-origin: reject.

7. If not processing a user gesture: reject.

8: User agent-specific rules: Reject/Resolve (ask the user somehow?)
... "Spec-out clickjacking." Interested in UI-Redressing.

<bhill2> that would mean that every existing resource on the web would have to update how they do their embeds

<bhill2> instead of the iframed content just being able to call a new API to resolve against browsers that implement this new policy

mkwst: Is this only for `document.cookie`?

JohnWilander: No, it means that any request made from this frame to its origin will have credentials.

bhill2: Why require `sandbox`? Need to update all existing content on the web, vs allowing frames to request.
... If the goal is to resolve things that broke, this pushes out the window of breakage.

JohnWilander: `sandbox` was a convenient place to put the attribute. Could consider putting it somewhere else.

bhill2: This model privileges sites that have JS access to the parent.
... Well-behaved folks are punished, because their relying-parties need to go update their embeds.
... Don't see the value-add on top of user-gesture requirements, etc.

JohnWilander: Ah, not a question around `sandbox`, but around the requirement for the iframe to change.

bhill2: I would like for the framed resource to be able to request permission without requiring the embedder to change.
... Requiring both parties to update is a substanttal adoption barrier.

JohnWilander: I hear you, and I'll consider it for sure.

tlr: What is the "same origin: resolve" rule doing?

Domenic: If you're same-origin, you can twiddle bits on your parent.

tlr: What about "not direct child"?

JohnWilander: Anti-clickjacking might be harder with nested iframes, wanted to mitigate that.
... token in the document: goal was for the owner of the main document to know and accept that the embedee would be able to ask for storage access.

tlr: Part of what I have in mind is that one site is embedded by another, but want some intermediary to be inbetween.

Domenic: Seems reasonable.

dveditz: What storage does this apply to?

JohnWilander: Currently only cookies.
... Considering expanding that, since when you have access to one storage mechanism, you can track.

tanvi: "Partition" === double keyed?

JohnWilander: Yes.

tanvi: 3 & 4? Sandbox and storage access token?

JohnWilander: Thought was that embedder should control whether the child can prompt.

<bhill2> seems like the requirement for a user interaction in the 3rd party frame resolves some of that concern

mkwst: Brad suggested that the embedder requirements privilege a certain kind of embedding (JS execution in the parent), which we'd actually not like to encourage.

tbl: User gesture requirement?

JohnWilander: Goal is to give the embedee the ability to state its purpose.

slightlyoff: You'd take a string from the frame and present it to the user?

JohnWilander: We'd have a set string from the browser containing the origin, and add a "purpose string" from the user.
... They can say why they want the access. Up to the user to decide whether they want to grant.

estark: Chrome has generally resisted putting site-controlled strings into trusted UI.
... Bad sites won't be honest in their purpose strings.
... UI is a little in tension with feature policy, delegation.
... Chrome's trying to restrict prompts to the origin that's visible in the address bar.
... Other origins are confusing to users.

JohnWilander: This is a third-party asking.
... We'd like to have user control.
... Some users won't understand the implications of saying yes, but the closest we can get is telling them who's asking.
... Legit use cases will work fine.
... You'll understand that this is a commenting widget from socialmedia.com, will grant the access.

tbl: Framing it as "log into X" rather than "grant storage to X" might work better.

AndrewBetts: This looks like an iframe-by-iframe basis. Have you considered an origin-by-origin basis?
... Consider two iframes on the same page, both loading content from the same origin.
... If one asked for access, will the other get access as well?

slightlyoff: State is accumulated under the double-keyed origin. Making this request now swaps those for the entire origin, even if it has running documents?

JohnWilander: Changes for all the frames.

slightlyoff: Broadcast API?
... How are developers supposed to deal with this?

tbl: If you have a view on an origin that is "impoverished", when you log in on one of them, you've logged into all.

AndrewBetts: Assuming we want all frames to change together, then why are we opting in with an attribute on a single frame?
... Is it just because we haven't shipped feature policy yet?

JohnWilander: It's important to me that when it's called, it's called with the embedder's permission.

tanvi: Aren't we going back to where IE was before, when it would ask users every time they wanted to have cookies on a site?
... Are there rules we could put together to grant access without asking the user?

JohnWilander: If the parent can just grant cookie access, then the third-party will force the first-party to add the attribute.

mkwst: If you're outside the 30-day window, can you request access to cookies?

JohnWilander: No. It'll always reject. We remove the cookies after 30 days, so there's nothing to request access to.

<tanvi> i see

<tanvi> so the third party had to be a first party in the last 30 days in order for a permission to even show up?

bhill2: The advisary doesn't need a 100% perfect view of the user's state. Satisfied with a probabilistic view.

<tanvi> is that correct?

bhill2: Numerous fingerprinting techniques.
... Users lose meaningful protection (SSO, IPC mechanisms between origins, etc)
... Can't log in without 100% accuracy, but less-than-perfect is fine for ads.
... One concern is that you're pushing the adversary to fingerprinting, giving users less control in the end.

JohnWilander: I don't agree with that view.
... Is this API useful, does it solve these problems?

bhill2: I know you don't agree with me, but it doesn't seem like this API is a net positive.

tanvi: You suggested that users won't be prompted often, since Safari has been behaving this way for a while.
... Might change if all browsers behave this way.
... If the market shifts, incentives for advertisers change.
... I expect you'd see permission prompts more often.

<bhill2> here's the IAB recommending more back-end matching and fingerprinting in response to the Safari changes: https://www.iab.com/news/understanding-reacting-apples-safari-browser-tracking-changes/

slightlyoff: As the adversary, I'd run the auction in the top-level, and interstitial users to force user action.

JohnWilander: you're arguing against ITP, not against this API.

<bhill2> as @slightlyoff says, the IAB in that same document recommends "Develop a common, consolidated ID routed through a single domain. "

slightlyoff: That's a fair point.

jochen___: Why not just assume that interaction in the last 30 days is good enough to allow access to this API without an attribute on the iframe?

JohnWilander: Designing ITP was full of tradeoffs. We tried to balance the goals of that feature with fallout.
... That's why we have 24h/30d timeouts.
... This would allow the domains in the partitioned state (the 30d) to request their ID in that embed scenatio.
... Willing to consider doing without the token in the 30d case. Perhaps that makes sense.

tanvi: Right now, third-party is double-keyed, unless within the 24h.
... This allows the site to get out of that double-key.

mkwst: State leaking between double-key and single-key, given the dynamic shift in state within an running execution context?

<bhill2> or content providers on the web will move to host everything as AMP at Google or Instant Articles on Facebook since that's the most effective way to monetize

JohnWilander: Perhaps that's not a big deal, if the user's opting in?

mkwst: Is this a persistent flag?

JohnWilander: Perhaps the permission could be persistent, but the API would need to be called with some regularity.

jochen___: On how many sites would I need to enable a given identity provider in order to use it on the internet?

JohnWilander: Oh, prompted on 10 different sites, maybe stop prompting?

jochen___: Sure. That's how it worked. The idea of having an identity provider is that it works.

JohnWilander: You can ask on various sites. Doesn't seem like an imposition.

jochen___: Still have to say yes a few times. Once to the RP, once to the browser, once to the IDP.

tbl: Might be reasonable for some people to "always" log in with a given IDP. But some people wouldn't want that.

bhill2: How long does this persist?
... Seen requests with the iOS analog to make requests in context.
... Ask user when the're in the middle of a related action, so it's easier for them to understand.
... That's not how iOS implemented it, we have to ask every time new permissions might be requested.
... encourages overasking to begin with.

JohnWilander: Intended to be a one-time prompt for a given context (B embedded in A).
... Not per-page-load.
... Would folks from other vendors be interested in implementing this for their 3rd-party cookie bloking options?

jochen___: Chrome has UI for this today that allows granular opt-in on a per-origin basis.
... Not clear that adding a user prompt above and beyond that UI would be valuable.

JohnWilander: Say I opted into 3rd-party cookie blocking in Chrome, and can see UI where it shows me that X domains were blocked.
... Need to understand where the iframe came from, right?

jochen___: Yes, but the assumption is that this is something the user is familiar with (their identity provider, etc).

tanvi: You can also have "Something's not working, allow cookies." button for that page load.

slightlyoff: Do you have evidence that users understand the policy you're suggesting?

JohnWilander: No.
... Let's move on to affiliated domains!

Affiliated domains

JohnWilander: goal is to make it simpler to integrate domains with different origins but the same owner.
... examples: apple.com, icloud.com, itun.es, ...
... google.com, abc.xyz, google.de, youtube,com
... etc.
... Today, these don't work together with 3rd-party blocking, partitioning, etc.
... Cache partitioning is inefficient.
... If we had a mechanism to know that a set of domains had the same owner, we could not have third-party treatment between affiliated domains:
... * No storage parititning
... * No cache partitioning
... * not considered cross-site requests
... * Something else I missed
... Strawman proposal:
... JSON file in a well-known location.

<tlr> I saw something about skipping pre-flights for CORS

JohnWilander: { data: { domain: "icloud.com", ownedBy: "apple.com", validUntil: "..." }, hashOfData: { sha256: "..." } }
... (on `icloud.com`)
... On `apple.com`:

<tlr> also, "not considered cross-site tracking" a little earlier

JohnWilander: { data: { domain: "apple.com", "ownedBy": "self", "owns": [ "icloud.com", ... ] }
... (missed most of that, sorry)
... Requires TLS.
... No credentials.
... No subdomains, public suffix +1
... Only owned by itself or one other domain
... Something else I missed. I need to type faster.
... A domain can only make statements about itself.
... There's an upper limit on the number of owned domains supported.
... Statement is only valid if bidirectional (A is owned by B, B owns A)
... Disregard whole file if inconsistent between A and B.
... Not allowed to serve different files to different user agents.

ArturJanc: Why?

JohnWilander: Would otherwise create another tracking vector.
... This all goes back to SOP.
... "Same origin" / "different origin"
... Suborigins are about security guarantees.
... Affiliated domains is more about privacy.
... How?
... * JSON?
... * Cert extentions?
... * Scalability?
... * Cacheability?

<scribe> ... * New tracking vector?

jeffh: How would this enable tracking?

JohnWilander: Cache. If you can keep this cached for 2 years, and carve out domains just for you, then make requests.

jeffh: Web isn't stateless on the client side anymore. Not sure you can do much about cache.

tbl: Would this be regulated somehow? would someone go to jail if they claim ownership that doesn't match reality? What if they don't claim ownership that exists?

JohnWilander: I'm not a lawyer.
... I could forsee that someone passed some law somewhere?
... I'm sure there's a way to game this by creating a consortium that virtually "owns" lots of domains.
... Mitigting that by forcing one root owner and imposing limits on the number of domains associated.

dveditz: Does the root owner get special abilities?

Johnwilander: Not as compared to the others. They're treated as a set.

dveditz: Facebook and Google could collaborate.

tlr: So a set is created by expending one domain, and then everyone claims that that domain owns it?

JohnWilander: Yes.

Patrick: If we allow for caching, how do you handle rejection?

<tlr> (and all of the authorizations apply peer-to-peer within that network)

Patrick: Hijack a domain for a day, cached for some period of time.

JohnWilander: Could always go to the main document's file and request that.

Patrick: Cache poisoning seems dangerous in this case.

JohnWilander: Not dangerous, just dropping partitioning.

tanvi: you're relaxing SOP when it comes to storage on the client side?

JohnWilander: No, not weakening SOP, just not partitioning.

battre: I'm interested in this from the passwords perspective. `amazon.*` interlink to share passwords.
... Should we bridge to app space as well?

JohnWilander: there are technologies for that.

battre: why aren't they the same technologies?

mkwst: Other use cases?

JohnWilander: Maybe relaxing CORS, dropping preflights?
... Just giving browsers more data about ownership so they can make decisions.

jeffh: You can do this. There are examples of these magic files out there on the web.
... Google's doing this, based on FIDO's facet list mechanisms.
... The thing you're going after here is "ownership": domain of administrative authority.
... It's wider than browsers and HTTP.
... email, DKIM, DMRK.
... There has been work on this. It's been easy to kick the can down the road.
... DBOUND in IETF.
... Browser vendors weren't in the room.
... Are IDs, is a problem statement.
... I sent them to the mailing list today.
... There's a particular proposal around doing this in the DNS. (Andrew Sullivan and jeffh)
... Similar mechanism.
... Doing things in DNS takes a long time.
... You could do this, perhaps that would trigger DNS to stop kicking the can down the road.
... It would be nice to do it the right way from the beginning, and I argue that the right way is in the DNS.
... If you can't, do it with the understanding that there's a higher-level problem space and that it interconnects with this problem.
... Try not to paint yourself into a corner that makes it harder than it already is to do this in DNS.
... I'd encourage you to read the problem statement.

JohnWilander: We talked about this 2 years ago in this group. I expect it'll happen again in 2 more years if we take that route.

<weiler> https://tools.ietf.org/html/draft-sullivan-domain-policy-authority-02

jeffh: The problem still exists. You talking about it seems to suggest that the problem is becoming more important.

JohnWilander: If we did this as a transition, would it help the DNS discussions?

jeffh: Maybe there wouldn't be an issue? But you should be aware of the longer-term goals, and try not to inadvertantly screw things up.
... Also, the facet ID in FIDO (similar to Google's digital asset list)
... Google's baked into Chrome the fact that `google.*` are affiliated.
... Already identity federation protocols, shouldn't try to solve the federation problem with digital asset list approach. Those arguments still hold.
... Lots of nuance to federation.
... I don't remember all the arguments offhand, but multiple standardized ways to do this for the time being.
... An issue with this is that changing data in DNS is separate from these JSON files.
... Changing one without changing the other leads to confusion.

jochen___: Every time we try to do something via DNS, the network team throws their hands up.
... Middleboxes, etc.

jeffh: Working on ways around that.
... DOH, DNS over TLS.
... Middleboxes are a real problem.

Angelo: Seems like this belongs to a broader context. Needs to be in Web Platform WG, not WebAppSec.

Single Trust.

JohnWilander: Allowing sites to say that a page is all from one owner.
... Safari shows the org name if you have an EV cert rather than the URL.
... "Shouldn't it only be that org? Shouldn't we not mix origins/owners then?"
... Consider login.
... Want to ensure that you're only talking to the org to which you're authenticating.
... Same for doctors. you want to describe symptoms only to your healthcare provider.
... Same for securedrop on news sites, signup forms, etc.
... * Autofill
... * Credential Management API
... * Sticky permissions for sensitive APIs.
... * Future things like medical info, account recovery.
... If we had affiliated domains worked out, we could know that these 8 domain names are all the same owner, so call the mix "single trust"

<jeffh> mkwst: thinks there are cases where single-trust makes sense. for credman might want to deal with identity provider in a frame but that would not work in this situaiton

<jeffh> ... have to carefully define what works in single-trust context and what doesn't

<jeffh> dveditz: would this even work on the web where sites pull in all sorts of libs and everything

ArturJanc: What's the probem with your hospital page loading an image from some other origin? Not active content?

JohnWilander: comes down to simplicity.
... Can't be gamed if no content from other organizations.

ArturJanc: Hospital could send data server-to-server?

JohnWilander: That's your hospital colluding.
... Incurs liabiity.

ArturJanc: If I'm willing to take user data into my ownership, and send it to an iframe, wouldn't I be willing to send it server-side?
... Not a lot of faith that restricting this in a way that's visible to users would be helpful.

John: Could give users a false sense of trust.
... Just one origin on the frontend, could imply to the user that the data won't go somewhere else, but no real restriction.

JohnWilander: Not how I interact with an org.
... Feels better if there's just one org in the room with me.

John: I wouldn't trust equifax, even if they're single trust.

tbl: Regulations. Could imagine EU imposing additional restrictions upon single trust sites.

tlr: I think we're trying to overload a specific policy solution on a technical measure.
... Orgs structure themselves into legal structures.
... Delegate things, build controls.
... Implement pieces of their sites well, pieces badly.
... Feels like technical limitations like CSP are valuable, doesn't feel like single trust addresses the use cases.

JohnWilander: I see this as a CSP directive.
... I'm taking away that we'd be the only ones to implement Storage Access API .

<bhill2> would rather StorageAccess API than not

JohnWilander: Will meet in two years about affiliated origins.

jeffh: I'd +1 the note that ITP encourages perverse incentives.

JohnWilander: If we're the only ones interested in this API, it seems like we should just implement it.
... Other vendors have 3rd-party-cookie blocking, wouldn't you want to support something like this?

jochen___: Chrome has UI that works pretty well.

Dev: Can you give sites a little more detail about why a rejection happens? Why no cookies exist?
... We'd like to know why we don't have cookies so that we know whether we should ask for this permission.

wseltzer: I think it's valuable to have this discussion.
... There's diversity in the platform.
... We can ask whether some of these pieces are more trouble than they're worth, but also help developers manage the platform, make features make sense to developers and users.

<wseltzer> scribenick: wseltzer

embedded enforcement

mkwst: embedder enforces a policy on the embedee, embedee must agreee
... exploring a policy internally with ads team
... they want to get some more restrictions

<jeffh> https://w3c.github.io/webappsec-csp/embedded/

mkwst: to make sure ads are only loading resources they said they'd load
... enforcing contractual relationships technically
... ensuring that resources are loaded from trusted origins
... fewer active users than I'd like
... please take a look at the spec; I'd like to close out open issues, move to CR
... call for implementation, get more experience with mechanism and its uses

Clear-Site-Data

mkwst: clear site data aims to allow websites to reset state associated with user
... you can already clear coookies if you know their names,
... but some situations can get you into bad state, service workers, if your server is compromised
... clear-site-data gives a reset
... shipped in chrome 60 or 61
... and ran into problems with people using header wrong
... so reverted
... e.g., authors were using clear-site-data on every resource
... fixing to execute only one at a time, serially
... feedback that the initial pass is not granular enough
... buckets, like all cookies, too large
... folks would like to clear with more granularity
... e.g. Dev saying Dropbox wants to clear all but one cookie
... I'd like to get feedback
... e.g., some Google folks want "everything that matches a regex"

Patrick: what comes first?

mkwst: setting comes first, then clearing
... the reason we did that, clearing takes a long time
... maybe invert
... 2 initial use cases: kill switch on origing; clearing data on logout
... explicit logout should clear state
... Github using it today.
... Photos will use on logout.

Angelo: cookies + ?

mkwst: cookies, indexdb, local storage
... figuring out logical chunks is a challenge
... a set of things exposed to the web
... but what about other things, HSTS, cache, internal to browser?
... we don't clear user settings

dveditz: any thought how it interacts with suborigins?

mkwst: clear them all
... we wouldn't expect to change settings page to have multiple listings

devd: suborigin could clear site data for suborigin

mkwst: don't feel strongly

tlr: keep in mind the use case of suborigins for partitioning

ArturJanc: backwards compatibility among browsers with different implementations?

jochen___: timeout for storage, expiration

mkwst: for embedded enforcement, my next step is to clean up the spec, send back to list
... then try to move to CR when you're happy
... Clear site data, let's see whether the buckets we have ar the granularity we want
... question whether we can address some by inverting csd and set-cookie

Requiring tests for spec changes

<foolip> https://foolip.github.io/ecosystem-infra-stats/testpolicy.html is the thing

foolip: groups trying to make testing a part of specification work
... keep tests synchronized to spec
... improve the feedback loop
... when you're making normative change to the spec, make sure the tests are updated
... or at least file an issue to make sure the tests will be updated
... graph, https://foolip.github.io/ecosystem-infra-stats/testpolicy.html
... we're past 50% of specs with tests
... if there are things that make webappsec tests hard, let us know

jochen___: clear site data is hard to test
... hard to see user gestures

<foolip> http://web-platform-tests.org/writing-tests/testdriver.html just landed

jochen___: in general, what's the plan for specs that depends on interaction

foolip: for clicking things, test talks to webdriver
... other instances where we have to mock input

jochen___: challenge where we need to test broken traffic

plh: we can generate broken traffic on wpt server

jochen___: difficult to record network traffic, e.g. for referrer policy

plh: file a bug on web platform tests, attention james graham

jochen___: I wrote a few thousand tests; it's hard

johnwilander: it's been hard to come up with tests that rely on domain names

mkwst: I've had a bug against wpt for things that aren't eTLD+1

foolip: yes, there's only 1 eTLD
... on the roadmap

johnwilander: also important to get real certificates

mkwst: for chrome in testing mode, we can tell it to ignore cert errors

johnwilander: trust stack below us, then it ignores HSTS

foolip: would it be fine to buy some domains, check in certs from letsencrypt?

johnwilander: yes

jeffh: cert testing sites out there, e.g. badssl
... offer up bad certs

mkwst: firefox has own root store
... if you use wpt-run, they will mint certs for wpt tests and add to root store
... you could imagine similar addition to keychain
... .test tld, running locally

johnwilander: testing HSTS preload list
... need something that's trusted

mkwst: HSTS preload may be a special case
... some things are difficult, but most things are possible to test
... we've generally been ok weighing the justifications
... and for most things WPT is useful infrastructure
... useful for discussions with other browsers: here's a tentative test for how we think the feature should work
... that said, it's only useful after a certain point
... too early, when you're rapidly iterating, you may not want to force tests
... requiring for things the group adopts seems reasonable

foolip: not "test driven development" because test isn't primary
... whatever order works for you

jochen___: how do we track the tentative tests that eventually should be merged?

mkwst: naming convention, .tentative

foolip: as soon as there's one implementation, you should have tests

mkwst: if you're implementing and writing tests, put them into WPT

foolip: how do we document this?

mkwst: we could say we won't accept patches without tests

plh: put it into your contributing.md

<scribe> ACTION: PLH to update contributing.md

<trackbot> Error finding 'PLH'. You can review and register nicknames at <http://www.w3.org/2011/webappsec/track/users>.

[adjourned, see you tomorrow]

s/11: 06 ...: over the last year we've spent time using CSP3 features and can give feedback on what's useful and what's not//

- DRAFT -

WebAppSec TPAC F2F, day 1

06 Nov 2017

Attendees

Contents