For local dev, post-install self-signed cert for HTTPS (via BrowserSync hopefully)

[cvan]

In order to use "powerful APIs," your site must be served from a "secure origin" - that is, be served over TLS or http://localhost:*/http://127.0.*.* (see [this](https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features and [this]%28https://w3c.github.io/webappsec-secure-contexts/%29 and [this]%28immersive-web/webxr#60, etc. for more context).

It's worth noting that WebVR is not a "powerful API" just yet, but already today some APIs such as are already a hassle to use (door-hanger permission prompts spamming on every API request/page load in Firefox or disabled in Chrome). Example: navigator.getUserMedia with Firefox over HTTP won't persist the "allowed" notification (only for HTTPS), and the API is already outright deprecated for external IPs/non-HTTPS origins in Chrome.

There's an easy way to create a self-signed cert from an npm command: https://github.com/cvan/webvr-holodeck/blob/6581527/package.json#L9

It's worth noting that budo offers this out of the box now: https://github.com/mattdesl/budo/blob/master/CHANGELOG.md#900

Relevant to issue #1277, which is being handled in PR #1671… also good news is that BrowserSync also already supports HTTPS out of the box (just set https: true in the options). (And here's the relevant script: https://github.com/BrowserSync/browser-sync/blob/master/lib/server/certs/gen.sh)

[ngokevin]

Merging with #1277

Though I am not sure why we need SSL for localhost since APIs will allow access to localhost, but #1277 will solve anyways. There's a PR open #1671

[cvan]

Although http://localhost and http://127.1.x.x are whitelisted as "secure origins" in Chrome and Firefox, if you need to test on mobile devices or dedicated remote devices (Google Daydream/Cardboard, Gear VR with Samsung Internet/Carmel, dedicated Windows machine for VR), you must load a URL on your LAN (e.g., http://10.0.1.59:9000) and load the scene in the headset.

Additionally, when testing a WebVR site (without ngrok/localtunnel/self-signed HTTPS), any WebVR site loaded in Chrome for Daydream injects a "This site is not secure" window that persists directly in front of you in VR (for the entire duration of the VR session); it's really the worst.

Unfortunately, when serving over a non-secure origin, most browsers won't let you use APIs such as Service Workers, getUserMedia, Speech Recognition/Synthesis, devicemotion, etc.
(Chrome tends to be stricter in its secure-origin policy, but Firefox, Safari, and Edge all have similar documented and enforced policies.)

I've looked at several projects/boilerplate/starter kits; unfortunately, most of them have quite convoluted instructions for setting up HTTPS (because it's intentionally difficult to generate self-signed certs [especially wildcard ones] and get the browser + OS to accept them, especially on macOS).

Possible solutions that come to mind:

• Recommend using ngrok (which returns both http and https URLs).
• Consider creating a boilerplate using BrowserSync (which is a nice npm local dev server that has a bunch of cool recipes, including easy HTTPS, built-in localtunnel support, and live-reloading).
• Document instructions for self-signed SSL certs and serving HTTPS.
  • Somewhere in the docs for local development (and for any A-Frame boilerplates that run locally, such as this one), we could link to budō's docs on HTTPS.

[ngokevin]

OK. I had a section on ngrok in the School, and I can add it to the Getting Started some time. Since the entry point is starting to be more and more Glitch, that will help as well.

[cvan]

awesome - thanks! 👍 also, great work on the Glitch boilerplates. very excited to be able to do more development from my Chromebook. 💻 😺

[bartburkhardt]

You can also use your homepage on Keybase
https://keybase.pub