[whatwg] Proposal: location.parentOrigin

[Adam Barth]

On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 3 Apr 2012, Adam Barth wrote:
>> On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson <ian at 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