Re: [ServiceWorker] self.caches should spec what to do for "untrusted" origins (#687)

In the case you're describing, the incumbent settings object is identical to the entry settings object and both are settings objects for `a.html`.  It sounds to me like you're a bit confused on that point...  Note that your example is subtly different from the one you link to in the spec, in that in your example there is no script running inside `b.html` at all, yes?

The intuitive understanding of incumbent vs entry settings objects is this: entry settings is where script was entered; incumbent settings is what script was running when the call into the DOM API was made.

Back to the issue in question here... what assumptions are you willing to make in terms of what objects can touch each other and how origins work?  Generally, if we managed to make the call at all that means the effective script origins of all the stuff involved are the same (or were the same at some point in time, for browsers that don't revoke things).  Since `document.domain` can't affect whether something is a unique identifier origin (so far?) that means that you really can use any of the four origins involved here (entry settings, incumbent settings, current realm (aka callee function), this object) and the effect will probably be the same.  Emphasis on _probably_.  If you have a clear mental model of which of those 4 origins is actually relevant here, you should use that one.  Which brings us back to the question of what origin is actually used for the operation that can't be performed when that origin is a unique identifier.  How is _that_ defined right now?

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/687#issuecomment-97829732