[whatwg] Proposal: location.parentOrigin

[Adam Barth]

== 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