bbaadd.com

Technology: Profiles in Courage

2008-08-05T13:47:00.003-04:00

Mass High Tech brings us the amazing story of a superhuman high tech CEO who at one time worked ten hour days, six days a week, for FIFTEEN MONTHS... apparently without a break.

The sacrifices those of us in high tech must make for our ambitions are under-estimated by the general public. This story proves it. Ten-hour work days, six days a week, behind a desk, sitting in meetings, making Powerpoint presentations... it's probably enough to kill or cripple an ordinary human. That's why CEOs are a different breed of Man.

http://www.masshightech.com/stories/2008/07/21/weekly1-New-Covergence-CEO-Moran-crafts-software-biz-growth-plans.html

CMS's say the darnedest things, #3

2008-08-03T11:47:00.004-04:00

Sometimes the programmers or designers who code a newspaper's style into a production system (for print or online) want to be helpful, so they embed little shortcuts into the system to "save typing" or to help make the publication more consistent.

In this case, someone has decided that every image that could carry a creator's credit is a photo, and that every photo is "by" some person.

This is nit-picking, yes. But a commercial newspaper is presumptively a professionally-written, professionally-edited creation, and as such, should be a standard-bearer for both content and style. A newspaper should demonstrate effective communication, rather than daring readers to read around pointless eccentricities hidden in the software that puts the paper together.

For what it's worth, I first confronted this class of problem around 1986 when I naively hard-coded a similar "photo by" credit into a print-publishing system. The editors and production manager identified the problem with that approach the first time a non-photo image needed a credit...

[ Boston Herald, July 14, 2008 ]

CMS's say the darnedest things, #2

2008-08-03T11:39:00.005-04:00

The Globe turns a critical eye to the Stingray Diet Plan for kids..
[ Boston Globe, July 7, 2008 ]

CMS's say the darnedest things, #1

2008-08-03T11:17:00.006-04:00

Publishers of web sites that contain lots of frequently-changing material use content management systems (CMS) to coordinate the display of all the words, pictures, links, indexes, and so on. Not surprisingly, newspapers with full online editions use CMS's behind the scenes to manage all the stories coming in from reporters and wire services, and to sync the online and print editions. Much of this happens automatically. Some of it shouldn't.

I remember how much care we used to take when laying out a newspaper page. In particular, the relationships between images on a page, and headlines on a page, were always scrutinized. That probably still happens with print editions. I also remember the fuss over the first automated layout systems for print, how much concern there was about the appearance and utility of the page.

No matter how much attention they may still give the print editions of their papers, it's disappointing to see how little concern is directed at the packaging of that same material online. The Boston Globe in particular commits offenses daily. I wonder if they even look at their own "output" at the Globe. Maybe after too many layoffs and years of decline, there's nobody left to put the house in order. If these things happened in print, at least back when I worked in newsrooms, there would have been yelling, lots of yelling. Editors used to yell a lot. Maybe they still do. And after the yelling, someone would have come away knowing never to commit this sort of offense again.

Here's the first in a probably never-ending series...

Hint: that's not Steven Tyler.
[ Boston Globe, June 28, 2008 ]

Technology: Macintosh WiFi disconnect problem

2008-06-01T12:50:00.056-04:00

There have been many complaints about intermittent wireless connection problems with Macs running OS/X 10.4 and 10.5 with some access points. I've experienced a number of these problems myself, and have tested and documented some possible solutions.

I've had problems with two systems:
- Mac 1: Mac Mini running OS/X 10.4, whose wireless connection would fade in and out constantly (minute-by-minute or at least hourly at times); terrible throughput
- Mac 2: MacBook running OS/X 10.5.2 or 10.5.3 that would fail to reconnect to a password-protected access point, with a "connection timeout" error

.. and two access points:
- AP1: Apple Airport Express initially configured as part of a cluster of AP's in a Wireless Distribution System (WDS)
- AP2: U.S. Robotics Wireless MAXg Router (model USR5461) standalone

I believe there are a few distinct problems.
- when the Mini was having connection/ping/throughput problems, the MacBook's connection was rock solid.
- when the MacBook could not re-connect to the access point, no other computer had similar issues.
- I've configured the Macs and access points in various combinations to isolate problems

The cause is not necessarily "a bad access point" as has been suggested in many forums. Don't smash up your access point yet, until you've tried some of these suggestions.
It may be the configuration of the access point that is causing the trouble. Some access points allow fine-grained configuration, and some do not. If an access point does not allow changing some config settings, and you're having these problems, then the AP may need to be replaced. For those models whose wireless settings can be configured in detail, I have some suggestions that may help.

Specific issues with the Apple Airport Express
Issue 1: Poor throughput when streaming music; dropped wireless connections from Windows clients (in particular)
Symptom: Airport Express throughput slows and sometimes drops connection when ANY client is streaming music through it; connection sometimes cannot be re-established w/o resetting the access point or rebooting the client
Cause: Airport Express has limited capacity to deal with heavy traffic. iTunes music streaming overwhelms the device
The problem with re-establishing the connection is possibly a Windows-specific issue related to Windows' handling of wireless reconnects (but also see issue 4 below for another possible cause)
Cure: Don't stream music through an Airport Express whose more-important function is Internet connectivity. Alternatively, pause music during big file transfers
Discussion:
The Express has some issues with heavy traffic generally. On every Airport Express I've used or heard about (models sold in 2006 and 2007), there are throughput issues when streaming music from iTunes while it's also routing Internet traffic. Specifically, when playing music from iTunes through the Express, Internet throughput slows considerably. That's not related to the two issues discussed here, but it is something to keep in mind as it's a problem that could be confused with the others.

Issue 2: Throughput and connection quality when operating in Wireless Distribution System (WDS) mode
Symptom: Poor throughput; intermittent (but not constant) dropping of wireless connection to client. Connection can be re-established.
Cause: Airport Express in WDS Remote Base Station mode seems to have throughput problems
Cure: Don't use Airport Express as a WDS node
Discussion:
The Airport Express can operate as as standalone access point, or it can relay an Internet connection from other AP's in a cluster to cover a larger area than one Express can reach. This setting is found on the WDS tab of the Airport Utility. Running as a WDS Remote Base Station caused disconnect problems for the Mac Mini and we saw substandard throughput generally. At one point this Express had been in a network with another. It wasn't switched back to standalone mode when the second Express went away. Un-checking the box for "Enable this Airport Express as a..." (WDS Remote Base Station or Main Base Station or whatever), did seem to improve throughput for all clients.

Issues for any access point, and configuration suggestions
Issue 3: Frequent wireless disconnects
Symptom: Wireless connection drops frequently; Airport icon in menu bar turns gray, eventually reconnects; poor throughput on large transfers
Cause: Power-save mode issue with some models, when beacon interval is long (1000ms down to some threshold)
Cure: Set access point's beacon interval to 100ms, if it is configurable
Discussion:
I believe the Mac Mini's internal Airport hardware is slipping into a low power mode due to certain management traffic from the access point. Specifically, a periodic signal called "Beacon" sends an "I am here" signal at intervals of between 1msec to 1000msec, depending on configuration. Beacons allow wireless devices to go into a power-save mode when there is no traffic to or from the access point, but it also seems to be the root of problems with the frequent-disconnect issue, at least on the Mac Mini here.

When beacons are frequent, they clutter the wireless channel with unnecessary traffic, and prevent power-saving devices from dropping into lower-power mode. So there is some motivation to impose a long interval between beacons. I had set my access point's beacon interval to the max 1000ms. Though the MacBook and other computers did not seem to have a problem with this, the Mini's connection constantly faded in and out, with the Airport icon turning gray, then coming back seconds later.

I think some less-frequent disconnection problems with a Windows laptop may have been related to this issue. With the beacon interval set to 75ms or 100ms, the Mini has maintained a constant connection to the access point. So, the problem seems to be in the Mac Mini's handling of wifi power-save mode. This is not configurable on the client, so the fix requires an access point on which this value can be set manually. The Airport Express does not have a configurable setting for Beacon interval, but this may not be a problem: we did not experience this issue when using the Express with the Mini.

