Almost forgotten in the financial world, but e-gold, the innovative digital gold currency issuer based in Florida, USA (and nominally in Nevis, East Caribbean), was one of the biggest early targets for phishing [1]. Because of their hard money policy, stolen e-gold has always been as highly prized by crooks as by its fan base of libertarians and gold enthusiasts [2].
Now it seems that they may have had success in stopping phishing and keylogging attacks; anecdotal reports indicate that their AccSent program has delivered the goods [3]. The company rarely announces anything these days, but the talk among the merchants and exchangers is that there's been relative peace since May. Before that, again anecdotally, losses seemed to be in the "thousands per day" mark, which racks up about a million over a year. Small beer for a major financial institution, but much more serious for e-gold which has on order of $10 million in float [4].
From the feelings of merchants, it seems to have been somewhere between totally successful and stunningly successful. Nobody's prepared to state what proportion has been eliminated, but around 90% success rate is how I'd characterise it. Here's how it works, roughly [5]:
"AccSent monitors account access attempts and issues a one-time PIN challenge to those coming from IP address ranges or browsers that differ from the last authorized account access. The AccSent advantage is that e-gold Users need not take any action - or even understand what an IP address or a phishing attack is - to immediately benefit from this innovative new feature. However, as powerful as AccSent is, the best protection against phishing and other criminal attacks is user education."
If it stomps phishing and keylogging dead for e-gold, is this a universal solution? I don't think so. As welcome as it is, I suspect all this has done is pushed the phishers over to greener pastures - mainstream banks. If every financial institution were to implement this, then the phishers would just get more sophisticated.
But in the meantime, this is a programme well worth emulating as even if it makes it just hard enough to push the victims down the street to the next muggins, that's welcome. This is the equivalent of putting deadlocks on your doors. The point is not to make your house impenetrable, but to make it harder than your neighbour's house.
It's also welcome in that any defence allows the people who have to deal with this get to grips with phishing and keylogging attacks in a concrete manner. Until now, there's been precious little but hot air. Concrete benefits lead to understanding and better benefits. Hot air just leads to balloons.
[1] Earliest report of a phishing attack on the company is 2001.
[2] See the May Scale, the essential Internet moneterists guide showing e-gold at #3.
[3] e-gold's Account Sentinel is described here: http://e-gold.com/accsent.html
[4] Compare this with the guestimates of around a bllion for mainstream phishing losses:
http://www.financialcryptography.com/mt/archives/000159.html
[5] A news snippet here: http://e-gold.com/news.html
In a curious crossover reminiscent of financial cryptography (!), here's an article from LinuxInsider that deals with all that good governance stuff coming out of the Sarbanes-Oxley mess. Even more curious, I don't disagree that much with what Paul Murphy had to say.
Sarbanes-Oxley: More Cause Than Cure?
Nothing more to say ... check it out if you are into governance.
One of the forgotten wars - TCP/IP versus the OSI stack - was reminded by Lynn Wheeler in a discussion of history. It was so forgotten that it took me a while to recall that indeed it was a war.
For a while, in about 1988, I was part of the standards committee for OSI, or at least the national chapter. My logic for joining was that I would learn about the future, and get a jump on everyone else.
Also, I got the protocols for free which made for a significant benefit, as no-one could afford to buy them. Every week protocol drafts turned up for review, and I read most of them diligently, looking for issues and recommendations. I didn't have much to say, because by the time they got to me, the protocols were either pretty "correct" or too big to absorb. I think others felt the same way, as I never came across any evidence that any one else was reading them.
After a year of this, I got a bit disillusioned. I'd submitted a bug in one of them - the sliding window calculations in the core TCP-like protocol were wrong - and nothing had happened. Mysteriously, the bug is still there, as far as I know. I'd noticed that the stack of protocols was exploding - upwards, sideways, backways, every way you could think of - but there wasn't that much evidence that anyone except big corporates was doing any implementation.
Meanwhile, those who wrote protocols were chugging along and connecting people, as if ISO didn't exist. And those networks were delivering value, whereas the standards bodies were not. So I left, and got back to real work.
My time was well spent. It taught me the value of real work as opposed to time wasting committees. Today's alliances and cartels and these or those initiatives are no different. Quick test - which Internet alliance has deployed a real successful product? Longer test, what percentage do you get dividing that number into the total number of cartels?
For old timers, Lynn's words are spooky. I was there, I was!
some of this was replayed in alt.folklore.computers a number of different times over the past 8-10 years. i have a little of it archived at http://www.garlic.com/~lynn/internet.htm as referred to in the above ... there is big difference between technology and operational service. while tcp/ip came into deployment in 1/1/83, a big change-over was the deployment of NSFNET1 & NSFNET2 backbones. These were NSF contracts with commercial entities. There is something to the effect that commercial entities sunk into NSFNET1 between four to five times what NSF actually paid in the contract (as part of promoting an operational, viable infrastructure ... and even more in NSFNET2).
misc. additional refs at:
http://www.garlic.com/~lynn/rfcietf.htm#history
in the late '80s and the early 90s the federal gov. had switched was actively trying to kill tcp/ip and was mandating OSI ... there was a bunch of stuff about GOSIP ... the federal government mandate to eliminate tcp/ip and move to OSI. some specific posts on gosip
http://www.garlic.com/~lynn/99.html#114
http://www.garlic.com/~lynn/99.html#115
http://www.garlic.com/~lynn/2001i.html#5
http://www.garlic.com/~lynn/2001i.html#6
at Interop '88, well over half the booths were demo'ing some sort of OSI related stuff. misc. past post/thread talking about OSI
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
misc. posts discussing interop '88
http://www.garlic.com/~lynn/subnetwork.html#interop
one of the issues (during this period) in the ISO & ANSI standards bodies was there was a mandate that no standards work could happen on anything that didn't conform to the OSI model. That represented a big problem. The "IP" or internetworking layer doesn't exist in OSI and therefor nothing could happen that involved internetworking (strong assertion that the internet is successful precisely because of the internetworking layer ... which is forbidden by ISO & ANSI as not existing in the OSI model. Another thing that doesn't exists in the OSI model is LANs. I was involved in some work with high speed protocol to standardize in ISO/ANSI. However it was rejected for 1) it went directly to the LAN/MAC interface (forbidden because LAN/MAC doesn't exist in the OSI model) and 2) it wen directly from layer 4 to MAC layer (bypassing the layer 3/4 interface, also a violation of the OSI model).
random other arpanet, nsfnet, internet postings
http://www.garlic.com/~lynn/subnetwork.html#internet
concurrent with the tcp/ip in the early & mid '80s was bitnet in the US and earn overseas
http://www.garlic.com/~lynn/subnetwork.html#bitnet
specific post of NSFNET announcement
http://www.garlic.com/~lynn/2002k.html#12
misc. additional NSFNET references
http://www.garlic.com/~lynn/2000e.html#10
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Naming and shaming was at its finest last night as the Big Brother awards were presented to Britain's worst by Privacy International. The winners included British Gas, the US VISIT fingerprinting programme, and the British Minister for Children, see the articles below for details.
It's hard to measure conclusive success for these awards, as no doubt the winners will pretend to shrug their shoulders and carry on their evil works. But it seems to give some pause for thought: I bumped into a couple of people there who were potential winners, and even though not directly addressed by this year's lists, there was an almost masochistic sense of wanting to see and experience that which was beyond the pale. So I'd conclude that there is a significant knock-on effect - companies know of and are scared of the awards.
It occurrs to me that there is room for an award or two in our field. Maybe not FC, which is too small and fragmented as a discipline ... but certainly in the application of cryptography itself.
Negative awards could include
Positive awards also should be given. I'd suggest:
I'm sure there are lots of other ideas. What we need is a credible but independent crypto / infosec body to mount and deal such an award. Any takers?
Here's a couple of articles on the awards, FTR:
http://news.google.com/url?ntc=5M4B0&q=http://www.theregister.co.uk/2004/07/29/big_brother_awards/
http://management.silicon.com/government/0,39024677,39122716,00.htm
The Economist has covered the early days of Unix, searching for why Unix and its companion language, C, became so important. They cover it fairly well.
Each successful technology carries its lessons; indeed it is hard to see how a successful technology cannot bring forth some new lessons, just in order to beat the status quo. The cleanliness of the Java virtual machine over the evils of C's buffer overflows and core dumps, for example.
The article didn't get it all, of course. One of the results of the beauty of the design was that the doco was rather small. I recall an experienced programmer, John, standing up in an early user group meeting holding up the manual. "I can take this home in my briefcase," he said, whereas other operating systems filled boxes and book shelves.
Of course, that bug was eventually fixed, and Unix joined its competitors in shipping with boxes of manuals.
Another artifact of the nominal or free delivery to Universities was that by the time the late 80s came around, there were enough software engineers that had trained at University that Unix was an easy sell. When selecting an OS for some project, it was pretty easy to say, "I want something like Unix." And that's one of the two punches that defeated IBM, the other being the PC.
The article also glosses over the role of BSD. It became the competitor, and it also became the one that fixed the (academic) shortfalls for the (commercial) real world. Virtual memory being the chief of those, but also more features, and less security. It's mostly forgotten these days, but BSD blazed the insecurity trail by mostly ignoring issues that the Bell Labs people thought sacrosanct, in the quest for more features.
Yes, we in the Bell labs religion hated the Berkeley religion, but it became the one to open up the net and practically every other application. Partly because the Californians didn't care about security, and partly because they could see the benefit in fast and furious communications. Of course, there were a dozen other lessons, and that's the story of the Internet, not of Unix, but the parallels with Microsoft's current day dilemma are worth pondering over.
On a closing note,
"Dr Pike says that the thing he misses most from the 1970s at Bell Labs was the terminal room."
It's true, I grew up in those places, and now that I think about it, we are only just now recapturing that spirit. The article seems to think that the open source community has inherited the legacy of Unix's collaborative spirit, but I disclaim that: email is too clunky.
Only with IM and potentially VoIP are we at the verge of re-creating the terminal room.
Over on the cryptography list, Perry Metzger writes:
> I hope you have no customers who you have advised to ignore the
> eavesdropping problem, because they stand a good chance of getting
> badly hurt.
As Perry Metzger declined to permit a rejoinder to that astouning claim on his list, I'll respond here. Warning: It takes few words to be wrong, many words to present a fairer picture.
Perry Metzger is confused by my search for Eve. We can address this at several levels:
1. Firstly, "In Search of Eve - the upper boundary on Mallory."
2. In the crypto world, what we do is to attack crypto systems. In fact, over in the cryptography algorithms side (as opposed to the protocols world of software engineering) professionals are encouraged to attack other people's systems for a decade or so before attempting to invent their own.
But, attacking crypto systems should not be misunderstood as meaning anything beyond the search for weakness so as to improve the result. Exposing a weakness is not a suggestion to turn off the system. It's an invitation to think about the weakness and improve it in future deployments.
3. Oddly enough, in our systems for financial trading, we do indeed tend to tell customers not to worry about the eavesdropping problem! That's because:
a) almost all financial fraud happens on the inside, and our systems are very strong there - unlike anyone else's financial systems who are generally wide open to fraud (not to do with crypto or software engineering,
but see for example "Mutual Funds and Financial Flaws"),
b) even if people could do eavesdropping, the frauds are more limited to things like insider trading and external attacks like competitive trading (recall I posted on fibre vampires earlier this year!),
c) we (and other financial cryptographers) throw in end-to-end encryption protection as a giveaway.
Perry Metzger is almost correct in what he suspects - our system would run 99% as strongly without any eavesdropping protection because most of the threat is on the inside. But, hey, once the software is built in, we tend to leave it in place. It's free, it's end-to-end, and it's transparent. Refreshingly unlike the protection that people are accustomed to getting from the CA/PKI model employed in SSL.
4. On the point of actual cryptographic protection: The systems we have implemented in financial cryptography have generally used RSA 1024+/-, triple DES and so forth. The difference between those systems and the systems others are perhaps more used to is that financial cryptography systems are much more strongly aligned to the customer's needs. For example, my work is the only work where anyone has successfully integrated digital signatures with human contracts, AFAIK, just by way of example ("The Ricardian Contract").
Gary H's SOX is in fact stronger than SSL not because it uses more or less bits but because it is integrated end-to-end. From the issuer to every transaction, it much more clearly aligns to patterns of trade than say something like SSL, which is a connection-oriented product and is thus extremely limited in the protection it can give to any particular business. (Although SOX is almost entirely unscrutinised by outsiders, so there may be bugs in there. I know of one, for example.) See 3., above for why we don't make a song and dance about it.
5. People in financial cryptography have a long history in basic crypto. We started the Cryptix group - the first solution for Java cryptography of any form. I believe it stands on its merits (albeit, it has being overtaken by BouncyCastle these days). Our work with PGP in Java (libraries in 2.6 and OpenPGP) was based on a view that it provides far more security as a model than others can ever hope to achieve (SSL and SSH), simply because the OpenPGP as a model is more aligned to what is needed by people and businesses.
Our Cryptix group provided all the Java infrastructure for the AES competition, running the gauntlet of Americans and foreigners working together to develop strong crypto. Even though we were there at the start, and the finish, we still haven't got around to putting our (public domain) Rijndael into SOX. Why? 3DES does the job.
In closing, when financial cryptographers say "don't worry about the eavesdropping problem," then customers don't need to worry. It's been taken care of, one way or another.
The primary reason for looking at threats is to develop a threat model [1]. This model then feeds into a security model, which latter decides which threats we can afford to deal with, and how.
But I have a secondary reason for looking at threats. An ulterior motive, as it were. I'm looking for reports of eavesdropping. Here's why. It's not the normal reason.
For the sake of today's polemic, on-the-wire threats divide into a few broad classes: denial of service, traffic analysis, eavesdropping, and the man-in-the-middle attack (MITM). Let's ignore the first two [2] and look at how the HTTPS protocol addresses eavesdropping, committed by Eve, and the MITM, committed by Mallory.
To defend itself, browsing has three major possibilities open to it: open HTTP, self-signed certificates and Certificate Authority (CA) signed certificates [3].
Of those, HTTP defends merely by the presence of masses of other traffic. Hiding in the noise of the net, as it where, which isn't much protection if someone is looking at you, directly, but it's better than nothing, and it's free.
CA-signed certs, on the other hand, protect by comprehensively negotiating secure connections between known parties. Sounds great, but they are expensive both to buy and to install [4] This is the reason why HTTPS is not widely deployed [5]: it's simply too darn expensive for an Internet that was built on "free".
Somewhere in the middle sits the self-signed cert. It can be generated within software, for free. There's no technical reason why a server can't deploy a self-signed cert automatically, and no good business reason why not, either [6]. It's a matter of a few seconds to create, and the SSL protocol handles it just fine.
It would seem to be a no-brainer that HTTPS would deploy much more widely, more rapidly, and more conveniently if it could bootstrap with self-signed certs.
Self-signed certs provide complete, 100% protection from eavesdropping. But they do have one weakeness - the MITM. Mallory can sneak in on the first connection or use and take control. And this weakness is touted as the major reason why, de facto, browsers force the use of CA-signed certs by discriminating against self-signed certs with popup warnings and dialogs and complicated security displays.
So the question comes down to this: How much security do we get by choosing CA-signed certs over self-signed certs? That question comes down to two things: how costly is an MITM, and how frequent is it.
Declaring my hand immediately, I don't think the MITM exists [7]. Or, Mallory is so rare that he will never be a threat. But I can't prove a negative. Also, say some, surely there is some merit in the argument that he isn't there because we deployed HTTPS? But that is to confuse cause and effect - we still need to prove that Mallory is present in any sense if we need to show that we have to protect against him.
There was little or no evidence of Mallory before HTTPS. And there is precious little now, in any field of computing endeavour [8].
There is another way however - instead of measuring Mallory, we can measure a *proxy* for Mallory. This is quite a sensible approach, and is widely used in statistics and risk measurement.
Eve is a great proxy. Here's why: Anyone likely to launch a man-in-the-middle attack is almost certainly eavesdropping already. And anyone who can't eavesdrop has no chance of running an MITM, skills-wise. Plus, Eve is a low risk attack, whereas Mallory takes risks by sending out packets.
So, the set of all MITMs is a subset of all eavesdroppers, at least for statistical purposes. We find Eve and we find something about Mallory - an upper bound.
We can't measure Mallory, he's simply too rare. But we could set at least an upper bound with a measure of Eve, his naughty cousin. And if that upper bound comes in at serious levels, we might deal with it. If not, then not.
The search for Eve is on! I've been looking for a year, by scanning all the news of threats, and last month I kept the list and posted a summary [9]. Yup, there's Eve, right up there in the first on on the list (obviously):
"Via eavesdropping, terror suspects nabbed" / Intelligence officials use cellphone signals to track Al Qaeda operatives, as number of mid-level arrests rises [10].
The attacker (in security terms) is listening to the victim (again, in security terms) using the cell phone network. That's over in Iraq, where they have armies and killing and destruction and things, so you'll pardon me if I present that as an example that has only hypothetical relevence to the Internet.
Which remains blissfully peaceful, and also apparently unlistened to, certainly in the last month. And that's been the pattern on the net, since whenever.
What can we conclude about MITMs? Here's a total stab in the dark: MITMs will be about 2 orders of magnitude less common than eavesdropping attacks (that's my guess, you make your own). So if there are 100 cases every month of eavesdropping - which might happen, and we'd not know about it - then there could be one MITM every month.
100 Eves a month might happen - the Internet's a big place [11]. I'd personally be suspicious of a claim of 1000 per month, that's too high to not be noticed [13].
So, I conclude that there might be about one Mallory per month, and we simply can't find him. Mallory gets away with his MITM.
Should we then protect against him? Sure, if you want to, but definitely optional, if it costs money. One case - hypothetical or otherwise - can never create enough cost and risk to cover society-wide costs. Remember, the Internet's a big place, and we only worry about things that happen to a lot of people.
The MITM is thus ruled out as a threat that simply must be protected against. Therefore, there is no foundation to the treatment of self-signed certificates as being too weak to promote!
That's the logic. Tricky, wasn't it? Eve is quite rare, and measurably so. Therefore Mallory is even rarer. Which means we don't need to pay any money to worry about him.
When doing scientific analysis of complex systems, especially for security purposes, we often have to make do with proxies (approximations) instead of the real measures. The same thing happens with economics; we can't easily test our designs against reality, we have to deploy and wait for the crooks to find us. This means we always have to keep our feet close to the ground, and take very careful steps, otherwise w
e start floating away on our assumptions.
Then, we end up with systems that are widely exploitable, and we just don't know how we got there. Or how to deal with it. (Well-read readers will recognise that phishing has that floating feeling of "just how did this happen?")
The logic above shows why a vote against self-signed certs is actually a vote *against* eavesdropping protection [14]. The fact that we got there by measuring eavesdropping and finding it low is interesting and perverse [15]. Nonetheless, the question remains whether we want to protect against eavesdropping: if so, then the answer is to deploy the self-signed cert.
In the meantime, keep your eye out for more reports of Eve. She will slip up one day, she's very natty, but not perfect.
[1] As an example, here is some work on a threat model for secure browsing, done for the Mozilla effort.
http://iang.org/ssl/browser_threat_model.html and http://iang.org/maps/
[2] I'm ignoring DOS and traffic analysis just for this argument. In a real security analysis, they should be better treated.
[3] There is another way: anonymous Diffie-Hellman (ADH), or ephemeral Diffie Hellman. Again, I'll ignore that, because it is deprecated in the RFC for TLS and also because most browser / server combos fail to implement it.
[4] All this cost falls on merchants, but they simply pass it on to consumers, so, yes, it costs us all.
[5] http://iang.org/ssl/how_effective.html or this month's embarrassment at http://www.securityspace.com/s_survey/sdata/200406/certca.html
gives 177k certs across 14 million servers. About 1%.
[6] There are many known bad reasons. I won't address those today.
[7] http://iang.org/ssl/mallory_wolf.html
[8] I've actually been scanning news reports for rumour of stolen credit cards - off the wire - since HTTPS started. But, no joy, not even amongst the many smaller merchants that don't use SSL. The credit card companies confirm that they have never ever seen it.
[9] There are some anecdotes. For the record, we generally rule out demos and techie boasts as threats.
[10] http://www.financialcryptography.com/mt/archives/000183.html
[11] By Faye Bowers June 02, 2004 http://www.csmonitor.com/2004/0602/p02s01-usmi.html
[12] By way of example, about 10,000 to 20,000 Linux servers get hacked every month, and people notice. Meanwhile about 200 BSD boxes get hacked a month, and that's so small that nobody notices. See the mi2g figures.
[13] Again, you pick your own numbers and justify your assumptions. It's called science.
[14] Voting against self-signed certs is also a vote against protecting against Mallory. For this even more perverse result, think of the stalled deployment, and check out the marketing angle:
[15] For the record, I believe that eavesdropping will increase dramatically in the future. But that's another story.
http://iang.org/ssl/dr_self_signed.html
I see a lot of threat articles come through from many sources. Each describes the latest threat to our net lives in an entertaining way - at least, as presented by the journalists who try and create a sense of excitement in their work.
We've seen them all before, in one variant or another. Still, reminders are good - these are the things that we have to balance when we build financial cryptography systems, and as there are so many and so varied a scale of threats, compromises are always needed. Here's the collected threats from the last month or so.
"Via eavesdropping, terror suspects nabbed" Intelligence officials use cellphone signals to track Al Qaeda operatives, as number of mid-level arrests rises.
By Faye Bowers June 02, 2004
http://www.csmonitor.com/2004/0602/p02s01-usmi.html
"NHTCU and Russian police foil online extortion racket" which was really clever, amounting to extortion for not DOSing the gambling sites.
http://www.finextra.com/fullstory.asp?id=12208
"Oops! Firm accidentally eBays customer database," when a disk drive sold on eBay carried data that it shouldn't. 7th June 2004, The Register.
"Venezuela: Fear for Sale" is an article about how government contractors are compiling databases on citizens in foreign countries. They just happen to have detailed files on countries in South America who are opposed to US interests.
GregPalast.com http://www.inthesetimes.com/site/main/article/fear_for_sale/
"Door locks know a lot more than you think" about how hotel door lock cards apparently don't know who you are, nor your credit cards, but they do (in concert with other systems) track entry to your hotel room.
June 12, 2004, Joe Sharkey NYT.
"Monaco banker faces re-imprisonment for not being French" is the story about the Brit who got caught doing special transfers for famous private clients of the bank. Whether he was acting for the client, or whether he was stealing, or whether the bank wanted a money laundering head is not clear and may never be clear.
Paul Murphy The Guardian Thursday June 17, 2004
"Iris scans at UK airports, says Home Office" is a story about testing iris scanners at borders, with no real hard indication that it will save anything, as yet.
By Lucy Sherriff 15th June 2004
"Google's Gmail: spook heaven?" argues that if Google can scan mail, then it puts in place the infrastructure for others to scan mail.
By Mark Rasch, SecurityFocus 15th June 2004
"How safe are the in-room safes in hotels?" says not safe enough for anything important, as it's too easy to break the pin code.
Roger Collis International Herald Tribune Friday, June 25, 2004
"Plan Would Pay Tax Whistleblowers" addresses how the IRS seeks to pay insiders to reveal on activity. A classic insider attack.
Mary Dalrymple AP.
"From a life of privilege to an English jail" reports on an all-American high school star who among other things fenced stolen account info from a ring of Russian thieves. Not clear how the "hackers" got the info, but they had access: "The Russians "were sitting there watching the accounts drain and recording everything so they knew how much money to expect at the end of the day," he said. "It was millions and m
illions of dollars." "
PAUL MEYER and MATT STILES / The Dallas Morning News June 27, 2004
"Email Spying and Attorney Client Privilege - US Government Reads All About It"
reports that the AG was secretly spying on the email of a lawyer for a Muslim mother of three. Emails made available from AOL, under warrant.
"Press card scam investigated" reports on one place to buy a fake press card.
30 June 2004 By: Jemima Kiss http://www.journalism.co.uk/news/story967.shtml
"The secrets your computer just can't keep safe" talks about malware - spying programs that are inserted into your PC: "On average every PC has 28 so-called spyware programs installed on it"
Mark Ward
http://news.bbc.co.uk/2/hi/technology/3845835.stm
"How [he who must not be named] Became a Dictator" talks about how a minority leader engineered a suspension of rights through a pogrom against bad people and took leadership of a country.
Jacob Hornberger
http://www.fff.org/freedom/fd0403a.asp
"Web sites allow gamblers to be their own bookmakers" talks about how offshore gambling sites (primarily Britain and Australia) are being financed by US investors. But, they don't take US customers.
Matt Richtel NYT July 7, 2004
http://www.iht.com/articles/528222.html
"Globalization, deregulation allow stock fraud industry to thrive" and it's Boiler Room all over again: this time the operation phones from one country, sells to an investor (read: victim) in another country for some Nasdaq loser stock in the US.
http://www.jewishworldreview.com/0604/stock_fraud.asp
"Text Messages May Turn Up in Bryant Case" about an alleged case of rape in the US, where the accuser exchanged cell phone text messages shortly after the incident. In this case, people are suprised that the telco can ... recover the messages!
JON SARCHE, Jun 07, 2004 AP
"Laptops containing sensitive financial details and all manner of corporate secrets can be snapped up at auctions for a pittance, a security firm revealed Wednesday."
(Reuters) By Bernhard Warner, European Internet Correspondent
http://www.reuters.com/newsArticle.jhtml?type=oddlyEnoughNews&storyID=5381490
"Smart-phone worm has a hang-up" reports about attempts to write a worm for cellular phones.
By Robert Lemos CNET News.com June 15, 2004
http://zdnet.com.com/2100-1105_2-5234953.html?tag=sas.email
"The Mystery of the Voynich Manuscript" New analysis of a famously cryptic medieval document suggests that it contains nothing but gibberish
Scientific American: June 21, 2004 By Gordon Rugg
http://www.sciam.com/print_version.cfm?articleID=0000E3AA-70E1-10CF-AD1983414B7F0000
"Spyware Sneaking into the Enterprise" ... well where else would it go?
By Roy Mark June 30, 2004
http://www.internetnews.com/security/article.php/3375661
"Woman allegedly stole law firm's identity" is another case of an insider shifting things around to steal money.
June 28, 2004, AP
http://www.cnn.com/2004/US/Northeast/06/28/corporate.id.theft.ap/index.html
"iPods are the latest security risk" because they can carry data out of corporates? Don't forget cameras, pocket drives, USB fobs, .....
John Leyden 7th July 2004 The Register
http://www.theregister.com/2004/07/07/ipod_security_risks/
Over in the US of A, the mutual funds scandal continues to rumble on. In this case, a new article "Regulators overstep with mutual fund trustees" brings out one of the conundrums in the structure that is in place. In short, the Bank of America, as part of its $375 million settlement with Elliot Spitzer's office, also decided to sack the Trustees of its funds.
Now people are wondering how it is possible for a manager to sack the Trustee. As the trade group wrote:
''By accepting the proposition that Bank of America has the capacity to settle charges by causing the replacement of mutual fund trustees, the Commission would be suggesting that Bank of America, not the trustees, controls the funds, ..."
Well, it's a good point, isn't it! Reading the article in full and considering every action and event, it is clear that Bank of America, the manager, and the regulators, New York Attorney General and the SEC, have all quite happily ignored the Trustees. Until it is time to sack them, of course.
Trusts are nominally owned by their Trustees, and the Trustee is in charge of all management and governance decisions. He can't be sacked by the manager, but in the Trust documents, there is often provision for a Trust Protector. This person can generally sack the Trustee, and do all sorts of other things, as laid out in the Trust document. Or, at the least, there will be a way to sort out these issues, if only because Trustees are often old, and check out of their own accord.
So, skipping that storm in a teacup, what was the substance of the Trustees' claim to control the management and to guard the funds? Here it is:
".... In a meeting in May 2002, [the Trustees] voted to take action against short-term traders, called market timers. These traders buy and sell shares of foreign funds overnight, to lock in quick profits at the expense of other investors. The board instituted a 2 percent penalty fee for anyone holding shares less than 90 days, in order to dilute any profits from timing.
"But at that same meeting, according to Spitzer's allegations, Nations Fund managers persuaded the trustees to give one elite client a free ride. According to the minutes of the meeting reviewed by Spitzer's investigators, Bank of America wanted to let a hedge fund, Canary Capital Partners, market-time at will, without paying the fees. The eight trustees present at the meeting (two missed the session) agreed to the arrangement, Spitzer said.
Whoops-a-daisy! The Trustees gave a free pass to Canary Capital, which was the market timer that started the whole schamozzle. So the more likely future for the Trustees is that they have to face criminal or civil proceedings for all that money that they let slip by. It may be that being sacked when they can't be sacked is the best thing that ever happened to them.
What I don't understand about this part is why people expect these appointments to actually work. Of course, if you put a Trustee in place, he might honestly do his job to look after the assets. But, more than likely, he won't. Why should he?
The only reason he would do the job properly is if he was monitored. Nobody was monitoring these guys, and the Managers were allegedly conspiring with them to let the fraud continue. Well, of course! There was too much money involved not to try and steal it.
Which is why when I designed the 5PM I started out with the principle that nobody does the job unless monitored. And nobody monitors like the owner (forget auditors, they're just more highly paid versions of the Trustees). So the most important person in the 5PM is the 5th party - the user. Or, the owner, as they like to call themselves. And the most important part of the structure is not who is doing what, but how they tell the user what they are doing.
And monitor they do - when given a chance, and when given some explanation of how they are the only ones really standing between their assets and the crooks that are pretending to guard them.
Addendum 2004.09.06 SEC scrutinizes trustees of mutual funds
Koblitz and Menezes have posted a new paper Another Look at "Provable Security". Serious readers in cryptography and philosophy of science (you know who you are) should grab a copy, but for the rest of us, turn to Eric Rescorla's shorter review.
In summary of his summary, the proofs are unproven, their assumptions are unrealistic, and a lot of the attacks that are contrived are also unrealistic. The result? Designers and programmers bypass all that and just code up what they can.
I especially like the "Fundamental Tenet of Cryptography" [Kaufman, Perlman, and Speciner]
"If lots of smart people have failed to solve a problem, then it probably won't be solved (soon).."
which brings to mind Adi Shamir's 1st law of cryptology:
"There are no secure systems..."
Come to think of it, Adi's other comments on that link bear much re-reading! These signs of revisionism from the academic side of cryptology are very welcome. They make utter sense to us higher layer geeks who have to build systems based on these weird and wonderful psuedo mathematical properties. It's definitely the case that for 99% of the geeks I've ever met, the notion that some claim or other is proven gets glossed over very quickly.
Not that the coders and other users of cryptography are so much better; we are currently going through our own era of revisionism. No-risk cryptosystems such as SSL and certificate authority-signed certs are being dissected in all their embarrassing real world weakness, you can't give away a PKI system these days, and all the while, opportunistic cryptography systems such as SSH and PGP continue to plod along, doing the work in a no-fuss but secure fashion.
Bringing the hubrists to task is a noble one, and only made more noble by a future generation's challenge to our own hubris.
The OpenPGP project has a long and interesting history. Here's some links on the worthwhile effort to document the rise and rise of this great project.
Fabian Rodriguez
PGP Corp
Wikipedia
It seems one story has been forgotten, including my own small contribution - the great saga of the PGP 5.0 source code book. The scanning was finished by a team that I coordinated at HIP97. We completed the task, but most of the work had been done by an international team which was coordinated out of Norway by Ståle Schumacher. Not to mention the work done by the original publishers, PGP Inc themselves, and Lucky Green's carriage of the books past the unhappy border guards tasked to protect the world from American cryptography.
Once the book was in the hands of the infidel foreigners, the task was to scan and OCR each page, and construct the source code from the results. To us at HIP was left the last 1% of the OCRs. As it was all the tail-end stuff, the 1% was the hardest - the ones with errors that defied the simpl scanning, OCRing and checksumming process. With about 20 volunteers (of the 3000 or so people at HIP), we set to with a vengeance. Proofreading and error correction was the order of the day.
We must have been going for about 24 hours on the project, and what was left was a bunch of pages that just defied checksums. I wrote a bunch of scripts that did things like insert tabs in where they could be hidden amongst spaces, and mass crunched through errant pages. The final page fell when the Scandanavians read out to us over the phone one particular line - where it should have had a vertical bar "|", it had a digit one "1". An easy mistake to make but it left us cussing and swearing.
It was 3 in the morning when we finally sent out the last fixes, and 2 hours later the Scandanavians pushed out the source code world wide. By this time, the party had broken, there were snoring dead bodies everywhere, and nothing intelligent was being done - a lot of the final work was completed surrounded by one of those head banging disco scenes the Dutch are infamous for.
I thought I'd written about the great adventure somewhere, but I couldn't find any evidence of that. For those interested in more HIP colour, read these rants:
It's cool to be iang@hip97.nl
Hipped on PGP
And bear in mind that we may be due for another in the series. Anybody know anything of plans for 2005? Also, see this additional story of PGP 5.5 - where our OCR experience was put to much good use with new tools and formats, and enabled Teun Nijssen and Stale to do the whole lot in a tenth of the time, by themselves.
Over on PGP Corp's web site, they've inadvertantly revealed a new way to futz with secure browsing [0].
Click on http://www.pgp.com/ and you will see an SSL-protected page with that cute little padlock next to domain name. And they managed that over HTTP, as well! (This may not be seen in IE which doesn't load the padlock unless you add it to favourites, or some such. So you need Firefox or Konqueror or Opera, it seems.)
Whoops! That padlock is in the wrong place, but who's going to notice? It looks pretty bona fide to me, and you know, for half the browsers I use, I often can't find the darn thing anyway. This is so good, I just had to add one to my SSL page. I feel so much safer now, and it's cheaper than the ones that those snake oil vendors sell :-)
What does this mean? It's a bit of a laugh, is all, maybe. But it could fool some users, and as Mozilla Foundation recently stated, the goal is to protect those that don't know how to protect themselves. Us techies may laugh, but we'll be laughing on the other side when some phisher tricks users with the new, improved favicon-SSL.
It all puts more pressure on the oh-so-long overdue project to bring the "secure" back into "secure browsing." Microsoft have befuddled the already next-to-invisible security model even further with their favicon invention, and getting it back under control should really be a priority.
Putting the CA logo on the chrome now seems inspired - clearly the padlock is useless. See countless rants [1] listing the 4 steps needed and also a new draft paper from Amir Herzberg and Ahmad Gbara [2] exploring the use of logos on the chrome.
[0] An earlier version of this blog credited PGP Corp with this discovery. I had assumed that they had realised the security significance of the favicon with respect to the browser security model. This appears incorrect - they simply put the logo from their corporate documents there.
[1] SSL considered harmful
http://iang.org/ssl/
[2] Protecting (even) Naïve Web Users, or: Preventing Spoofing and Establishing Credentials of Web Sites
http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing.htm
I must have written a hundred times that privacy enhancing payments are only private to a degree. From eCash to Ricardo to e-gold to PayPal to greenbacks to ... well, all of them can be tracked somewhat. They help protect honest people from bad trackers, but they don't protect real serious criminals from serious sustained levels of tracking.
In a sort of Darwin award for criminals, here's the story of a major heist that went wrong, because the crooks believed they could use a privacy-based payment system to get their ill-gotten gains. Oh well, no great loss to society here.
http://www.crime-research.org/news/13.07.2004/485/
(one section quoted from the interview)
What kinds of Internet crimes are the most dangerous at the moment? Can you explain them? What can you say about blackmail?Spread of computer viruses, plastic card frauds, theft of money from bank accounts, theft of computer information and violation of operation rules of computer systems are among the most dangerous offences on the Internet. In order to get one million of UAH (about $185-190 thousand) certain people phoned director of Odessa Airport, Ukraine and informed that they had placed an explosive device on board of a plane flying for Vienna and they also had blown up a bomb in the building opposite to the airport building to confirm their serious intentions.
The Security Service of Ukraine and the Air Security Office were informed of the accident right away. Criminals put detailed instructions on fulfillment of their requirements on the Internet. The main demand was one million of UAH. Criminals planned to use Privatbank's "Privat-24" Internet payment system to get the money. The useful feature for criminals in that case was that this system allowed anonymous creation and control over an account knowing only login and password. Therefore they used the Internet to secure anonymous and remote distribution of their threats and receipt of money.
Besides typical operational measures, there was a need to operationally establish data on technical information in computer networks as criminals used the Internet at all stages of their criminal offence. The Security Service decided to engage experts of a unit on fighting crimes in the sphere of high technologies at the Ministry of Internal Affairs. They were committed to establish senders of threat e-mails and the initiators of bank payments.
The response of ISP and the information they provided helped to determine phone numbers and addresses related to criminals, and also allowed to get firm evidences stored in log data bases of ISP and Privatbank.
Logs allowed to find out IP addresses of computers, e-mails and phones that helped to review concrete computers at the scenes.
The chronicle of events proves that prompt and qualified aid, provided by the unit on fighting crimes in the sphere of high technologies at the Ministry of Internal Affairs in January 2002, to officers of departments fighting terrorist and protecting state organization at Security Service allowed to reveal a criminal group, to prevent their criminal activity, and thus to give due to cyber terrorists.
Governance is about the appropriate aligning of incentives. When we build a governance layer, what we are essentially doing is cleaning up after the technocrats have done their best. In the case of FC, the technocrats are cryptographers, software engineers, rights people, and accountants.
Of course, because we all talk to each other, and we're all multidisciplinary, there is no throw-it-over-the-wall architecture in FC, now, is there? Governance people widely discuss what they can and can't do, and in discussion with the above ubergeeks, and driven by the reqiurements of layers 6, 7, we eventually come up with a design that is cohesive.
Here's an important idea that we are pushing to take the phishing out of secure browsing. Breached ot the tune of about a billion dollars, the out of date security model for browsing can actually be fixed up quite easily. But to do so we have to think broadly - and we have to align incentives properly. Here's how branding helps where crypto and protocols fail.
http://iang.org/ssl/VeriCola.html
(oh, sorry, yes, this is another rant in the infamous "SSL considered harmful" series. Enjoy!)
Will K has alerted me to this: Over in the Jabber community, the long awaited arisal of opportunistic, ad hoc cryptography has spawned a really simple protocol to use OpenPGP messages over chat. It's so simple, you can see everything you want in this piece of XML:
<message to='reatmon@jabber.org/jarl' from='pgmillard@jabber.org/wj_dev2'>
<body>This message is encrypted.</body>
<x xmlns='jabber:x:encrypted'>
qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
[snip]
Oin0vDOhW7aC
=CvnG</x>
</message>
Well, life doesn't get much simpler. So far it is lacking a key exchange format, but hey, here's one I knocked up:
<message to='reatmon@jabber.org/jarl' from='pgmillard@jabber.org/wj_dev2'>
<body>This message includes sender's public key.</body>
<x xmlns='jabber:x:publickey'>
mQGiBDjddDERBADBnXl2kf4gLFNSLs4BRt/tt/ilv+wnC5HFgSpKyUk/ja2uKJ2C
[snip]
E7U1RhQBQTI=
=ze8A</x>
</message>
Yeah gods, it is so simple, it's embarrassing. Here's the wishlist for a portable, popular IM protocol for secure chat:
Hey presto, a secure chat. Yeah, sure, those nasty ugly bogeymen, the MITMs, could sneak in and do something nasty, but when that happens (don't hold your breath), we can worry about that (hint: web of trust is easy to add...).
One thing wasn't clear - the JEP document above indicates that Presence messages were signed. Anybody got a clue as to why anyone would sign a presence message?
Presented yesterday at the IEEE's first Workshop on Electronic Contracting, a new paper entitled "The Ricardian Contract" covers the background and essential structure of Systemics' innovation in digital contracts. It is with much sadness that I am writing this blog instead of presenting, but also with much gladness that Mark Miller, of E and capabilities fame, was able to step in at only a few hours notice.
That which I invented (with help from Gary Howland, my co-architect of the Ricardo system for secure assets transfer) was a fairly mundane document, digitised mundanely, and wrapped in some equally mundane crypto. If anything, it's a wonderful example of how to use very basic crypto and software tools in a very basic fashion to achieve something much bigger than its parts.
In fact, we thought it so basic that we ignored it, thinking that people will just copy it. But, no-one else did, so nearly a decade after the fact, I've finally admitted defeat and gone back to documenting why the concept was so important.
The Ricardian Contract worked to the extent that when people got it, they got it big. In a religious sense, which meant that its audience was those who'd already issued, and intiutively felt the need. Hasan coined the phrase that "the contract is the keystone of issuance," and now Mark points out that a major element of the innovation was in the bringing together of the requirements from the real business across to the tech.
They are both right. Much stuff didn't make it into the paper - it had hit 20 pages by the time I was told I was allowed 8. Slashing mercilessly reduced it, but I had to drop the requirements section, something I now regret.
Mark's comment on business requirements matches the central message of FC7 - that financial cryptography is a cross-discipline game. Hide yourself in your small box, at your peril. But, no person can appreciate all the apposite components within FC7, so we are forced to build powerful, cross-discipline tools that ease that burden. The Ricardian Contract is one such - a tool for bringing the technical world and the legal world together in issuance of robust financial value.
Will Kamishlian has written an essay on the question I posed on the Internet security community last week: "why is the community being ignored?" It's a good essay, definitely worth reading for those looking for the "big" perspective on the Internet. Especially great is the tie-in to previous innovative booms and consequent failures in quality. Does it answer the question? You be the judge!
Here's the problem -- of personal information vulnerability as I see it from the lowest to the highest level.
1. User Level
The problem of phishing stems from the rendering of HTML from within an email client. I started to receive phish email long before I knew about the problem. I ignored these email messages because the URL in the email did not match that of my bank, etc. This would not be the case were I using a client that rendered messages in HTML.
2. Software Provider Level
Users want their Internet experience to be seamless and user-friendly. Therefore, software providers are going to continue to add new features and functionality to their email clients, browsers, etc. in a quest to provide an *easy* experience. Therefore, problem #1 is not going away. In fact, it will get worse. As new features are added, so too will new vulnerabilities. Software providers will -- as they have in the past -- patch these vulnerabilities piecemeal.
3. Industry Level
At the industry level, a widespread disagreement will remain about how to pro-actively protect the user. Individual software providers will resist any intervention that may potentially limit the features that they can provide to users. Therefore, problem # 2 is not going away.
At the moment, the problem could be solved at the industry level. As the article notes, there is a dearth of neither security experts nor advice. The professionals exist. What is needed is a consortium that can agree on an extremely basic security model from which all security aspects can be devolved -- from models to specifications. The model must be so basic that no provider can argue with its validity. Extensions to this basic model would provide lower-level models from which specifications and certifications could be devolved.
4. Societal Level
Users want more features, and providers want to satisfy users; however, in doing so, users are getting harmed. In the long term, there are four possible scenarios for this state of affairs:
* Over time, users will accept the harm and adopt the technology
* Industry will adopt universal technology to prevent harm
* Industry will create a third party to ensure safe guards
* Government will step in to introduce safe guards
By long term, I refer to a state of maturation for electronic commerce over the Internet.
Ian's article caught my eye because I am a student of history, and have been tracking the Internet boom against other booms in the past, such as that of the growth of the railroad industry, from its inception to its maturity.
The growth of the Internet mirrors the birth, boom and maturity of several industries. These come quickly to mind:
* Railroad
* Electrical
* Airline
* Automotive
In each of these industries, consumers initially accepted a relatively high risk of potential harm as a cost of doing business. As each of these industries matured, consumer pressure produced improvements in consumer safety. Note that the author refers to these industries as they grew in the United States.
Regarding the current state of affairs for electronic commerce, we can draw lessons from the means by which each of the above industries responded to the pressures for consumer safety. Each of the above responded in a unique manner to societal pressures for consumer safety.
Railroad Industry
Major railroad disasters caught the public attention (much as airline disasters do now) during the 1860's and 1870's. Over time, industry players universally adopted safety technology -- primarily the telegraph and air brakes -- that did much to improve consumer safety. The final piece of railroad consumer safety was put in place when the industry convened to adopt standard time -- an institution that lives with us today. The universal adoption of new technology and of standard time was possible because by the 1870's there were a few major players, which could impose their will on the entire industry, and which could foresee that consumer safety improvements would lead to increased revenues.
Electrical Industry
The electrical industry responded in a manner much different from that of the railroad industry. Unlike the railroad industry, there were no headlines of failures leading to the deaths of tens of people at a time. On the other hand, adoption of electricity in the home was slowed by the fact that electricity represented a very new and unknown (to the consumer) technology, so that electrical accidents -- in the industry's infancy -- were accorded the horror of the unknown.
During the infancy of the electrical infancy, major players realized that they could achieve widespread adoption by ensuring consumer safety. At the same time, insurance companies were often bearing the cost for electrical catastrophes. The insurance companies, in conjunction with the electrical industry, created the Underwriters' Laboratory -- another institution that lives with us today. Thus, a third party was created with the single goal of providing consumer safety.
Airline Industry
Consumer safety in the airline industry progressed in a way dissimilar to both of the above. During the 1930's, the public was horrified by news accounts of airline disasters (much as the public had been horrified by train disasters decades earlier). The difference between the 1930's and the 1870's is that by the 1930's, consumers had adopted the notion that the government could and should enact legislation to ensure consumer safety. As a result, societal pressures built to the point that politicians quickly stepped in to provide consumer safety, and the forerunner to the Federal Aviation Administration (FAA) was formed. The FAA now influences airline passenger safety on a worldwide level.
Automotive Industry
The automotive industry comes last on this list because it was forced to adopt consumer safety measures long after this industry had matured. The reasons for this are that unlike the railroad and airline industries, catastrophes did not make front page news, and unlike the electrical industry, the technology did not represent the unknown -- automobiles were an advancement on the horse and buggy. Until the 1960's, consumers accepted a relatively low level of safety because safety was viewed as a consumer issue.
Safety in the automotive industry changed in the 1960's, due in large part to the efforts of Ralph Nader. Nader used statistics to demonstrate the lack of concern on the part of the automotive industry. While individual car crashes did not make front page news, Nader's statistics of thousands of preventable deaths did make news. Auto makers did not initially respond to the societal pressure that Nader created, and as a result, the government stepped in. The Department of Transportation began to promulgate automotive safety regulation.
During the 1970's class action lawsuits brought a new type of pressure on the automotive industry. Huge payouts in cases, such as the Ford Pinto suit, brought us a new breed of lawyer adept at winning large sums from juries sympathetic to descriptions of death and bodily harm caused by negligence on the part of manufacturers. I do not have a strong opinion on what the net effect that these lawsuits have had on consumer safety; however, I suspect that these lawsuits have increased costs to the consumer in greater measure than they have improved overall consumer safety. Class action lawsuits are won when the defendent is found *provably* negligent. The lesson to the industry is to not be caught *provably* negligent.
The Electronic Commerce Industry
Where does all of this history leave us? We can find relevant historical conditions from each of these industries, and from these conditions, we can plan for the future of electronic commerce. From the foregoing, we can accept that consumers expect the government to step in quickly whenever an industry is viewed as negligent with regard to consumer safety (as in the airline and automotive industries).
The infancy of the electronic commerce industry is similar to that of the electrical industry in that the Internet has an aspect of the unknown, although unlike the electrical industry, failures and accidents in the electronic commerce industry do not lead to death or injury. Nevertheless, we can expect that consumer adoption of electronic commerce will be slowed until consumers are reassured that their safety is protected by a technology they do not understand.
Unlike the railroad and airline industries, failures in electronic commerce do not usually make front page news. On the other hand, politicians and interest groups are beginning to weigh in with statistics -- at a governmental level. We can expect that there will be pressure on the government to regulate this industry. Witness the quick passage of legislation designed to prevent spam.
Like the railroad industry, there are a few major players (that provide electronic commerce software) that could move to self-regulate the entire industry. To simplify the current state of affairs, Microsoft will not adhere to standards that it either does not control or that may limit its ability to offer new features. Other players are loath to adhere to standards that Microsoft controls. Therefore, we cannot expect that the major players in the software industry will move to self-regulate *unless*, as was the case with the railroad industry, the major players come to believe that cooperation would lead to higher revenues for all participants.
Unlike the railroad industry, it is unlikely that a massive improvement in consumer safety could result from universal adoption of a few key pieces of technology. Electronic commerce, like the airline industry, has too many points of potential failure for a simple widespread solution. Therefore, we cannot expect technology to come to the rescue.
The interesting thing about the electrical industry is that it was insurers who moved to form the UL because insurers paid the costs of electrical catastrophes. At the moment, the costs of electronic commerce failures are being borne by consumers and a wide variety of providers (banks, retailers, etc.). The lesson here an industry, bearing the costs of failure in another industry, can act in concert to compel improvements in consumer safety.
Coming lastly to the automotive industry, we can see a parallel in that consumer safety in electronic commerce is much viewed as a cost of doing business. Most consumers recognize that risks exist, however unknowable, yet this is accepted as the cost of conducting business online. Electronic commerce failures do not make front page news; however, we can expect that consumer interest groups and politicians will be making headlines with statistics of people harmed by electronic commerce. Perhaps, the electronic commerce industry will come under fire from lawyers who can easily identify large groups of consumers *harmed* by rich software development companies.
Looking Forward
From the foregoing, we can see that consumer adoption of electronic commerce will be hampered until consumers perceive that a higher level of safety is provided. We can expect no silver bullet in terms of technology. We can expect -- absent credible efforts by the industry to self-regulate -- that politicians will come under increasing pressure to regulate electronic commerce. The software industry powers will work to thwart that pressure; however, they may be unsuccessful -- especially when one considers the power wielded by the big three automakers during the 1960's.
The question is, will the industry move to self-regulate before government moves in? In my opinion, the best hope for self-regulation would be in parallel industries -- especially banking. I believe it is unlikely that software providers will commonly agree that improved consumer safety would lead to revenue growth for all. On the other hand industries, such as banking, are bearing an increasing share of costs for failures in electronic commerce, and those that bear the costs are likely to move in concert -- as did insurers by forming the UL. If pressure were brought to bear, I think that these adjacent industries might bring the best results in terms of self-regulation.
So, we are left rolling our own, until either government or adjacent industries step in to create standards for consumer safety regarding electronic commerce. Our only hope for preventing onerous government regulation lies in convincing these adjacent industries that by acting in concert, they can reduce their costs by improving consumer safety on the Internet.
Goldmoney's newly released bar count shows, as predicted, that it has now overtaken e-gold as the largest issuer of gold currency. Last quarter growth was 42%, and as e-gold have been flat or declining for many years now, goldmoney's future leadership is a near certainty. Congratulations!
However, this only applies to grams of gold - arguably the most important measure but not the full story. If e-gold's silver, platinum and palladium is taken into account, e-gold is still slightly larger (calculate on Examiner). Swapping white metals into gold (via USD) gives e-gold a total basket of 1,813,748.30, slightly larger than goldmoney's 1,783,552.182gg.
Until the next 3 bars goes in, that is. Unfortunately, as goldmoney only releases its figures every quarter, we won't know for another three months, and until then, goldmoney can't report that they are the biggest.
Damn those auditors, curse them! If only there was a solution to this....
The 30 Jun 2004 quarterly stats for GoldMoney have been posted today at
http://goldmoney.com/en/report.html
There are now 1,783,552.182gg in circulation, representing 142 LBMA good delivery bars.
http://goldmoney.com/en/bar-count.html
That's an increase of 42 bars from the 100 bars in GoldMoney as of 31 Mar 04, or 42% growth for the quarter.
Importantly, the total grams of gold reported by VIA MAT (gold in the vault) and total goldgrams reported by Dimension Data (digital gold currency in the database) are identical, again confirming that GoldMoney is 100% gold, always.
Regards
James
subscribe: send blank email to dgcchat-join@lists.goldmoney.com
unsubscribe: send blank email to dgcchat-leave@lists.goldmoney.com
digest: send an email to dgcchat-request@lists.goldmoney.com
with "set yourname@yourdomain.com digest=on" in the message body
This article announces the arrival of real time Java. Being the premier big systems language, the niggles and flaws in Java have always been writ large - the lack of access to the OS is my particular bug bear due to the dramatic expense of dealing with it in real world systems that need to be reliable. Another big problem in performance systems is getting the garbage collector under control. There's only desultory efforts for that, things like the WeakReferences allow a programmer to code defensively, but they don't give control.
Real time is another area where Java just won't cut it, and not only because of the GC issue. In my experience, real time is hard. It requires a top-to-bottom philosophy, and most after-the-fact reworks of systems end up being near-real-time but not the real McCoy. Still, the features that get added always find a use somewhere, so even near-real-time is useful for expanding the solution set.
An interesting article about how a manager lost his job when an instant messaging virus sent his entire recorded conversations to his buddy list. This brings out the ticking time bomb that is the archive of all ones conversations. I've always treated chat and IM as just that - idle chat, and don't record those comments please!
Yet I seem to be a minority - I know lots of people who record their every message. And they've got good reasons, which makes me feel even worse. This permanent archiving kind of takes the spontaneity out of it, and it certainly makes it un-chat-like. How does one feel about teasing around with ones partner, as one does, when the threat of a divorce case in 4 years time brings out how cruel you were? Or, idle musings on the safety features of a product, in an open whiteboard fashion, gets dragged into liability suits?
I don't think there is an easy answer to this dilemma. The medium of chat is as it is, and no amount of wishing for that personal, forgiving experience can make the chat archiving devil vanish.
But there are some things that could be done. Here's one idea - perhaps a chat client could present a policy button with a buddy connection. For example, there might be different buttons for partner/confidential, business/confidential, negotiation/confidential and client/attorney privilege.
The first might extend husband-wife protection, with an intent of making the chat not useable against each party in a court of law. The second might create an internally confidential status, so that any forwarding could be warned against. The third would extend confidentiality to the documents such that they couldn't be used in a dispute (this is a trap for young players that I fell into). And the fourth could make the discussions inaccessible to aggressive plaintiffs. (And, we'd of course need another button for "write your own." Not that many people would of course.)
To support these buttons, there would need to be a textual understanding. A contract, lawyers would call it. If we both selected the same contract, then we'd agreed up front to its provisions. In legal terms, this gives us some protection - the courts generally agree with what you said up front.
There are limits of course - for example contract protection gets weaker if criminal proceedings are being undertaken. In which case, if you murder your spouse, you shouldn't expect the marital confidentiality button to save you. Also, even if the words can't be presented in court, there might be a lot of value in just reading them.
But it could bring back enough peace of mind to enable IM to get chatty again. What say you? Select your chat confidence policy and IM me with comments....
Curious how history turns out. Back in 1990 or so, David Chaum launched a revolution with his invention of untraceable digital cash tokens. For much of the 90s, there was a pervasive expectation that electronic money would be untraceable. Yet, it didn't turn out that way. Almost all systems were traceable. Even DigiCash's offerings were only loosely private. And now, a fairly tough analysis on the Bagdad Greenbacks mini-scandal has this engaging quote:
A former consultant to the Senate Banking Committee opined after the Kelly hearings: "It is a monumental act of stupidity for Congress and the Treasury to allow the Fed to ship large amounts of physical currency around the world and then act shocked when the customers turn out to be drug dealers and money launderers. The U.S. government should promote the electronic use of dollars as a means of exchange, but not the use of physical currency [1]."
Electronic Money is Traceable Money. So we rely on the Issuer to be careful with the data, by one means or another. In order to evaluate the privacy of the data, evaluate the policies and weaknesses of the Issuer. You are going to have to do that anyway, to evaluate the safety of the Issuer, and it adds maybe 5% to the workload to check out their privacy practices.
I am reminded of my informal research into the heavy narcotics world. Being dragged to ever-frequent social gatherings in the "tolerant and open" Amsterdam party scene, I found myself a fish out of water. So I constructed a little plan to gain some benefit from the experiences on offer: I mixed financial cryptography and the available experience in movement of product, and verbally trialled the new untraceable digital cash products on the street dealers.
The results were a surprise, even to me. Your average hard-core dealer would not use a digital cash product that was touted as being a privacy product. Reason? Because if it was touted as a privacy money, then that was probably a lie.
That is, if it is claimed to be untraceable, or anonymous, it probably isn't. Whereas, if there is no such claim, at least you can examine the system and draw what benefits there are plainly on view.
The fears of these dealers seemed to me to be overly paranoic at the time (and recall, the mid 90s was a time when everyone was paranoic!). But they have been confirmed empirically. At least two high profile money systems that claimed to be private were lying (these were the cases I *know* about). Literally, they were misleading the public and their own people by keeping secret their transactional tracing capabilities.
Why was this? In both cases, the original aim was safety of the float. And, this is a good reason - hard analysis of an untraceable money system such as blinded token money (sometimes wrongly called anonymous money) leads one to the overwhelming conclusion that it will fall to the bank robbery problem. But, in the 90s, everyone believed that these money systems should be private, so that was what they claimed.
Now, I guess, if people in Congress believe that electronic money is traceable money, then we can get over the myth of untraceable digital cash and get back to serious architecture. It was a nice myth while it lasted, but ultimately, a huge distraction, and a waste of the resource of countless programmers who believed it could be done.
[1] Is Alan Greenspan a Money Launderer?
http://www.insightmag.com/news/2004/06/11/National/Investigative.Reportis.Alan.Greenspan.A.Money.Launderer-690804.shtml