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…
According to an article in the Swedish newspaper, Svenska Dagbladet <http://www.svd.se/svd/ettan/ettan_97-04-11/narkotikapolisen.html>, the Stockholm narcotics police have asked the national police and State Prosecutor to require that purchasers of a new telephone card used for mobile telephones be registered, and that the police have access to the purchaser database. "Since the card is purchased anonymously, the owner cannot be determined, which makes wiretapping impossible." The new card is pre-paid with 250 or 550 kroner (very roughly $32 or $70) air time and a telephone number, but does not require any other subscription. The card can be used on an ordinary GSM mobile telephone "which can be borrowed or stolen" and can be re-loaded when the air time runs out. A similar card is in use in France. However, the French security service made the government force the telephone company to require that purchasers show an id card when they purchase the card. Quickly translated and summarized by Martin Minow <minow@apple.com>
>From C|Net: http://www.news.com:80/Categories/Index/0,3,1,00.html?ntb.net E-mail being sent through America Online has been delayed since Monday due to an unusual spike in mail, according to AOL spokeswoman Tricia Primrose. AOL added new mail servers, now handling about 1 million messages an hour, but the residual effects of the original jam are lingering. Primrose could not say exactly when the system would run smoothly, adding that the volume of e-mail sent to and from the online service has doubled from 5 to 10 million messages since December, when AOL began offering flat-rate pricing. Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.
I pay for parking in the local parking garage on a monthly basis and have a pass-card which ID's me to the garage's entry/exit control system. One day, after parking in the garage as usual in the morning and working through the day in my nearby office, I walked back into the garage, started my car and attempted to exit the garage. Instead of the gate rising and allowing me to pass, a klaxon sounded and I was obliged to summon a garage attendant who eventually accused me of attempting a "pass-out" fraud - he got rather excited and I think he anticipated being rewarded for his vigilance. A pass-out, in their jargon, is where one customer hands his pass out to another who then uses it again in an effort to park two cars on one pass. I had the attendant call his boss and then had to have her call in the next level of management before I found someone who would even consider the possibility that I'd not risk criminal charges over a petty fraud like this. Boss-lady eventually began to wonder out loud if the fact that the computer had "gone on the fritz" an hour previously might be somehow related to this mess, but she was in no hurry to come to any rash conclusions. I was partially into an impromptu tutorial about the consequences of "glitches" on saved state when, mercifully, other customers started to suffer similar problems in the adjoining exit gates. They all gathered around and listened as I struggled to convince boss-lady that we had NOT all conspired to commit pass-out fraud simultaneously. She did let us all leave eventually, but never seemed truly convinced that we had not gotten away with some cunning trickery. RISKS? Nothing new - do I really need to say it? Believing the computer is always right; insufficient training of personnel who co-operate with automata. Michael O'Donnell mod@std.com.goAnnoySomebodyElse
Well, this old risk of "computers are never wrong" caused my high school teenager a buck (dollar) at the school library. He received a notice of fine for an overdue book. When he argued (his side of the story) they said "its in the computer". And besides that, there was no way to change the fine because, again, "its in the computer and we can't change it". He told me that they had tried to charge him for a book that never was returned because the computer said it had been checked out to him. When he pointed out to them that the book had been, supposedly, checked out BEFORE we even moved here, it (the record of fine) was removed from the computer (see above). It saddens me that the technologically ignorant are teaching my children that "computers are never wrong". That's the REAL RISK of education ... assuming that "computers are never wrong". -Joe
For several months I have been receiving bad DNS name service requests from a ISP site in Washington state. These were directed to nonexistent or internal hosts in our domain, and were intercepted and logged by our packet filter. It appears that some time ago (perhaps even before we went on the net), the ISP sent out incorrect information, perhaps on a setup disk, to their subscribers listing our addresses as secondary name servers. If for some reason their primary name server did not respond, the client would try to contact my (nonexistent) name servers. There was never a security problem, but the proliferation of log messages was annoying. After repeated complaints, the ISP finally "solved" the problem by installing an IP filter on their router to prevent the misdirected packets from going out on the net. This worked well, until recently I began to see messages from another network directed to our non-existent "name servers". I contacted this Internet provider, coincidentally also located in Washington state, and found that, yes, some of his customers had recently transferred over from the other ISP! And no doubt brought their configuration with them.. The real problem, of course, was that the first ISP chose to confine the problem rather than fixing it. This assumed that the "infected" users stayed put behind their router, which was not a valid assumption. Now I'm considering putting up a "special" name server on those addresses... Al
The Associated Press today reports that Robin Guenier, head of the UK's TaskForce 2000, estimates that Y2K reprogramming efforts will cost Britain $50 billion dollars, three times the guesstimates of business consultants and computer service companies. Guenier suggested that 300,000 people may be required to tackle the problem. (Coincidentally, that number is roughly equivalent to the number of full-time computer professionals in the UK.) [Various versions of this noted by several folks.]
An article in today's *Times* (14 Apr 1997) by their Defence Correspondent Michael Evans, titled "L100m scheme to reboot missiles" goes into the difficulties that the British Ministry of Defence are going to face in overcoming the problems of the year 2000. The article refers to "Thousands of miniaturised computers inside missiles and other modern weapon systems" that will need be replaced or reprogrammed. The rest of the article is of little surprise to RISKS readers, but the estimated figure of 100 million (U.K.P) is interesting in light of recent guesswork on costs within various sectors. Geraint Price - Geraint.Price@cl.cam.ac.uk Computer Laboratory, New Museums Site, Pembroke Street, Cambridge, CB2 3QG.
There appears to be some confusion over the approach Win95 takes to
Greenwich Mean Time (GMT).
The Greenwich Meridian provides the baseline for calculating times
world-wide. In the UK and Ireland throughout the summer months a scheme,
known in the UK as British Summer Time, applies. This type of scheme may be
known elsewhere as Daylight Savings Time - although how one saves daylight
in a fully reuseable form I'd like explaining!
The Date/Time/Time Zone function in Win95 allows for setting the 'local time'
to any world time zone. Win95 regards GMT as a time zone not an absolute
time, and, accordingly, selecting 'Adjust for daylight saving changes' gives
GMT+1 when the clocks are put forward in the UK and Ireland.
Michael Bacon
[Mark Brader <msb@sq.com> notes that the basic risk in dealing with GMT
is that of one person assuming that "GMT" means UTC, while another person
interprets it as "the current civil time in the UK". This is the fault
of the UK for not having distinct abbreviations such as our EST (always
-5) and ET (-5 or -4) [and even EDT], but what can we do about that?
And don't forget that the differences between UK local time and North
American east-coast local time change FOUR times a year because the
changes happen on different weekends. PGN]
I tried out one of the new Web Kiosks that is being installed by a USWest-related entity. Great idea though weak in execution. But the issue I'm not as concerned about the strange keyboard or the malfunctioning credit card scanner. At least, not for RISKS. Nor the unnecessarily bad performance. So goes naive implementations. THe problem is that the browser defaults to remembering passwords for visited pages. Unless you remember to uncheck "save password" for each and every visit, you're leaving a trailing. I would have complained except that I couldn't find an e-mail address other than a USWest one. And the people at that address said they have nothing to do with the Kiosk. I do naively assume that they are nice trustworthy people and don't do their own "tapping". But then, that's the risk of any public appliance including the telephone — I just assume that store owners do not tape conversations over their public phones. Alas, a nice idea, public Web Kiosks, that will probably fail due to poor execution rather than a poor idea. But this is not the forum for Risks of Marketing.
In February 1997, a Swedish web design company started a contest offering $1500 to anyone who could break into their web server. The contest ran for about two months, they increased the reward to about $15,000 (100,000 Swedish Kroner), and nobody succeeded. Here are a few notes from their report (still in Swedish, an English translation is due "real soon now," look on <http://hacke.infinit.se/> for details): * Their web server is an "out of the box" machine with no firewall or other "magic" running a commercial web server. Installation time, including unpacking the computer, was around 30 minutes. * The earliest attacks exploited known Unix security holes, with Windows NT showing its popularity. * An amazing number of people tried to break the administration password for their WebStar server which, if successful, would allow remote management. There were over 220,000 attempts to guess the password, all unsuccessful. (Even if someone was successful, this wouldn't allow changing a web page.) * Next, people tried breaking their DNS server, presumably so they could "move" hacke.se to a machine with a different IP number with a fake web page. However, their DNS server also runs on a Mac, so these attempts failed. Sendmail attacks didn't work (no Unix, remember). * Their router was the only non-Mac software in the chain, but it, too, withstood attacks. * The best attack was pure social-engineering: e-mail with a falsified return address asking for a change in the web page because I don't have time to do it myself." That, too, failed; it helped that the message was written in English, not Swedish. * Some statistics: over 650,000 hits from over 100,000 unique IP addresses, sending over 8,000 MB data. About 75% of the visitors were from the USA, 20% from Sweden, and the rest from other parts of the world. "We wish to thank the visitors that came from El Salvador and Mauritius." This is not to say that the Mac was completely problem-free: it's susceptible to SYN flood and "ping of death" attacks, and crashed three times during the test period, but restarted automatically within a minute, thanks to two small shareware programs. Martin Minow minow@apple.com
In Australia we have a Government-run "Medicare", which subsidizes Medical care, child care, etc. Today my wife asked me to take a pile of claim forms down to the Medicare office to get a refund. The forms had to have her signature on them, so she used some that were lying around the house, which were obtained a few months ago. After standing in a queue for too long, the operator processed the forms. She seemed to be have some trouble with one of them, so I managed to peer around the corner of the monitor to see what was happening. One of the codes that she had entered from the form (e.g. 95) was highlighted in red, along with an ominous message saying "Invalid code". According to the form, it was the correct code for "Full-time tertiary student". After further delay, and trying a few other random codes selected from the form, someone else came along and was able to solve the problem - The form was an old one, and the codes had changed. They worked out what the new code was (e.g. 42) and entered it without further trouble. By this time I had a neck like a giraffe, but was able to see that the new code for "Full-time tertiary student" was actually the same as one of the old codes for something entirely different. The amount of refund is based on these codes. The risks? First, that with the change in forms and codes, some (but not all) of the old codes were reused, but with different meaning (I wonder what happens if they have to rerun or check some previous transactions?). If I had come along with an old form filled out with the number 42 it would have been accepted, but would have meant something entirely different. Second, there was no way to tell that the form was out of date, other than the system rejecting some of the "old" code numbers. Third, in hindsight I'm not actually convinced that the form was out of date - the system may have rejected the code for some other reason. It's possible that some of the categories and therefore their corresponding codes are no longer eligible for refunds (i.e. a policy change), and the "new" code still stands for the category on my "old" form. Thus, the amount of refund I received may not be correct (which in fact was less than I expected). This is a further cause of concern as the data on the Medicare computers is used by other Government departments to check eligibility for other benefits. Maybe I'm paranoid, but I won't be surprised if my wife gets a letter in the mail a year from now saying "We have reason to believe you ceased full-time tertiary study in April 1997 and demand immediate repayment of $10,000 in falsely claimed benefits..." Paul Brebner, CSIRO Software Engineering Initiative, Division of Soils, Black Mountain, Canberra, ACT 2601, AUSTRALIA +61-6-246-5923
I was recently on a European passenger flight and over the Baltic observed another aircraft zing past on a reciprocal course. The high closing speed gave the impression that the other aircraft was much closer than reality - actually it was a Jumbo about 1.5 miles away rather than a much closer 737, as I had thought. But discussion with flight deck crew later revealed other 'facts' which may lead to increased head-on collisions in future: * Advanced flight systems control heading, height and speed very accurately, so that now more aircraft fly more-or-less exactly in the centreline of the airway. * Many airways are bi-directional, on identical tracks separated only by height. * A pilot commented that he now frequently sees other aircraft pass directly under or over his own. Conclusion: GPS and advanced nav aids have improved the accuracy of flight, possibly to the point where collision RISK is increased. Formerly, small navigation errors within an airway prevented ever exactly following the centreline. No more. Now, collision is only prevented by controlled variation in ONE dimension - height. A SINGLE failure in height control or measurement will now make a collision inevitable. Of course in this example, collisions were only prevented THEORETICALLY by control of vertical separation anyway, since all aircraft were assumed to follow the centreline of each airway. But PRACTICALLY, the risk of actual collision was further reduced by horizontal errors too. Seems to me like a good argument now for always slightly separating the tracks of reciprocal airways. I would be most interested in the comments of some real professionals - I'm very much an amateur. John Brooks - Technical Consultant, Energy, Network Systems and Data Comms South Croydon, 7CR2 7HN, UK Tel: (44) 181 681 1595 Fax: (44) 181 649 7536
As further background: The Conservatives' tactic was to announce a whole series of far-reaching measures in matter of days, all to take effect at about the same time, all of them to be rammed through in the same manner. Presumably they intended that opposition would be weakened by a division of focus. At least some of those opposing to the changes are doing so not because they feel that the "megacity" is impractical, but because they object to the tactics, or the other measures, and now choose to fight anything that this government does. > The opposition ... is proposing about 12,000 amendments In fact, one of these amendments was passed, after the government members missed their cue to vote on it. Presumably a sham review will now be held and the execution... er, changes will proceed on schedule. After a few more days, the legislature's Speaker (moderator) ruled that the identical parts of the text did not need to be read each time through any more, but only the name of each street. It still took some time, but all the opposition amendments were defeated by the end of last week. Presumably, the next time this sort of thing happens, the computers will be programmed to produce a more varied set of amendments, to defeat the "only read the changing part" technique used this time. Mark Brader <msb@sq.com> SoftQuad Inc., Toronto
> The risk is that as we automate systems, we sometimes forget that > automation does not automatically equal efficiency. On the contrary, as you pointed out yourself - it's very efficient for *them*. The problem is that the time/labor/intelligence load hasn't been *saved*, it's just been transferred to the users. For most people who use such a system once per year, the amount of additional load should be minimal ... except that if a previously painless task becomes annoying, the cost in public relations more than outweighs the savings in staff. I work for a company that makes voicemail components. We cringe every time we hear about "voice-mail jail" and other poor uses of such technology, because one bad example puts people off the entire concept, which is =on average= pretty useful. Same goes for computers and just about anything else. -harlan
It's been an interesting week for me WRT security and export/import controls. I've been using MIT PGP v2.6.2 and Viacrypt's v2.7.1 (Macintosh) for quite a while on my home systems. I also use Viacrypt's v2.7.1 (AIX) product where I work. Yes, all of my machines are located in the U.S. or Canada. Yes, I realize this is an export-controlled product. Yes, I have agreed not to export any of these products to people that shouldn't have them. Yes, I even avoid using the freeware version for business purposes. Enough background... I was somewhat disheartened to learn that I could not download any of PGP's (or MIT's) current products from work via the WWW because the administrators of our firewall had implemented a policy of "if it's not explicitly permitted, it is denied." PGP's and MIT's download servers run on non-standard ports (i.e. they don't run on the IANA assigned port 80 for http) and were, hence, blocked from access by me from work. The risks: Enforcing security policies blindly can actually reduce security. I was further disheartened, when I attempted to download several of PGP's latest products for the Macintosh to my home system. After answering "Yes" to several questions related to my status for distribution, I was eventually greeted with a message that said something like "We can't determine if you are located in the U.S. or Canada, so you have to go through the manual order process." I'm 99% sure that this message was generated by whatever mechanism performs IP address to hostname lookups. My TLD happens to be .NET, which is not geographically limited to the US (but, then again, neither is .COM, go figure...) The risks: Trusting DNS, Trusting the InterNIC. I then thought I would get "cute" and try using the lynx browser from the shell account that I have with my ISP. This failed, since at least part of the download process for some products required shhtp (SSL) connections and SSL was not supported by lynx. The risks: as a producer of information, disregarding low-end client software can lose some (percentage) of the total market. I then said (to myself) "what the heck." and pointed my Mac browser at http://www.anonymizer.com/ and then entered the URL for PGP's site. Lo and behold, I was eventually greeted with "You have successfully passed export restriction." I now have access to the files that I should have been able to (legally) access all along by way of "cheating." The risks: It's very probable that lots of other people have access to files that they are not legally entitled to by the same means. Other risks: The government _cannot_ control access to information once it has been made publicly available and is widespread. (At least they can't control things without resorting to means that would toss the bill of rights out the window - Apologies in advance for the US-centric view of things....) Steve@AZTech.Net (sgibbo@amex-trs.com) [NOTE ADDED LATER: I mention above using www.anonymizer.com to access export-restricted content at www.pgp.com. Unfortunately, I was misled by the message "You have successfully passed export restriction." The next page in the download sequence (that I did not follow when I wrote the original article) is secured via ssl and could not be accessed through the current incarnation of the anonymizer service. Steve]
In my first job I had to support code in which the variables were
i, ii, iii, iiii, j, jj, ...
which continued through k and l.
More recently, I worked at a place where the ENFORCED naming convention
had been to label the functions called by a program named joe thus:
joe_i_j_k... where i, j and k are integers
This meant that joe_2_3 was the third function called by the
second function called by main (the language was C). In fairness, the
convention was discontinued before I arrived. Still, there was a huge
amount of code written to the standard that had to be maintained.
I have seen code where large groups of variables were prefixed with x_,
then repeated with p_, etc. Of course you might wonder why there were
large groups of variables in the same scope at all (don't ask me).
It sometimes seems to me that our limited name-space is one of the most
significant obstacles to code re-use. Our linkers are no help at all:
if two libraries refer to the function, but expect it to behave
differently, only trouble will come of it. Strong meaningful names
fail if the only difference among various implementations are in the
time/space/re-entrancy trade-offs. There are lots of dictionary
algorithms.
The hardware solution of numbering each type of chip and providing a
huge variety to choose from is hardly appealing. Yet I have seen three
letter acronyms collide, and have been forced to work with 5 letter
prefixes on large projects. They certainly don't appear meaningful,
but they can provide a somewhat OO feel. OO languages alleviate the
problem somewhat, but we still see serious products with these ugly
prefixes. Perhaps the hardware solution will be approached asymptotically.
Risks?
* In order to reuse well-designed and tested libraries, we accept
meaningless names.
* In order for names to be meaningful, we accept that only one
can fit on a line.
* Meaningful names are 'documentation', and we will try to debug
what they mean instead of what the code is really doing.
* Someone will sell us another cure-all that doesn't.
* I will have to learn yet another naming convention.
Danny House
TELECOMMUNICATIONS & THE FUTURE OF DEMOCRACY
Preliminary Report on the First U.S. Citizens' Panel
by Dick Sclove, The Loka Institute
A 7-page report is at <http://www.amherst.edu/~loka/alerts/loka.4.3.htm>.
You can also receive the full report by e-mailing <Loka@amherst.edu>, asking
us to e-mail you "Loka Alert 4:3."
Dick Sclove, Executive Director, The Loka Institute, P.O. Box 355
Amherst, MA 01004, USA resclove@amherst.edu +(413) 582-5860
Please report problems with the web pages to the maintainer