Re: Chrome WebVR avaliable only on secure origins

Thanks Brandon;

For my part, I'm doing my best to be patient and I hope I've been raising
valid issues and not holding back on what I think the implications are. At
times my passion might seep through, though and if so, please bear with me,
too ;-)

Tony



On Fri, Jul 15, 2016 at 1:07 PM, Brandon Jones <bajones@google.com> wrote:

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


-- 


Tony Parisi                             tparisi@gmail.com
Follow me on Twitter!             http://twitter.com/auradeluxe
Read my blog at                     http://www.tonyparisi.com/
Learn WebGL                         http://learningwebgl.com/
Mobile                                    415.902.8002
Skype                                     auradeluxe

Read my books!
*Learning Virtual Reality*
http://www.amazon.com/Learning-Virtual-Reality-Experiences-Applications/dp/1491922834


*Programming 3D Applications in HTML5 and
WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966
<http://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966>WebGL,
Up and Running*
http://www.amazon.com/dp/144932357X