- From: Tony Parisi <tparisi@gmail.com>
- Date: Wed, 13 Jul 2016 13:42:36 -0400
- To: Martin Splitt <mr.avgp@gmail.com>
- Cc: public-webvr@w3.org, Brandon Jones <bajones@google.com>, Chris Van Wiemeersch <cvan@mozilla.com>, Sean McBeth <sean.mcbeth@primrosevr.com>, Florian Bösch <pyalot@gmail.com>
- Message-ID: <CAHNoKZgztGL=feXwWmTjNx=OtLto3Jz+0dWxSGrb7Wp=WK2jDg@mail.gmail.com>
But, Given that this whole thing seems to be a foregone conclusion-- I haven't seen any sympathy for the dev on this thread in two years-- can us unwashed web developers get a little help in the form of the following: - Continue support for debug flags in the browsers? e.g. a new flag in the spirit of --allow-file-access-from-files - Provide basic tutorials and information on the easiest ways to set up secure servers, and pointers to setup steps for existing hosting services such as Linode... ? Tony On Wed, Jul 13, 2016 at 1:34 PM, Tony Parisi <tparisi@gmail.com> wrote: > +1 voice added to the chorus... this is really worrisome. I felt the same > about the fullscreen restrictions when they were first being discussed > coming on two years now. > > Not only does this threaten the open web but it hampers development. Used > to be, like Sean said, that all it took to get going was a text editor and > a free server. Now you have to apply for certs and muck with setup. Hell > you might as well just publish a native app to the Apple or Google store. > > Tony > > > On Wed, Jul 13, 2016 at 11:50 AM, Martin Splitt <mr.avgp@gmail.com> wrote: > >> Right, with all clarifications in place, I think it's time to go with my >> personal opinion. >> >> I find the limitations of APIs such as the full screen mode, webrtc and >> WebVR worrying. >> >> It puts limitations on sharing and embedding across different content and >> ignores the fact that a lot of necessary work to get encrypted traffic for >> everybody without the hassle that it still is. >> >> It's great to see that services like Let's Encrypt and Github Pages, >> Zeit, Cloudflare working towards that, but it's not the open web we want.. >> >> I still wonder what the benefits are (and my attempt to assume arguments >> for the proponents have been demonstrated to be inconsistent). >> >> On the other hand: The issue of HTTPS everywhere is more than just WebVR, >> thanks to HTTP/2 being SSL only. >> >> I wonder where all this will go, but I doubt WebVR needs to enforce this.. >> >> Cheers 🍻 >> Am 13.07.2016 4:08 nachm. schrieb "Jaakko Manninen" <jaakko@vizor.io>: >> >>> I agree that requiring SSL will undemocratise WebVR because getting SSL >>> can be quite a challenge and incurs a cost. That's not the open web >>> anymore. >>> >>> I'm also worried about embedding, an important use case for Vizor.io is >>> to be able to embed your production into any web page. >>> >>> Overall I think this change is too prohibitive and not necessary to >>> begin with - IMHO adequate security provisions like CORS are already in >>> place. >>> >>> Best regards, >>> >>> Jaakko >>> >>> On Wed, Jul 13, 2016 at 2:23 PM, Sean McBeth <sean.mcbeth@primrosevr.com >>> > wrote: >>> >>>> On LetsEncrypt: the Windows/IIS story is effectively non-existent. I >>>> don't think it is very good to be suggesting a "solution" that effectively >>>> dictates a platform. >>>> >>>> I know Windows isn't popular, and in a perfect world I'd certainly like >>>> to be off of it, but Oculus and Valve have restricted the HMDs, under some >>>> post-hoc rationalization that Apple and X.org have hobbled the OSes. For >>>> once, it's *not* Microsoft's fault I'm stuck on Windows. >>>> On Jul 13, 2016 7:07 AM, "Florian Bösch" <pyalot@gmail.com> wrote: >>>> >>>>> If TLS would fulfill the following criteria I would not object in any >>>>> way to its promotion of use for everything. >>>>> >>>>> 1. Free for any scope and use >>>>> 2. Censorship resistant >>>>> 3. Surveillance resistant >>>>> 4. Fast (as in not significantly slower for all use-cases) >>>>> 5. Decentralized >>>>> 6. Easy to deploy >>>>> 7. Not jurisdiction bound (no US-based root CA, no US-based "free" >>>>> providers) >>>>> 8. Included with every domain (including every subdomain, or any >>>>> domain (wildcard)) >>>>> 9. Implementations where straightforward, bug-resistant, minimal >>>>> and easy to integrate, available in a variety of languages and environments >>>>> 10. The protocol wasn't a completely lost cause of legacy gunk >>>>> 11. It was so well engineered that even homegrown implementations >>>>> of it would be easy to get right >>>>> 12. It would not impose various restrictions on the use of >>>>> networks, that present a restriction of how networks used to be used >>>>> >>>>> TLS is so far away from all of this, that I find it fundamentally >>>>> objectionable to promote its use universally. If you want to use TLS as it >>>>> exists, fine. Enforcing it on everybody: principled absolute nono. >>>>> >>>>> >>>>> On Wed, Jul 13, 2016 at 12:46 PM, Chris Van Wiemeersch < >>>>> cvan@mozilla.com> wrote: >>>>> >>>>>> Not to dispute the very legitimate points addressed in the past few >>>>>> threads, just FYI it's possible to start Chrome and Firefox such that a >>>>>> local web server is not needed (for three.js/A-Frame/WebVR development, for >>>>>> example): >>>>>> https://github.com/mrdoob/three.js/wiki/How-to-run-things-locally#content-loaded-from-external-files >>>>>> >>>>>> I try to link to that page in project READMEs and documentation. Just >>>>>> trying to spread the knowledge, but obviously I'm not dismissing the other >>>>>> points. >>>>>> >>>>>> The same-origin policy is a hassle, yes. It's also the sandbox that >>>>>> enables folks to load a web page and not be afraid of getting a virus. >>>>>> FWIW, IME, most (non-super-technical) folks I've encountered understand >>>>>> this. And they're the same folks who get scared when they see contextless >>>>>> permission prompts and blindly accept them because… all my friends use >>>>>> Whatsapp or Snapchat. Again, not an excuse. It's just the landscape today. >>>>>> >>>>>> For folks interested, Anne van Kesteren (standards guru at Mozilla) >>>>>> has written quite a few good pieces on his blog about these very topics. >>>>>> Though he's advocated for the same-origin policy (for the aforementioned >>>>>> reasons), he is also critical of its hinderance to web development (and >>>>>> consumption of web pages): >>>>>> https://annevankesteren.nl/2016/07/web-computing >>>>>> >>>>>> >>>>>> On Wed, Jul 13, 2016 at 3:36 AM, Sean McBeth < >>>>>> sean.mcbeth@primrosevr.com> wrote: >>>>>> >>>>>>> It comes to my attention that the issue with XmlHTTPRequest is not >>>>>>> to do with secure origins, but same-origin policy. So I also have to keep >>>>>>> track of multiple ways in which my page may not work, for no other reason >>>>>>> than "browser refuses to do what is syntactically correct". It's a serious >>>>>>> barrier to adoption for new developers. >>>>>>> On Jul 13, 2016 6:29 AM, "Sean McBeth" <sean.mcbeth@primrosevr.com> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Jul 13, 2016 6:04 AM, "Martin Splitt" <mr.avgp@gmail.com> wrote: >>>>>>>> >>>>>>>> > >> We welcome feedback, especially if this policy makes your >>>>>>>> planned use case infeasible! >>>>>>>> > > >>>>>>>> > > TLS makes all kinds of things infeasible. >>>>>>>> > >>>>>>>> > Can you give a example? >>>>>>>> >>>>>>>> For one thing, your own file system is not considered a secure >>>>>>>> origin. I've ran into lots of people trying to get into WebVR that just >>>>>>>> don't understand what that means. They see a page, they see they can link >>>>>>>> to images on that page, they can double click on that file and see the >>>>>>>> results. It never occurs to then that they need to run a local web server. >>>>>>>> If they don't already know what that means, it's nearly impossible to >>>>>>>> explain the indirection. Why do they need a web server when the file is >>>>>>>> right there? >>>>>>>> >>>>>>>> I know several more people who have no idea how to setup a >>>>>>>> self-signed certificate on their machine to be able to test features on >>>>>>>> their own networks. OpenSSL is not that easy to install on Windows.. A >>>>>>>> similar fiat decision was made for WebRTC. I eventually just copied the >>>>>>>> certs off of my production site and live with the cert warnings. S terrible >>>>>>>> solution to a stupid problem. >>>>>>>> >>>>>>>> Frankly, I've been a web dev for 20 years and it feels rather >>>>>>>> ridiculous that web dev is harder, more cumbersome *today*. I don't even >>>>>>>> get why disabling XmlHTTPRequest was necessary, rather than restricting it >>>>>>>> to the parent directory of the page. >>>>>>>> >>>>>>>> I agree with Florian. It's on Google to provide tools, not dictate >>>>>>>> how they are used. >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >>> -- >>> Jaakko Manninen >>> CTO, Vizor.io >>> +358-44-989-1619 >>> @Vizor_VR / @kschzt >>> >> > > > -- > > > 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 > > -- 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
Received on Wednesday, 13 July 2016 17:45:36 UTC