To be fair, I haven't had any fraudulent charges in several years: it's quite possible my bank may have such a system now, but I haven't ever had to use it (fingers crossed). The last time was something like 10 years ago, and they immediately froze the account when I called (or did they call me? I don't recall the exact details.) and sent me a new card. The new card came with a little form that itemized the disputed charges and wanted me to (a) verify that those are the charges in question, (b) sign at the bottom to attest to that, and (c) mail it back at their expense (they included a prepaid envelope). I'm sure it was just for the lawyers. Either way, it only took a moment.

I, too, refuse to provide account details to random callers for the same reason you do.

Although somewhat snarky, the subject line sums up my opinion pretty succinctly: as an individual, does it really matter much?

If my credit card gets compromised, by law the most I'm liable for is $50 (and my bank's policy is that I have $0 liability for fraudulent charges). On the few occasions, when my card information has been misused, the transactions were reversed and a new card in my wallet within a day or two. All I had to do was fill out a form saying "I didn't make these charges.", sign it, and send it to the bank. A mild irritation, to be sure, but hardly a big deal. With chip cards now commonplace in the US, simple cloning of cards is less of an issue than it was.

Legally, I seem to recall that debit cards have somewhat less protection, but banks often extend their $0 liability policy to them as well, so long as you report it being lost or stolen within a reasonable time. Still, I dislike these since one is not merely disputing whether or not one owes money to the bank, but rather if one should get one's own money back.

As for bank transfers and the like, I'd like it if the US would add "push" transfers like European banks do, rather than the "payee pull" system it currently has. Still, my understanding is that one is still protected from unauthorized withdraws from one's bank account.

In short: I'm not terribly concerned about my financial information being abused by criminals, as the law and bank policies offer significant legal protections from fraudulent activity. Any such issues are a minor inconvenience. Of course, one should take reasonable precautions, but in general it's not a big deal. I'm a lot more concerned about criminals gaining access to difficult-to-change/cancel things like one's social security number, with which they could apply for new, unknown-to-you accounts in your name. That's much more of a hassle to resolve than simply having a credit card stolen or a bad guy making an unauthorized debit from one's account.

