<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Sorry for the delay Herbert,<br>
      <br>
      The browser's JavaScript enforces a "same origin" policy, whether
      the content arrives by HTTP,  HTTPS, or FILE. If the content is
      not the same origin, then permission must be obtained from the
      server of the page prior to requesting content from another
      source. Since there is no server at <a class="moz-txt-link-freetext" href="FILE://">FILE://</a>, no approval can be
      given and no request for content is made. Some browsers (e.g.,
      Chrome) in their default setting do not allow XHR content from
      <a class="moz-txt-link-freetext" href="file://">file://</a>. It is possible to change that.<br>
      <br>
      The group working on the standard has not settled on what happens.
      The last proposal to put a red banner on non-HTTPS content has
      been withdrawn. It appears that there are some internal (within
      Google at least) communication issues. They are all being quiet
      right now.<br>
      <br>
      What does appear to be likely is that there will be some sort of
      notification if a web page starts WebVR and the content was remote
      and not encrypted during transmission. The current discussions do
      not have a long-term notification for content accessed as <a class="moz-txt-link-freetext" href="file://">file://</a>.
      I can't understand how browser builders would require local
      content (<a class="moz-txt-link-freetext" href="file://">file://</a>) to be encrypted. The browser would have to
      handshake with the file system and there would be no point in
      that.<br>
      <br>
      In no cases is anyone proposing changes to the policy of a remote
      pages be able to load content from a local file system.<br>
      <br>
      The biggest issue for developers is allowing WebVR to run on
      devices in a local server environment. It becomes very awkward and
      inconvenient If a certificate is required just to do local
      development (e.g., small server for mobile devices).<br>
      <br>
      <br>
      Leonard Daly<br>
      <br>
      <br>
      <br>
    </div>
    <blockquote
      cite="mid:4bf715d5-ff98-bb0e-fe67-af34eb15588f@bitmanagement.com"
      type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <p>Hi all,</p>
      <p>i guess the point about <a moz-do-not-send="true"
          class="moz-txt-link-freetext" href="file://">file://</a> does
        not mean that reading the local disk should be in an encrypted
        form. Or disabled per se.<br>
        i guess it means that if the content arrives via <a
          moz-do-not-send="true" class="moz-txt-link-freetext"
          href="https://">https://</a> then referencing assets like
        Inlines or textures via <a moz-do-not-send="true"
          class="moz-txt-link-freetext" href="file://">file://</a> is<br>
        disabled for security reasons. Am i right?</p>
      <p>However i think that is just good old same-origin-policy. No
        content coming from a web server should be able to<br>
        reference stuff on the hard disk. Although for in house demos
        (web server inside the intranet) this may be feasible.<br>
      </p>
      <i>Herbert</i>
      <p><br>
      </p>
      <br>
      <div class="moz-cite-prefix">On 15.07.2016 20:13, Leonard Daly
        wrote:<br>
      </div>
      <blockquote
        cite="mid:eeeb4edc-c580-4bd0-850e-ba6450e3ad30@realism.com"
        type="cite">
        <meta http-equiv="content-type" content="text/html;
          charset=windows-1252">
        <p>There is a very heated discussion going on in the web-vr list
          concerning the WebVR specification. The browsers companies (at
          least Google and Mozilla) are considering making this
          capability require that the content arrived over HTTPS. This
          seems (to me) to be part of a much larger push to require all
          content be encrypted.</p>
        <p>My point is not to get in a discussion here about the merits
          of this idea, but to provide preliminary notice that all Web3D
          content is going to need to support HTTPS at the same Profile,
          Component/Level as HTTP protocol is supported. It may even be
          the case that <a moz-do-not-send="true"
            class="moz-txt-link-freetext" href="FILE://">FILE://</a>
          won't work or will require a configuration setting change in
          the browser.<br>
        </p>
        <br>
        <div class="moz-signature">-- <br>
          <font class="tahoma,arial,helvetica san serif" color="#333366">
            <font size="+1"><b>Leonard Daly</b></font><br>
            3D Systems & Cloud Consultant<br>
            X3D Co-Chair on Sabbatical<br>
            LA ACM SIGGRAPH Chair<br>
            President, Daly Realism - <i>Creating the Future</i> </font></div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
x3d-public mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
x3d-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>
<a class="moz-txt-link-freetext" href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a>
</pre>
    </blockquote>
    <br>
    <p><br>
    </p>
    <div class="moz-signature">-- <br>
      <font class="tahoma,arial,helvetica san serif" color="#333366">
        <font size="+1"><b>Leonard Daly</b></font><br>
        3D Systems & Cloud Consultant<br>
        X3D Co-Chair on Sabbatical<br>
        LA ACM SIGGRAPH Chair<br>
        President, Daly Realism - <i>Creating the Future</i>
      </font></div>
  </body>
</html>