TPAC 2019 Agenda.

[mikewest]

Suggestions or thoughts about topics we should discuss at TPAC? This would be a lovely place to put them.

---

• Old Things
  • For the third year in a row, how do we get Referrer Policy, Secure Contexts, Mixed Content, and Upgrade Insecure Requests to REC?
  • Ditto for Clear-Site-Data, Credential Management.
  • What are we doing with Content Security Policy and Embedded Enforcement
  • ...
• Less-old Things
  • Fetch Metadata
  • Origin Policy
  • CORS-RFC1918
  • Feature/Document/* Policy (@clelland?)
    • Cookie Controls
  • CORP/COEP/COOP + 👻 Spectre 👻
  • ...
• New Things
  • Trusted Types update. Adopt into the WG? (@koto)
  • HTTP State Tokens
  • Mixed Content 2 (@estark37)
  • IsLoggedIn API (@johnwilander)
  • CSP Next?
  • Double-keyed (or more) caches
  • Protecting/sandboxing <iframe> sites (history.length, caches, window[i])
  • Sec-Origin (@deian)
  • ...
• Process Things
  • Charter still reasonable?
    • Putting privacy more clearly in scope and make browser privacy policies part of the security review process
  • Evergreen standards?
  • Relationship with other groups (TAG, PING, HTTPbis, etc.)
  • Security reviews of upcoming features.
  • Various browsers' launch processes

[annevk]

Ideas:

• Double-keyed (or more) caches
• Protecting/sandboxing <iframe> sites (history.length, caches, window[i])
• Putting privacy more clearly in scope and make browser privacy policies part of the security review process

[mikewest]

@annevk: Added those in, thank you!

[deian]

Is there enough time to briefly chat about a new Sec-Origin header we've been working on?

[Malvoz]

Too early to talk about First-Party Sets?

Feature/Document/* Policy

I'm not sure how detailed discussions get at TPAC, but I'd like to highlight Cookie control, if I may.

Protecting/sandboxing <iframe> sites (history.length, caches, window[i])

As a developer I find sandboxing difficult. Either I'll restrict essential features due to lack of documentation from service providers, or take the safe route and restrict a very minimal set of features (or not use sandbox at all). Document-Policy might make things easier, but ultimately I think code distributors need a motivator to provide documentation on which features can be safely restricted without breaking the frame.

[mikewest]

@deian:

Is there enough time to briefly chat about a new Sec-Origin header we've been working on?

Added it to the list. Will you be attending in person, or do we need to find a California-friendly time for you to dial in? Also, is there an explainer document we could link to so folks are up to speed on the proposal when we discuss it?

@Malvoz:

I'm not sure how detailed discussions get at TPAC, but I'd like to highlight Cookie control, if I may.

Added.

As a developer I find sandboxing difficult.

I think it's generally the case that a frame-to-be-sandboxed needs to cooperate with its sandboxer if breakage is to be avoided. Just applying unexpected restrictions is unlikely to be effective, as you note. What do you think this group can do to improve that situation? Where would you like the conversation at TPAC to focus?

[terriko]

I'm interested in CSP Next and also in the security reviews for other W3C projects/features, but I won't be at TPAC. California-friendly times would cover me, and I'll likely be able to shift my schedule later to get more overlap.

[hillbrad]

@johnwilander is there a pre-read for Login API?

[johnwilander]

@hillbrad, not yet. I hope to publish an explainer of some sort.

[wjmaclean]

Can we discuss an Origin Policy for opting in to Origin Isolation? We will have an explainer we can share before the end of this week.

[clelland]

Re: #555 (comment), there have been a number of different proposals for isolating documents from each other -- this proposal with origin policy, a couple of different feature policy features, 'domain' in sandbox, and probably a couple of other ideas around agent cluster isolation. I don't think it's spefically within the charter, but is a general discussion around that problems space in scope for this group?

[cyberphone]

Web2App access is a popular topic outside of the W3C:
https://lists.w3.org/Archives/Public/public-payments-wg/2019Sep/0000.html
People do all sorts of tricks to circumvent the limits of the Web. Why not give them something that has a blessing? URL Handlers doesn't really cut it and Web extensions like featured in Chrome (desktop only) are downright horrible since they potentially open open any site for DOM access.

[yoavweiss]

As part of the FeaturePolicy discussion, would also be great to talk about support for markup based FP declaration.

[arturjanc]

The agenda seems pretty full by now, but it could be interesting to spend a few minutes talking about how we could make the platform safe (or, safer) by default for new applications.

That is, now that we have mostly coherent proposals for preventing injections (CSP3/Next + Trusted Types) and locking down cross-origin interactions (COOP, CORP, Fetch Metadata), and we're making progress on Origin Policy, could we bundle them together with a simple origin-wide opt-in? If so, can we even go a step further and enable this by default in some cases? (learning from the successes & mistakes of the HSTS preload list)

[annevk]

I noticed September 17 clashes with Web Components. Not really sure how to deal with that, but maybe leave some stuff for September 19?

[hober]

I imagine this issue can be closed now. Is there any plan for WebAppSec to meet at TPAC 2020? I don't see the group listed on the group schedule page.