But surely, then, you remember that science doesn't stop at the question. You need to actually do research. In climate science, that means collecting data and building a model. I think it is noteworthy that no AGW opponent has built a model.

You can call them anything you want, but they are following the scientific method to the extent allowed by the nature of an observational science. They self-identify as scientists. AGW opponents do not have a single model that they can point to, and as far as I know, no prominent AGW opponent is working on a model. They can self-identify as scientists if they want, but they certainly aren't sticking to "their" philosophy.

Thanks for the high-res version. Is there some technical reason that they omit the ocean data? I would think the oceans have quite a bit of photosynthetic activity!

Whatever the environment, there are jobs that require someone just to be there waiting for something unusual to happen. Even in the nuclear missile bunkers, I bet they spend about 95% of their time sitting around waiting for an alarm they hope never comes. You can only clean so much before it's time to lean. So what if OP works in a clean room? I bet there are plenty of "I'm paid to sit here" jobs in there, too.

I recently moved from hand-written HTML for my personal site to Jekyll, which is the engine that powers GitHub pages. It does exactly what I want from a CMS:

• Cleanly separate content and presentation.
• Provide easy-to-edit templates.
• Allows all of the content to be stored in a VCS.
• Generates entirely static content, so none of its code is in the TCB for the site.

The one thing that it doesn't provide is a comment system, but I'd be quite happy for that to be provided by a separate package if I need one. In particular, it means that even if the comment system is hacked, it won't have access to the source for the site so it's easy to restore.

How is your LAN secured? If it's wired, then I assume that you know about ARP poisoning attacks. If it's wireless, then I assume that your post was intended as a joke.

That's the best way of securing a connection, but it doesn't scale. You need some out-of-band mechanism for distributing the certificate hash. It's trivial for your own site if you're the only user (but even then, the right thing for the browser to do is warn the first time it sees the cert), but it's much harder if you have even a dozen or so clients.

The 'brought to you by' box on that site lists Mozilla, Akamai, Cisco, EFF, and IdenTrust. I don't see Google pushing it. They're not listed as a sponsor.

That said, it is pushing Certificate Transparency, which is something that is largely led by Ben Laurie at Google and is a very good idea (it aims to use a distributed Merkel Tree to let you track what certificates other people are seeing for a site and what certs are offered for a site, so that servers can tell if someone is issuing bad certs and clients can see if they're the only one getting a different cert).

It depends on your adversary model. Encryption without authentication is good protection against passive adversaries, no protection against active adversaries. If someone can get traffic logs, or sits on the same network as you and gets your packets broadcast, then encryption protects you. If they're in control of one of your routers and are willing to modify traffic, then it doesn't.

The thing that's changed recently is that the global passive adversary has been shown to really exist. Various intelligence agencies really are scooping up all traffic and scanning it. Even a self-signed cert makes this hard, because the overhead of sitting in the middle of every SSL negotiation and doing a separate negotiation with the client and server is huge, especially as you can't tell which clients are using certificate pinning and so will spot it.

Every HTTP request I send to Slashdot contains my cookie, which contains my login credentials. When I do this over a public WiFi network, it's trivial for any passive member of the network to sniff it, as it is for any intermediary. Worse, because it uses AJAX stuff in the background, if I briefly connect to a malicious access point by accident, there's a good chance that it will immediately send that AP's proxy my credentials. I've been using this account for a decade or so. I don't want some random person to be able to hijack it so trivially.

Given hoe poorly most people secure their WiFi, having a warning if you're using a DVR on a LAN and it doesn't support end-to-end encryption sounds like a good plan to me. Of course, this raises an interesting question about built-in obsolescence, given that certificates have a valid-until date.

Thanks, I did not know that. But to be clear, this does not create junction points... this is the "official" method that I reference. I don't want people cutting-and-pasting Users :)

I'm thinking (hoping?) that normal disk caching would take care of stuff like that. Honestly, I'd just use the supported method unless your SSD was very, very tiny. I use the junction point method because I wipe out the C: drive from time to time to avoid Windows cruft. Every so often I apply Windows updates and re-baseline.

You're right, but it's not always the devices within the same product category. A lot of stuff that's in consumer devices begins life in very niche applications (e.g. military or medical devices) to get the first bit of R&D funding and then needs another big chunk to become cheap enough for consumer devices.

You misunderstand. It might not be free for you, but it's free for the fish...