Fabulous Adventures In Coding
Eric Lippert is a principal developer on the C# compiler team. Learn more about Eric.
“Diet Dr. Pepper tastes more like regular Dr. Pepper.”
That was a previous advertising slogan for Diet Dr. Pepper, my personal favourite source of both caffeine and phenylalanine; I’m drinking it right now as I write this.
The present slogan is the brain-achingly oxymoronic “Diet Dr. Pepper: There’s Nothing Diet About It” – really? Seems like one ought to change the name then, if the name of one’s product is so misleading as to require its complete and utter disavowal in the slogan.
But that’s not what I want to talk about today. I actually want to talk about predicates.
The word “predicate” is one of those slippery words that has multiple technical meanings depending on the domain, all related but subtly different enough that one really ought to carefully call out how one is using the term.
What all of these things have in common is that a predicate is something into which you can "substitute" a value to obtain a result of either truth or falsity.
What on earth does this have to do with Diet Dr. Pepper tasting more like regular Dr. Pepper?
Is “tastes more like regular Dr. Pepper” actually a predicate? If it is then when it is applied to a subject it must produce a statement which can be classified as true or false. Let’s leave the subjective nature of taste aside for a moment; that’s not the fundamental logical problem here.
Rather, consider this utterance: “Diet Dr. Pepper tastes more like” Is “tastes more like” a predicate? Of course not. That utterance doesn’t make any sense. Tastes more like… what? This utterance cannot be classified as true or false for any subject, so the latter part of it cannot actually be a predicate.
But the same thing goes for “tastes more like regular Dr. Pepper”! Tastes more like regular Dr. Pepper… than what?
In order to actually be a predicate it needs more objects. For example, “Diet Dr. Pepper tastes more like regular Dr. Pepper than a pint of Guinness tastes like a mango lassi” is a statement which actually has a truth value. Perhaps a subjective and arguable truth value, but at least this sentence has the form of a statement with a subject and a real predicate now. The original slogan’s “predicate” isn’t really a predicate at all; one might think of it as a pseudopredicate.
Advertisers love pseudopredicates. Once you realize that they exist you see them all the time. Advertisers love them because they make no testable claim which could be shown to be false in a court of law. Rather, they rely on either the irrational belief that “more” anything means “better”, or upon your brain’s ability to fill in the rest of the objects which they intend you to infer.
In this particular case, I imagine that the crafters of this slogan intended your brain to fill in “Diet Dr. Pepper tastes more like regular Dr. Pepper than our previous formulation of Diet Dr. Pepper tasted like regular Dr. Pepper” – that is, they want to make the claim that the product has improved without making the admission that the previous formulation was less than delicious.
Or, perhaps they want you to fill in “Diet Dr. Pepper tastes more like regular Dr. Pepper than Diet Coke tastes like regular Coke” – that is, they want to assert that their product is superior to a competing product. This assertion is in my personal opinion true, but the Coca Cola company could potentially take issue with if stated baldly as an objective claim. By relying upon a pseudopredicate to make a slogan which actually is so malformed as to have no truth value at all, the copywriters duck these thorny issues. There are lots of ways that clever advertisers leverage our tendancies to "fill in the blanks" in order to sell products.
That’s not actually what I want to talk about today either. I actually want to talk about writing secure code.
What on earth does Diet Dr. Pepper tasting more like regular Dr. Pepper have to do with writing secure code?
The other day I got a question about the characteristics of a particular bit of source code obfuscation technology, which we shall call X; what the technology actually consists of and what the precise question was are irrelevant to this discussion.
I answered the question with a question; I asked why it was that the questioner wanted to use technology X. The answer was “To protect the source code”. Leave aside for the moment the fact that I could probably have deduced from the original query that the questioner was interested in protecting some resource. There’s a deeper problem here. In the utterance “technology X protects the source code”, is “protects the source code” a predicate, or a pseudopredicate?
It’s a pseudopredicate. There is an object missing. To make this a predicate, it needs to be something like “protects the source code from casual inspection and editing by snoopy people” – as it happens, this predicate was true for technology X. What I was rather worried about was that the questioner actually had in his head the predicate “protects the database administrator password that I’ve stuck into my source code from discovery and misuse by a determined and intelligent attacker”. That predicate happens to be utterly false for technology X. Because he was not actually stating a predicate that could be true or false of X I was unable to answer the guy's question about X.
I never, ever lock my car doors anymore. Why? I drive a soft-top convertible. One day I woke up to discover that someone had sliced open the top and unlocked the car. The two bucks in quarters I keep in the car for parking meters was a trivial loss compared to the hundreds my insurance company paid to get the top replaced and the hours of my time wasted in dealing with the situation. The locks are not a mitigation to that vulnerability at all! Locking my car doors makes it more prone to be damaged, not less.
I do, however, lock my house, to protect it against random people wandering in. However, the locks are hardly any mitigation to the vulnerability of the house to determined attack from a wily, hostile burglar. It would be foolish of me to say that “the locks protect my house” without mentioning the threat.
What I’m rambling on about here is this: the fitness of a particular security technology to mitigate a vulnerability can only be evaluated in the context of a stated threat against a stated resource. That’s because every security technology is designed to mitigate specific vulnerabilities to particular threats. When you’re evaluating the benefit of a particular security system, make sure that the predicates you are using to talk about the system are actually predicates, not pseudopredicates; state the threats.
I've always been bothered by that Dr. Pepper slogan. My brain filled in the blanks as "Diet Dr. Pepper tastes more like Regular Dr. Pepper than Regular Dr. Pepper tastes like Regular Dr. Pepper". I guess that's sort of like giving 110% effort.
My brain also fills in the blanks like Peter Thatcher's does...
Great post, and very well done to write using a context that a hobbyist/non-pro like me can easily digest. Usually I don't have the brain-space to properly digest your other articles!
So, Kyle, what about "Diet Dr. Pepper: There's Nothing Diet About It" ? What is the listener's obligation to the speaker of that particular gem?
Kyle: I think you make some good points. However, in cases of ambiguity, there are other options than the speaker being deceptive or mis-speaking. There's also the possibility that the speaker mis-thought or mis-understood. In Eric's obfuscation example, it's quite plausible that the speaker thought that "protects the source code" is a predicate all by itself, and if so, that misapprehension needs to be corrected in order to properly answer the question.
There are also subtle issues of emphasis in spoken English that convey extra information when there is a shared context:
THESE cookies taste better (implication: than those cookies)
These COOKIES taste better (implication: but the cake is still terrible)
These cookies TASTE better (implication: but they're still too crumbly)
These cookies taste BETTER (implication: but still not very good)
So where is the car right now? :)
I absolutely love the clarity you bring to any topic written on your blog. I think you would make a great teacher!
Probably become a .NET trainer. I would pay a premium to attend classes where you are the trainer.
Thanks JD, that's a kind thing to say. I do enjoy teaching, and might do more if I ever retire from this job.
All this talk of Dr Pepper is making me think of buying one.
Seriously though, as a lawyer (as well as amateur programmer), much of our work in drafting contracts or bringing or defending claims, I would suggest, is about spotting and challenging the use of pseudopredicates by others, and ensuring that your contract obligations or claims are expressed as full predicates, and better still, the predicates our client had in mind.
"Diet Dr. Pepper: There's Nothing Diet About It"
This is what is called a lie. It obviously has something Diet about it, its name.
Pseudo-Predicates in Specifications
Using Dr. Pepper is always a good technique to get me to read a tech blog. Not often does it leads to an excellent and entertaining social commentary on how we ("the unwashed masses") allow ourselves to be lead astray by reading our own goals / hopes / dreams / fears into other peoples (inaccurate) statements. Nor is it surprising, and worth remembering, that some people out there would use "especially malformed English" to "exploit this weakness" and "cause arbitrary behaviour to executie in the host brain." Vey funny!
An excellent reminder that “accurate language leads to accurate thinking.”
Visiting with my cousin, who has her PhD in physics, often reminds me how inaccurate my language becomes. No excuses - but I blame working with business folk all day long. Which leads to the corollary statement:
“Inaccurate language leads to accepting all sorts of silly thinking.” Remember this one next time you're in a management or marketing meeting! ;-)
That's why I always leave the top off. The day someone wants to steal my car, the top won't stop them. And I don't know why obfuscation makes people think their code is "secure", since I've seen whole products being reverse-engineered in hours even after obfuscation - you won't stop smart people with casual solutions. Great article, I'll recommend it to many consulting friends out there :)
Here's a radical thought,
Does obfuscation actually protect your code less?
I remember a legal case being bought against a certain technology company we all know on the basis that portions of its code was taken directly from another companies code. With obfuscation your code is likely to produce very similar MSIL but possibly more different than if you and another produced the same algorithm, without obfuscation. So in this manner you have less evidence of code theft.
Not that I expect anyone here would ever decompile/disassemble a competitors product to solve particular issues.
"The commercial for Diet Dr. Pepper says it tastes just like regular Dr. Pepper. Well then they ****ed up!" - Mitch Hedberg.