2006-01-16

Florida Bar Takes Preliminary Position on Metadata Mining

As reported in the Florida Bar News:

"The Bar Board of Governors is asking whether an ethics opinion or Bar rule is needed to reguylate mining of metadata from electronic documents. The Florida Bar has taken the preliminary position that the mining of metadata from a digital data file constitutes unethical behavior, but in the meantime, governors didn't want to leave any doubt how they felt about it.

The Board, at its December 16 meeting in Amelia Island, voted unanimously for a motion to express its sentiment that metadata mining is something lawyers should not do.

'I have no doubt that anyone who receives a document and mines it...is unethical, unprofessional, and un-everything else', said member Jake Schickel, who made the motion that the board express its disapproval at the practice"

Florida's effort to address metadata is laudable. In fact, I think it is a jurisdictional first, and shows the forward thinking attitude of the Florida Bench and Bar.

However, the issues surrounding metadata are complex. They begin with definitional and semantic challenges (which change depending upon with whom you talk) and continue into obligations of data generators, data recipients, as well as discovery issues. Metadata can and does contain source information, authentication informatio (timestamps and digital signatures) as well otherwise potentially discoverable information. Standards authored by ANSI address the use of digital signatures and timestamps for electronic data used in the financial world. Certainly, if these digital signatures were embedded in metadata, the legitimate discovery of a litigant, or a regulatory authority, could be thwarted, and serve ends not intended by a Bar position against metadata examination. Indeed, it could be argued that information supporting an assertion of fact may only source from metadata. Another interesting question is whether, in a Federal Court matter, it might be argued the Federal Rules of Civil Procedure present a direct conflict with any proposed prohibition on the search for and use of metadata.

Imo, a sticky wicket, but one that begs at least a "college try" to set guidelines for the practitioner as well as for the Bar.

Link to the article: http://www.floridabar.org/DIVCOM/JN/JNNews01.nsf/cb53c80c8fabd49d85256b5900678f6c/c3f75b4e10e94f78852570e50051b23e?OpenDocument&Highlight=0,metadata*

2006-01-09

Software Liability Laws from an Alternate Universe...

I wrote this nearly one year ago, and decided not to post at the time. In light of recent events, including the refusal of a Breath-a-lyzer appliance manufacturer to provide source code as required by law, I will now step out on a limb, probably really annoy some people, maybe everyone and post...

Steven

The ten alternate by-laws:

1. If your operating system cannot either detect or prevent a bad guy from running his program on your computer, it is badly written, and you've purchased defective software.

2. If operating system software requires monthly patches in order to correct security issues identified by former (and current) bad guys, you've purchased defective software.

3. If operating system software contains no native anti-virus or other malware prevention features in its fourth of fifth iteration in fifteen or twenty years, you've purchased defective software.

4. Talking about trustworthy computing at trade shows does not make defective software non-defective. Or trustworthy.

5. If operating system software is designed so that popular anti-virus and anti-malware programs can't be installed with crashing the operating system, you've purchased defective software.

6. Grafting an internet browser to an operating system is like grafting a leg onto your head.

7. Creating an impression that walking around with a leg grafted onto your head makes you run better does not make you run better.

8. If an operating system is defective and subject to an exploit in a computer at home, it is more than likely to be equally defective and subject to same when ported to a mobile device.

9. Case hardening defective operating system software in a FIPS enclosure does not make the operating system software non-defective, but it probably does a great job at protecting defective software.

10. A thirty day programming hiatus is never sufficient to correct security vulnerabilities in various operating systems containing millions of lines of code.

2006-01-04

MS Deletes Chinese Dissident Blog from MSN Spaces

Odd. A site hosted (I think) in the United States must comply with Chinese law. Interesting theory, with even more interesting ramifications. Now, if "local laws required the stoning of purveyors of sex-oriented blogs I wonder if there would be such a rush to comply...

Cnet headline: "Microsoft has admitted to removing the blog of an outspoken Chinese journalist from its MSN Spaces site, citing its policy of adhering to local laws"

"...A Microsoft representative told ZDNet UK on Wednesday that it blocked Anti's MSN Space blog to help ensure that the service complied with local laws in China. "

And the link: http://news.com.com/Microsoft+censors+Chinese+blogger/2100-1028_3-6017540.html?tag=nefd.top

Third Party Windows wmf Exploit Patch Made Available

Ilfak Guilfanov (the author of the patch) may be a nice guy, a capable programmer, and perhaps even a local hero. I'm not certain if I would install a patch into an OS that didn't come from the OS vendor. Of course, as of the time of this post, there is none, millions of computers are exposed, and aye, that's the rub.

This is different from 1980-1995, where the OS was relatively simple, DOS didn't have memory management or disk management (such as defrag) capabilities, and third party manufacturers such as Quarterdeck and Central Point (RIP) provided same. Indeed if a system file became corrupt, one could always reinstall pieces of or the entire operating system, quickly and painlessly, without necessity for 'net connection or authentication. Keep a copy of one's latest config.sys or autoxec.bat, even your command.com or win.ini files, and a simple copy over usually fixed most problems.

At that time, there were no high expectations that DOS was meant to really work without ever crashing, and most security problems arose from inserting infected floppy disks from friends, children, or employees with both. Certainly also at that time the expectation was that there could be no liability for such unstable platforms, because *everyone* knew that they were unstable, and used them nonetheless.

And so, for the early years of DOS, I label using these early OS's as an assumption of risk. MS has had twenty years of Wwindows and DOS programming experience to get security right, and I think that an "assumption of risk" approach is no longer applicable. On the other side of the argument, is there now some sort of "mitigation of risk" approach that might be used as (1) a shield when MS claims that the use of an authorized patch insulates it from liability, or "voids" any warranties or reps or (2) as a sword when attempting to obtain equitable relief? This is not like the situation where HP will disclaim a warranty when one uses a non-HP printer cartridge in an HP product. The product tend to work in the first instance, and third party products are provided as a cost saving measure only.

The problem with the operating system is now is that the problem *is* the operating system. All the PR, "trustworthy computing" articles, "crisis rooms" and "scientists" and "visions of the future" won't ameliorate that problem unless real, constructive action is taken. I find it discomfiting that a garage-level programming operation (no disrespect intended) has issued a patch for a critical flaw before MS can get its arms around it sufficient to provide its paying customers with secure and trusted (I consider the term "trustworthy" a semantic nullity) computing systems.

What's old is new again.

The link to the SANS Internet Storm Center article: http://isc.sans.org/diary.php?storyid=996

S