July 23, 2014
on trust, Trust, trusted, trustworthy and other words of power
Follows is the clearest exposition of the doublethink surrounding the word 'trust' that I've seen so far. This post by Jerry Leichter on Crypto list doesn't actually solve the definitional issue, but it does map out the minefield nicely. Trustworthy?
On Jul 20, 2014, at 1:16 PM, Miles Fidelman <...> wrote:
>> On 19/07/2014 20:26 pm, Dave Horsfall wrote:
>>> A trustworthy system is one that you *can* trust;
>>> a trusted system is one that you *have* to trust.
> Well, if we change the words a little, the government
> world has always made the distinction between:
> - certification (tested), and,
> - accreditation (formally approved)
The words really are the problem. While "trustworthy" is pretty unambiguous, "trusted" is widely used to meant two different things: We've placed trust in it in the past (and continue to do so), for whatever reasons; or as a synonym for trustworthy. The ambiguity is present even in English, and grows from the inherent difficulty of knowing whether trust is properly placed: "He's a trusted friend" (i.e., he's trustworthy); "I was devastated when my trusted friend cheated me" (I guess he was never trustworthy to begin with).
In security lingo, we use "trusted system" as a noun phrase - one that was unlikely to arise in earlier discourse - with the *meaning* that the system is trustworthy.
Bruce Schneier has quoted a definition from some contact in the spook world: A trusted system (or, presumably, person) is one that can break your security. What's interesting about this definition is that it's like an operational definition in physics: It completely removes elements about belief and certification and motivation and focuses solely on capability. This is an essential aspect that we don't usually capture.
When normal English words fail to capture technical distinctions adequately, the typical response is to develop a technical vocabulary that *does* capture the distinctions. Sometimes the technical vocabulary simply re-purposes common existing English words; sometimes it either makes up its own words, or uses obscure real words - or perhaps words from a different language. The former leads to no end of problems for those who are not in the field - consider "work" or "energy" in physics. The latter causes those not in the field to believe those in it are being deliberately obscurantist. But for those actually in the field, once consensus is reached, either approach works fine.
The security field is one where precise definitions are *essential*. Often, the hardest part in developing some particular secure property is pinning down precisely what the property *is*! We haven't done that for the notions surrounding "trust", where, to summarize, we have at least three:
1. A property of a sub-system a containing system assumes as part of its design process ("trusted");
2. A property the sub-system *actually provides* ("trustworthy").
3. A property of a sub-system which, if not attained, causes actual security problems in the containing system (spook definition of "trusted").
As far as I can see, none of these imply any of the others. The distinction between 1 and 3 roughly parallels a distinction in software engineering between problems in the way code is written, and problems that can actually cause externally visible failures. BTW, the software engineering community hasn't quite settled on distinct technical words for these either - bugs versus faults versus errors versus latent faults versus whatever. To this day, careful papers will define these terms up front, since everyone uses them differently.
July 22, 2014
How Central Banking magnifies the Crisis and ensures Depression
he current times are fantastic opportunities for a new generation of economists to cut their teeth, albeit in studying the misery of us all. Here's some of that, cutting of teeth or gnashing, you decide. H/t to Arthur, here is the punchline from "Banks, government bonds, and default: What do the data say?" from Nicola Gennaioli, Alberto Martin, Stefano Rossi:
The transmission mechanism
Our results support the notion that banks’ holdings of public bonds are an important transmission mechanism from sovereign defaults to bank lending. These findings are broadly consistent with the following narrative. Public bonds are very liquid assets (e.g. Holmstrom and Tirole 1998) that play a crucial role in banks’ everyday activities, like storing funds, posting collateral, or maintaining a cushion of safe assets (Bolton and Jeanne 2012, Gennaioli et al. 2014a). Because of this, banks hold a sizeable amount of government bonds in the course of their regular business activity, especially in less financially developed countries where there are fewer alternatives. When default strikes, banks experience losses on their public bonds and subsequently decrease their lending. During default episodes, moreover, some banks deliberately hold on to their risky public bonds while others accumulate even more bonds. This behaviour could reflect banks’ reaching for yield (Acharya and Steffen 2013), or it could be their response to government moral suasion or bailout guarantees (Livshits and Schoors 2009, Broner et al. 2014). Whatever its origin, this behaviour is largely concentrated in a set of large banks, and is associated with a further decrease in bank lending.
There you have it. In short human words, the need for banks to hold the bonds of their government becomes a limit on their lending activity. As they enter crisis (the banks, the government or the economy), the banks are incentivised to hold more bonds. As they hold more bonds, their lending decreases.
Reducing lending confirms the recession, and indicates why we now see full depression in Southern Europe.
I've oft ruminated on the failure of economics that is central banking; it works until it doesn't. Central banking works thusly:
- the government wants someone to hold their bonds.
- it needs a central bank to regulate the banks,
- to insist that the banks hold their bonds.
- The quid pro quo for this is that central banks will backstop the banks.
- So, happily, the government can now issue more bonds than is good for it,
- force the banks and itself into trouble, and
- pass the cost onto the public (inflation or bailouts).
Notice that part 7 -- the cost of central banking always ends up with the citizen through either bailout (taxpayer) or inflation (money-holder). One destroys the middle classes, the other penalises the poor through their cash holdings. (The rich know that the safe money is now in owning and running the banks, who win always because they are rarely forced into real bankruptcy.)
One thing that strikes from that is the history of banking (c.f. Dowd especially) suggests that the requirement to hold state bonds is what brought the end to free banking in the USA. Now fast forward to Europe, and what brought the end was banks and governments over-extended in a deadly embrace.
The common factor is the lack of ability to inflate. The individual states in the USA weren't able to issue their own dollar, because money was competitive. The individual states in Europe are likewise unable to inflate away their trouble, because they gave that up to ECB.
What's left is bailouts.
Postscript, adding the graph that Patrick refers to in comments:
July 17, 2014
Casebook for a disaster: google's BebaPay and why it is wrong, wrong, wrong
USA press are starting to poke fun at BebaPay, the google payment system for Kenya's mass transit buses called matatus.
Now the secret's out. BebaPay is a casebook study in how not to do a payment system, but it is still a bit of a challenge to try and show why. This is an effort in as few of my words as I can.
Hitler is a matatu, electric raspberry in color, one of the thousands of minibuses that serve as Nairobi’s subway system. ... Hitler has been misbehaving lately, refusing to adopt a new technology that could revolutionize one of East Africa’s most lawless and lucrative cash-based industries.
Google, which some could argue also has a funny, funny name, has been pushing the new technology: a little green transit card that will replace cash payments and track every transaction on the minibuses, ...
Hitler, owned by someone who hasn't heard of Godwin's Law, is typical of mass transit in Africa. Google wants them to take BebaPay, a smart card (NFC) payments solution, instead of that filthy cash stuff.
... owners typically demand from the crews a flat fee for using their buses for the day, the drivers and conductors squeeze every cent they can from passengers by stuffing them in as tightly as possible and getting them to their destination at deadly speed. ... If a cop stops a matatu for speeding or overloading, no problem. The driver just shoves a fistful of Kenyan shillings out the window.
In short: cash-based opportunities for corruption, “kitu kidogo,” Swahili for “a little something” means the market will fight it, not adopt it. The players will sabotage it.
The journo spotted it, why didn't google?
The idea to use technology to tackle the matatu problem started on a rainy day a couple of years ago when some executives at Google were staring out their plate-glass windows at the matatus stacked up on Uhuru Highway, watching passengers pay double for a ride (matatus always jack up fares on rainy days). The Google executives said, What about a transit card?
They invented it in a glass fishbowl. It's as if the 'google executives' didn't go for a matatu ride, or if they did, they closed their eyes and prayed for a quick return.
Surely wiser heads warned?
“People thought Google was crazy to go into Kenya’s transport sector,” said Dorothy Ooko, an executive at Google’s 40-person office in Nairobi. “When we first got involved, nobody wanted to touch this.”
Why didn't they listen? Or at least try and figure out the market, and enter into positive part of it, not a part that will deliberately and systematically sabotage their every step?
One answer is written on the side of another matatu I saw in Nairobi, literally. Unfortunately I couldn't get my android to camera-mode fast enough, but I believe I have the words memorised:
Unless your name is google, stop acting like you know everything
Please, someone, anyone, send me a snap of it!
July 13, 2014
Clinkle crinkle CLUNK
The shine is off Clinkle, the amazing little app that last year landed 30 million dollars for a demo. What were they thinking, people asked? Apparently we now know, they weren't thinking:
“[Executives] came in thinking, ‘OK, this product is launching soon,’” the former employee explains. “Then they realized the back end is not ready, the front end is not ready, Lucas is re-thinking the design, the architecture is not laid out, there’s no security framework, there’s no fraud detection framework, the bank contract is still being signed, the payment processor still needs a lot of work, and they still haven’t figured out who the credit card processor is going to be. These people got overwhelmed.”
Well, there you have it. For the record, I've never done a demo in those terms. All my tech has always been shown in the raw -- when it shows a payment, it is a payment, it's transactional, secure, crypto all the way down.
Investors take note: financial cryptography doesn't really work with screen-shot style demos, HTML5, Flash whatever your poison. If you're looking at ideas on screen, no matter how beautifully drawn or rendered, you're investing in turtles. All the way down.
Don't go there.
Having said that, it takes a special person to even see the entire architecture of financial cryptography and its 7 layers. Hats off to Lucas Duplan for even coming close to building the demo. We don't know what his secret sauce is, and I'd be suspicious that it's even secret or sauce .... but the man can sell.
If he hooked up with a team that could build FC, he'd be dangerous.
But reality is what it is. Second mistake is to believe that he can do it all; the sad sad truth of the startup world is that the Zuckerberg mythology as so aptly shown in the film _The Social Network_ is a one-off. A rarity proven in the exception. It isn't reality, it isn't likely, and it isn't something we should be fooled by. in practice, it takes a serious amount of knowledge to field an FC product, and Declan should hand over the CEO rule and reduce himself to supporting a bigger team, not directing it.
Before that, however, it seems that we have some more hurdles to get over:
For the first time, all Clinkle employees are finally testing out a basic version of the app and moving money.
Alley-oops! No, I really don't think so. You don't go from "there’s no security framework" to moving money just like that.
How do I know that? Well, the thing is that a model for secure payments is so hard that it basically has to derive from someone who's done this sort of thing before. Otherwise, you're asking for a miracle in the making. None of these things are currently evidenced in Crinkle's publicity, so they almost certainly don't have a model for secure payments.
Therefore, Clinkle employees are testing out opportunities for fraud. The real question is, who picks up the tab when the money gets raided? If it is the back-end processor, that contract won't last a week. If it is the consumer, the reputation will lose its shine, and CLUNK. If it is the investor, the question is likely how long they can last while adding the security on later. Etc.
Better off to invest in a complete tech-business-governance model to begin with, methinks.