Bruce Schneier argues that data is the pollution of the information age, and “just as 100 years ago people ignored pollution in our rush to build the Industrial Age, today we’re ignoring data in our rush to build the Information Age.” ...
Many years ago, I worked for the small town where I grew up. My title was Street Commissioner. This is a very small town, and I was a part time employee with one helper. Basically, I was the guy what fixed things. We had a very old network of water pipes that supplied water from several wells. The water system leaked in many places. Occasionally, a small leak turned into a big leak, and something had to be done about it. You might think that the first response to a big water leak would be to close the water valves in order to isolate the leak and prevent the loss of valuable water. Not so fast! First of all, in an interconnected network that had been upgraded and patched by piecework for many decades, it wasn’t always possible for small localized segments to be isolated, and turning off the water for a large area would inevitably lead to discord. Second, closing even a single valve caused pressures throughout the system to change. Any pressure change anywhere in the system had the potential to cause new failures at weak points, which would just compound the problem. Furthermore, at some point repairs could be counterproductive and completely replacing parts of the network would be the best option. This would require time for the town council to approve the funds, and for contractors to be hired, and for the work to be scheduled and completed – all while the leaking water is causing collateral damage to the roadway and inconveniencing the affected residents with low water pressure. Eventually the big leak had to be repaired, and the water had to be turned off somewhere before the repair could be completed. The decision about where and how to accomplish this was not a simple decision, due to the competing factors involved, and the practical realities a small town is faced with. I call this problem the Petcock Problem. Imagine petcock valves scattered throughout a network of pipes. I call this the Petcock Problem because petcock valves typically have three positions, analogous to the notion of closing, opening, or redirecting connections on the network in order to isolate a fault. The Petcock Problem would apply in many situations involving complex networks, such as when a tree knocks down a power line or when an internet router dies. Sometimes the best solution is to isolate the fault to the most localized part of the network possible, thereby inconveniencing the least number of people at the expense of putting the larger network at greater risk of a much larger catastrophe. Sometimes the best solution is to shut down the entire network temporarily, thereby inconveniencing everybody that relies on the network, but removing any risk of further degradation while repairs are completed. Most of the time the best solution is somewhere in between these extremes. As the network ages and faults become more commonplace, at some point the best solution is to scrap the entire network and build a new one. This is the Petcock Problem, or “How do you stop the bleeding?”. The solution involves balancing several variables, some of which are known quantities, some of which are wild guesses, and some of which are potentially very chaotic (in that a small change in value could have an unpredictable impact on the outcome). [Disclaimer: I’m sure that the study of network topologies has its own terms of art and well researched algorithms for describing and solving these types of problems. I’m not claiming to have some new revelation about networks here. This is just my own little custom worldview.] In a future post I will explain how the Petcock Problem applies to something as diverse as the Vernor lawsuit.
From a new features overview of Autodesk Design Review 2010 comes the following snake oil claim: Digital Signatures To help secure your data, you can now digitally sign DWFx files. As I’ve explained before, digital signatures do not provide data security; they simply authenticate the person that applied the signature. Digital signatures are a welcome feature with many potential uses, but data security is not one of them.
Of course I’m talking about Autodesk’s newly reinvented nomenclature for bug fixes. Once upon a time they were known as bug fixes, then service packs, and now “updates”. Is the Autodesk marketing department running amok? The subtle spin is certainly a sign of the times, but I wonder if the change in terminology comes about for another reason as well. Autodesk promises “features extensions” to subscription customers. They have had difficulty delivering such extensions on a consistent basis. One of the reasons, I suspect, is that developers of extensions encounter the same brick walls that third party developers battle all the time: AutoCAD bugs, of course; but also incomplete APIs and feature limitations. It’s possible that updates not only fix bugs, but also fill gaps so that extension developers can get their extensions working. Then again, the change in terminology might be part of a new fad. My wife, who is an engineer working in the automotive industry, informs me that they no longer issue drawing revisions in her company. Instead, they now issue “updates”. I wonder how long it will be before auto mechanics stop repairing cars and start updating them instead.
Steve Johnson asks “where have all the developers gone?”, and Deelip Menezes wonders in a comment whether Autodesk’s annual release cycle for AutoCAD is part of the problem. I’ve always said that an annual release cycle is untenable. The annual release cycle is motivated by Autodesk’s desire to make the subscription program look attractive. Has it worked? Based on what I’ve read and heard through the grapevine, it has definitely worked. More customers than ever are choosing the subscription model. In many cases, the annual subscription business model actually works well for software like AutoCAD, providing benefits for both Autodesk and their customers. But subscription is not for everyone. In typical greedy big corporate fashion, Autodesk have overplayed their hand. Instead of concentrating on those customers for whom subscription makes sense and leaving the others to choose a different model, the “more is always better” marketing machine kicked in. Ergo, the annual release cycle carrot and the AutoCAD retirement program stick were invented. [Oh sorry, it’s called the Autodesk Loyalty Program.] I am already seeing the beginnings of a movement of discontent among Autodesk customers, and I expect the annual release cycle to collapse under its own weight within another year or two. In the meantime, tremendous damage is being done. Customers, third party developers, authors, and consultants all suffer under the strain of the annual release cycle, but that’s only the tip of the iceberg. To pull off annual releases, Autodesk have to be working on multiple versions of AutoCAD in parallel. While AutoCAD 2006 was being beta tested, AutoCAD 2007 and 2008 were already under development, and AutoCAD 2009 was already in the planning stages. When CUI was first introduced to the public, the new ribbon UI was likely already in the planning stages. Is it any wonder that the angry feedback about CUI was ignored? When you have an annual release cycle with 3 or 4 future releases on parallel tracks, you can’t just stop and fix a fundamental design flaw. All you can do is increase your public relations budget. The harm done to third party developers is substantial, but the inability to shift gears and correct fundamental design flaws is the real travesty of the annual release cycle.
Like that day almost 50 years ago, could today be the day that ObjectARX has died? There have been a flurry of posts in the ObjectARX discussion group about problems downloading the new ObjectARX 2009 SDK. At first I dismissed the problems as new release hiccups, and expected things to get resolved in short order. Seeing that there were no new complaints this morning, I headed over to http://www.objectarx.com/ to download the new ObjectARX 2009 SDK. Instead of the new ObjectARX 2009 SDK, I received the following: ...
This Autodsys press release made me chuckle. Their IntelliCAD based AcceliCAD now supports custom entities, announces the press release. “Instead of creating custom objects as is necessary in some other CAD packages the application developer can instead use the primitives already built into the program such as LINEs, ARCs, CIRCLEs, and POLYLINEs.” Hmmm, that sounds an awful lot like blocks in AutoCAD – a feature AcceliCAD has surely supported since its inception. The press release continues, “That means there is no need to define grip points or editing operations for the entities because those functions are already built into AcceliCAD." ObjectARX programmers have been able to create custom objects in AutoCAD for years. One of the most common reasons for creating a custom object is to “define grip points or editing operations”. Otherwise, blocks work just fine in most cases.
One of the defining characteristics that distinguish humans from computers is our ability to act irrationally. Our biological computer system is capable of interjecting an otherwise logical thought process with random perturbations that often result in completely unpredictable outcomes. Looked at in the abstract, this is the essence of how we escape the shackles of destiny and turn an otherwise mundane march of time into a serendipity of human experience. In practical terms, it’s our ability to make mistakes that gives us supremacy over mere electronic circuits. If we were simply pre-programmed machines, we would be no better, and perhaps no different, than a computer. By making mistakes, we learn. By taking risks, we discover. By challenging and disregarding what is already known, we learn what is not. And that, my friends, is why maps are evil.
There is nothing magical about digital signatures. They are simply an electronic mark used to signify a promise and to cement faith in the document or transaction to which that promise is attached. Some day digital signatures will be as commonplace among CAD professionals as the human readable “wet stamp” is today. However it must also be said that, just as CAD did not make architects more creative, digital signature technology will not make engineers more trustworthy. The technology to use digital signatures has been around for well over 20 years, and a wide variety of software tools exist today that make digital signatures easy to use on almost any platform. So why is the use of digital signatures not more widespread? Primarily because the utopian dream of a paperless world has yet to materialize. So long as hardcopy on paper is regarded as the authentic “record” version of a document, digital signatures are virtually useless. Even if new buildings are designed completely in CAD, an architect’s digital signature simply won’t mean anything if downstream consumers of the building design require a paper blueprint. The true benefits of a paperless world simply can’t be realized until every link in the chain has joined the digital club. So long as even a single node on the distribution tree requires a human readable method of verifying authenticity, the architect is forced to use a handwritten wet signature on paper blueprints from the very start. Handwritten signatures can be scanned into an electronic format, but then they lose their putative value because a digital facsimile is so easily reproduced. Therefore only original and unique handwritten wet signatures are trustworthy in a human readable form. Digital signatures do not translate to paper because they are not human readable. Therefore digital signatures only have value for a document in electronic form. This maxim is fundamental to a proper understanding of the emerging digital signature technology: digital data can only be securely signed by computers; and human readable documents can only be securely signed by humans. I see many people in the CAD industry looking for a hybrid solution to this paper vs. digital dilemma by using a “digitized signature” (i.e. handwritten on paper, then scanned into electronic format) so that printed output contains this digitized signature. This cannot even remotely be considered a digital signature! There is simply no such thing as a secure printed digitized signature. Yes, you can digitally sign a document that has an embedded digitized signature, but once it is printed, that digitized signature is not worth the paper it’s printed on. Not only could that signature be stolen from the document and used maliciously, there is no way to tell from the signature alone whether or not it has already been stolen and used maliciously. The only hybrid approach that is practical and legally sound is to use digital and wet signatures in parallel. Using an architect as an example, this would mean creating and disseminating two sets of signed documents: the CAD model of a building (perhaps converted into a common 2D format like PDF, DWFx, or XPS) with the architect’s digital signature and paper blueprints with the architect’s individually handwritten wet signature. A number of companies claim to sell some sort of hybrid solution involving the creation of a secure digitized signature. This is simply capitalism – selling something useless just because there is a market for it. A digitized signature is only secure if it is never used. I’ve heard the rationalization that the digitized signature printed on paper meets a psychological need for people accustomed to seeing one, even if it has no legal value. In my opinion, such pandering borders on deception and serves only to further alienate digital signature technology from those who would benefit from it. This sort of abuse is typified by an emailed PDF file consisting of a scanned document with a handwritten signature. In such cases, checking the sender’s email address likely becomes the most reliable way to verify the document’s trustworthiness. Spam filters bear witness to the fact that the sender’s email address is the most important – and often only – criteria we use in determining the level of trust to place in emailed documents. This is an important point to keep in mind. The act of applying a digital signature requires the use of a secure private encryption key, but the digital signature alone does not provide security in any way. Digitally signing a document does not prevent it from being modified or stolen. In that respect it is no different than a handwritten wet signature. However, unlike a wet signature that cannot be easily duplicated, a digital signature does not prevent a signed document from being copied. This does not make digital signatures inferior. On the contrary, making copies is necessary and commonplace in the digital world, so the fact that exact copies of digitally signed documents are still trustworthy is a huge benefit over handwritten signatures. There are other notable differences between a digital signature and a handwritten signature. Digital signatures can be time-stamped, thus providing reliable evidence that a document was signed on or before a certain time. A disadvantage of digital signatures is that they are only as reliable as the digital ID used to create them. To combat this problem, a public clearinghouse of compromised digital IDs must be maintained, and auditing systems must be in place to immediately detect and report suspicious activity. Time stamped digital signatures created before a digital ID is compromised can be easily and certainly distinguished from compromised signatures if properly designed and competently managed infrastructure is in place. This is necessary to ensure that previously existing digital signatures survive a compromising event. In conclusion, adequate technical solutions and time tested safeguards already exist for successfully using digital signatures in a professional environment, but digital consumers still need to learn how to work within the limitations of the technology. Building an acceptable comfort level with a technology that must by its nature completely replace something as significant and culturally ingrained as the handwritten signature will not be easy or quick, but it is inevitable.
Security and encryption legend Bruce Schneier posted this essay: The War on the Unexpected I think we should all be reminded that representative governments are always at risk of death by democracy: suicide under the watchful eyes of a body politic beholden only to the next election.
I’ve heard the word “brutal” used more than once during conversations with Autodesk employees about the Autodesk sponsored discussion groups. It’s true that raw unfiltered feedback can be brutal, and it can also hurt your ego if you happen to be the target of criticism. The trick is to learn how to interpret the feedback. If you can master that skill, that raw feedback is a fast, unbiased, low noise-to-signal-ratio predictor of the future. I’ve seen many recognizable Autodesk names come and go since the days of Autodesk’s original online discussion group, the CompuServe ACAD forum. Oftentimes, they came espousing the virtues of such a vibrant community, only to wilt away after they got singed a few times in the inevitable flame wars. Some Autodesk names (Art Cooney comes to mind) have been around forever, and still take it all in stride. Personally, I view the discussion groups as one of Autodesk’s biggest competitive advantages, even while they go largely untapped. This week saw too issues erupt into what could fairly be termed brutal feedback. The first was caused by the Autodesk University registration site failing under the load of opening day registration. Several threads (“Dear Carl Bass” and “AU2007 Registration is now open!!!") called Autodesk to the carpet for blowing it again, after a similar fiasco in 2006. The second event occurred when AutoCAD product manager Eric Stover announced a new “bonus” tool called CommandComplete. I pity the poor guy or gal that wrote this tool (on their own time, I’m sure), all excited to see how it is received, only to become the victim of a flame war. Okay, not really a flame war in this case because Eric employed his finely tuned flame retardant diplomacy skills to prevent it from getting out of hand – so let’s just call it a “venomous reaction”. There is a moral to this story. Some companies would kill to have access to this kind of critical, unfiltered, instantaneous feedback from the unwashed masses. I hope Autodesk recognizes the goose that lays the golden egg.
Reading the discussion about the reluctance to move to 3D/BIM in the latest issue of upFront.eZine reminded me of the principle of rational ignorance. The principle of rational ignorance applies when the perceived cost of obtaining knowledge is greater than the perceived benefit. It’s a bit of a chicken-and-egg scenario, where individuals rationalize their decision to remain ignorant based on their perception of the (lack of) benefit in the very thing they are ignorant about. It is interesting to think about the 2D to 3D paradigm shift in terms of shifting the balance in the rational ignorance equation. I think there’s also another principle at work here: Newton’s Third Law. The harder the collective movers and shakers try to push, the harder the end users resist. Maybe if the software companies stopped pushing so hard, the shift would occur naturally with much less resistance. By the way, I noticed a familiar theme in the upFront eZine discussion: those resistant to the paradigm shift lament the lost art of drafting and fail to believe that the new paradigm no longer needs artisans. Obviously there are other factors at work here – factors over which no amount of logic will prevail.