Issue 4: Cannot re-connect to password-protected (WPA/WPA2) base station after previous successful connection
Symptom: OS/X 10.5.{2,3} client cannot reconnect to AP after previously using it and waking from sleep or even after a reboot. Rebooting the access point seems to allow connections again, for a while. Error on client is "Connection timeout" or "incorrect password"
Cause: I have not made a definitive diagnosis, but the problem seems to be related to WPA2 generally, and probably WPA with TKIP encryption
Cure:
Configure access point to allow both WPA2 and WPA, or WPA only.
and... configure access point to use AES encryption only (no TKIP).
and... configure problematic clients to use WPA, not WPA2.
Discussion: The above lays it all out, and there is not much more to say. I have not worked out the details of what is malfunctioning , but I have made the above changes to my access point and am now able to reliably connect/disconnect with a 10.5.x client that prior to the change was constantly failing with the "connection timeout" error message.

To configure a Mac to use WPA rather than WPA2 when both are offered by an access point (OS/X 10.5.x):
- System Preferences/Network
- Click Airport
- Select the acccess point you want to connect to ("Network Name:")
- Click Advanced...
- On the Airport tab, click on the name of the network to configure
- Click the "edit" icon (the pencil to the right of "+" and "-" below the list)
- Change Security: from WPA2 Personal to WPA Personal
- Click Add to save the change
- The network name should now display "WPA Personal" in the list of wireless networks
- Click OK to exit the advanced screen, and Apply to save the new network preferences
- Let me know if this fixes it for you. It's working well for me.

Other configurable settings on my access point, and how they are set now (in case this also helps):
Beacon = 100ms
RTS = 2347 (effectively meaning "no RTS")
Fragmentation = 1024
DTIM = 1
preamble = SHORT
Security method = WPA2 and WPA
Encryption = AES Only
Key rotation = 180 seconds

Security:First live SiteKey exploit

2007-10-30T13:37:00.002-04:00

A PDF of this post is available, along with other related publications, at http://cr-labs.com/publications/

FOR IMMEDIATE RELEASE
OCTOBER 30, 2007 12:30EDT

First live SiteKey exploit seen in operation

An active exploit of the SiteKey security system used by Bank of America and other financial institutions, employing the man-in-the-middle attack described by Challenge/Response Labs in our white papers of July 2006 and in subsequent work by other researchers, has been observed in a live phishing attack. We believe this is the first time a live, man-in-the-middle attack against SiteKey has been seen in the wild.

The fraudulent site displays valid SiteKey images and text phrases to potential fraud victims. It apparently became active in the early morning of Oct. 30, 2007 (EDT) and was still active at 12:30 EDT Oct. 30, 2007.

We have tested the fraudulent site using the credentials for both a non-existent and an actual account. The site successfully retrieved and displayed a correct SiteKey image for the valid account when given the correct answer to one security question. It also successfully detected and recovered from the error sent back from Bank of America's servers when we used a nonexistent account ID.

The attack appears to use PHP scripts to relay a victim's login credentials to the attacking site, and to relay a victim's SiteKey image and phrase from Bank of America's servers back to the victim.

Firefox’s built-in "Tell me if the site I'm using is a suspected forgery" feature, using a downloaded list of suspected sites, does correctly flag the fraudulent site, and warns the user away.

Why today's development is significant:
• Now that the supporting software ("scripts") has been written and debugged, the code can be expected to circulate to other attackers, so that even those lacking the skill to devise this type of attack on their own can create fake banking sites that interact fully with SiteKey.

• Customers of all financial institutions that use SiteKey-style security are vulnerable to this class of attack.

• Nothing more can be done to "fix" SiteKey to stop the attack, compared to what can be done about any phishing exploit (that is, banks must contact ISPs and server operators to attempt to shut the servers down).

• A potential risk we noted in July 2006, and subsequently studied in depth by other researchers, is now an actual risk. Bank of America's statement that "If you recognize your SiteKey image, you'll know for sure that you are at the valid Bank of America site. Confirming your SiteKey image is also how you'll know that it's safe to enter your Passcode." may create a false sense of security, increasing the likelihood that a customer could be persuaded to enter his or her password into a fraudulent web site, when that fraudulent site shows their SiteKey image and phrase - exactly as occurs in this attack.

• Because the exploit was launched through a compromised BlogSpot blog page, it was propagated by Google Alerts and potentially by RSS feeds, and may have circulated widely without requiring a mass e-mailing.

-----------

NOTES AND CONTACT INFORMATION

Challenge/Response LLC is a Cambridge, MA provider of collaborative, p2p security and e-commerce technologies that bring together the online and offline worlds.

The 2006 Challenge/Response Labs publications, "Fraud Vulnerabilities in SiteKey Security at Bank of America" and "Why SiteKey Can't Save You", as well as this report, are available at: http://cr-labs.com/publications/

The NIST Vulnerability Summary for this issue is CVE-2006-7201, available at http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-7201

See also: The Emperor's New Security Indicators: An evaluation of website authentication and the effect of role playing on usability studies, by Stuart Schechter, Rachna Dhamija, and Andy Ozment, available at: http://usablesecurity.org/emperor/

The exploit was observed and recorded by Challenge/Response, LLC on Oct. 30, 2007, 0908 to 1012 EDT.

Technology: Why Advertising Sucks

2007-08-08T11:10:00.000-04:00

In an online group discussion, Chris Ovenden brought up the mess of advertising we're all immersed in right now:

I have been wondering recently what the world would be like if it were illegal to advertise to people who don't want to be advertised at. (So if they google "fizzy drink" it's okay to send them to pepsi.com; billboards would be out.) But things are going in the opposite direction: ad-supported is about the only financial model anybody seems to be able to come up with.

So what do people think? Is it time to legislate to stop this madness?

My thoughts:

There's no way "ad supported" can pay for as many things as it's supposed to pay for, going forward from here.

People make the same amount of money as always. In the US at least, they're now spending more of it for gasoline and other essentials. They're probably buying about the same amount of crap as always.

There are so many ads because:
- ads are more inefficient today than ever before
- advertisers need people to upend their budgets to buy into new categories of formerly-unknown stuff

Inefficient mechanisms aren't valuable. They have to be operated over and over again to have any influence at all. When the mechanism is advertising, the resulting spray of ads creates more distraction and more competition for attention, which in turn demands more advertising to overcome the ambient noise.

Ads aren't just competing against same-category products (Ford vs Chevy) any more, but against all the other ads for your attention.

Clutter begets clutter in a death spiral. Everyone loses.

The asymmetry that's making things extra messy right now is that online ads are horribly inefficient and cheap, while traditional ads still cost a fortune to book, stage and execute. So by scratching just a couple of minutes of national TV or radio broadcast spots, an advertiser can shake loose enough cash to gum up millions of web page views, wasting zillions of user-hours.

Online I use Firefox + Adblock to make the ads go away. I would be happy to instead pay the site the $0.001 that it might receive for my "viewing", in exchange for a better design whose integrity isn't wrecked by all that useless advertising.

I don't think in the US or elsewhere there'd be any legal way to legislate against ads... everyday free speech is sure becoming a problem, but commercial free speech seems to be pretty well protected :-). And as practical matter, how would ya? I do favor real-world community standards for physical signage, billboards, and so on, but these are at least clearly delineated - physical signs live inside the legal boundaries of a place and can be measured, licensed, and so on.

Ads often destroy the coherence of online properties.. aren't efficient... are intrusive. If an entertainment provider is no longer entertaining, or an information providers is more about ads than information, people will eventually wander away. I might be more of an early adopter/rejecter than then general population, but all come around to these conclusions eventually.

The real problem is that the packaged-entertainment-products industries have been horribly wrong at interpreting and responding to the rejection of inferior goods and/or inferior experiences by consumers. By contrast, nobody's said the Oldsmobile brand folded because customers "failed" to buy ugly, badly-built cars.

