Um... Lauren is a dude and I'm pretty sure he knows what he's talking about.

Damn. So close. Almost made it to the end without a typo!

Was there a link in the email that took them to a page to confirm their login information before Google deleted there accounts?

He should have used the SarcMark[!]

I've never been able to get a full understanding of an unfamiliar project by simply reading the code (and mapping out relationships, though I have done that from time to time). The most insight (for me at least) comes from running the code, changing it to see how it breaks, and running it again. Nothing tells you more about a piece of code than seeing how it works normally, then seeing how your changes affect it.

By deliberately breaking it. When you make a change and something else breaks you know immediately that those components are coupled. No reading/mapping required. Once that coupling is identified you can focus your code reading to understanding how tightly or loosely coupled they really are.

Rinse and repeat. It might seem simplistic or naive, however, once you've spent hours/days reading and mapping code, you're ultimately going to need to run it and modify it. In which case you are going to break it and learn something about component interactions that reading alone didn't tell you. My personal preference is to skip all that business up front and dive in. I'll still end up reading all the code. Just focused on certain areas of functionality one at a time.

You will never fully understand the code just by reading it. My approach is to ignore all of it until something needs to be changed. When you need to change something, add a feature, etc... find where in the code the functionality is and tweak it a bit. See what happens. Tweak it some more. See what breaks. You will start to get a deep understanding of a focused section of the code and not have to worry (yet) about other unrelated areas. Start with small changes first. Larger changes may require a deeper understanding of the architecture and how pieces interact. This will come in time. After a few iterations of this and you will eventually become intimately familiar with all the pieces of the code.

Of course when called out on it he said he meant that the NSA doesn't read citizens email:
http://news.yahoo.com/blogs/ticket/intel-chief-clapper-gave-least-untruthful-answer-u-164742798.html
http://news.yahoo.com/blogs/ticket/spy-chief-clapper-denies-misleading-congress-spying-americans-221024826.html

Which 1) no longer denies phone records are collected and 2) no longer answers the question that was asked in the first place!

They don't need to decipher it in transit. They just send a NSL to the ISP to give it to them once it's been received.

No. SSL/TLS only encrypts data in transit. Once it reaches it's destination, i.e. Google, it is decrypted so it can be processed.

I worked on a piece of software that gathered data from various sensors. The application stored the calibration settings in the system registry which were configured at installation time and should never need to be touched by the user. To make life easy (for us) we created a fancy interface in the application to enter the data but hid it behind a weird hot key combination so the user wouldn't find it and be tempted to monkey with it. AFAIK no one has ever stumbled upon it.

like nunchuck skills, bowhunting skills, computer hacking skills...

Interesting point. There were fewer devices in '98 available to be used to receive a back channel message. Could this be a case of technology evolving so fast it obviates a patent before it has expired? What might have been considered non-obvious then would certainly be obvious now.

They have some pretty neat equipment for finding the utility lines. Just the other week I saw the water company come through marking the water lines. One guy with a spray can followed the other who was holding this stick with a fork in it. The pointy end always pointing at the ground.

I think her justification for the title of the song was that none of the examples in it were actually ironic... which in itself is ironic.

When a technical person who isn’t familiar with patent law reads a patent they often come away with a misunderstanding of what the patent actually covers – usually thinking that it is much broader than it actually is. This gives the impression that the patent covers things it doesn’t, and then leads to the impression that it is overly broad, obvious and shouldn’t have been granted.

My impression that a patent is overly broad does not stem from a misunderstanding from reading the patent. It comes from the overly broad litigation tactics wielded by the patent holder.