When I first saw this, I thought of it as a natural outgrowth of a cyber cafe. They already have the basic computer equipment (for internet browsing, etc.). Why not leverage it more and pick up some extra cash?
Starbucks was already adding cyber cafe equipment, which is as close to the original purpose as leaving out newspapers (people read the newspaper and order an extra cup or two of coffee while they finish). This gives that equipment a use in the evenings when people aren't normally sitting in a cafe to read the news.
Just agreeing with the parent post. When you own your own business, you are not your own boss and you do not set your hours: your customers are and do. At best, you can choose when you will work your extra hours and what customers to pursue. However, you will find that you can't really turn away customers, just determine which to actively pursue (going door to door allows you to determine which doors, etc.).
One has *more* bosses when one owns a business, as all the customers can tell you what to do. At least when you work for someone, only that person determines your salary. On the bright side, you do have more flexibility when one of your "bosses" fires you, as you have others to pick up the slack. However, if that happens too much, you won't be able to find new customers.
/. has included articles from the NY Times for quite a while. There have been a number of complaints that it requires registration to read. The recommended solution has been to not include NY Times articles as/. links (i.e. to refuse to post a link to NY Times the same way/. would not link to an article that required monetary payment).
The "soul sucking 'Free' registration required)" is a compromise that seems to be working (I don't see the complaints that registration is required anymore). Except when people miss the joke and complain about that.
Obviously the poster read the article. T.f. it can reasonably be assumed that the poster disagrees that registration required links should be barred from/. (as paid links presumably are -- at least I've never seen one). The extraneous comment wards off those who would be offended, while at the same time implying that they are being overly sensitive. Laugh. It's/. humor.
TMDA.net makes a server to do exactly this: generate one off or expiring email addresses. You can install it on your mail server. May require Linux/Unix.
SpamGourmet is a free service that generates and handles these email addresses for you (if you do not have your own mail server).
If you are stuck on MS Windows and want to use your own mail server, MailEnable is free beer and allows catch-all addresses (all mail in a domain that isn't assigned to a specific email account goes to the catch-all account). There is also a professional version that supports web mail and other useful goodies.
Using both SPF and blacklisting is more effective than either alone. SPF requires the spammer to actually own the domain name in the From address. Also, it slows down spammers ability to make changes (they need to update the SPF records in DNS). Further, now you can blacklist *both* the domain (which costs the spammer money) and the IP (which also costs the spammer money).
Another advantage of SPF is that it prevents joe jobs and virus spams (unless they point their SPF DNS at the virus computer's IP, which would be fraudulent and illegal). RBLs success is pushing them into this. No reason to let them squeeze out.
No one solution will fix spam. It takes a variety of methods. Where one is weak, another takes up the slack.
Drop SMTP in favor of a system where email is kept on the *sending* server until you request it. Sending an email would involve sending the message envelope (sender name, etc.) along with an access key (to identify you as the actual recipient of the email). If you look at the envelope and decide to open it, then you connect to the sending server and download the rest of the message.
Why this helps:
1. It moves the burden from the receiving server to the sending server. Sending now takes up ISP bandwidth and storage rather than putting that burden on the receiver's ISP.
2. As this is kept on the *original* sender's server, there is no point in open relays. You still have to reveal the *actual* mail server that is sending the email. Same with open proxies.
3. Because of that, blacklists work. You can now blacklist the storage facility IP, which can't be hidden (otherwise you wouldn't be able to connect and get the email).
4. Virus spammers can no longer send directly to the recipient's server (unless it will also serve up the messages). They will have to use an intermediate (sending) server. This server will be able to see that it is sending loads of messages, delete the message, and cancel the envelopes.
You can do sender verification as part of this as well if you like. The public key would go into the envelope.
You do realize that image recognition is one of the *hardest* tasks to do with a computer right? It would probably be cheaper just to hire a person to respond to the challenges than to automate this. Just like it is cheaper to use people to sort parts and insert them into a machine than it is to make a robot to do it.
In and of itself, it would be computationally difficult (if it is even possible) to scan these images consistently. Implementing such a thing would increase the cost of spamming sharply (image recognition is way more resource intensive than sending email).
It's worth noting that TMDA.net includes the ability to include these kinds of challenges in the response but does not use them. Why? They aren't necessary. Spammers don't use valid email addresses to send their emails. Forget the question of whether they could automate responses; they aren't set up to receive responses, much less answer them. This is unlikely to change, as receiving responses would double the work of sending spam. Answering the responses would triple it -- even without complicated challenge systems.
What happens if they do create an automated response? They successfully get through so that... their newly validated email address can be blacklisted. If the email address is blacklisted quickly and broadly (through spamhaus or similar), then it will miss most of the intended recipients. Again, this increases the costs of sending SPAM.
No one method is not going to eliminate SPAM. Every anti-spam method has a response. However, each response increases the complexity of spamming, which reduces the profitability.
There is no CR deadlock problem. Yes, it is theoretically possible, but every Challenge/Response system has checks to handle this. In particular, if you send someone an email, TMDA.net whitelists that person. Thus, when you get their challenge, you will accept it rather than challenging.
It is true that automated systems will have trouble with challenge/response systems. After all, this is the whole point. Who cares? If you sign up for it, you can whitelist the sender. If someone else requests it for you, then they can answer the challenge (or maybe they don't need to do so, as they are already whitelisted). It would be easy enough to switch the tell a friend systems to launch the email client to send the email.
The author correctly reviews the issues with Computational Challenge systems. Mainly because those systems aren't well thought out (Thank You Microsoft).
I am unsure that public key interfaces like GPG offer much in fighting SPAM (although the encryption aspect can be useful in and of itself). Otoh, they are very good at whitelisting your own circle of friends and catching joe jobs in that circle. I have not done a more in depth study (any more than the author did) to see if they would work well in more general situations. My feeling is that domain verification like SPF is sufficient there.
The author's previous article mentioned the domain verifiers and once again missed the point. His two problems are mobile computing and domains that are host-less or vanity. He starts talking about sending email through ISP mail servers, but everyone already knows that this is incorrect. Instead, one should send through a mail server associated with the domain name by using SMTP AUTH. In general, vanity domains already come with these. Mobile computers should use these for security's sake anyway. Host-less forwarding accounts should demand that they get an SMTP server as well. Most of them already come with webmail (which has its own SMTP server) anyway. This is a downside but only a minor one.
Our security *expert* notices that POP mail authenticates in plain text by default. For some reason, he associates this with sending mail, even though POP is used by the *recipient*. Possibly POP before SMTP is the issue. Minor issue, since SMTP AUTH is strictly preferable to a POP before system.
CANSPAM only allows ISPs to sue, so the open source community cannot involve itself in CANSPAM lawsuits (except as ISPs -- members of the open source community are ISPs).
Some things you can do:
1. Make sure that all your domains have SPF ( http://spf.pobox.com ) records defined. This allows SPF aware servers to reject messages that do not come from your domain's authorized senders.
2. Use throwaway addresses to sign up for sites. For example, SpamGourmet.com provides these. Plus, you can use the TMDA.net software to generate them if you manage your own server. This reduces the burden on your legitimate mail servers.
2a. Track results from these throwaway addresses. If one starts getting spammed, check the appropriate privacy policy. If appropriate (i.e. they violated their privacy policy), take legal action.
3. Encourage your ISP to use appropriate black lists (the ones that identify actual spammers). This cuts down on spammers ability to reach customers. Remember, the point of SPAM is to make money. No money, no SPAM.
4. When you get virus SPAM, use the Received headers to determine who actually sent it. Then send their ISP a complaint. Check other emails to see if you can figure out whose computer sent it (might have the same IP number or at least similar). If you can, tell them and explain some options for clearing the virus.
5. If someone joe jobs you, then you can sue. They are fraudulently stealing your identity and blackening your name.
6. Never buy from a company that appears in a SPAM. Forward the email to their abuse department and tell them so.
Not only aren't you paying for postage, but the fact that they are paying for postage means that they are subsidizing delivery (of other mail) to your house. Delivering 10 letters doesn't cost significantly more than 1 at time of delivery (may increase travel costs). This helps keep your postal costs down by paying part of the actual deliverer's salary.
SPAM *increases* the cost to your ISP, because it uses more bandwidth and server resources without any increase in revenue.
You may want to check into SPF ( http://spf.pobox.com ). It allows you to specify an IP with an A record (presumably genevish.org is pointed at your dynamic IP with dyndns.org or similar?) as a valid sender for your domain.
This would also kill joejobs using your domain from other IPs (at least for SPF aware recipients).
In regards to 4, they had that here. Then they messed it up. What you are talking about is the initial decision. What I am talking about is *verifying* that initial decision. If they put you in the wrong machine, give you the wrong ballot, or miscode your smart card, then something needs to be done at that point to verify and catch the error. Note that this happens *after* you sign the roll (i.e. the mistake is made after correctly identifying the precinct).
Note: a simple verification method is to just have all voting districts in separate locations. Then you don't have the problem of miscoded smart cards or incorrect machines. I suppose that they could issue incorrect ballots, but not by mixing them.
The hanging chad/no hanging chad issue hid the larger issue in Florida: the punch ballot was designed badly and offered no way for the voter to truly verify that they got the result that they wanted. Due to the design, voters who thought they were voting for Gore *actually* voted for Buchanan. This was the real tragedy of that election.
Uniform standards for throwing out votes (and that is what the standard determined, the number of *legitimate* but badly indicated votes to throw out) would not have fixed this. The problem would have remained that Gore was not getting votes that were intended for him. If Bush had faced the same issue, then no big deal; mistakes cancel out. However, he did not. The place to vote for Bush was clearly indicated. The place to vote for Gore was not (Buchanan's slot was where Gore's would reasonably be: second after Bush).
Note: the problem did affect both parties, just not in that election. In general, the ballots were designed such that the major party to which the governor did not belong was the one that got screwed. In 1996, Dole got screwed by the same effect. No one complained then because it didn't affect the election: Dole would have lost both nationally (even with Florida's votes) and in Florida regardless. I'm rather glad that we at least notice when this happens in unimportant (i.e. not close enough that it made a difference) elections now.
The minor question of whether or not to count ballots that tried to correct this vote for Buchanan by also punching out the hole for Gore is almost irrelevant. The fact that so many people made that mistake (which was understandable given the horrid design of the Florida ballots) and did not correct it properly (I think that they were supposed to request a fresh blank ballot rather than try to adjust the one they had) was the immediate problem. The real problem is that the system did not enforce this.
A proper voting method should include the following characteristics:
1. Voters should know how their votes are going to be counted (i.e. to what candidates) prior to final submission.
2. Voters should be able to change their votes to reflect their true desires if miscast. The revised votes should then be reverified (see 1).
3. There should be a paper trail that is also verified (see 1) and reviseable in case of mistake (see 2). This paper (or whatever substance) trail can be used to recreate all the votes in case of a recount. It should be in human readable form, so that the voters may check their votes to see how they will be cast. In case of mistake (rather than changing one's mind), the voter should be able to reject/void that entry and replace it with a corrected version. This should not happen, but the ability should exist -- just in case.
4. Show voters their residence info (i.e. address). This info should not be recorded for privacy reasons, but it should indicate to the voters where the voting machine thinks that they live. If the residence is wrong, then the voter should get the card reprogrammed. This verifies that the voter is at the right place.
At best, it seems that these new machines provide 2 and maybe 1. Of course, 2 is not very difficult. 1 is rather useless without 3 (how do we know that the machine isn't just giving all the votes to one candidate). Combining all four is certainly technologically feasible. In fact, the mechanical voting booths which I have always used handle 1 and 2 (certainly better than Florida); the lack is in having a human readable paper trail.
I guess that it is back to the drawing board. I wonder if the ACLU, et. al. will sue the makers of the new machines to get a working system to replace them.
I never realized how unstable the US voting system was until the Florida incident. How do you know that votes are tabulated correctly in Canada and/or the UK? Maybe your Labour vote was really given to the Tory (or whatever).
Obviously, the problem *in this case* is twofold:
1. They didn't test these systems enough.
2. They have no way of fixing the problem, since they have no audit trail.
Another point is that the problem that arose is not a technological one per se. They could have made the same mistake in previous elections. If people are sent to the wrong voting booth or given the wrong ballot, you have the same effect. This is exacerbated by the fact that this is the first Presidential election since redistricting (in 2000, people may have voted in a different place). Further, the new electronic machines probably increased turnout.
Again, I say: "How do you know that your ballots are counted correctly?" How do you know that you (and everyone else) filled out the correct ballot (the actual problem here)? How do you know that the way you (and everyone else) filled out the ballot is the way that the ballot is meant to be filled out (the problem in Florida)?
Are you really so sure of your system that you can say absolutely that it is working? On what do you base this? Lack of complaints?
Mandrake is a nice (and cutting edge) distro. Mandrake markets itself to Linux users who buy software for Linux reasons. By contrast, Lindows.com and Xandros market *directly* at people who would otherwise buy MS.
Criticizing LindowsOS/Xandros Desktop for not matching up to other Linux distros is missing the point. They are not intended to match up to other Linux distros. If you want to run Linux, forget LindowsOS/Xandros Desktop: install stock Debian (or Mandrake, Gentoo, etc.).
LindowsOS aims at people who want a cheaper alternative to Microsoft Windows. It is cheaper than MS Windows (that "high yearly fee" of $50 is cheap compared to paying $100 to update Windows and another $300 to update Office; it also gives discounts on various third party software).
Xandros Desktop is aimed at business users with an existing Microsoft network. It is designed to allow install piecemeal (buy one new Xandros machine at a time) by *MS Windows* admins (as opposed to more expensive Linux admins).
There are a variety of reasons to choose other distros over LindowsOS/Xandros Desktop. When reviewing Linux distros, this should be noted. The purpose of this article is not to review Linux distros -- it's to review alternatives to MS Windows. Lindows.com and Xandros have positioned their products in that light (largely because it is more profitable to compete against commercial software than shareware) and are reaping the benefits in terms of publicity.
For whom would you expect them to write articles? 3% of their readers? Or 90+% of their readers? Isn't it obvious?
If Linux had more than 50% of the desktop computing market, it would be the primary game development market (for PCs, what MS has now). If Linux had 20% of the desktop computing market, game developers would be forced to support it (all major games and most minor games). If Linux had 5% of the desktop computing market (what Apple traditionally had), game manufacturers would consider supporting it: note that Blizzard releases the Warcraft series for Macs.
While true that Linux can't get 100% market share without game support, this is ultimately irrelevant. With any meaningful share, Linux will get game support from the game writers. A more reasonable target is the 5% mark. That is what Macs have traditionally held. With that 5% (and momentum), Linux will be able to draw more ports in general (not just games). Apps like Dreamweaver are far more important here. I know a number of people that would happily develop on Linux if they could do so with Dreamweaver -- it makes running the local web server much easier. Plus, Linux runs resource intensive apps better than MS Windows (which is a resource hog).
Linux needs to concentrate on individual apps rather than classes of apps. Things like IDEs and CAD tools are important because people devote entire PCs *just* to running them.
The same people might devote a PC to running games, but they will want it to run *all* their games. This is not practical at this point. With 20% marketshare, possibly. With more than 50% market share, absolutely. With 3% market share? Not a chance.
For a CAD or development tool though, most people just run one. If a lean distro (e.g. Debian or Gentoo) will run their software, they will be happy to use it. CAD especially. CAD users are perfectly happy to have hardware that does *nothing* but run CAD. They will have two PCs sitting next to each other and browse slashdot on the one while waiting for the other to finish calculating an arc (CAD is a lot of hurry up and wait).
Linux is not at the point where it can undertake an end game strategy (which is what pursuing game support is) -- even if Linux were the type of entity could employ a strategy. Right now, to achieve more market share, Linux needs to be targetted at niches: low cost base PCs with browser, email, basic office (e.g. LindowsOS); low cost PCs attached to an office network (e.g. Xandros); servers (Red Hat, Debian, etc.); high end application workstations (not yet available, but the Fireworks announcement suggests that they are coming); techies, who don't mind extra work to get things running the way they want (Gentoo, Slackware, etc.)--the traditional Linux market (see Linus Torvalds: the original Linux user from back when the Linux market size was 1:) ).
Concentrating on the end game (100% support from a wide variety of apps, including games) now is just a waste of resources. Prepare for it? Sure. Concentrate? No. The primary strategy to improve game support should be to increase market share.
With Linux, the manufacturers can take something like gtkpod and customize it for *their* hardware. Not as important for the big manufacturers (they would probably prefer to write their own software), but little manufacturers can benefit from this. As Linux (in all forms) picks up more and more of the market, this advantage will increase. This is why it is good for Linux that it has passed MacOS in new installs. More and more, manufacturers will find it useful to release Linux drivers and it is easy for small manufacturers to do so.
This also might be a good time to review things like use of the LGPL and porting to MS Windows. Note that if gtkpod has both Linux and MS Windows versions, it makes sense for small manufacturers to develop to gtkpod -- they get drivers for *both* systems that way (plus Linux drivers are easy ports to Unix versions). LGPLing relevant libraries can help pull big manufacturers (e.g. HP, IBM) in to development, as they can include the LGPLed libraries in their proprietary versions. This leverages their resources to also help improve the base libraries.
IBM open sourced AFS, so there is some precedent. Of course, AFS's reliance on root servers (to integrate the different AFS cells; what allows cmu.edu to cd into mit.edu or pitt.edu) make it a stronger commercial open source candidate (i.e. potential revenue is more from leasing root server access than selling client or normal server licenses anyway). Still, anything that centralizes file serving can lead to support contracts, etc. that can justify open source development.
Open sourcing would also allow integration of open source tools like MySQL or ReiserFS.
I do a lot of work with shopping cart sites...many of them would pay to move up the spidering after making changes (e.g. US$20 to spider today rather than next month). If that's all that this is (paying to get your site spidered earlier and/or more often), then it's a good thing. Free sites will still get spidered and rankings won't get affected (except in the short term, i.e. when they would otherwise not be listed because the content hasn't been spidered yet), but sites will have the ability to speed up the spidering process if they have time dependent info (or just don't want to wait two months to get spidered after making changes).
Interestingly enough, one of the main uses I could see for this would be for news organizations to pay to get their new news spidered on a regular basis (hourly?). The intriguing part of that is that those people would be competing with Yahoo (which offers news access as one of its services).
Of course, you can also get problems long term, as they switch from a net wide scan every three months to six months to a year... All to make their frequent spider program look better.
Yes, but we don't necessarily need to go as far as what you recommend. I have no problem with requiring people to only send viruses inside zips (e.g. if sending to Sophos). That's not a big deal.
I don't particularly want to limit number of emails, because I don't really think it is necessary or particularly helpful. Nor do I want to block port 25, since it blocks legitimate traffic (e.g. I *normally* connect to port 25 of my external mail server to send email). Further, it ruins all the sender authentication systems, which are based on people connecting directly to their SMTP server rather than using their ISP's server.
Without that, we have no way of telling who is actually sending the email. We are back to the whole problem of open proxies, etc. As this is still a bigger problem than viruses sending spam, I think that this is counter productive.
SPF ( http://spf.pobox.com ) is strictly better. With SPF, mail from SPF enabled domains is restricted to particular machines. The domain manager is responsible for maintaining this. SPF blocks both open proxies *and* residential virus spams from incorrect email addresses. With SPF and SMTP Auth, the virus spams would have to give the correct email address of the sender. Then, you can report them and get their account turned off (assuming it didn't get turned off already for sending a virus).
It doesn't need to be that limited a number. With SPF ( http://spf.pobox.net ), each domain chooses its own limits. For your domain, you could designate your home PC as a trusted mail server (might need to use a dynamic DNS system for this). Thus, email that comes from you only needs to go through your SMTP server (authenticated by SPF) and the receiver's server (authenticated by an MX record).
This way we get the original poster's trusted servers *and* don't impact privacy unduly (note: the only new public information is that the DNS manager for domain.tld vouches for whatever machine as an SMTP server; if this is still too much info to hand out, don't use SPF on that domain; you might not be able to send emails to all servers from that domain any more, but those who value their privacy at that level will still have the option to accept non-SPF email). I believe that this is sufficient to get the desired effect. I also believe that something is necessary.
I'm not sure that you can automate PGP to that extent. At the very least, you would need some way for an ISP to sign a PGP key on the customer's client. Massive changes in clients (to manage, request, and verify keys) required. New configuration details required (a key server is need along with an SMTP server and a POP or IMAP server). Also, using PGP to authenticate senders is a 'bomb swats fly' method. Let PGP stick to its strong suit (privacy/encryption) and close up the spam holes with a simple sender domain authentication system (like SPF).
One of the advantages of SPF (and possibly this MS format) is that it doesn't require *any* changes from end users that already use their domain SMTP server. It only requires changes by people who send their own (presumably technical people who can figure it out) or who use a bandwidth (ISP) SMTP server that is separate from their domain server (suggested change: switch to their domain SMTP server). It allows people to make changes (for example, whitelisting SPF valid domains by default), but it doesn't require everyone to use them to work.
My biggest concern is false positives, i.e. valid email to or from me being classified as spam. SPF allows me to prove my identity. Those who use spam detection can then whitelist emails from me (and will have the knowledge to do so, since they already do spam detection). Those who do not will be unaffected. Same thing the other way. I can whitelist those who send email from SPF domains. Those who do not will get processed in the normal way.
A side note is that SPF authenticates mail sending machines. PGP authenticates people. Machines have fixed IPs and their network traffic can be blocked at the network edge if they are malicious. People can be coming from anywhere. One must receive, store, and process the email *before* classifying it. Thus, PGP doesn't reduce mail server loads at all. SPF can (authenticated but malicious domains can be blocked from connecting).
I am more concerned with the generation overhead. I can write an SPF specification by hand (plus they offer a nifty web tool to do it for you). It is human readable. An XML format can easily balloon into something that is not simply readable.
Email and DNS are both currently simple text formats. If they want to offer a new format for email and/or DNS that is XML based, that's fine (although I'm not really interested in adopting it). They can try to push the whole thing through and people can adopt it or not as they choose.
However, if they want to extend the existing formats with spam protection, it should still be a simple text format. SPF does this. It uses a standard +/- system to include/exclude certain entities from sending email. It works through DNS. No worries about commas, tabs, ends of lines, etc. DNS parsers already exist. This just adds an extra element to an existing standard.
And that is why Microsoft is using it I'm sure. They have a bunch of nice GUI tools that parse XML, so anything they do now has to be XML.
It's the same as the way they do email. If I switch to source edit view, my simple text message (e.g. Got It.) balloons into ten lines of generated HTML gobbledygook. Yes, I really need to specify the font for *each* line...even the ones that are blank.
I really hope that the standard is not set by MS. Something very simple (this is who can transmit for this domain) could turn into something ugly. I can write SPF declarations by hand. Chances are that their XML declarations will be twenty times as long and will need tools to create them. Yes, the XML parsing tools are ubiquitous, but a simple format doesn't require a parsing interface to feed you info. I see no reason not to make a human readable interface.
"Yeah but there are better ways to get it then Hummers. I'd rather have flex-time then a chance to take the company Hummer out for a spin once a month or so. I'm sure 95% of the/. readership would agree."
Sure, but why choose? They could provide *both* flex time *and* loads of goodies. Plus, stock options and high salaries. The biggest thing about the dotcoms was that they really didn't have much in the way of expenses other than bandwidth and labor. It's also worth noting that by buying these things as corporate expenses, they save the programmers buying them themselves. The company can expense these; people can't. Plus, once they IPOed, how do they *keep* the people who just became millionaires: by treating them like millionaires.
Stock options are a nice perk in stable situations, but they are really volatile in start-ups. The problem is that if the company takes off, now all your employees have enough money that they don't need you anymore. The rational thing might be to hire new employees with regular salaries; the problem was that those people would rather work for another start up and get rich.
The worst part is that people who recognized that stock prices were unrealistic were pushed aside in favor of those who were willing to ride the bubble. I remember a mutual fund manager getting fired (or at least reassigned within the company) for pulling one of Fidelity's big funds (the one that used to be run by that Lynch guy who retired in his forties) out of stocks because they were overvalued. Unfortunately, he did this a year or two before the bubble burst and thus missed part of the run up. In the end he was proven correct; stocks were over-valued at the time. The problem was that they were due to get *more* over-valued and he missed it.
The larger problem is that the incentives are screwy. Whether it's accounting (Enron/Worldcom) or investing, there is no benefit to finding problems (like unsupportable predictions of the future). It's a lot easier to just take your paycheck and go home. If something goes wrong, you can always find another job (it's not your money at risk)...eventually. However, if you don't leap on the current opportunity, you miss your chance at a big bonus.
It's an unstable system. I get to choose whether you gamble or not. If you win, I get part of your losings. If you lose, then you lose and I come out even. Obviously, it makes sense for me to always gamble your money. Worst case? *I'm right where I would have been if I didn't.* What makes this worse is that the way the system worked, I would get paid each time you won but would not pay you back when you lost.
I talked to one accountant who used to work at one of those big firms (not Arthur Andersen, but similar in size). He said that they were all like that. Finding problems meant having to do more work and not meeting your estimate. Since the accounting firm guaranteed their price (i.e. if they find things wrong, they can't charge you more to actually fix them), there was a real incentive to avoid finding problems. No malevolence/collusion involved. Just the natural evolution of a flawed system.
Slashdot Mirror
When I first saw this, I thought of it as a natural outgrowth of a cyber cafe. They already have the basic computer equipment (for internet browsing, etc.). Why not leverage it more and pick up some extra cash?
Starbucks was already adding cyber cafe equipment, which is as close to the original purpose as leaving out newspapers (people read the newspaper and order an extra cup or two of coffee while they finish). This gives that equipment a use in the evenings when people aren't normally sitting in a cafe to read the news.
Just agreeing with the parent post. When you own your own business, you are not your own boss and you do not set your hours: your customers are and do. At best, you can choose when you will work your extra hours and what customers to pursue. However, you will find that you can't really turn away customers, just determine which to actively pursue (going door to door allows you to determine which doors, etc.).
One has *more* bosses when one owns a business, as all the customers can tell you what to do. At least when you work for someone, only that person determines your salary. On the bright side, you do have more flexibility when one of your "bosses" fires you, as you have others to pick up the slack. However, if that happens too much, you won't be able to find new customers.
/. has included articles from the NY Times for quite a while. There have been a number of complaints that it requires registration to read. The recommended solution has been to not include NY Times articles as /. links (i.e. to refuse to post a link to NY Times the same way /. would not link to an article that required monetary payment).
/. (as paid links presumably are -- at least I've never seen one). The extraneous comment wards off those who would be offended, while at the same time implying that they are being overly sensitive. Laugh. It's /. humor.
The "soul sucking 'Free' registration required)" is a compromise that seems to be working (I don't see the complaints that registration is required anymore). Except when people miss the joke and complain about that.
Obviously the poster read the article. T.f. it can reasonably be assumed that the poster disagrees that registration required links should be barred from
TMDA.net makes a server to do exactly this: generate one off or expiring email addresses. You can install it on your mail server. May require Linux/Unix.
SpamGourmet is a free service that generates and handles these email addresses for you (if you do not have your own mail server).
If you are stuck on MS Windows and want to use your own mail server, MailEnable is free beer and allows catch-all addresses (all mail in a domain that isn't assigned to a specific email account goes to the catch-all account). There is also a professional version that supports web mail and other useful goodies.
Using both SPF and blacklisting is more effective than either alone. SPF requires the spammer to actually own the domain name in the From address. Also, it slows down spammers ability to make changes (they need to update the SPF records in DNS). Further, now you can blacklist *both* the domain (which costs the spammer money) and the IP (which also costs the spammer money).
Another advantage of SPF is that it prevents joe jobs and virus spams (unless they point their SPF DNS at the virus computer's IP, which would be fraudulent and illegal). RBLs success is pushing them into this. No reason to let them squeeze out.
No one solution will fix spam. It takes a variety of methods. Where one is weak, another takes up the slack.
Drop SMTP in favor of a system where email is kept on the *sending* server until you request it. Sending an email would involve sending the message envelope (sender name, etc.) along with an access key (to identify you as the actual recipient of the email). If you look at the envelope and decide to open it, then you connect to the sending server and download the rest of the message.
Why this helps:
1. It moves the burden from the receiving server to the sending server. Sending now takes up ISP bandwidth and storage rather than putting that burden on the receiver's ISP.
2. As this is kept on the *original* sender's server, there is no point in open relays. You still have to reveal the *actual* mail server that is sending the email. Same with open proxies.
3. Because of that, blacklists work. You can now blacklist the storage facility IP, which can't be hidden (otherwise you wouldn't be able to connect and get the email).
4. Virus spammers can no longer send directly to the recipient's server (unless it will also serve up the messages). They will have to use an intermediate (sending) server. This server will be able to see that it is sending loads of messages, delete the message, and cancel the envelopes.
You can do sender verification as part of this as well if you like. The public key would go into the envelope.
You do realize that image recognition is one of the *hardest* tasks to do with a computer right? It would probably be cheaper just to hire a person to respond to the challenges than to automate this. Just like it is cheaper to use people to sort parts and insert them into a machine than it is to make a robot to do it.
... their newly validated email address can be blacklisted. If the email address is blacklisted quickly and broadly (through spamhaus or similar), then it will miss most of the intended recipients. Again, this increases the costs of sending SPAM.
In and of itself, it would be computationally difficult (if it is even possible) to scan these images consistently. Implementing such a thing would increase the cost of spamming sharply (image recognition is way more resource intensive than sending email).
It's worth noting that TMDA.net includes the ability to include these kinds of challenges in the response but does not use them. Why? They aren't necessary. Spammers don't use valid email addresses to send their emails. Forget the question of whether they could automate responses; they aren't set up to receive responses, much less answer them. This is unlikely to change, as receiving responses would double the work of sending spam. Answering the responses would triple it -- even without complicated challenge systems.
What happens if they do create an automated response? They successfully get through so that
No one method is not going to eliminate SPAM. Every anti-spam method has a response. However, each response increases the complexity of spamming, which reduces the profitability.
There is no CR deadlock problem. Yes, it is theoretically possible, but every Challenge/Response system has checks to handle this. In particular, if you send someone an email, TMDA.net whitelists that person. Thus, when you get their challenge, you will accept it rather than challenging.
It is true that automated systems will have trouble with challenge/response systems. After all, this is the whole point. Who cares? If you sign up for it, you can whitelist the sender. If someone else requests it for you, then they can answer the challenge (or maybe they don't need to do so, as they are already whitelisted). It would be easy enough to switch the tell a friend systems to launch the email client to send the email.
The author correctly reviews the issues with Computational Challenge systems. Mainly because those systems aren't well thought out (Thank You Microsoft).
I am unsure that public key interfaces like GPG offer much in fighting SPAM (although the encryption aspect can be useful in and of itself). Otoh, they are very good at whitelisting your own circle of friends and catching joe jobs in that circle. I have not done a more in depth study (any more than the author did) to see if they would work well in more general situations. My feeling is that domain verification like SPF is sufficient there.
The author's previous article mentioned the domain verifiers and once again missed the point. His two problems are mobile computing and domains that are host-less or vanity. He starts talking about sending email through ISP mail servers, but everyone already knows that this is incorrect. Instead, one should send through a mail server associated with the domain name by using SMTP AUTH. In general, vanity domains already come with these. Mobile computers should use these for security's sake anyway. Host-less forwarding accounts should demand that they get an SMTP server as well. Most of them already come with webmail (which has its own SMTP server) anyway. This is a downside but only a minor one.
Our security *expert* notices that POP mail authenticates in plain text by default. For some reason, he associates this with sending mail, even though POP is used by the *recipient*. Possibly POP before SMTP is the issue. Minor issue, since SMTP AUTH is strictly preferable to a POP before system.
He does make
1. Brilliant idea
2. Apply to porn industry
3. Profit!
CANSPAM only allows ISPs to sue, so the open source community cannot involve itself in CANSPAM lawsuits (except as ISPs -- members of the open source community are ISPs).
Some things you can do:
1. Make sure that all your domains have SPF ( http://spf.pobox.com ) records defined. This allows SPF aware servers to reject messages that do not come from your domain's authorized senders.
2. Use throwaway addresses to sign up for sites. For example, SpamGourmet.com provides these. Plus, you can use the TMDA.net software to generate them if you manage your own server. This reduces the burden on your legitimate mail servers.
2a. Track results from these throwaway addresses. If one starts getting spammed, check the appropriate privacy policy. If appropriate (i.e. they violated their privacy policy), take legal action.
3. Encourage your ISP to use appropriate black lists (the ones that identify actual spammers). This cuts down on spammers ability to reach customers. Remember, the point of SPAM is to make money. No money, no SPAM.
4. When you get virus SPAM, use the Received headers to determine who actually sent it. Then send their ISP a complaint. Check other emails to see if you can figure out whose computer sent it (might have the same IP number or at least similar). If you can, tell them and explain some options for clearing the virus.
5. If someone joe jobs you, then you can sue. They are fraudulently stealing your identity and blackening your name.
6. Never buy from a company that appears in a SPAM. Forward the email to their abuse department and tell them so.
Not only aren't you paying for postage, but the fact that they are paying for postage means that they are subsidizing delivery (of other mail) to your house. Delivering 10 letters doesn't cost significantly more than 1 at time of delivery (may increase travel costs). This helps keep your postal costs down by paying part of the actual deliverer's salary.
SPAM *increases* the cost to your ISP, because it uses more bandwidth and server resources without any increase in revenue.
You may want to check into SPF ( http://spf.pobox.com ). It allows you to specify an IP with an A record (presumably genevish.org is pointed at your dynamic IP with dyndns.org or similar?) as a valid sender for your domain.
This would also kill joejobs using your domain from other IPs (at least for SPF aware recipients).
In regards to 4, they had that here. Then they messed it up. What you are talking about is the initial decision. What I am talking about is *verifying* that initial decision. If they put you in the wrong machine, give you the wrong ballot, or miscode your smart card, then something needs to be done at that point to verify and catch the error. Note that this happens *after* you sign the roll (i.e. the mistake is made after correctly identifying the precinct).
Note: a simple verification method is to just have all voting districts in separate locations. Then you don't have the problem of miscoded smart cards or incorrect machines. I suppose that they could issue incorrect ballots, but not by mixing them.
The hanging chad/no hanging chad issue hid the larger issue in Florida: the punch ballot was designed badly and offered no way for the voter to truly verify that they got the result that they wanted. Due to the design, voters who thought they were voting for Gore *actually* voted for Buchanan. This was the real tragedy of that election.
Uniform standards for throwing out votes (and that is what the standard determined, the number of *legitimate* but badly indicated votes to throw out) would not have fixed this. The problem would have remained that Gore was not getting votes that were intended for him. If Bush had faced the same issue, then no big deal; mistakes cancel out. However, he did not. The place to vote for Bush was clearly indicated. The place to vote for Gore was not (Buchanan's slot was where Gore's would reasonably be: second after Bush).
Note: the problem did affect both parties, just not in that election. In general, the ballots were designed such that the major party to which the governor did not belong was the one that got screwed. In 1996, Dole got screwed by the same effect. No one complained then because it didn't affect the election: Dole would have lost both nationally (even with Florida's votes) and in Florida regardless. I'm rather glad that we at least notice when this happens in unimportant (i.e. not close enough that it made a difference) elections now.
The minor question of whether or not to count ballots that tried to correct this vote for Buchanan by also punching out the hole for Gore is almost irrelevant. The fact that so many people made that mistake (which was understandable given the horrid design of the Florida ballots) and did not correct it properly (I think that they were supposed to request a fresh blank ballot rather than try to adjust the one they had) was the immediate problem. The real problem is that the system did not enforce this.
A proper voting method should include the following characteristics:
1. Voters should know how their votes are going to be counted (i.e. to what candidates) prior to final submission.
2. Voters should be able to change their votes to reflect their true desires if miscast. The revised votes should then be reverified (see 1).
3. There should be a paper trail that is also verified (see 1) and reviseable in case of mistake (see 2). This paper (or whatever substance) trail can be used to recreate all the votes in case of a recount. It should be in human readable form, so that the voters may check their votes to see how they will be cast. In case of mistake (rather than changing one's mind), the voter should be able to reject/void that entry and replace it with a corrected version. This should not happen, but the ability should exist -- just in case.
4. Show voters their residence info (i.e. address). This info should not be recorded for privacy reasons, but it should indicate to the voters where the voting machine thinks that they live. If the residence is wrong, then the voter should get the card reprogrammed. This verifies that the voter is at the right place.
At best, it seems that these new machines provide 2 and maybe 1. Of course, 2 is not very difficult. 1 is rather useless without 3 (how do we know that the machine isn't just giving all the votes to one candidate). Combining all four is certainly technologically feasible. In fact, the mechanical voting booths which I have always used handle 1 and 2 (certainly better than Florida); the lack is in having a human readable paper trail.
I guess that it is back to the drawing board. I wonder if the ACLU, et. al. will sue the makers of the new machines to get a working system to replace them.
I never realized how unstable the US voting system was until the Florida incident. How do you know that votes are tabulated correctly in Canada and/or the UK? Maybe your Labour vote was really given to the Tory (or whatever).
Obviously, the problem *in this case* is twofold:
1. They didn't test these systems enough.
2. They have no way of fixing the problem, since they have no audit trail.
Another point is that the problem that arose is not a technological one per se. They could have made the same mistake in previous elections. If people are sent to the wrong voting booth or given the wrong ballot, you have the same effect. This is exacerbated by the fact that this is the first Presidential election since redistricting (in 2000, people may have voted in a different place). Further, the new electronic machines probably increased turnout.
Again, I say: "How do you know that your ballots are counted correctly?" How do you know that you (and everyone else) filled out the correct ballot (the actual problem here)? How do you know that the way you (and everyone else) filled out the ballot is the way that the ballot is meant to be filled out (the problem in Florida)?
Are you really so sure of your system that you can say absolutely that it is working? On what do you base this? Lack of complaints?
Mandrake is a nice (and cutting edge) distro. Mandrake markets itself to Linux users who buy software for Linux reasons. By contrast, Lindows.com and Xandros market *directly* at people who would otherwise buy MS.
Criticizing LindowsOS/Xandros Desktop for not matching up to other Linux distros is missing the point. They are not intended to match up to other Linux distros. If you want to run Linux, forget LindowsOS/Xandros Desktop: install stock Debian (or Mandrake, Gentoo, etc.).
LindowsOS aims at people who want a cheaper alternative to Microsoft Windows. It is cheaper than MS Windows (that "high yearly fee" of $50 is cheap compared to paying $100 to update Windows and another $300 to update Office; it also gives discounts on various third party software).
Xandros Desktop is aimed at business users with an existing Microsoft network. It is designed to allow install piecemeal (buy one new Xandros machine at a time) by *MS Windows* admins (as opposed to more expensive Linux admins).
There are a variety of reasons to choose other distros over LindowsOS/Xandros Desktop. When reviewing Linux distros, this should be noted. The purpose of this article is not to review Linux distros -- it's to review alternatives to MS Windows. Lindows.com and Xandros have positioned their products in that light (largely because it is more profitable to compete against commercial software than shareware) and are reaping the benefits in terms of publicity.
For whom would you expect them to write articles? 3% of their readers? Or 90+% of their readers? Isn't it obvious?
If Linux had more than 50% of the desktop computing market, it would be the primary game development market (for PCs, what MS has now). If Linux had 20% of the desktop computing market, game developers would be forced to support it (all major games and most minor games). If Linux had 5% of the desktop computing market (what Apple traditionally had), game manufacturers would consider supporting it: note that Blizzard releases the Warcraft series for Macs.
:) ).
While true that Linux can't get 100% market share without game support, this is ultimately irrelevant. With any meaningful share, Linux will get game support from the game writers. A more reasonable target is the 5% mark. That is what Macs have traditionally held. With that 5% (and momentum), Linux will be able to draw more ports in general (not just games). Apps like Dreamweaver are far more important here. I know a number of people that would happily develop on Linux if they could do so with Dreamweaver -- it makes running the local web server much easier. Plus, Linux runs resource intensive apps better than MS Windows (which is a resource hog).
Linux needs to concentrate on individual apps rather than classes of apps. Things like IDEs and CAD tools are important because people devote entire PCs *just* to running them.
The same people might devote a PC to running games, but they will want it to run *all* their games. This is not practical at this point. With 20% marketshare, possibly. With more than 50% market share, absolutely. With 3% market share? Not a chance.
For a CAD or development tool though, most people just run one. If a lean distro (e.g. Debian or Gentoo) will run their software, they will be happy to use it. CAD especially. CAD users are perfectly happy to have hardware that does *nothing* but run CAD. They will have two PCs sitting next to each other and browse slashdot on the one while waiting for the other to finish calculating an arc (CAD is a lot of hurry up and wait).
Linux is not at the point where it can undertake an end game strategy (which is what pursuing game support is) -- even if Linux were the type of entity could employ a strategy. Right now, to achieve more market share, Linux needs to be targetted at niches: low cost base PCs with browser, email, basic office (e.g. LindowsOS); low cost PCs attached to an office network (e.g. Xandros); servers (Red Hat, Debian, etc.); high end application workstations (not yet available, but the Fireworks announcement suggests that they are coming); techies, who don't mind extra work to get things running the way they want (Gentoo, Slackware, etc.)--the traditional Linux market (see Linus Torvalds: the original Linux user from back when the Linux market size was 1
Concentrating on the end game (100% support from a wide variety of apps, including games) now is just a waste of resources. Prepare for it? Sure. Concentrate? No. The primary strategy to improve game support should be to increase market share.
With Linux, the manufacturers can take something like gtkpod and customize it for *their* hardware. Not as important for the big manufacturers (they would probably prefer to write their own software), but little manufacturers can benefit from this. As Linux (in all forms) picks up more and more of the market, this advantage will increase. This is why it is good for Linux that it has passed MacOS in new installs. More and more, manufacturers will find it useful to release Linux drivers and it is easy for small manufacturers to do so.
This also might be a good time to review things like use of the LGPL and porting to MS Windows. Note that if gtkpod has both Linux and MS Windows versions, it makes sense for small manufacturers to develop to gtkpod -- they get drivers for *both* systems that way (plus Linux drivers are easy ports to Unix versions). LGPLing relevant libraries can help pull big manufacturers (e.g. HP, IBM) in to development, as they can include the LGPLed libraries in their proprietary versions. This leverages their resources to also help improve the base libraries.
IBM open sourced AFS, so there is some precedent. Of course, AFS's reliance on root servers (to integrate the different AFS cells; what allows cmu.edu to cd into mit.edu or pitt.edu) make it a stronger commercial open source candidate (i.e. potential revenue is more from leasing root server access than selling client or normal server licenses anyway). Still, anything that centralizes file serving can lead to support contracts, etc. that can justify open source development.
Open sourcing would also allow integration of open source tools like MySQL or ReiserFS.
I do a lot of work with shopping cart sites...many of them would pay to move up the spidering after making changes (e.g. US$20 to spider today rather than next month). If that's all that this is (paying to get your site spidered earlier and/or more often), then it's a good thing. Free sites will still get spidered and rankings won't get affected (except in the short term, i.e. when they would otherwise not be listed because the content hasn't been spidered yet), but sites will have the ability to speed up the spidering process if they have time dependent info (or just don't want to wait two months to get spidered after making changes).
Interestingly enough, one of the main uses I could see for this would be for news organizations to pay to get their new news spidered on a regular basis (hourly?). The intriguing part of that is that those people would be competing with Yahoo (which offers news access as one of its services).
Of course, you can also get problems long term, as they switch from a net wide scan every three months to six months to a year... All to make their frequent spider program look better.
Yes, but we don't necessarily need to go as far as what you recommend. I have no problem with requiring people to only send viruses inside zips (e.g. if sending to Sophos). That's not a big deal.
I don't particularly want to limit number of emails, because I don't really think it is necessary or particularly helpful. Nor do I want to block port 25, since it blocks legitimate traffic (e.g. I *normally* connect to port 25 of my external mail server to send email). Further, it ruins all the sender authentication systems, which are based on people connecting directly to their SMTP server rather than using their ISP's server.
Without that, we have no way of telling who is actually sending the email. We are back to the whole problem of open proxies, etc. As this is still a bigger problem than viruses sending spam, I think that this is counter productive.
SPF ( http://spf.pobox.com ) is strictly better. With SPF, mail from SPF enabled domains is restricted to particular machines. The domain manager is responsible for maintaining this. SPF blocks both open proxies *and* residential virus spams from incorrect email addresses. With SPF and SMTP Auth, the virus spams would have to give the correct email address of the sender. Then, you can report them and get their account turned off (assuming it didn't get turned off already for sending a virus).
It doesn't need to be that limited a number. With SPF ( http://spf.pobox.net ), each domain chooses its own limits. For your domain, you could designate your home PC as a trusted mail server (might need to use a dynamic DNS system for this). Thus, email that comes from you only needs to go through your SMTP server (authenticated by SPF) and the receiver's server (authenticated by an MX record).
This way we get the original poster's trusted servers *and* don't impact privacy unduly (note: the only new public information is that the DNS manager for domain.tld vouches for whatever machine as an SMTP server; if this is still too much info to hand out, don't use SPF on that domain; you might not be able to send emails to all servers from that domain any more, but those who value their privacy at that level will still have the option to accept non-SPF email). I believe that this is sufficient to get the desired effect. I also believe that something is necessary.
I'm not sure that you can automate PGP to that extent. At the very least, you would need some way for an ISP to sign a PGP key on the customer's client. Massive changes in clients (to manage, request, and verify keys) required. New configuration details required (a key server is need along with an SMTP server and a POP or IMAP server). Also, using PGP to authenticate senders is a 'bomb swats fly' method. Let PGP stick to its strong suit (privacy/encryption) and close up the spam holes with a simple sender domain authentication system (like SPF).
One of the advantages of SPF (and possibly this MS format) is that it doesn't require *any* changes from end users that already use their domain SMTP server. It only requires changes by people who send their own (presumably technical people who can figure it out) or who use a bandwidth (ISP) SMTP server that is separate from their domain server (suggested change: switch to their domain SMTP server). It allows people to make changes (for example, whitelisting SPF valid domains by default), but it doesn't require everyone to use them to work.
My biggest concern is false positives, i.e. valid email to or from me being classified as spam. SPF allows me to prove my identity. Those who use spam detection can then whitelist emails from me (and will have the knowledge to do so, since they already do spam detection). Those who do not will be unaffected. Same thing the other way. I can whitelist those who send email from SPF domains. Those who do not will get processed in the normal way.
A side note is that SPF authenticates mail sending machines. PGP authenticates people. Machines have fixed IPs and their network traffic can be blocked at the network edge if they are malicious. People can be coming from anywhere. One must receive, store, and process the email *before* classifying it. Thus, PGP doesn't reduce mail server loads at all. SPF can (authenticated but malicious domains can be blocked from connecting).
I am more concerned with the generation overhead. I can write an SPF specification by hand (plus they offer a nifty web tool to do it for you). It is human readable. An XML format can easily balloon into something that is not simply readable.
Email and DNS are both currently simple text formats. If they want to offer a new format for email and/or DNS that is XML based, that's fine (although I'm not really interested in adopting it). They can try to push the whole thing through and people can adopt it or not as they choose.
However, if they want to extend the existing formats with spam protection, it should still be a simple text format. SPF does this. It uses a standard +/- system to include/exclude certain entities from sending email. It works through DNS. No worries about commas, tabs, ends of lines, etc. DNS parsers already exist. This just adds an extra element to an existing standard.
And that is why Microsoft is using it I'm sure. They have a bunch of nice GUI tools that parse XML, so anything they do now has to be XML.
It's the same as the way they do email. If I switch to source edit view, my simple text message (e.g. Got It.) balloons into ten lines of generated HTML gobbledygook. Yes, I really need to specify the font for *each* line...even the ones that are blank.
I really hope that the standard is not set by MS. Something very simple (this is who can transmit for this domain) could turn into something ugly. I can write SPF declarations by hand. Chances are that their XML declarations will be twenty times as long and will need tools to create them. Yes, the XML parsing tools are ubiquitous, but a simple format doesn't require a parsing interface to feed you info. I see no reason not to make a human readable interface.
"Yeah but there are better ways to get it then Hummers. I'd rather have flex-time then a chance to take the company Hummer out for a spin once a month or so. I'm sure 95% of the /. readership would agree."
Sure, but why choose? They could provide *both* flex time *and* loads of goodies. Plus, stock options and high salaries. The biggest thing about the dotcoms was that they really didn't have much in the way of expenses other than bandwidth and labor. It's also worth noting that by buying these things as corporate expenses, they save the programmers buying them themselves. The company can expense these; people can't. Plus, once they IPOed, how do they *keep* the people who just became millionaires: by treating them like millionaires.
Stock options are a nice perk in stable situations, but they are really volatile in start-ups. The problem is that if the company takes off, now all your employees have enough money that they don't need you anymore. The rational thing might be to hire new employees with regular salaries; the problem was that those people would rather work for another start up and get rich.
The worst part is that people who recognized that stock prices were unrealistic were pushed aside in favor of those who were willing to ride the bubble. I remember a mutual fund manager getting fired (or at least reassigned within the company) for pulling one of Fidelity's big funds (the one that used to be run by that Lynch guy who retired in his forties) out of stocks because they were overvalued. Unfortunately, he did this a year or two before the bubble burst and thus missed part of the run up. In the end he was proven correct; stocks were over-valued at the time. The problem was that they were due to get *more* over-valued and he missed it.
The larger problem is that the incentives are screwy. Whether it's accounting (Enron/Worldcom) or investing, there is no benefit to finding problems (like unsupportable predictions of the future). It's a lot easier to just take your paycheck and go home. If something goes wrong, you can always find another job (it's not your money at risk)...eventually. However, if you don't leap on the current opportunity, you miss your chance at a big bonus.
It's an unstable system. I get to choose whether you gamble or not. If you win, I get part of your losings. If you lose, then you lose and I come out even. Obviously, it makes sense for me to always gamble your money. Worst case? *I'm right where I would have been if I didn't.* What makes this worse is that the way the system worked, I would get paid each time you won but would not pay you back when you lost.
I talked to one accountant who used to work at one of those big firms (not Arthur Andersen, but similar in size). He said that they were all like that. Finding problems meant having to do more work and not meeting your estimate. Since the accounting firm guaranteed their price (i.e. if they find things wrong, they can't charge you more to actually fix them), there was a real incentive to avoid finding problems. No malevolence/collusion involved. Just the natural evolution of a flawed system.