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.

It's more than "aren't recommended".

RFC6376: "Signers MUST use RSA keys of at least 1024 bits for long-lived keys."

Given Google were using a long-lived key, they were violating a MUST provision in the DKIM spec. (Pedantically, that means they weren't sending DKIM compliant mail at all).

Crappy, unshielded starship drives pump so much electromagnetic crap out that it gets picked up by nearby ships internal intercoms. If the Narn would just put decent mufflers on their riced-up ships...

Also, installation should be as automated as is reasonable. Spinning up a new node shouldn't require more than a couple of commands to image the base OS, install the application and integrate it into the rest of the network. Upgrades, ditto.

The developers should be doing this for their test / integration environment, QA for their testing environment and Ops for staging and production environments. That's true whether or not Dev and Ops are the same people.

If it can only be installed manually by the developers, you have a serious problem - but if it can only be installed manually by Ops, that's just a slightly smaller problem.

People who care more about "effective ownership and control of the computer' than user experience tend to produce applications and environments that are vastly more configurable, but have much worse UX than those produced by developers who focus on user experience.

That's the underlying problem with Linux on the Desktop.

The person in the state that received it would (in most states) be committing tax fraud.