Jeff Jonas

Ironman Australia, 2009 – Misplaced Delusions of Grandeur

Port Macquarie, Australia is a very beautiful place.  The race is well run and the course is excellent – albeit a bit hilly.

The funniest thing happened on the bike.  As I have mentioned before (here) performing math functions in the head while in these races is nearly impossible – even single digit addition.  So get this: I am feeling real strong on the first of three bike loops.  Almost no one has passed me and I am flying.  I look down at my bike computer and see that I am moving along at 22mph at that moment … but have averaged just over 24mph so far!  I was giddy.  I contemplated what it would be like to finish the 112 mile bike leg of the race in well under five hours and how even the pros behind me would be miffed at this performance.  A few minutes later, my speed is still hovering around 22mph yet my average speed was up around 25mph.  How this happened I was not sure … but so it must be as the computer does not lie.  So I continue to quietly chuckle to myself about my extraordinary power.  Soon I see my average speed is almost 27mph.  Now this caused me pause.  It was like a riddle.  How could this be?  Wait a minute … I look closer at my computer and see that this incredible average speed was really “total distance travelled!”  What an idiot.  I flip the computer display over to average speed to find out my real average speed … 19.5 mph!  Ughhh.  This, I must admit, broke my will.  The next 2 hours I coasted a lot and averaged about 16mph.  What a loser.

Here a new swim tip for hackers: When you are near the back of the swim you will find some people swimming the breast stroke.  Remember to avoid these folks.  Their frog-style kick can deliver exceptional beatings to your head.  I was reminded about this 2-3 times in the first 20 minutes of this race.  As I reflected on this over the next few miles of swimming, I was quite sure this was karma caused by my inappropriate behavior during the UK Ironman (ref: Kick to Kill).

On the subject of deadly: While driving around we discovered a giant spider (at least 3” leg span) climbing down my window inside the car.  Knowing Australia has lots of deadly critters, I was quite panicked.  The good news is … I was able to use the map to throw the spider out the window.  The bad news is … I threw the map out the window.  Michelle says “Needed map!”

Actual Important Things If You Are Going To This Race

1. Make sure bike has no dirt on it when you land in Australia.  They will check your bike tires at Customs at the airport to see if you are bringing dirt in.  Getting your bike quarantined would be bad.

2. Be prepared for hills on the bike, humidity, and maybe some rain.

3. I recommend you get in the water and swim a bit up the river before race day.  There can be strong currents.  During my test swim (that made my arms sore because I had not swam in months) it took 45 minutes to swim up the river and 15 minutes to swim back down.  Had I not tested the water, this might have spooked me race day.

4. The road is a bit rough in places on the bike course.  And due to the rain, there were a number of folks with flats.  So I swapped out my tires for thicker ones and rode with 110 PSI and had no problem at all.

5. I learned to drive on the left side of the road for the first time.  Although this had always been a fear, this is a great place to learn.

6. Watch for spiders and get two maps.

 

RELATED POSTS:

Hacking the 2008 UK Ironman: Kick to Kill

Malaysia Ironman versus South Africa Ironman – “Tastes like Mango”

Hacking the 2007 Brazil Ironman Triathlon in Florianopolis (May 27, 2007) – Strategy, Tragedy and 100% Pure Agava Tequila

Preparing for the 2007 New Zealand Ironman in Singapore?

Handicapped at the 2006 Arizona Ironman

Surviving the 2006 France Ironman and How Intelligent are Chimpanzees?

Dumb and Dumber: Consequences of the 2006 Silverman Triathlon

What sharks? Reflections on the 2005 Western Australia Ironman

Nation At Risk: Policy Makers Need Better Information to Protect the Country

Last Tuesday, March 10, The Markle Foundation Task Force on National Security in the Information Age released a report titled: Nation At Risk: Policy Makers Need Better Information to Protect the Country. (PDF here)

Members of the Task Force who prepared this report included: William Crowell, Bryan Cunningham, Jim Dempsey, John Gordon, Slade Gorton, Jeff Jonas (me!), Judith Miller, Jeffrey Smith, Abraham Sofaer, Rick White, and Richard Wilhelm.

We made the following five recommendations, calling for the accelerated creation of an information sharing framework:

1. Reaffirm Information Sharing as a Top Priority

2. Make Government Information Discoverable and Accessible to Authorized Users by Increasing the Use of Commercially Available Off-the-Shelf Technology

3. Enhance Security and Privacy Protections to Match the Increased Power of Shared Information

4. Transform the Information Sharing Culture with Metrics and Incentives

5. Empower Users to Drive Information Sharing by Forming Communities of Interest

The report is relatively short and to the point, just 27 pages long. It includes a handy four page appendix summarizing all of the recommendations (pages 22-25).

Here are a few elements I would like to bring to the attention of my readers:

