MIX: 'data:' and 'javascript:' are not authenticated origins.

specs/mixedcontent/index.html

@@ -1100,14 +1100,11 @@ <h3 class="heading settled" data-level=5.4 id=is-origin-authenticated><span clas
       </li>
     </ol>
 
-<p class=issue id=issue-12ee7138><a class=self-link href=#issue-12ee7138></a>What should we do with <code>data:</code>? It seems that we would
-    need to define some sort of taint checking in order to determine whether
-    they were created from authenticated resources, which seems error prone.
-    Perhaps excluding them is really the right thing to do.</p>
-
 <p class=note>Note: The origin of <code>blob:</code> and <code>filesystem:</code> URLs
     is the origin of the context in which they were created. Therefore, blobs
-    created in an authenticated origin will themselves be authenticated.</p>
+    created in an authenticated origin will themselves be authenticated. The
+    origin of <code>data:</code> and <code>javascript:</code> URLs is an
+    opaque identifier, which will not be considered authenticated.</p>
 
 <p class=note>Note: Step #5 above is meant to cover vendor-specific URL schemes whose
     contents are authenticated by the user agent. For example, FirefoxOS
@@ -1432,7 +1429,4 @@ <h2 class="no-num heading settled" id=issues-index><span class=content>Issues In
             integration with Fetch isn’t fully specified. It’s also not really
             clear what "insecure" should mean in a ServiceWorker context. We
             accept <code>blob</code> resources, for instance: should we accept
-            responses synthesized by the service worker?<a href=#issue-7701a1bf> ↵ </a></div><div class=issue>What should we do with <code>data:</code>? It seems that we would
-    need to define some sort of taint checking in order to determine whether
-    they were created from authenticated resources, which seems error prone.
-    Perhaps excluding them is really the right thing to do.<a href=#issue-12ee7138> ↵ </a></div></div>
+            responses synthesized by the service worker?<a href=#issue-7701a1bf> ↵ </a></div></div>

specs/mixedcontent/index.src.html

@@ -968,14 +968,11 @@ <h3 id="is-origin-authenticated">
       </li>
     </ol>
 
-    ISSUE: What should we do with <code>data:</code>? It seems that we would
-    need to define some sort of taint checking in order to determine whether
-    they were created from authenticated resources, which seems error prone.
-    Perhaps excluding them is really the right thing to do.
-
     Note: The origin of <code>blob:</code> and <code>filesystem:</code> URLs
     is the origin of the context in which they were created. Therefore, blobs
-    created in an authenticated origin will themselves be authenticated.
+    created in an authenticated origin will themselves be authenticated. The
+    origin of <code>data:</code> and <code>javascript:</code> URLs is an
+    opaque identifier, which will not be considered authenticated.
 
     Note: Step #5 above is meant to cover vendor-specific URL schemes whose
     contents are authenticated by the user agent. For example, FirefoxOS