It's 2016, and Instructables is owned by a big company now. Why does it still not support HTTPS successfully? Answered
(I thought there was a forum for topics about the Instructables website itself, but apparently not, so I'm putting this in Square Pegs.)
Posting this publicly poses no risk to the security of the Instructables website or any user's account. Any attacker who would use this information (which is pretty much all of them) would be able to figure it out on their own more easily than finding and reading this post. It is extremely obvious to anyone who simply looks at the address bar while visiting the website. (I would be very surprised to learn that no one has taken advantage of it already, if that can even be proven.)
Instructables appears to be severely behind the times when it comes to keeping its users' accounts safe from hacking, and their communications secure from eavesdropping and tampering.
Just about everyone who runs a website or is very active online these days knows the importance of having a secure HTTPS connection between your computer and the website's server. (For anyone who hasn't been paying attention for the past ten years or so, here's a Wikipedia article about it.) Like any security-conscious Web user, I'm reluctant to log into any website that doesn't use HTTPS, especially when I'm on an Internet connection that's not my own. (Just look up Firesheep to see why.)
In the early years of the Web, HTTPS didn't exist, and every webpage was loaded and every form was submitted insecurely.
Then HTTPS was developed. For years, many websites used HTTPS just for their login pages, and used HTTP (i.e. insecure communication) for the rest of the site, once you logged in. This was better than only HTTP because it kept man-in-the-middle attackers from seeing your password, but they could still manipulate the content you saw or the actions you took after logging in, or take over your session using Firesheep. At that time, website operators didn't want to use HTTPS for their entire sites because it would slow down page loading.
These days, however, most websites that you can log into use HTTPS for everything, because it's more secure and there's no longer any reason not to. HTTPS is now much faster than HTTP, because it allows more optimization and compression.
The only websites I can think of other than Instructables that let you log in insecurely are those that don't support HTTPS at all, mostly small-time forums operated by people without much website administration expertise.
It appears that Instructables has made some attempts to support HTTPS, as evidenced by this forum topic from 4 years ago. That was a complaint that the certificate (from Fastly, the CDN Instructables uses) wasn't valid for Instructables and was therefore rejected by the user's Web browser, preventing a secure connection. One of the replies mentioned that a secure login page was available at https://ssl.instructables.com/account/login, and that login page is actually still available.
However, it is not linked to from any other page that I can find, meaning that everyone who doesn't know about it (i.e. the vast majority of users) is logging in insecurely, meaning that the sentence "When sensitive personal information is transferred over the Internet, we encrypt it using Transfer [sic] Layer Security (TLS) encryption technology or similar technology." in the Autodesk Privacy Statement is factually incorrect about Instructables. Furthermore, working HTTPS doesn't seem to be available at all for the user account settings, meaning that when a user changes their password, both the old password and the new password are transmitted insecurely, which also makes that sentence incorrect.
Additionally, when I try to use HTTPS for any other Instructables page, it doesn't work. https://ssl.instructables.com redirects to https://www.instructables.com, while https://www.instructables.com results in the above mentioned certificate error because the certificate Fastly is using doesn't include Instructables on the list of (many) sites that it's valid for. (I can bypass the certificate error and load Instructables over HTTPS anyway, but this is a bad security practice, and the connection does not stay on HTTPS as I browse, making it pointless.)
In summary, Instructables seems five to ten years behind the rest of the Web when it comes to user account security.
However, I think this could probably all be solved pretty easily, by asking Fastly to enable (or fix, if it's supposed to be enabled already) HTTPS for the domain [www.]instructables.com, and either changing all links to point to HTTPS URLs or (preferably) enabling HSTS, which will cause all users to use HTTPS regardless of the URLs they type or the links or old bookmarks they click. This would likely have the side benefit of speeding up page loading for all users.
P.S. The lack of HTTPS has also caused me to worry about another aspect of Instructables account security. The Privacy Statement says nothing about how users' credentials are stored on the server(s) to prevent breaches of sensitive information by malicious attackers, negligence, disgruntled employees, etc. (It only says that employees are only allowed to access users' information if they need to to perform their duties, and that data is securely destroyed when no longer needed.) Does Instructables use industry-standard salted hashing (SHA-1 or better) to keep users' passwords secure on the server(s)?