W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

[webappsec] Topics for Rechartering

From: Brad Hill <hillbrad@gmail.com>
Date: Sun, 19 Oct 2014 13:12:29 -0700
Message-ID: <CAEeYn8j81aOra8doNU8U0w91EPwcX6ME9zrn7DmuzjHTumEcgA@mail.gmail.com>
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

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.


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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:41 UTC