The Daily Parker

...you know it's going to be bad. And it really is:

Passed in 2012 after a 60 Minutes report on insider trading practices in Congress, the STOCK Act banned members of Congress and senior executive and legislative branch officials from trading based on government knowledge. To give the ban teeth, the law directed that many of these officials' financial disclosure forms be posted online and their contents placed into public databases. However, in March, a report ordered by Congress found that airing this information on the Internet could put public servants and national security at risk. The report urged that the database, and the public disclosure for everyone but members of Congress and the highest-ranking executive branch officials -- measures that had never been implemented -- be thrown out.

The government sprang into action: last week, both chambers of Congress unanimously agreed to adopt the report's recommendations. Days later, Obama signed the changes into law.

Bluntest of all was Bruce Schneier, a leading security technologist and cryptographer. "They put them personally at risk by holding them accountable," Schneier said of the impact of disclosure rules on Congress members and DC staffers. "That's why they repealed it. The national security bit is bullshit you're supposed to repeat." (Three of the four experts we consulted opted for the same term of choice.)

As Schneier said, "There was a security risk, but it was not a national security risk. It was a personal Congressperson risk." And that was enough to stymie transparency.

One commenter on the original CRJ article points out, "Right, they're concerned about people getting their personal info online...as they pass CISPA."

This was a bipartisan effort, by the way.

Via Sullivan, a new Google Chrome plugin that allows you to embed secret messages in photos you post on Facebook:

That’s the idea behind Secretbook, a browser extension released this week by 21-year-old Oxford University computer science student and former Google intern Owen-Campbell Moore. With the extension, anyone — you, your sister, a terrorist — could share messages hidden in JPEG images uploaded to Facebook without the prying eyes of the company, the government or anyone else noticing or figuring out what the messages say. The only way to unlock them is through a password you create.

The extension is only available for the Google Chrome browser — Campbell-Moore cites its developer tools and popularity — and the messages are restricted to 140 characters. Less certain is what Facebook thinks; a spokesman declined to comment. But it’s still the first time anyone’s managed to figure out how to automate digital steganography — the practice of concealing messages inside computer files — through Facebook, the world’s biggest social media platform. Unlike cryptography, which uses ciphertext to encrypt messages, steganographic messages are simply hidden where no one would think to look.

Calling Bruce Schneier...

Too much going on:

• Paul Murphy at Financial Times thinks Cyprus will do the right thing
• Microsoft released figures about national security letters the FBI has sent it
• .NET 4 introduced the System.Numerics.Complex type
• Microsoft's Channel 9 posted a video about migrating applications to Azure virtual machines
• Jeff Atwood makes a case for the Ruby language
• BuzzFeed imagines Twitter's 7th anniversary promo video with the Inception theme
• No one really cares about LinkedIn endorsements
• T-Mobile has put up an animated graphic showing cyber attacks in real time

Now, I will go back to drafting documentation while I wait for AT&T to reconfigure my DSL and kill my landline. I've had a POTS ("plain old telephone service") twisted-pair line longer than most people on earth have been alive. After today, no longer. I don't think I'll miss it, either. I only have it because I have a business-class DSL, which I don't need anymore, and the only people who call it want money from me.

Security guru Bruce Schneier examines Papal election security:

Probably the biggest risk is complacency. What might seem beautiful in its tradition and ritual during the first ballot could easily become cumbersome and annoying after the twentieth ballot, and there will be a temptation to cut corners to save time. If the Cardinals do that, the election process becomes more vulnerable.

A 1996 change in the process lets the cardinals go back and forth from the chapel to their dorm rooms, instead of being locked in the chapel the whole time, as was done previously. This makes the process slightly less secure but a lot more comfortable.

There are also enormous social -- religious, actually -- disincentives to hacking the vote. The election takes place in a chapel and at an altar. The cardinals swear an oath as they are casting their ballot -- further discouragement. The chalice and paten are the implements used to celebrate the Eucharist, the holiest act of the Catholic Church. And the scrutineers are explicitly exhorted not to form any sort of cabal or make any plans to sway the election, under pain of excommunication.

Of course, no amount of security in the world will prevent the electors from replacing Joseph Ratzinger with someone at least as out-of-touch and reactionary as he is, given the constitution of the cardinality these days.

More things I gotta read later:

• The New York Times has a thorough look at their recent security problems, and security writer Nick Selby takes Symantec to task for its response.
• The Atlantic posted photos of Grand Central Station commemorating its 100th birthday this month.
• Sarah Goodyear imagines drone-proof cities in the Middle East.

Now, back to rewriting an authentication provider...

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...

James Fallows, reacting to the Patreaus debacle, reminds everyone of the obvious:

Here is the secret plan:

Never put anything in an email message, to anyone, that would cause you serious problems if it fell into the wrong hands.

That's the plan™. All of it. Never do this. Ever.

Yep. This is the advice security experts have given for, well, ever.

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.

Then export it to a private folder.

2. Import the .pfx file into your local certificate store.

3. Export the same certificate as 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.
 

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.

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...

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.