Re: Chrome WebVR avaliable only on secure origins

I know I've been a bit quiet on public channels after starting this thread,
but wanted to drop in and just say that there's still ongoing internal
discussions about this policy. And yes, we are reading ALL the various
threads that have come up about the subject. Please have some patience
while we collect feedback and explore the various use cases that are being
brought up. We'll be sure to keep the community updated as much as we can
as we work through it.

Thanks,
--Brandon

On Fri, Jul 15, 2016 at 10:28 AM <contact@corxia.com> wrote:

> For the reasons being for https (ability to take control of ones sense),
> I don't think we should be looking at https at all.
> Right now if we focus our sense towards a web page and fully immerse in
> the way we do so now.. we are met by 'pop ups' / 'light boxes'.
> If over taking one of our senses is a core reason to implement a
> protocol, should we not be more focused upon the webvr version of pop
> ups?
> I'd rather be more focused on how to prevent that from occurring
> (mayhaps layers of immersion?) than forcing data through a pipe hole.
> We right now are in a position to define an attribute of layers, seeing
> as z-axis is a new co-ordinate we are dealing with.
> How may you ask? the origin defines the limit of the z-axis, anything
> not from the origin is always given a lower subset of z-axis.
>
> On 2016-07-15 08:52, Tony Parisi wrote:
> > James
> >
> > So thoughtful and so spot on.
> >
> > I was also thinking Security Theatre. I'm still taking my shoes off at
> > airports... And asking myself, "Do I feel safer?"
> >
> > Sent from my iPhone
> >
> > On Jul 14, 2016, at 3:42 PM, James Baicoianu <james_w3@baicoianu.com>
> > wrote:
> >
> >> On Wed, Jul 13 2016 at 04:29, Brandon Jones <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
>
>
>