Recommendation 2 speaks to "Discoverability." Our Task Force built on our earlier recommendations (in prior reports) to use data indices – much like the card catalog at the library. Using indices, users can locate data in the enterprise and if qualified for authorized use, they can limit access to the records of relevance. Notably, this model means less data is being transferred around, therefore less data must be kept in synch. The risk of unintended disclosure is mitigated to a degree because fewer copies of data are being made. In short, indices allow users to locate just what they need and no more.

In recommendation 3, the Task Force makes a number of specific security and privacy recommendations. One of my favorite examples is:

"… including implementation of real-time audits of user compliance and behavior and immutable audit logs that record how a system has been used …"

These Immutable Audit Logs are clever little inventions that allow oversight and accountability groups to see exactly how a system has been used. Even a system administrator cannot secretly change the past by altering the log. Imaging every time someone peeks into the card catalog whether they find something, or not, this is recorded in an indelible manner. What cards they saw, what books they looked at, and so on … all accounted for with no way to hide the facts.

The use of the term "metrics" in recommendation 4 is also worth special mention. One such metric the Task Force would like to see is reporting what percent of a system’s information is discoverable i.e., percentage of records that have corresponding cards in the card catalog. Case in point; what is the value of a book on the shelf at the library if there is no related card in the catalog?

Finally, as indices are going to be the way information sharing gets accomplished … in my opinion, the essential policy debate must immediately begin considering the following:

1. How many indices? There are benefits for fewer. And there are different benefits for more. One index for law enforcement and one for intelligence? Or, one index for foreign collections and another for open source? One index, 20 indices, or 100?

2. Where will these indices physically reside? At Google? (Note: Google is an index already used for open source).

3. Which key attributes will be placed in the index? While the library uses subject, title and author … maybe one index will need to contain who, what, where, when.

4. How much latency between data changes in source systems and their corresponding change in the index? For example, if a watch list record is deleted in a source system, what is the maximum amount of time one would want to wait until the same record is redacted from the card catalog?

5. When a user searches the card catalog, who do you notify when an index card is found?

a. Only the inquirer?

b. Only the owner?

c. Both?

d. Neither, only a third party is notified?

e. No one can be told?

6. When there is any notification, what information is revealed about the index card to the inquirer and/or data owner?

a. All the attributes related to the index card?

b. Some of the other attributes on the card (e.g., search author and see title)?

c. No other attributes are revealed?

d. The custodian organization of the data record?

e. The custodian source system of the record?

f. The actual record number used to identify this piece of data in the source system?

g. The user, if any, associated with this record, e.g., the analyst’s name and phone number?

7. When there is a notification to a data owner, what information is revealed about the inquirer?

a. All the attributes related to the search?

b. Some of the other attributes on the search?

c. No other attributes are revealed?

d. The inquirer’s organization?

e. The inquirer’s source system?

f. The actual session number used to initiate the inquirer’s search?

g. The inquirer’s name and phone number?

8. What user audit standards and processes will be required to ensure the system is being used in accordance with law and policy?

9. What metrics will be kept and who can see which metrics?

RELATED POSTS:

Discoverability: The First Information Sharing Principle

Information Sharing: Got Directory?

No Need to "Over Share" – Thoughts on Information Sharing

It’s All About the Librarian! New Paradigms in Enterprise Discovery and Awareness

Federated Discovery vs. Persistent Context – Enterprise Intelligence Requires the Later

Immutable Audit Logs (IAL’s)

Found: An Immutable Audit Log

Full Attribution, Don’t Leave Home Without It

Out-bound Record-level Accountability in Information Sharing Systems

Data Tethering: Managing the Echo

To Anonymize or Not Anonymize, That is the Question

Ontology And Why I Am Not Obsessed With This Fancy Little Overrated Word

I don’t really like using overloaded words like this – words that mean many things to many people. Nonetheless, the subject of “ontology” is worthy of brief mention. 

First, one definition from Dictionary.Com:

Ontology -noun- (computer science) A rigorous and exhaustive organization of some knowledge domain that is usually hierarchical and contains all the relevant entities and their relations.

The main problems I have with spending any energy on pre-constructing well thought out ontologies are two fold: 1) change happens; and 2) there is no such thing as a single version of truth.

While some things are well suited for ontologic declaration like planets, species, currencies, dates and times (a small universe of easy stuff) … many things are not well suited for such pre-defined structural classification (a larger universe of hard stuff) as this leads to non-scalable, non-sustainable, brittle information management systems. No one makes a better case for this than Clay Shirky in this article called: Ontology is Overrated: Categories, Links, and Tags.

My opinionated opinion is therefore: The more difficult the ontologic classification effort, the greater the degree the approach is probably the wrong approach. Conversely, the easier the ontologic classification effort, the more sense this makes to me. Hence, I am leaving ontologies to others as my focus is elsewhere.

What is the preferred model? 

Automated. Untrained. Unguided. Self-organizing.

