- From: Brad Hill <hillbrad@gmail.com>
- Date: Sun, 19 Oct 2014 13:12:29 -0700
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Reminder: Our group is operating under a short-term charter extension and we need to work on a new charter at TPAC. Below are some ideas on what the group might work on in the next year or two. I've tried to keep running notes for the last few months as our recharter approached, and this is what I have. Apologies if I missed your contribution - I'd love for you to reply and add it here if I did. I'll put together a poll somewhere shortly where folks can vote on what they're interested in, but feel free to use the list in the meantime to encourage or disapprove, or most importantly, to volunteer if you'd like to be an editor, implementer or test coordinator for one of these ideas. -Brad --------------------- 1) Credential management API, write-only DOM elements and the draft specifications Mike West has posted here for comment and review. 2) Revive a formal spec for the Content-type: No-Sniff feature and publish it here. (previous efforts at IETF failed, but this is about browser behavior and I think it is reasonable for this group to work on) 3) Specify better how Service Workers and CSP interact 4) Joel Weinberger's Sub-origins proposal, previously discussed on this list. 5) Return additional cookie data to servers: Servers might want to know if a cookie with httpOnly was set by JS or if a secure cookie was set insecurely 6) Block loading of insecure content in child browsing contexts - so if you load an ad in an iframe and it tries to load insecure content, it doesn't bust your green lock 7) Web Components security model? 8) Something resembling a Cross-Origin+Sandboxed Worker. An alternative to <script src="remotehost.com"> that lives in an isolated world with no DOM but has structured APIs to interact with the containing page. Web Components were motivated by the overhead of loading into an iframe. It's not sustainable to have 20 or 30 nested browsing contexts, especially in a multi-process model. But an isolated JS runtime is much lighter-weight (no DOM, no renderer). Can we support the models people want with script includes in a more secure fashion? Maybe we can support legacy JSONP in a secure way with this, too. 9) Even richer Cross-Origin Worker APIs, e.g. allowing persistent Shared and Service workers to communicate x-origin. 10) Better authentication APIs? WebCrypto Next Steps workshop results - does any of what people wanted belong in this group?
Received on Sunday, 19 October 2014 20:12:57 UTC