For email opt-in, it's pretty easy. You send the subscribee a confirmation mail containing a random number string, and if they send it back (just hit 'reply' and quote the whole thing) they're confirmed.
There's a snag here. Some systems out there on the Internet allow users to set "out of office" notifications. Said systems are not always intelligent enough to notice that their "response" is not to a human.
The generally accepted best practice is to offer both a "click here to confirm" link, and "reply to this message, keeping just the line that starts with 'subscribe' if you don't have web access". There are too many systems out there that will tickle the return address without user intervention.
Some spammers are dumb as bricks, and think their audience is of the same mental composition.
I loved the message that asserted that "you" opted in from IP address 10.0.0.12. Who was this "you"? A guy called "MAILER-DAEMON@example.com. Yeah right, that convinced me that Mailer daemon subscribed to the penis enlarger info. My Mailer Daemon doesn't even _have_ a penis, dunno about theirs.
It sure does. It's the same misfeature that causes lookOut to show foo.bmp.pif as foo.bmp, and that causes Windoze to look inside the.pif to see that it is in fact a.exe. Which is precisely what the virus author intended.
This has been pointed out years before the actual viruses started to hit. This "intelligence" in the name of user friendliness is one of the bigger design flaws in Windoze.
The web server tells the browser what the content is supposed to be, and IE then cheerfully starts to to its own thing, with no override or even a warning. Not even a paperclip that tells the user that he is "correcting" the info.
Here's a hint if you want to download a URL as a bag of bytes with no interpretation: right click on it in Mozilla, select "Copy link location", type "wget " into a window and paste the URL.
An even better hint: tell the good folks at divx.com that their web server is misconfigured.
I'm not sure the Kerberos thing would be any good in court (try exlaining to a judge that SID's aren't part of any internet standard).
Much of the outrage about Microsofs stance on standards has more to do with their lack of respect (or should I just say arrogance?) In the Kerberos case, they usurped an unassigned field for data that by definition doesn't comply to any standard outside of Microsoft. I think that in this case asking nicely would not have helped them, because MIT would never have accepted an MS-only extension to Kerberos (not even if MS didn't play sillybuggers with the EULA attached to the docs for it).
In many cases however the issue is more clear-cut. Back when Windows 95 was being developed, MS wanted some extensions to PPP. So, they proposed to use four unused fields. The standards guys said "njet, you're using protocol independent fields for IP specific data. Go and do your homework and make this world a better place for all". They didn't, and left the ISP's to clean up their mess. This is one I can explain to my mother. Even a judge might grok it.
The bigger issue is not so much COM or not. For example, there's always XPCOM that was developed as part of Mozilla.
The Microsoft advantage is the Microsoft disadvantage: there is a single vendor to cast interfaces into concrete.
In practice, I'd expect the most sucessful interfaces to become available as interface libraries to UNIX tools (in your example, that OpenLDAP would come with a C# interface in much the same way that Perl interfaces are ubiquitous in UNIX).
Having a choice between "vendors" in the UNIX world has advantages and disadvantages too, but plumbing between libraries and a language is a small matter of programming. How well it can be implemented is dependent on two factors:
How well the C# interface is documented
How well the MS code is written
The latter may sound surprising, but experience shows that the hardest thing in emulating MS libs more often than not is getting the implementation bug for bug compatible.
My experience has been mostly with C libraries and Perl interfaces, and I've never lost too much time gluing stuff together. Making that glue code reusable is much harder, and is helped a lot if you have an interface specification available (Java did a lot of good work in that area, and rumor has it C# does a good job at it too).
Documentation of the interfaces is what the success in practice hinges on.
For those tuning in late, the UI for modifying an ACL on a directory gave the user two choices: either replace all underlying ACL's, or applying it just to the directory.
The first would run the risk of wiping out all ACL's at a deeper level (I've seen the results of a misguided sysadmin wiping out the ACL's of all user directories, and it ain't pretty). Not applying it recursively of course leaves you with inconsistent ACL's.
The beauty of Netware's ACL's was mentioned, but that solution would've been a serious deviation from the VMS heritage on which NT was built.
To do ACL's right on NT isn't impossible (and maybe the interface has improved since NT 4.0, the last Windows release I'm certified on:-)
But to do it right would mean designing a user interface which can do the _intended_ change (e.g., downgrade write access to readonly for user BILLG) without overwriting other restrictions. This would require a dialog such as the Word dialog when changing styles on selected text with multiple styles, which would at best be a challenge in training in its own right (how many people do you know that know how to operate the Style menus in Word? Just checking).
I've dealt with ACL's on VMS, on RACF, on Netware and on NT. The only one I liked was the only one I could explain to fledgling administrators. The fact that you can't go back and undo a change on NTFS is something that goes so badly against user expectations that it just doesn't stick.
...don't forget that our 802.11b channels have much larger asses...
Are you talking maximum rectal diameter here, or buttockprint?
If the latter, you may find that higher power doesn't always improve communication range, and in practice, the 802.11b protocol will in almost all cases use less power than the maximum allowed, making wattage a moot point. For access point density you want less power, not more.
If the former, I've got no clue how to improve on the situation.
Banks do care about check fraud (how else were these people caught?).
Checks as they are used in the US don't _exist_ in Europe any more. From the 1960 onwards, checks were actual money (they could not bounce). They died off a few years ago. The only paper still being used is in transfer forms, which you send directly to your own bank to request a money transfer to your correspondent.
One thing that banks don't like to do is absorb things, at least not the one I worked at. For example: After handling upwards of $20,000 a day, the bank still expected my cash drawer to be within $5 of what the computer said it was.
We may be talking at cross purposes here. I worked at the DP department of one of the largest Dutch banks. I don't know their exact criterion for how well the cash drawer must match the computer, but it's probably something in that ballpark. Yet, they absorb millions in losses from credit card fraud and refuse to do something about it. On the other hand, ATM fraud is always blamed on the customer, and it took some well publicized fraud cases to get them to admit that copying a card is trivial, as is shoulder surfing the PIN code. As a result, more customers refuse to use ATM machines and go to the expensive branch office (expensive to the bank, that is).
Thanks for catching my goof about sending checks in e-mail. I meant snail mail of course.
If you think that Online Banking is a way for banks to avoid a paper trail (and thus their involvement in fraud) then so be it. Don't sign up for online banking: you can still do things the old way.
Actually, I was making the opposite point: that if done right, Internet banking is more secure than paper banking. Plain passwords don't fit in there. And that is not _my_ risk assessment, it's the banks. Less paper means less handling means lower costs, and if people lose trust in paperless banking, that will cost the bank money by using expensive transfer forms.
I don't think so. For what it's worth, most banks in the Netherlands do not send checkbooks by e-mail anymore.
massive anti-fraud measures
Snicker. Those come into action long after the fraud has been committed. Dozens of teenagers have criminal records now because they assisted criminals in siphoning off money using stolen checks. The banks don't care; they absorb the losses in the unlikely even the customer can prove that the withdrawal was fraudulent, and start worrying only when national television starts camping outside their offices.
Banks over here realize that once criminals find a way to steal even small amounts of cash using electronic banking, users will lose trust in the system and will resort to more expensive ways of effecting funds transfers (which entail more risk, by the way, but the user perception is different).
Just an example of how petty thieves cause major headaches to banks: criminals would fish completed transfer forms from the banks mailbox, change the amount and the account number, and stuff the transfers back in the banks mailbox. No huge amounts of money were stolen, most of the fall guys were apprehended, but the customer response was such that almost all bank fronts were replaced to include fish proof mailboxes.
Sure, credit cards are less safe than Internet Banking, but the banks have a huge interest in securing Internet Banking and avoiding all security incidents, because the customers rack up huge costs which the banks can't recover if they fall back to paper funds transfers.
Plain text passwords are a disaster waiting to happen. Not just in the banking world.
This would be a good time to turn the RIAA on to VeriSign for aiding and abetting the illegal downloaders by providing name service for the.com domain.
I wonder when employers will be held liable for their adulterous employees. The lights are on but there doesn't seem to be anyone home in the legal system.
I'm stunned the word "password" is even in the dictionary of a banking website designer.
I've got two banks. One, the Postbank, was a pioneer in electronic banking eons ago. Their first implementation used a dialup system with one time passwords (you get a printed sheet with codes, and you have to enter one per transaction). Read-only access to your data sits behind username and password (and both are enforced to be unrelated to your name or account number).
My other bank flailed for years, and required authentication that was strong but entirely unusable. They now have a system where you get a card reader, which requires you to insert your card; the reader does a local validation of your PIN code, when it matches, the device handles challenge/response keys.
The security of the latter device is as strong as the security of the embedded chip on the card. I'm pretty sure it can be broken given time and effort, but it sure as heck beats any system where the user has to dream up a password. At least, this system requires possession of your bank card, because hypothetical hacks on the card do require you to have the physical card in your possession.
I was surprised to see one of my banks, ABN AMRO, listed as "no plans to support Opera". For those that don't know it, it is one of the bigger banks in the Netherlands, and it is not particularly know for getting electronic banking right.
I tried Galeon and regular Mozilla and found it just worked. No ActiveX crap, light (and more importantly: sensible) usage of JavaScript, and a really well thought out security model. They really seem to have had browser independance in mind when designing the software.
I'd be darn surprised if Opera doesn't just work.
Of course, The Reg is just a journalism site, so I can forgive them for not investigating it themselves, but still, this is not the right picture.
I even made a point of dropping my bank a note that they got it right, and should keep the team that built the site. I even got an answer from a sentient being on my comment!
Hmmm... A year ago I got a phone call from my US counterpart about a "PC" that was spreading Nimda.
Turned out that it was the PABX control system. It didn't run any virus protection software, because all antivirus software tested brought down the software.
Now, here's the horrible bit. The PABX itself is a solid bit of engineering, with an ASCII only bit of RS232 based interface controlling it. If those bits had even remotely been documented, anyone with experience with something as simple as expect could have coded up an interface to it in a day at most -- much less time than what was invested in bringing the Windows interface to it on line.
To this date, we're not using the advanced features of the system because just getting it to work right on the supported platform turned out to be too great a nightmare to offset the possible gains from it.
PABX interfaces are the prototypical illustration of why documenting the low level interface can benefit the advanced user without impeding sales of the "integrated" windows "solution" to customers who can deal with interfacing Windows stuff. We're as shortstaffed in Windows DDE skills as we are in low level Unix stuff, but if the RS232 interface had been documented, we could've assessed the risks and benefits of talking directly to the hardware and make an informed decision on which group should handle the PABX interface and which tools to use.
The PABX is basically on life support, because the bundled apps suck and implementing a simple toolkit that covers our basic needs is impossible for lack of docs. That, in management terms, is a "lose-lose" proposition.
Re:Assimetric aerial (and a new hobby)
on
WiFi Triangulation
·
· Score: 2
Cards can be calibrated as well.
Uh-huh. I agree. But I think I pointed out that if you control the client PC cards, you have an entirely different situation than the big brotherish scenarios where unwilling users were to be traced, that started this whole thread.
I recently made a tour of a mountain side, and according to my GPS wound up 100 meters higher than the top. To my recollection, I had at least one foot in solid contact with the mountain at any time. I checked the GPS's reported EPE and the difference between its datum and MSL, but neither could explain that difference. Signal reflection could.
My IEEE 802.11b card has an external aerial that I can orient for maximum interference (and of course, I've been toying with that to explore the interactions with my adjustable base station antenna, weren't you warned that/. is a geek site?).
Most good routers are designed to have the ability (if you enable it) to look inside of the packets
Hmmm, last I looked at the Cisco feature set (or the like from Foundry and Nortel and what have you), it was a challenge to put in rules that
a) didn't take out significant "good" traffic, and
b) did take out significant "bad" traffic.
I agree that rate limiting ICMP traffic is an appropriate answer, especially in the light of this particular attack, but I'm appalled by the number of illitarate dorks who copy snippets titled "how to block all ICMP" from a textbook into their firewall without the slightest understanding of why ICMP was implemented in the first place.
I hate to think of what could happen if the 31334 hackers really start mixing attacks.
I positively _love_ wd40, but I will not apply it to reduce the squeeking of my cars brakes. Too many people use the Internet equivalent of WD40 on their network brakes.
<toung="in cheek">The reason the site hasn't been updated that long just _might_ be that no new violations have been spotted. I've seen a huge increase of user interfaces emulating the poor aspects of physical devices (i.e., lots of wasted screen real estate, and a user interface which cannot reasonably be operated without a user manual which explains what all the silly icons mean), but those are just a repeat of the QuickTime Player debacle</toung>
Re:Assimetric aerial (and a new hobby)
on
WiFi Triangulation
·
· Score: 5, Interesting
Yes, it will confuse it.
Their method will probably even fail if you switch WiFi cards. I've got a Compaq WL110 which has a range of about 10 feet. My Lucent card on the other hand sees the access point from 100 feet, without line-of-sight (I assume the radio waves bounce off the ceiling through the window; no other way to explain _that_ range).
My access point has antennas that can be moved into different polarisations, and in an off-colour configuration, access without line-of-sight becomes really spotty: it works in one place, and a few feet to the side it stops.
But it seems to me the point of the seller is not to track abusers, but rather to track known-good devices in a known area. That alone is a cool concept, if you see what contortions people go through now when designing warehouse positioning systems. I've seen the results of an automated fork lift running through the wall of a warehouse because the reflective pad that marked the end of the aisle was covered in grime.
Hmmmm, I can envision the next hobby: sit outside a warehouse with a 2.4GHz klystron, wait until you hear the fork lift come down the aisle, then switch on the jammer and watch the fireworks:-)
Let's inform him on some of the "innovating" that Microsoft has done in the past... shall we?
I'm not someone to stand up for Microsoft, but this comparison _really_ is too easy.
What Unix users tend to forget is that Microsoft actually did some things right in Windows that Unix (or rather, the X Windows toolkits) to this date doesn't do right consistently. Take cut&paste. It's a basic feature, but the sheer scope of deviation among toolkits is just revolting. Tabbing between fields, same story.
As a matter of fact, the thing that I hold against Microsoft is precisely _not_ borrowing successful concepts from other companies. My favorite: Apple for years had a highly successful magazine for Apple Developers, called (wait for it!)... "develop". If a developer asked "develop" a question illustrated by an example, it would be answered with regards to the technology, but equally important, UI goofs would be pointed out.
If you look at MSDN, you will invariably see UI questions answered with "sure, you can do that, here's the code". No matter how counterintuitive or outright stupid the proposed UI is.
Microsoft sucks at trying to sway developers to pay attention to the looks of the UI (and, matter of fact, the WIN32 API doesn't make it particularly easy to do screen layout right), but much of the groundwork for UI behavior is done right, and screwing it up takes a conscious effort. A shocking innovation? I don't think so. Done better than the average Unix tool? You betcha.
Of course, Apple has much to answer for after they set the Dung Standard for user interfaces with their glitzy but totally unusable quicktime player.
I have the mixed pleasure of having participated in the EC comment period for the software patent law.
I wrote a small essay about what the most prominent shortcomings of the proposed practice were. My comments made it to the final report, but I felt that same report chastised my contribution together with many others for, in effect, "using my own words". I can't, and won't, write legalese. Unfortunately, the Dark Side will have its lawyers on their contributions, and by virtue of speaking the language so close to the hearts of the recipient of the comments will win on form alone.
The long and short of it: get a lawyer to review your contribution. Offer to fix his PC if that's what it takes you to get his time. Or mow his lawn. Be creative.
The hardest part of running Exchange is to find qualified administrators. I'm not talking MCSE here (I know some very capable MCSE's, but in general MCSE is not a valued qualification in my book).
A good Exchange admin can get user-visible uptimes that rival those of *NIX based solutions.
And make no mistake, top brass don't care about availability. They'll raise a stink about it and life goes on.
The "Exchange is easier" argument has been raised only anecdotally in this argument so far, which is good because it's plain untrue. It is at least as hard as setting up a *NIX solution (and chances are, Exchange will beat *NIX on functionality).
And that functionality is my pet peeve. When users look at me to prevent the next variant of Klez, I tell them that they picked the gee-whiz user friendly gooiey over my security concerns, and would they please work it out amongst themselves? It's rare that I have users who actually want all the automation nonsense, but not a single one of them has followed up on my suggestion to write to MS to get something done about the no-questions-asked automatic opening of attachments, e-mailed JavaScript and stuff.
Users don't want risk, but they can't be bothered to do something about it. So, they get what they asked for. Heaps of functionality. For their benefit, and the dubious benefits of others.
The old adage in the computer industry always was "No manager was ever fired for buying IBM". Things haven't changed that much, just the name of the upper dog.
I hear the argument about sueing a lot. I even hear it from managers who had to suffer the pain of a Microsoft audit (an audit is their way of saying "thank you" to loyal customers who MS feels haven't been stripped of cash sufficiently yet).
First of all, please don't shout. About the only thing missing from the esteemed AC's post was the tag.
I've tried to figure out how to do calendaring with open tools for the longest time (though from the other end of the spectrum, looking for a *NIX client that talks to Exchange for calendaring).
I cringe when I hear the words "protocol" and "Exchange calendaring" used in the same sentence. When I was young (but not as pretty), the word "protocol" in the context of networks involved documenting how to get at something without having to use the proprietary bits.
Apparently, Exchange 2000andsomething will change that. I'm not holding my breath.
I'm always surprised that the freedom thing comes up in these discussions. Look at the web page that this thing links to. It starts out mentioning that many "countries and companies" [sic] "routinely apply blocking".
Uh huh. And then, in the footnotes you'll find the literature references which almost exclusively point to repressive regimes.
It's pretty rare that you see privacy advocates point to blocking measures being used to increase privacy. In the case of corporations, that includes privacy w.r.t. corporate secrets, as well as privacy w.r.t. the internal infrastructure (think viruses, worms, JavaScript "window.open" bombs, etc).
For some reason, it never occurs to some privacy advocates that even at the individual level, blocking can be beneficial.
The most interesting discussion, on how democratic controls should be applied to the filtering, is rarely held.
I'm stuck in corporate hell. If dozens of users beat down my door with requests to block porn spam, then I'm not just legally justified in blocking the shit, but also morally.
It's rare that people are actually offended by it. More often than not, it's just because they lose work because they open an e-mail, and their system just locks up under the load caused by all the window.opens.
I'm fully aware that some corporate sysadmins are moralistic dorks. But I'm quite offended by the insinuation that by blocking certain web sites I'm somehow taking away my users $DEITY given rights to view certain information crucial to their civil rights.
Oh well. All evidence points to the conclusion that.mil and.k12.state.us have given up any expectation of effective censorship, for the good or for the bad. The amount of porn spams hitting my company from.mil or k12 institutions is just shocking, and maybe corporations should follow the lead of the government in just doing away with firewalls and let Al Qaida and the spammers sort it all out through economic darwinism.
It certainly is no worse that todays phone system. Every US carrier has tapping equipment (that you pay for), ostensibly for law enforcement only.
Your tax dollars at work.
With Internet, you at least have the chance that your calls get routed through China, South Korea Brazil or other rogue countries. Besides, there is way too much Internet traffic to look at.
A friend of mine worked at a big Dutch ISP, and our equivalent of the feds came and insisted they'd be allowed to place a wiretap. He showed them to the multi-wavelength fibers and wished them luck.
Besides, I'm not holding my breath for next generation wireless. Actually, I believe slow pickup will be its savior, because I just don't believe the bandwidth is there even with 3G to support the beautiful things the telcos had been promising consumers (128 kilobit/sec of data to your handheld? Either the per-byte charges will be insane, or the bandwidth will run out as fast as you can say "porn").
Telephone poles will be there for a long time in locations where burying the cable is not an option. And as long as a cable pair will bring a fast consumer connection to the Internet equivalent of a CO more reliably and cheaply than wireless, I think "fixed wireless" is a lost proposition. Until the next quantum leap in wireless comes around. With wireless, the bottleneck is measured in gigabits per square mile. With wires, it's measured in megabits per cable pair. It just doesn't add up, per square mile.
Wireless is nice as a supplement to wired. That's why i-mode is so popular: it fills an important low bandwidth niche.
Slashdot Mirror
For email opt-in, it's pretty easy. You send the subscribee a confirmation mail containing a random number string, and if they send it back (just hit 'reply' and quote the whole thing) they're confirmed.
There's a snag here. Some systems out there on the Internet allow users to set "out of office" notifications. Said systems are not always intelligent enough to notice that their "response" is not to a human.
The generally accepted best practice is to offer both a "click here to confirm" link, and "reply to this message, keeping just the line that starts with 'subscribe' if you don't have web access". There are too many systems out there that will tickle the return address without user intervention.
Some spammers are dumb as bricks, and think their audience is of the same mental composition.
I loved the message that asserted that "you" opted in from IP address 10.0.0.12. Who was this "you"? A guy called "MAILER-DAEMON@example.com. Yeah right, that convinced me that Mailer daemon subscribed to the penis enlarger info. My Mailer Daemon doesn't even _have_ a penis, dunno about theirs.
Regardless, usually the IE method works out.
.pif to see that it is in fact a .exe. Which is precisely what the virus author intended.
It sure does. It's the same misfeature that causes lookOut to show foo.bmp.pif as foo.bmp, and that causes Windoze to look inside the
This has been pointed out years before the actual viruses started to hit. This "intelligence" in the name of user friendliness is one of the bigger design flaws in Windoze.
The web server tells the browser what the content is supposed to be, and IE then cheerfully starts to to its own thing, with no override or even a warning. Not even a paperclip that tells the user that he is "correcting" the info.
Here's a hint if you want to download a URL as a bag of bytes with no interpretation: right click on it in Mozilla, select "Copy link location", type "wget " into a window and paste the URL.
An even better hint: tell the good folks at divx.com that their web server is misconfigured.
I'm not sure the Kerberos thing would be any good in court (try exlaining to a judge that SID's aren't part of any internet standard).
Much of the outrage about Microsofs stance on standards has more to do with their lack of respect (or should I just say arrogance?) In the Kerberos case, they usurped an unassigned field for data that by definition doesn't comply to any standard outside of Microsoft. I think that in this case asking nicely would not have helped them, because MIT would never have accepted an MS-only extension to Kerberos (not even if MS didn't play sillybuggers with the EULA attached to the docs for it).
In many cases however the issue is more clear-cut. Back when Windows 95 was being developed, MS wanted some extensions to PPP. So, they proposed to use four unused fields. The standards guys said "njet, you're using protocol independent fields for IP specific data. Go and do your homework and make this world a better place for all". They didn't, and left the ISP's to clean up their mess. This is one I can explain to my mother. Even a judge might grok it.
The bigger issue is not so much COM or not. For example, there's always XPCOM that was developed as part of Mozilla.
The Microsoft advantage is the Microsoft disadvantage: there is a single vendor to cast interfaces into concrete.
In practice, I'd expect the most sucessful interfaces to become available as interface libraries to UNIX tools (in your example, that OpenLDAP would come with a C# interface in much the same way that Perl interfaces are ubiquitous in UNIX).
Having a choice between "vendors" in the UNIX world has advantages and disadvantages too, but plumbing between libraries and a language is a small matter of programming. How well it can be implemented is dependent on two factors:
How well the C# interface is documented
How well the MS code is written
The latter may sound surprising, but experience shows that the hardest thing in emulating MS libs more often than not is getting the implementation bug for bug compatible.
My experience has been mostly with C libraries and Perl interfaces, and I've never lost too much time gluing stuff together. Making that glue code reusable is much harder, and is helped a lot if you have an interface specification available (Java did a lot of good work in that area, and rumor has it C# does a good job at it too).
Documentation of the interfaces is what the success in practice hinges on.
ACL's done _right_ on NT? Give me a break!
:-)
For those tuning in late, the UI for modifying an ACL on a directory gave the user two choices: either replace all underlying ACL's, or applying it just to the directory.
The first would run the risk of wiping out all ACL's at a deeper level (I've seen the results of a misguided sysadmin wiping out the ACL's of all user directories, and it ain't pretty). Not applying it recursively of course leaves you with inconsistent ACL's.
The beauty of Netware's ACL's was mentioned, but that solution would've been a serious deviation from the VMS heritage on which NT was built.
To do ACL's right on NT isn't impossible (and maybe the interface has improved since NT 4.0, the last Windows release I'm certified on
But to do it right would mean designing a user interface which can do the _intended_ change (e.g., downgrade write access to readonly for user BILLG) without overwriting other restrictions. This would require a dialog such as the Word dialog when changing styles on selected text with multiple styles, which would at best be a challenge in training in its own right (how many people do you know that know how to operate the Style menus in Word? Just checking).
I've dealt with ACL's on VMS, on RACF, on Netware and on NT. The only one I liked was the only one I could explain to fledgling administrators. The fact that you can't go back and undo a change on NTFS is something that goes so badly against user expectations that it just doesn't stick.
...don't forget that our 802.11b channels have much larger asses...
Are you talking maximum rectal diameter here, or buttockprint?
If the latter, you may find that higher power doesn't always improve communication range, and in practice, the 802.11b protocol will in almost all cases use less power than the maximum allowed, making wattage a moot point. For access point density you want less power, not more.
If the former, I've got no clue how to improve on the situation.
Banks do care about check fraud (how else were these people caught?).
Checks as they are used in the US don't _exist_ in Europe any more. From the 1960 onwards, checks were actual money (they could not bounce). They died off a few years ago. The only paper still being used is in transfer forms, which you send directly to your own bank to request a money transfer to your correspondent.
One thing that banks don't like to do is absorb things, at least not the one I worked at. For example: After handling upwards of $20,000 a day, the bank still expected my cash drawer to be within $5 of what the computer said it was.
We may be talking at cross purposes here. I worked at the DP department of one of the largest Dutch banks. I don't know their exact criterion for how well the cash drawer must match the computer, but it's probably something in that ballpark. Yet, they absorb millions in losses from credit card fraud and refuse to do something about it. On the other hand, ATM fraud is always blamed on the customer, and it took some well publicized fraud cases to get them to admit that copying a card is trivial, as is shoulder surfing the PIN code. As a result, more customers refuse to use ATM machines and go to the expensive branch office (expensive to the bank, that is).
Thanks for catching my goof about sending checks in e-mail. I meant snail mail of course.
If you think that Online Banking is a way for banks to avoid a paper trail (and thus their involvement in fraud) then so be it. Don't sign up for online banking: you can still do things the old way.
Actually, I was making the opposite point: that if done right, Internet banking is more secure than paper banking. Plain passwords don't fit in there. And that is not _my_ risk assessment, it's the banks. Less paper means less handling means lower costs, and if people lose trust in paperless banking, that will cost the bank money by using expensive transfer forms.
But let us remember that nothing is air-tight
Yes, I know.
banks rely upon the good nature of their clients
I don't think so. For what it's worth, most banks in the Netherlands do not send checkbooks by e-mail anymore.
massive anti-fraud measures
Snicker. Those come into action long after the fraud has been committed. Dozens of teenagers have criminal records now because they assisted criminals in siphoning off money using stolen checks. The banks don't care; they absorb the losses in the unlikely even the customer can prove that the withdrawal was fraudulent, and start worrying only when national television starts camping outside their offices.
Banks over here realize that once criminals find a way to steal even small amounts of cash using electronic banking, users will lose trust in the system and will resort to more expensive ways of effecting funds transfers (which entail more risk, by the way, but the user perception is different).
Just an example of how petty thieves cause major headaches to banks: criminals would fish completed transfer forms from the banks mailbox, change the amount and the account number, and stuff the transfers back in the banks mailbox. No huge amounts of money were stolen, most of the fall guys were apprehended, but the customer response was such that almost all bank fronts were replaced to include fish proof mailboxes.
Sure, credit cards are less safe than Internet Banking, but the banks have a huge interest in securing Internet Banking and avoiding all security incidents, because the customers rack up huge costs which the banks can't recover if they fall back to paper funds transfers.
Plain text passwords are a disaster waiting to happen. Not just in the banking world.
This would be a good time to turn the RIAA on to VeriSign for aiding and abetting the illegal downloaders by providing name service for the .com domain.
I wonder when employers will be held liable for their adulterous employees. The lights are on but there doesn't seem to be anyone home in the legal system.
I'm stunned the word "password" is even in the dictionary of a banking website designer.
I've got two banks. One, the Postbank, was a pioneer in electronic banking eons ago. Their first implementation used a dialup system with one time passwords (you get a printed sheet with codes, and you have to enter one per transaction). Read-only access to your data sits behind username and password (and both are enforced to be unrelated to your name or account number).
My other bank flailed for years, and required authentication that was strong but entirely unusable. They now have a system where you get a card reader, which requires you to insert your card; the reader does a local validation of your PIN code, when it matches, the device handles challenge/response keys.
The security of the latter device is as strong as the security of the embedded chip on the card. I'm pretty sure it can be broken given time and effort, but it sure as heck beats any system where the user has to dream up a password. At least, this system requires possession of your bank card, because hypothetical hacks on the card do require you to have the physical card in your possession.
I was surprised to see one of my banks, ABN AMRO, listed as "no plans to support Opera". For those that don't know it, it is one of the bigger banks in the Netherlands, and it is not particularly know for getting electronic banking right.
I tried Galeon and regular Mozilla and found it just worked. No ActiveX crap, light (and more importantly: sensible) usage of JavaScript, and a really well thought out security model. They really seem to have had browser independance in mind when designing the software.
I'd be darn surprised if Opera doesn't just work.
Of course, The Reg is just a journalism site, so I can forgive them for not investigating it themselves, but still, this is not the right picture.
I even made a point of dropping my bank a note that they got it right, and should keep the team that built the site. I even got an answer from a sentient being on my comment!
Hmmm... A year ago I got a phone call from my US counterpart about a "PC" that was spreading Nimda.
Turned out that it was the PABX control system. It didn't run any virus protection software, because all antivirus software tested brought down the software.
Now, here's the horrible bit. The PABX itself is a solid bit of engineering, with an ASCII only bit of RS232 based interface controlling it. If those bits had even remotely been documented, anyone with experience with something as simple as expect could have coded up an interface to it in a day at most -- much less time than what was invested in bringing the Windows interface to it on line.
To this date, we're not using the advanced features of the system because just getting it to work right on the supported platform turned out to be too great a nightmare to offset the possible gains from it.
PABX interfaces are the prototypical illustration of why documenting the low level interface can benefit the advanced user without impeding sales of the "integrated" windows "solution" to customers who can deal with interfacing Windows stuff. We're as shortstaffed in Windows DDE skills as we are in low level Unix stuff, but if the RS232 interface had been documented, we could've assessed the risks and benefits of talking directly to the hardware and make an informed decision on which group should handle the PABX interface and which tools to use.
The PABX is basically on life support, because the bundled apps suck and implementing a simple toolkit that covers our basic needs is impossible for lack of docs. That, in management terms, is a "lose-lose" proposition.
Cards can be calibrated as well.
/. is a geek site?).
Uh-huh. I agree. But I think I pointed out that if you control the client PC cards, you have an entirely different situation than the big brotherish scenarios where unwilling users were to be traced, that started this whole thread.
I recently made a tour of a mountain side, and according to my GPS wound up 100 meters higher than the top. To my recollection, I had at least one foot in solid contact with the mountain at any time. I checked the GPS's reported EPE and the difference between its datum and MSL, but neither could explain that difference. Signal reflection could.
My IEEE 802.11b card has an external aerial that I can orient for maximum interference (and of course, I've been toying with that to explore the interactions with my adjustable base station antenna, weren't you warned that
Most good routers are designed to have the ability (if you enable it) to look inside of the packets
Hmmm, last I looked at the Cisco feature set (or the like from Foundry and Nortel and what have you), it was a challenge to put in rules that
a) didn't take out significant "good" traffic, and
b) did take out significant "bad" traffic.
I agree that rate limiting ICMP traffic is an appropriate answer, especially in the light of this particular attack, but I'm appalled by the number of illitarate dorks who copy snippets titled "how to block all ICMP" from a textbook into their firewall without the slightest understanding of why ICMP was implemented in the first place.
I hate to think of what could happen if the 31334 hackers really start mixing attacks.
I positively _love_ wd40, but I will not apply it to reduce the squeeking of my cars brakes. Too many people use the Internet equivalent of WD40 on their network brakes.
I wholeheartedly agree!
<toung="in cheek">The reason the site hasn't been updated that long just _might_ be that no new violations have been spotted. I've seen a huge increase of user interfaces emulating the poor aspects of physical devices (i.e., lots of wasted screen real estate, and a user interface which cannot reasonably be operated without a user manual which explains what all the silly icons mean), but those are just a repeat of the QuickTime Player debacle</toung>
Yes, it will confuse it.
:-)
Their method will probably even fail if you switch WiFi cards. I've got a Compaq WL110 which has a range of about 10 feet. My Lucent card on the other hand sees the access point from 100 feet, without line-of-sight (I assume the radio waves bounce off the ceiling through the window; no other way to explain _that_ range).
My access point has antennas that can be moved into different polarisations, and in an off-colour configuration, access without line-of-sight becomes really spotty: it works in one place, and a few feet to the side it stops.
But it seems to me the point of the seller is not to track abusers, but rather to track known-good devices in a known area. That alone is a cool concept, if you see what contortions people go through now when designing warehouse positioning systems. I've seen the results of an automated fork lift running through the wall of a warehouse because the reflective pad that marked the end of the aisle was covered in grime.
Hmmmm, I can envision the next hobby: sit outside a warehouse with a 2.4GHz klystron, wait until you hear the fork lift come down the aisle, then switch on the jammer and watch the fireworks
Let's inform him on some of the "innovating" that Microsoft has done in the past ... shall we?
I'm not someone to stand up for Microsoft, but this comparison _really_ is too easy.
What Unix users tend to forget is that Microsoft actually did some things right in Windows that Unix (or rather, the X Windows toolkits) to this date doesn't do right consistently. Take cut&paste. It's a basic feature, but the sheer scope of deviation among toolkits is just revolting. Tabbing between fields, same story.
As a matter of fact, the thing that I hold against Microsoft is precisely _not_ borrowing successful concepts from other companies. My favorite: Apple for years had a highly successful magazine for Apple Developers, called (wait for it!)... "develop". If a developer asked "develop" a question illustrated by an example, it would be answered with regards to the technology, but equally important, UI goofs would be pointed out.
If you look at MSDN, you will invariably see UI questions answered with "sure, you can do that, here's the code". No matter how counterintuitive or outright stupid the proposed UI is.
Microsoft sucks at trying to sway developers to pay attention to the looks of the UI (and, matter of fact, the WIN32 API doesn't make it particularly easy to do screen layout right), but much of the groundwork for UI behavior is done right, and screwing it up takes a conscious effort. A shocking innovation? I don't think so. Done better than the average Unix tool? You betcha.
Of course, Apple has much to answer for after they set the Dung Standard for user interfaces with their glitzy but totally unusable quicktime player.
I have the mixed pleasure of having participated in the EC comment period for the software patent law.
I wrote a small essay about what the most prominent shortcomings of the proposed practice were. My comments made it to the final report, but I felt that same report chastised my contribution together with many others for, in effect, "using my own words". I can't, and won't, write legalese. Unfortunately, the Dark Side will have its lawyers on their contributions, and by virtue of speaking the language so close to the hearts of the recipient of the comments will win on form alone.
The long and short of it: get a lawyer to review your contribution. Offer to fix his PC if that's what it takes you to get his time. Or mow his lawn. Be creative.
One has to wonder what Microsoft payed him to ruin the governments case :-)
The hardest part of running Exchange is to find qualified administrators. I'm not talking MCSE here (I know some very capable MCSE's, but in general MCSE is not a valued qualification in my book).
A good Exchange admin can get user-visible uptimes that rival those of *NIX based solutions.
And make no mistake, top brass don't care about availability. They'll raise a stink about it and life goes on.
The "Exchange is easier" argument has been raised only anecdotally in this argument so far, which is good because it's plain untrue. It is at least as hard as setting up a *NIX solution (and chances are, Exchange will beat *NIX on functionality).
And that functionality is my pet peeve. When users look at me to prevent the next variant of Klez, I tell them that they picked the gee-whiz user friendly gooiey over my security concerns, and would they please work it out amongst themselves? It's rare that I have users who actually want all the automation nonsense, but not a single one of them has followed up on my suggestion to write to MS to get something done about the no-questions-asked automatic opening of attachments, e-mailed JavaScript and stuff.
Users don't want risk, but they can't be bothered to do something about it. So, they get what they asked for. Heaps of functionality. For their benefit, and the dubious benefits of others.
It's all down to consumer choice.
The old adage in the computer industry always was "No manager was ever fired for buying IBM". Things haven't changed that much, just the name of the upper dog.
I hear the argument about sueing a lot. I even hear it from managers who had to suffer the pain of a Microsoft audit (an audit is their way of saying "thank you" to loyal customers who MS feels haven't been stripped of cash sufficiently yet).
First of all, please don't shout. About the only thing missing from the esteemed AC's post was the tag.
I've tried to figure out how to do calendaring with open tools for the longest time (though from the other end of the spectrum, looking for a *NIX client that talks to Exchange for calendaring).
I cringe when I hear the words "protocol" and "Exchange calendaring" used in the same sentence. When I was young (but not as pretty), the word "protocol" in the context of networks involved documenting how to get at something without having to use the proprietary bits.
Apparently, Exchange 2000andsomething will change that. I'm not holding my breath.
I'm always surprised that the freedom thing comes up in these discussions. Look at the web page that this thing links to. It starts out mentioning that many "countries and companies" [sic] "routinely apply blocking".
.mil and .k12.state.us have given up any expectation of effective censorship, for the good or for the bad. The amount of porn spams hitting my company from .mil or k12 institutions is just shocking, and maybe corporations should follow the lead of the government in just doing away with firewalls and let Al Qaida and the spammers sort it all out through economic darwinism.
Uh huh. And then, in the footnotes you'll find the literature references which almost exclusively point to repressive regimes.
It's pretty rare that you see privacy advocates point to blocking measures being used to increase privacy. In the case of corporations, that includes privacy w.r.t. corporate secrets, as well as privacy w.r.t. the internal infrastructure (think viruses, worms, JavaScript "window.open" bombs, etc).
For some reason, it never occurs to some privacy advocates that even at the individual level, blocking can be beneficial.
The most interesting discussion, on how democratic controls should be applied to the filtering, is rarely held.
I'm stuck in corporate hell. If dozens of users beat down my door with requests to block porn spam, then I'm not just legally justified in blocking the shit, but also morally.
It's rare that people are actually offended by it. More often than not, it's just because they lose work because they open an e-mail, and their system just locks up under the load caused by all the window.opens.
I'm fully aware that some corporate sysadmins are moralistic dorks. But I'm quite offended by the insinuation that by blocking certain web sites I'm somehow taking away my users $DEITY given rights to view certain information crucial to their civil rights.
Oh well. All evidence points to the conclusion that
It certainly is no worse that todays phone system. Every US carrier has tapping equipment (that you pay for), ostensibly for law enforcement only.
Your tax dollars at work.
With Internet, you at least have the chance that your calls get routed through China, South Korea Brazil or other rogue countries. Besides, there is way too much Internet traffic to look at.
A friend of mine worked at a big Dutch ISP, and our equivalent of the feds came and insisted they'd be allowed to place a wiretap. He showed them to the multi-wavelength fibers and wished them luck.
Customers aren't ready for quantum leaps.
Besides, I'm not holding my breath for next generation wireless. Actually, I believe slow pickup will be its savior, because I just don't believe the bandwidth is there even with 3G to support the beautiful things the telcos had been promising consumers (128 kilobit/sec of data to your handheld? Either the per-byte charges will be insane, or the bandwidth will run out as fast as you can say "porn").
Telephone poles will be there for a long time in locations where burying the cable is not an option. And as long as a cable pair will bring a fast consumer connection to the Internet equivalent of a CO more reliably and cheaply than wireless, I think "fixed wireless" is a lost proposition. Until the next quantum leap in wireless comes around. With wireless, the bottleneck is measured in gigabits per square mile. With wires, it's measured in megabits per cable pair. It just doesn't add up, per square mile.
Wireless is nice as a supplement to wired. That's why i-mode is so popular: it fills an important low bandwidth niche.