[whatwg] Proposal: location.parentOrigin

[Adam Barth]

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.

Adam


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
> alternative:
>
>  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.
>
> Adam