I liked Santosh Dawara's example[1] of a moviehouse that's going after profit by maxing out the daily screenings, trying to pull in every available rupee. This is the same as not leaving factory machinery idle when it could be making stuff. It's also a market differentiator. When faced with more-or-less identical competition, a successful strategy is to offer new reasons to choose you over someone else. If everyone else is showing ads, show movies instead. And the movies themselves seem to have have crowded out advertising in this venue, which is a great triumph for movies, if it works.

------

[1] Santosh Dawara wrote:

I am currently working with the number 1 Multiplex in India (in terms of avg. annual occupancy). They have decided to take a unique approach - they don't show ads. Instead, they focus on packing in as many Shows per screen per day. This approach maximizes their profit making ability on the weekends. They show an average *6* shows per screen per day. This is probably a national record. Note, these are Hindi movies with 3 hour durations. Another downside is that the intervals are as short as 5 mins. Never enough time to go grab popcorn.

Life: WiFi in the Garden

2007-05-29T16:16:00.000-04:00

Grandma's house now has cable Internet and WiFi.

So it's a piece of cake (2 bars of signal) to sit on the back patio, away from the house, and connect to the net. This is the same place where 20 and 30 years ago, and to an even greater extent - before I was born - guys from the neighborhood would hang out in the summer, right there next to the garden, to play cards, drink beer and talk all day and into the evening. We had picnics on the old picnic table, and played baseball in the small adjacent yard that wasn't planted with tomatoes and peppers.

There was once a big apple tree whose shade and branches created this gathering spot (and whose green apples made messy baseballs for batting practice in late fall)... but it was too old and had to be taken down, to be replaced by a compact yellow building that extends into its old space, a workplace for gardening and a shady place to sit and enjoy the quiet. The functionality is still there. This could still be the center of the neighborhood again, if there were a neighborhood for it to be the center of. But the people have mostly gone away, and even worse, they've most likely died and the traditions went along with them. Their children and grandchildren have largely moved away, as I did. I can't simulate the kind of friendship and activity that happened there, in AIM or Friendster or MySpace or anywhere else on the net, any better than I can conjure up the smells or sounds of the place, or any better than I can imagine what it must have been like when my grandparents were young and everything was new and there was no such thing as Me.

That laptop has a built-in camera, and the extended-distance 802.11G signal reaches well into the patio and the garden beyond, but the sounds and smells of summer in a garden in a quiet corner of Ohio, and the magic of such a powerful locus of activity and friendship, just don't translate into words or bits or even clever storytelling. I know exactly what it was like. I just can't tell you.

Technology: Goo

2007-02-10T09:55:00.001-05:00

This short essay was provoked by two comments in an online conversation about cellular phones, and an article in the Washington Post:

From the conversation:
I believe that most US carriers will allow use of an unlocked phone. I know for a fact that T Mobile will; I don't see why anyone who travels much would get a locked phone... I personally own an unlocked cell phone. I bought it used, and had someone unlock it.

I don't think carriers, for the most part, can tell whether your cell phone is locked or unlocked. If they can now, they couldn't always, and have surely moved on to more interesting things, such as trying to escape another Judge Green-style imposition of actual competition.

The greater problem is and has always been acquiring that unlocked phone. For many people (myself included) it's plainly not worth the money to pay $400 for a phone that can be had for $50 with an agreement and a lock. Third-party unlock services apparently work much of the time, but are sketchy... so ordinary consumers (most people) are really at a loss. Due to carrier obfuscation of the truth, I'd venture that most would not even imagine that a Cingular phone could be used with T-Mobile.

Carrier customer support will give up unlock codes "sometimes." Sometimes, I'm told, unlocking a phone requires a cable and a PC... or is that only required for hacking the unlock process if the carrier or phone vendor won't cooperate? It's a confusing space. The phone-makers won't tell. And what is "sometimes?" Ordinary consumers are not equipped to make requests that sometimes get you yelled at, that sometimes yield the requested information, and that most often require pushing a vendor to the point of frustration before they'll give up the information they should have given up at the first request.

From the Washington Post article:
Until federal regulators issued a landmark ruling in 1968, Americans could not own the telephones in their homes, nor attach answering machines or other devices to them. Now, a growing number of academics and consumer activists say it's time to deliver a similar groundbreaking jolt to the cellphone industry, possibly triggering a new round of... technical innovations to rival the one that produced faxes, modems and the Internet.

Wireless carriers... say the move is unnecessary and potentially harmful. But... a number of researchers are asking why the companies are allowed to force consumers to buy new handsets when they change carriers, pay a specified carrier to transfer photos from a camera phone, or download ring tones or music from one provider only.

From the conversation:
Unlocking phones is already an approved exemption from the DMCA.
http://www.law.com/jsp/article.jsp?id=1170410587623

I think I've now moved beyond bewildered and pissed off at the state of technology and control in our everyday world, and become merely amused at the new absurdities that arrive daily.

Can you even get your arms around the idea that we live in a world where a telephone - a little thing that you talk into and keep in your pocket, and apparently own, and have to pay money to use each month - would be the subject of an exemption in Federal law so that you don't go to prison for tampering with it?

A friend just asked me for some advice about a security protocol - and I advised him to remove an unnecessary extra layer that he'd added atop an existing, adequate protocol. Unnecessary complexity guarantees that unanticipated states of operation will be made possible. These states will be occasionally (or frequently) entered. Chaos will follow. In any machine, process or set of policies, good overall design is impossible if the system can generate and enter unknown or chaotic states.

I think we're just about at that point with consumer electronics, computers and the Internet.

There's got to be a finite limit, a breaking point - after which it's just not feasible to pile on more clutter without the whole thing coming unglued... where "unglued" may mean:
- customer frustration so that they cut back on using the stuff
- an intolerable, unaffordable increase in support needs due to the now N x N possible interactions between things
- or a regulation and policy stack so dense that it makes development, much less new invention - even by "authorized" developers - practically impossible.

Simplicity plainly will prevail in the end. My frustration is that I've been fated to be alive during this bizarre transitional period, that's left us all - techie, insider, vendor, consumer - trapped by so much pointless, wasteful goo in our everyday devices, and our everyday activities.

Java: How to use complex objects as keys in Ehcache (and Maps generally)

2007-01-30T15:53:00.001-05:00

I've been using the open source Ehcache for some projects I'm working on.

Ehcache uses Java "Map" classes to store the cache in memory. From the memory store, they can be overflowed to disk (if all the allocated memory is used) and/or persisted to disk (so that stopping and starting an application preserves cached objects between runs).

I have some issues with the bumpy spots, omissions and redundancies in the new documentation, but overall this is great stuff. Finding ehcache saved me from writing my own, less-capable cache, and I am grateful to have it.

There is, however, a problem storing and finding cached data with ehcache when using some kinds of objects as keys.

Quick refresher
Maps (and any cache, for that matter) have two parts
(1) a key that's used for finding objects;
(2) the stored objects

So, the basic operations on a Map (or cache) are:


  void put (Object key, Object item); 
  Object get (Object key);

The problem
Specifically, if a cache key is not a String but some other kind of object (say, a custom Class with some fields in it), cache lookups may fail some of the time, even when the stuff you're looking for is right there in the cache.

EXAMPLE 1. The key is a String, and this succeeds:


WhateverObject item1 = new WhateverObject();
Element el = new Element("Item1",item1);
cache.put(el);
cache.get("Item1");

EXAMPLE 2. The key is not a simple String, but this succeeds:


class MyKey {
  int a,b;
}
WhateverObject item1 = new WhateverObject();
MyKey key = new MyKey(); key.a = 12; key.b = 22;
Element el = new Element(key,item1);
cache.put(el);
cache.get(key);

EXAMPLE 3. ... but a similar lookup fails when a new MyKey object (containing the same values as the original key) is used for the lookup:


class MyKey {
  int a,b;
}
WhateverObject item1 = new WhateverObject();
MyKey key = new MyKey(); key.a = 12; key.b = 22;
Element el = new Element(key,item1);
cache.put(el);
MyKey key2 = new MyKey(); key.a = 12; key.b = 22;
cache.get(key2);

