

Mork keeps on giving: When the database worms eat into your murder trial - bartonfink
http://www.jwz.org/blog/2011/07/mork-keeps-on-giving-when-the-database-worms-eat-into-your-murder-trial/

======
raganwald
I'm confused by why JWZ says that the Mork database code has anything to do
with killing people. It is not presented as a product to be used for the
collection of forensic evidence. Every user agrees to terms of use that
suggest it is not a mission-critical piece of software to be used for sending
a manned mission to mars or saving the location of your buried ingots of gold.

Relying on its data to convict someone of a capital offense says more about
the justice system then it does about the software, and if an alleged killer
should go free because of its unreliability, that says more about the
inability of the police to gather sound evidence than about the inability of
its programmers to build software for the unstated requirement that it catch
criminals.

~~~
allwein
>I'm confused by why JWZ says that the Mork database code has anything to do
with killing people.

Here's the progression of thoughts.

1) Messed up database format is difficult to decipher.

2) Difficulty in deciphering the format, leads a forensic analyst to
mistakenly conclude that the site was visited 84 times instead of just once.

3) Assume that Jury reaches conclusion that Casey Anthony killed her daughter
using chloroform. Thus the choice is then whether it was simple manslaughter
and she gets a few years in prison, or it was premeditated murder, and thus
eligible for the death penalty.

4) Since the suspect visited the site 84 times, this helps lead to the jury
concluding that the killing was premeditated murder, and thus Casey Anthony
should be put to death.

5) Thus, as the result of a bad database format, someone was put to death
instead of just serving a few years in jail.

~~~
raganwald
I agree with your analysis of the argument being presented, however I disagree
with the argument itself.

1) Street light burns out but hasn't been replaced yet, making street dim

2) Dim lighting leads bystander to mistakenly conclude that accused was
present at scene of crime

...

5) Thus, for the want of a light bulb, someone is put to death.

My contention is that it is a failing of the process for the Jury to reach the
conclusion based on a forensic analyst's mistake. I'm not an expert on
courtroom proceedings, but I certainly hope that if I am ever asked to give
expert testimony in court, I will not look the jury in the eye and claim in
loud, ringing tones that I am 100% confident of my findings when spelunking
through a database format I didn't write that was written by code I haven't
examined line by line.

If I was foolish enough to make claims like this, I hope someone would cross-
examine me properly. I hope that someone, somewhere would suggest that there
might be any number of reasons why the word "chloroform" might appear on the
hard disk in that spot and give alternate explanations. And so on, and so
forth.

If people are being sent to Death Row based on what looks to me like
incredibly scanty evidence, I don't think the scanty evidence is the problem,
I think the process for evaluating evidence is the problem.

~~~
thisuser
Unfortunately law seems to be one of the most conservative institutions (i.e.
slow to change) in existence. It it set up to be an adversarial system between
two parties, and most of the institutional structure depends upon that.
Between the desire for an adversarial system and constitutional right to trial
by jury, I'm not sure how you can really move away from my expert witness vs
your expert witness when examining evidence for a jury. Any ideas? A
"technical judge" that adjudicates evidence into more explainable forms to be
explained to the jury?

~~~
WettowelReactor
Conservative (risk aversion) and slow to change are not the same thing. By
being slow to change law and lawyers introduce excessive risk in their
offerings which, ironically, makes them negligent at their stated purpose.

------
parfe
Trying to figure out what the original author of Mork was thinking I found
<https://developer.mozilla.org/en/Mork_What_Is_It>

Looks like David McCusker is the original author and it was only supposed to
be a temporary solution that lasted until 2009.

[http://web.archive.org/web/20050315212725/http://erys.org/re...](http://web.archive.org/web/20050315212725/http://erys.org/resume/netscape/netscape.html#mork)
explains mork being an abstraction layer on top of MDB.

Also
[http://web.archive.org/web/20050324235032/http://erys.org/re...](http://web.archive.org/web/20050324235032/http://erys.org/resume/netscape/mork/mork.html)
for some general info linked from the mozilla.org link.

------
ErrantX
Welcome to my job..... and this is only the tip of the iceberg. Mork is one of
many painful "things" that no one seems to be able to produce a decent
forensic tool for :S

------
gwern
Looking at that format, no wonder JWZ had trouble getting a list of recently
visited URLs.

Quite a contrast with the present-day. A few months ago, I wanted to extract
just that information, and despite not knowing a lick of SQL, I still managed
to write a little script which would extract 'all URLs visited in the last
month': <http://www.gwern.net/Archiving%20URLs#local-caching>

