Reject non-http URLs for url member

index.html

@@ -35,6 +35,14 @@
           browsers: ["chrome", "firefox", "safari", "edge", "and_chr", "and_ff", "ios_saf"],
         },
         xref: "web-platform",
+        localBiblio: {
+          "Wylecial": {
+            "date": "2020-08-25",
+            "title": "Stealing local files using Safari Web Share API",
+            "Author": "Pawel Wylecial",
+            "href": "https://blog.redteam.pl/2020/08/stealing-local-files-using-safari-web.html"
+          }
+        }
       };
     </script>
   </head>
@@ -176,6 +184,9 @@ <h4>
                 <li>If |url| is failure, return <a>a promise rejected with</a>
                 {{TypeError}}.
                 </li>
+                <li>If |url|'s [=URL/scheme=] is not "http" or "https", return
+                <a>a promise rejected with</a> {{TypeError}}.
+                </li>
                 <li>Set |data| to a copy of |data|, with its {{ShareData/url}}
                 member set to the result of running the <a>URL serializer</a>
                 on |url|.
@@ -464,6 +475,42 @@ <h2>
         guard against this, but implementors will want to be aware that it is a
         possibility.
         </li>
+        <li>
+          <p>
+            Share targets that dereference a shared URL and forward that
+            information on might inadvertently forward information that might
+            be otherwise confidential. This can lead to unexpected information
+            leakage if shares reference content that is only accessible by that
+            application, the host on which it runs, or its network location.
+          </p>
+          <p>
+            Malicious sites might exploit share targets that leak information
+            by providing URLs that ultimately resolve to local resources,
+            including, but not limited to, "file:" URLs or local services that
+            might otherwise be inaccessible. Even though this API limits shared
+            URLS to "http:" and "https:", use of redirects to other URLs or
+            tweaks to DNS records for hosts in those URLs might be used to
+            cause applications to acquire content.
+          </p>
+          <p>
+            To avoid being used in these attacks, share targets can consume the
+            URL, retrieve the content, and process that information without
+            sharing it. For instance, a photo editing application might
+            retrieve an image that is "shared" with it. A share target can also
+            share the URL without fetching any of the referenced content.
+          </p>
+          <p>
+            Share targets that fetch content for the purposes of offering a
+            preview or for sharing content risk information leakage. Content
+            that is previewed and authorized by a user might be safe to
+            forward, however it is not always possible for a person to identify
+            when information should be confidential, so forwarding any content
+            presents a risk. In particular, the {{ShareData/title}} might be
+            used by an attacker to trick a user into misinterpreting the nature
+            of the content, as demonstrated in the [[Wylecial]] <a data-cite=
+            "Wylecial#">proof of concept attack</a>.
+          </p>
+        </li>
       </ul>
     </section>
     <section class="appendix informative">