Re: Update on WebVR spec, Chrome, and HTTPS

On Fri, Sep 9, 2016 at 7:23 PM, Brandon Jones <bajones@google.com> wrote:
>
> First off, if you haven’t heard already, Microsoft has announced that
> they are working on WebVR support in Edge
> <https://blogs.windows.com/msedgedev/2016/09/09/webvr-in-development-edge/>.
> This means that even wider support for WebVR apps across new and exciting
> hardware! It’s a huge deal for web developers, and reiterates the fact that
> the best way to reach the widest number of customers in VR will be via the
> web.
>
I hugely applaud Microsoft for keeping up to date with the current state of
the art, if only all vendors showed the same dedication (the guilty know
who they are).

There is one slightly awkward bit about it though. Some VR vendors (who
know too who they are), only offer VR support to 3rd party apps, after
nagging users to allow it. Citing security and usability concerns and
whatnot as the reason for this. Those vendors also clearly indicated never
to move away from that entry barrier for 3rd party apps.

The awkward bit is if you (as a VR vendor) are deploying your software on
somebody elses operating system, and then declare a piece of software that
OS vendor also supplied, as a "insecure and possibly bad 3rd party app".

Now I'd imagine that that OS vendor and that VR vendor have a little
grouphug and get rid of that 3rd party entry barrier for that OS vendors
piece of software. But now, other browsers want in on that deal too, would
be a little unfair to them otherwise wouldn't it?

So the big awkward question here is: Does this mean that browsers can now
get preferential treatment in the "3rd party apps are bad" area from VR
vendors? And if they can, can other apps get it too? And if so, how?


> The good news is that we are going to stick with the policy that we
> announced last time: WebVR will be allowed on all HTTP domains with a
> persistent overlay to alert users to the non-secure origin. That includes
> HTTPS content embedded on HTTP domains.
>

I realize this is the best "deal" (as in the robotchicken kind of sense
https://www.youtube.com/watch?v=WpE_xMRiCLE) we're gonna get. Nevertheless
I'd like to comment on that.

   1. VR isn't HTTPS content, using the traditional phrasing of "secure
   content embedded in insecure origins" is... just misleading and a
   disservice to discussion of real security threats, it muddies the waters of
   the whole real security debate, please don't do that. I realize that there
   is some wish to talk about new capabilities as if they where security
   relevant, even though they aren't, and everybody even the proponents admits
   that. But if you really have to have some communication on that, please
   phrase it in a way that doesn't mix actual security, with this political
   new capability circus. It gets really difficult, really fast, to discuss
   actual security threats if that political white noise is drowning out any
   intelligent discussion.
   2. Purely from a UX point of view, a persistent overlay is trouble. It
   doesn't inform the user in any way of anything relevant just hanging about
   there. And it will interfere with with whatever content is presented in VR.
   There's no need to present somebody an overlay hours and hours on end, at
   the max 10 seconds in it becomes extremely annoying to users. So please
   don't pretend that it is meant to be informative, it isn't. What it is
   meant to be is annoying to users. I understand that the "security" circus
   is used as a justification for this bad decision. But "good" (SIC)
   intentions, don't justify the means. A bad UX decision is a bad UX
   decision, regardless of how you justify it. Now obviously this is the road
   taken by Google, and it's their very right to make bad UX in their own
   software. I can't prevent anybody from shooting themselves in the foot.
   What I can point out though is that I don't recall any good piece of
   software that's succeeded in annoying/nagging its users into submission,
   and getting away with it. It cheapens the software of whomever is peddling
   it, and in the case of Browsers, makes it harder to compete with native
   apps.