You might have noticed that some web browsers are displaying a scary looking “Not secure” warning for BLF. Everything is normal, and there is NO reason for concern.
Basically, it has to do with the simple fact that BLF doesn’t use SSL (the https:// protocol). Since BLF doesn’t process any sensitive information it’s not imperative to implement SSL. The site has NOT been compromised, nor does it have viruses or anything of that nature. It’s just an overly-alarming warning from the browser that it displays on all sites that use the http:// protocol with any sort of user login feature.
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.
I use the pickiest Android browser (Chrome), and I've not seen a single warning.
Now that we're here sb56637, I am going to suggest a forum improvement in emojis/emoticons. The available range via simple post editor is a little bit :(( limited and definitively :X outdated (and not to say the advanced post editor is a @#$% in this regard) . I know you just have to host a good handful of emoji images and make them available for insert via some small applet, there are plenty of nice emoji sources free to use nowadays. Hijacking outside bandwidth to make use of them is uncomfortable and worries me a little bit.
He didn’t say it was secure, just that it wasn’t necessary to be secure…as we don’t process transactions on the site or share detailed personal information.
Its Google they updated the verification process and if a website doesn’t have a SSL its flagged as unsafe they want all servers/websites to use HTTPS. Is the issue only with Chrome?
The problem is not the installation of a certificate, but all the other services that are only available through http. You will get an unsecure/mixed content loaded message (there is a workaround: Load all external content through BLF server).
And G00gl€ can $#%& my @#%$ with the security stuff and whatever, by the way. They get bully with sheesh and I hate that. I've posted a few messages in the G00gle help forums and its surprising to see how awkward and @#$% is the code/engine which runs them. Its a unbelievably freakin' mess.
G00gl€, Appl€ and the dimwits feeding them blindly need a flogging.
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.
I use a unique password generated by Lastpass for each and every website. That said, I don’t give out personal information on websites that are not secure. Plus, I use a VPN. I’m no expert, but I think I’m a couple of steps above the average Joe.
My home ISP injects advertising into web pages that are not encrypted.
My cell ISP severely reduces the quality of the video clips I text out if they can process them. (non iMessage encrypted deliveries)
If they have the balls to do that, they have the balls to profile me based on comments I post on BLF. For that reason I wish BLF had SSL.
With regards to advertising I have it blacklisted by default on Android thanks to AdAway (root). It can also be done by other means on Windows (done it) or Linux machines.
Adverts are an unnecesary pester illness in my honest opinion. I never buy based on advertising alone (if at all), but rather on my own needs and objective reviews.
That’s just not true. At very least, BLF processes email addresses during registration. If my contact information doesn’t fit your definition of sensitive, what more do you want?
It’s not good practice, but I’m sure enough users also use a generic password for this site as well - that could definitely be considered ‘sensitive’, depending on what else it’s used for.
me a little bit.
