151–160 of 215 posts
Earlier quoted context omitted.
Perhaps it would be if the license was different.
Unlikely. The Apple kernel guys are purists and would probably use the BSD kernel even if Linux were MIT licensed.
I bet they were considering it.
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…
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.
Earlier 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.
When it doesn't work on anything other than localhost, you can't host a web server on your dev machine and test how it works on your phone. I've been through the hell of trying to test WebRTC applications on mobile Safari, and it's horrible. 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…
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.
How about making that work, first?
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.
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…
> 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.
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.
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.)
Earlier quoted context omitted.
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…
It may be, but just open an HTML file and write an app using your camera and microphone is not something that is typically the result of doing just that (nor should it be).
Putting some effort into figuring out how the pieces fit together is not a bad thing. You can still set up HTTPS if need be without having to rely on a for-profit corporation. It's trivial to install a self-signed cert in iOS and OSX the last I checked (and I seem to remember it wasn't so hard in Windows either). It was excruciatingly bad in Android (well, mostly missing IIRC) around Gingerbread — but that too is a good example of why using products built by people with no comprehension of how to secure things is bad.
A learning curve is not inherently bad, but beyond that, especially with something that has such huge security implications, some understanding of WHY you should be encrypting camera fees is something I'd want any dev working on a camera/audio recording app to understand. There's a reason that while CB radio is easily accessible, there are barriers to entry for Hams. With power comes responsibility.
Earlier quoted context omitted.
Have you noticed that the people who tape up their laptop camera almost always still carry around a smartphone in their pocket 100% of the time.
A smartphone is significantly more secure than a computer. I install lord knows what NPM package from God knows where on a weekly basis. Only since very recently does mic or camera access cause any kind of system prompt on Mac. Smartphones , for all their faults , at least are far less vulnerable to viruses than pcs. Or at least iOS vs Mac.
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…