Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TPAC 2019 Agenda. #555

Open
mikewest opened this issue Aug 22, 2019 · 14 comments

Comments

@mikewest
Copy link
Member

commented Aug 22, 2019

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


@annevk

This comment has been minimized.

Copy link
Member

commented Aug 23, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Aug 23, 2019

@annevk: Added those in, thank you!

@deian

This comment has been minimized.

Copy link
Member

commented Aug 23, 2019

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

@Malvoz

This comment has been minimized.

Copy link

commented Aug 25, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Aug 27, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2019

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

@johnwilander

This comment has been minimized.

Copy link

commented Aug 27, 2019

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

@wjmaclean

This comment has been minimized.

Copy link

commented Sep 9, 2019

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

This comment has been minimized.

Copy link

commented Sep 9, 2019

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

This comment has been minimized.

Copy link

commented Sep 10, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

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

@clelland clelland referenced this issue Sep 11, 2019
3 of 5 tasks complete
@arturjanc

This comment has been minimized.

Copy link

commented Sep 12, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 12, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.