Fairhaven, The River

Asian Market info

This is just so that googler's can find this information.  The New Oriental Supermarket in Littleton MA is open from 10AM to 8PM seven days per week.

They are the typical low budget asian market, with no web site.  It has the usual shelves of dried fungus, more shelves of dried stuff you can't recognize that is labeled only in Chinese.  Several refrigerated units have recognizable and unrecognizable fresh vegetables.  There is an aisle of various kinds of noodles and all sorts of rice.  Several freezer cases are full of prepared dumplings, stuffed rolls, etc.

This will maybe save a few people phone calls or wasted trips.

The latest in sailboats

I noticed this nice writeup on the early experiences with the Beluga Skysails.  It gives some real numbers, like a 10% reduction in fuel use for the ship, and a realistic report on how the highly risk averse maritime industry evaluates and reacts to a radically new technology.  Kudos to the US Navy for supporting this effort with their long term contract to use the ship.  They understand that it takes several years of genuine operational experience to settle in a technology.  (At least in this case.  The USN overall track record is a lot shakier.)  A few more years and some higher fuel prices may see more of these ships be launched or retro-fitted.  The retro-fit alternative is one thing that makes this technology interesting.  It reduces the capital investments needed.

The cover page has a better picture.  The photo in the article is some heavily photoshopped composite.  I've seen the real ship carrying the real wind turbines, and it did not look like that at all.  They did go for a symbolic use of a sail assisted ship carrying wind turbine on it's first commercial voyage.  But it was only turbine blades above decks.

Paper Recycling

The 2008 figures for paper recycling in the US are out.  The impact of a full year of recession is a decrease in per capita paper utilization, but no drop in the recycling trend.  Since the 1970's the trend has been an increase of about 0.75% per year in recycling content.  The recession did not interfere.  2008 saw an overall 57% recycling rate.  The US remains on target for the goal of 60% by 2013.

Next year will need examining also.  The municipal recycling efforts are much harder to subsidize than before.  Revenues from all sources are down.  But recycling is still less expensive per ton than trash disposal.   It's tougher for towns to use revenue to cover collection costs, but most towns realize that pushing recycling efforts is still a cost reducer.  If the word gets out to the public properly, the percentage improvement should hold.

I saw the latest figures for some of the local paper collecting bins.  The net income is pennies per ton.  The best money is from corrugated boxboard.  It gets both repeat use as boxes and excellent recycling yield.   Our town curbside collection contract is a mixed contract covering containers and paper with no further breakdown.  We pay for each ton collected, but it's about $50 less per ton than the regular trash disposal.

Encrypted Disks

The May CACM has an article on recovering passwords from RAM and using that to break protection on encrypted hard disks.  It remains crucial to decide what risks you have and what the real threat is.  DICOM just approved the standards for using password protection on removable media.  (It already had PKI based encryption covered, but in practice the password based in far more usable.  With suitable precautions it is probably just as robust against the real threats.)  It protects reasonably well against exposure through media theft, but only with the assumption that the passphrase is well protected.  If you write the passphrase on the media, you eliminate most of the protections.

My risk analysis based on their work is this:

1. If you are personally a target, all current disk encryption methods will be breached.  You might be a personal target through criminal activity, military activity, political activity, etc.  Disk encryption is not protection for you.
2. If you are a target of opportunity, disk encryption alone can be breached.  Actually, some techniques like the default TPM and basic Bitlocker of Vista reduce your protection because they fool you into thinking that you are protected, while in fact you are not.  Most people are a target of opportunity.  If a thief steals your laptop and thinks - "I wonder if there are any worthwhile secrets on this thing?" you just became a target.
3. If you are worried about parts depot repair, recycling, re-sale, etc. then current disk encryption is usually good protection.  Just make sure to shut down a few hours before handing over the system, or make sure that they remove the disk and are not left alone to play with the system.  Of course erasing the disk is even better if you know that the disk will be sold or re-used.

