SET Realities
Dear DDJ,
Having been involved in the first year or so of creation of the SET credit card protocol, I enjoyed the article "The SET Standard and E-Commerce" by William Stallings (DDJ, November 2000). The article gives a nice and readable overview of the protocol.
However, I'm afraid the closing section, "SET in Practice" is a bit lacking and overly optimistic. In reality, SET adoption has been very slow and limited — and it seems that chances of SET being widely deployed, as is, are rather slim. There are multiple reasons for this. I think the most important is that SET requires implementation by all parties — cardholder, merchant, and their respective banks. There isn't a migration path, whereby a party would receive some benefit by implementing before others — on the contrary.
As a result, there recently have been new efforts to provide secure credit card solutions, which will have a reasonable, gradual adoption path. For example, by combining credit-card security with micropayments (as IBM does), by providing simple, if limited, solutions based on complementing SSL based transactions with direct authorization from the cardholder to the issuing bank, and other approaches. A more in-depth overview is available in http://www .hrl.il.ibm .com/mpay/course/ course.html.
Amir Herzberg
CueCat
Dear DDJ,
While we're as happy as the next hacker to play with the CueCat (see "Editorial," by Jonathan Erickson, DDJ, November 2000), as an eight-year old barcode software company, my hit on Digital Convergence and the CueCat is a little different than the prevailing SlashDot/Open Source/Linux crowd perspective. I did take the time to elaborate my views recently: see http://www.azalea.com/qtools/ AzaleaQToolsUpdate.pdf.
We want lots of CueCats out in the real world — that is the nonwarehouse, shipping industry, overnight delivery world. Yes, we want barcode scanners in homes across the land. Then and only then can the real games begin. AzaleaQTools will evolve into something constructive, not attacking Digital Convergence. I don't care if their business plan is flawed or if ultimately they succeed or fail. All I know is they are well funded enough to distribute millions of "free and low-cost bar code scanners" before their 15 minutes of fame is up.
Jerry Whiting
Dear DDJ,
I got a CueCat as part of my Wired magazine subscription, and I am of the opinion that Digital Convergence will be bankrupt shortly, due to its general incompetence, and lack of support from the advertising community.
In the first place, Digital Convergence was too cheap in manufacturing the CueCat. It failed to incorporate the necessary adaptors to achieve effective hardware compatibility with AT keyboards or laptops, the way a cheap mouse would. The odds are very much against many prospective users trucking down to Radio Shack to buy the things, as recommended in the brochure, so, right off the top, the user base is severely limited. Furthermore, the user base is limited in particular ways, with an emphasis on the kind of cheap "family computer" sold by Radio Shack, than on the kind of "heavy iron" favored by people who use computers in their work, and who are most demographically desirable to advertisers. The failure to provide a Linux driver is part of a broader pattern.
Parenthetically, I remember that some years ago, in 1994, I considered buying a Radio Shack computer, but had to turn them down because their computers did not support 5-1/4 inch floppies, which of course had been the generally prevailing standard a couple of years earlier. In short, we're talking about a group of companies who "just don't get it."
Looking at the last couple of issues of Wired, I find that large numbers of advertisers have declined to play ball with Digital Convergence at all. I don't suppose an advertiser can get a barcode number for free, or for a nominal registration charge? Furthermore, I noted that practically all the advertisers who had barcodes also had other contact information, typically URLs and voice phone numbers. They were hedging their bets, and are quite willing to concede anonymity sooner than be bypassed. About the only notable exception to this policy were the makers of the Altoids candies. I don't think Digital Convergence can survive as an appendage to Altoids, even assuming that Altoids themselves survive.
Altoids are a rather strange product, if you think about it. They are candies marketed as if they were whiskey. That has been tried. About 30 years ago, there was a beverage known as "bitter lemon." It failed. The whole point of whiskey is to get looped. In short, how wonderful that all these people found each other!
Andrew D. Todd
Dear DDJ,
I was reflecting on Jonathan Erickson's "Editorial" (DDJ, November 2000), especially the phrase "customers who still believe in concepts such as ownership and private property," and I identified a recent trend among capitalists — regarding our privacy and our right to it.
These new wireless technologies are so popular among venture capitalists lately because they were sold to them largely as a means to keep track of users' habits and profiles — and target them precisely. Also considering the future of ".Net" and the new trends in software licensing (ASPs, downloaded Java style, CORBA, and "adware"), it only makes it clearer that we are bound to be almost naked in the eyes of these companies when it comes to our privacy. The open-source community needs to enforce and educate others on cryptography, the importance of privacy, and what is done with the data mined from the casual computer user — and suggest solutions that are practical.
Jose Melo de Assis Fonseca
C++ Namespaces
Dear DDJ,
I am a big fan of C++ and I feel that Stroustrup and the Standards committee do a fantastic job with the highly challenging job they have of improving the language standard while keeping compatibility with old C++ code. In some cases they have failed, but most C++ code will still compile on the latest compilers.
However, in Herb Sutter's "Migrating to Namespaces" (DDJ, October 2000), we're told that we need to learn about namespaces right away because modern compilers, which have namespace facilities, will not compile old C++ code written in ignorance of them. Herb then gives us an example of some old code that is apparently broken. The code includes <iostreams.h> and does not use the std:: qualifier to access names in the std:: namespace.
What Herb forgets is that including <iostreams.h> automatically dumps all the names defined in std into the global namespace (with a using directive) — a technique used explicitly so the addition of namespaces does not break old code. The other header, <iostreams>, does not have the using directive and is appropriate for new code, or when you are migrating old code. So the code that Herb claims is broken is not, and will compile correctly on any conformant C++ compiler (or, rather, any C++ compiler with conformant header files).
Using namespaces is definitely a good thing for new projects, and upgrading old projects to use namespaces is no doubt desirable, but those of us working on legacy C++ projects have nothing to fear in upgrading to a modern, namespace- supporting compiler. Our old code will still compile and link exactly as we expect it to, with no extra effort on our behalf, and we can reap the other benefits of a more up-to-date compiler, such as better back-end optimization.
Eddie Edwards
C++ Aliasing
Dear DDJ,
Mark Mitchell's article "Type-Based Alias Analysis" (DDJ, October 2000) was refreshing reading after having programmed for some 12 years in an aliasing-free concurrent language. However, I have some points to add:
- Mark does not directly state that aliasing can also happen in pointerless languages. When an object in such a language is used by its name only, it may still be treated by reference by the compiler, thus opening for aliasing errors.
- Aliasing-free code could be fast, but aliasing of objects could be fatal! In the Java example below x=x+(x-x) may correctly be x but fatally zero when c1 is aliased.
class thing ? // By Peter Welch, Univ. of Kent at Canterbury, UK int x; public thing (int v) ?x = v;? public static void harmless (thing t1, thing t2) ? t1.x = t1.x + t2.x; t1.x = t1.x - t2.x; ? ? class alias ? public static void main (String args[]) ? thing c1 = new thing(10); thing c2 = new thing(20); thing.harmless (c1,c2); // c1.x=10 c2.x=20 thing.harmless (c1,c1); // c1.x=0 has become 0! ? ?
- Aliasing may also be a wanted trait. Passing by reference and doubly linked lists are examples.
- Mark mentions that the C9X "restrict" does not prohibit the programmer from making aliasing errors. With occam the compiler takes me at the subtlest places, where I would not have imagined problems — but then there is no "restrict"-type decoration, all variables are verified for aliasing errors, and the compiler can, therefore, always assume aliasing-free code.
- I have just recently learned (at a SIG at the CPA 2000 conference; wotug.ukc .ac.uk/cpa2000) that if you could control aliasing in an object-oriented language, you could also control garbage collection. An object free of aliasing can be deallocated in unit-time once it goes out of scope for the single only referencer of that particular object.
Oyvind Teig
DDJ
