Camera and microphone require HTTPS in Firefox 68

It will still work on localhost, which is nice. It would be nice if it also worked on local IPs, like 192.168.<i>.</i>. Those do not work on Chrome, I think, which make mobile testing a bit more cumbersome.

In general, I&#x27;m NOT happy with how camera&#x2F;microphone, GPS and sensors like Gyro&#x2F;accel&#x2F;magnetometers and beacons (radio&#x2F;wifi&#x2F;bluetooth&#x2F;nfc), screen size&#x2F;resolution, battery level, hardware port identifiers etc are accessed by any website or app on my laptop&#x2F;phone.<p>This developed over the years without any input or choice from the end-user. The device manufacturers, platform owners (Apple, Google, Microsoft, Mozilla) and app developers joined together and forced this surveillance aparatus on all end-users.<p>This power balance has to change.

Dear Apple: for Christmas I&#x27;d like physical, no-bullshit power shutoff switches for your camera and microphone on the Macbook Pro. Other devices too—if you can manage it, that&#x27;d be great. Sincerely, the people who put tape over their cameras, the people who don&#x27;t because it&#x27;s ugly and messes with closing the lid but wish they could, and the people who would be in one of those two camps if they understood the risk (so, altogether, 100% of your users).

This sucks, my community[1] has a local offline-first video&#x2F;audio call app that we run on a physical mesh network.<p>This will make it impossible for people to talk to each other, without first needing to be connected online to some certificate authority, or without some extraordinarily difficult pre-installation process, which is often not even possible on a phone.<p>HTTPS was important, but now its being used to shoe horn dependency on centralized online-only authority. Perfectly ripe to censor anyone.<p>1. <a href="https:&#x2F;&#x2F;gitter.im&#x2F;amark&#x2F;gun" rel="nofollow">https:&#x2F;&#x2F;gitter.im&#x2F;amark&#x2F;gun</a>

Does anyone still remember the times when MSIE actually warned you if you were POSTing anything over an unencrypted connection?

This page&#x27;s content is in a div named &quot;mobile-pusher&quot; with a <i>400px</i> padding-right, which then gets disabled when loading a JS script from a third-party domain (ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna-ssl.com). wtf?

Love it, although I&#x27;m sure you can still send video&#x2F;audio in non-encrypted ways right?

This is very annoying for development in my eyes.<p>What is the preferred way to include https in your development flow? Have an nginx or apache running? What about automated tests against a running application?

What took them so long?

They cant even get firefox to properly load (let alone let me pick) all 10 of my webcams.<p>How about making that work, first?

Chrome has been doing it since around 2016, it seems.

In Firefox 73, they&#x27;ll require consent!