It's partly because they're big, but it's also because they're cheap.

If they used fraud or deception to install malware to take control of peoples machines to, say, send spam, that'd be solidly criminal.

Sending spam probably costs the owner of the compromised machine much less than bitmining does (in additional energy costs, cooling costs and possibly accelerated degradation of the GPU, possibly leading to failure). I'm not seeing how the same standards don't apply.

One that says much more about Bob Ferguson than it does T-Mobile.

... spreadsheets kill people.

Ban Excel!

Can't argue with any of that.

But you don't have to choose just one of those. Virtualization is easy. Pick the best of each OS.

I have an OS X laptop, and I'm quite happy with the UI and most of the basic desktop apps (other than Safari, which is the poster child for "QA gone to shit").

But I do a lot of my work in an ubuntu instance that's running in vmware - it has a partially shared filesystem so I can work in ubuntu while editing the files I'm working on in an OS X native editor like sublime text if I want to. Or I can run emacs/X11 on ubuntu, displaying on the OS X desktop.

I even have a Windows instance, for those rare times when I really need to use Word or IE or Minesweeper.

Google offers free services. People will attempt to abuse them. That's no great surprise, nor is it specific to Google.

When someone abuses Googles services in a way that's a threat to other users there are only two ways to mitigate the incident. The best, by *far*, is for Google to stop the abusive behaviour. The other is for the affected parties to block access to (some subset of) Google. Those are really your only options.

Google is (based on externally visible behaviour) worse at mitigating abuse up-front by discouraging attempts to abuse their service, and at responding to reports of abuse, than other companies - and this appears to be an intentional choice by Google, based on their corporate culture. The tradeoff there is that people are more likely to just block Google servers, in response to the never ending trickle of abusive behaviour.

That's Google's problem. Well, actually, Google don't generally appear to think any of this is a problem at all - and *that's* the real problem as far as the rest of the Internet is concerned.

Google docs is massively abused for phishing, and there doesn't seem to be much action by Google to prevent that.

If Google paid more attention to preventing or mitigating abuse using their network, or even paid active attention to reports of abuse, people wouldn't have to resort to blocking them.

Because bringing a lawsuit is ridiculously expensive and time consuming. Spending months-to-years of time and lawyers salaries to go after a small spammer just isn't worthwhile. The telcos involved, however, can just shut them down without much difficulty or cost - if they choose to do so.

The FTC aren't in a position to really handle robocalls and SMS spam, other than acting as a last resort legal hammer for egregious cases.

The telcos, on the other hand, could *trivially* stop the vast majority of it if they had any interest in doing so. But they don't have any interest in that - they get paid by the various crooks doing this sort of thing. And it doesn't cost them any customers - what are the customers going to do, move to a different US telco that's just as bad?

Also available to the distributor is all the information about the other artists you listen to. And your zip code, your email address, your age. Possibly, depending on what sort of account you have, your home address and your credit card number. I'm pretty sure that she wouldn't ask for your credit card number, but I'm sure she'd love to have your email address.

Geographic distribution and some basic demographics is one thing, and quite a reasonable one, but combine "How do I reach them? How can I tell them I have a new album coming out?" and “I want my data and in 2012 I see absolutely no reason why I shouldn’t own it.” and it sounds like the worst sort of stalkery marketer who'll abuse the hell out of your personal information for a buck.

And if you are trading child porn, of course you'll have an open wifi access point and blame it on the sketchy guy with the laptop in the van...

I wonder how they're planning to prevent Oracle releasing a more sophisticated proprietary JIT for 64 bit ARM?

Yup, all of that is likely what happened.

A critical part of DKIM is selector-based key rotation (as even the 2048 bit key won't help you at all when an ex-employee or a contractor walks off with the private key, while key rotation will reduce the window of exposure from that sort of event). Google aren't the only ones to have missed that.

(Many of the original - and current - examples of how to set up DKIM suggest using a date as part of the selector, so as to make it clear that the key was supposed to be fairly transient. That leads to the lovely situation that you can look at a lot of peoples DKIM setups and see that they created their key pair once, several years ago, using the current date and haven't changed it since - their failure to rotate keys is self-documenting.)

There are many reasons why DKIM doesn't need to be "really strong crypto" - it's intended just for someone to assert that they're responsible for an email message, that they're prepared to accept complaints about the mail they send, and that you should pay attention to their previous behaviour when deciding whether or not to deliver a message. Stealing someones DKIM private key lets you piggy back on their good reputation to get spam or phishing emails into an inbox rather than a spam folder for a short time period, and that's about it. It's nowhere near as high value a target as anything like TLS certificates.

Googles reputation is certainly worth more than the estimated $75 it would cost to crack their short key, so it's good they've fixed that. And even though much of the media coverage of this has been tech-tabloid drivel it's a good thing if it gets other companies to look at key length and rotation frequency.

(Disclaimer: I've been working with the DKIM spec since the early days of DomainKeys. http://dkimcore.org/ is me.)

The DKIM spec itself (RFC6376) says: "Signers MUST use RSA keys of at least 1024 bits for long-lived keys."

It's pretty unequivocal. Google just misconfigured their mailserver.