I'm signed in, have an account that's nearly ten years old (not *as* old as yours, but still six digits), have Excellent karma (and have for years), have tried multiple browsers, and still get redirected every time. I'm not a subscriber, (on any accounts; I only have the one) but if that's the difference, I am pissed.

While that's at least an understandable argument, I still don't buy it.
1) People who want to block ads - a significant portion of the site - just block them. I don't imagine the intersection of "people bothered by /. being unsecured and
would also block mixed content" and "people who aren't subscribers, Excellent karma, or just using an ad blocker anyhow" is that big.
2) I have Excellent karma and disabled ads. I still can't use HTTPS. That's a really easy thing for them to check, if they wanted to support HTTPS at all (and this was their reason not to).
3) Some ad networks don't support HTTPS (or at least, don't have a valid cert for their domain name because their content all comes from Akamai or similar), but some (as you point out yourself) do.

There really aren't any valid excuses.

Wow, really? That's several kinds of BS, that right there. Neither security nor privacy should cost money.

Also, that's not mentioned on the FAQ under subscriber perks. In fact, the string "https" doesn't occur anywhere on the FAQ at all. Is it documented somewhere else that I just didn't see?

a) is already taken care of; they have a signed cert in place and set up.
b) is probably the main reason, but you would think that they would be more wise to what their user demographic wants. (But then, there's beta, so...)
c) is not a valid reason. Leaving aside the fact that IE6 traffic has got to be absolutely miniscule on this site - which serves HTML and CSS than IE6 has no idea how to handle - those people could just go on using HTTP. We're not asking them to mandate HTTPS, just to allow it.

As you say, the server load is pretty trivial. Even if you aren't using the new CPUs with hardware accelerated crypto, the vast majority of the CPU time to serve a web application over HTTPS is spent parsing requests and building pages, not doing crypto... and unless you have really excellent caching, the I/O time to do things like database access dwarfs the CPU time altogether. Using TLS typically imposes less than 5% overhead, often much less.

... I have this sudden urge to write a browser extension. I'm not sure *how* I want it to render <sarcasm> tags, but I think I do want it to do so. Just in case.

TLS (or lack thereof) is, or at least should be, completely transparent to the Perl-based web application powering the site. In fact, the HTTP request itself doesn't even specify anything about the protocol. The request line has the path and stuff after it, and the Host header has the domain name, but doesn't mention the protocol. The absolute minimum they should do would be to return *exactly* the same content over HTTPS that they do over HTTP for a given request (remember, the HTTP traffic is the same whether it's tunneled through TLS or not).

In fact, I just checked: the site already uses protocol-agnostic URLs. For example:
<a title="" class="read-more" href="//hardware.slashdot.org/story/14/10/24/2320227/microsoft-now-makes-money-from-surface-line-q1-sales-reach-almost-1-billion"><span>Read More</span> </a> (random link off the home page, note the href="//hardware.slashdot..." URL, which doesn't specify HTTP or HTTPS). Your browser handles such URLs by using whatever protocol the page itself was served over.

They wouldn't have to change a damn thing except to remove the stupid rule that redirects users out of HTTPS. That's a pretty damn minor change.

Of course not. It's added to your requests when they reach the ISP gateway. Why would you expect to be able to see them on anything between you and that gateway?

Where did you check from? You don't see the headers on your end; they're only added at the ISP gateway. Unless you were able to bounce a request off an external web server and see the headers that it *received* - which don't have to be the ones you sent - then you don't know. Oh, and don't use HTTPS for the test, since they obviously can't modify those requests.

USA, so more like every two years for the federal government (this is an election year for congress, though not for the presidency) and it lasts a lot longer than a fortnight (which, it should be mentioned, is a word only very rarely used on this side of the pond) due to the degree of campaigning that people do here (though it's definitely a bigger deal on the presidential years).

No argument on the "tell you what you wanted to hear anyway" part, though! Something so far removed from the few very carefully controlled Major Issues as corporate misuse of licensed bandwidth is going to be completely ignored by both sides (and there *are* only two sides; the media won't even report on any other parties or permit them at the debates). Occasionally some congressthing ("critter" isn't sufficiently derogatory for them) will make some statement (and maybe actually introduce / support some legislation) about such topics, but generally only when pandering to local interests in their districts.

Does that unique identifier get passed down all the way to the server you're trying to connect to, even if you go through a proxy server or reset your router? This is significantly worse than MAC or IP addresses.

This plan. I like this plan! Put a random value in the header on every request. If you're not on Verizon, it'll look like you are (but as a different person every time). If you *are* on Verizon, you may just confuse the software that is adding those headers, or that is logging them. Poison their tracking data with meaningless garbage, and make it *cost* Verizon money to try and track us.

Well, that and use HTTPS everywhere possible, of course. But that requires that the sites you use allow people to do so (*AHEM* Slashdot, looking at you...)

Oh, and don't use Verizon. That's the best way to hit them in the pocketbook, by far. I like the idea of sending the header even when you don't use Verizon though, as a general-purpose "fuck you!" to them.

No, it's actually much worse than that. Slashdot supports HTTPS just fine. They simply force you back to HTTP (using a redirect *out* of HTTPS whenever you request an HTTPS page)! Total bullshit; there's no legitimate reason for such behavior. Even without dedicated TLS hardware, the overhead of HTTPS is pretty trivial for modern servers.

Slashdot actually supports HTTPS just fine. They simply redirect you back to HTTP immediately! Try it yourself: https://slashdot.org/ - 302, Location: http://slashdot.org/index2.pl - 302, Location: http://slashdot.org/

I wish I was joking...

Thank you! Editors, this is a good topic but is a terribly-written submission; with a little cleanup it would be a good front-page item.

Even if the libraries are only used internally, the program using them (presumably iTunes and/or "AppleMobileDeviceSupport" stuff) are vulnerable. OpenSSL 0.9.8d actually has 33 vulnerabilities, according to http://www.openssl.org/news/vu.... It's an over-eight-year-old version, and has vulnerabilities ranging from bypassing certificate validation (permitting man-in-the-middle attacks on the traffic) to memory corruption potentially leading to arbitrary code execution.

1) XP is obsolete; if Microsoft doesn't support it anymore then why the hell should Apple bother? Apple doesn't support their *own* operating systems for anywhere close to seven years! (BTW, Vista is much closer to eight years old than seven.)
2) The up-to-date versions of both of those libraries run just fine on modern Windows versions, so your explanation doesn't even make sense for stupid reasons.