The Daily Parker

Politics, Weather, Photography, and the Dog

Document disposal mishap in New York

Via Bruce Schneier, apparently some of the confetti thrown at the Macy's Thanksgiving Day Parade last weekend came from the Nassau County Police:

A closer look shows that the documents are from the Nassau County Police Department. The papers were shredded, but clearly not well enough.

They even contain information about Mitt Romney's motorcade, apparently from the final presidential debate, which took place at Hofstra University in Nassau County last month.

Most significant, the confetti strips identified Nassau County detectives by name. Some of them are apparently undercover. Their social security numbers, dates of birth and other highly sensitive personal information was also printed on the confetti strips.

I expect the follow-up story to describe how a document destruction company now faces a massive lawsuit...

Windows Azure deployment credentials

My latest entry is up on the 10th Magnitude tech blog:

We've taken a little more time than we'd hoped to figure out how to deal with Azure deployment credentials and profiles properly. In an effort to save other development teams some of our pain, we present our solution. First, the general principle: Publication profiles are unique to each developer, so each developer should have her own management certificate, uploaded by hand to each relevant subscription.

When you deploy a project to a Windows Azure Cloud Service instance, you have to authenticate against the Azure subscription using a management certificate. The Publish Windows Azure Application wizard in Visual Studio presents you with a helpful link to sign in to your Azure subscription and download credentials. If you do this every time you publish to a new subscription, you (a) rapidly run up against the 10-certificate limit in Azure; and (b) get ridiculous credential files called things like "WorkSubscription1-AzDem12345-JoesSubscription-MySecretProjectThatMyBossDoesntKnowAboutSubscription.publishsettings" which, if you're not paying attention, soon shows up on a Subversion commit report (and gives your boss access to that personal project you forgot to mention to her).

Don't do that. Instead, do this:

1. Create a self-signed certificate using IIS. Name it something clear and unique; I used "david.10thmagnitude.com," for instance.
Image of creating a self-signed certificate
Then export it to a private folder.
Image of exporting a certificate from IIS to a folder

2. Import the .pfx file into your local certificate store.
Image of importing a private key

3. Export the same certificate as a .cer file.
Image of exporting a cer file

4. Go to the Azure management portal's management certificate list.

5. Upload the certificate you just created to the subscriptions to which you want to publish cloud services.
 Image of uploading a cer file

Now you have a single certificate for all your subscriptions. Next, create a publishing profile with the certificate:

6. In your Azure cloud service project, right-click the project node and choose "Publish…" to bring up the Publish Windows Azure Application wizard.

7. Drop down the "Choose your subscription" list and click "<Manage...>"

8. Click "new"

9. In the "Create or select..." drop down, find the certificate you just created and choose it.

10. Continue setting up your publishing profile as you've done before.

That's it. Except for one other thing.

If you have more than 0 developers working on a project, at some point you'll use source control. Regardless whether you have Subversion, Mercurial, or whatever, you need to avoid committing keys, certificates, and publishing profiles into your VCS. Make sure that your VCS ignores the following extensions: *.pfx, *.cer, *.publishsettings, and *.azurePubxml.

