- From: Joel Weinberger <jww@chromium.org>
- Date: Wed, 11 Sep 2013 16:21:14 -0700
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAHQV2KkuszYSNJHG3Td0YS7tQZQtjqwhvoH2983G__GnELG-_Q@mail.gmail.com>
Hi everyone. In our earlier thread, it seemed to me that we were converging to an agreement that serialized suborigins are probably the best approach to make sure suborigins fail closed. Of course, what that serialization should look like is what really seems to be up in the air right now. After talking with Adam Barth, we both agree that Brad's hashing proposal has a lot of great advantages. Of course, as Michal pointed out, it also isn't particularly developer friendly. Here's a quick set of suggestions that Adam and worked out that I think eases some of the concerns. We propose that we represent serialized suborigins as follows: suborigin://HASH:PORT where the suborigin is a protocol literal, PORT is a standard origin port, and HASH is a hashed combination of the host name and suborigin string. Obviously, this is basically Brad's proposal, although we thought it was important to make sure to keep a protocol and port in the representation. Furthermore, we propose for a number of built-in functions to take care of suborigins for the developer. The goal is basically that a developer should never see (and certainly never write) a HASH value. The main API that comes to mind is: location.suborigin(name, [domain]) which returns a suborigin HASH value for the suborigin named by name. If no domain is specified, returns the value for the current domain, otherwise calculates it for the named domain. This way, a developer never has to see or calculate these in client. When checking one, it should be as simple as: if (e.origin == location.suborigin("foo", "some.domain")) { ... } Of course, there are a variety of ways to go from here. Adam pointed out that this actually has the interesting property that if you receive a message from a suborigin, and the suborigin doesn't name itself, you can't know a priori who sent the message. We could consider this a "good thing," but if we don't, we could always keep track of generated suborigin HASH values in browser and provide an API call location.lookupSuborigin(suborigin) which takes a suborigin value, looks it up in browser, and returns a (domain, suborigin_name) pair. In terms of the actual suborigin value, we define it as SHA256 Like I said, I like Brad's suggestion a lot, so I tried to write up a slightly more formal version here. Thoughts? --Joel
Received on Wednesday, 11 September 2013 23:21:41 UTC