Hacker News Reader

Comment by jrockway | Hacker News Reader

I like how the workaround is to open the file with The Gimp and export to psd. Then Photoshop will open it fine.

I'm assuming this is a case of "the suits told us it couldn't import banknotes", so they made it not import banknotes. Banknotes that were already imported... well you didn't say anything about that.

(The same thing happened for the DVD encryption. Someone asked an engineer for encryption. The engineer just happened to have made it easy to bruteforce the key, negating the entire point of the encryption.)

Remember: you're the software engineer -- write the software you want, not the software you think someone wants you to write.

View on HN

> (The same thing happened for the DVD encryption. Someone asked an engineer for encryption. The engineer just happened to have made it easy to bruteforce the key, negating the entire point of the encryption.)

The DVD Content Scramble System came out in 1996, at which time the US still heavily regulated the export of "strong" crypto. DVD-CSS uses a LFSR-based stream cipher with a 40 bit key because it could be implemented efficiently in hardware, and the export restrictions did not apply to ciphers with 40 bit keys. Considering the constraints it was designed under I don't think anyone should be inferring that it was weak on purpose.

Well, it was weak on purpose. But for the US government's purpose, not the engineer's.

Right. What I meant was that I don't think it was vulnerable to a meet-in-the-middle attack (which makes it trivial to crack) on purpose.

> Remember: you're the software engineer -- write the software you want, not the software you think someone wants you to write.

That's easier said than done, kudos to those that pull that off but there is this thing called code review and if your co-workers are halfway competent you'll get called on what you built. In some cases that can be a career limiting move.

Better to pick your employers so that you don't end up as an enabler of technology used against the public interest.

Of course if you're going to 'take one for the team' and purposefully gain employment somewhere for the sole reason of messing with the machine that's a laudable strategy but it will likely come at a price in the longer term.

Figuring out how to manipulate the Someone so that they want you to write what you want to write- or at least tell you to write what you want to write, or to compromise on writing something closer to what you wanted to write- seems a useful strategy for mitigating those risks.

I have recent relevant experience in this regard. I'm working on a system for university-level language professors, a large part of which is making it easy for them to use videos for homework assignments. We recently had a meeting with one of the university's copyright lawyers to ensure that the video delivery system was sufficiently "safe", and they'd be legally protected from being sued for copyright violations when professors want to use films in their classes.

We quickly discovered that, if we explained things well enough that the copyright lawyer was capable of understanding how decrypted video ended up on the students' screens, and thus how a sufficiently tech-savvy student might possibly pirate it, they would freak out and insist we Do Something More. The obvious solution: stop explaining how things work, 'cause this is just making more work for ourselves. Tell them "other people used this thing and didn't get sued", and deflect all technical questions, on the other hand, and they leave us alone and let us work on something reasonable.

And so it should be. We're talking about a technological measure that is being implemented with the intent of preventing an actual crime. There is a real possibility in this case that undermining the measure will increase the amount of that type of crime that is committed. There is also little evidence that the measure is being abused by others on a significant scale with actual negative side effects for anyone.

Now, a developer might not want to implement that measure because they were concerned with other consequences that might not be in the public interest, or with the future potential for such consequences. This might be a perfectly reasonable position morally and/or technically, and as you say, that developer has the choice not to take that job. It's not as if good programmers are starving in the streets for lack of other opportunities, after all.

But if you do take a job as a programmer on a project, typically your authority and responsibility do not extend to setting the requirements and deciding on policies like this. If you presume to deliberately undermine those whose jobs do include making those decisions, you should be treated as a bad employee and dealt with accordingly, and that does include being fired, getting a professional reputation for being unreliable and not a team player, and so on.

All I'm saying is to think about what you want to do, and understand that in the context of employment, business goals, and so on. Don't just take someone's task list, and work on it from top to bottom. Make the task list something you own and want to work on.

Also, if you decide you don't want to try that hard on "anti-counterfeiting" protection, that's fine with me ;)