You want to ignore pfx and publishsettings files because they contain secrets. (I hope everyone knows this already. Yes, pfx files use passwords, but publishsettings don't; and anyway, why would you want to risk anyone else authenticating as you without your knowledge?) Ignore cer files because they're not necessary in an Azure project. And ignore azurePubxml files because every developer who publishes to Azure will wind up overwriting the files, or creating new ones that no one else uses.

Grant me the serenity

Via Sullivan, artist Heather Dewey-Hagborg is creating 3D portraits from random hairs:

Collecting hairs she finds in random public places – bathrooms, libraries, and subway seats – she uses a battery of newly developing technologies to create physical, life-sized portraits of the owners of these hairs. You can see the portrait she’s made from her own hair in the photo below. While the actual likeness is a point of contention, these images bring about some creepy-yet-amazing comments; on genetic identity (how much of “you” really resides in your DNA?); on the possibilities of surveillance (what if your jealous partner started making portraits from hairs they found around your house?); and on the subjectivity inherent in working with “hard” data and computer systems (how much of a role do human assumptions play in this machine made portrait?).

The artist's site is here.

All right. This came a little sooner than I expected, and from a different source. I've long recognize the necessity of adapting to, rather than raging impotently against, the fundamental changes to the security and privacy mores we've had for several thousand years. (As Bruce Schneier has pointed out, "Fifteen years ago, [CCTV cameras] weren't everywhere. Fifteen years from now, they'll be so small we won't be able to see them.") But this project, if it works as hoped, actually freaks me out a little.

I'm going to whistle past this graveyard for the time being...

Troubleshooting software installation on Windows 7

I have just spent an hour of my life—one that I will never get back—trying to figure out why I couldn't install any software from .msi files on one of my Windows 7 machines. Every time I tried, I would get a message that the installer "could not find the file specified."

I'll spare you all the steps I went through to figure out why this was happening, and get to the punchline:

>

Yeah, you see, the SYSTEM account needs full control over any file you're trying to install on Windows. Here's how it should look:

So, if you're a security-conscious individual who's locked down his PC thoroughly, and you can't seem to install anything on Windows anymore, check the permissions on the folder containing the .msi file.

As we say in programming: herp-a-derp.

Out of the apartment, into the cloud (Part 2)

Last weekend I described moving my email hosting from my living room home office out to Microsoft Exchange Online. And Thursday I spent all day at a Microsoft workshop about Windows Azure, the cloud computing platform on which my employer, 10th Magnitude, has developed software for the past two years.

In this post, I'm going to describe the actual process of migrating from an on-site Exchange 2007 server to Exchange Online. If you'd prefer more photos of Parker or discussions about politics, go ahead and skip this one. It's pretty technical and Parker only makes a brief cameo.

About 18 months ago, 10th Magnitude's CTO tried to move us to the predecessor offering now replaced by Exchange Online and Office 365's, Business Productivity Online Suite, AKA "BPOS." He was quite adamant that BPOS was a CPOS, and made just setting up the service a complete PITA. I'd like to assure him and everyone else thinking about cloud-based email that the situation today has improved.

The new migration tools start you with a step-by-step checklist, liked to all the documentation you need, that takes you through the entire process:

Step 1 took fifteen seconds. I called my dad and told him I was moving his email account to a different server, and that he probably wouldn't even notice the change except his password would change. He said fine. That was easy.

Step 2 was to add my domains to Exchange Online. My existing Exchange organization hosted eight domains, which it had acquired over the 12 years or so I'd run development servers in my office. Each domain required going into my DNS registration account at DNS Made Easy and adding a TXT records proving I owned it. Fortunately, my DNS provider and Microsoft communicated in real time about the updates, so I got through 7 of 8 domains in about 10 minutes. The 8th domain, which unfortunately was the Active Directory root domain, had its nameservers pointed at the DNS registrar that I used before switching to DNS Made Easy. Switching nameservers took an entire day, for reasons that pass understanding.

Step 3, mailbox migration, had a few hiccups, and required about more effort than I anticipated. First, using the Remote Connectivity Analyzer, I discovered that the specific combination of DNS records, firewall rules, and mailbox configuration on my Exchange server wouldn't allow migration. It took about two hours of playing whack-a-mole to get just one of the tests in the suite to work. Microsoft provided (generally) comprehensive instructions on how to fix the problems I encountered, however. The test suite itself gave me a good idea of what I was doing wrong on its own, even without the TechNet articles.

The remaining steps in the plan—redirecting mail to the new server, completing the mailbox migration, activating users, and starting to use Exchange Online—took about fifteen minutes. Seriously.

The whole effort took six hours total. Part of this includes the post-move configuration changes I had to make to several services and Web sites, as my Exchange server was also my internal SMTP server. This blog, all of my hosted websites, and the collection of services that support those websites (like Weather Now, for example) all had to have a new SMTP server to send emails out. That was a little tricky, and required using IIS6 tools on a Windows 2008 server. But that's another story.

Also, my RSS feeds didn't fare well in the switch. With Exchange 2007 and Outlook 2010, your RSS feeds are stored on the server, not the client. So I had to add all of them back by hand after the migration.

It's important to note a few things that would make this more difficult for a larger business than mine. I had two active mailboxes for people and a couple for support services, I controlled both the Exchange server and the network, and I had no critical business issues during the switch. Larger organizations will have to handle a migration much more carefully than I did.

In the end, my email experience is exactly the same. And my apartment home office is noticeably quieter with two fewer servers gobbling electricity.

Terrorists! Communists! Anarchists! Roundheads! Saxons!

The FBI has put together a committee of university presidents to root out foreign spies who have infiltrated American colleges:

While overshadowed by espionage against corporations, efforts by foreign countries to penetrate universities have increased in the past five years, [Frank] Figliuzzi, [Federal Bureau of Investigation assistant director for counterintelligence] said. The FBI and academia, which have often been at loggerheads, are working together to combat the threat, he said.

Attempts by countries in East Asia, including China, to obtain classified or proprietary information by “academic solicitation,” such as requests to review academic papers or study with professors, jumped eightfold in 2010 from a year earlier, according to a 2011 U.S. Defense Department report. Such approaches from the Middle East doubled, it said.

The problem with this, as a number of people pointed out in the article, is that academics share information freely. That's their freaking job. And the U.S. has hundreds of thousands of foreign students—76,000 from China alone—because, for now anyway, we have the best schools in the world.

Of course the FBI should go after real spies, and discovering former Russian intelligence agent Sergei Tretyakov probably prevented Russia from stealing information that would have helped them catch up to where we'd gotten ten years earlier.

The university presidents on the FBI's committee need to remember their first duty. I hope some of them will remind the FBI that suspecting lots of foreigners of trying to spy on us will cost more than it will save.

This is a very old conversation. There are always people who see enemies everywhere. Sometimes they're right; but we need to make sure that when they're wrong, they don't cause more damage than they're trying to prevent.

Disclosing Facebook passwords

Raganwald yesterday posted a facetious resignation outlining the dangers to employers of asking prospective employees to disclose social media information:

I have been interviewing senior hires for the crucial tech lead position on the Fizz Buzz team, and while several walked out in a huff when I asked them to let me look at their Facebook, one young lady smiled and said I could help myself. She logged into her Facebook as I requested, and as I followed the COO’s instructions to scan her timeline and friends list looking for evidence of moral turpitude, I became aware she was writing something on her iPad.

“Taking notes?” I asked politely.

“No,” she smiled, “Emailing a human rights lawyer I know.” To say that the tension in the room could be cut with a knife would be understatement of the highest order. “Oh?” I asked. I waited, and as I am an expert in out-waiting people, she eventually cracked and explained herself.

“If you are surfing my Facebook, you could reasonably be expected to discover that I am a Lesbian. Since discrimination against me on this basis is illegal in Ontario, I am just preparing myself for the possibility that you might refuse to hire me and instead hire someone who is a heterosexual but less qualified in any way. Likewise, if you do hire me, I might need to have your employment contracts disclosed to ensure you aren’t paying me less than any male and/or heterosexual colleagues with equivalent responsibilities and experience.”

Three things:

  • He's right on the main point. Looking through employees' Facebook pages uninvited is tricky enough. Determining whether or not to hire someone based on a Facebook page is closer to the line. Forcing the disclosure crosses the line, surveys the land, plants a flag, and invites the natives to kill you in your sleep.
  • Disclosing a password to anyone for any reason is, almost always, a bad idea. Authentication is half of security (the other is authorization, which depends on you being who you say you are). The corollary to authentication is deniability. If you lose control over your Facebook password, you expose yourself to identity theft. To emphasize this point, in our office we routinely prank developers who leave their keyboards unlocked when they leave the room. Walking away at a client site could let clients see other clients' materials, for starters, but it also could allow someone to send email or make Facebook posts in your name.
  • I am proud to report that Illinois is right now passing a law to prohibit this practice. It will probably be signed later this month.

Other things of note

I don't want to lose these things:

That is all. More UK and France photos later today.