... 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.

I'm going to assume you meant to say "hundreds of thousands" and that English is not your first language. I'll give you the benefit of a doubt that far.
You're going to have to provide a citation for the actual value, though. According to the estimates that I've read, you're off by two orders of magnitude (that is, it's a few thousand deaths, not tens much less hundreds of thousands). http://en.wikipedia.org/wiki/C... (Estimates of human deaths due to radiation from Three Mile Island and Fukushima - neither of which killed anybody directly - are in the single digits.)

How do you justify the claim that mining accidents don't count, by they way? The extraction of the fuel is certainly a part of the cost - both in money and in lives - of running a power plant.

You sound like somebody who has made some assumptions, decided they are facts, made more assumptions based on them, and continued on until you have an entire encyclopedia of "knowledge" that has no basis in reality. For example, you appear to believe that mining, refining, and transporting uranium is dangerous. None of those are really true. Uranium mining per unit volume is comparable to coal mining for the same volume, but the volume of coal used by a single commercial power plant in a day is more than the volume of uranium fuel used by all the world's reactors in a year. Refining and transporting uranium is *expensive* (because people are so cautious about it, and so afraid of terrorists getting ahold of it) but not actually unsafe; until combined into fuel rods for insertion in a reactor assembly, fuel-grade uranium is safer to transport than, say, natural gas or gasoline (petrol). It's already obvious you didn't look up any statistics about Chernobyl, either; you appear to have just decided that "lots of people died" -> "lots" of deaths must mean hundreds of thousands -> "hundred[s of] thousands dead after [C]hernobyl..." May I recommend using facts based on observations instead of guesses in the future?

The other thing to remember about those reactors is they assume the availability of the ocean as an effectively limitless source of reasonably cool water. This influences aspects of their design from basic operation to last-ditch emergency measures in ways that just don't apply on land. Sure, you could build a bunch of them along the coast, but offshore construction on that scale is not cheap (and then you still need to get the power to the cities that need it). Worth investigating, but not an obvious win.

Some of the things that would be really great to launch - say, a "Project Orion"-style nuclear pulse rocket (NPR) - aren't feasible without a tremendous mass. NPRs can actually accelerate faster the more massive they are, because they can take the impacts better.

Putting 1000 tonnes in orbit - which would be a *small* NPR - would take about as many launches to build as the ISS did... if we can use the Flacon Heavy for each one. That's ignoring the cost and risk of assembling it in space (and the cost is high, because that means you need to get the equipment and people into orbit too, plus the infrastructure they require). The pusher plate of an NPR is, by itself, probably going to be too heavy for a Falcon Heavy, so it will need to be constructed in space... which would basically mean an entire orbital foundry!

Some things just don't break down into little pieces in an economical fashion.

My approach would be more along the lines of "convictions only stay on your record for a limited time". This solves the "basically serving a life sentence" problem that is so common in the US. Say you get arrested on a minor charge, convicted to spend three months in prison... and upon release if you go a year without any further convictions, your record is considered clean and you can legally claim you were never convicted at all. There might be some *specific* scenarios where the probationary term would need to be effectively your whole life, or where some things would always be present in your background (child molester trying to get a daycare job even forty years later, for example), but otherwise have the crimes simply disappear from your public record.

With that said, the system in the Netherlands does sound quite reasonable, and I'm not sure there's any need to reinvent the wheel. My approach is based more on the idea of demonstrating rehabilitation (the 1-year period in the example would probably vary depending on the sentence and possibly also on prison behavior, much as how the time behind bars itself is variable) than on strictly categorizing offenses, but either way is a lot better than what the US has right now.