I think in many cases ontologies are best not pre-defined, more ideally the structures and hierarchies should emerge based on actual use/context. They are not static – they evolve and accumulate over time. They must also support disagreement … which will be sorted out later based on the lens (preferences, biases, etc.) of the viewing entity at a time of need. 

I am hopeful this is the first and last time I have to use the “Ontology” word.

What about the Semantic Web?  DON’T EVEN GET ME STARTED!

 

 

RELATED POSTS:

There Is No Such Thing As A Single Version of Truth

It Turns Out Both Bad Data and a Teaspoon Of Dirt May Be Good For You

Smart Systems Flip-Flop

“Macro Trends: The Privacy and Civil Liberties Consequences … and Comments on Responsible Innovation” – My DHS DPIAC Testimony, September 2008

On Wednesday, September 17th, 2008 I testified before the DHS Data Privacy and Integrity Advisory Committee (DPIAC).  The testimony transcripts were recently posted on the DHS web site.

Transcript Here  (My testimony starts on the bottom of page 9.)

In this testimony I covered a number of topics including:

I. Macro Trends

1. The world is not a more dangerous place – average lifespan continues to increase (More here: The World is Not a More Dangerous Place)

2. Fewer people can create bigger effects faster … in both directions – destruction or value creation (More here: More Death Cheaper in Future, Ludicrous Speed Billionaires)

3. Competition is driving technology adoption – notably the organization who receives the data first has the advantage (More here: Ubiquitous Sensors? You Have Seen Nothing Yet)

4. Data is being created faster than organizations can make sense of it – to this degree organizations are getting dumber (More here: Why Faster Systems Can Make Organizations Dumber Faster)

5. Commingling data for enhanced context will drive a new generation of smarter systems (More here: Smart Systems Flip-Flop)

6. The surveillance society continues to build momentum as consumers find it irresistible (More here: Six Ticks till Midnight: One Plausible Journey from Here to a Total Surveillance Society)

II. Las Vegas: What Can Be Learned

1. Las Vegas is one of the fastest growing cities in the Unites States of America (before the economic crash of course)

2. Casinos have a minimal security and surveillance budget

3. Casinos have a legal obligation, in some circumstances, to determine your identity (e.g., under age gambling, crossing a winnings threshold which necessitates IRS reporting)

4. Public and private watch lists are used – some compulsory, some elective

5. There are a fair number of scams that are tried on casinos – some scam artists are using false identities and disguises (More here: The Vegas Asymmetric Threat, Takin’ Vegas, Be Anyone in Las Vegas, Get Help Creating a Cover Story Here)

6. When employees go bad, this is particularly problematic

7. Most ‘tripwires’ are generated by alert employees who are watching, not by computers

8. An organization called Griffin Investigations provides information sharing of cheaters and advantage players (e.g., card counters) – they system is called Griffin GOLD (My old SRD company build this system)

9. One example of a watch list and insider-threat detection system known as Non-Obvious Relationship Awareness (NORA) was built for the industry (My old SRD company build this system too) (More here: IEEE Spectrum Story: Vegas 911, IEEE Paper: Threat and Fraud Intelligence – Las Vegas Style)

10. A patron can still enter a casino and enjoy a degree of activity without exposing their identity

11. There is no “predictive data mining” to spot unwanted behavior

12. Most vulnerabilities are remedied with processes not additional electronic surveillance

13. Humans are in the security decision loop – computer systems do not make security decisions, rather only promote items of interest

14. Facial recognition technology is not used at doors looking for watch listed persons

III. Towards Responsible Innovation

1. Technologists should more regularly engage the privacy community (More here: Responsible Innovation: Staying Engaged with the Privacy Community) 

2. Information sharing systems must have information attribution (More here: Full Attribution, Don’t Leave Home Without It, Out-bound Record-level Accountability in Information Sharing Systems) 

3. Data destruction requires careful planning and execution (More here: Decommissioning Data: Destruction of Accountability) 

4. Limit data transfers and use indexes to make information discoverable (More here: Discoverability: The First Information Sharing Principle) 

5. If data changes in a source system replicate this change through the information eco system (More here: Data Tethering: Managing the Echo) 

6. Where possible obfuscate data (More here: To Anonymize or Not Anonymize, That is the Question) 

7. Build high assurance accountability into systems (More here: Immutable Audit Logs (IAL’s), Found: An Immutable Audit Log) 

8. Data mining is not always good or bad, it depends on the circumstances (More here: Effective Counter-Terrorism and the Limited Role of Predictive Data Mining, Data Mining, Predicate Triage and NSA Domestic Surveillance) 

9. Link analysis, especially predicate-based, has some usefulness – although it is also wise to ‘prune’ early (More here: Hunting Bad Guys, Phone Records, and a Few Good Dead Men, Predicate-based Link Analysis: A Post 9/11 Analysis (1+1= 13), Sometimes a Big Picture is Worth a 1,000 False Positives) 

