"ACC does not use HTTPS, so, if you're on a public WiFi network, or if you have a virus on your device, it would be easier for an attacker to read your login information.
ACC has never used HTTPS before, so it's not a "new security issue", so not exactly a worry. The only difference is that the latest iOS update adds this warning if it guesses that there's a login form on the page. The "User Name Lookup" triggers it if you focus on it, as well as a few other pages."
I don't really have much to lose by someone finding out my login here, but for members who use ACC on public WiFi and don't come up original passwords, it would be beneficial to have ACC secured.
With HTTPS now being fairly standard for webpages, we should consider making ACC secure if that's not already planned for ACC 2.0.
Yes, unfortunately there is no version of IIS that is both old enough to support many of the language features we rely on and new enough to be easily configurable for HTTPS. So it's something that's not really possible at the moment.
I suppose we could set up a reverse proxy, but I'm not a big fan of that because it falsely indicates that the site is "fully secure". It would protect against bad actors local to users (e.g. on public Wi-Fi networks or with nosey ISPs), but on the other side of the proxy we would be funnelling all requests through a single unsecure channel, so it would actually be easier than it is now for someone to intercept all traffic from all users. Also, it would require Jader to change DNS settings, and getting him to be online at a convenient time is its own problem.
ACC 2.0 will be fully protected with HTTPS.
There's no place like 192.168.0.0/16.