Re: [webvr] Chrome WebVR avaliable only on secure origins

It comes to my attention that the issue with XmlHTTPRequest is not to do
with secure origins, but same-origin policy. So I also have to keep track
of multiple ways in which my page may not work, for no other reason than
"browser refuses to do what is syntactically correct". It's a serious
barrier to adoption for new developers.
On Jul 13, 2016 6:29 AM, "Sean McBeth" <sean.mcbeth@primrosevr.com> wrote:

>
> On Jul 13, 2016 6:04 AM, "Martin Splitt" <mr.avgp@gmail.com> wrote:
>
> > >> We welcome feedback, especially if this policy makes your planned use
> case infeasible!
> > >
> > > TLS makes all kinds of things infeasible.
> >
> > Can you give a example?
>
> For one thing, your own file system is not considered a secure origin.
> I've ran into lots of people trying to get into WebVR that just don't
> understand what that means. They see a page, they see they can link to
> images on that page, they can double click on that file and see the
> results. It never occurs to then that they need to run a local web server.
> If they don't already know what that means, it's nearly impossible to
> explain the indirection. Why do they need a web server when the file is
> right there?
>
> I know several more people who have no idea how to setup a self-signed
> certificate on their machine to be able to test features on their own
> networks. OpenSSL is not that easy to install on Windows. A similar fiat
> decision was made for WebRTC. I eventually just copied the certs off of my
> production site and live with the cert warnings. S terrible solution to a
> stupid problem.
>
> Frankly, I've been a web dev for 20 years and it feels rather ridiculous
> that web dev is harder, more cumbersome *today*. I don't even get why
> disabling XmlHTTPRequest was necessary, rather than restricting it to the
> parent directory of the page.
>
> I agree with Florian. It's on Google to provide tools, not dictate how
> they are used.
>