10. Low fidelity watch list entries (identities with few attributes, e.g., name only) are problematic (More here: Precision in TSA’s Terrorist Watch List, Comments on the TSA No-Fly and Selectee Watch List Process)

IV. Closing Statements

1. There are going to be more sensors, more data.  This data will be commingled for greater accuracy to serve consumers and to protect countries.  What data is collected and when … will be the debate.  Once data has been collected, the holder has the obligation to make sense of it.

2. The most fundamental principle I have synthesized from my many conversations with folks in the privacy advocacy community is this one point: “Avoid consumer surprise.”  (More here: Where Possible … Avoid Consumer Surprise)

3. Finding professional bad actors involves the detection of weak signal.  The computational remedy for weak signal involves observing and commingling transactions that are unanticipated by the bad actors.

4. Hence the tension.

[End of Testimony] 

I wish I would have also made this point:   

I am concerned.  If organizations don’t start implementing more privacy-enhancing technology I think research and productization in this area will decrease in coming years.  This would be a bad thing. 

RELATED POSTS: 

My Testimony Before The DHS Data Privacy and Integrity Advisory Committee (2005) 

RELATED PAPERS: 

Giannino Bassetti Foundation: Jeff Ubios

Transparency, Privacy and Responsibility: An Interview with Jeff Jonas 

Heritage Foundation: Paul Rosenzweig/Jeff Jonas

Correcting False Positives: Redress and the Watch List Conundrum 

Cato Foundation: Jeff Jonas/Jim Harper

Effective Counterterrorism and the Limited Role of Predictive Data Mining  

Steptoe & Johnson: Stewart Baker

Anonymization, Data-Matching and Privacy: A Case Study  

IEEE Security and Privacy: Jeff Jonas

Threat and Fraud Intelligence: Las Vegas Style 

Santa's Surveillance Operations Center Enjoys Big Gains in 2008(*)

While everyone knows Santa maintains the most invasive, robust, 7x24x365 data surveillance operation in existence against mankind as a whole; nonetheless, far from being called under scrutiny or criticized by privacy advocates, this operations center grew dramatically and saw vast improvements in accuracy throughout the 2008 calendar year.

Santa’s insatiable appetite to know who’s been good and who’s been naughty is the motivatation for doing such a meticulous job collecting and analyzing data on every individual.  As with any surveillance operation there are always a variety of gaps in time for which one cannot account for the behavior and location of an individual.  However this surveillance gap closed to some degree this year.  Jolly lucky for Santa, when certain airlines began refusing cash for in flight sales in lieu of credit cards, Santa’s ability to see that someone had indulged in binge drinking on a flight is now possible.  Other gains in 2008 were seen in many areas including, more phones with GPS and cameras, parking garages only accepting credit cards ... making one’s anonymous presence in that location more difficult. 

Of course, Santa is benevolent.  So, virtually no one has a problem with Santa’s surveillance operation and related data centers.  

Also worthy of mention; the Santa's data governance and overall IT security must be extraordinary as there continue to be zero reports of a breach.   (If there were a breach the operation would have had to make a public disclosure -- as mandated by law -- duh!)

And on an unrelated note, if I were to make a prediction, the notion of giving people who have been naughty a piece of coal in their stocking is possibly a policy that needs to be reconsidered … for obvious reasons.

(*) Forward looking statements contained in this report are opinion only and should not be counted as facts or performance predictions.

RELATED POSTS:

Six Ticks till Midnight: One Plausible Journey from Here to a Total Surveillance Society

Puzzling: How Observations Are Accumulated Into Context

If the goal is to make substantially more sense of data – the only way forward is CONTEXT ACCUMULATION.  

This is so important … I have been feverishly looking for a better way to explain in plain English how real-time, streaming, contextualization works.  The very best analogy I have come up with to date is that of assembling jigsaw puzzles.  The parallels are uncanny.

Puzzling

A pile of puzzle pieces are in a box.  You cannot look at the picture on the cover of the box, as that would be cheating and not like the real world.  

You grab a piece out of the box and look at your table space.  It is the first piece.  So it really does not matter where you place it.  The second piece is now in hand.  Does this relate to the first piece?  Probably not.  So it is placed stand alone elsewhere on the table.  This was an assertion. You decided this second piece is not related to the first piece.  

Soon there are many free standing pieces scattered across the table space - none at this point have been associated (snapped together).  Now you have the next piece in hand, eager to find its mate.  Do you attempt to physically match it with every possible piece in what would be a very brute force and time-consuming manner?  No.  You notice the piece in hand has at least one discriminating feature, some red and white on one of the puzzle edges.  Glancing over the table space you look for pieces with a similar distinguishing feature.  You find three such candidates.  Your attention is now narrowly focused on just these three pieces.