The problem is that at room temperature the RAM bits take too long to zero.  There is ample time for someone to reboot the system using either USB boot or PXE boot and copy out the contents of RAM.  You need to be power off for 30+ minutes before there is much confidence that data will not be recoverable.  They did the proof by implementation that automated RAM scanners can find passwords and break in to all of the popular open source and proprietary disk encryption systems.  The keys are right there.  (If you use TPM and basic Vista bitlocker, you can have power off forever and still get the keys.  The keys are in non-volatile RAM.  Bitlocker users should use one of the more advanced modes.  Microsoft should remove the basic mode.)

In practice there is also the extremely serious problem that laptops are basically left on all the time, although for power reasons they may be in standby or hibernate modes.  This is because it takes too long to boot, and it takes too long to restore user context.   One of the reasons that I and others like the Mac is that you can just close the lid and it goes to sleep within seconds (and nothing breaks).  You can restore operation by opening the lid, and again it is ready within seconds.   You can configure it to ask for a password, but the keys are not scrubbed from memory, so a sleeping system can be stolen and keys retrieved.

If boot were really fast (through techniques like saved context information on disk), the memory (or at least keys)  scrubbed on sleep/shutdown, then systems might be somewhat secure.

Something to think about when protecting information from opportunistic theft.

Pace Layering and standards

Pace layering is a concept that I first saw in Brand's book "How  Buildings Learn."  The concept is that there are different layers of organization and structure that evolve at different paces.  In a building I might have:

1. My desktop, where contents are re-organized hourly or even more often
2. The equipment layout, which changes every few weeks
3. The cubicle walls and furniture, whose layout changes a few times per year.
4. The internal walls, which only change every few years or longer.
5. The building envelope and infrastructure core (plumbing, etc.) that change every decade or two.
6. The multi-structural components (like electrical outlets) that very rarely change their design.

These layers are in a constructive learning tension.  I am limited by the interior walls.  They constrain the available cubicle and furniture placements.  They also support the workflow, privacy, and operations.  I may complain that I want a wall or door moved.  If it is important enough, this may happen, but it will be at a different pace than my furniture layout changes.

This same situation is present in standards.  The building example has standards at several layers.  The cubicle maker has standard heights, shapes, and possible layouts.  These are moderately ephemeral, changing as models change.  They are somewhat multi-vendor, but that is not well coordinated.  The electrical outlets are extremely stable and very restrictive, with uniform implementation by every vendor of electrical outlets.

You need to think about the pace levels of your problem space when working on standards.  Putting a standard at the wrong pace level is a serious problem.  So it is important to consider the stability of the problem space, the process and speed of standardization, and other pace related characteristics.  You need to ruthlessly separate items that are at different pace levels.  The standards process for something that changes rapidly (like furniture layouts) must be very different than that for something that changes slowly (like building walls).  Mixing the two may be tempting from an organizational perspective, but it is a bad idea.

Creating this separation will lead to some difficult and emotional conflicts.  Excluding something "important" because it is at a different pace level creates difficulties.  The use of terms like levels helps, because the excluded work is at least recognized.  But telling the advocates to go find another home can still be very difficult.  There will also be strong process conflicts.  The rapid, informal, error tolerant process appropriate for furniture layout is much easier than the slow rigorous process needed for changing the building envelope.  People working on the envelope will be tempted to take shortcuts that are not appropriate, especially if they also are working on furniture layout problems.

The rapid pace may be envious of the "power" that the slow paced standards have.  There is a temptation to seize the power that the envelope standards have to control and limit the available furniture layouts.  But furniture layouts should not be subject to the kind of strict controls that are appropriate for a building envelope.

There is no simple easy answer.  But proper consideration of pace levels is critical when defining the scope of new standards efforts.

