In theory there could be personal information in PMs. But when it comes to “web security”, there are a huge number of factors that are often confused:
1. **The risk of malware on your device that logs your personal data and “phones home” to the attacker.** This is by far the most common attack.
- SSL (https://) does NOT protect against this risk.
- As the administrator of BLF, I can’t do anything to protect users from this risk.
2. The risk of somebody tricking you into revealing your password(s) and/or financial information by pretending to be somebody else. This is also a common attack vector.
- SSL (https://) does NOT protect against this risk.
- As the administrator of BLF, I can’t do anything to protect users from this risk.
3. The risk of somebody hacking into the web server and installing something malicious that infects visitors. This is also relatively common.
- SSL (https://) does NOT protect against this risk.
- As the administrator of BLF, it is entirely my responsibility to protect my users against this sort of attack, and I take it very seriously. There are a huge number of best practices for administrating a web server that I adhere to to keep the server as secure as possible. Usually if there is a sudden unplanned maintenance window for BLF, it’s because I’m applying security patches.
4. The risk of somebody hijacking the webpage data while it’s in transit “on the wire” between the web server and the visitor and modifying and/or stealing the data. This is not common.
- This is what SSL (https://) is designed to protect against.
So I don’t see any imminent risk for BLF users by not immediately implementing SSL. I’m sure I will eventually, but it’s not a priority. A frequently overlooked downside of implementing SSL is that it requires significantly more server resources to encrypt and decrypt all the traffic. The BLF server is already under rather heavy load most of the time, and SSL would surely push it over the edge, requiring another server upgrade or even a migration to a different host.