A year behind is typical for corporate users. Selected security patches get applied after thorough testing, but unlike a home user a corporate IT department can't simply apply any update Microsoft sends down. They have to insure that every bit of software they run, which is overwhelmingly not from Microsoft, is compatible and runs correctly with the updates applied to Windows, and is supported by the vendors. That's the major reason why corporate systems were running Windows XP for so long after Win7 came out, they had a lot of software that wasn't certified for or flat-out wouldn't run on Win7. It's why Win8 and 8.1 have so little adoption in the corporate world. Hardware is typically on a 3-5 year lease term, and other than security patches the OS typically doesn't change until at least it's time to replace all the hardware. Corporate IT departments can't and don't run their systems the same way a casual home user does.

... Long live the version number. We saw it with Windows 95/98, XP and Vista, despite the names they still had nice conventional version numbers just like earlier versions. You just had to know where to look for them. MS may remove visible version numbers from Windows, but they'll still keep adding functionality and making backwards-incompatible changes which means software will still need some way of telling whether the system it's installed/running on supports the functionality it needs. Application developers being too lazy to write the large chunks of code needed to probe every single API they want to use and test for which specific variation is present, and the Windows team not having the time/resources let alone the inclination to go back and retrofit everything in Windows with individual version numbers or feature/variant flags, that means a version number that can be incremented to indicate the point at which a particular API or variation became available that app devs can easily test. And of course corporations are going to demand some way to make sure that the Windows 10 machines they buy in 2017 will run the Windows 10 image from 2016 and that the 2017 "written for Windows 10" software will actually run on machines using that image.

Where's the "three strikes" policy now?

Let me answer that with a question: where are the three strikes? Can you cite me the court case(s) where a judge has ruled that infringement has occurred?

People who know stuff don't cause me any stress. It's people who think they know stuff but don't that cause the most stress, and I haven't found Millenials to be much worse in that regard than any other age group. More often it's that they do know and what they're asking is entirely reasonable, it's just prohibited for silly reasons. Eg., they come in wanting their phone to just work with the Exchange server. Yes, it should just work. Exchange supports all the protocols needed for it to just work. I've argued repeatedly in favor of that but upper management thinks they know better and won't permit POP3/IMAP4 to be turned on, after all they're open protocols and anything open has to be an open invitation to hackers to walk into our network (grumblegriemutterstupidsuits tiesmustcutoffbloodtothebraingrowlgnashgrumble).

There seems to be a required step missing: filing a lawsuit against the infringing publisher. If they're selling the books (as opposed to giving them away free), the kind of volume described should amount to enough money to make a lawsuit feasible. And once you have a John Doe lawsuit filed, based on the initial evidence (as described it should be trivial to provide in the complaint a list of books you hold the copyright on that this publisher is publishing without authorization) you can justifiably ask Google in a subpoena for information pointing to the real identity of the publisher. If money's involved Google has some sort of real financial information about the defendant, otherwise they couldn't send the defendant their money. Google may blow off demands that just make a claim, but they won't just ignore a subpoena that lays out Play store items from this publisher matched to your copyright registrations for those items.

Consider a regular bookstore. If you walked in and said "I hold the copyrights to those titles over there, and that publisher is pirating them.", what do you think the reaction of the bookstore would be? My guess is it'd be along the lines of "The publisher claims they're not. If you want us to stop doing business with that publisher, come back with a court order.". Your claims, however well-founded, aren't a legal determination, and the bookstore or even the distributor aren't the ones in our system charged with making that legal determination. It may suck, but consider the flip side: the publisher replies with a claim that they do have a contract with you and you're just trying to weasel out of it. Which would you rather do: argue the point once in front of a judge, or try to prove the absence of a contract to every single bookstore and distributor out there?

It's not the Millenials. They're a bit more demanding, yes, but not significantly so compared to all the other groups of clueless users I've dealt with over the last 3 decades. Mostly they can be dealt with by telling them that I'd love to be able to do what they want but management's refused to allow it so they need to go talk to $AppropriateExecutive and convince him to change the policies on it. That gets them out of my hair.