That seems pretty reasonable: all of the listed certs from 2016-09-23 to the present (except on 2017-05-21, I have no idea what's going on there) have been replaced at 2-month intervals, which is in line with the recommendations and when the reference implementation of their ACME client (certbot) renews certs (the certs are valid for 90 days and are renewed after 60 days). Each renewal involves the generation of a new public/private keypair. All in all, seems pretty reasonable.

I agree.

While I appreciate the necessity for manually adding roots (e.g. for internal, corporate resources), I dislike HTTPS snooping and its ability to override baked-in protections against phishing and impersonation of major sites like Google (among many other reasons to oppose such things).

That said, it's one thing for a company to deploy such a system with a corresponding company-owned root across company-owned computers, but another thing entirely for a government to do the same thing to all (or a substantial fraction of) people within its borders. The latter is, with the exception of China and maybe North Korea, bordering on infeasible.

An individual user affected by a one-time event probably won't know, but depending on the remote site and browser used by the user, it may be still be detectable, particularly if used on a larger scale.

For example, Chrome comes with information about authorized CAs and intermediates used by Google baked-into the browser itself, and has since 2011. It will refuse to connect to a "Google" site using an unauthorized certificate (unless manually added by an administrator, for things like SSL interceptors used at businesses, but unlikely in use on a wide scale on the general internet). It sends telemetry back to Google about any bad certs that it sees for Google properties (that's one of the ways they learned about the DigiNotar compromise), and I wouldn't be surprised if such information was also checked for other major sites.

Many CAs also submit records to public Certificate Transparency logs. Google, in particular, uses its standard web crawlers to feed data about certificates it sees into CT logs and has been strongly encouraging (and requiring, in some cases) CAs to submit data to CT logs. This makes detection of falsely-issued certificates quite easy. Perhaps not detectable fast enough to stop an individual, targeted attack, but it should be enough to detect any medium-scale attack on the public internet.

[citation needed]

Sarcasm aside, I'm really interested in reading more about that.

I have Huawei USB cellular modem that identifies itself simultaneously as:
1. USB mass storage, if one has a microSD card in the internal slot. This is handy for storing files and whatnot on the stick.
2. As a CD-ROM drive with a virtual CD containing the drivers needed for the cellular modem functionality, so the user can install the drivers needed while only possessing the stick itself (e.g. no real CD, no internet download, etc.).
3. As a cellular modem.

PAR2 not a filesystem, but rather a means of generating error-correction codes to detect and repair damage to files.

The actual PAR2 algorithm hasn't changed, though development for PAR3 is ongoing. It's simply that one particular implementation, QuickPar, is obsolete, while MultiPar, a similar program that is completely compatible is more modern.

Online.net's C14 service is even cheaper, at EUR 0.002/GB/month plus EUR 0.01/GB for "operations" (such as creating an archive from the temporary staging area, manually verifying archives on demand, or recovering an archive), and offers the same 99.999999999% durability as Glacier. No bandwidth costs and no complicated retrieval speed costs like Glacier, and you can use rsync to upload to the staging area. Naturally, they perform behind-the-scenes error checking and repair, but the manually-selected verification process is nice to explicitly verify that things are intact.

They offer an "Enterprise" level with even more durability for increased costs (EUR 0.004/GB/month + EUR 0.025/GB for operations), as well as a new "Intensive" level that costs EUR 0.005/GB/month with no operations fees (it's intended for more frequent accesses to backed-up data).

Online.net is owned by Iliad, who in turn is owned by Free, a major French telecom, so the risk of suddenly going out of business is low.

Disclosure: I'm a happy C14 user, but otherwise have no connection to the company.

QuickPar on Windows is long-obsolete. MultiPar is the more modern variant.

According to this site, the blood alcohol limit in Germany is 0.05%, not 0.5%. That's a factor of ten difference. The limit in the US, according to the same site, is 0.08%, which is even higher than Germany.

The driver described in this article had a BAC four times the legal limit in Germany.

Because that's how they did it before and they consider it "safer" in the context of not making uneccessary changes this soon to the leap second. In the future they plan to do it 24 hours in advance:

Although we decided it would be safest for Google's infrastructure to handle the 2016 leap second using a 20-hour smear, the same way we handled the leap seconds in 2012 and 2015, this is not the only smear that works well. Many organizations use smeared clocks, and it would be helpful if the smears were the same. After all, the purpose of clocks is to read the same time in different places.

We would like to propose to the community, as the best practice for leap seconds in the future, a 24-hour linear smear from noon to noon UTC. We plan to use this smear starting from leap second #38, which is likely to be in 2018.

Source: https://developers.google.com/time/smear.

By "shorter keys" I mean "shorter certificate validity periods". Sorry for the confusion.

The security aspect (in regards to revocation) of shorter keys is nice, but encouraging automation to make widespread HTTPS use easy is the whole point of Let's Encrypt. It shouldn't be a surprise that they set cert lifetimes to encourage automation.

Without automation, deploying secure sites is a pain: administrators have to go through tedious, error-prone manual work that the typical mom & pop business or individual website won't bother with. This maintains the status quo, with not many sites being secure.

With automation, the user who otherwise wouldn't deploy HTTPS simply clicks a button on their web host management interface and Presto!, their site has a cert. (Alternatively, HTTPS could be enabled by default for them, as it is with WordPress.com-hosted sites.) For more technical administrators, a simple command-line tool and a cronjob take care of things in seconds. Easy, and it promotes a more secure web.

There's nothing magical about 90 day certs, and the timing was chosen to be short enough to encourage automation while being long enough to allow for manual renewal if needed. Indeed, they even say, "Once automated renewal tools are widely deployed and working well, we may consider even shorter lifetimes." That's fine with me: it's no skin off my back if they start making certs only valid for a week or two, as a daily cronjob manages everything.

Of course, your mileage may vary and you have your preferences. That's totally fine -- I too use non-LE certs for some internal services where automation isn't really viable -- and nobody's forcing you to use their service. It's a free internet, after all, and there's other CAs to choose from.

I don't know of any one-stop-shop (certificate issuance and backup MX service are pretty orthogonal to each other), but there's plenty of CAs out there that will issue you certificates.

This Comodo reseller sells PositiveSSL certs for ~$5/year with a validity time up to 3 years. That's about as cheap as you can get. They also offer (for the next few weeks, at least) GeoTrust, Symantec, and Thawte certs, but the costs for those are higher and they'll stop selling them in December. Comodo offers free S/MIME certs that validate only your email address, as well as paid ones that validate your email and name (if it matters). The paid ones start at $12/year.

Of course, Let's Encrypt is a good option: the certs are free and you can run any of a multitude of ACME clients (or write your own) to validate your domain, generate the key (which is made by and stays on your system), request the certificate, and install the certificate. A simple cronjob handles renewals without any interaction from you. That makes life really easy. They don't do S/MIME certs, though.