What's going on?
This behaviour is consistent with the contract for Map objects, and may be the desired behavior for some object persistence designs. However, it may be completely undesirable for others. With regard to the storage model and ehcache in particular, the behaviour is sometimes right and sometimes wrong for memory-only caches, but always wrong for caches that persist to disk, if you buy into the presumption that a disk-persisted cache will be accessed in separate runs of an application.

The crux of the problem is in the way Java's Map classes store and index the keys in a Map (and thus, the keys to ehcache objects, which use Maps).

To make searches fast and straightforward to implement (internally, in Java), the keys are stored as integers in a table. The integers are hashes derived from the key objects. That is, they're one-way mappings from something like "ABC" to an integer value like 64578. Integers are fast to search, fast to sort, and fast to compare.

So you've probably guessed where this is going.

Finding an object in a cache or in a Map requires that the caller present a key that reduces to exactly the same hash as was created when put(key,item) was called to add the item to the Map in the first place.

In other words:
To find an object in a Map or Map-based cache, keys with identical content must reduce to exactly the same hash every time they're converted from their usual form into hashes.

Java generates these hashes by calling the hashCode() method that every Object has. And it compares them by calling the equals() method that's a standard method in every Object.

The problem comes from the way that Java makes the hashes.

Strings implement the hashCode() method in a way that is based on the content of the String, and that is repeatable every time the method is called on an identical string.

For example, "ABCDE".hashCode() always returns the integer value 62061635 no matter how many times you call it.

Objects that are not Strings use the default hashCode() method of the Object class. This hashCode() is not based on the content of the object, but on its OID, which is different for every instance of an object, and every run of an application. That's why the code in Example 3 fails: objects 'key' and 'key2' are different objects (even though they're of the same class), so their default hashCode() values will be different.

As well, the class's equals() method doesn't compare object content, but OIDs, so (from Example 3):
key != key2

Example 2 works fine, because the object "key" that was used to put the data into the cache is the same object for both the put and the get... and thus the OID is the same for both operations.

Solution

The solution to this problem is to give your key objects a hashCode() method that return identical hash values for identical content, and an equals() method that returns true when two keys have the same content. With that change to the class that's used as a key, Map class accesses, and by extension, ehcache cache lookups, will work as expected.

Here is a sample class that implements the methods using a lazy trick to just make the object's contents into a String, and then returns the hashCode() of that String (because, as mentioned, Strings return the same hash for the same String content every time).

A better, more efficient implementation of hashCode() would generate a return value directly from the fields of the key class, without the String overhead... but you get the idea. This example also implements a toString() method that returns the content of the class as a String. Obviously that won't be needed if you make a hashCode() method that goes right from fields of the class to a distinct integer value.

In this example, the "key" to some data is an object that has two fields, a Date and a double. Date is just a thin wrapper around a long, and this example uses that long. I did this to save the conversion from long to the formatted date string that would happen if the Date were used directly.


import java.io.Serializable;
import java.util.Date;

public class CacheKey implements Serializable {
 private static final long serialVersionUID = 1L;

 public Date when;
 public double howMuch;

 public CacheKey(Date when, double howMuch) {
  this.when = when;
  this.howMuch = howMuch;
 }

 /**
  * Generate a hashcode based on the content of the object
  */
 public int hashCode() {
  return this.toString().hashCode();
 }
 
 /**
  * Make a string for use by hashCode(), including all fields
  */
 public String toString() {
  return ""+when.getTime()+howMuch;
 }

 /**
  * Compare this object with another. Note that comparisons 
  * MUST compare the values of the fields of the object that are
  * of interest (or whatever else is of interest). You can't compare the
  * hashes and get a good result -- hashes are allowed to collide. They just
  * reduce the search space tremendously.
  */
 public boolean equals(Object o) {
    CacheKey ck = (CacheKey) o;
    return ( (ck.when == this.when) && (ck.howMuch == this.howMuch));
}


  return (this.hashCode() == ((CacheKey) o).hashCode() );
 }
}

References:
http://www.oracle.com/technology/pub/articles/maps1.html
http://sourceforge.net/projects/ehcache/
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html

Postscript:
Notes about the "cheap" method I used to make the hashCode()

Someone suggested that I use Strings as keys.

The problem is that I'm using a self-populating (or pull-through) cache. With this kind of cache, the cache itself calls the method that fetches things not found in the cache, by calling that method with the key value. Thus, the key must encapsulate everything that's needed to fetch the desired data. In the case of my application, that's two Date objects, and two doubles... and there's no way around it. A String just won't work. Well, not directly.

Anyway, carefully overriding hashCode() to generate an integer based on the contents of the key object, and then overriding equals() so that it compares the hashCode of the current Object to the hashCode of the compared Object, is the proper solution.

My example code takes a cheap shortcut, tacking the fields together in a String and returning the hashCode of that String.

It shows the general idea of what needs to happen, and for that matter, I'm not totally opposed to the approach, given the kind of data I'm working with.

I could generate an integer hashCode() by summing the integer values of the fields. However... (1) the Date objects will be clustered very close together so their Date.getTime() methods will return nearly identical values; (2) if using long getTime() values, I'd have to subtract a large constant to get them into integer range...

... and even after all that, both overflows and collisions would remain a strong concern.

Another approach would be to perform a hash operation over, say, the bytes of the values of the fields. For my money, that's not so different from making a String out of the fields and letting its hashCode() method deal with it... String conversions aren't cheap, but the base operation to fetch data takes something like 5000msec, and even with this unoptimized key-handling, cache retrievals take on the order of 25msec (from memory) to 100msec (from disk), so it's a tremendous savings.

Diggler assists with "digg this" buttons on Blogger pages

2007-01-12T18:09:00.000-05:00

It's obviously desirable to place a "Digg This" button on a blog entry.

Digg provides the script and instructions. Unfortunately these don't work on Blogger, because Blogger strips the JavaScript out of posts. Diggler makes it easier to use an iFrame workaround to get that precious "digg this" button onto a Blogger page.

This page is using it :)

Here's the link to diggler.splattercast.net

Who's watching the watchers? (StopBadware blacklists a cartoon book site)

2007-01-11T18:58:00.002-05:00

Capefeare.com is described as "The Ultimate Life in Hell Website" and contains some scans of Matt Groening's first work, Life in Hell (I was a huge fan - these hip cartoons ran in the Village Voice and other places in the unhip 1980s).

Copyright issues notwithstanding, the site seems to have no evil intentions. It's not selling software. Afaik, it didn't try to install anything on my computer.

The site has a straightforward description:
...Here, you'll find information about Matt Groening's first work ever, Life in Hell, which started in 1980 long before the Simpsons became popular. Here, you will find Life in Hell comic strips that came from magazines or newspapers that aren't published in any Life in Hell books! There are also Life in Hell references in the Simpsons/Futurama vice versa, lists of Life in Hell books (14 of them), and even Life in Hell wallpapers! This is heaven for any Life in Hell fan!

That sounded pretty good to me. And yes, it could be a lie.

When I found this site through Google, the Google link didn't take me to the site. Instead, it warned me that I'd be taking a great risk if I opened the page:

The search:

