Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Camera and microphone require HTTPS in Firefox 68

blog.mozilla.org

Post reply on HN
Print view View original

141–150 of 215 posts

Re: Camera and microphone require HTTPS in Firefox 68

#141

Post by mort96 »

acdha wrote: post #131
mort96 wrote: post #118

Earlier quoted context omitted.

> This is clearly more complicated than ideal, but it should work. Exactly. Imagine you're someone who just wants to play around with cool web technologies. Maybe you're fairly new to web dev; maybe you're fairly new to the world of programming in general and you're using the web to learn it, which has historically been one of the huge strengths of the web. You suddenly encounter a brick wall, where you figure out th…

This feels pessimistic to me: most people didn’t learn the web that way, instead using shared servers — and there were plenty of similar complaints that it was too hard to learn Unix/Windows admin stuff, too. Today, you can use glitch, github pages, jsbin & a million friends, zeit, etc. or the same cheap Dreamhost account people used $20 years ago and start practicing with HTTPS and many other amenities at minimal co…

I have to imagine the "just open a .html file and start playing" route is a huge vector for getting people into proper programming. I know it's what both I and my brother did. Maybe you don't agree, but I think it's a horrible shame that we're making that route less and less possible by disabling features for anything other than HTTPS.

Glitch honestly looks really good, but I'm a bit worried about telling people that the way to learn programming is to rely on a random for-profit corporation's computers rather than letting people realize the actual power they have over their own machine.

Re: Camera and microphone require HTTPS in Firefox 68

#142

Post by kalleboo »

lucb1e wrote: post #24
klodolph wrote: post #14

Earlier quoted context omitted.

iptables on your phone? I think you would need to root your phone, if it's Android.

I think it's not unreasonable for a techie to be the admin of their own phone. (I still don't get how this is an unpopular opinion.)

As I get older and get other responsibilities, I want to be admin of fewer and fewer things. Same reason I replaced my Linux fileserver with a Synology. I'll let someone else stay on top of the security issue du jour.

Re: Camera and microphone require HTTPS in Firefox 68

#143

Post by comex »

mort96 wrote: post #129
edoceo wrote: post #123

Earlier quoted context omitted.

The burden is a little higher but not insurmountable and it obligates new folks into things they need to know. I think it's an acceptable forcing function. Especially given the security concerns.

What security concerns though? It's not like accessing the camera on a random attacker controlled HTTP page is less secure than on a random attacker controlled HTTPS page. If the user lets a malicious web page access the camera, that's game over regardless. I'm all for doing stuff to tell users that the HTTP page they're visiting is insecure, but telling people who are new to web dev to get a domain and learn how the…

> What security concerns though? It's not like accessing the camera on a random attacker controlled HTTP page is less secure than on a random attacker controlled HTTPS page. If the user lets a malicious web page access the camera, that's game over regardless.