Comparing the piece in hand to the each candidate, you are assessing confidence.  And at the end of this process you have come to a decision point: a new assertion.  It is either (A) a match, (B) not a match but possibly a member of a family of pieces that hopefully will converge as new puzzle pieces arrive, or (C) at this time, has no apparent relation whatsoever to any other pieces.

You only connect two pieces when you are sure.  You would never get out a hammer and force the piece.  In this regard you are favoring the false negative – only connecting the pieces if you have a high degree of certainty.

Let’s say this latest piece finds a match.  You are now sitting there with a new puzzle unit (two pieces).  Looking this new unit over you ask yourself, “Now that I know this, are there some other puzzle pieces that can now be associated to this unit?”  This involves the same process: candidates, confidence, and assertion.  There comes a point where an assertion or set of assertions are made and now it is time to move on to the next piece.

Some pieces produce remarkable epiphanies.  You grab the next piece, which appears to be just some chunk of grass - obviously no big deal.  But wait … you discover this innocuous piece connects the windmill scene to the alligator scene!  This innocent little new piece turned out to be the glue.

You can change the approach, operate on a hunch and become curious.  Sometimes you decide there is an opportunity to resolve some uncertainty.  For example, you have a cluster of pieces all appearing to be related – each having some red and white expressed.  With this new interest in mind you don’t grab the next random piece but rather shuffle through the pieces in the box looking specifically for red and white pieces.  The goal: with the right few pieces this whole portion of the puzzle may resolve.

Luckily you have only been snapping pieces together when you are sure.  Otherwise, your puzzle would be not only a mess but more importantly it would not be evolving towards any degree of clarity.  But no matter how careful you have been … every now and then you grab the next piece out of the box and the home you find for it causes you to realize that two earlier piece should not have been connected at all.  It catches you off guard for a second, but upon closer inspection you realize you stuck these pieces together inappropriately.  Shame, shame.  But luckily, this past error (a false positive) was discovered and corrected – thanks to the new observations.

The puzzle you are working on today happens to be a pretty big puzzle with what appears to be thousands of pieces.  And without the cover of the box you are unsure of its final size (e.g., 1’x 1’ or 3’x 3’, or bigger).  One thing is for sure: you have to leave some space between pieces that do not connect; therefore, you need a table bigger than the final puzzle size.  Notably, after a great deal of work, there is a point when the in-progress puzzle reaches a maximum of required workspace.  After this tipping point, new pieces have a higher likelihood of finding mates and consolidation than not.

As the working space of the puzzle begins to collapse, not only does context become richer, but the computational effort of figuring out where the next piece belongs becomes more efficient despite the fact there are more pieces on the table than ever.  Assertions become faster and more certain. So much so … those last few pieces are as fast and easy as the first few pieces!  [I have seen this behavior in one of my systems … an absolutely phenomenal event with extraordinary ramifications!]

But is it really this easy?  No.

There may be more than one puzzle in the box, some puzzles having nothing to do with others.  There may be duplicate pieces, pieces that disagree with each other, and missing pieces.  Some pieces may have been shredded and are now unusable.  Other pieces are mislabeled and/or are exceptionally well crafted lies.  

Nonetheless, you will never know what you know ... unless you contextualize your observations!

On a Slightly More Technical Level:

1. When I speak of Persistent Context, this is synonymous with the ”work-in progress puzzle” where the net sum of all previous observation and assertions co-exist.

2. Semantic reconciliation (e.g., identity resolution) is but one of several steps of contextualization processing, albeit one of the most important ones that asserts ”same” or ”not same.”

3. Contextualizing observations is entirely dependent on one’s ability to extract and classify features from the observations.  Feature extractors fall woefully short today.  I’ve hinted at what I think will fix this in previous posts and more about this later.

4. Using new observations to correct earlier assertions is an essential property I have been referring to as Sequence Neutrality.  When systems favor the false negative, sequence neutrality most frequently discovers false negatives while the discovery of previous false positives are far and few between.

5. Non training-based, context accumulating systems with sequence neutrality have this behavior: the puzzle can be assembled first pass, without brute force, where the computation cost of the last pieces are as easy as the first pieces, while having no knowledge of what the picture looks like before hand, and regardless of the order in which the pieces are received.

This is what I am working on these days.  It is very exciting and I enjoy talking about such things.  Feel free to comment or email me questions.  I answer every email I get.

MUST READS:

Algorithms At Dead-End: Cannot Squeeze Knowledge Out Of A Pixel

Context: A Must-Have and Thoughts on Getting Some …

Photosynth / Infosynth

Smart Systems Flip-Flop

Federated Discovery vs. Persistent Context – Enterprise Intelligence Requires the Later

To Know Semantic Reconciliation is to Love Semantic Reconciliation

 

OTHER RELATED POSTS:

The Fast Last Puzzle Piece