The response (http://www.google.com/interstitial?url=http://capefeare.com):

Not listed at StopBadware.org - what's the issue?
The site is not listed at http://stopbadware.org/, which at this writing has 412 sites in its catalog.

So, I'm confused. I didn't study the site in depth, but I did take a look at the source code of the home page and can't find anything evil there. It has a some Google Syndication stuff. There is a stats link for the tracking site "extremetracking.com" and 1 pixel web bug for "extreme-dm.com".

I hate that stuff, particularly the web bug, but "everybody uses" the damned things, and the presence of a web bug definitely doesn't make a page "badware." Most important, web bugs and stats links don't "harm" a computer - the thing that StopBadware.org is supposed to be protecting us against.

The site seems to be legit. There's even a large and active Simpsons fan forum, among other cues that suggest that it's on the up and up. Again, it could all be a lie, but it doesn't seem to be.

Appeal. That's the only recourse.
So, many questions remain: Who's watching the watchers? Who corrects the mistakes, and who pays for lost business when a commercial site ends up in being banned? And why is this site banned if StopBadware.org doesn't seem to know anything about it?

This matter has all the marks of a coordination issue between the blacklisting source (stopbadware.org) and the information provider (Google), and nobody outside that circle can probably fix it.

Here's what StopBadware.org says about making "an appeal" to be removed from the listings:
If you are the administrator of a website or the producer of software that has appeared in a StopBadware.org report and would like to speak with us regarding the evaluation of your site/software, please contact us at appeals@stopbadware.org.

My e-mail to the organization's contact address, asking what's up with this, yielded a canned reply saying that they're receiving too much e-mail to be able to answer e-mail.

So, if updates and corrections don't happen in a timely fashion, what can a little guy do? Sue Google and StopBadware.org (at Harvard's Law School)? Not likely.

Thanks, but...
I commend everyone involved for trying to solve a terrible problem.

But when the only recourse for a mis-listed site is to send an "appeal" to a blind e-mail drop, I'm left wondering if more must be done to guard against incorrect listings. Getting the attention of StopBadware.org creates an unremovable global ban on a web site, damaging its reputation (deservedly in most cases, to be sure).

But the good done in most cases cannot excuse errors, or undo the damage they cause, particularly when the well meaning people behind StopBadware.org are also very involved in monitoring, reporting about, and railing against net censorship in China and other places.

Privacy breach at Emigrant Direct?

2006-12-24T10:15:00.000-05:00

