Meh. I've got 25 years in the industry, I think I know reality quite well, thank you.

Why would I want to work for a foolish company like that?

Google.

And, yes, people absolutely do get bonuses for writing easter eggs at Google. And April Fool's jokes, and much more.

Prior to Google, I worked for IBM, where I also saw people get bonuses for doing whimsical things. And before that, Philips, and Unisys, and... I did mention I've been in the industry for 25 years, right?

Meh. Did it offend you when you did a Google search for "barrel roll", and your browser window's contents rotated? There's no doubt that the situation you're describing can happen, but it's not hard to stay far, far away from that line.

If the easter egg is done well, yes.

All of the above, and the customers buying real enterprise systems, which cost tens of millions of dollars, not piddly thousands.

Dude, lighten up. I've worked on many massive projects with tightly-spec'd RFPs and outside of systems where slight errors may result in death (e.g. aerospace, some medical systems), real people are much less uptight than you seem to expect.

Cite?

Back when I was writing stuff that distributed as compiled Windows executables, I'd throw a little window into the About of programs that had GUIs - if you held Ctrl-Alt-Shift and clicked the app icon the About text would change to include the names of the team and (depending on space) possibly a `fortune` style pithy saying.

Pretty mild, and if anyone had complained about the waste of time to implement changing the text of a few fields in an existing screen it would have served as a good person filter.

I would say something. I'd give him a pat on the back and maybe a small bonus, as long as it's suitably hidden and well done... playful, not obnoxious, not going to get in anyone's way, etc.

Customers like easter eggs. Assuming the software is generally high quality, they're amusing, minor diversions that add a little fun for the users as well as the programmers.

I once added a Tetris clone to what would end up being an Oracle product after acquisition. It replaced the editor in an IDE if you changed the description of a document to match the address of the office we used to work. It survived at least three major releases. The code may still be there for all I know, probably unreachable.

That product had a few Easter eggs, a picture of the dev team in a dinner party that could be access by typing a correct sequence in the about box, also in a couple of releases, on Christmas a Santa's hat would appear on one of the icons (we had to remove that one, since it was perceived politically incorrect). Even one version that never got released, had a simulation function for a business process where work items moving through the process diagram would be rendered as Lemmings, with music and everything.

You're still using a Nexus One? Even the Nexus S got upgraded to 4.1. Serious kudos on keeping that five year-old phone running. Do modern apps run on it?

From a broader perspective, while I think Google should probably do a little better at updating older Nexus devices than it has, it's really not that bad; the Nexus 4 and first-gen Nexus 7 got Lollipop (though it doesn't run all that well on the N7v1), and I suspect that if it weren't for the fact that the SoC vendor is gone, the Galaxy Nexus would have as well.

(I'm a member of Google's Android security team.)

This is a valid issue, but separate from what the report is attempting to address. Well, not entirely separate, because the Android security team does in some cases classify apps that request excessive permissions as potentially-harmful, but only when there's evidence that the apps are actually trying to abuse the user.

Note that I'm not trying to downplay the issue of apps that request more permissions than they need. I think (based on lots of evidence) that in most cases this is more an artifact of developer laziness than malice; they aren't sure exactly what they need and definitely don't know what they're going to need in the future and so find it easier to ask for the world. This is a problem the Android security team recognizes and is working to address, in various ways that I can't go into.

Actually, Google specifically assumes that your privacy does have value to you, and that you should be able to decide what you'll trade it for.

Benefit to Google, or lack thereof, is completely irrelevant to the Android security team's decision to classify an app as potentially harmful or not. In general, the Android security team treats the rest of Google as just another app developer and online service provider. It's not our job to enable their revenue streams. Granted that we recognize that those revenue streams pay our salaries, but in the long run treating users well is what will enable Google to continue making money and paying our salaries.

Take it with a grain of salt, sure, that's wise. However, there's nothing marketing-related about the numbers in the report. These numbers are snapshots of the data the Android anti-malware team uses internally to assess its effectiveness. The numbers are not fudged, and what they show is that while there are issues, Google's anti-malware team is making solid progress and the current state of the ecosystem is actually not too bad. There are some caveats (called out in the report) around the fact that the numbers describe the prevalence of known potentially-harmful apps. The charts get revised retroactively when new PHAs are discovered but snapshots in reports are static. Still, I think the numbers are quite reliable.

Note that I'm a member of the Android security team, and my manager is the primary author of the report and blog post, though I work on platform crypto features, not anti-malware.

At worst, the numbers in the report represent the ways in with the Android team fools itself about the state of ecosystem security. At best they're an accurate and nuanced reflection of the state of the ecosystem. The truth is somewhere in between, but I think it's far, far closer to the latter than the former. What the numbers definitely are not is anything cooked up specifically for the public.

Fortunately, we know how to counter that threat.

It also seems pretty unlikely that the NSA had enough foresight to get VC++ instrumented to subvert TrueCrypt. It's not impossible, but there have been a lot of similar tools over the years, and I don't think the compilers could have been modified to subvert all of them.

Reading comprehension fail. Please re-read this sentence from the GP:

Absolute certainty is impossible, but audits like this do provide a basis for a reasonable belief that the security of TrueCrypt is good.

Specifically, the S boxes (essentially some translation tables used in the algorithm) in the original design were vulnerable to linear cryptanalysis, which is a cryptanalytic technique that involves constructing systems of linear equations representing the transformations in key portions of the algorithm, then applying mathematical analysis to deduce key and/or plaintext bits. Linear cryptanalysis was unknown in the academic world at the time, but it was apparently known to the NSA. The NSA's changes made DES resistant to linear cryptanalysis.

However, the NSA also reduced the key size and block size from 128 bits to 56 and 64 bits, respectively. This likely made DES vulnerable to brute force attacks by particularly well-funded attackers (e.g., the NSA). Use of multiple DES operations in sequence overcomes this issue and Triple DES today is still considered to be quite strong. So, all in all, the NSA improved DES security. This isn't surprising because it was a core part of their mission; a mission that appears to have been deprecated in the post 9/11 world, but was still very important to the NSA in the 70s.

Weird coincidence: watched part of it last night. (Through Harry the cabbie. Too tired to watch any more)

You mean from the Apple/Mac world...

Just don't bring the green orb with you.

But I like toast and jam.

Was this a Fareed original, or yet another of his pieces of plagiarism?