Re: Chrome WebVR avaliable only on secure origins

Thank you, James, for the JanusVR statistics! It's always helpful to have
real-world numbers to look at when gauging the impact of these types of
decisions.

On Thu, Jul 14, 2016 at 3:43 PM James Baicoianu <james_w3@baicoianu.com>
wrote:

> On Wed, Jul 13 2016 at 04:29, Brandon Jones <bajones@google.com>
> <bajones@google.com> wrote:
>
> > We realize that some developers have strong opinions on this subject. We
> > welcome feedback, *especially *if this policy makes your planned use
> case
> > infeasible! But we also feel that the development community around a new
> > feature like this is actually in the best position to gracefully handle
> > this requirement. WebVR projects are less likely to have large amounts
> of
> > legacy code that needs to be updated to support HTTPS. Additionally,
> > efforts like Lets Encrypt are in full swing and make it easier than ever
> to
> > make your sites secure.
>
>
> Thanks for the advanced warning on this change.  This will definitely
> cause some problems for one of my use cases.  Let me explain.
>
> My current project is JanusWeb, an in-browser WebGL/WebVR client for
> JanusVR rooms.  JanusVR rooms are 3d worlds defined by simple JSON or XML
> mark-up which can be written by any user, and hosted on any website -
> similar in concept to A-Frame.  These rooms can be linked together with
> portals, allowing for seamless movement from room to room, even though each
> room may be hosted on different servers, controlled by different entities.
> Originally these rooms were written to be viewed in the native JanusVR
> client, but JanusWeb makes that content accessible directly in the browser.
>
> So here's the problem.  The vast majority of these rooms are being created
> by amateur users, not professional web developers.  The pages are being
> hosted in a wide variety of ways - some content is hosted on large-scale
> professional hosting services specifically geared towards hosting VR
> content, while the rest is scattered all over on a hodgepodge of personal
> webservers, free web hosting services, AWS, Dropbox, distributed services
> like IPFS, or even just embedded in temporary pages like Pastebin.
>
> Since this content is hosted in a completely decentralized fashion, it's a
> usability challenge to tell web users "you can only view this content in VR
> if the site you hosted it on uses HTTPS," especially when the content
> authors may be people who have enough technical ability to cobble together
> some JSON or XML mark-up, but not necessarily enough to register a domain,
> set up a server, run Lets Encrypt, and configure everything properly.
>
> To give some real-world numbers, of a sampling of 3200 existing JanusVR
> rooms, only 300 are currently hosted on HTTPS hosts.  So if WebVR is only
> available for HTTPS websites, that means only 10% of this particular
> ecosystem would be viewable in VR.  I would expect a similar distribution
> for related projects like A-Frame.  This of course poses usability
> challenges - do you drop someone out of VR when they walk through a portal
> to an HTTP website and force them to switch to 2D browsing mode?
>
> Another issue with HTTPS is the Schroedinger-like nature of HTTP caching.
> I can configure my server with all the right headers to tell the browser to
> cache my content, but because it's HTTPS the browser may decide to ignore
> that.  My understanding (it's been a few years since I extensively tested
> this so please correct me if I'm wrong) is that most browsers refuse to
> cache HTTPS pages to disk across browser loads for security reasons.  3D
> content tends to be quite large, and not being able to cache effectively is
> a serious hindrance.  Yes, there are tricks like storing assets to
> IndexedDB or localStorage, but these are merely hacks which are subject to
> their own restrictions and pitfalls.
>
> VR and WebVR in particular are nascent technologies and I think we're
> seeing that a lot of the early experimentation and implementation is being
> done by amateurs.  Amateurs are trying out all kinds of different
> experiences, experimenting with different means of displaying data and
> moving around and manipulating worlds, and generally doing all the research
> which professionals and companies aren't yet willing to commit full
> resources to.
>
> This early experimentation is what will help the industry evolve a set of
> common best practices, and I think it's important to keep the barrier to
> entry for users to create content for this new medium as low as possible.
> Currently, it feels a lot like the early weirdness of the World Wide Web in
> the 90s, when nobody really yet knew what to do with it and anything was
> fair game.  The fact that anyone could just open up a text editor and start
> creating new content allowed us to quickly figure out what did and didn't
> work, and the entirely new fields of professional web design, web
> development, JavaScript frameworking, and hardcore memeing were born of the
> chaos.
>
> Where would we be today if in the 90s, web developers had been required to
> file with a centralized authority for the ability to use specific features
> on their websites?  I'm quite certain that JavaScript would never have made
> it through its first few painful years of life, and the web would be a very
> different place had this been the policy then, and I worry about not giving
> web-based VR the opportunity to reach its full potential by putting up
> technical barriers to entry early in its lifecycle.
>
> I understand the desire to incentivize developers to switch to HTTPS for
> security reasons, but the fact is, not all content needs to be protected,
> and HTTPS really does very little if anything to protect users from any
> potential security pitfalls and bad experiences that these technologies may
> expose users to, since anyone including scammers can trivially acquire a
> valid HTTPS certificate.  The only argument in favor of tying this feature
> to HTTPS is exactly the one that worries us the most - "if someone is using
> this technology to distribute malicious experiences, their certificates can
> be revoked to protect people from exposure to that content."  There's a
> word for that, of course - censorship.
>
> Overall it feels a bit like a digital version of Security Theater, in a
> greater argument over whether freedom of expression and anonymity are more
> or less important than our freedom to be protected from unpleasant things.
> We understand the well-meaning intent, in an ideal world all web traffic
> would be encrypted for the protection of the user's privacy, but the
> current situation with TLS is too heavily tied with identity, and too
> cumbersome to impose on content authors.
>
> There's a greater conversation to be had about how we can transition the
> web as a whole to secure protocols, but locking up unrelated features to
> force the issue is not the way to go.
>
>
> > Thanks!
>
> Thank you as well, for all you've done for the community.
>
>
> -- James Baicoianu
>
>