- From: Adam Barth <w3c@adambarth.com>
- Date: Tue, 3 Apr 2012 16:04:25 -0700
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
Received on Tuesday, 3 April 2012 16:04:25 UTC