[x3d-public] Encrypted Content

Leonard Daly Leonard.Daly at realism.com
Wed Aug 3 07:27:33 PDT 2016


Sorry for the delay Herbert,

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 FILE://, 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 file://. It is possible to change that.

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.

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 file://. I can't 
understand how browser builders would require local content (file://) to 
be encrypted. The browser would have to handshake with the file system 
and there would be no point in that.

In no cases is anyone proposing changes to the policy of a remote pages 
be able to load content from a local file system.

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).


Leonard Daly



> Hi all,
>
> i guess the point about file:// does not mean that reading the local 
> disk should be in an encrypted form. Or disabled per se.
> i guess it means that if the content arrives via https:// then 
> referencing assets like Inlines or textures via file:// is
> disabled for security reasons. Am i right?
>
> However i think that is just good old same-origin-policy. No content 
> coming from a web server should be able to
> reference stuff on the hard disk. Although for in house demos (web 
> server inside the intranet) this may be feasible.
>
> /Herbert/
>
>
>
> On 15.07.2016 20:13, Leonard Daly wrote:
>>
>> 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.
>>
>> 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 FILE:// 
>> won't work or will require a configuration setting change in the browser.
>>
>>
>> -- 
>> *Leonard Daly*
>> 3D Systems & Cloud Consultant
>> X3D Co-Chair on Sabbatical
>> LA ACM SIGGRAPH Chair
>> President, Daly Realism - /Creating the Future/
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
X3D Co-Chair on Sabbatical
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160803/809761d4/attachment.html>


More information about the x3d-public mailing list