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.
[deleted]
Camera and microphone require HTTPS in Firefox 68
181–190 of 215 posts
Re: Camera and microphone require HTTPS in Firefox 68
#182It 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.
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
[deleted]
Re: Camera and microphone require HTTPS in Firefox 68
#183Earlier quoted context omitted.
Correct. Probably can even configure local network file servers, but better if not. If we don't ever need to use domains in the mesh (we have a separate directory / search system). Wait, I only have to have the certs locally (offline) on the routers? Ahh, hmm, cause you're saying I could MITM it. But Browsers (especially on mobile) all usually freak out when they go to ` https://subnetIPaddress` saying "your connecti…
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 to the Internet. In theory you could work around the issue by redirecting such traffic to your own DNS server.)
As for longest certs, the CA/Browser Forum Baseline Requirements (which all CAs have to follow) specify a maximum validity period of 825 days, or a little over 2 years. You should be able to find CAs offering certs with that period. (Why such a specific number? I have no idea.)
Re: Camera and microphone require HTTPS in Firefox 68
#184It 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.
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
Re: Camera and microphone require HTTPS in Firefox 68
#185Earlier 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.
> especially on mobile where you can't just add your cert as a trusted cert easily
What do you mean? Do some Androids block it? Or iOS? I've got it easily available in settings.
Re: Camera and microphone require HTTPS in Firefox 68
#186Earlier 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.
Not sure if you've heard of NGrok, but this tunnels your server and can be accessed outside of your network with or without https.
Re: Camera and microphone require HTTPS in Firefox 68
#187Earlier quoted context omitted.
It's fantastic that it works with localhost (and I assume 127.0.0.1?), and it's fantastic that it doesn't work with anything else. This is the best middleground.
Would be better if it also supported a new warning / permission to request insecure camera access.
Too confusing. There is already a permission prompt for camera access, so now there'd be two prompts, or it's still one prompt but the text is different in either case, which users can't be expected to understand.
You can go into about:config and explicitly undo this setting if you're in some weird dev corner case where it's a problem, but you should definitely put "Stop doing AV stuff in an insecure context" near the top of your TODO list.
Re: Camera and microphone require HTTPS in Firefox 68
#188Earlier 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.
It's a USB camera. It needs more time than a flicker to turn on and start producing frames. I don't think you could do as you said and still have the camera both work and the LED be dim.
The camera on Macs has actually been a PCIe peripherafor quite a few years now. But your point stands; it still takes a good second or so after the LED turns on for the camera driver to start producing frames to userspace.
Re: Camera and microphone require HTTPS in Firefox 68
#189Earlier 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…
Since we're talking about a Web Browser I'm going to assume we're talking about the Web PKI - certificates that are trusted in common software like web browsers that use TLS.
Leaf certificates in the Web PKI specify one or more SANs (Subject Alternative Names, the "alternative" is because this is the Internet's alternative to the way the X.500 directory system was designed, you don't use the X.500 directory system so you don't care about this) which can each be either an IP address (either IPv4 or IPv6) or it can be any Fully Qualified Domain Name (like bobs-laptop.example.com) from the Internet DNS or it can be a "Wildcard" like *.servers.example.com, which is considered a "match" for any Fully Qualified Domain Name that has exactly one label (a name with no dots in it) instead of the asterisk, so it would batch bigfiles.servers.example.com, and www.servers.example.com but not www.example.com or bigfiles.servers.microsoft.com)
You can get software (such as "Certbot" or "acme.sh") to help obtain trusted certificates periodically from the Internet automatically (at no cost) for a machine which has a Fully Qualified Domain Name on the Internet and is connected to the Internet at least sometimes. You may need to write software yourself to manage actually installing such certificates if your server software is custom - if you use common server software like Apache the tools can do it for you. The no cost option is provided by a charity, ISRG. If you're not a charity and appreciate the service you might consider sending a few bucks their way so they can keep doing this.
If your servers are not ordinarily connected to the Internet, but you do own an Internet domain name (e.g. example.com) you can just make up names for them in that domain and you will be able to obtain certificates for those made-up names, since you control the domain they're your names to do with as you please. But doing this is a bunch more work than the scenario where they're on the Internet.
Re: Camera and microphone require HTTPS in Firefox 68
#190In general, I'm NOT happy with how camera/microphone, GPS and sensors like Gyro/accel/magnetometers and beacons (radio/wifi/bluetooth/nfc), screen size/resolution, battery level, hardware port identifiers etc are accessed by any website or app on my laptop/phone. This developed over the years without any input or choice from the end-user. The device manufacturers, platform owners (Apple, Google, Microsoft, Mozilla) a…
There's no problem with having the capability in a web app. It's only a problem if those capabilities are not consented to b the user first.
There is definitely no problem in having the capabilities in the hardware. But appropriate assured controls should have been built and provided to the end-user. The challenge is these controls are not in hardware-switch-esque form. They are left to the whims and fancies of individual apps. That blame goes to platforms.