(Why am I thinking of this now?  The current HITSP effort needs to think about pace leveling, and I was just reminded of Brand's book because I found it while cleaning up my office area.)

Heating Season Assessment

This winter's heating season is about finished.  I did my assessment of how changes have affected my home energy use.  In summary:

• Heating consumption reduced about 20%
• Electricity consumption reduced about 130W

Electricity

The Kill a Watt has definitely paid for itself.  I went around doing various measurements and made decisions based on measurements.  There were three surprises to me:

1. The inkjet printer consumes almost 10W when sitting idle.  This is much more than I expected, given its energy star rating.  When I re-read the energy star regulation I found it requires an idle consumption of under 10W, which the printer does just barely meet.  So I changed my habits to turn off the printer whenever I pick up printed results or finish scanning. This is not much extra work.  If I forget, it doesn't matter much, I just turn it off when I notice. 
2. Ethernet hubs consume 10-15W.  That was more than I expected.  I did some re-cabling and built one crossover cable to eliminate the need for one hub.
3. My wireless telephone consumes 20W.  I haven't replaced it yet.  I could replace it and the remote with a DECT phone that consumes 5W.  This would save $15/yr and cost about $60.  My delay makes me a typical consumer.  An ROI of 25% does not inspire a purchase.

No surprise was the benefit from consolidating an internal server and the need to put TV and DVD on a powerstrip for an easy on/off.  Doing all this has a net savings of about 130W based on electricity bills.  This is a savings of $200/yr.

I have already shifted lights to CFLs, so it's getting harder to cut much more without some substantial changes.  The next thing that I could do is replace an old PC (233 MHz Pentium) that acts as my general proxy server for scrubbing ads, filtering traffic, email fetching, etc.  It's a matter of lots of software reconfiguring.  I don't feel like putting in all that time to save about $50/yr.

Heating

This was based on degree days and oil usage in gallons.  I saved about 20% through two major steps:

1. An aggressive effort with caulk and plastic to weatherstrip and seal windows, etc.  Having done all that I also got enough improvement that I have figured out remaining things to tackle.
2. A questionable mechanical thermostat was replaced with an electronic setback thermostat.  I think the old one was not working properly.  The automatic setback didn't seem to be effective.  The new one definitely works. 

Short of major home construction changes like opening up walls to re-insulate, I probably won't get more than another 10%.  From an ROI perspective I've gotten most of the easy changes.  The heating system is already measured at 85% system efficiency.  That's as high as you get with heating oil and normal systems. 

Media Passphrases in DICOM

There is an issue regarding how DICOM should specify the use of a pass phrase as part of the addition of pass phrase based media encryption.  This discusses the issues and my current recommendations.

Meta-discussion (DICOM Philosophy)

DICOM provides a complete interoperability specification.  It does not leave out critical components.  But, DICOM does not want to re-invent wheels.  For example, DICOM devotes several pages to precisely specify the use of TCP/IP and several pages to how DICOM conformance statements will document the use of network options.

There are issues surrounding the pass phrases for media encryption that need some degree of specification.

Scope and Assumptions

I will assume that the users are able to convey the pass phrase somehow, most likely orally or in some printed form.  They can deal with issues of proper spelling, capitalization, writing system, etc.   An example of writing system selection is conveying whether the hanzi are in traditional or simplified form.  All of these can affect the use of a pass phrase as an encryption key.  Users will understand this and be able to convey this kind of information.

The problem arises because the RFC specifies how the byte sequence of the pass phrase is processed to create the encryption key.  The RFC does not specify the relationship between the byte sequence and the user conveyed pass phrase.

I believe that DICOM must specify this relationship and might give guidance regarding some of the operational pass phrase issues.

Issues

Encoding Systems

In China computer systems utilize Big5, GB2312, GBK, GB18030, and Unicode.  Internally the Unicode systems might use UTF-8, UTF-16, UTF-32, UCS-2, or UCS-4 encoding.  There are similar internal variants for GB18030.   So there are more than ten possible byte sequences that might be used internally to represent the exact same pass phrase.  With the exception of GB2312, GBK, and GB18030 using UTF-8 these will be different for a passphrase using normal Chinese and latin characters. 

Similar issues arise around the world with the mixture of ISO 2022 and 5 possible Unicode encodings.   The only major world segment where this is a lesser issue is in the English speaking countries.  The latin alphabet is encoded the same way for ISO IR-6 in ISO 2022, ASCI, Big5, GB2312, etc.  The issue of Unicode internal coding does remain a potential problem for the latin alphabet.

Unicode (and GB18030) specific issues

There are some further issues that are unique to Unicode and GB18030.  GB18030 inherits these issues from Unicode, so for the rest of this I will just refer to Unicode terminology. 

Composing Characters and related issues

Many languages have accented and modified characters.  Unicode includes some code points for pre-composed characters such as an accented "e".  These characters can also be represented by two composing characters: an "e" and an accent.  These will have two different byte sequences.  The Unicode report TR-15 discusses the issues of composing characters in much more detail.  Composing characters matter for string comparison, hash codes, and other computer functions.

The W3C, IHE, and others have recommended the use of Normalized Form C (NFC) from TR-15.  DICOM will need to specify the normalization in order to get consistent byte sequences for pass phrases.  NFC is the appropriate form to use.

Composing Languages

Some languages, like Thai, have no pre-composed characterset available.  For this kind of language there are language specific rules regarding the proper ordering of the code points used to compose the final representation.

Multi-lingual use

Many media exchanges will be among systems that all support the same language; but, there will also be exchanges that cross language boundaries. Issues that will arise when this happens include:

• homotypes - One example is the  Serbian "dot-less i".  This is a different code point than the composing dot-less i.  It is nearly impossible to tell these two apart visually, and in many fonts the two are identical.  A system configured for Serbian will use the Serbian character.  A typical configuration for other European languages is to use the composing dot-less i.  Data exchange between Serbian and non-Serbian systems will fail mysteriously.  It is not reasonable for users to recognize this kind of problem.

            Many of the punctuation marks, space characters, dashes, etc. are also homotypes.

• Ad hoc solutions - Enterprising users will try to use available alternative data entry systems for unsupported character sets.  For example, Greek may be entered by using the local equation support.  But some of the mathematical characters that look like the Greek characters are different code points.  These are not true homotypes because the characters do look somewhat different.  This difference is subtle and is likely not noticed by the users.
• Complete failure - There will be many system - language combinations that simply do not work.  It is not practical to enter any of the composing writing systems (like Thai) on a system that lacks data entry support for that language.

My Recommendations

It is not reasonable to expect users to know how their characters are encoded internally.  Only the software developers know what internal coding system is used and what byte sequence is provided to the encryption algorithm.

DICOM must specify the byte encoding algorithm to be used for encryption.  I would require that it be Unicode text in normalization form C encoded using a minimum length UTF-8 encoding.  This is regardless of the local system internal encoding preferences or language support.

We need proper wording to explain why this matters and that this is a requirement for defining the byte sequence used to generate the encryption key, not a requirement on the user interface.

The multi-lingual issues, and the need to support archival uses, also drive the need for an option that does constrain the user interface somewhat.  All of the encoding systems support the latin alphabet (ISO IR-6).  DICOM has mandated that at a minimum, any DICOM conformant system must support the latin alphabet.  (For those not accustomed to the jargon, ASCII is an encoding of the latin alphabet.)

DICOM should specify a pass phrase interface option that restricts the pass phrase to use only characters in the latin alphabet.  This option can then be used when describing a particular piece of media.  The name "International Latin pass phrase" could be used to describe a software capability as well.  The users can then specify that they want media with an "international latin pass phrase" when they need to ensure that any DICOM compliant system be able to process the encrypted media.

Medical standards and leap seconds (aka Navigators vs Doctors)

Previously:

Leap Seconds
State of the Standards
What Matters When measuring
The UNIX-NTP real world compromise
What about SNTP (e.g., Windows)
What's wrong with the UNIX-NTP compromise?
What else is wrong with the compromise
What should medicine do about leap seconds? (First thoughts)

Steve Allen's comment about navigators helped me reach a proposal for what standards need to do about leap seconds for medical records.

Navigators understand their use of time and have a degree of control.  Doctors do not.

• Navigators understand how time affects their work.  Doctors do not.  Doctors understand human physiology, pathology, etc.  Time became relevent only when machines were introduced.  Time is just an engineering issue to doctors, so they point to the engineers and say "fix it."
• Navigators can make appropriate feature and quality tradeoffs for timing systems.  Doctors and hospitals cannot do much.  This is partly due to the differences in understanding and training.  It is also due to differences in safety rules.  Patient safety rules mean that doctors either use a standard pre-qualified product from a vendor (subject to FDA rules) or they use an experimental modified product (subject to internal IRB review).  It is immensely easier to use standard pre-qualified product.  The time and expense of IRB review and tracking is justifiable for medical trials.  It is rarely justified for other uses.
• Purchase and configuration decisions are based on the primary medical characteristics.  Time related issues are just an engineering detail to be fixed.

The challenge for medical standard is to provide recommendations that reflect these differences.  The standard products need to be usable in the real world when they comply with the standards recommendations.

1. They must be fully functional when added to the existing mess of good and bad implementations that are found in hospitals. Hospitals will not scrap all their existing equipment.  At most, they will be willing to reconfigure it.
2. The standards must be something that can be followed blindly.  The engineers are able to understand all these issues, but engineering resources are limited.  Product management wants the engineers to spend their time on improving the medical features.  So, to be widely accepted the standard must not require much thought to inplement.
3. The standards must withstand the well meaning bad advice that will be given and found in regulation and SOPs. There will be a lot of well meaning bad advice that is appropriate for very different situations.  This means both that the recommendations must be unambiguous and simple, and that there must be tutorials or informative material to explain the tradeoffs and reasons behind the choices.

I think that some form of the Unix-NTP compromise is appropriate.  The existing systems are a mix.  Some will both accept and generate leap seconds.  Some will accept but not generate.  Some will neither accept or generate leap seconds.  Fortunately, medicine does not need highly accurate time.  The administrative uses can accept large errors, in what I call administrative scope.  The operating rooms need close synchronization within their scope, but are otherwise like administrative uses.

One well meaning mistake is attempting to make the entire hospital an operating system scope.  This is impractical.  It would mean that every Windows system would need customized drivers and networking to support NTP, IRIG, or something similar.  This is a complete waste of time and money.  Receptionists, heating controls, and other administrative systems have no use for this added accuracy.  It is far less expensive to just maintain accurate synchronization within each operating room on a per operating room basis.  The only step needed is to hammer home to the administrative software developers that they must accept the occasional time jump and mis-synchronization of a few seconds.  That's just the nature of SNTP on Windows.  It does no harm for administrative purposes as long as the administrative software is properly written.

Another well meaning mistake is attempting to make the operating system scope closely synchronized with an external time base.  There is no medical need for this.  It introduces a lot of problems if you insist on putting leap seconds into the closely synchronized time traces for things like angiography, EKG, sound, and endoscopy series.  Medicine cares about their synchronization.  It doesn't care if they deviate from standard time by a few seconds or even a few minutes.

The compromise of introducing intentional controlled deviations from UTC allows the mixing of systems that do and don't support leap seconds.  The intentional deviation never has leap seconds.  The controlled deviation is compatible with the medical synchronization needs.  With proper software drivers, the controlled deviation is compatible with highly accurate time sources.  (This does eliminate a few products, but most products can be configured to use the unix-ntp compromise.)

So, how to get agreement and promulgate this.

Two cheers for Apple

I'm somewhat disabled by the temporary loss of use of my MacBook, but Apple does do a good job for their customers.  When the battery failed a few months ago the replacement took under a minute.  It was a simple "Still covered by extended care? Yes.  Here's your new battery."   Too many retailers still bury you in paperwork and questions.

Now it suffered an LCD failure.  (Ugly blotches appeared on the screen.)  The "genius" took a quick look at it, said "It's a hardware problem of some sort.", inventory check showed that it will be a few days getting the replacement, so I've got a receipt rather than a laptop.  Again, no fussy questions or paperwork.  The only downside is the wait for its repair.  (They replace the entire LCD side of the clamshell, and didn't have the glossy screens in stock.)

