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

> As per your comment, I think using entry settings object here makes sense.

OK, that flat out contradicts your comments in https://github.com/slightlyoff/ServiceWorker/issues/687#issuecomment-97752545

Also, my comments about not being able to change effective script origin on unique identifiers apply if the only decision is a boolean "is this a unique identifier origin?".  If you actually care about the identity of the origin, then you need to care about the identity of the origin!

Let's look at this testcase, which has full generality, I believe:

    <!-- a.html -->
    <iframe src="b.html"></iframe>
    <iframe src="c.html"></iframe>
    <iframe src="d.html"></iframe>
    <script>
    window.onload = function() {
        window.frames[0].doOpen();
    }
   </script>

    <!-- b.html -->
    <script>
    function doOpen() {
      parent.frames[1].caches.open.call(parent.frames[2].caches, someName);
    }
    </script>

Let's say a.html, b.html, c.html, d.html are all from different origins but have all set their document.domain so that they are same-effective-origin, so that the doOpen() call succeeds, as does the caches.open call.  Which origin should be used for the name-to-cache map?  The options are the origins of  a.html, b.html, c.html, and d.html.  The entry settings object is a.html, incumbent settings is b.html, the callee Realm is c.html, and the this object is from d.html. 

Another option to sidestep all this is to spec that the ServiceWorker APIs fail out if `document.domain` was set and that setting `document.domain` throws if the ServiceWorker APIs were accessed, so you can't do both in the same document.  There's been some talk of doing that for some other APIs but it's never materialized...

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