Entity Resolution Systems vs. Match Merge/Merge Purge/List De-duplication Systems

Accumulating Context: Now or Never 

Big Breakthrough in Performance: Tuning Tips for Incremental Learning Systems

Streaming Analytics vs. Perpetual Analytics (Advantages of Windowless Thinking)

Enterprise Intelligence – My Presentation at the third Annual Web 2.0 Summit

The Triadic Continuum

It’s All About the Librarian! New Paradigms in Enterprise Discovery and Awareness

Intelligent Organizations – Assembling Context and The Proof is in the Chimp!

The Phone Call is Coming From Your House! Context is King

More Data is Better, Proceed With Caution

How to Use a Glue Gun to Catch a Liar

It Turns Out Both Bad Data and a Teaspoon of Dirt May Be Good For You

There Is No Such Thing As A Single Version of Truth

Sequence Neutrality in Information Systems

The Dissenting Numerati

There is a new book out called The Numerati by Stephen Baker.  In a nutshell, this book describes machines that are making sense of more and more data about people. As a result, these machines are making more and more decisions for people.  The “Numerati” are the people who build these machines and their algorithms.

This book brings to light our journey: machines measuring and directing people and how, as this continues to evolve, it will lead to some pretty interesting consequences … good and bad.

Anyway, Baker names names in this book such as Rayid Ghani (Accenture), Josh Gotbaum (Spotlight Analysis), James Schatz (National Security Agency), Eric Dishman (Intel) and a handful of others as Numerati.

I have a bit of a cameo in the book too (pages 131-37, 140-41, 150-53 and a few other mentions).  Also, in this NPR interview (staring at 13:30) Baker describes me as “the dissenting Numerati” which, I still think is a good thing.

And after careful inspection of the references to my work, I must say the author he nailed it.  I love that – as there is nothing worse than something untrue making its way into print.  

Baker did a fantastic job.

RELATED LINKS:

Transparency, Privacy and Responsibility: An Interview with Jeff Jonas

Effective Counterterrorism and the Limited Role of Predictive Data Mining

RELATED POSTS:

Ubiquitous Sensors? You Have Seen Nothing Yet

Responsible Innovation: Designing for Human Rights

Responsible Innovation: Some Things are Best Left Un-invented

Responsible Innovation: Staying Engaged with the Privacy Community

Large Hadron Collider: The End Of The World As We Know It?

If someone asked you in 2007 to estimate the likelihood that Morgan Stanley, WaMu, Countrywide, Merrill Lynch, Wachovia and other titans of financial services would fall to their knees within a year … what odds would you have made?  Might the experts have said “impossible?”

In 2007 I asked a physicist and executive associated with the Large Hadron Collider what the odds were this little black hole they hope to create actually gets out of control (hungry and eats Earth).  The answer: “very unlikely.”

So here is a thought for the day: What if our Earth math and assumptions used to determine “frequency of rare events” in financial markets happens to be the same kind Earth math and assumptions used to determine the risk of playing with black holes?

Wouldn't it be funny if us earthlings never have time to realize all the existing black holes in the universe are really just the residual evidence of other civilizations which had advanced enough to build their own colliders.

D’oh.

On a more serious note … they are looking for yet undiscovered particles that come from the near-light speed collision.  What intrigues me is this: what kind of sensor strategy does one use when one doesn’t know exactly what one is looking for?  That is cool!

RELATED LINKS:

YouTube: end of the world?, the Large Hadron Collider (LHC)

RELATED POSTS:

The World is Not a More Dangerous Place

Hacking the 2008 UK Ironman: Kick to Kill

I completed another full distance triathlon last month.  And consistent with my tradition I barely trained, barely survived, and barely remember what happened.

I’ve organized this blog post into three parts; funny stuff for the casual reader; practical stuff for the Ironman hacker; and finally; specific notes about the UK Ironman.

On the Lighter Side

I was feeling unusually relaxed the night before the race – so relaxed that I decided celebration was in order.  For starters I had two glasses of champagne before dinner.  Then instead of the traditional pre-race pasta dinner I chose the tasting menu with wine pairings.  Five courses and five glasses of wine later, rich sauces, an amazing cheese cart, and a chocolate sundae I was feeling no fear and no pain … oh and frisky too.  Micheeeelleeeee?  Moving right along …

I find myself in my wetsuit before dawn with the other athletes waiting to be escorted to the water the morning of the race after less than three hours of sleep.  I realize that I am already feeling incredibly dehydrated!  Luckily there was some water nearby (on my bike).

Bang.  The gun goes off and 1,200 of us start swimming in the narrow man-made lake.  This was one the most violent swims I have ever experienced.  I got kicked in the ribs, three times in the same place.  I also got kicked in the right eye so hard the swim goggle was trying to suck my eyeball out of its socket.

