Re: [whatwg] Proposal: location.parentOrigin
On Tuesday, July 16, 2013 at 7:53 PM, Ian Hickson wrote: Can't you do window.isSameOrigin by just trying to access window.location.href and seeing if you get an exception? Unfortunately not, because of the previously mentioned WebKit bug which logs an error message but doesn't throw (so there's no way of knowing whether an exception was thrown or not). --tobie
Re: [whatwg] Proposal: location.parentOrigin
On Wed, 17 Jul 2013, Tobie Langel wrote: On Tuesday, July 16, 2013 at 7:53 PM, Ian Hickson wrote: Can't you do window.isSameOrigin by just trying to access window.location.href and seeing if you get an exception? Unfortunately not, because of the previously mentioned WebKit bug which logs an error message but doesn't throw (so there's no way of knowing whether an exception was thrown or not). We can trivially change that, if that's the only problem. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
On Tue, Jul 16, 2013 at 4:14 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 17 Jul 2013, Tobie Langel wrote: On Wednesday, July 17, 2013 at 12:42 AM, Ian Hickson wrote: On Wed, 17 Jul 2013, Tobie Langel wrote: On Tuesday, July 16, 2013 at 7:53 PM, Ian Hickson wrote: Can't you do window.isSameOrigin by just trying to access window.location.href and seeing if you get an exception? Unfortunately not, because of the previously mentioned WebKit bug which logs an error message but doesn't throw (so there's no way of knowing whether an exception was thrown or not). We can trivially change that, if that's the only problem. Fixing that bug would be a great step forward. Adam? We're in the process of changing that now. You can follow our progress on this bug: https://code.google.com/p/chromium/issues/detail?id=17325 Adam
Re: [whatwg] Proposal: location.parentOrigin
On Tue, Nov 20, 2012 at 6:47 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 26 Mar 2012, Adam Barth wrote: For nested browsing contexts, expose the origin of the parent browsing context via location.parentOrigin. (For non-nested browsing context, the property would null.) This ended up implemented in WebKit as Location.ancestorOrigins(), a method that returns a static DOMStringList with the origins of the ancestor browsing contexts in reverse order (top-level browsing context last, parent browsing context first). It doesn't respect sandboxing. This API is painful to use and doesn't contain any info for window.opener or sibling browsing contexts (see WebKit bug[1] and related discussion on G+[2]) which makes it useless for some of the use cases. A better API would allow to get the origin of a referenced browsing context, e.g.: window.getOrigin(otherWindow); and to check whether it came from the same origin (sugar around window.getOrigin(otherWindow) == window.getOrigin(window)): window.isSameOrigin(otherWindow); That said, one of the key use cases for this API is to code around a Webkit bug[3] so maybe that should be fixed first. --tobie --- [1]: https://bugs.webkit.org/show_bug.cgi?id=83493 [2]: https://plus.google.com/116910304844117268718/posts/QyHfGL9GBd5 [3]: https://bugs.webkit.org/show_bug.cgi?id=43504
Re: [whatwg] Proposal: location.parentOrigin
On Mon, 26 Mar 2012, Adam Barth wrote: For nested browsing contexts, expose the origin of the parent browsing context via location.parentOrigin. (For non-nested browsing context, the property would null.) This ended up implemented in WebKit as Location.ancestorOrigins(), a method that returns a static DOMStringList with the origins of the ancestor browsing contexts in reverse order (top-level browsing context last, parent browsing context first). It doesn't respect sandboxing. Are other browser vendors interested in implementing this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
On Wed, 4 Apr 2012, Michal Zalewski wrote:
In fact, in the vein of opt-in disclosure perhaps something like
discloselocation={none|origin|full} would be more convenient - in which
case, you get something like
window.parentLocations[n].{origin|href|hash|...}
I constantly fear that origin scoping for security mechanisms is too
coarse-grained in many use cases, because the complexity of what lives
in any single origin is growing pretty rapidly. Sites put
attacker-controlled content inside framed gadgets or advertisements, and
can't be reasonably expected to understand that if such a frame is
navigated to in a particular way, it may circumvent an origin-scoped
check.
Tab suggests (on IRC) that this should just be tied to sandbox=, which
seems reasonable at first blush.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
Tab suggests (on IRC) that this should just be tied to sandbox=, which seems reasonable at first blush. Sandbox is opt-in (which means we'd start revealing origins in existing settings without a warning); and has other serious constraints which preclude it from some existing use cases (e.g., no plugins). /mz
Re: [whatwg] Proposal: location.parentOrigin
My sense is that's an acceptable risk given that this information commonly leaks in document.referrer anyway. Using sandbox sounds like a worthwhile backstop though. Adam
Re: [whatwg] Proposal: location.parentOrigin
On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) The use case is the same as in the previous email, specifically: ---8--- 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. ---8--- The payment widget might care about all of its ancestors. For example, suppose the payment operator has a relationship with store.example.com. They might wish to fall back to using a confirmation page if store.example.com is embedded as a frame in another web site (e.g., pintrest). Why don't they just ask the parent frame for their parent's origin, since they trust them? From my original email: ---8--- 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). ---8--- (This is what I get for jumping in a thread half-way rather than doing my usual wait til the end and read everything then reply to everything...) So is there any concern that there might be a hostile origin between a trusted top-level origin and a trusted parent origin? Top-level browsing context: victim-of-injection.example.org Contains: evil.invalid Contains: victim-host-of-victim-of-clickjacking.example.net Contains: victim-of-clickjacking.example.com Should we just expose the chain of ancestor origins in an array? My concern with exposing parent.location.origin to cross-origin frames based not on an origin check but on a are you contained test is that it is hard to define exactly who is allowed to access the member. For example, what if the entry script is actually in another window, but it calls a method in the iframe, and that method tries to walk the chain? Does it fail? What if the iframe calls a method on the window, and the window then tries to walk the chain? What if the window walks the chain without calling a method in the iframe? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
On Wed, Apr 4, 2012 at 11:06 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) The use case is the same as in the previous email, specifically: ---8--- 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. ---8--- The payment widget might care about all of its ancestors. For example, suppose the payment operator has a relationship with store.example.com. They might wish to fall back to using a confirmation page if store.example.com is embedded as a frame in another web site (e.g., pintrest). Why don't they just ask the parent frame for their parent's origin, since they trust them? From my original email: ---8--- 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). ---8--- (This is what I get for jumping in a thread half-way rather than doing my usual wait til the end and read everything then reply to everything...) So is there any concern that there might be a hostile origin between a trusted top-level origin and a trusted parent origin? Top-level browsing context: victim-of-injection.example.org Contains: evil.invalid Contains: victim-host-of-victim-of-clickjacking.example.net Contains: victim-of-clickjacking.example.com Should we just expose the chain of ancestor origins in an array? That could work. Using an array might be a good way to encourage developers to check all the ancestors rather than arbitrarily picking the parent or the top. My concern with exposing parent.location.origin to cross-origin frames based not on an origin check but on a are you contained test is that it is hard to define exactly who is allowed to access the member. For example, what if the entry script is actually in another window, but it calls a method in the iframe, and that method tries to walk the chain? Does it fail? What if the iframe calls a method on the window, and the window then tries to walk the chain? What if the window walks the chain without calling a method in the iframe? When doing access checks, browsers already need to pin down exactly which script is performing the access. The spec doesn't get 100% of these details correct, but normally the differences aren't observable. You can actually observe the difference if you plan a bunch of nutty tricks with document.domain, but I can send an email about these details later. To answer your question, I would do the access check based on the document associated with the current script, which is the document that contained the definition of the most recently executing user-defined closure. This is the security context most often used for security checks (even though the entry script is commonly used for things like relative URL resolution). However, I think you're right that exposing an array is a better approach to nudge developers into writing robust code. Adam
Re: [whatwg] Proposal: location.parentOrigin
On Wed, Apr 4, 2012 at 11:20 AM, Adam Barth w...@adambarth.com wrote: On Wed, Apr 4, 2012 at 11:06 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) The use case is the same as in the previous email, specifically: ---8--- 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. ---8--- The payment widget might care about all of its ancestors. For example, suppose the payment operator has a relationship with store.example.com. They might wish to fall back to using a confirmation page if store.example.com is embedded as a frame in another web site (e.g., pintrest). Why don't they just ask the parent frame for their parent's origin, since they trust them? From my original email: ---8--- 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). ---8--- (This is what I get for jumping in a thread half-way rather than doing my usual wait til the end and read everything then reply to everything...) So is there any concern that there might be a hostile origin between a trusted top-level origin and a trusted parent origin? Top-level browsing context: victim-of-injection.example.org Contains: evil.invalid Contains: victim-host-of-victim-of-clickjacking.example.net Contains: victim-of-clickjacking.example.com Should we just expose the chain of ancestor origins in an array? That could work. Using an array might be a good way to encourage developers to check all the ancestors rather than arbitrarily picking the parent or the top. My concern with exposing parent.location.origin to cross-origin frames based not on an origin check but on a are you contained test is that it is hard to define exactly who is allowed to access the member. For example, what if the entry script is actually in another window, but it calls a method in the iframe, and that method tries to walk the chain? Does it fail? What if the iframe calls a method on the window, and the window then tries to walk the chain? What if the window walks the chain without calling a method in the iframe? When doing access checks, browsers already need to pin down exactly which script is performing the access. The spec doesn't get 100% of these details correct, but normally the differences aren't observable. You can actually observe the difference if you plan a bunch of nutty tricks with document.domain, but I can send an email about these details later. To answer your question, I would do the access check based on the document associated with the current script, which is the document that contained the definition of the most recently executing user-defined closure. This is the security context most often used for security checks (even though the entry script is commonly used for things like relative URL resolution). However, I think you're right that exposing an array is a better approach to nudge developers into writing robust code. I should note that WebKit already implements location.origin (and HTMLAnchorElement.origin), which returns the Unicode serialization of the URL's origin. If we go with the array approach, we might want to add the plain origin property to the spec as well (with the normal security rules). Adam
Re: [whatwg] Proposal: location.parentOrigin
On Wed, Apr 4, 2012 at 11:20 AM, Adam Barth w...@adambarth.com wrote: On Wed, Apr 4, 2012 at 11:06 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) The use case is the same as in the previous email, specifically: ---8--- 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. ---8--- The payment widget might care about all of its ancestors. For example, suppose the payment operator has a relationship with store.example.com. They might wish to fall back to using a confirmation page if store.example.com is embedded as a frame in another web site (e.g., pintrest). Why don't they just ask the parent frame for their parent's origin, since they trust them? From my original email: ---8--- 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). ---8--- (This is what I get for jumping in a thread half-way rather than doing my usual wait til the end and read everything then reply to everything...) So is there any concern that there might be a hostile origin between a trusted top-level origin and a trusted parent origin? Top-level browsing context: victim-of-injection.example.org Contains: evil.invalid Contains: victim-host-of-victim-of-clickjacking.example.net Contains: victim-of-clickjacking.example.com Should we just expose the chain of ancestor origins in an array? That could work. Using an array might be a good way to encourage developers to check all the ancestors rather than arbitrarily picking the parent or the top. My concern with exposing parent.location.origin to cross-origin frames based not on an origin check but on a are you contained test is that it is hard to define exactly who is allowed to access the member. For example, what if the entry script is actually in another window, but it calls a method in the iframe, and that method tries to walk the chain? Does it fail? What if the iframe calls a method on the window, and the window then tries to walk the chain? What if the window walks the chain without calling a method in the iframe? When doing access checks, browsers already need to pin down exactly which script is performing the access. The spec doesn't get 100% of these details correct, but normally the differences aren't observable. You can actually observe the difference if you plan a bunch of nutty tricks with document.domain, but I can send an email about these details later. To answer your question, I would do the access check based on the document associated with the current script, which is the document that contained the definition of the most recently executing user-defined closure. This is the security context most often used for security checks (even though the entry script is commonly used for things like relative URL resolution). However, I think you're right that exposing an array is a better approach to nudge developers into writing robust code. Yup, exposing the whole chain seems like the right solution to me. Saying that there can't be evil content sandwiched between trusted ones seems optimistic to me and is bound to be proven wrong. This also makes us line up with the CORS Origin header which sends the origins of the whole redirect chain, and there are definitely similarities between HTML framing and HTTP redirecting. / Jonas
Re: [whatwg] Proposal: location.parentOrigin
I can think of some fringe scenarios where disclosing parent origins may be somewhat undesirable. One example may be a double-bagged advertisement, where the intent is to not tell the advertiser about the top-level page the ad is embedded on (visited site - iframe pointing to the ad provider site - iframe with embedded advertiser content). Not sure if there's anything more convincing, but perhaps it's desirable to obtain constent from parents before populating the array (e.g. iframe discloseorigin=yes). If a member of the chain doesn't consent, the corresponding element of the array is null / undefined / an empty string? /mz
Re: [whatwg] Proposal: location.parentOrigin
In fact, in the vein of opt-in disclosure perhaps something like
discloselocation={none|origin|full} would be more convenient - in
which case, you get something like
window.parentLocations[n].{origin|href|hash|...}
I constantly fear that origin scoping for security mechanisms is too
coarse-grained in many use cases, because the complexity of what lives
in any single origin is growing pretty rapidly. Sites put
attacker-controlled content inside framed gadgets or advertisements,
and can't be reasonably expected to understand that if such a frame is
navigated to in a particular way, it may circumvent an origin-scoped
check.
/mz
Re: [whatwg] Proposal: location.parentOrigin
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 w...@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
Re: [whatwg] Proposal: location.parentOrigin
On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) The use case is the same as in the previous email, specifically: ---8--- 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. ---8--- The payment widget might care about all of its ancestors. For example, suppose the payment operator has a relationship with store.example.com. They might wish to fall back to using a confirmation page if store.example.com is embedded as a frame in another web site (e.g., pintrest). Why don't they just ask the parent frame for their parent's origin, since they trust them? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) The use case is the same as in the previous email, specifically: ---8--- 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. ---8--- The payment widget might care about all of its ancestors. For example, suppose the payment operator has a relationship with store.example.com. They might wish to fall back to using a confirmation page if store.example.com is embedded as a frame in another web site (e.g., pintrest). Why don't they just ask the parent frame for their parent's origin, since they trust them? From my original email: ---8--- 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). ---8--- Adam
[whatwg] Proposal: location.parentOrigin
== 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