The advice to buy extended care with their laptop is very good. 

What should medicine do about leap seconds? (First thoughts)

Previously:

Leap Seconds
State of the Standards
What Matters When measuring
The UNIX-NTP real world compromise
What about SNTP (e.g., Windows)
What's wrong with the UNIX-NTP compromise?
What else is wrong with the compromise

Wishful thinking:  Just switch to TAI.  (TAI is the basic atomic time used by UTC, but without any of the leap seconds.)   Medicine doesn't care if earth-astronomical times drift slowly away.  Details about sunrise and sunset don't matter.  TAI is simple, well behaved, and entirely appropriate to medicine.

Unpleasant reality:  Pushing all of our ISO/ITU representatives to support the removal of leap seconds is more likely to succeed.  It is easier than dealing with the constant education and explanation issues that would arise if medicine were to just abandon UTC in favor of TAI.  Two industries have succeeded in ignoring UTC.

• Telecommunications (both landline and cellular).  These systems depend upon extremely precise timings among equipment scatter across continents.  Their timing demands are much stricter than anything in medicine.  Introducing leap seconds would have cost a huge amount of engineering, reduced reliability, increased cost, and served no purpose.  So telecommunications networks all use variations on TAI.  They are mostly of the form TAI+n seconds.  Telecommunications has extremely little need to share data with the rest of the world, so they just convert to approximately UTC when necessary for things like billing records.  Many such records are only accurate to the minute, so the conversion is often just roundoff error.
• Global Positioning Satellites (GPS).  Like telecommunications, these have extremely precise timing requirements that pushed the state of the art of atomic clocks.  GPS time is also TAI+n seconds.  Sunrise, sunset, etc.  are irrelevant to GPS.   GPS time is an almost closed system.  If you want to get GPS time, some receivers will provide it.  (Be careful with this.  Many of the low cost receivers have rather high phase errors and jitter.  They were designed for accurate positioning, not accurate timing.)

Medicine has almost constant interactions with non-medical systems at the administrative level.  So while it could act like telecommunications, there would be a lot of potential confusion and explanation needed.

If we can get leap seconds removed from UTC it would eliminate all this explanation and solve our forward looking problem.  Maybe the 2012 efforts will be successful.  The 2003 effort by the US was not sufficiently persuasive.   Increasing numbers of people are understanding that how much more this is beyond a simple "fix your software", and by 2012 we may be willing to watch sunrise and sunset slowly drift in the clock rather than suffer with extensive software design problems.

Unfortunately, standards are only part of the solution.  We have an unpleasant and inescapable legacy problem.  What should we do with all the existing records.  Some are administrative scope, some are operating system scope, many are poorly documented scope, many have timing errors.  This is all part of the growing petabytes of medical record.

Until leap seconds are removed, this will continue to grow at the rate of petabytes per year.

I believe that some variation on the UNIX-NTP compromise will be needed when dealing with all these records.  At least properly implemented DICOM objects provide a UID that identifies their time synchronization source.  This can be used to automate some of the grunt work of correlating and correcting records when necessary.

Next: Medical standards and leap seconds (aka Navigators vs Doctors)