I'm on the road and can't write in much detail, but I just noticed that I have been receiving spams since before December 8, addressed to an e-mail address that is ONLY used with Emigrant Direct Bank (http://emigrantdirect.com).

When I opened an account there, I created a separate e-mail address. They've never had any other, and there's no reason for me to have ever used this e-mail address elsewhere.

Barring the live capture of traffic (c'mon nobody really does that just to get e-mail addresses)... I can't think of any means that this address would have made it into spammers' hands .... other than an inside job or some kind of break in.

I hope it's not true. I'm open to hearing plausible explanations, or from anyone who has had the same experience.

I'm changing the address to see if it happens again.

Technology: Friendster acting desperate and dateless

2006-12-15T13:21:00.000-05:00

Friendster wants me to be excited that one of my friends has updated something about his account, even if it's something as simple as updating his bookmarks. yeah. So it sends out e-mails like this complete with the picture and name of, well, a guy I have never met and don't know:

How did that happen? Here in Cambridge there's a place called Inman Square, and once upon a time someone made a Friendster profile for "Inman". Lots of people list "Inman" as their friend. I am a friend of Inman. The guy in the e-mail is a friend of a friend of Inman. That is, he's three steps removed from me, where the most critical link is not even a person. It's like this:

Conclusions:
1. Considering how far Friendster is willing to stretch the definition of "Friend," there must not be much going on within the Friendster "community"... I receive very few of these announcements even though Friendster is making such a amazing leap to come up with anything meaningful to say to me. It's worse than a bad date where you just have nothing to say to each other... sometimes even bad dates will buy me a drink or dessert. Friendster just sends these sad emails, searching for a connection that's just not there.

2. Inert catalogs of people and the real or make believe connections between them are somewhat academically interesting right up to the instant that they're built and deployed. Then, they're not very interesting at all.

Security: Unanswerable Questions, Part 1

2006-11-01T19:03:00.000-05:00

In the course of resetting a "forgotten" password (btw every couple of months when I try to use the Capital One website, my password doesn't work until I "reset" it).. I was required to also change my "security question" (no good reason for that requirement, when you think about it). Unfortunately customers are not trusted to choose the security question, so Capital One does it for you...

How many people can answer this question? I cannot. I feel inadequate. And yet, I had to provide an answer to that question in order to get into my account. So, I made something up, which is even more secure than answering the question... but personal questions like this are still weird and horrible security risks over time.

Here's a screen grab of the forgotten-password screen. The question's at the bottom of the image...

Finance: It's I-Bond time again

2006-10-19T14:10:00.000-04:00

Every May 1 and November 1 the Treasury revises the interest rates paid on I Bonds, which are a kind of US Savings Bond that is indexed to the rate of inflation... after a fashion, anyway.

A major component of the bond's interest rate is the rolling 6-month inflation rate. Those numbers are released in advance, and September's 6-month inflation rate (just released) is used in the computation of I bond rates for November.

The 6-month inflation rate for September was 1.55%.

When that's cranked through the formula for setting the inflation-indexed part of the bond rate, it comes out to a bit more than 3.10%.

Then the government adds a "fixed rate" set by the Treasury, that isn't as predictable. The fixed rate has never been below 1.00%. For the current period starting last May, it's 1.40%.

FYI the fixed rate also adds a smidgen to the inflation-indexed part of the bond's rate, so if the fixed rate is 1.20%, and the inflation rate is 1.55%, the bond's interest rate would be 4.32% (not 4.30% as you might guess).

Anyway, the rate for November 06 through April 07 I Bonds will be: 3.10% + fixed rate

We can guess that the fixed rate will be somewhere between 1.00% (the historical low) and 1.50% (just above the current 1.40%) for a total interest rate of 4.12% to 4.62%

When to buy I Bonds
Currently, I Bonds have the worst interest rate of any government security or insured investment. There is little reason to buy them before the considerable rate increase that's assured for November.

The money that would buy those I bonds should be earning interest somewhere else right now, hopefully at 4.00% or higher (EmigrantDirect is paying 5.05% in an MMDA cash account, for example).

An optimal strategy for moving money into I Bonds at the new rate:

1. Maintain cash designated for I bonds in liquid (e.g. MMDA) accounts paying at least 4.00% until bond purchase.

2. Bonds pay interest for the entire month of purchase, even when purchased at the end of the month, so near the end of November, extract cash from the high-interest cash account and purchase I Bonds at the new rate, capturing regular interest on the money for November, AND an entire month of I Bond interest.

Considering the big increase in the rate, this approach probably works whether the accounts are tax-advantage (e.g. IRA) or not.

Investors who need to create or stay in a tax-advantaged investment in the very near term should consider purchasing 13-week T Bills in the interim... this pushes back the I Bond purchase date a bit, but bonds always adjust their rates at 6-month intervals, so a bond purchased in December or January will earn six months' interest at the new 4.x% rate once purchased, and will have its rate adjusted every 6 months thereafter.

Remember that I Bonds can't be cashed at all for the first year, and that a penalty of the 3 most recent months' interest is assessed if the bonds are redeemed in the first five years.

Followup: 11/1 Rate Announcement
The fixed rate as of 11/1 remains at 1.40%, so the new rate is 3.10% + 1.40% + (a bit more, see the formula for details) = 4.42%.

The ongoing discussion of I Bonds at Suite101.com is another place to chat about this kind of investment.

Process: Communication is the problem to the answer, Part 1 of N

2006-10-11T11:03:00.000-04:00

Sure to be a recurring theme... communication breakdowns in everyday life...

Found on MySpace yesterday. Is this even English?

Process: Apple's battery puzzle

2006-10-04T16:49:00.000-04:00

Apple's exploding battery return process includes a puzzle: fit a 3.75" label into a 2.75" space, without covering any of the necessary address information:

Turn page over for solution:

Process: EmigrantDirect's missing "delete" button

2006-10-02T10:28:00.000-04:00

I wanted to remove a link between my Emigrant Direct savings and another bank account that I closed several months ago. So, I signed on (username, password, last 4 digits of SSN) and didn't know exactly what to look for, but assumed it'd be along the lines of "Accounts / Funding / Delete"

Here's the screen:

With no "delete" option in sight, I wrote to customer service... received this reply this morning (e-mail notification of "important message", then username, password, last 4 digits of SSN to sign on):

It feels more and more like organizations publish instructions that "seem" correct, whether or not they really are correct. In this case, there's no delete option, but the customer service rep presumes there should be... or it's missing from my screen due to some other business rule that nobody at the back end has told the front end about. In any case, it's a process failure on the bank's part... two people spent a lot of time working their way toward ultimately useless, redundant instructions.

Technology: Making digital goods valuable

2006-09-05T11:23:00.000-04:00

MySpace just announced that it will begin selling music by the thousands of bands represented on the site.
In an online forum, someone asked:

"... what are the chances that the apathetic teen generation will want to actually "pay" for music? They don't seem to buy it from shops, or any other download store, so why will MySpace be any different?

My answer:
That's an easy one... a music download represents the reduction of the music to "product" in a very uninteresting form.

Vinyl albums (ignore for the moment the necessity of the medium) presented music with a containing context, back-story, and other features that improved the experience of the music and that enhanced the value of owning one's own copy. The containers that black vinyl comes in are themselves often appreciated, sans music, as freestanding works of art and pop culture.

CD's were the start of the downfall of the valuation of music, not because of the digital music on the CD, but because the packaging and surrounding materials failed to evolve into some album-equivalent for the new format, and because so many packages were (and are) stripped down to nothing but a shiny disc in a plastic box. The containing experience, the context and the backstory were taken away, and the product lost some of its substance.

I do not suggest that the album aesthetic should have been literally scaled down and dropped into CD packaging, but that new forms appropriate to the medium should have evolved, and did not... with notable exceptions, of course.

And now, people are asked to pay money for the right to reproduce and decode bits... just bits. There's not even an album cover to hang on the wall.

I don't expect, going forward, that "pay for music" is going to have any traction all by itself. Bits aren't very interesting, or very personal.

The demand of the industry is that would-be buyers must be re-educated to "value" these ephemeral bits as the industry requires them to. But people aren't going to learn an exception for one kind of good, and won't be "trained" to value bits as they might value an album cover with lush inside graphics, or a super-thin cell phone, or a nice pair of shoes.

The problem with the industry's expectations - and here it acts like a parent disappointed in a child's sloppy skills at some task - is that people simply don't seem to work as the industry wishes they would. Perhaps a change in perceived valuation might happen eventually. But it's still the case that such a change could not be imposed by fiat into any generation that's alive right now except by force. That's DRM: imposing unintuitive, unfamiliar behaviors on people whose worlds, other than as consumers of media, don't work that way.

No industry can thrive with unhappy or confused customers forced into an arbitrary model of valuation for one kind of optional good. People get bored and move on, work around, or just ignore anomalies. That's why we have file sharing.

The whole story isn't really very interesting. The same issues trashed the first wave of web-hype startups that priced their goods at $0 and found "those customers who value the product at $0." There was no reason for the startups to be surprised when, once prices were raised above $0, people went away.

Bottom line: the difference between $0.00 and $0.05 is much greater, in terms of consumer behaviour, than the difference between $0.05 and $1.00. The difference in perceived valuation - by humans - of cool sunglasses and some digital bits is likewise substantial.

I've been working on some models for de-commodification of digital goods that I really oughtn't blast out in public just now, but would invite anyone with an interest to write me directly if you'd care to discuss in more detail.

The secret of creating valuation in digital goods is no secret - the "goods" have to be converted (or mapped, or attached) to something that has intrinsic value to normal people, acting as they do ordinarily, without imposing arbitrary exceptions. Customer perception of value cannot be changed on demand of a producer. Rather, the nature of the goods must change to engender perceived value among potential customers.

Security: Why SiteKey Can't Save You

2006-08-24T14:04:00.000-04:00

The PDF version of this document including an abstract is available from Challenge/Response, LLC Labs at  http://cr-labs.com/publications/.

This overview of “Fraud Vulnerabilities in SiteKey Security at Bank of America” is written for a non-technical audience. Some details have been greatly simplified, and some new material is presented. Readers seeking more depth of coverage should consult the original paper, available at the above URL.

Although this report discusses SiteKey℠ at Bank of America Corporation, the general risks discussed here apply to all SiteKey sites including ING Direct and Vanguard.com, and they apply even more generally to any security method that relies solely on server-side interventions to detect and stop online fraud.

The product and the problem

SiteKey shows web banking customers a “secret image” – a little icon of a mandolin or a coffee mug or something else – that only the customer and the bank are supposed to know. Customers of SiteKey-using banks are told that if their correct secret image appears a purported bank web page, they can be sure that they are connected to the bank’s real web site, and can safely enter passwords and other secrets. Nobody could guess a person’s secret icon chosen from a pool of hundreds of images, right?

Bad guys – unless they’re psychic – definitely cannot guess secret pictures with the accuracy needed to pull off phishing frauds. Unfortunately, the design of SiteKey means they don’t have to guess. Rather than guessing, a scammer can carry out a “man in the middle” attack in which an innocent person’s true SiteKey image is retrieved directly from the bank’s own servers, then displayed to the victim on a fake web site. Criminals who can write simple server software, or who hire someone to write such software, can create fake bank web sites that look just like the real thing, and that display correct, “secret” SiteKey images to unsuspecting victims. 

Defeating SiteKey in a ten step man-in-the-middle attack: in the end, the fraudulent server has the victim’s  user name, password, question-bypassing token and SiteKey image, allowing unlimited access to the account.

What this means for online banking customers

Even if you see your personal, “secret” SiteKey image on a web page, the page may not be legitimate. When entering your password or answering a security question, picture or not, you could be giving away secrets to an overseas crime ring, rather than logging on to a bank account.

Some SiteKey installations strongly promote the safety of SiteKey. For example, Bank of America tells customers:
“If you recognize your SiteKey, you’ll know for sure that you are at the valid Bank of America site. Confirming your SiteKey is also how you’ll know that it’s safe to enter your Passcode and click the Sign In button.”

But that statement is not true all the time. It’s true most of the time, because most of the time a bank’s customers are not looking at fraudulent web pages. But “most of the time” is of little use when trying to detect the one instance out of a thousand when it really is a bad guy, and not the bank, at the other end of the connection. SiteKey can’t always do that, and the process of creating a fake SiteKey page is fairly trivial.

Some people may be worse off with SiteKey than without it. Marketing language like “...if you recognize your SiteKey... you’ll know that it’s safe to enter your Passcode” could unintentionally help criminals by persuading security-conscious customers that the presence of the SiteKey image is absolute proof of the safety of a web page.

An additional problem is that the things SiteKey protects – user names and passwords – aren’t very good security devices. In particular, they can be reused by a bad guy in a “replay attack,” which means simply that once stolen, they can be used over and over to access a victim’s account.

Although some security systems resist replay attacks, few online services offer replay-protected authentication, so this vulnerability isn’t special. But Bank of America says SiteKey does guard against replays by requiring customers to save and answer personal “challenge questions” such as “What was the name of your first pet?”
This sounds fairly safe: a bad guy holding someone’s user name and password is not likely to guess the name of the victim’s first pet before the system locks him out for making too many incorrect guesses.

But a bad guy who has stolen a user name and password using a real SiteKey image – via the method described in the full paper – doesn’t have to answer challenge questions. When an attacker fools a victim into making a single login to his or her account though a fake site, SiteKey issues a “bypass token” – a code that turns off challenge questions altogether. The token can be copied and shared among many computers.

Thus, by tricking a victim just once, an attacker picks up a victim’s user name, password, SiteKey image and bypass token, granting unlimited access to the victim’s account even though the attacker cannot answer the remaining challenge questions that should still guard it. Challenge questions provide little added protection against future access to an online account, and are compromised right along with the user name and password during man-in-the-middle attacks.

Limitations of single-ended security

Security methods that try to protect everyone from the server’s end of a connection are popular right now. Customers don’t have to be involved, and it is presumed, wrongly in my view, that they cannot or will not participate in their own protection beyond looking at pictures in web browsers. SiteKey appears to involve both ends of the connection, but as explained here, when a SiteKey image is sent blindly toward an apparently customer-controlled computer, there is no assurance that the image has reached an actual customer, or that it has done so so free of “man in the middle” tampering.

Server-side security does stop some attacks, and makes others difficult. But the approach has gaps that cannot be filled by adding more server-side security. Security is a process issue more than a technology issue. Fixing half a process is a bad idea generally, and it’s a terrible approach to high-stakes security.

Just as a landline phone call doesn’t travel over a private wire between two phones, there are no direct connections on the Internet. A web page sent from your bank’s web server to your browser is turned into “packets” that pass through many unrelated points along the way. A bank can’t lock down the path those packets travel between itself and you, because it doesn’t control the whole path from end to end. And some indirection in online communications is perfectly normal, so it can be difficult or impossible to tease out rare cases of malicious indirection.

A bank’s web server also cannot control exactly what’s displayed on your computer screen. Web browsers are not televisions that show exactly what was sent: they interpret web pages and display them a bit differently on every computer. Something could be changed en route – such as when an attacker drops a real SiteKey image onto a fake web page – and the bank probably will not know anything about it.

If a victim is led far astray – say, to a fake web page that does not involve a bank’s servers at all – the bank cannot detect or interrupt the fraud. SiteKey helps with this scenario, by forcing fraudsters to retrieve a victim’s SiteKey image from their bank’s real servers. If too many inquiries were to come to those servers from one place, alarms could be raised. However, such monitoring can be foiled with “bot nets” – clusters of thousands of Internet-connected home and office computers that have been taken over by criminals without their owners’ knowledge. Fraud-related connections made through such bot nets would not come constantly from one busy server, but would arrive a few at a time from many different computers, interfering with this sort of detection.

Customers of SiteKey-protected banks are also apparently still falling victim to frauds that don’t even attempt to show SiteKey images. Customers need more basic assistance in detecting those occasions when a bank’s servers are completely uninvolved in a fraud.

What can customers do to be safe? Can anything more be done by banks?

Keep in mind that a bank using SiteKey is no less secure than any other online bank – it’s just not appreciably more secure than the others. Never let your guard down just because you see your correct, personal SiteKey image.

The best tactic is to observe the same safety tips that apply to all other e-commerce:
1. Never click links in e-mail messages 
2. Always type the URL of your bank’s home page into the browser, or save the bank’s login page as a bookmark 
3. Remember that banks and e-commerce vendors don’t send alarmist “your account will be closed” messages 

The Federal Trade Commission offers more tips at: http://www.ftc.gov/bcp/conline/pubs/alerts/phishingalrt.htm

Although the connection between a bank and its customers cannot be made completely safe with security that’s added only at the bank’s end, this does not mean that frauds cannot be stopped. If fraud-stopping processes are engineered properly, frauds can not only be detected, but could made a virtual non-issue in everyday e-commerce.

Challenge/Response and other companies are working on end-to-end security methods that make e-commerce sites and their customers partners in safe online commerce. Customers should encourage their banks and other online trading partners to let them take an active role in their personal protection by using tools like these.

Making SiteKey less risky

A few changes could make SiteKey installations less risky for customers. Among our suggestions are these:
1. Financial institutions must never claim that a security system will provide absolute security. Customers need and deserve frank information about risks in the security provided by the companies they do business with.
2. Customers should be given more control over the “bypass tokens” that disable challenge questions. For example, a customer should be able to tell SiteKey to invalidate all the tokens ever issued for his or her account. Then no computer would be able to access that customer’s account without a fresh, complete theft of the customer’s secrets.
3. The Federal Trade Commission recommends that banks use SSL for all web pages. SSL encrypts the data between a bank and a customer, and activates the “lock” icon in browsers. SSL does not prove that a web page is legitimate. However, fraudsters move their fake sites constantly as their servers are discovered and taken offline, and SSL servers are difficult to move around. For that reason, most online frauds do not use SSL and probably will not use it in the future. A missing lock symbol on a page that should be secure would definitely signal trouble if banks always used SSL. But despite the FTC’s guidance, most banks still don’t use SSL for all their web pages, so the presence or absence of the lock symbol does not help customers discover frauds by this simple method.
4. Banks may have to stop e-mailing their customers with messages that include links back to the banks’ web pages. Fake e-mails outnumber real ones by a big margin, and it is hard to tell a real e-mail message from a fake.

Notes

- SiteKey began as a product of Menlo Park, California-based PassMark Security. Passmark Security was acquired by RSA Security in April, 2006. As of July 2006, RSA was in the process of acquisition by EMC, Inc.

- The information needed to understand SiteKey or to perpetrate frauds against its users can be acquired with little more than a web browser and an HTTP or TCP monitor such as tcpdump, or from the traffic logs of a web proxy such as Squid. No privileged access to servers or other devices is needed.

Security: SiteKey isn't as safe as you may have expected

2006-07-20T09:58:00.000-04:00

The SiteKey anti-phishing system used by Bank of America and other financial institutions is susceptible to a real-time exploit in which an attacker can create a fake web page that includes a victim’s correct, secret SiteKey image, text phrase and challenge questions.

So... if you're looking at a web page that claims to belong to your bank, and it's even showing your secret SiteKey image, it's possible the page is not coming from your bank, but from an attacker trying to steal your login secrets. Really.

My new paper discusses the problem, and explains why single-ended, server-side-only authentication used by SiteKey and other systems is not and cannot be an adequate protection against phishing or other online frauds.

"Fraud Vulnerabilities in SiteKey Security at Bank of America" is here (376K PDF):
http://cr-labs.com/publications/SiteKey-20060718.pdf

Process: Privacy is painful

2006-05-07T09:28:00.000-04:00

Capital One recently sent me one of those fine-print privacy-policy mailings and "opt out" instructions. This isn't because Capital One and the rest of the banks, brokers and credit card companies want to be good guys about our privacy. They're required by Federal law to do this once a year..

... and they don't make it easy to get away from the "information sharing." First (and least important) they've hired Mrs Blaster to record the voice prompts -- it's loud, grating, and painful to listen to. Hear for yourself at 1-888-817-2970.

... most important, opting out requires following this fast-talkin' monotone through lengthy rants about "opportunities" and "personalized offers" -- their attempt to get the caller to NOT opt out, by persuasion or confusion. The actual opt-out process consists of pressing the number "1" several times, at just the right moment.

I'm posting this because I just noticed my phone had keypress history on its display, and I'm impressed with the amount of work I had to perform to tell my bank to stop giving information about me to strangers, in relation to two accounts: (account numbers have been replaced)


1 3 2 5 2 4 6 3 1 1 0 7 #
1 1 1 1 1 1 3 3 1 5 6 4 8 1 1 3 9 #
1 9 1 1 1 1 9

The call lasted 6 minutes, and I'm pretty fast. Approximately 5 1/2 of the 6 minutes consisted solely of Mrs Blaster shouting about all the great stuff I'd miss if I opted out.

One of the preferences, for one of the accounts, "has already been registered" and cannot be changed over the phone. I can write them at a PO Box to change that specific preference. Of course the recording didn't tell me whether I'm currently opted "out" or "in" for that preference. Let's do the math: Capital One has the compute power to track my account balances, to postal-mail and e-mail me when they want to sell me stuff, plus the ability to assist "trusted business partners" by giving my credit and account records to strangers... but Capital One can't read back a one-bit value related to something that obviously matters to me.

After all that, I now must go to Capital One's preferences website at http://preferences.capitalone.com/ to remove my e-mail addressses. You're not allowed to do that over the phone.

Apologies to readers, cuz this /is/ a rant and I don't have a solution, except to encourage others who confront this to vote with their feet. I hope that by cataloging these insults, more palatable alternatives to the kind of existence imposed by the Capital Ones of the world will become apparent. Capital One is customer-hostile, and won't sell me anything by annoying me. I'll be leaving soon.

Finance: You can panic now, or panic later

2006-04-27T01:32:00.000-04:00

TheStreet.com contributor Terry Savage is advising people to load up on I Bonds before a likely rate decrease on May 1.

Her math is approximately correct, but I'm not sure she really understands why that is. She carries on too long about the "complexity" of the Fed's methods in calculating I-bond interest rates, and not nearly long enough in explaining the justification of a panic purchase. The Fed's methods do involve multiplication and addition, but it's not "calculus" as she calls it. Most important, there are gobs of alternatives that will pay more interest than an urgent I Bond purchase... with none of the panic.

Here's the deal: I Bonds pay interest based on a two-part formula. Part of the bond's interest rate is set when the bonds are issued, and part of the rate is adjusted every six months (November 1 and May 1). For example, I bonds issued between Nov. 2005 and now have a 1.0% fixed rate, and a 5.7% inflation-adjusted rate for a "composite rate" of 6.73% (the extra .03% comes from the Fed's formula - look it up below). This is a very high rate, relative to other investments. It occurred because the two sampled months had a big disparity in their Consumer Price Index figures. It's a bit of an anomaly actually... but because I bonds are designed for long-term investment, these things do average out in the end so while the Fed's methods are vulnerable to short-term blips, over the long haul, it's all rational.

By the way, if you want to know more about I Bonds and rate calculations, the US Treasury publishes comprehensive online resources that will tell you all you need to know, so I won't fill this space with empty repetition of their work.

Savage is flapping her arms yelling "buy I bonds now!" because it seems inevitable that the May 1 adjustment will see a big decrease in I bond rates. The previous rate was high because of a blip, and inflation over the recent 6 months was low. I Bonds are inflation-indexed, so... inflation goes down, I Bond interest rates go down.

Savage says investors must lock in that darling 6.73% rate now.. today... Friday... Monday's too late...

I'm pretty sure this is lousy advice. Savage has failed to consider alternative investment vehicles for money that would go into those I Bonds, and she isn't counting the costs of disposing of the bonds if the interest situation doesn't improve after a year.

The problem is that once the rate drops to 2.0%, that 6.73% over six short months hasn't earned the investor very much money, but has created a lot of bother with rules about selling the bonds, possible interest penalties, and worst of all, a panicky "buy now" imperative.

The effective interest rate on these bonds for the first year, using her figures (assuming the May 1 rate will be 2.00%) is (6.73% + 2.00%) / 2 = 4.365% or a bit lower if you sell the bond at the end of the year, due to penalties. There's an example below with real numbers filled in, to illustrate where the money comes from and goes.

So, an I Bond might earn you 4.365% for year 1, free of state and local taxes.

What alternatives exist to I Bonds that don't have the uncertainty and the assured low rate? That's an easy one.

Other government securities
Monday's 6-month rate for US Treasury Bills was 4.919%. T bills are state/local tax free, and the investment terminates after 6 months with no penalties or other obligations. You can also ease your way into these over several weeks if you don't want to commit to a single moment's rate -- T bills are auctioned every Monday.

Good old CDs
BankRate.com is showing one year Certificates of Deposit paying up to 5.35% APY. Assuming a 10% tax rate on the interest and no deductions to offset it, that's an effective after-tax yield of around 4.815% in a simple, insured form that terminates after a year, and the banks will be there to take your call today, Monday, or whenever you are ready.

To recap, the best case for I Bonds is a 4.365% return... the worst case for a simple 1-year CD considering 10% tax overhead is 4.815%, and the worst case for T bills is 4.919% (give or take a few small decimals).

There is no reason at all to buy I Bond right now considering the looming rate reduction. Even those investors who want to stay in Fed securities would be better off moving into T bills or CDs for the near term, then revisiting the I Bond situation in October when the Consumer Price Index that drives the November variable rate will be known. For a tax-advantaged account such as an IRA, the interest rate is all that matters, so CDs make even more sense than T Bills or Bonds, if your IRA custodian offers high-rate CDs.

I think the Fed will raise the fixed rate at least a little to get it off the 1.00% mark where it's been stuck for more than a year. They can't sell this product if it's only earning 2.0%, and the fixed rate is totally at the Fed's discretion. In the past it has dropped as much as 1.00% from one 6-month period to the next. And the fixed rate has not been bumped up since the Fed's interest rate increases began... it's overdue.

Repeating... explore alternatives... take a deep breath... no need to rush into anything...

EXAMPLES, rounded generously

I Bond purchased April 27, 2006:
$10,000 @ 6.73% for 6 months (April-Sept) = $340
$10,340 @ 2.00% for 6 months (Oct-March 2007) = $110
Total for first year: $10,450
If rates don't increase, you'd want to sell this bond
Penalty for selling after 1 year: $55 (last 3 months' interest)
Net after 1 year: $10,395 (Sell) to $10,450 (hold) free of state and local taxes

Certificate of Deposit, 1 year at 5.30% APY
$10,000 @ 5.30% = $10,530
10% taxes = $105
Net after 1 year: $10,425 after 10% state and local taxes

T Bill (using 4.919% rate from April 24 for 6 months, and guessing 4.5% worst case for the 2nd six months)
$10,000 @ 4.919% for 6 months = $246
$10,246 @ 4.500% for 6 months = $231
Net after 1 year: $10,477 free of state and local taxes

Process: insecurity in Internet email-to-fax services

2006-04-05T09:44:00.000-04:00

(This has also been submitted to Risks Digest and may appear there in edited form).

Dallman Ross (RISKS-24.23) wrote about the possibility of "Joe-jobbing" someone via the email-to-fax services that only authenticate the e-mail "from" address when sending (expensive) faxes.

The risks appear to be mitigated such that real financial damage to a target is impractical, but the devil is in the details as I've just confirmed in examination of a large fax/voicemail service:

- This service (and JFax as well) once offered concerned customers (me) the option to place a text password inline at the top of the email body, eg: {password="SendMyFax007"}. However, I noticed the password string sometimes leaked into the sent message, and its absence didn't always prevent a message going out. This "feature" doesn't seem to be publicly documented and was never user-configurable. I don't know if it's still available.

- The service under study this morning seems to update its authentications after a huge delay, if at all. I removed all references to an account's formerly authorized email address via the web page at 8:14am and replaced it with another. At 9:17am the service is still sending faxes received from the deleted e-mail address. So, even removing a compromised address doesn't stop the attack immediately. Inexplicably, it's referencing a "free trial account" now (the account was started as a free trial years ago). But it's charging the faxes against a real account, and logging them there.

- The services top-up a debit balance held at the service, then run it down before charging the credit card again. If you keep a low refill amount, this would throttle an attack, but the victim remains dependent on the company to "do the right thing" to reimburse.

- There is no way to stop faxes going out, and no way to remove stored credit card data or to stop the auto-charging of same. Attempts to erase credit card details yield a "you have entered an invalid credit card number" error. The service's contract requires that it be allowed to store credit cards and auto-charge both fixed monthly fees and per-use fees.

- The company cannot be easily reached by telephone, even in an emergency.

- The service allows account holders to disable notification of sent faxes. Presumably large account holders (those topping up with $100 or $250 per occurrence) thus wouldn't learn about an attack quickly. Thus the most valuable accounts (with high balances) are perhaps the least likely to catch an attack quickly.

- The service allows broadcast faxing on approved accounts, the fax equivalent of a spam relay.

I discussed these risks in 2002 with an architect of JFax, who is also a principal at another fax service. His (anonymized) comments below shed some light on their reasoning. He, and JFax before, considered this design necessary and reasonable given the limitations of both technology and customers. He's troublingly confident about the utility of "tracing an email back to where it came from" as a means of solving the problem.

Quote from fax service architect, Feb. 20, 2002:
"Yes, we've been through this one about a thousand times in the past. When we started (the service) back in 1996, we used to make the sender place their customer ID and password in the subject line of the email. We lost a lot of business because most folks could never figure out how to send a fax.

"We do send a confirmation to your email address every time a fax is sent on your behalf, so if someone is scamming your account, you should know fairly quickly. Please inform us immediately and we'll credit your account and trace the mail trail back to find out where the email came from.

"This is a small risk that we have to face in order to do business in our market. Fortunately it hasn't been too big a problem (stolen credit cards seems to be a much more real issue for us to deal with). In my dealings with J2 (JFax)... I learned that they really hadn't had any issues with this type of issue either. We'll keep our eyes open though."