No. But accessing the camera on a non-attacker-controlled HTTP page is less secure than doing so on a non-attacker-controlled HTTPS page, because an attacker could MitM the former but not the latter. (Even if the camera data itself is sent securely, the attacker could just change the host page's JavaScript to send it to a different server instead.)

Re: Camera and microphone require HTTPS in Firefox 68

#144

Post by Avamander »

tenebrisalietum wrote: post #137
marknadal wrote: post #112

This sucks, my community[1] has a local offline-first video/audio call app that we run on a physical mesh network. 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. HTTPS was important, but now its being used to shoe h…

It's been over a year, but I played around with PKI and installing your own self-signed root certs on iPhone and Android (for HTTPS) was not hard.

But having to start exchanging root certs is not trivial in mesh environments, it's also insecure if you have to accept someone else's root.

Re: Camera and microphone require HTTPS in Firefox 68

#145

Post by baroffoos »

asdfasgasdgasdg wrote: post #36
asark wrote: post #6

Dear Apple: for Christmas I'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'd be great. Sincerely, the people who put tape over their cameras, the people who don't because it'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…

I think I understand the risk, and I definitely would not bother with such a switch even were it available. So maybe I actually don't understand it. What exactly is the risk? Have there been any actual cases of someone being spied on with their laptop webcam that would have been prevented by a switch? I'm only aware of cases where the webcam switch would not have helped (e.g. roommate sets up notebook to record owner…

One use case is protecting against non malicious but unexpected use of the camera. For example when you want to join a call with voice only but the app defaults to video and voice. You can have your camera off and mic on and you know for sure you won't be unexpectedly streaming video.

Re: Camera and microphone require HTTPS in Firefox 68

#146

Post by SlowRobotAhead »

cstejerean wrote: post #128
SlowRobotAhead wrote: post #34

Earlier quoted context omitted.

FWIW... I bet you could power the camera, get a still frame at 60fps, shut it down, and not see the led come on. It would be 1/60, 16ms plus or minus the amount of overhead needed, plus autofocus and exposure correction might make it impractical, but it’s definitely not a bulletproof fix.

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.

Re: Camera and microphone require HTTPS in Firefox 68

#147

Post by SlowRobotAhead »

heavenlyblue wrote: post #54
SlowRobotAhead wrote: post #34

Earlier quoted context omitted.

FWIW... I bet you could power the camera, get a still frame at 60fps, shut it down, and not see the led come on. It would be 1/60, 16ms plus or minus the amount of overhead needed, plus autofocus and exposure correction might make it impractical, but it’s definitely not a bulletproof fix.

Apple could simply make the camera take 1 second to activate.

Slow spool up embedded devices... we’re moving backwards :)

Re: Camera and microphone require HTTPS in Firefox 68

#148

Post by comex »

mort96 wrote: post #118
comex wrote: post #111

Earlier quoted context omitted.

If you own a domain, you can add a subdomain that points to the local network IP, and get Let's Encrypt to give you a certificate using the dns-01 validation method (which doesn't require Let's Encrypt to actually access the IP address in the A record). This is clearly more complicated than ideal, but it should work. Edit: You can also use a custom CA root certificate, which can be installed on iOS etc. mkcert is a g…

> This is clearly more complicated than ideal, but it should work. Exactly. Imagine you're someone who just wants to play around with cool web technologies. Maybe you're fairly new to web dev; maybe you're fairly new to the world of programming in general and you're using the web to learn it, which has historically been one of the huge strengths of the web. You suddenly encounter a brick wall, where you figure out th…

I fundamentally agree, but I think the solution is to continue making HTTPS easier to use rather than giving up on security.

For anything on the public Internet, things are already incredibly better than they used to be: HTTPS is free, and there's a wide range of easy ways to set it up on your site, ranging from Caddy (a webserver with built-in Let's Encrypt support) to CloudFlare (who will proxy your site for free including SSL termination). There are still problems – e.g. for all that certbot (official Let's Encrypt client) tries to be easy to use, it's more fiddly than ideal. But the goal of "HTTPS just works" seems clearly within reach, and things can only continue to improve from here.

On the other hand, the situation with local network servers is a complete mess. This includes not just development environments, where "just don't bother with security" is a viable option, but also things like home routers and IoT devices which do want to be secure. Currently, routers tend to just use HTTP, which is insecure if you have anyone untrusted on your Wi-Fi network. IoT devices, of course, tend to route everything through centralized cloud services; there are a lot of reasons for that, and it's easy to blame invidious motives, but I suspect a significant part of the reason is just that it's really hard to make an easy-to-use-device without a centralized service. At a bare minimum, you need to be able to:

1. Securely pair with the device;

2. Connect the device to the network; and

3. Access the device's services over the network, using the existing pairing record to establish identity and prevent a MitM.

(Ideally you would also be able to expose the device's services to the wider Internet, but that's another story.)

You can do this already with a custom protocol, but not with a browser. The closest browsers have to a "pairing record" is asking you to trust a self-signed cert for some random domain, but that's nowhere near the semantics you actually want. After all, it doesn't really matter whether the device controls such-and-such domain; what matters is whether it's the same device you paired with. Meanwhile, trusting random self-signed certs is fundamentally insecure, and (intentionally) difficult to do.

What we need IMO is an entirely new protocol to address this use case, and I think such a protocol might also work for local dev servers.

In the meantime... well, there are always plenty of workarounds.

Re: Camera and microphone require HTTPS in Firefox 68

#149

Post by comex »

marknadal wrote: post #119
comex wrote: post #114

Earlier quoted context omitted.

A browser doesn't need to connect to the certificate authority to validate a cert; only the server hosting the app 'needs' to be online (at least long enough to obtain a signed certificate every so often). The bigger problem is that there has to be a single server hosting the app in the first place, which IMO is a severe flaw in the Web's architecture. But this change doesn't really make the situation worse.

Subnet IPs are always different tho. Can I really get a cert for all subnet addresses? That'd be awesome! Please please educate me. I want to be clear though, I need it so that the user doesn't have to install the cert themselves, or have to be online to approve. Previously, a user would connect to the local wireless network, then the router would open them up to a directory listing of the local apps available on the…

SSL certificates are typically issued for domains and aren't tied to a specific IP address. So you need a domain name, and clients need to be able to resolve that domain to your IP, which means the network needs a DNS server – but the DNS server itself doesn't have to be online at all times, it just has to know what IP to return for your domain. I am not sure how that works with your mesh setup.

Note that some domain validation methods involve the certificate authority resolving the domain to an IP address and trying to connect to it on the public Internet – but not all. Let's Encrypt, for example, supports the dns-01 method, which just requires a custom TXT record to be set on the domain. (But of course the TXT record itself needs to be on the public Internet.) That said, since your goal is to work offline, you may want to use a different CA that issues longer-lived SSL certificates, since Let's Encrypt only gives you 3 months at a time.

Re: Camera and microphone require HTTPS in Firefox 68

#150

Post by shkkmo »

mort96 wrote: post #93
hannob wrote: 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.

Easy:

1) Get a signed certificate for a subdomain on a domain you own (e.g. dev.example.com)

2) Change your hosts file to point any local IP you wish, or setup a DNS entry for that subdomain that points to 127.0.0.1

Post reply on HN