Live data from Hacker News

Camera and microphone require HTTPS in Firefox 68

blog.mozilla.org

201–210 of 215 posts

Re: Camera and microphone require HTTPS in Firefox 68

#201
post #93
post #50

Earlier quoted context omitted.

> It would be nice if it also worked on local IPs, like 192.168... That would defeat the security purpose. Anyone within your local network (which practically speaking very often means the next Wifi your device could find) could attack you.

But how do you do local development when you can't get an SSL cert for your dev machine's server? No, self signed certs don't always do what you need, especially on mobile where you can't just add your cert as a trusted cert easily.

[deleted]

Re: Camera and microphone require HTTPS in Firefox 68

#202
post #2

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

in order to replicate or simulate a production environment i sometimes do something like this:

ip route add local 192.0.2.123/32 table local dev lo

which makes your system act like this is a local address without actually being one.

EDIT: nvm i just realized that wont solve your issues with mobile development...

Re: Camera and microphone require HTTPS in Firefox 68

#203
post #175
post #51

Earlier quoted context omitted.

> (I still don't get how this is an unpopular opinion.) Not unpopular, just unrealistic. You can't do it on an iPhone, and if you're doing local web development you really ought to be checking it on an iPhone.

If you're doing local web development, then running the iOS simulator will give you the necessary Safari iOS Web view controls.

It won't get you the necessary touch interactions if you're doing something that uses them, though.

Broadly speaking, you want to test on the actual device your users are using, not an approximation of one.

Re: Camera and microphone require HTTPS in Firefox 68

#204
post #183
post #179

Earlier quoted context omitted.

You won't have to buy certs from LetsEncrypt, they're provided free. So you'd have to have an external DNS that allows you to provision DNS records for mymesh.example.com and request a wildcard certificate for that domain. The script is automated and will ensure that the certificate is always up to date. Inside the mesh you would need: * Have an internal DNS that resolves myserver.mymesh.example.com to an internal IP…

To further clarify, running an internal DNS server doesn't require a MitM, as the DNS server address for a network is generally supplied as part of DHCP. (There is one reason you might want to do a MitM, but I really don't recommend it. Namely, some people change their settings to ignore the DHCP-supplied DNS server and hardcode an address, e.g. 8.8.8.8, which they would fail to reach if the network isn't connected t…

It is true, instead of MITMing the HTTP request, you can MITM the DNS request. The issue then is that you need to distribute and configure the private key and certificate on all the static file servers rather than just on the router

Re: Camera and microphone require HTTPS in Firefox 68

#205
post #191
post #152

Earlier quoted context omitted.

> Imagine you're someone who just wants to play around with cool web technologies. Maybe you're fairly new to web dev; Then... you can do it on localhost. I can't really image the new web dev that is using separate computer on their local network as a dev server but can't figure out how to get a Let's Encrypt cert to use.

False. Usually it’s just as easy if not easier to configure your dev server to listen on 0.0.0.0 instead of 127.0.0.1, and these days most sites are mobile first, so it’s very natural to develop on your computer and test on a phone in the same LAN. Figuring out accessing your computer via 192.168.0.x is way easier than figuring out how to issue a LE cert (the easy part) and use it on your dev server (the hard part).…

> Figuring out accessing your computer via 192.168.0.x is way easier than figuring out how to issue a LE cert (the easy part) and use it on your dev server (the hard part).

It really isn't that hard. I still can't imagine this hypothetical "new dev" who is doing cross-browser testing of this specific feature but can't install a simple SSL cert or get help doing so.

This isn't a barrier for entry to new developers, this is a specific use case that requires learning a minor, otherwise useful skill to get around. I think that is a totally reasonable trade-off.

Re: Camera and microphone require HTTPS in Firefox 68

#206

Earlier quoted context omitted.

Mozilla’s previous blog post on the topic says > Mozilla will provide developer tools to ease the transition to secure contexts and enable testing without an HTTPS server. https://blog.mozilla.org/security/2018/01/15/secure-contexts... But the bugzilla entry they linked to with that has been unassigned for two years, so maybe they changed their minds or figure the localhost exception is sufficient. https://bugzilla.m…

for easy bypass this guard - ( for rapid development / testing ) - and dont have a localhost environment ths helped me (with the 68.0 win edition): about:config set the media.getusermedia.insecure.enabled from false to true

Good to know! I'm leaving it alone on my main FF installation, but I've set that in Developer Edition.

Re: Camera and microphone require HTTPS in Firefox 68

#207
post #95

Earlier quoted context omitted.

As a layperson in this arena, I'm skeptical as to whether it's a great solution. Is it possible to turn the camera on and off very quickly? If so, a smart hacker could do that really quickly and if the owner ever notices they would probably think there is a problem with the electrical rather than thinking they are being monitored.

If you install Oversight, you can get persistent notification center alerts for most mic and cam activations (of course, it likely won't help if you have targeted malware that knows how to disable/uninstall Oversight) - https://objective-see.com/products/oversight.html

Or MicroSnitch

https://www.obdev.at/products/microsnitch/index.html

Re: Camera and microphone require HTTPS in Firefox 68

#208
post #23

Earlier quoted context omitted.

For local development, Chrome has a flag that lets you force specific origins to be treated as secure: chrome://flags/#unsafely-treat-insecure-origin-as-secure I don't think Firefox has anything equivalent though? This bug on the topic is unassigned: https://bugzilla.mozilla.org/show_bug.cgi?id=1410365

Interesting! Though I find that behaves rather strangely – seems to clear itself on every launch.

Yea that's annoying, but I believe that's intentional... you can pass that flag in as an arg when you launch chrome though so you don't have to set it up each time.

Re: Camera and microphone require HTTPS in Firefox 68

#209

Earlier quoted context omitted.

You continue to miss the point. Its not a question of _why_ I trust my compiler or my computer. If you trust npm packages and ship them then that's not malpractice. Its about admitting you _don't_ trust npm packages, but you go ahead and use them anyways. That is malpractice, because you admit you know better but take action anyways. "I know this procedure may do more harm than good, but I will perform it anyways bec…

Trust? I don’t even trust my eyes.. :) Though yes, if laziness is what makes it malpractice, then I’m the Jack Kevorkian of IT. I plead guilty.

Glad were in agreement :)

Re: Camera and microphone require HTTPS in Firefox 68

#210

Earlier quoted context omitted.

How much would you bet?

Considering I have a device here that has an I2C camera and in firmware I can turn it on and off at right around 25ms, I’d consider betting quite a bit. Instead of being snarky, how about you explain why this isn’t possible. Even if it was 100ms almost no one would catch that.

I’m not being snarky, and we’re not talking about some random device you have. We’re talking about the camera on a Mac. The bet is that you can’t turn it on and off so fast as to be un-noticeable because there is a noticeable delay between that light turning on and getting an image from that camera. So I’ll gladly take the other side of that bet.
Post reply on HN