Mostly the stress comes from management wanting more and more from fewer people with fewer resources, less funding and lower salaries. Instead of being skeptical, they buy into the salespeople's lies completely and then yell at IT when what was delivered doesn't do what was promised and never will. And gods help you if you do manage to prove the salesperson lied, because then it's your fault management bought into it. This from management's not a new thing, I've watched it growing since the early 90s.

This seems to be more a carrier problem than a Google or manufacturer problem. Google has the base OS updates available quickly. The manufacturers have to handle the hardware-related stuff, making sure firmware blobs for their hardware are compatible and such, but that doesn't seem to be that hard a problem what with a lot of phones sharing common hardware. I've commonly seen LG and Samsung have updates available within a week or two. The big delay always seems to be my carrier not letting my phone update because they haven't finished doing all the modifications they do for locked built-in apps, custom apps (eg. LG uses a custom calendar app instead of plain Google Calendar), UI customization/branding and so on.

It seems remarkable similar to Internet access, where ISPs always want to sell you not just Internet access but a whole wrapped-up package that includes them controlling what content you get and how you get it so they can steer you to content they control or get paid for. And as with net neutrality, the cel-phone carriers are going to strongly resist being relegated to the role of mere sellers of a pipe without any control over the device and the "user experience" that goes with it and allows them to steer users towards stuff the carrier gets paid for.

That's an argument for having the browser try HTTPS first, optionally falling back to HTTP if HTTPS isn't available. That's fine by me. It's not an argument for disabling capabilities of HTML/Javascript/etc. just because the transport isn't encrypted. It's also not an argument based on security but on privacy, and there's plenty of privacy problems that exist regardless of whether the connection's encrypted or not (eg. web bugs placed in advertising coming from servers in the site's domain (but not operated by the site and not on the site's network) that then use plain query-string parameters to relay data to off-site servers bypassing browser origin checks).

The problem is that requiring HTTPS doesn't make sites more secure. It prevents an attacker who can't obtain a legitimate SSL certificate for the domain from running a mid-transit MITM attack, nothing more. The biggest problems seem to be a) phishing attacks that convince the user to visit a rogue site eliminating the need for MITM, b) local system compromises (client- or server-side) that have access to the cleartext traffic and don't need an MITM, and c) rogue CAs who issue certificates for domains the recipient isn't authorized for which allows for mid-transit MITM with HTTPS. The first two can't be mitigated by anything other than smarter users (HAH!), and mitigating the third requires massive changes to certificates so it's possible to determine whether a certificate belongs to a given site without depending on anything in the certificate and without depending on the CA having validated the recipient.

Doesn't that depend on the configuration and purpose? If the HTTP server's running on my own machine and the URL is "http://localhost/...", am I automatically insecure because I can't get an SSL certificate for "localhost"? And how would an attacker not already on my machine exploit this?

If I can't test the full capabilities of a Web site because the browser won't let me, I'm going to have to switch browsers and relegate Firefox to testing-only just like IE is currently.

So, how exactly do they propose to recover from a compromise of these kinds of systems where it's impossible to change the authentication data? And these systems will be compromised, history has taught us that. At least with a password or a certificate carried in a two-factor dongle I can change/reissue it and what the crooks have is no longer valid. I don't like systems whose failure mode in the event of a compromise is catastrophic.

The article misses one point in it's analogy to paying for promotion: who's being paid. When I pay a store for special placement, I'm paying the store for special placement of my stuff on it's shelves. That's fine, it's the store's shelves and they're free to handle them however they choose. But suppose that, instead of placement on the store's shelves, I'm paying the store for special placement in the customer's pantry? Once I pay the store they'll send people to customer's homes to put my products front and center in the customer's pantry even if the customer didn't buy them and if that leaves the customer without enough space for what they did buy then tough luck, what the store put there is locked down so only the store can move it and they won't. That's not fine. It's not the stores shelves, and nobody's paying the customer for special placement on their shelves.

