Yes, it is noteworthy that steganographic techniques are clearly going to be important to both sides of the "information wants to be free" vs. "access to information must be restricted" struggle.
I'm using the first phrase to encompass people whose communications could comprise everything from music/software/books/movies, through the traditional bugbears like child porn, bomb plans, drug deals, terrorist schemes, etc., up to and including subversion of the prevailing societal order (ours or your pick of oppressive foreign ones). Similarly, I use the second phrase as shorthand for the people, agencies, etc. that are out to intercept, interdict, or punish any or all of these. Note that different people will necessarily have different attitudes towards different subsets of these kinds of communication, in different contexts. Doesn't matter. They're all digital data and when you remove the entropy by compressing and encrypting, you can't tell one from the other.
Of course, given this indistinguishability, the fact that one is openly communicating encrypted information is likely to tend, quite unfairly, towards being inherently incriminating in any but the most enlightened, free society. And that will be the main value of steganography to the "information wants to be free" contingent. Because as long as we are permitted to own programmable computers and communicate at least some type of unencrypted, information-theoretically redundant, innocuous-seeming digital information -- be it music, voice, pictures, even text -- it will be possible to pass along encrypted data while utterly hiding the fact that you are using encryption.
Think about this for a second, because it is this combination of encryption and steganography, I think, that offers the real open road, the assurance that -- short of resorting to utter fascism or reverting to pre-Information Age conditions -- the "information wants to be free" side is going to win in the end, for good or for bad. (I tend to think, or at least hope fervently, that it is for good.)
It is true that the same technology is going to enable content providers to use watermarking and the like, but I think that this "double-edged sword" really has one sharp edge and one blunt one. The IWTBF side has control of the sharp edge (encryption combined with the ability to hide your use of encryption) whereas the ATIMBR side must make do with the blunt edge of watermarking and the like, which are never going to do much to hinder the copying and trading of digital information.
After all, if it can be viewed/read/listened to, then it *can* be copied. Any watermark will almost certainly turn out to be removable ultimately. The same is true of steganographically hidden encrypted information, of course, but note that the ability to destroy hidden information in an intercepted file (e.g. scramble a bunch of bits) doesn't imply that the intercepting authority can a) prove that there was hidden information in the first place, let alone b) discover it. On the other hand, a defeated watermark means a file that is no longer traceable in any way, one which can freely be passed on (with steganographically hidden encryption, if necessary) from that point on.
So ultimately, I think the battle stands more or less won, before it has really even gotten underway (after all most ostensibly illegal communication nowadays -- think MP3 trading -- isn't even being encrypted yet, let alone hidden). Short of forcibly prohibiting computer ownership and cleartext digital communication, there really is no way to evade the sharp edge of the steganographic-cryptographic sword.
I've been using Ricochet for about six or seven years now. When I lived in Berkeley, until 1998, a Ricochet modem was the main connection to the net for my home network of (then) some 12 machines. It ran at about the speed of a 56K dialup (officially they promised "28.8K modem speed," but by 1998, after numerous network improvements, I regularly got 6KB/sec downloads). In fact there was a period before 56K modems became generally available in which the Ricochet was often faster than a dialup link would have been. I didn't have a laptop at the time, so my Ricochet never left my apartment.
At $30 a month, it was a great deal -- DSL and cable modems, remember, weren't available yet, and ISDN was expensive. Even the cost of a second phone line, plus a traditional dialup ISP, would have been more than $30 a month, and I would have had to deal with the hassle of trying to maintain a 24-hour connection and a static IP (since I often made incoming connections to my machines). People who are commenting that Ricochet's problems stem from its being "slow" should remember that, back when it was "28.8K" (meaning up to 50K-60K), the fastest wired connections generally available for a reasonable price were the same speed. ("For a reasonable price" would have excluded ISDN back then).
I have both cable modem and DSL connections where I live in Los Angeles now and am very happy with multi-megabit/sec access rates. But I still think Ricochet is an awesome product. I'm writing this now in New York City, on a laptop using a Ricochet GS modem on the new, nominally "128Kb/s" high-speed network, in New York City. In another window I am VNC'd into an X session on one of my Los Angeles home boxes and have been successfully doing some fairly graphics-intensive Mathematica hacking for the past few hours, with a very acceptable responsiveness: far better than dialup. In fact, I guess I'm being a little blas\'e about it -- it's pretty mindblowing that I can sit in a cafe with a laptop and a little grey box and do serious, graphics-intensive work on a machine sitting in my apartment 2500 miles away. Not to mention websurfing, etc. etc. etc.
For now, Ricochet is the only product offering anything close to this capability. It's a bit pricy at $70/month, but I expect that will drop eventually. They're available in a number of major markets: Bay Area, New York, Los Angeles, DC, Seattle, etc. Maybe it's not a bad idea for them to hold off on expanding to other markets while they concentrate on increasing their subscribership in those key areas where they are already available. In any case, I think they have an awesome product. They have spent many, many years getting it to the point that it is at now, but the product has been awesome (by comparison with the prevailing connection standards) for the whole time. I *really* don't want to see them die (especially not as I own a certain amount of stock in the company:-), but furthermore, I really don't think they deserve to die. And I don't think they will, either, though I can see the financial difficulties and uncertainly lasting a little longer.
Kiscica
You don't know how heavy 5000 pounds is?!?!?!
on
E=MC
·
· Score: 1
I apologize in advance if the reviewer is from somwhere like Singapore or is a non-native speaker (with a name like Michael JasonSmith?!) who just happened to learn English really, really well (though in that case I'd still argue that knowing, more or less, what pounds, feet, etc. are is an essential part of English-language literacy).
If you're from USA, the UK, Canada, or Australia, then -- come on, who are you trying to fool? The big English-speaking countries have adopted the SI system to varying degrees, it's true (with the US lagging far behind everyone else), but if I'm not mistaken, everyone who grows up in any of those countries encounters Imperial units often enough that 'not knowing how heavy 5000 pounds is' would be a laughable pretension (or else evidence of severe cultural illiteracy).
Argue, if you like, that the author should, in a book about physics, use SI units. But don't claim that the use of Imperial units is an obstacle to your comprehension of the book.
Most people reading this book, after all, can safely be presumed to have graduated from elementary school. (Sadly, in the US, I suspect that using SI units exclusively would be a hardship for at least some potential readers -- a situation I do deplore).
Finally, even if we stipulate that a reader could start out having absolutely no idea how heavy pounds are, why would he/she have to keep referring to tables/the net/etc.? Once you have ascertained that a pound is a little less than half a kilogram, a mile is somewhat less than two kilometers, etc. I'm sure you'd know all you needed to mentally translate the measurements in the rest of the book. After all, precision is presumably not an issue for most of the numbers. All you really need to know is that 5000 pounds is a little more than 2 tonnes, or about the weight of a medium-sized truck.
Again, if your name ('Michael JasonSmith') is unfairly leading me to believe that you grew up in the US, UK, etc. then I apologize (though I stick to my basic point, which is that fluency in English includes a basic familiarity with the peculiar units of measurement used in everyday life in the largest English-speaking countries!)
P.S. Please don't interpret this message as being anti-SI. I am a biologist myself and, like all scientists, use SI units almost exclusively in my work (the exception being when I have to do some machining, which usually involves decimal inches). Even at home I tend to use SI units
more often than Imperial ones: I weigh myself on a kg scale and I even cook with SI-graduated utensils, relics of the years I lived in Europe. But I do live in the US now, which means that when I buy (say) fish, I have to ask for it by the pound, and when I look on a road sign, I see the distance to my destination in miles. All this of necessity leads to a gut-level familiarity with the meaning of those units, just as, when I lived in Europe, I quickly got used to asking for drinks in deciliters, fish in kilograms, and fishing line in meters!
I like the part about "locking down" part of the code to keep "geeks" from figuring out how to put cash on the card. Will people never learn that security through obscurity is no security at all? Make the mechanisms open and the encryption secure and everyone will be happy (although I suspect retrofitting NYC's Metrocard system to be truly secure would be an enormous undertaking).
It's outrageous that we should be in the thrall of a corrupt company like this. I feel that, in many ways, this sort of thing is a much more powerful argument for open source than any individual company's case history.
Just curious: how did you "nearly get arrested" because of Metrocard's deficiency?
I think the big international media companies are much more worried about Region 1 films reaching other regions of the world prior to their offiial release.
For what it's worth, I play DVDs -- and video cassettes -- produced and distributed in Hungary, and elsewhere in Europe, all the time, with no trouble. I have a dedicated Win98 box attached to my multisystem (NTSC/PAL/SECAM) TV. With Remote Selector I've never had trouble playing Hungarian and other Region 2 discs on my nominally Region 1 DVD-ROM drive. (They do come out in PAL though I'm not aware of any reason why the player couldn't show them in NTSC).
I think region coding is basically a waste of time on the part of DVD manufacturers; eventually it will be dropped entirely. I'm looking forward to that day...
One thing seems pretty clear to me: as long as site administrators keep taking down the "offending" material as soon as they get a cease-and-desist (C&D) letter from a whiny company like Digital Convergence, regardless of the strength of the company's legal position -- sending these letters is going to continue to be an effective way for companies to get want they want.
No one wants to face a lawsuit, and I can understand why individual hackers who just don't want the hassle give in so easily when they receive a C&D letter.
But surely there are *some* people out there who feel they can take the risk and stand up to nasty letters making demands with such dubious legal backing? I'd think that the CueCat flap would be a perfect place to start. Everyone seems to agree that Digital Convergence hasn't a legal leg to stand on here:
they may not even have a relevant patent
even if they did, it would not be a patent infringement to decode CueCat output and use it for any purpose whatsoever; it might be an infringement to manufacture your own CueCats (especially if you used the same "encryption"), but no one's doing that!
the anti-circumvention part of the DMCA, even if you stipulate that such an idiotic law could or should remain on the books, isn't even at issue here as no copyrighted material is being accessed by "circumventing" the CueCat encryption
Digital Convergence may regard their "encryption" as a trade secret, but it is determinedly not illegal to reverse-engineer and reveal trade secrets (it would be a different matter if someone were revealing information obtained under an NDA or other privileged position, but that is not the case here)
Digital Convergence may be hopping mad that people have reverse-engineered the CueCat and are using it for purposes that they didn't intend for it, but --- tough cookies. They certainly have the right to ask people nicely not to do it if they want, but their threatening letters are utterly spurious.
So why don't the people who are getting these letters write back, enumerate the above points, and simply refuse to take their software down?
Incidentally, since lawyers are likely to go to a site's ISP if the site admin isn't willing to budge, admins may also feel that their connectivity is at risk. It would be nice if the position of ISPs in situations like this were clarified so they could stand up to legal intimidation by saying "we are not responsible for the contents of our customers' sites and refuse to intervene in disputes of this sort."
Well, it's not at all obvious to me that one system is clearly superior to the other.
*Someone* has to pay for airtime minutes, right? If Australia's system is similar to that which is almost universal in Europe, then the person who calls your cell phone pays a large per-minute charge (over and above what it would cost to call a regular phone) for the privilege.
I can certainly see some situations in which that might be preferable to cell phone users, and some in which it might not. (For instance, if you used your cell phone for business purposes, you might not want your customers to have to pay extra to reach you... then again, you might want them to think twice before calling your cell phone instead of the main office -- it really depends.)
In my particular case, I was quite happy to pay (once, at least!) for those incoming calls: they were virtually all calls from my fiancee, so it wouldn't really matter whether she or I paid -- it's our money either way.
AT&T's One Rate service is actually very convenient for us: since my account is New York based, I get a local New York number. (Note that landline phone users generally do not pay, in the US, for calls to local numbers.) When my fiancee calls the NY number, my phone rings in Los Angeles, or wherever else I happen to be. The minutes come off my cell account whether I called her or she called me, but that's the only cost, since it's a local call for her. As for the couple hundred minutes each month that result from other people calling me, for the most part, I can write those off as business expenses:-).
It's sort of an accident of history that the calling-party-pays system wasn't used here, by the way. From the early days of mobile telephony, mobile phone numbers have always been effectively indistinguishable in form from regular, landline numbers. Since US residents are used to paying no per-minute charges for local calls, and there was no way to distinguish mobile numbers from landline numbers in the same area code, a calling-party-pays system would have led to some nasty surprises and thus wasn't permitted.
All in all, I prefer (for my particular purposes, at this particular time) the "cell phone user pays" system common in the US to the "caller pays" system common elsewhere. I certainly don't see that one is inherently superior to the other. The best thing, IMHO, would be for companies to offer both alternatives (perhaps even on a single account): a regular number, with a normal local area code, to which the cell user pays for incoming calls, and a number, with a distinct distinguished area code (similar to the 900 prefix used for -- mostly disreputable -- pay services here) for calling-party-pays calls. I think this has been done, on a limited scale, in some areas here, but it hasn't really caught on so far as I know.
40 cents a minute is a ripoff, though. The cell company has your cash money in advance (and thus the interest on it that much longer), and doesn't have the expenses of billing and collection. They should be charging *less* per minute than with a monthly-billed plan.
And then expiring the minutes you've paid (dearly) for in advance is inexcusable.
I'm sure that their customer base is almost entirely composed of people with bad credit records who are desperate for cell service, which is why they can get away with the ripoff. It's a pity -- I'd love a straightforward service, whether prepaid or billed, where I pay *a reasonable rate* for only the number of minutes I use. But cell companies are making money hand over fist with the present setup and I don't see anything compelling them to stop. (Nor, honestly, do I really think legislative intervention is a good idea here. One hopes that eventually, as network development costs are amortized and the cost of providing service decreases, companies will compete on better prices and more favorable contracts and eventually things will get better. As long as the market doesn't develop into a monopoly.)
My guess is that things get lost between the cracks because companies feel that lowered customer service expectations (now that we are all used to dealing with infinitely deep phone trees, etc.) mean they can get away with eliminating trained, competent customer service agents who know how to (and have the authority to) deal with out-of-the-ordinary problems and glitches.
I had the mother of all run-ins with a different division of the same company, AT&T Wireless Services. Last year around July, I suddenly stopped being able to receive calls on my AT&T One Rate cell phone. This was actually a big inconvenience for me since I don't have a landline phone. My fault for listening to their 'it may be the only phone you'll ever need' propaganda...
For about a week the company maintained alternately that (1) that's impossible so it must be my fault, (2) it must be a technical glitch but 'cellular service is not guaranteed so there is nothing they can do about it', or (3) the problem has been reported, and no, they can't tell me when it will be fixed. Finally after one week without being able to receive incoming calls, I was informed that this was a known problem for people with New York AT&T phone accounts who were using the Los Angeles AT&T network (like me at the time -- note that this
isn't 'roaming' under the one-rate plan).
Fine. And that there was no estimate about when it would be fixed. Sorry, no, they couldn't give me any more information.
Somehow, for my $150 a month (closer to $200 with taxes), I had expected a little more.
Well, a few days later, I started receiving calls again -- everything seemed OK. I called customer service and requested a service credit for being effectively without phone service (most of my calls are incoming) for almost two weeks -- they were happy to oblige. So far so good.
Then my real problems began.
My next bill was for about $400 -- after the $50 service credit. That was a shock, to say the least, since I was always careful to keep track of minutes used and virtually never went over the 1400 minutes allotted to my plan. In fact I *knew* that I hadn't even gotten close in the previous month, on account of being virtually unable to use the phone for a week and a half!
Cursory inspection of the bill revealed the problem. Every single incoming call I had received since the problem was solved had been billed twice. AT&T charges a lot, $0.25, for minutes over your plan. Since my fiancee calls me at least once a day and we often speak for an hour or more, I had some 1000 minutes of incoming calls that month. Because of the double billing, I was over my allotment by about $250.
'OK, no problem,' I thought. It's an obvious error. Each incoming call appeared twice on the bill, once at, say, 3:17PM and once at 6:17PM. Presumably related to the three hour time difference between NY and LA. All I have to do is call AT&T up and point out that there's a bug in their billing system, and they'll fix it. End of story.
Ha ha ha.
Thus began one of the most frustrating seven-month periods of my life. It's still painful for me to think back on it! I don't want to go over every little detail, but before it was over, I had spent more than eight hours on the phone with AT&T customer service (I know it was more, because I only started keeping track in the second month) -- sent fax after fax and a couple of registered letters -- and received two more bills with incorrect charges totalling over one thousand dollars.
I was told repeatedly that there was no problem and that the bills must be correct. When this happened, I would ask the customer service rep whether he/she believed that I had purposely requested every single person who ever called me to call back three hours later and talk for the same amount of time. No? Then how did they explain the fact that every single incoming call was duplicated on the bill? They didn't know but they were sure there was no problem.
I didn't pay the disputed part of the first bill, but when the next bill came with some $200 more in phantom calls, plus late fees on the initial amount, plus charges for my calls (including being stuck on hold for more than an hour at a time) to the AT&T offices to deal with the problem -- I started to get pissed. By that time, they were admitting that there was a known double-billing problem that affected 'a few customers.' In order to get credit for the double-billed calls I would have to fax them a copy of the bill with the disputed calls circled. I did that.
The customer service supervisor reported back to me that he had indeed found double-billed calls. About 100 minutes of them. Considering that the overbilled total at that point was something like 2500 minutes, I was surprised, to say the least. Turned out the guy had used a rather stringent definition of double-billed calls: the calls had to be the same amount of time, appear next to each other on the bill -- and be billed at the same time. Since all of my double-billed calls appeared three hours apart (presumably a consequence of my being in LA with a NY phone) he caught only a couple of calls I had received while I was in New York. Never mind that I had already pointed out the three-hour difference issue and circled every single one of those calls in my fax. They weren't double-billed calls by his definition.
I received one more bill with double-minute calls before they straightened the problem out. At this point I had something like $800 in disputed charges, which I of course refused to pay, and naturally AT&T shut my service off (big problem since, again, I don't have a landline phone) and, incredibly, placed a negative entry in my credit rating (despite promising me that no such action would be taken before the issue was straightened out).
I was told over and over to just pay the disputed amount and it would be refunded if they determined that a mistake had in fact been made.
I would have loved to tell AT&T to go to hell at that point, but there were several things holding me back. First, they still were dunning me for almost $1000 in erroneous charges. Second, when I called another cell phone company (GTE), I was told (despite my otherwise spotless credit record) that because my cell service had been shut off by AT&T for $1000 in 'unpaid bills,' I would be required to pay a $800 deposit (!) if I wanted to establish service with them. Finally, aside from the week-and-a-half of unexplained non-service, I hadn't had problems with AT&T's One Rate service itself -- having a cell phone with a NY local number and no roaming charges was awfully convenient for someone like me who travels between LA and New York and mostly needs to stay in touch with people in New York. I still maintained some hope that this could all be straightened out.
Well, ultimately, of course, it was. It took four more months, during which time my service was repeatedly turned on then shut off again. It became a monthly ritual with me to be told that 'my bill was being reviewed' and that all the overbilling would be credited to my account within a month -- of course it never was, so the service would get shut off once more, and I got to spend another hour on the phone with the idiots. Eventually, though, they paid it all back -- all the overbilled calls, all the late fees, all the 'reconnection fees,' the calls to and from customer service that I wasn't supposed to be charged for but was, and so on and so on -- some $1000 all told.
What sticks in my mind most from the whole affair is this: AT&T's customer service policy was cut out to make it as difficult as possible for me to get through this ordeal. For one thing, I was virtually never allowed to speak to the same customer service rep twice. The typical sequence was this:
I'd call customer service, wait on hold for 15 minutes, then get connected to a front-line customer service person
I'd ask to speak to a supervisor right away, and be flatly refused. So I'd have to explain the whole damn story to the front-line person for the nth time.
Front-line person would look at bill, conclude that (usually) she could do nothing, and would agree to switch me to a supervisor
I'd wait on hold for 20-30 minutes. Supervisor would come on line.
I'd ask for and get supervisor's name. Let's call him (usually) Supervisor X. Supervisor X would tell me that he had no private number of his own so he couldn't give me any way to reach him.
I'd explain whole story to Supervisor X for (n+1)th time.
Supervisor X would look at bill, decide that nothing could be done until he consulted with his supervisor, to whom I would *never* be allowed to speak myself (this was a hard and fast rule which I *never* managed to circumvent -- I never got past the second level no matter how much I pleaded).
Supervisor X would *promise* to call me/fax me back as soon as problem was resolved. I'd reluctantly agree to leave ball in his court.
Supervisor would fail to call back for two-three days, phone service would be shut off again, I'd call back and...
...ask to speak to Supervisor X. Instant stone wall. Every single customer service person I ever reached swore up and down that there was no way for them to connect me to someone I had spoken to earlier.
Repeat from beginning.
So part of their tactic, I believe, was to try to wear me down by forcing me to start over each time I tried to contact them. The only good side to this was that, each time I called, I maintained a faint hope that maybe -- this time -- I'd be lucky enough to reach someone who would recognize that there was indeed a problem here, and do something about it. Never happened.
Now, it's simply impossible for me to believe that all of those customer service people could be that dense. It doesn't take a genius to realize that there is a problem with a bill in which every incoming call appears twice, to recognize a simple pattern of X-minute call at time Y followed by X-minute call at time Y+3:00. Most of those customer service representatives (supervisors all) didn't sound that stupid. So I am forced to believe that they were all being wilful 'know-nothings': that is, it was AT&T company policy to stall, to not admit, as long as possible, that there could be a serious billing error. I firmly believe that, had I paid the $1000 in extra charges, which was what AT&T seemed to believe I was obligated to do, and then tried to get my money back, I'd still be waiting today. I would not be surprised if AT&T profited significantly from this error: presumably some of the erroneous bills were paid sans complaint (I'm thinking of corporate accounts here).
All right, stepping out of anonymous cowardice here... it's not as if I were trying to hide anything.
It's not so much the fact that they'll *have* the number that bothers me -- as you point out, anyone can just get it off a check -- but the fact that, in giving it to them in this manner (according to the posted terms of use), I am authorizing them to make EFT's from (and/or to) the account forever after (there is NO option to "remove a bank account from your PayPal account" -- I checked!).
As soon as I have given them my account number, they are then authorized to execute an EFT at any time without my physical signature on a paper check: only a click or two of the mouse is necessary to approve each one. And by "verifying" my account, I agree to these terms. Again, there's no obvious way for me to withdraw my EFT authorization after "verifying."
As someone else pointed out, they offer insurance against possible fraudulent transfers from my bank account. That's good, because federal law does not protect me here as it does with, say, credit cards. With the credit card, if a fraudulent transfer does occur, the CC company has to prove that I was responsible (by omission or commission) for the fraud, else I am not liable for it. With preauthorized bank account EFTs of this sort, the situation is a lot less clear (which is why the private insurance is needed), but one thing is quite obvious: the money is GONE from my bank account until I persuade PayPal's insurer to put it back.
And that, in short, is why I don't want to link my bank account to my PayPal account.
Rafts of posts have pointed out that this box works with 'any LPD-enabled network printer,' as if that somehow meant that HP really is supporting Linux/Unix (after and just forgot to mention it (lpd being, after all, originally a Unix-based protocol).
Please read that again. All it means is that their box can (nay, must) communicate with its associated printer over the network -- port 515, lpd protocol. It doesn't mean that a Unix or Linux client can communicate *with the box* using lpd!
Now you might very well ask why you'd need to communicate with the box if you can just spool directly to the printer with lpd. In fact, you might ask why you'd need the box at all, given that your printer already must have a network port -- why not just use an lpd client on your Windows client?!
HP seems to be selling this as a better spooler that acts as an intermediary between your crappy Windows boxes and your printer's rudimentary built-in network connection. It's common practice to do this on a Windows server box because (a) Windows lpd clients are not very common and (b) network-enabled printers for some reason don't usually speak SMB and (c) the network printers don't handle spooling in a very sophisticated manner. The advantage to the box is supposed to be that it is cheaper than buying a whole new Windows server machine to do the jobbecause your Windows file server keeps going down and you don't want printing to be interrupted when it does (they actually say this, almost!)
Of course a dumpster-dived (-dove? -diven?) 486 running Linux would do this just fine and other stuff as well, as it has in our lab for years, but I can see the appeal to non-technical types who just want everything to work when they plug it in.
The box apparently does NOT support *clients* via lpd, and as such cannot really be called 'Linux-compatible.' Though I am sure it is possible to talk to it using Samba (obviously HP doesn't support this; in their FAQ they state flat out that Unix clients cannot use the box). All I can say is, 'stupid, stupid, stupid.'
Actually, you should read those question marks (which, of course, showed up as quotes on the machine I was posting from) as evidence that I rarely use a Windows machine at all: otherwise I'd be aware of that pitfall. (Also I happened to be posting that from a machine with a Hungarian keymap).
No, I certainly was not trying to "impersonate" anyone. Being a "Linux proponent," moderate or otherwise, is not really an important part of my life -- I don't spend all that much time proselytizing -- but I spend 8-10 hours a day working under Linux right now, and have spent a large part of the past 17 years of my life working under Unix systems, so I certainly feel comfortable in using that inclusive "us."
I'm not sure I understand what your beef is here. I certainly am not stipulating that Microsoft is "not all bad." I just don't believe that the fact that one of their programmers committed an inadvertent buffer overflow error is evidence of evil (if it were, then basically any assemblage of modern programmers, e.g. the loosely bound ones that are responsible for modern open source Unix distributions, would have to be judged by the same standard).
Microsoft has committed plenty of -advertent- (I know there is no such word, figure it out) acts of evil, and I have no problem with attacking them for such, though doing so hardly constitutes a major portion of my life.
Look, Microsoft was essentially irrelevant to me up until 1995 or so, since until then I rarely if ever "used" a computer -- I was too busy hacking on them, as I have been doing for the past twenty-three years or so, in the following environments: (in roughly chronological order) "bare metal", VAX VMS, LISP machines, and Unix. To this date I have written perhaps 2000 lines of code in an MS-DOS (not Windows) environment and that under duress.
Back then, the word "user" was virtually an insult, and I would have had to call you outside, BlueUndies, for characterizing me as a "Linux user":-). Nowadays, however, we are, willy nilly, almost all users some of the time, even those of us who are programmers and hackers first and foremost. And even if we are Linux users, we are using our Linux in the midst of a net saturated with Windows desktops. So Microsoft is no longer irrelevant, even to me, even if I never use their sucky software
But for heaven's sake, if we are going to attack them, let us do based on their intentional Bad Decisions and Evil Moves and not for a programming mistake that, encouraged by a long-standing flaw of our common programming environment (C and the C library!), is rampant among programmers on every platform out there!
Oh, I quite agree that this bug is extremely disturbing. It is potentially much more dangerous than the "executable attachment" problem since it can be exploited without the user having to do anything stupid first (I will resist adding "other than choose to use Outlook in the first place"). I certainly did not mean to imply in my original post that I am not disturbed by it. If I or anyone I knew used Outlook I would be tripping over myself right now to make sure it was not running, automatically checking every five or ten minutes a mail spool that, at any moment, could receive a message prefaced with the Header of Death. I just think that the blame for buffer-overrun vulnerabilities is spread very thin right now, in the sense that thousands and thousands of programmers all over the world are still writing sloppy code, under Unix as well as Windows, that fails to do appropriate bounds-checking. The designers of language libraries and perhaps even OS and hardware designers share, to some extent, some responsibility for this problem. Buffer overrun has been a well-known attack channel for -decades-. I distinctly remember writing exploits to get root on BSD vaxen back in the mid-eighties. We didn't think twice about it, and it was well-known then. rtm's worm used the same bug, a couple of years later. All hackers need to wise up about this (and library, language, and OS designers need to make it easy to avoid the error and difficult, or impossible, to commit it). I totally agree that this particular case is a bug with frightening potential consequences. I just don't think it has much to do with Microsoft per se. Disclaimer: I rarely use Microsoft products (although I do happen to be posting this very message from a machine running Internet Exploiter!) and have little regard for them. kiscica
This bug is a standard buffer overflow vulnerability, an accident, and not a design bug like automatic or near automatic execution of executable mail content (sheesh), responsible for the previous mail worms and viruses. I do not want to be seen as defending Microsoft's practices, their ideals, or their bad program designs (e.g. aforementioned executable mail content). HOWEVER, a buffer overrun bug like this is not an inherent misfeature of Microsoft's design. It's a bug plain and simple, and furthermore one that has affected and continues to affect many, many Unix programs. This could have happened to "us", in other words. (If there were a buffer overrun problem in fetchmail, for example -- there isn't, but suppose there were.) We can and should rail at Microsoft for designing in weaknesses like that which made the ILOVEYOU fiasco possible. With a buffer overflow problem, I think that the "may he who is without sin cast the first stone" principle must apply. One of their anonymous programmers made a serious mistake. Same mistake has been made, over and over, in virtually every Unix system daemon since the Epoch. They get fixed (with an alacrity usually proportional to the consequences of an exploit) and that's that. And though I passionately believe in Open Source, please note that the fact that the source for most of those daemons has been examined by thousands and thousands of people, they never got fixed all at once. For example, -every- Red Hat Linux distribution in memory has fixed some buffer overruns and introduced others.... kiscica
Ah yes, the KIM-1. Atually, I think it was made by the company that manufactured the 650x-series microprocessor (used in most of the Commodore line -- but remember the SuperPET with its Motorola 6809? -- as well as the Apple), rather than by Commodore, though if I recall correctly Commodore later purchased MOS Technology. The KIM was, I suppose, a sort of evaluation board for the 6502 -- which was one of the first really inexpensive microprocessors, costing only a few tens of dollars, compared to over a hundred for the Motorola 6800 from which its design was partly copied.
<wavylines> ...The KIM-1 was my first computer. I was 7 or so at the time and passionately into (primarily analog) electronics -- I remember it was around the time that I won the coveted privilege of wielding a soldering iron without direct adult supervision! I didn't build the KIM kit myself, of course -- soldering 40-pin DIPs wss somewhat beyond my skill level. A family friend gave me one preassembled. It was the first computer I had ever seen. In fact, I think it was virtually the first computer I was aware of. I had rececntly read the Altair series in my favorite magazine, Popular Electronics, but strangely enough it hadn't made much of an impression: I was more interested in building simple discrete analog circuits to make various sound effects.
So 6502 machine code was my first, and for a good while my only programming language. I laboriously entered the opcodes in hex on that weird little keypad, first trying out the games and amusements in the First Book of KIM, then venturing on to write my own programs. I don't think I ever even got the cassette interface working, but I didn't mind coding and recoding by hand. I remember taking the KIM and my home-built power supply along with me when my parents visited friends for an evening of chamber music. I would sit, engrossed, on a sofa, hacking on the KIM, all but oblivious to the strains of Haydn surrounding me.
My second computer was another single-board kit, this one based on a 16-bit (Texas Instruments) microproessor. It would be at least a couple of years before I started using "real" computers, with keyboards and CRT displays and "high level" languages (BASIC, that is) -- first the TRS-80 at the local Radio Shack, then the Apple II wherever I could beg time on one, then, when I was in 6th grade, finally discovering the joys of time-sharing on the PDP11/44 at the high school across the street. I was 11 by the time my parents finally gave in to my impassioned pleas for a computer with a keyboard and a screen and bought me, not the Apple II I really wanted, but a brand-new box, the Commodore VIC-20. That machine, however, meant my independence: with the money I soon made selling my VIC BBS software and other code, I was soon capable of buying an Apple. I didn't -- the Commodore 64 seemed like a better deal. Later I bought an IBM-XT, when it first came out... ten megs of disk and 320K of RAM... more than that PDP11/44 had had just a couple of years before.
as anyone who's familiar with Hungarian could tell (it isn't at all in the style of ordinary Hungarian-to-English mistranslation, or "Hunglish" as we call it). Note that the article does point out that this is a joke: >USA Today, presumably pressed for space, >published only a few of these gems, leaving the >rest to the imagination, whence has sprung the >following complete transcript: -kiscica who has worked as a Hungarian-to-English (and vice-versa) translator
Slashdot Mirror
Yes, it is noteworthy that steganographic techniques are clearly going to be important to both sides of the "information wants to be free" vs. "access to information must be restricted" struggle.
I'm using the first phrase to encompass people whose communications could comprise everything from music/software/books/movies, through the traditional bugbears like child porn, bomb plans, drug deals, terrorist schemes, etc., up to and including subversion of the prevailing societal order (ours or your pick of oppressive foreign ones). Similarly, I use the second phrase as shorthand for the people, agencies, etc. that are out to intercept, interdict, or punish any or all of these. Note that different people will necessarily have different attitudes towards different subsets of these kinds of communication, in different contexts. Doesn't matter. They're all digital data and when you remove the entropy by compressing and encrypting, you can't tell one from the other.
Of course, given this indistinguishability, the fact that one is openly communicating encrypted information is likely to tend, quite unfairly, towards being inherently incriminating in any but the most enlightened, free society. And that will be the main value of steganography to the "information wants to be free" contingent. Because as long as we are permitted to own programmable computers and communicate at least some type of unencrypted, information-theoretically redundant, innocuous-seeming digital information -- be it music, voice, pictures, even text -- it will be possible to pass along encrypted data while utterly hiding the fact that you are using encryption.
Think about this for a second, because it is this combination of encryption and steganography, I think, that offers the real open road, the assurance that -- short of resorting to utter fascism or reverting to pre-Information Age conditions -- the "information wants to be free" side is going to win in the end, for good or for bad. (I tend to think, or at least hope fervently, that it is for good.)
It is true that the same technology is going to enable content providers to use watermarking and the like, but I think that this "double-edged sword" really has one sharp edge and one blunt one. The IWTBF side has control of the sharp edge (encryption combined with the ability to hide your use of encryption) whereas the ATIMBR side must make do with the blunt edge of watermarking and the like, which are never going to do much to hinder the copying and trading of digital information.
After all, if it can be viewed/read/listened to, then it *can* be copied. Any watermark will almost certainly turn out to be removable ultimately. The same is true of steganographically hidden encrypted information, of course, but note that the ability to destroy hidden information in an intercepted file (e.g. scramble a bunch of bits) doesn't imply that the intercepting authority can a) prove that there was hidden information in the first place, let alone b) discover it. On the other hand, a defeated watermark means a file that is no longer traceable in any way, one which can freely be passed on (with steganographically hidden encryption, if necessary) from that point on.
So ultimately, I think the battle stands more or less won, before it has really even gotten underway (after all most ostensibly illegal communication nowadays -- think MP3 trading -- isn't even being encrypted yet, let alone hidden). Short of forcibly prohibiting computer ownership and cleartext digital communication, there really is no way to evade the sharp edge of the steganographic-cryptographic sword.
I've been using Ricochet for about six or seven years now. When I lived in Berkeley, until 1998, a Ricochet modem was the main connection to the net for my home network of (then) some 12 machines. It ran at about the speed of a 56K dialup (officially they promised "28.8K modem speed," but by 1998, after numerous network improvements, I regularly got 6KB/sec downloads). In fact there was a period before 56K modems became generally available in which the Ricochet was often faster than a dialup link would have been. I didn't have a laptop at the time, so my Ricochet never left my apartment. At $30 a month, it was a great deal -- DSL and cable modems, remember, weren't available yet, and ISDN was expensive. Even the cost of a second phone line, plus a traditional dialup ISP, would have been more than $30 a month, and I would have had to deal with the hassle of trying to maintain a 24-hour connection and a static IP (since I often made incoming connections to my machines). People who are commenting that Ricochet's problems stem from its being "slow" should remember that, back when it was "28.8K" (meaning up to 50K-60K), the fastest wired connections generally available for a reasonable price were the same speed. ("For a reasonable price" would have excluded ISDN back then). I have both cable modem and DSL connections where I live in Los Angeles now and am very happy with multi-megabit/sec access rates. But I still think Ricochet is an awesome product. I'm writing this now in New York City, on a laptop using a Ricochet GS modem on the new, nominally "128Kb/s" high-speed network, in New York City. In another window I am VNC'd into an X session on one of my Los Angeles home boxes and have been successfully doing some fairly graphics-intensive Mathematica hacking for the past few hours, with a very acceptable responsiveness: far better than dialup. In fact, I guess I'm being a little blas\'e about it -- it's pretty mindblowing that I can sit in a cafe with a laptop and a little grey box and do serious, graphics-intensive work on a machine sitting in my apartment 2500 miles away. Not to mention websurfing, etc. etc. etc. For now, Ricochet is the only product offering anything close to this capability. It's a bit pricy at $70/month, but I expect that will drop eventually. They're available in a number of major markets: Bay Area, New York, Los Angeles, DC, Seattle, etc. Maybe it's not a bad idea for them to hold off on expanding to other markets while they concentrate on increasing their subscribership in those key areas where they are already available. In any case, I think they have an awesome product. They have spent many, many years getting it to the point that it is at now, but the product has been awesome (by comparison with the prevailing connection standards) for the whole time. I *really* don't want to see them die (especially not as I own a certain amount of stock in the company :-), but furthermore, I really don't think they deserve to die. And I don't think they will, either, though I can see the financial difficulties and uncertainly lasting a little longer.
Kiscica
I apologize in advance if the reviewer is from somwhere like Singapore or is a non-native speaker (with a name like Michael JasonSmith?!) who just happened to learn English really, really well (though in that case I'd still argue that knowing, more or less, what pounds, feet, etc. are is an essential part of English-language literacy).
If you're from USA, the UK, Canada, or Australia, then -- come on, who are you trying to fool? The big English-speaking countries have adopted the SI system to varying degrees, it's true (with the US lagging far behind everyone else), but if I'm not mistaken, everyone who grows up in any of those countries encounters Imperial units often enough that 'not knowing how heavy 5000 pounds is' would be a laughable pretension (or else evidence of severe cultural illiteracy).
Argue, if you like, that the author should, in a book about physics, use SI units. But don't claim that the use of Imperial units is an obstacle to your comprehension of the book.
Most people reading this book, after all, can safely be presumed to have graduated from elementary school. (Sadly, in the US, I suspect that using SI units exclusively would be a hardship for at least some potential readers -- a situation I do deplore).
Finally, even if we stipulate that a reader could start out having absolutely no idea how heavy pounds are, why would he/she have to keep referring to tables/the net/etc.? Once you have ascertained that a pound is a little less than half a kilogram, a mile is somewhat less than two kilometers, etc. I'm sure you'd know all you needed to mentally translate the measurements in the rest of the book. After all, precision is presumably not an issue for most of the numbers. All you really need to know is that 5000 pounds is a little more than 2 tonnes, or about the weight of a medium-sized truck.
Again, if your name ('Michael JasonSmith') is unfairly leading me to believe that you grew up in the US, UK, etc. then I apologize (though I stick to my basic point, which is that fluency in English includes a basic familiarity with the peculiar units of measurement used in everyday life in the largest English-speaking countries!)
P.S. Please don't interpret this message as being anti-SI. I am a biologist myself and, like all scientists, use SI units almost exclusively in my work (the exception being when I have to do some machining, which usually involves decimal inches). Even at home I tend to use SI units more often than Imperial ones: I weigh myself on a kg scale and I even cook with SI-graduated utensils, relics of the years I lived in Europe. But I do live in the US now, which means that when I buy (say) fish, I have to ask for it by the pound, and when I look on a road sign, I see the distance to my destination in miles. All this of necessity leads to a gut-level familiarity with the meaning of those units, just as, when I lived in Europe, I quickly got used to asking for drinks in deciliters, fish in kilograms, and fishing line in meters!
I like the part about "locking down" part of the code to keep "geeks" from figuring out how to put cash on the card. Will people never learn that security through obscurity is no security at all? Make the mechanisms open and the encryption secure and everyone will be happy (although I suspect retrofitting NYC's Metrocard system to be truly secure would be an enormous undertaking).
It's outrageous that we should be in the thrall of a corrupt company like this. I feel that, in many ways, this sort of thing is a much more powerful argument for open source than any individual company's case history.
Just curious: how did you "nearly get arrested" because of Metrocard's deficiency?
I think the big international media companies are much more worried about Region 1 films reaching other regions of the world prior to their offiial release.
For what it's worth, I play DVDs -- and video cassettes -- produced and distributed in Hungary, and elsewhere in Europe, all the time, with no trouble. I have a dedicated Win98 box attached to my multisystem (NTSC/PAL/SECAM) TV. With Remote Selector I've never had trouble playing Hungarian and other Region 2 discs on my nominally Region 1 DVD-ROM drive. (They do come out in PAL though I'm not aware of any reason why the player couldn't show them in NTSC).
I think region coding is basically a waste of time on the part of DVD manufacturers; eventually it will be dropped entirely. I'm looking forward to that day...
Kiscica
No one wants to face a lawsuit, and I can understand why individual hackers who just don't want the hassle give in so easily when they receive a C&D letter.
But surely there are *some* people out there who feel they can take the risk and stand up to nasty letters making demands with such dubious legal backing? I'd think that the CueCat flap would be a perfect place to start. Everyone seems to agree that Digital Convergence hasn't a legal leg to stand on here:
So why don't the people who are getting these letters write back, enumerate the above points, and simply refuse to take their software down?
Incidentally, since lawyers are likely to go to a site's ISP if the site admin isn't willing to budge, admins may also feel that their connectivity is at risk. It would be nice if the position of ISPs in situations like this were clarified so they could stand up to legal intimidation by saying "we are not responsible for the contents of our customers' sites and refuse to intervene in disputes of this sort."
Well, it's not at all obvious to me that one system is clearly superior to the other.
:-).
*Someone* has to pay for airtime minutes, right? If Australia's system is similar to that which is almost universal in Europe, then the person who calls your cell phone pays a large per-minute charge (over and above what it would cost to call a regular phone) for the privilege.
I can certainly see some situations in which that might be preferable to cell phone users, and some in which it might not. (For instance, if you used your cell phone for business purposes, you might not want your customers to have to pay extra to reach you... then again, you might want them to think twice before calling your cell phone instead of the main office -- it really depends.)
In my particular case, I was quite happy to pay (once, at least!) for those incoming calls: they were virtually all calls from my fiancee, so it wouldn't really matter whether she or I paid -- it's our money either way. AT&T's One Rate service is actually very convenient for us: since my account is New York based, I get a local New York number. (Note that landline phone users generally do not pay, in the US, for calls to local numbers.) When my fiancee calls the NY number, my phone rings in Los Angeles, or wherever else I happen to be. The minutes come off my cell account whether I called her or she called me, but that's the only cost, since it's a local call for her. As for the couple hundred minutes each month that result from other people calling me, for the most part, I can write those off as business expenses
It's sort of an accident of history that the calling-party-pays system wasn't used here, by the way. From the early days of mobile telephony, mobile phone numbers have always been effectively indistinguishable in form from regular, landline numbers. Since US residents are used to paying no per-minute charges for local calls, and there was no way to distinguish mobile numbers from landline numbers in the same area code, a calling-party-pays system would have led to some nasty surprises and thus wasn't permitted.
All in all, I prefer (for my particular purposes, at this particular time) the "cell phone user pays" system common in the US to the "caller pays" system common elsewhere. I certainly don't see that one is inherently superior to the other. The best thing, IMHO, would be for companies to offer both alternatives (perhaps even on a single account): a regular number, with a normal local area code, to which the cell user pays for incoming calls, and a number, with a distinct distinguished area code (similar to the 900 prefix used for -- mostly disreputable -- pay services here) for calling-party-pays calls. I think this has been done, on a limited scale, in some areas here, but it hasn't really caught on so far as I know.
40 cents a minute is a ripoff, though. The cell company has your cash money in advance (and thus the interest on it that much longer), and doesn't have the expenses of billing and collection. They should be charging *less* per minute than with a monthly-billed plan.
And then expiring the minutes you've paid (dearly) for in advance is inexcusable.
I'm sure that their customer base is almost entirely composed of people with bad credit records who are desperate for cell service, which is why they can get away with the ripoff. It's a pity -- I'd love a straightforward service, whether prepaid or billed, where I pay *a reasonable rate* for only the number of minutes I use. But cell companies are making money hand over fist with the present setup and I don't see anything compelling them to stop. (Nor, honestly, do I really think legislative intervention is a good idea here. One hopes that eventually, as network development costs are amortized and the cost of providing service decreases, companies will compete on better prices and more favorable contracts and eventually things will get better. As long as the market doesn't develop into a monopoly.)
I had the mother of all run-ins with a different division of the same company, AT&T Wireless Services. Last year around July, I suddenly stopped being able to receive calls on my AT&T One Rate cell phone. This was actually a big inconvenience for me since I don't have a landline phone. My fault for listening to their 'it may be the only phone you'll ever need' propaganda...
For about a week the company maintained alternately that (1) that's impossible so it must be my fault, (2) it must be a technical glitch but 'cellular service is not guaranteed so there is nothing they can do about it', or (3) the problem has been reported, and no, they can't tell me when it will be fixed. Finally after one week without being able to receive incoming calls, I was informed that this was a known problem for people with New York AT&T phone accounts who were using the Los Angeles AT&T network (like me at the time -- note that this isn't 'roaming' under the one-rate plan). Fine. And that there was no estimate about when it would be fixed. Sorry, no, they couldn't give me any more information.
Somehow, for my $150 a month (closer to $200 with taxes), I had expected a little more.
Well, a few days later, I started receiving calls again -- everything seemed OK. I called customer service and requested a service credit for being effectively without phone service (most of my calls are incoming) for almost two weeks -- they were happy to oblige. So far so good.
Then my real problems began.
My next bill was for about $400 -- after the $50 service credit. That was a shock, to say the least, since I was always careful to keep track of minutes used and virtually never went over the 1400 minutes allotted to my plan. In fact I *knew* that I hadn't even gotten close in the previous month, on account of being virtually unable to use the phone for a week and a half!
Cursory inspection of the bill revealed the problem. Every single incoming call I had received since the problem was solved had been billed twice. AT&T charges a lot, $0.25, for minutes over your plan. Since my fiancee calls me at least once a day and we often speak for an hour or more, I had some 1000 minutes of incoming calls that month. Because of the double billing, I was over my allotment by about $250.
'OK, no problem,' I thought. It's an obvious error. Each incoming call appeared twice on the bill, once at, say, 3:17PM and once at 6:17PM. Presumably related to the three hour time difference between NY and LA. All I have to do is call AT&T up and point out that there's a bug in their billing system, and they'll fix it. End of story.
Ha ha ha.
Thus began one of the most frustrating seven-month periods of my life. It's still painful for me to think back on it! I don't want to go over every little detail, but before it was over, I had spent more than eight hours on the phone with AT&T customer service (I know it was more, because I only started keeping track in the second month) -- sent fax after fax and a couple of registered letters -- and received two more bills with incorrect charges totalling over one thousand dollars.
I was told repeatedly that there was no problem and that the bills must be correct. When this happened, I would ask the customer service rep whether he/she believed that I had purposely requested every single person who ever called me to call back three hours later and talk for the same amount of time. No? Then how did they explain the fact that every single incoming call was duplicated on the bill? They didn't know but they were sure there was no problem.
I didn't pay the disputed part of the first bill, but when the next bill came with some $200 more in phantom calls, plus late fees on the initial amount, plus charges for my calls (including being stuck on hold for more than an hour at a time) to the AT&T offices to deal with the problem -- I started to get pissed. By that time, they were admitting that there was a known double-billing problem that affected 'a few customers.' In order to get credit for the double-billed calls I would have to fax them a copy of the bill with the disputed calls circled. I did that.
The customer service supervisor reported back to me that he had indeed found double-billed calls. About 100 minutes of them. Considering that the overbilled total at that point was something like 2500 minutes, I was surprised, to say the least. Turned out the guy had used a rather stringent definition of double-billed calls: the calls had to be the same amount of time, appear next to each other on the bill -- and be billed at the same time. Since all of my double-billed calls appeared three hours apart (presumably a consequence of my being in LA with a NY phone) he caught only a couple of calls I had received while I was in New York. Never mind that I had already pointed out the three-hour difference issue and circled every single one of those calls in my fax. They weren't double-billed calls by his definition.
I received one more bill with double-minute calls before they straightened the problem out. At this point I had something like $800 in disputed charges, which I of course refused to pay, and naturally AT&T shut my service off (big problem since, again, I don't have a landline phone) and, incredibly, placed a negative entry in my credit rating (despite promising me that no such action would be taken before the issue was straightened out).
I was told over and over to just pay the disputed amount and it would be refunded if they determined that a mistake had in fact been made.
I would have loved to tell AT&T to go to hell at that point, but there were several things holding me back. First, they still were dunning me for almost $1000 in erroneous charges. Second, when I called another cell phone company (GTE), I was told (despite my otherwise spotless credit record) that because my cell service had been shut off by AT&T for $1000 in 'unpaid bills,' I would be required to pay a $800 deposit (!) if I wanted to establish service with them. Finally, aside from the week-and-a-half of unexplained non-service, I hadn't had problems with AT&T's One Rate service itself -- having a cell phone with a NY local number and no roaming charges was awfully convenient for someone like me who travels between LA and New York and mostly needs to stay in touch with people in New York. I still maintained some hope that this could all be straightened out.
Well, ultimately, of course, it was. It took four more months, during which time my service was repeatedly turned on then shut off again. It became a monthly ritual with me to be told that 'my bill was being reviewed' and that all the overbilling would be credited to my account within a month -- of course it never was, so the service would get shut off once more, and I got to spend another hour on the phone with the idiots. Eventually, though, they paid it all back -- all the overbilled calls, all the late fees, all the 'reconnection fees,' the calls to and from customer service that I wasn't supposed to be charged for but was, and so on and so on -- some $1000 all told.
What sticks in my mind most from the whole affair is this: AT&T's customer service policy was cut out to make it as difficult as possible for me to get through this ordeal. For one thing, I was virtually never allowed to speak to the same customer service rep twice. The typical sequence was this:
So part of their tactic, I believe, was to try to wear me down by forcing me to start over each time I tried to contact them. The only good side to this was that, each time I called, I maintained a faint hope that maybe -- this time -- I'd be lucky enough to reach someone who would recognize that there was indeed a problem here, and do something about it. Never happened.
Now, it's simply impossible for me to believe that all of those customer service people could be that dense. It doesn't take a genius to realize that there is a problem with a bill in which every incoming call appears twice, to recognize a simple pattern of X-minute call at time Y followed by X-minute call at time Y+3:00. Most of those customer service representatives (supervisors all) didn't sound that stupid. So I am forced to believe that they were all being wilful 'know-nothings': that is, it was AT&T company policy to stall, to not admit, as long as possible, that there could be a serious billing error. I firmly believe that, had I paid the $1000 in extra charges, which was what AT&T seemed to believe I was obligated to do, and then tried to get my money back, I'd still be waiting today. I would not be surprised if AT&T profited significantly from this error: presumably some of the erroneous bills were paid sans complaint (I'm thinking of corporate accounts here).
All right, stepping out of anonymous cowardice here... it's not as if I were trying to hide anything.
It's not so much the fact that they'll *have* the number that bothers me -- as you point out, anyone can just get it off a check -- but the fact that, in giving it to them in this manner (according to the posted terms of use), I am authorizing them to make EFT's from (and/or to) the account forever after (there is NO option to "remove a bank account from your PayPal account" -- I checked!).
As soon as I have given them my account number, they are then authorized to execute an EFT at any time without my physical signature on a paper check: only a click or two of the mouse is necessary to approve each one. And by "verifying" my account, I agree to these terms. Again, there's no obvious way for me to withdraw my EFT authorization after "verifying."
As someone else pointed out, they offer insurance against possible fraudulent transfers from my bank account. That's good, because federal law does not protect me here as it does with, say, credit cards. With the credit card, if a fraudulent transfer does occur, the CC company has to prove that I was responsible (by omission or commission) for the fraud, else I am not liable for it. With preauthorized bank account EFTs of this sort, the situation is a lot less clear (which is why the private insurance is needed), but one thing is quite obvious: the money is GONE from my bank account until I persuade PayPal's insurer to put it back.
And that, in short, is why I don't want to link my bank account to my PayPal account.
Kiscica
Rafts of posts have pointed out that this box works with 'any LPD-enabled network printer,' as if that somehow meant that HP really is supporting Linux/Unix (after and just forgot to mention it (lpd being, after all, originally a Unix-based protocol).
Please read that again. All it means is that their box can (nay, must) communicate with its associated printer over the network -- port 515, lpd protocol. It doesn't mean that a Unix or Linux client can communicate *with the box* using lpd!
Now you might very well ask why you'd need to communicate with the box if you can just spool directly to the printer with lpd. In fact, you might ask why you'd need the box at all, given that your printer already must have a network port -- why not just use an lpd client on your Windows client?!
HP seems to be selling this as a better spooler that acts as an intermediary between your crappy Windows boxes and your printer's rudimentary built-in network connection. It's common practice to do this on a Windows server box because (a) Windows lpd clients are not very common and (b) network-enabled printers for some reason don't usually speak SMB and (c) the network printers don't handle spooling in a very sophisticated manner. The advantage to the box is supposed to be that it is cheaper than buying a whole new Windows server machine to do the jobbecause your Windows file server keeps going down and you don't want printing to be interrupted when it does (they actually say this, almost!)
Of course a dumpster-dived (-dove? -diven?) 486 running Linux would do this just fine and other stuff as well, as it has in our lab for years, but I can see the appeal to non-technical types who just want everything to work when they plug it in.
The box apparently does NOT support *clients* via lpd, and as such cannot really be called 'Linux-compatible.' Though I am sure it is possible to talk to it using Samba (obviously HP doesn't support this; in their FAQ they state flat out that Unix clients cannot use the box). All I can say is, 'stupid, stupid, stupid.'
Ah, I see now.
Actually, you should read those question marks (which, of course, showed up as quotes on the machine I was posting from) as evidence that I rarely use a Windows machine at all: otherwise I'd be aware of that pitfall. (Also I happened to be posting that from a machine with a Hungarian keymap).
No, I certainly was not trying to "impersonate" anyone. Being a "Linux proponent," moderate or otherwise, is not really an important part of my life -- I don't spend all that much time proselytizing -- but I spend 8-10 hours a day working under Linux right now, and have spent a large part of the past 17 years of my life working under Unix systems, so I certainly feel comfortable in using that inclusive "us."
kiscica
I'm not sure I understand what your beef is here. I certainly am not stipulating that Microsoft is "not all bad." I just don't believe that the fact that one of their programmers committed an inadvertent buffer overflow error is evidence of evil (if it were, then basically any assemblage of modern programmers, e.g. the loosely bound ones that are responsible for modern open source Unix distributions, would have to be judged by the same standard).
:-). Nowadays, however, we are, willy nilly, almost all users some of the time, even those of us who are programmers and hackers first and foremost. And even if we are Linux users, we are using our Linux in the midst of a net saturated with Windows desktops. So Microsoft is no longer irrelevant, even to me, even if I never use their sucky software
Microsoft has committed plenty of -advertent- (I know there is no such word, figure it out) acts of evil, and I have no problem with attacking them for such, though doing so hardly constitutes a major portion of my life.
Look, Microsoft was essentially irrelevant to me up until 1995 or so, since until then I rarely if ever "used" a computer -- I was too busy hacking on them, as I have been doing for the past twenty-three years or so, in the following environments: (in roughly chronological order) "bare metal", VAX VMS, LISP machines, and Unix. To this date I have written perhaps 2000 lines of code in an MS-DOS (not Windows) environment and that under duress.
Back then, the word "user" was virtually an insult, and I would have had to call you outside, BlueUndies, for characterizing me as a "Linux user"
But for heaven's sake, if we are going to attack them, let us do based on their intentional Bad Decisions and Evil Moves and not for a programming mistake that, encouraged by a long-standing flaw of our common programming environment (C and the C library!), is rampant among programmers on every platform out there!
kiscica
Oh, I quite agree that this bug is extremely disturbing. It is potentially much more dangerous than the "executable attachment" problem since it can be exploited without the user having to do anything stupid first (I will resist adding "other than choose to use Outlook in the first place"). I certainly did not mean to imply in my original post that I am not disturbed by it. If I or anyone I knew used Outlook I would be tripping over myself right now to make sure it was not running, automatically checking every five or ten minutes a mail spool that, at any moment, could receive a message prefaced with the Header of Death.
I just think that the blame for buffer-overrun vulnerabilities is spread very thin right now, in the sense that thousands and thousands of programmers all over the world are still writing sloppy code, under Unix as well as Windows, that fails to do appropriate bounds-checking. The designers of language libraries and perhaps even OS and hardware designers share, to some extent, some responsibility for this problem.
Buffer overrun has been a well-known attack channel for -decades-. I distinctly remember writing exploits to get root on BSD vaxen back in the mid-eighties. We didn't think twice about it, and it was well-known then. rtm's worm used the same bug, a couple of years later.
All hackers need to wise up about this (and library, language, and OS designers need to make it easy to avoid the error and difficult, or impossible, to commit it). I totally agree that this particular case is a bug with frightening potential consequences. I just don't think it has much to do with Microsoft per se.
Disclaimer: I rarely use Microsoft products (although I do happen to be posting this very message from a machine running Internet Exploiter!) and have little regard for them.
kiscica
This bug is a standard buffer overflow vulnerability, an accident, and not a design bug like automatic or near automatic execution of executable mail content (sheesh), responsible for the previous mail worms and viruses. I do not want to be seen as defending Microsoft's practices, their ideals, or their bad program designs (e.g. aforementioned executable mail content). HOWEVER, a buffer overrun bug like this is not an inherent misfeature of Microsoft's design. It's a bug plain and simple, and furthermore one that has affected and continues to affect many, many Unix programs. This could have happened to "us", in other words. (If there were a buffer overrun problem in fetchmail, for example -- there isn't, but suppose there were.) We can and should rail at Microsoft for designing in weaknesses like that which made the ILOVEYOU fiasco possible. With a buffer overflow problem, I think that the "may he who is without sin cast the first stone" principle must apply. One of their anonymous programmers made a serious mistake. Same mistake has been made, over and over, in virtually every Unix system daemon since the Epoch. They get fixed (with an alacrity usually proportional to the consequences of an exploit) and that's that. And though I passionately believe in Open Source, please note that the fact that the source for most of those daemons has been examined by thousands and thousands of people, they never got fixed all at once. For example, -every- Red Hat Linux distribution in memory has fixed some buffer overruns and introduced others.... kiscica
<wavylines>
...The KIM-1 was my first computer. I was 7 or so at the time and passionately into (primarily analog) electronics -- I remember it was around the time that I won the coveted privilege of wielding a soldering iron without direct adult supervision! I didn't build the KIM kit myself, of course -- soldering 40-pin DIPs wss somewhat beyond my skill level. A family friend gave me one preassembled. It was the first computer I had ever seen. In fact, I think it was virtually the first computer I was aware of. I had rececntly read the Altair series in my favorite magazine, Popular Electronics, but strangely enough it hadn't made much of an impression: I was more interested in building simple discrete analog circuits to make various sound effects.
So 6502 machine code was my first, and for a good while my only programming language. I laboriously entered the opcodes in hex on that weird little keypad, first trying out the games and amusements in the First Book of KIM, then venturing on to write my own programs. I don't think I ever even got the cassette interface working, but I didn't mind coding and recoding by hand. I remember taking the KIM and my home-built power supply along with me when my parents visited friends for an evening of chamber music. I would sit, engrossed, on a sofa, hacking on the KIM, all but oblivious to the strains of Haydn surrounding me.
My second computer was another single-board kit, this one based on a 16-bit (Texas Instruments) microproessor. It would be at least a couple of years before I started using "real" computers, with keyboards and CRT displays and "high level" languages (BASIC, that is) -- first the TRS-80 at the local Radio Shack, then the Apple II wherever I could beg time on one, then, when I was in 6th grade, finally discovering the joys of time-sharing on the PDP11/44 at the high school across the street. I was 11 by the time my parents finally gave in to my impassioned pleas for a computer with a keyboard and a screen and bought me, not the Apple II I really wanted, but a brand-new box, the Commodore VIC-20. That machine, however, meant my independence: with the money I soon made selling my VIC BBS software and other code, I was soon capable of buying an Apple. I didn't -- the Commodore 64 seemed like a better deal. Later I bought an IBM-XT, when it first came out... ten megs of disk and 320K of RAM... more than that PDP11/44 had had just a couple of years before.
But I never forgot Kim.
</wavylines>
as anyone who's familiar with Hungarian could tell (it isn't at all in the style of ordinary Hungarian-to-English mistranslation, or "Hunglish" as we call it). Note that the article does point out that this is a joke:
>USA Today, presumably pressed for space,
>published only a few of these gems, leaving the
>rest to the imagination, whence has sprung the
>following complete transcript:
-kiscica
who has worked as a Hungarian-to-English (and vice-versa) translator