You bring up a valid point. Based on the description of your problem, I would consider this to be a bug that should be resolved by the SE team by adding a valid SSL cert, either specifically for
www.superuser.com, or for
Account security is a very important subject, and SE has been investing lots of time and resources into getting SSL working across all their services. This is a commendable effort, but SSL is still a work in progress for them, and they have not had the time or resources to get certificates issued for every domain and subdomain.
www.superuser.com is a valid way to access Super User, even if it's not the preferred way.
Both no-www and yes-www -- two disagreeing camps on whether or not to use
www in URLs -- agree on the point that every website should be accessible via both the "naked domain" (e.g.
http(s)://superuser.com) and via its
www. equivalent (e.g.
As of now, we have the following situation:
http://superuser.com -- Works fine.
http://www.superuser.com -- Works fine, redirects to
http://superuser.com, compliant with no-www standards.
https://superuser.com -- Works fine for protecting your session cookie. Some site resources are loaded over unencrypted channels, but this is only a risk for content injection; the browser security model still makes it difficult to extract the session cookie cross-domain without obtaining local user trust, which is generally not practical. So you get a security upgrade, and otherwise the site is fine.
https://www.superuser.com -- Broken! There is no standards justification I can find to support leaving this broken, and it's liable to scare away or discourage at least a couple users.