Ah, but the argument might be that it's not the customer's line, it belongs to the ISP. If so, then exactly what is that bill the customer's being sent every month for then? We already have situations like this. If I'm renting an apartment the landlord still holds the title to it but it's my apartment as long as I'm paying the rent and the landlord isn't free to just do anything to it he pleases any time he pleases. If I'm making payments on a car loan the bank holds title to the car but it's still my car and as long as I'm making the payments the bank can't just come in and borrow it any time they please or have it repainted to a color they like or anything like that. In the same way, the customer's paying for Internet access and as long as they pay the bill every month it's their Internet access and the ISP doesn't have an unrestricted right to decide how chunks of it must be used (unless, as with the boxes that disable a car if payments aren't made on time, it's made completely clear up front that this is being done and why and it serves a reasonable purpose (use of that box after a payment has been missed is one thing, but if the finance company tries to claim a right to use them when they think a payment might be missed soon (even though payments are still current) the courts would reject that as unreasonable even if the contract tried to allow it).

It may work out for candidates, though. Right now the company tends to start low and let the candidate name a higher figure, then go back and forth ending up somewhere in the middle. If their initial offer's too low the candidate will just name something higher, and unless the candidate's really cocky the company stands a good chance of getting them for less than they were willing to offer. With no negotiation the company knows there may well be competing offers out there so if they make their offer too low the candidate, knowing they can't negotiate, will probably walk away. Where before the company had an incentive to low-ball the offer and negotiate up, now they have an incentive to offer the most they'd be willing to pay this candidate to minimize the chance of losing the candidate to a competing offer.

NB: this is also why companies try to get the candidate to give an expected salary first, knowing that that sets an upper limit and the candidate is caught between asking for as much as possible and keeping the salary down so the company doesn't decide it's more than they'll consider.

I'd rather vendors worked the same way, give me their best price and I'll tell them whether it's within my budget or not. But then I'm a tech, not a salesman, I prefer to minimize the rigamarole so I can get back to doing productive work.

Well, we already have seamless transfer of public keys. That's the whole point of the PGP keyservers, after all. As far as revocation, your argument fails to take compromises into account. The ability to revoke a key is what allows me to handle a case where someone's broken into my computer and gotten hold of my private key. If I couldn't revoke my key, they could impersonate me forever using the stolen private key. Expiration serves a similar purpose, limiting the timeframe when a stolen key could be useful even absent a revocation. Properly done, expiration is handled before it happens by distribution of a new key signed by both itself and the old key. Since the attacker doesn't have the old key (it hasn't been revoked) he can't forge the old signature, and if both the old and new signatures are valid the new signature can't have been created by an attacker and the new key is clean. Both expiration and revocation become even more critical when I'm dealing with people I don't know directly, and let's face it we very rarely communicate only with a small circle of people we know personally.

And no, the CA system isn't inherently less vulnerable than self-signing alone. Self-signing without some additional authentication leaves you trusting the word of a malicious party about their identity, and they're highly unlikely to tell you the truth about that. That's why a self-signed PGP key by itself can't be trusted (unless you got it directly from it's owner by a secure channel), you need additional signatures from trusted parties to affirm it's authenticity. The problem is that the certificate system itself only permits one signature on a certificate/key. PGP had it right by permitting an arbitrary number of signatures on a key. If I require at least 3 different root CAs to vouch for a certificate, it becomes much much harder for any party to compromise things. In part that's because it takes more effort to compromise 3 root CAs, but it's also because it makes revoking a root CA certificate much less of a problem. Right now revoking a root CA certificate instantly invalidates every single certificate issued by that CA. Allowing multiple signatures would mean it would only invalidate those certificates where that CA was the last remaining trusted CA signing the certificate. OTOH if my certificate were signed by Equifax, Experian and Verisign and it was found Verisign had given their root key to the government, my certificate would still be valid after Verisign's root certificate was forcibly untrusted because I've still got 2 trusted CAs vouching for it. I'd only be in trouble if Equifax and Experian had both already had their root certificates untrusted and I'd failed to get additional signatures done by other CAs before Verisign went.

This is what certificate pinning was made for. If the browser knows what certificates the site ought to be using, it can simply refuse to connect to anything in the site's domain that isn't using one of those expected certificates. This doesn't even require CA-issued certificates, self-signed ones would be equally secure except for the fact that browsers complain about them. Note that this is just a slightly more permissive form of the server authentication built into the SSL protocol.