If you fuck up your goals, yup, you could be fired. Supply of programmers is much lower than demand, so I bet you'll find more work. Or you can retire and repair bicycles for a living. You'll do fine.

"Encryption" of media like that is always just going to be obfuscation, you get protection form the anti DMCA removal law, the actual encryption isn't worth the bits it flips. In fact, if you make it "stronger" from a cryptographic standpoint you simply make it cost more to decode and add no strength to the actual defense it is trying to provide (getting further under DMCA umbrella). If you want to criticize it was probably foolish to include actual encryption in the first place, why waste cycles when you can XOR with 0x69?

And what about the 6.68 billion people that are not subject to the DMCA?

If the US treaty negotiators get their way, DMCA will become pretty much universal world-wide.

> write the software you want, not the software you think someone wants you to write

It's not always that easy =(

write the software you want, not the software you think someone wants you to write.

This brings up the thought of whether some of the developers for locked-down systems like game consoles, phones, tablets, etc., are deliberately introducing vulnerabilities with the intention of enabling users to use them to take control of their devices, and of course they would behave entirely as if it was accidental. It's somewhat far-fetched and optimistic, but certainly a nice possibility to think about...

I feel like it's more of a case of "Never attribute to malice that which is adequately explained by stupidity.".

Even though console/content lockdown is a business line item, it's not as much of a priority to the business to ship a console that will sell well, and to develop it with deadlines that are too short.

I liked that last phrase, so I generalize it:

Remember: you're the Xer -- do the X you want, not the X you think someone wants you to do.

Let's try that principle in a few other contexts.

"Remember, you're the politician. Pass the laws you want, not the laws you think the electorate want you to pass."

"Remember, you're the soldier. Fight the wars you want, not the wars you think your country's leadership want you to fight."

"Remember, you're the fireman. Fight the fires you want, not the fires you think the person who called 911 wants you to fight."

The idea that you should do whatever you want regardless of the team or management you work with looks pretty dumb when you apply it to situations that actually matter. The world would not be a better place if everyone decided to just assume they're right all the time and ignore everyone else.

The idea that you should do whatever you want regardless of the team or management you work with looks pretty dumb when you apply it to situations that actually matter.

I see that principle as putting the responsibility back into the shoulders of the person carrying the action. I see it as a way of ignoring the "just following orders excuse".[1][2] So no, I don't think it looks pretty dumb, I think it is as something to consider seriously.

[1] http://en.wikipedia.org/wiki/Superior_orders

[2] http://en.wikipedia.org/wiki/Milgram_experiment

Edit: Added footnotes

I see it as a way of ignoring the "just following orders excuse".

You're going to Godwin the thread? Really?

If you do want to make that argument, please consider firstly that the Nuremberg defence failed, in that particular context, because it was considered so obviously inappropriate for the defendants to act as they did just because they were ordered to do so that they should have known better and refused to comply.

Secondly, please also consider that the Nuremberg verdicts stand in stark contrast to normal military discipline in basically every armed service in the world, where refusing to follow a lawful order from a superior officer is grounds for a court martial and potentially a severe punishment.

In particular, the current situation recognised by the International Criminal Court and the 100+ signatory states to the Rome Statute lists only genocide and crimes against humanity as manifestly unlawful, potentially admitting the superior orders principle as a defence in other cases where the defendant believed they were complying with a lawful order. This is even noted in one of the links you gave yourself.

In any case, I would hope we all agree that being instructed to implement a software safeguard against criminal production of counterfeit currency is not on the same scale as being instructed to execute millions of innocent people in gas chambers.

There are multiple dimensions to command and authority. Let's try these:

"Remember, you're the politician. Pass the laws you want, not the laws the party leaders say you should pass."

"Remember, you're the soldier. Complete the mission without unnecessary collateral damage, even though you wouldn't be punished for killing civilians unnecessarily."

"Remember, you're the fireman. Exercise caution the way you want, not how you've seen firefighters in movies act."

Sometimes you should ignore people and pressure to do the right thing.

Remember: you're the software quality engineer -- test the meaning of the requirements, not the text of them.

Reply on news.ycombinator.com