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

On Wed, Jul 13, 2016 at 12:00 PM, Martin Splitt <mr.avgp@gmail.com> wrote:

> Am 13.07.2016 11:28 vorm. schrieb "Florian Bösch" <pyalot@gmail.com>:
>
> >
> >> This is consistent with our current policy for powerful new features,
> >
> > It's a bad policy.
>
> Mind elaborating on this? The policy is not a surprise seeing browser
> vendors concerned with transport encryption for privacy and integrity of
> content and data. I don't find it "bad" to safeguard users from MitM etc.
> for many features such as geolocation or payments. For WebVR this is
> debatable, I guess, but not a bad policy in general. What makes it bad?
>
There's several reasons why it's bad:

   1. It encroaches upon functionality that's unrelated in any way to
   security (for instance it's semi-understandable why getUserMedia or
   ServiceWorkers would be affected, less so why fullscreen or pointerlock
   should be)
   2. It proposes the principle of using an arbitrary selection of features
   (see point #1) as a carot (the feature) and a stick (the absence of the
   feature) to drive people to use HTTPS
   3. It uses the TLS infrastructure for this endevour, which is itself
   objectionable in many regards (including not being meant for what it's now
   come to be promoted for)
   4. Due to the nature of TLS and its shortcomings, it provides google
   with an *unfair advantage over others*, which is a problem because the
   policy is *promoted by google*, and *enforced trough chrome*, which is *made
   by google*. In antitrust parlance, that's what you call "a conflict of
   interest".

>> We are, in effect, giving sites the ability to take over not just your
> cursor
> >
> > Gaze isn't your cursor. And it's not "taking it over". If you don't
> react to gaze, you make users puke, there's no choice on following gaze if
> you're writing VR.
> >
> >>
> >> or your screen
> >
> > You're not giving people the control to take over somebodies screen,
> unless you consider "writing any webpage" the same. Why don't you make "any
> wepage" HTTPS only? Hm funny that, ain't it?
>
> It's not your cursor but it makes you more susceptible to bad experiences
> and tearing down the headset may be a little late to avoid a very bad
> experience.
>
In what way way is TLS preventing people from deploying bad WebVR content?
This is an argument from false cause. Essentially you say: TLS is helping
make good WebVR content. It's a false cause, because there is no causal
relationship between one and the other.

> Also, what's so bad about having every website on HTTPS, besides the
> nuisance that is the CA business. Let's Encrypt tries to remediate that
> (and hopefully more will follow).
> >>
> >> but completely override one of your senses.
> >
> > You're not overriding anybodies senses. It's a HMD, people can take it
> off.
> >
>
> That's not sufficient when something bad has already happened. Think of
> jumpscares,for instance.
>
False cause argument. In what way is TLS helping to avoid people deploying
jumpscares? TLS has no causal relationship to the deployment of WebVR
jumpscares.


> >> It's prudent for us to ensure the digital reality we deliver
> >
> > You don't deliver anything. Website authors deliver content, you're just
> transmitting it. How authors transmit is up to them, not to you.
> >
>
> Browser vendors provide us with the ability to deliver content using VR
> hardware , I dont see your point here.
>
The transport of content should have no bearing on what that content is.
It's not in the UAs place to make the decisions for two causally unrelated
set of capabilities to be used together. This bundling is what I find
objectionable as per general objection against carot&stick'ing.
Additionally, browsers themselves don't deliver anything, they transmit.
Website authors deliver.

> >>
> >> to users is authenticated,
> >
> > TLS does nothing whatsoever for authentication in any way.
> >
>
> It authenticates the content provider to the user.
>
Ideally it does, but in many cases that authentication has no relevance.
For instance, http://slither.io/

> > TLS makes all kinds of things infeasible.
>
> Can you give a example?
>
Localhost testing, intranet deployment, dns round robin, edge routing,
performance issues, wildcard certificate uses (cost), high performance
webservers (integration), etc.