Even though I try to avoid kicking when I swim (to save my legs for later) there came a point where the bastard behind me was trying to swim right over me.  This went on way too long.  I got a bit fussy.  So I started kicking super hard, mind you, not for speed.  In all honesty, I was trying to cut him in half.

As the athletes left the water, a good number of them littered the shore all cramped up from the cold water.  As I soon discovered I had my own problems.  Apparently, the goggle eyeball suction problem had rendered my right eye inoperable – something I did not notice while swimming.  It would no longer focus – it was like looking through waxed paper.  Everything was so blurry it was difficult maintaining balance after coming out of the water.  I remember thinking this eye problem would wear off shortly.  Nope, I spent the remainder of the race vision impaired.

During the bike leg, there was this one particular moment … roughly 100 miles into the race … I was peddled into the wind.  I was in the easiest gear on a flat section of the course – traveling at times as slow as 4.5 mph.  Shoot me now.

This race took me almost 15 hours – one of my slowest times.

But unlike the rest of the athletes who went back to their room for a good night sleep – nope not me!  I had to speak in Washington DC the next day at 3pm.  So with only two and a half hours of recovery sleep after the race, we got up at 4am and headed to Heathrow for a 7am-ish flight back to the States.

My Newly Discovered Ironman Hacker Tips

I started my distance training five weeks out.  My plan was to avoid any swim training if at all possible, run two hours every other day and get one long bike ride in the week before the race.  My training never goes as planned.  I only got six runs under my belt and maybe four rides.  And on the only day I had available to get in a long ride, I got a flat less than a mile from my house.  I felt lazy.  So I rode the flat tire to Starbucks and called Michelle to come pick me up.

I knowingly violated one of my most important Ironman hacking rules … if you can only be strong at one event … it better be the bike, because it is really important to make sure you get off the bike with some legs left.  Based on this race I would say that this remains a pretty good rule.

I registered the day before the race and decided not to attend the mandatory race brief.  This never seems to matter as most other athletes are willing to tell me (in the middle of the race) things like how many laps and on which side are you supposed to pass on the bike. 

The water was cold (60 degrees) which made it very difficult to move my hands and muster up the energy to get out of my wetsuit.  As usual, I swam with my bike shirt and shorts under the wetsuit.  That turned out to be a bad idea this time.  Luckily, I had packed a diverse wardrobe of options in the “swim to bike” bag.  I put on my arm warmers, a warm long-sleeve cycling jacket and my plastic raincoat (even though it was not raining) in a layering strategy for warmth.  I also put on my full cold weather cycling gloves.

It is hard enough to keep properly fueled in these races when you are not cold.  Add cold weather and you burn calories at a whole new level.  Thirty miles into the race I was so out of energy I was debating if I could make it.  Time to break another rule: never drink Coca Cola until the last two hours of the run.  But in this case, I needed energy immediately.  So I started drinking Coca Cola way ahead of schedule – a smart move otherwise I may not have finished in sub-15 hours. 

Eighty miles into the ride and still freezing my butt off I realized that the water I could see inside my waterproof jacket was evidence that this jacket was preventing me from ever drying off after the swim!  So I pulled over and took the jacket off.   The idea being I had to get colder to get warmer.  Luckily twenty minutes later the water evaporated - I was dry and no longer cold.

I also broke another rule.  Never race in shorts you have never trained in (last time I tried this I was rubbed raw).  But I had to this time!  The day before I left for the race I opened up a package and found a pair of race shorts and shirt sent by the UK Rotary Club.  See … I had made a Rotary donation in order to even get into this race – and they expected me to wear their flag, so to speak.  Anyway, this time running in unfamiliar shorts turned out just fine.  So the rule is now a guideline: it is safest to race in what you train in.

Here are a few other tips:

1. If kicked in goggles and you get negative eye suction, don’t keep swimming with the suction pulling on your eyeball, re-adjust those goggles quickly.

2. If the weather is cold, consider not wearing all your bike gear under the wetsuit.  Take the time to dry off and then put it on dry in T1.

3. If you ingest a lot of alcohol the night before … chase the liquor with lots of water … if you can remember to.

Ironman UK Specific Tips

Ironman UK is one of the more beautiful race courses.

Logistics: If you are going to take a train from London, timing is everything.  Commuter trains get very full.  We were denied entry to the first train due to the size of my bicycle case.  Alternatively, if you think a taxi from London might be a good idea – it ain’t.  We could not even find a London taxi cab driver who knew where Sherborne Castle was and when they figured it where it was – they wanted 400+ pounds for the trip!

We stayed at the Summer Lodge in Evershot.  An amazing place with one of the best restaurants Michelle and I have ever eaten at.  It is so good that without great self-control you will become possessed and screw up your pre-race meal (stay away from the wine pairing menu).  As we had to get back to London at an odd hour we found a local taxi that took us in a mini-van back to Heathrow for a measly 120 pounds!  If you want a local cab and cheap airport service (from or to Heathrow), try these folks:

