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.
autossh -L 2080:localhost:80 192.198.1.14
Firefox will believe that your service is local, and will allow the activation of the camera and the microphone even though you do not use https.
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 good starting point:
What do you mean? Do some Androids block it? Or iOS? I've got it easily available in settings.
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
chrome://flags/#unsafely-treat-insecure-origin-as-secure
> 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.mozilla.org/show_bug.cgi?id=1410365
The last comment proposes a whitelist for development domains, but no response to it.
ths helped me (with the 68.0 win edition):
about:config
set the
media.getusermedia.insecure.enabled
from false to true
Specifically, you need HTTPS for WebRTC, but you obviously have to use a self signed cert because local IP. You can ignore the cert error and load the page, but connecting to the websocket for signaling will still fail because websocket on iOS requires a non-self-signed cert.
Non-HTTPS websocket would work, but not from a HTTPS host. So you're in a situation where you need HTTPS due to WebRTC, but you can't use HTTPS due to websockets.
In trying to push people to HTTPS by disabling features on HTTP, we're making development a _much_ worse experience. I'm not sure that's right.
I use xca[0] to create/manage the root CA and the certificates, but there are other tools to do this.
Not true at all, SSL certs have nothing to do with IP of the servers that use them, the servers just have to have the correct private key for that cert.
You can make any domain point to local IPs by using the hosts file or even editing DNS directly.
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.
I do wish there was a public solution offering this type of easy dynamic DNS with https. (Sharing the script I wrote could cost a lot on dns hosting and increased server expenses.)
> adb reverse tcp:3000 tcp:3000
openssl genrsa -out key.pem 2048
openssl req -new -key key.pem -out certificate.csr
openssl x509 -req -in certificate.csr -signkey key.pem -out certificate.pem
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...
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.
This power balance has to change.
There are leaked schematics of MacBooks online (that unofficial repair shops use) so if you want to investigate this I'd expect it to be a good place to start.
(For video, anyway. I don't see any similar solution for audio.)
1. If it does happen to light up, what would you do, turn off your computer? That's shitty.
2. What if your AFK and aren't looking at the light?
Correct. And that was my reason for NOT covering the camera. Because I would be able to see if it was on due to some malware. However, I did not expect a vulnerability like Zoom's, where a simple website would be able to trigger a webcam. Combined with external monitors, the LED would be potentially missed for a good amount of time. So I've reversed my position since then.
Edit: Just tested on my MBP. Opened photo booth, covered the camera with my thumb, shone a bright flashlight at the point just left of the camera. The display got brighter but Photo Booth showed no changes in what the camera was seeing.
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 naked). Even that is incredibly rare, or if not rare, almost never reported.
https://www.dailymail.co.uk/sciencetech/article-5228017/Hack...
https://www.dailymail.co.uk/news/article-2638874/More-90-peo...
https://globalnews.ca/news/2158281/what-you-need-to-know-abo...
https://www.telegraph.co.uk/technology/news/10131456/Hackers...
This site claims a guy made a business selling software to hack and remotely control webcams, complete with paid employees and $350,000 in income:
Also, there are many security programs that can seruptitiously take photos or videos using the camera. Usually this is to help in recovery after theft.
People would get someone infected, and then share the credentials so everyone could watch. So, I personally know of a handful of people that were spied on 20 years ago.
https://en.wikipedia.org/wiki/Robbins_v._Lower_Merion_School...
The use case is that you leave them turned off by default in case someone pwns you, and only turn them on when you need to use them.
Still miss the physical mic mute button on my old Thinkpad X230... and it didn't have a webcam button for that, but we've _almost_ had all of the right features in the past...
https://en.wikipedia.org/wiki/Berkeley_Software_Distribution
Smartphones , for all their faults , at least are far less vulnerable to viruses than pcs.
Or at least iOS vs Mac.
In this case the camera or microphone is the least of your worries.
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 horn dependency on centralized online-only authority. Perfectly ripe to censor anyone.
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.
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 network (like the video/audio call), they click the link (just points to the dynamic subnet IP of a static file server) to load the offline HTML page which then connects to call anyone in the network, including users on neighbor and neighbor-of-neighbors routers.
Basically our own decentralized telecom!
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.
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.
> Subnet IPs are always different tho. Can I really get a cert for all subnet addresses?
SSL certs don't usually have anything to do with the IP address, that is usually handled by the hosts file / DNS entries.
There is no reason the non-profit can't get a domain and a free SSL cert and distribute that cert and it's private key with the router software as a default while allowing admins to install/configure their own domain and SSL cert.
The router can then MITM all requests to that domain using a SSL termination proxy for the file server.
Are you sure you don't want confidentiality on the audio/video calls on your network? After all it's passing through all the mesh nodes and vulnerable to eavesdropping.
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?
This is still mildly annoying.
How about making that work, first?