Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
[I am translating a condensed version of an article that appeared in a German newspaper. I did not write the program!! That ActiveX translation caused a *lot* of wind! -dww] >From the *Ostseezeitung*, 28 Feb 1997 [I was in Rostock, Germany at a wonderful conference]: German hospitals are using computer programs to calculate if it makes financial sense to keep patients in intensive care on the life support machines. This was published in the German weekly "Der Woche" in the most recent edition. According to "Der Woche", the computer assesses the vital statistic data kept on patients and computes the likelyhood of the patient surviving. The health authorities in Bremen yesterday told the hospital "Links der Weser" to stop using this program, as it is unethical. The Marburger Bund, a doctor's association, warned the same day that such programs are being introduced into hospitals around the country. The chairman of the Marburger Bund, Frank Ulrich Montgomery stated:" When the survival of a person is dependent on money-based criteria, then we have ethically reached the situation where the Nazis left off." However, Montgomery notes that it is indeed useful to track data on patients in the intensive care units, as there are quite a number [he said "infinite", but I don't believe that! -dww] of information points collected about patients. The City Hospital Merheim in Cologne will continue to use the program. The head of the surgery department, Prof. Hans Troidl, called the press reports "stupid and irresponsible." The program determines the condition of a patient determined by the blood values and the body temperature and such. In addition, the program notes how many patients with the same values survived. [more quotes and stuff deleted] The decision how to help the patient is solely the responsibility of the doctor and cannot be delegated to a computer. The computer is only a consulting aid. [A doctor in Bremen] said that we should be considering the costs of treatments, however, and begin discussions on this topic. [more quotes, nothing new.] Coming down the steps at my train station at home I saw the evening yellow press has the "Dr. Death Computer" in big headlines, so stay tuned for a big row in Germany about such programs. The risk? Don't write programs without weighing the effect it might have on public sensitivities! (Check out the ACM Code of Ethics!) Debora Weber-Wulff, Technische Fachhochschule Berlin, FB Informatik, Luxemburger Str. 10, 13353 Berlin, Germany firstname.lastname@example.org
The *Dallas Morning News* posted an item on its Web page on 28 Feb 1997 (although the newspaper story did not appear until the following day), alleging the existence of a report stating that Timothy McVeigh had admitted to his attorney Stephen Jones that he (McVeigh) was responsible for the Oklahoma City bombing that killed 168 people at the Alfred P. Murrah Federal Building in April 1995. Jones at first denied the existence of the report, but now admits the report does exist — although he denied its representing a confession. What makes the case RISKS-relevant is that Jones is charging that the *News* stole the document in January as a result of a computer break-in that enabled access to confidential defense materials. [Source: a *Los Angeles Times* item, 4 Mar 1997, itself including AP sources; seen in *San Francisco Chronicle* of that date, A2.]
Web entrepreneurs who charge subscription fees for accessing their Web sites are finding their customers are passing along their passwords to friends, relatives, etc., thus diminishing Web operators' potential for making their venture pay off. "Everybody on the Internet who sell subscriptions has this problem to one degree or another," says a producer for SportsZone. A technical fix is possible, but Web site operators are reluctant to make things more difficult for legitimate subscribers to log on. Meanwhile, Internet Billing offers software that allows Web sites to limit how many times the same password may be used each day — a solution that would probably keep some of the piracy down, but runs the risk of alienating paying customers who just want to log on a lot. (*Wall Street Journal,* 21 Feb 1997; Edupage, 23 February 1997)
[On WJFK-FM, an advocate of Forepaws (an animal rescue group) recommended tattooing your SSN on your dogs to combat dognapping, and suggested that this has become a semistandard practice.] This is an astoundingly poor idea, considering the well-known sensitivity of the SSN — which should never be used to ID something for which the likelihood of theft is high enough to warrant a confidential ID. It exposes the SSN to exactly the worst people to have access to it. This is a case where the cure is worse than the disease. Also, it could actually stimulate dognapping since it adds information value to the dog. [Pat's letter to the station deleted. PGN] Pat Sullivan [Certainly gives you cause for pause (four paws?) that RISKS is emBARKing on animal-related risks of SSNs. How about BARKcoding? Also intriguing is that Pat lives on Barker Hill Road, perhaps doggedly. PGN]
Paul Greene, a student at Worcester Polytechnic Institute, yesterday posted a note about a flaw discovered by him and colleagues, which allows Web servers to execute arbitrary commands on users of Microsoft's Internet Explorer 3.01 browsers (and possibly earlier versions?). The flaw can be triggered *without* using ActiveX, and even if IE is set to its highest security level. Windows 95 does not prompt you before merrily executing. A .URL file attack works on both Windows 95 and NT 4.0. Greene's site is http://www.cybersnot.com and MS's impending fix is posted at http://www.microsoft.com/ie/default.asp . [Source: AP item, seen in *San Francisco Chronicle*, 4 Mar 1997, C4]
As the architect and primary implementor of the Authenticode code-signing technology (boy, that'll get me mail :-) found in Internet Explorer 3 and in Windows NT 4, I think my perhaps somewhat lengthy and clearly very biased perspective on some recent articles might be of interest to others. Bob Atkinson > From: "Theodore Y. Ts'o" <tytso@MIT.EDU> > Subject: Re: Myths about digital signatures (Felten, RISKS-18.83) > > For example, if an Active X component has a loophole where (with the right > document) said component can be induced to interpret and execute arbitrary > Visual Basic statements, even if the signer was honest, and legitimate, and > properly went through all of the Microsoft certification procedures, it > still might be possible to exploit a security bug in the Active X component. First, a correction. Microsoft does not have any 'certification procedures' with respect to the integrity or lack thereof of third party applications against security attacks. There is no magic bullet that would enable us to make such statements. Software developers, as they always have been, have the responsbility of themselves exercising appropriate diligence in this regard. We do, however, offer system services that aid developers in this endeavor. For example, the underlying Authenticode engine is available for use by applications so that, say, if they themselves are an execution engine which might from time to time download possibly malicious code, they can apply the same gatekeeping checks as the system's download engine applies. This was, exactly, intended to address the scenario describe here (see the "WinVerifyTrust API" if anyone is interested). As another example, the overall system infrastructure, which includes the Java VM and its attendant sandbox, has mechanisms for classifying ActiveX components as "safe for scripting" and "unsafe for scripting;" a similar mechanism applies to "safe for initialization" (from data on web pages). These are designations assigned by the ActiveX component developers themselves. In short, components that designate themselves as 'safe for X' can be interacted with by (possibly malicious) code inside the sandbox; code designated as 'unsafe for X' is prevented by the system from being instantiated or interacted with by sandbox code. The point being that the system provides the component developer flexibility in balancing his development time and effort with the amount of richness available to his component once downloaded. > The Java security model at least *thinks* about this issue, where as the > Active X approach completely punts about this concern. Having spent considerable brain cycles on the issue over the last couple of years, you'll I hope pardon me if my opinion differs from the thought expressed here. Users want and demand a rich computing experience. Users want software that does interesting, important, and useful things for them, be that Navigator plug-ins, arbitrary EXEs, .Zip files, Java (system) classes, ActiveX controls, or something else. The same security issues being discussed with respect to ActiveX apply equally to all these _other_ forms of application, all of which in the course of doing interesting and useful things on behalf of the user is going to at times need to be given access to information or capabilities that _could_ be used for evil instead of goodness. With traditional software distribution channels (Egghead, Computer City, ...) you know where the code came from because it says so on the box, and you trust the retailer to sell you only legitimate product that hasn't been tampered with. Got a problem with the program? The guy on the box is who you call; he sure doesn't want the embarrassment or liability of shipping product that ends up having a virus in it, so he takes care not to do so. The combination of criminal and tort laws together with a company's desire to stay in business and enhance its reputation works together to create a system that supplies customers with rich, useful software at a minimum of risk. We have decades if not centuries of experience with this model of conduct between supplier and customer. It seems to work pretty darn well. In the online world, users have heretofore installed software manually, by way of manual download. In doing so, they have had to resort to ad-hoc and often naive mechanisms for judging the risk they are taking in doing so. "Just where did this code come from? Who is responsible for what it does? And has it been tampered with? How do I know?" The online distribution channel has lacked mechanisms that provide the accountability present in traditional channels. We can make users lives dramatically better by automating the online software installation process. The rich, useful code can just always be simply there right when you need it, rather than your having to understand what code it is you're missing, hunting around to find it, and having to have the computer experience to figure out how to manually install it. In addition, we can provide mechanisms that bring to bear in the online world the same forces successfully used to manage risk in traditional channels, mechanisms that can help users be conscious of the risks involved and make informed choices about them. These mechanisms are particularly important to have in place when installation is automated, as it is in IE3, but the mechanisms are also valuable and useful even when installation is done manually. > From: email@example.com (Fred Cohen) > Subject: Re: MS on the CCC ActiveX virus (RISKS-18.83) > I appreciate your [BradSi's] insightful opinion on this matter, however... > Anyone can get a signature key without authenticating their legitimacy. > It's relatively easy to break into a system and take a legitimate key. It is true that the user's understanding and the care with which he manges his private key is an important part of an overall security infrastructure. Flaws in any one part of that overall infrastructure may compromise the system as a whole. However, compromise of private keys is a concern that IMHO warrants less worry than other aspects of a system might. In Authenticode as implemented in IE3 and NT4, the private keys are managed by the system's cryptographic provider infrastructure (CryptoAPI), which enables a number of different cryptographic devices to be used transparently by applications. Several different cryptographic hardware devices are on the market that support CryptoAPI, offering extraordinarily good, virtually foolproof private key protection in a range of prices from a couple of hundred to a few thousand dollars (see, for example, http://www.spyrus.com/whats_new/pr_csp.htm, or http://www.bbn.com/offerings/sksign.html ). Such hardware devices and the increased key protection they provide are likely to be well worth the investment, especially for commercial enterprises in the business of software publishing. Indeed, from my own personal perspective it can be argued (disclaimer: I am not now, nor ever have been a member of the legal profession) that given the modest costs and given the nature of being in the software business to not take such precautions might be considered negligent on the part of such an enterprise. For those curious: at the present time, the private keys with which Microsoft signs code that it publishes are managed inside BBN SafeKeyper boxes housed in a guarded steel and concrete bunker. Even were a SafeKeyper to somehow be physically stolen, these cool little boxes have several elaborate internal defenses designed to have the box destroy itself rather than compromise its keys. As I understand things, a military variation on the SafeKeyper technology is used as an integral part of launch control of nuclear missiles on submarines in the US Navy. In the absence of a hardware device, CryptoAPI provides an in-the-box a software-implementation of the cryptography; however, when this cryptographic provider is used with Authenticode, the private key is not in fact kept online, but rather on a floppy disk, which need be inserted only during the actual act of code signing, hopefully on a managed, virus-free 'release environment' machine used to protect against this and a whole host of other more traditional potential virus attacks. > The default may be changed by the user for one use and remain changed. > Other flaws in Explorer may be used to turn that feature on - then look out. > > The CCC demonstrated its malicious executable code running on Microsoft > > Internet Explorer 3.0 This is true, as the demonstration was made, but it is misleading, as it leaves out significant contextual information. The CCC demonstrated code which, if it had been actually deployed, would, as I understand things from the press descriptions I have seen, carry out actions which are out-and out-theft. Theft is illegal. You can go to jail for it, if they catch and convict you. Let's look at that for a moment. There are the following ways in which that malicious code could get on a user's machine: 1. The user can choose to bypass the security support provided by the system by setting his security level to 'none' or 'medium'. The CCC control was unsigned, and thus cannot be installed by IE unless the user overrides the protection provided by the system. 2. The code could be signed, and then downloaded by IE3, and accepted by the user. That is, the crooks can if they like leave their clear, unsmudged fingerprints all over their illegal device. This makes catching and convicting the responsible party somewhat easier. 3. Some well-intentioned software agent other than IE3 can download and install the malicious code. Such agents, would, however, have the same responsibility for exercising due diligence in protecting the user as IE3 itself has. Fortunately (see above), the mechanisms are available in the system infrastructure to allow them to do this. In the absence of the user bypassing the system's security infrastructure, which as was mentioned is highly discouraged, then should the system be attacked by a malicious ActiveX control, some piece of malicious or negligent digitally-signed code that was downloaded is ultimately responsible for carrying out the attack or allowing it to occur. The mechanism which prevents this from happening is the deterrent of a reasonable expectation of getting caught and being held accountable for one's actions. This is the same mechanism used to great effect in the rest of a free society to balance freedom of action and unencumbrance by red tape with society's need for safety and protection. The presence of digital signatures on code does not remove the need for law enforcement agencies to do their investigative work when confronted with a crime; their detective and analysis skills will continue to be be valuable and needed. Even in the absence of an audit log of execution (a very good idea, where technically feasible), if you eat hamburgers at Restaurant X, and you get sick, and Fred eats hamburgers at Restaurant X, and he gets sick, and so on, chances are that there's something wrong with the hamburgers at Restaurant X. Or if you drink fruit juice from Company Y ... you get the idea. Effective and successful criminal prosecutions are regularly and routinely made on less than perfect evidence, often _much_ less clear than we're discussing here. What digital signatures on code provides is a robust and unforgeable attribution of responsibility for publication once the actual offending code is identified. And, as implemented contractually and technically in the present release of Authenticode, when you sign code you _are_ most certainly taking explicit responsibility as the code's publisher, an action not to be taken lightly from a legal point of view. The additional ability to have third parties digitally "endorse" or "rate" works published by others we have always thought to be a very useful and valuable concept, but it is a separate and distinct one from that of signing as the publisher. > As the folks at Microsoft know well, impediments are easily and commonly > removed - and the use of the display box for popular applications is > likely to result in the question being turned off in favor of easy access. Yes, the concern that inconvenience or annoyance causes the end-user to bypass the security infrastructure (see #1 above) is an important consideration. However, I am optimistic given our experience to date that we've done well in this regard, though only time will tell for certain. Educating users not to lower their security level is extremely important; we're working very hard on educational initiatives like the Security Advisor program (http://www.microsoft.com/security). Moreover, in the Authenticode infrastructure is the notion that one can come to 'trust' certain publishers. Code that is legitimately signed by a software publisher who is listed by the user as trusted is automatically approved for installation without user intervention. For example, if Microsoft Corporation were listed, then code signed as being published by Microsoft will be downloaded and installed without any dialog box or other repeatedly-annoying UI. The net effect is a mechanism that allows the user to bypass redundant and repeated prompts for the same approval _without_ compromising his protection in any way. Within intranets, even greater protection can be achieved by enforcing download and signature-checking policy within a company's firewall. This can be done, for example, with TIS's Gauntlet Internet Firewall (http://www.tis.com/docs/corporate/press/96/mspr.html). > From: Steve_Kilbane@cegelecproj.co.uk > Subject: Re: MS on the CCC ActiveX virus (RISKS-18.83) > > > [MS Press Release:] Other firms such as Sun and Netscape are > > following our lead, and have > > announced that they will also provide code signing for Java applets. > not only are Microsoft > attempting to justify giving away the family silver, but they're also trying > to imply that they're the ones responsible for the idea of code signing [...] > I wasn't following Java back when it was called Oak and set-top boxes were > the name of the game, but I wouldn't be hugely surprised to discover that > signed code was part of the plan even then. Anyone with more authority care > to comment? I think too much is being read here into our press release. Invention of basic ideas and usable, successful, practical wide-spread deployment of implementations of ideas are different beasts. Both are important, and both are needed. Both require some amount of creativity and innovation. The general notion of digital signatures has been around for quite a while. Just to take one example implementation from many possibilities, Apple some time ago shipped in their OS a "digital signature on documents" infrastructure (whose name alas escapes me at the moment). The relevant technical standards used in Authenticode (X.509 and PKCS #7) are also not new by any stretch of the imagination. With respect to signed _code_, various Java-related web pages on the Sun web site circa early summer 1995 indeed did mention in passing that it was an interesting idea to apply digital signatures to code. Clearly Sun was at that time exploring this interesting idea. However, no insights were offered as to the actual policies or architecture that might be involved. To be just a little overly-severe, what I recall was little more than simply "digital signatures" and "downloaded code" being mentioned in the same sentence. IMHO, the most important innovations of Authenticode on prior general practice in the industry lie in the area of usability, especially as related to the user's understanding of and administration of trust. You might notice, for example, that the certificate dialog simply states "X is published by Y under credentials issued by Z," as in "Surround Video Control is published by Microsoft under credentials issued by Verisign" a simple "brand of identity" approach rather than the historical approach of thrusting upon the user a whole chain of delegated identifications. Also, appropriate clickable hyperlinks are provided on the prompting dialog, allowing both the publisher to set appropriate expectations with the user as to what his code is going to do, and for the credentials agency to inform the user of its identification policies, all before the user has make the decision of whether to allow any of the publisher's code to run or not. Third, as was mentioned, repeated prompts for essentially the same approval can be easily and simply automated without loss of security. Fourth, the fact that we focused on mechanisms whereby signatures can be physically inserted within existing file formats (.EXEs, .CAB, .class, etc) rather than as separate files increases usability by avoiding the need to keep multiple files in synchronization. None of these ideas is by itself especially deep. But taken together, I submit that the overall user experience is significantly more straightforward. Finally, there is the simple fact that despite the (welcome!) future plans in the area of code signing expressed by both Sun and Netscape, Authenticode is still the only actually-deployed code signing infrastructure. It's seven months into widespread shipment, nine or ten months since it's first beta, close to a year since its first public demonstration, and close to fifteen months since it's announcement. Ideas are important, but it's difficult to impact users unless you actually ship product.
Suffering from a sinus infection, I went to my doctor's office in search of answers. A standard operating procedure in the US is for a nurse to take a patient's temperature, blood pressure, and to ask a few questions before the doctor comes in to spend some time with the patient. Well, they have these new "ear" based thermometers (I won't even hazard a guess as to how they really work) which they place in your ear and "push a button" to read the patient's temperature - at which point the patient feels/hears a small click in their ear and a number appears on a small LCD display on the device. My first reading came up "3" - my second reading came up "3" at which point the nurse shook the device - my third reading came up "3" - at which point I asked the nurse what the "3" really meant. She replied, "3's an error code." "Hmmm, any idea what it means? Am I broken?" "Nah [laughs], it just means something isn't right, this happens a lot in the mornings before it warms up but not usually in the afternoon...I don't know what it means." At this point she opens the door and yells across the office for another nurse to come in - who does, takes the 'earometer' if you will, places it in my ear and "click" I'm now 94.7! Hurray they have *a* number! The first nurse writes 94.7 down, and moves on to the more traditional method of taking my blood pressure... The Risks? A medical device with unusable error codes (as suggested by my user study N=1) and an inherent belief that whenever the system appears to work, that it is actually working. Let's hope people working with infusion pumps, heart monitors etc. etc. are a little less trusting in this master we call technology. Matt McNally PS - This probably wouldn't have drawn my attention if I hadn't literally had 15 minutes to ponder the event while the local druggist's cashier attempted to "manually" enter my credit card number for a purchase approval. It seems this national chain no longer trains their cashiers to handle credit card approvals outside of the built-in register function. The store basically came to a halt until the druggist (reading instructions from a card) was able to call his merchant account's approval system directly.
Please report problems with the web pages to the maintainer