John’s Airport Travel

Johnstaxi@btopenworld.com

T 01935 472966 – M 07971 656416

Registration: This is a well-organized race.  Not as good as Ironman South Africa but much better than Ironman Malaysia.

The swim: The water in the narrow man-made lake was around 60 degrees.  Everyone was wearing a wetsuit.  Some got in the water then immediately climbed out and quit because it was so damn cold.  For those that passed the first dunk test, you have to swim more than 100 yards (a long way for untrained folks like me) to the starting line and then hover around until the race starts.  If you arrive early to the start you will be waiting around and freezing for 10 or more minutes.  The course is narrow so the good news is you cannot get very far off course.  The bad news is you will get the living daylights beaten out of you – think mosh pit.  At the end of the swim many athletes were cramped up from the cold. As they climbed out of the water, event staff and EMT’s dragged them off to the side of the course and stretched them out.  My girlfriend saw a Japanese athlete stuck in a cramped up gimp position with blue skin being transferred from a rescue boat straight into an ambulance.  Key point: it was cold.

The bike: Undulating hills.  Wind.  Rain.  Cold.  Hot.   Something for everyone and all on the same race day.  Best to prepare and carry enough clothes with you and a plan to cover up for rain, warm up, and cool off as needed.

One bloody dude I chatted with mid-cycling was blown over (crashed) when he was riding along next to a large hedge.  All was well until a gap in the hedge where the left-to-right wind gust took the bloke down.  So be ready for wind.

The run:  Hills.  Dirt.  Mud puddles.  Ankle twisters.  The main thing about the run is that as the day progresses and the sun sets, there are sections of the course where the lights do not provide the necessary coverage.  Be careful not to catch a pothole or tree root and trip.

Also, not all run course toilets are equally maintained so don’t wait for the very last minute to jump in a porta-potty – leave enough time to make it to the next – if the first one is a disaster!

Race photos:  After returning home Michelle found a great digital race photograph of me being offered by Action Sports International for 25 Euros (about US$35).  Then when the email arrived with the link to the photo, it came with this surprise term of use:

“Purchasing a photo, you may not display, transmit, distribute or otherwise exploit the photo, or any portion thereof, in any manner, including, without limitation, electronic reproduction, publication or any display of photographs, without the prior written consent of Action Sports International. Photos are intended for your personal use only. You may not use or reproduce a photo in such a manner as to suggest an affiliation with or endorsement by any product, person or entity that is not affiliated with you. You also agree not to modify, alter or otherwise manipulate any photo, including without limitation, adding other material to a photo, without Action Sports International prior written consent.”

Just great!  I cannot link to the photo or send a copy to friends and family.  When we emailed them and asked permission to show the picture in a Facebook photo album even with credits – they never replied.

What a rip off.  From an ethical and transparency point of view Action Sports should disclose such terms to the buyer before they take your money.  Their current practice is bad behavior.  Buyer beware.

RELATED POSTS: 

Malaysia Ironman versus South Africa Ironman – “Tastes like Mango”

Hacking the 2007 Brazil Ironman Triathlon in Florianopolis (May 27, 2007) – Strategy, Tragedy and 100% Pure Agava Tequila

Preparing for the 2007 New Zealand Ironman in Singapore?

Handicapped at the 2006 Arizona Ironman

Surviving the 2006 France Ironman and How Intelligent are Chimpanzees?

Dumb and Dumber: Consequences of the 2006 Silverman Triathlon

What sharks? Reflections on the 2005 Western Australia Ironman

The Fast Last Puzzle Piece

The notion that the more data, the slower the system – ain’t always true.

My favorite way to explain this very important phenomenon involves the familiar process of assembling a jigsaw puzzle.

The first piece you take out of the box and place on the work surface requires very little computational effort.  The second and third pieces require almost equally insignificant mental effort.  Then as the number of pieces on the table grows the effort to determine where the next piece goes increases as well.  But there is a tipping point where the effort to determine where to place the next piece gets easier and easier … despite the fact the number of puzzle pieces on the table continues to grow.

Well isn’t it interesting, although obvious, that those last few puzzle pieces take nearly as little effort as the first few!

I have witnessed this.   

This has a slew of ramifications.

This does not apply to all domains.  This behavior requires: (a) observations from the same universe; (b) observations with enough features to enable contextualization; (c) observations in which these features can be extracted, enhanced and classified; (d) sufficient saturation of the observational space; and (e) enough smarts to stitch these puzzle pieces together.

Context accumulating systems, fed appropriate observations, can be expected to have this behavior.

 

RELATED POSTS:

More Data is Better, Proceed With Caution

Context: A Must-Have and Thoughts on Getting Some …

To Know Semantic Reconciliation is to Love Semantic Reconciliation

Big Breakthrough in Performance: Tuning Tips for Incremental Learning Systems