[whatwg] Proposal: location.parentOrigin
w3c at adambarth.com
Tue Apr 3 16:04:25 PDT 2012
Talking with some folks off-list, there are also use cases for knowing
the origin of the top-most document. Rather than introduce topOrigin,
we might be better off with alternative (1) below, making
location.origin visible to descendant frames.
On Mon, Mar 26, 2012 at 5:09 PM, Adam Barth <w3c at adambarth.com> wrote:
> == Proposal ==
> For nested browsing contexts, expose the origin of the parent browsing
> context via location.parentOrigin. (For non-nested browsing context,
> the property would null.)
> == Use Case ==
> Some widgets want to behave differently depending on the context in
> which they are embedded. For example, a payment widget might want to
> send the user to a confirmation page for most web sites but might be
> confortable with a more streamlined user experience when embedded on a
> whitelist of sites with which they have a contractual relationship.
> Note: There is also some connection with the use cases for
> X-Frame-Options and frame-ancestors. Those mechanisms address uses
> cases where document do not wish to be displayed in unfriendly
> contexts at all. This mechanism addresses use cases where widgets
> wish to always be displayed but wish to behave differently in
> different contexts.
> == Alternative ==
> 1) We could make location.origin visible to across origins to child
> frames. This approach is somewhat more aesthetic and also lets a
> document query the origin of all of its containing browsing contexts.
> However, we don't want to expose location.origin in general because
> that could let an attacker learn about where redirects lead by
> creating an iframe and reading back it's location.origin. Exposing
> location.origin to child frames only mitigates this issue but would
> require a somewhat tricky ad-hoc security check. For that reason, it
> seems better to expose the origin of the parent on the child's
> location object directly, where the property would have a normal
> security check.
> 2) The widget provider could use a different URL for the two different
> versions of the widget. The widget with the streamlined experience
> would then use X-Frame-Options to prevent itself from being displayed
> in hostile environments. There are a couple of disadvantages to this
> a) X-Frame-Options (and frame-ancestors) require the widget to
> declare upfront the contexts in which it is willing to be embedded.
> For a payment widget that might be used by many hundreds or thousands
> of web sites, that's somewhat impractical.
> b) Each complication in the instructions for embedding the widget is
> costly to the widget provider because fewer developers will use the
> widget. For example, the widget provider might want to make it
> extremely easy to embed the contract-free version of the widget and
> then make the sales process for the streamlined use experience not
> require any technical changes on the part of the embedder.
> 3) The widget could use postMessage to communicate with the embedder
> and to establish the origin of the embedder. However, this requires
> running code in the embedder that knows how to respond to the messages
> appropriately. If the widget provider supplies the code, then the
> embedder needs to trust the widget provider to run code in its origin,
> which is undesirable. If the embedder provides the code, then that
> greatly increases the complexity of embedding the widget (see 2(b) for
> a related discussion).
> == Risks ==
> There is some risk that exposing this information might leak
> information from the parent to the child iframe. For example, if the
> parent document's origin (e.g., it's host name) contains sensitive
> information, that information might be leaked to documents it chooses
> to display in frames. While possible, this risk seems fairly remote.
More information about the whatwg