Uh, really weak! If someone sells me a puppy, I'm still going to have to buy dog food in the morning.
Ah, but if you buy the Microsoft Puppy you will have to buy the dog food from Microsoft. This is to ensure maxiumum customer satisfaction. And if you have questions about raising your Microsoft Puppy, there's an 800 number you can call.
It's all very well to say that spam should be stopped at the source, but how do you plan to do that? Blocklists that pressure the ISP? SPEWS is pretty effective, but Verio, UUNet and Sprint are deeply committed to spam. They won't dislodge their pet spammers until they feel financial pain. Want the government to stop spam at the source? I see lots of problems with that. One of them is the creation of another eternal government responsibility like the war on drugs. They will forever need more funding for "the war on spam" because spammers are getting more clever. These federal agencies develop a symbiotic relationship with the "problems" they're trying to "solve".
In practice, a multipronged approach will work best, combining prosecution, litigation, blocklists, content-based filtering, complaints to upstream providers and education of new users. Graham's article, in fact, shows how attempts to avoid prosecution push spammers into the arms of content-based filtering.
I don't ask for a 100% solution to spam, because any such solution will have awful side effects.
I didn't read the POPFile link. Had I read it, I would have known that POPFile is a POP Proxy. Therefore it is a good candidate for conversion to a standalone executable. In other words, given the lack of standard email hooks on the Windows platform, POPFile cleverly avails itself of the one standard to which mail clients are pretty much forced to adhere - POP3.
However while the proxy itself can live as an.exe, integration with the mail client is still desirable if the user is to categorize mail and thus "teach" the system. I guess the alternative, for naive users, is to ship the proxy with a static table of probabilities which can be periodically updated like virus definitions.
You know, on this issue, you really depress me. You are clearly not of the academic nature, so your stance toward something thats probably way above your head really frustrates part of me.
I think you may have misunderstood that comment. Since Paul Graham started talking about Bayesian filtering, there's been some tendency here to refer to all learning spam filters as Bayesian. Which results in complaints, which results in the designation "pseudo-Bayesian" for the many independently-discovered learning algorithms that don't have a theoretical underpinning.
Put another way: if an algorithm outputs a dimensionless "score", and the author can't set an upper bound on the score, it's at most pseudo-Bayesian. If it outputs a probability that the message meets certain criteria, then it could be "true Bayesian". Additional implication: the "pseudo-Bayesian" filter may have a stack of rules in addition to its table of probabilities.
I don't think we're splitting hairs on some deep statistical issue. I think we're groping for very rough categories in a new field of application software. If you can establish clearer categories, that might help.
With 1 line of regex I eliminate 95% of my spam: match and throw it out.
Graham addresses this in the article. One can identify most spam with a simple rules-based engine. That tends to make one lazy in reading the spam folder, which means false positives can languish unread. Enhancing the rules-based engine becomes an ongoing project as the volume and clerverness of spam increase. Hopefully Bayesian filtering can automate this.
It would be great if someone ported this, to an.exe file or something that everyone could run.
I don't think an.exe would help much - a Windows user doesn't need a standalone executable. He needs a filter (probably a.dll) coded to the specific filtering API of his mail client. Or does Microsoft have a generic mail filtering API? That way the filter seems to run "inside" the mail client.
In general this illuminates one of the advantages of Unix. Lots of programs are written as filters that read from STDIN (standard input) and write to STDOUT (standard output). My own mail filtering script, for example, does that. I didn't have to learn any mailer-specific API, and my script can be used in different contexts. (Actually my script doesn't write to STDOUT - it saves the message to the appropriate folder.)
Windows does not lend itself to the everything-is-a-filter idea because, among other things, process creation is slow and expensive. When a filter is invoked, a process is launched. Unix has more efficient process creation, and Linux has especially efficient and light process creation. Therefore on Windows a mail filter should be implemented as a reusable software component (probably a COM object) that can be called by the mail client.
Also, most mail clients on Unix use the same mail folder format (mbox) which is basically just the literal messages from the network written to a file. Since it is the assumed common language of mail folders, it encourages software to interoperate on the file level, which my script does by writing messages to mail folders. (Unix is file-centric.) Windows mail clients, in contrast, seem to store mail folders in proprietary formats. That's because Windows philosophy is that an application serves as gatekeeper to "its" files - the file is not a unit of interoperability. In our case it means a standalone mail filter probably couldn't write messages to the mail folder.
Unix is a more friendly, efficient development environment because you can write a mail filter as a standalone program and test it without building a test harness.
There's no way to completely secure a system short of making it entirely useless.
Granting that for the sake of argument, what's the most effective way to increase security? I'd say, ensure that a talented adversarial force is constantly looking for holes in the security. Since that force already exists, why not try to harness it?
While one can quite legitimately explore a network and report vulnerabilities to the proper authorities...
Just to be clear, one cannot legally do that under current law. In fact, an Oklahoma techie was charged under a wire fraud statute after demonstrating weaknesses in a customer's security to FBI agents.
That would be like getting people to break into stores and then paying them off at the expense of the people who got broken into.
Here are some differences:
The Government has articulated a national interest in the "National Information Infrastructure". In other words, keeping an insecure server on the internet contributes to the potential impact of a cyber-terrorist attack. Failing to adequately secure a store does not threaten US national security. Therefore, it makes sense to test the security of Internet hosts and penalize those who maintain insecure hosts.
Due to the global nature of the Internet, and the replayable nature of computer exploits, every Internet host is subject to best-of-breed attacks initiated from anywhere on the globe, including info-warfare units of hostile countries. In contrast, a retail store is physically vulnerable only to people who live nearby or make a special journey to reach it. Attacks are generally not replayable - skill and risk are required for each attack. To be concrete, a security flaw in IIS resulted in Code Red rapidly swarming across the internet. It could have been much worse. However, the fact that most retail stores can be broken into by throwing a cinder block through the plate glass will probably not be utilized by a US adversary. It's not high-leverage enough.
Computers are much more likely to be used as bases for further attacks than are retail stores. Therefore the negligence of maintaing an insecure Internet host is much more harmful to the community than the negligence of maintaining an insecure retail store.
Physical barriers merely present a known time delay to best-of-breed attacks. In other words, you don't need a flaw in a physical barrier in order to break it; you just apply an appropriate attack for a known period of time and the barrier is defeated. The barrier should be chosen so that its penetration time exceeds the response time of responding personnel. To increase the penetration time, the barrier must generally be more expensive. Therefore, selection of such barriers is a tradeoff between penetration time and cost. Internet host security is completely different. There is generally no such thing as penetration time; almost any conceivable attack is either a) nearly instantaneous or b) impossible in a realistic time frame. If someone breaks into an Internet host, it's not because the owner skimped on the armor plating. It's because there is an actual logical flaw in some of the code running on that host. (Taking code to include relevant configuration files.) If it's "new" flaw, we the public need to find out ASAP, because the "bad guys" may already know. If it's an old flaw, the owner of that computer is negligent.
PS: This post made Lynx coredump. Fortunately I found the post in the core file and pasted it into Netscape.
Criminalizing hacking is probably a mistake. It's a natural impulse to explore networks and work past barriers. It's no coincidence that the word "hacking" describes both creative programming and "malicious" network connections. They both stem from the impulse to explore systems.
The Government is now voicing concern about our "National Information Infrastructure" and its vulnerability. Passing tough laws and increasing enforcement is exactly the worst thing we could do for that cause. It will merely grow "hothouse flowers" - vulnerable networks that will not be probed by ordinary people (because they're scared) and will remain vulnerable for cyber-terrorists or organized crime.
Indulging the weakness of our corporate information security will be a never-ending spiral. Instead we should drag these hothouse flowers out into the real world and let natural selection take its course. In fact, the government could help most by offering bounties to people who hack into important facilities. Of course these bounties would be added to the tax bill of the corporation responsible for the security weakness. If most of the malicious hackers were reporting to the government, there'd be no way for "victims" to hide the incidents, and they could be publicized so customers and shareholders can react appropriately. That's how free markets are supposed to work - people buy and sell based on information.
Small scale hackers and script kiddies are like the constant barrage of viruses that keeps our immune systems on their toes. If we manage to scare them all away, we become the "boy in the bubble".
Outlook 2000 running against Exchange Server 5.5 doesn't send iCal/vCal requests -- all it does is send this: [textual representation of appointment]
Here's what I think is really happening. Outlook sends messages to Exchange via a proprietary protocol. The protocol allows appointment objects to be included in a message. When you get mail from Exchange via POP or IMAP, the messages are "reconstructed" into text from a binary data structure. Note that the headers are somewhat bogus - for example there is no Received header for the Outlook-Exchange hop, which was theoretically the first hop.
The "reconstruction" process doesn't know what to do with the appointment object, and therefore drops it.
The textual representation is probably a non-essential nicety generated by Outlook in the body of the mail so the message won't have an empty body. I think it can be shut off in Outlook - there is at least one user whose appointment messages appear empty to me (I POP from Exchange.)
OK, so MAPI is an api implemented by mapi.dll. What is the protocol(s) typically used between Outlook and Exchange? Or rather, I guess, between the client-side mapi.dll representing Outlook and the server-side mapi.dll representing Exchange? I'm visualizing:
[Outlook]---[mapi.dll]===[mapi.dll]---[Exchange]
Where '-' is a function call or callback, and '=' is the wire protocol. Is that protocol also called MAPI? Is it serialized objects or is it an extension of IMAP?
I think some people are thrown off the scent by the fact that Outlook and Exchange both support some open protocols as afterthoughts. I know Outlook can do IMAP, but I doubt that that's the typical protocol used in a full Outlook-Exchange implementation, or there wouldn't be much of a proprietary lock.
I basically agree. However at some point the finite capacity of last-mile infrastructure requires either rationing or charging.
Of course if they adopted this policy, people might use the cable LAN to route traffic to local competitive ISP's that offer better/cheaper internet connectivity. Thus you pay the cable company for their LAN and pay the real ISP for real connectivity.
Based on a few T-1's I've ordered in NYC, about half the cost is FCC fees and taxes, which I'm pretty sure aren't charged for DSL and cable. The more expensive CSU/DSU and quality level and phone line quality are other expenses that don't occur with a cable connection.
My point is that all "consumer bandwidth" has to come from "real bandwidth" somewhere. The expensive circuit and terminating equipment have to exist upstream of the cheap circuit and terminating equipment. Maybe you can show a substantial volume savings going from T1 to T3 and beyond.
The reduction from $5 to $2 decreases the upstream cost, but doesn't eliminate transfer as a factor in the profitability of an account. You still can't afford heavy bandwidth users at low flat fees. At that rate a 384 Mbps line at 25% utilization would consume $50 per month.
Since the cable company has a goverment granted monopoly in most cities, citizen/consumers should have a greater say in pricing than if it were a truely free market.
I'll go further - the company that provides the lines should not be allowed to sell services on top of the lines. Rather, they should make their money by renting use of the lines directly. I wouldn't want a private company owning the road in front of my dwelling and only allowing their "partners" to drive commercial vehicles on that road. They should be required to sell capacity nondiscriminatorily. That would probably mean genericising the existing capacity in a way that allows independent ISPs to encapsulate their protocols so they can't interfere with each other.
This article mixes together two different things: the genuinely sinister drive to close off the internet, and the perfectly reasonable desire of the telecoms to stop losing money on poorly-thought-out internet access offerings.
With regard to the latter, please realize that ISP's usually pay for their bandwidth. To make a profit, they must charge (bandwidth cost) + (distribution cost) + (overhead) + (profit). The marginal cost of 1 gigabyte of transfer is very roughly $5.00. I base this on rates charged by colocation providers, so realize that it doesn't include distribution (last mile) costs. Therefore a typical consumer bandwidth allocation of 5 Gigabytes per month costs the provider roughly $25. If the provider charges $40/month, he has $15 to cover (distribution cost) + (overhead) + (profit). That's slim. If the consumer manages to double his transfer, and consume $50 worth of upstream transfer, he is now costing the provider money.
I think that under the current system many customers are costing their providers money. We've gotten so used to subsidized bandwidth (subsidized by the foolishness of telecom marketers) that we've lost sight of the underlying economic reality, which is dictated by the backbone carriers.
Look at it another way. If you want a full 1.5 Mbps internet conection, you must pay from $700 to $1500 for a T1, depending on location. How do you expect to buy the equivalent for $40-$60 a month, even if the last mile capacity is that high (which it sometimes is)? Just to break even, the provider would have to dilute that bandwidth by a factor of 20 (fit 20 consumer circuits on one T1) - and that's without considering distribution and overhead costs. Therefore, you can use an average 70 Kbps - little faster than a modem.
For better or for worse, the providers estimated very low usage when they planned their offerings. They now want to ditch the high-usage users who are like Homer Simpson at an all-you-can-eat buffet. You can call the providers foolish, dishonest, etc. and probably be right. But you cannot expect them to subsidize you indefinitely.
Eventually users must start paying for their own bandwidth or reduce their consumption to meet their budget.
Did anyone bother reading the page on Search King's site? I'm not defending SK, because they appear to be an unethical business that tried to sell ranking on Google. But it's disturbing that almost noone has even read the other side of the story.
This isn't about the "PageRank algorithm". It's about Google manually assigning a page rank of zero ("the dreaded PR zero" as SK calls it) to punish SK for attempting to abuse the system. SK also claims that Google enforces an idea of "bad neighborhoods" by assigning PR 0 to anyone who links to a PR 0 page.
In other words, Google appears to be using similar tactics to the spam blacklist SPEWS. Both entities:
Claim to be automated and objective, while manually manipulating the listings.
Penalize not only "bad guys" but those who associate with "bad guys", thereby seeking to isolate the "bad guys" from the rest of the internet.
Had predecessors (MAPS, AV) that were were easily abused.
Produce listings by a secret method.
I use both SPEWS and Google. I like the results. But I realize that concentrated power tends to be abused. And inability to see both sides of the story makes abuse easier.
Apache is more flexible, but in traditional versions (1.x) you have a problem in that a new program instance is used for each request. That makes things like maintaining persistent connections to the application servers really hard.
Actually, Apache 1.x forks a number of children upon launch, the quantity specified by the StartServers parameter (default 5). It then forks and kills children as necessary to accomodate the load, keeping the number of spare (idle) processes between MinSpareServers and MaxSpareServers. So it always has a pool of spare servers to handle the next connection - it does not fork upon accepting a connection.
Therefore database handles can be held by the process and used through multiple request/response cycles. Mod_perl users accomplish this transparently with the Apache::DBI module, which overrides the connect method of DBI, causing it to first draw from a pool of cached handles.
Of course this technique can easily be applied to TCP connections to application servers, or any other reusable resource that takes time to acquire.
With the way things are going, I would be surprised if Microsoft couldn't get some sort of law passed on the importation of a circumvention device, provided they threw enough lobbyists at it.
The DMCA already prohibits trafficking in circumvention devices. And yes, imported electronics have been seized by U.S. Customs under the DMCA.
The clarity of the court's questioning was impressive. They found holes in both Lessig's and Olson's arguments. Lessig was able to minimize the holes to some extent, while Olson appeared tired or unprepared. Justice Breyer summed up the economic issue by citing the brief of the amici economists to illuminate just how Congress has achieved the "delicate balance" between content producers and the public: the content producer gets 99.8% of the value and the public gets 0.2%.
I think it's pretty clear that the Justices who spoke find the copyright extension reprehensible and inconsistent with the Framers' goals. However, they will not strike it down unless there is a strong constitutional argument for doing so.
Even if we lose the case, I'm glad the issues have been put on the table so clearly.
I take your point that Apache is not as innovative as commercial offerings. But I'm curious: do you think that threads really make sense in a web server? The clone() call is like fork() except the memory space is not copied. So to handle 50 concurrent connections, you get reduced memory footprint. Is it worth the added complexity? Especially since, as you point out, the complexity is not confined to the core server (where the most attention can be focused) but leaks into all the modules?
Should anyone be running 12-way web servers? I worked for a company that ran NES on big Sun's. It made no sense to me since web serving is the most easily parallelizable computing function. Even worse, they used tons of straight CGI thinking that vendor-supplied magic would take the place of careful design on their part. Everyplace else, we've used load balanced PCs with Linux or FreeBSD and Apache. That delivers much more bang for the buck.
I guess the key to staying happy without threads is a good proxy server so slow connections can't tie up an expensive, fat process. Now, if the proxy is threaded, or just select()s over a bunch of sockets, doesn't matter - we don't have to extend and modify it. I'm curious if your Sun-using customers who saved money by using NES understood this.
Unix gives us a nice, clean process architecture. Why ruin it to get some marginal increase in performance when hardware is always getting cheaper and more powerful? As I see it, the threading mania came from Windows, where there wasn't a better way to do things.
We have enough things to troubleshoot without processes being able to invade each other's memory spaces.
I agree. But if they overfatten it, we can write the lean client as a Mozilla app. The hardest part will be getting momentum behind one specific standard.
By the way, I think it's important that the wire protocol specify display objects logically, not physically. It should be possible to write monochrome, or low-res, or character mode, or speech-driven clients that talk the same protocol. However it could contain hints for the most common platform (hi-res color GUI). And needless to say, such abstraction means any server-side app offering this interface lends itself to remote automation.
i mean, what if i am a competitor of some company and i can convince
Joey McNicol that their IP needs to be banned.
First, Joey has no known relationship to SPEWS. T3 deliberately or accidentally confused them because SPEWS does not publish contact info while Joey was visibly complaining about them. SPEWS almost certainly blacklisted T3 on their own without being told by anyone - they monitor spamtrap addresses.
Could SPEWS abuse their power? Well, MAPS and ORBS both abused their power at one point by adding 'spite listings'. This led to the downfall of ORBS and contributed to the irrelevance of MAPS. SPEWS is under a microscope - every one of their listings can be challenged on nanae. On the very rare occasions where they're wrong, the listings are quickly changed. If SPEWS ever has a single known persistent listing that is not justified in the eyes of the anti-spam community, there will be substantial protest and a serious loss of confidence in SPEWS. So far there has never been any mystery - every listed address is linked in some obvious way to persistent mail abusers.
Spurious comment I know but do you trust a company that claims the safe they're selling is 'secure'
Since you ask, the security of a safe is assured by its UL label. Construction labels, typically B and C, simply specify certain thickness of steel. Performance labels, such as TL15, TL30 specify resistance to expert attack for a certain time period. A safe rated TXTL-60 will:
Successfully resist entry for a net assault time of 60 minutes when attacked with common hand tools, picking tools, mechanical or portable electric tools, grinders, drills, pressure devices, explosives and oxy-fuel gas cutting or welding torches.
First, I'm not condemning Tomb Raider. Game makers have no obligation to cater to women, who in any event will not buy many games.
Having said that, there are fairly clear reasons why many women would not enjoy Tomb Raider, and I think the inability to grasp these reasons reflects badly on the maturity, sensitivity and empathy of some of the posters here.
First, game characters have personas which players are invited to identify with or work alongside. This is true although the player controls the character's actions. For example, Pacman is an opportunistic, greedy, but essentially nonviolent character. He is not paranoid or vengeful, but believes that "turnabout is fair play". Since he's constantly in motion, we can't tell if he's utterly relaxed or utterly frantic. When Pacman eats a ghost the result is a non-lethal stay in the "penalty box". Likewise, when Pacman is "tagged" by a ghost only one of three pacmans is consumed, like a pinball falling off the board. These softened deaths imply that the interaction between Pacman and his pursuers is merely a game, not a life and death struggle. Pacman is one of the few games that appealed to females.
The typical first person shooter projects a somewhat different character. Although he rarely appears on screen, his persona is clear. A ruthless killer hunted by ruthless adversaries, he is skilled in handling a variety of firearms. His body is a killing machine, not a sex object. He is not on display.
Consider Lara Croft in light of the above. She has the persona, in a way, of a young man - aggressive, exploratory, self-contained. But she has the body of an attractive young woman, complete with a tiny waist and large breasts. And that is also part of her persona - the panting after exertion that emphasizes her breasts. Lara is an attractive woman who is inherently amenable to a masculine style of thinking and action. To understand why this could irritate some women, consider her opposite number: the male hero of romance novels or of soap operas. If you're a man, don't you feel a kind of gut hatred for the blow-dried, earnest, wide-eyed soap character who makes heartfelt speeches about his feelings?
I think the reason is that he's a gender traitor, a man with the soul of a woman. Superficially masculine, he is overly melodramatic and concerned with relationships. Most of all, he hits the spot for millions of women who would like the men in their lives to be like that - handsome, well groomed, full of deep emotional conflicts that he's happy to air.
Lara, of course, is a male fantasy. She has, from our viewpoint, all the desirable characteristics of a woman with none of the unpleasant baggage. It's hard to imagine her asking if you think she's fat. In fact, it's hard to imagine her caring about your opinion at all.
Others in this thread have wondered how there can be any objection to Lara's breasts when male action heroes sport gigantic muscles which could also be considered sexy. First of all, Lara is eroticized, placed on display for the player's enjoyment, in a way I haven't seen any male game character presented. Admittedly, I haven't played many games recently. I do agree with the feminists, however, that our cultural presentation of females as erotic objects is so ingrained that it's hard to notice. Can you imagine our musclebound action hero filmed from the side, panting in that delightful way Lara has? We simply don't detail, illuminate and present male bodies as we do female bodies. Second, the muscles of a male hero are assets in his adventures. If combatting a city full of evil aliens, I'd like someone built like Duke Nukem to help. But if I had to pick a woman to help me raid a dangerous tomb, I'd rather have one of those granite-faced female Sherrif's deputies you see in L.A. than a slender, busty model. Lara isn't really built to fight - she's built to titillate.
Lastly, it's interesting to note that Lara, like many heroines designed to appeal to men, is quite a loner. She doesn't seem to have parents or siblings or a boyfriend or husband - any of the emotional connections that would be interesting to women, but a turnoff to men.
As I pointed out, the people processes are the weak point.
Even though I used a human "error" as the gateway to the hypothetical hack, such a hack could occur with little or no human error. The real lesson is that general purpose computers cannot be fully trusted. There's just too much going on between Tempest emissions, mysterious firmware in lots of peripherals, very complex modern operating systems with sometimes unpredictable faults. All usable OS's are crumbling piles of buffer overflows waiting to be exploited.
Remember, when DES was standardized NIST would not approve software implementations. It's generally believed that NIST was representing the NSA. Since then computers have not gotten simpler or more reliable.
I'm behind a simple and cheap NAT box, and I don't run any services that require incoming ports to be openned.
Someone commented a few days ago that since the exploits are being squeezed out of the common daemons the attackers must eventually shift to client-side code which has received little scrutiny so far. Any estimates of how many exploitable buffer overflows are present in Mozilla? This will be a new era, because computers natted behind firewalls are typically much less secure than computers on the internet.
Even Verisign could be compromised, but it isn't likely because their business depends on people trusting that this can never happen. I've done this kind of work in a commercial setting, so I know what the issues are.
Verisign's not likely to be compromised by immediate-gratification kiddies who would harm their reputation. Although in fact this may have happened - if attackers stole card numbers by MITMing transactions with a fake Verisign certificate, it was probably never discovered. Someone who runs an e-commerce site told me that 25% of his transactions are fraudulent, with stolen card numbers. In other words, while abuse of a card number is obvious, it is not obvious where the card number came from.
Anyhow, if there are more dedicated groups who really want to compromise Verisign, they may well have done so. I'm afraid you will bridle at this comment, having experience in this area. Since I know nothing of Verisign's particular security arrangements, I'll just mention some general considerations:
Security by routine gets rusty unless constantly probed by an adversary. The Air Force used to send phony relief crews to Titan missile bases to see if they could talk their way into the control center. Does Verisign continously attack its security arrangements with well-funded, independent, skilled adversaries who are thoroughly briefed on the security arrangements? I suspect a commercial organization finds it more profitable not to.
Does Verisign monitor the personal lives of employees with access to cryptographic material? Many people in the valley are feeling the pinch of recession. If an employee can't make the mortgage payment due to a laid-off spouse, he could be pressured into selling out.
How many copies of their private keys does Verisign keep? I assume that the primary copy is in tamperproof hardware used for signing. But there must be backups or the business is quite vulnerable to a bit changing in an EPROM. How are the backups stored, and what procedure is used to safely transport the backup data to the production equipment when necessary? Is this procedure drilled, examined, attacked?
How does Verisign handle an audit, such as a BSA audit? How about fire inspection? Insurance inspection? What if a fire occurs inside the building? Won't they have to evacuate and give the fire department free reign?
Under the USA PATRIOT Act, the FBI can demand Verisign's keys and they cannot tell anyone about it. Has it happened yet? If so, how did they authenticate the FBI agents?
Would Verisign ever admit to being compromised?
All of these comments point to the same idea: serious cryptographic security is not possible for private commercial entities.
Good point. I didn't realize you were beyond the reach of our splendid freedom-loving institutions. However, it looks like Canada will adopt some form of the DMCA (interesting article here), and if the Hollings bill passes there will surely be pressure on Canada to pass an equivalent.
As for customers pausing before buying DRM, I'm not hopeful. Palladium is poised to appeal deeply to the fears of the average computer-ignorant person. You can prevent a recipient from forwarding your email to a third party! You can send out a newsletter that's only readable for 7 days!
I guess you're not planning to buy an AMD or Intel PC or CPU after mid-next-year then. Will you start stockpiling obsolete computer parts? And if the Hollings bill passes and your stockpile becomes illegal contraband (after the grace period) will you trash it or live the hunted life of a drug dealer?
I appreciate the sentiment, but I'm not sure it's realistic. The folks we're up against are not going to leave any easy way out.
But will any patented algorithms be accepted going forward? The RSA patent caused enough annoyance that I think everyone adopting crypto is wary of patents. And one of the criteria for the AES was freedom from patent encumbrance. We already have more than enough unencumbered algorithms for the recognized tasks such as block cipher, stream cipher, public-key. I think a patented algorithm would only be used if it provides substantial capabilities beyond what we have now (very unlikely) or if the patent itself were desirable to ban interoperable implementations.
Slashdot Mirror
Ah, but if you buy the Microsoft Puppy you will have to buy the dog food from Microsoft. This is to ensure maxiumum customer satisfaction. And if you have questions about raising your Microsoft Puppy, there's an 800 number you can call.
It's all very well to say that spam should be stopped at the source, but how do you plan to do that? Blocklists that pressure the ISP? SPEWS is pretty effective, but Verio, UUNet and Sprint are deeply committed to spam. They won't dislodge their pet spammers until they feel financial pain. Want the government to stop spam at the source? I see lots of problems with that. One of them is the creation of another eternal government responsibility like the war on drugs. They will forever need more funding for "the war on spam" because spammers are getting more clever. These federal agencies develop a symbiotic relationship with the "problems" they're trying to "solve".
In practice, a multipronged approach will work best, combining prosecution, litigation, blocklists, content-based filtering, complaints to upstream providers and education of new users. Graham's article, in fact, shows how attempts to avoid prosecution push spammers into the arms of content-based filtering.
I don't ask for a 100% solution to spam, because any such solution will have awful side effects.
I didn't read the POPFile link. Had I read it, I would have known that POPFile is a POP Proxy. Therefore it is a good candidate for conversion to a standalone executable. In other words, given the lack of standard email hooks on the Windows platform, POPFile cleverly avails itself of the one standard to which mail clients are pretty much forced to adhere - POP3.
.exe, integration with the mail client is still desirable if the user is to categorize mail and thus "teach" the system. I guess the alternative, for naive users, is to ship the proxy with a static table of probabilities which can be periodically updated like virus definitions.
However while the proxy itself can live as an
I think you may have misunderstood that comment. Since Paul Graham started talking about Bayesian filtering, there's been some tendency here to refer to all learning spam filters as Bayesian. Which results in complaints, which results in the designation "pseudo-Bayesian" for the many independently-discovered learning algorithms that don't have a theoretical underpinning.
Put another way: if an algorithm outputs a dimensionless "score", and the author can't set an upper bound on the score, it's at most pseudo-Bayesian. If it outputs a probability that the message meets certain criteria, then it could be "true Bayesian". Additional implication: the "pseudo-Bayesian" filter may have a stack of rules in addition to its table of probabilities.
I don't think we're splitting hairs on some deep statistical issue. I think we're groping for very rough categories in a new field of application software. If you can establish clearer categories, that might help.
Graham addresses this in the article. One can identify most spam with a simple rules-based engine. That tends to make one lazy in reading the spam folder, which means false positives can languish unread. Enhancing the rules-based engine becomes an ongoing project as the volume and clerverness of spam increase. Hopefully Bayesian filtering can automate this.
I don't think an
In general this illuminates one of the advantages of Unix. Lots of programs are written as filters that read from STDIN (standard input) and write to STDOUT (standard output). My own mail filtering script, for example, does that. I didn't have to learn any mailer-specific API, and my script can be used in different contexts. (Actually my script doesn't write to STDOUT - it saves the message to the appropriate folder.)
Windows does not lend itself to the everything-is-a-filter idea because, among other things, process creation is slow and expensive. When a filter is invoked, a process is launched. Unix has more efficient process creation, and Linux has especially efficient and light process creation. Therefore on Windows a mail filter should be implemented as a reusable software component (probably a COM object) that can be called by the mail client.
Also, most mail clients on Unix use the same mail folder format (mbox) which is basically just the literal messages from the network written to a file. Since it is the assumed common language of mail folders, it encourages software to interoperate on the file level, which my script does by writing messages to mail folders. (Unix is file-centric.) Windows mail clients, in contrast, seem to store mail folders in proprietary formats. That's because Windows philosophy is that an application serves as gatekeeper to "its" files - the file is not a unit of interoperability. In our case it means a standalone mail filter probably couldn't write messages to the mail folder.
Unix is a more friendly, efficient development environment because you can write a mail filter as a standalone program and test it without building a test harness.
Granting that for the sake of argument, what's the most effective way to increase security? I'd say, ensure that a talented adversarial force is constantly looking for holes in the security. Since that force already exists, why not try to harness it?
Just to be clear, one cannot legally do that under current law. In fact, an Oklahoma techie was charged under a wire fraud statute after demonstrating weaknesses in a customer's security to FBI agents.
Here are some differences:
The barrier should be chosen so that its penetration time exceeds the response time of responding personnel. To increase the penetration time, the barrier must generally be more expensive. Therefore, selection of such barriers is a tradeoff between penetration time and cost.
Internet host security is completely different. There is generally no such thing as penetration time; almost any conceivable attack is either a) nearly instantaneous or b) impossible in a realistic time frame. If someone breaks into an Internet host, it's not because the owner skimped on the armor plating. It's because there is an actual logical flaw in some of the code running on that host. (Taking code to include relevant configuration files.) If it's "new" flaw, we the public need to find out ASAP, because the "bad guys" may already know. If it's an old flaw, the owner of that computer is negligent.
PS: This post made Lynx coredump. Fortunately I found the post in the core file and pasted it into Netscape.
Criminalizing hacking is probably a mistake. It's a natural impulse to explore networks and work past barriers. It's no coincidence that the word "hacking" describes both creative programming and "malicious" network connections. They both stem from the impulse to explore systems.
The Government is now voicing concern about our "National Information Infrastructure" and its vulnerability. Passing tough laws and increasing enforcement is exactly the worst thing we could do for that cause. It will merely grow "hothouse flowers" - vulnerable networks that will not be probed by ordinary people (because they're scared) and will remain vulnerable for cyber-terrorists or organized crime.
Indulging the weakness of our corporate information security will be a never-ending spiral. Instead we should drag these hothouse flowers out into the real world and let natural selection take its course. In fact, the government could help most by offering bounties to people who hack into important facilities. Of course these bounties would be added to the tax bill of the corporation responsible for the security weakness. If most of the malicious hackers were reporting to the government, there'd be no way for "victims" to hide the incidents, and they could be publicized so customers and shareholders can react appropriately. That's how free markets are supposed to work - people buy and sell based on information.
Small scale hackers and script kiddies are like the constant barrage of viruses that keeps our immune systems on their toes. If we manage to scare them all away, we become the "boy in the bubble".
Here's what I think is really happening. Outlook sends messages to Exchange via a proprietary protocol. The protocol allows appointment objects to be included in a message. When you get mail from Exchange via POP or IMAP, the messages are "reconstructed" into text from a binary data structure. Note that the headers are somewhat bogus - for example there is no Received header for the Outlook-Exchange hop, which was theoretically the first hop.
The "reconstruction" process doesn't know what to do with the appointment object, and therefore drops it.
The textual representation is probably a non-essential nicety generated by Outlook in the body of the mail so the message won't have an empty body. I think it can be shut off in Outlook - there is at least one user whose appointment messages appear empty to me (I POP from Exchange.)
OK, so MAPI is an api implemented by mapi.dll. What is the protocol(s) typically used between Outlook and Exchange? Or rather, I guess, between the client-side mapi.dll representing Outlook and the server-side mapi.dll representing Exchange? I'm visualizing:
]
[Outlook]---[mapi.dll]===[mapi.dll]---[Exchange
Where '-' is a function call or callback, and '=' is the wire protocol. Is that protocol also called MAPI? Is it serialized objects or is it an extension of IMAP?
I think some people are thrown off the scent by the fact that Outlook and Exchange both support some open protocols as afterthoughts. I know Outlook can do IMAP, but I doubt that that's the typical protocol used in a full Outlook-Exchange implementation, or there wouldn't be much of a proprietary lock.
I basically agree. However at some point the finite capacity of last-mile infrastructure requires either rationing or charging.
Of course if they adopted this policy, people might use the cable LAN to route traffic to local competitive ISP's that offer better/cheaper internet connectivity. Thus you pay the cable company for their LAN and pay the real ISP for real connectivity.
My point is that all "consumer bandwidth" has to come from "real bandwidth" somewhere. The expensive circuit and terminating equipment have to exist upstream of the cheap circuit and terminating equipment. Maybe you can show a substantial volume savings going from T1 to T3 and beyond.
The reduction from $5 to $2 decreases the upstream cost, but doesn't eliminate transfer as a factor in the profitability of an account. You still can't afford heavy bandwidth users at low flat fees. At that rate a 384 Mbps line at 25% utilization would consume $50 per month.
I'll go further - the company that provides the lines should not be allowed to sell services on top of the lines. Rather, they should make their money by renting use of the lines directly. I wouldn't want a private company owning the road in front of my dwelling and only allowing their "partners" to drive commercial vehicles on that road. They should be required to sell capacity nondiscriminatorily. That would probably mean genericising the existing capacity in a way that allows independent ISPs to encapsulate their protocols so they can't interfere with each other.
This article mixes together two different things: the genuinely sinister drive to close off the internet, and the perfectly reasonable desire of the telecoms to stop losing money on poorly-thought-out internet access offerings.
With regard to the latter, please realize that ISP's usually pay for their bandwidth. To make a profit, they must charge (bandwidth cost) + (distribution cost) + (overhead) + (profit). The marginal cost of 1 gigabyte of transfer is very roughly $5.00. I base this on rates charged by colocation providers, so realize that it doesn't include distribution (last mile) costs. Therefore a typical consumer bandwidth allocation of 5 Gigabytes per month costs the provider roughly $25. If the provider charges $40/month, he has $15 to cover (distribution cost) + (overhead) + (profit). That's slim. If the consumer manages to double his transfer, and consume $50 worth of upstream transfer, he is now costing the provider money.
I think that under the current system many customers are costing their providers money. We've gotten so used to subsidized bandwidth (subsidized by the foolishness of telecom marketers) that we've lost sight of the underlying economic reality, which is dictated by the backbone carriers.
Look at it another way. If you want a full 1.5 Mbps internet conection, you must pay from $700 to $1500 for a T1, depending on location. How do you expect to buy the equivalent for $40-$60 a month, even if the last mile capacity is that high (which it sometimes is)? Just to break even, the provider would have to dilute that bandwidth by a factor of 20 (fit 20 consumer circuits on one T1) - and that's without considering distribution and overhead costs. Therefore, you can use an average 70 Kbps - little faster than a modem.
For better or for worse, the providers estimated very low usage when they planned their offerings. They now want to ditch the high-usage users who are like Homer Simpson at an all-you-can-eat buffet. You can call the providers foolish, dishonest, etc. and probably be right. But you cannot expect them to subsidize you indefinitely.
Eventually users must start paying for their own bandwidth or reduce their consumption to meet their budget.
This isn't about the "PageRank algorithm". It's about Google manually assigning a page rank of zero ("the dreaded PR zero" as SK calls it) to punish SK for attempting to abuse the system. SK also claims that Google enforces an idea of "bad neighborhoods" by assigning PR 0 to anyone who links to a PR 0 page.
In other words, Google appears to be using similar tactics to the spam blacklist SPEWS. Both entities:
I use both SPEWS and Google. I like the results. But I realize that concentrated power tends to be abused. And inability to see both sides of the story makes abuse easier.
Actually, Apache 1.x forks a number of children upon launch, the quantity specified by the StartServers parameter (default 5). It then forks and kills children as necessary to accomodate the load, keeping the number of spare (idle) processes between MinSpareServers and MaxSpareServers. So it always has a pool of spare servers to handle the next connection - it does not fork upon accepting a connection.
Therefore database handles can be held by the process and used through multiple request/response cycles. Mod_perl users accomplish this transparently with the Apache::DBI module, which overrides the connect method of DBI, causing it to first draw from a pool of cached handles.
Of course this technique can easily be applied to TCP connections to application servers, or any other reusable resource that takes time to acquire.
The DMCA already prohibits trafficking in circumvention devices. And yes, imported electronics have been seized by U.S. Customs under the DMCA.
The transcript is well worth reading.
The clarity of the court's questioning was impressive. They found holes in both Lessig's and Olson's arguments. Lessig was able to minimize the holes to some extent, while Olson appeared tired or unprepared. Justice Breyer summed up the economic issue by citing the brief of the amici economists to illuminate just how Congress has achieved the "delicate balance" between content producers and the public: the content producer gets 99.8% of the value and the public gets 0.2%.
I think it's pretty clear that the Justices who spoke find the copyright extension reprehensible and inconsistent with the Framers' goals. However, they will not strike it down unless there is a strong constitutional argument for doing so.
Even if we lose the case, I'm glad the issues have been put on the table so clearly.
I take your point that Apache is not as innovative as commercial offerings. But I'm curious: do you think that threads really make sense in a web server? The clone() call is like fork() except the memory space is not copied. So to handle 50 concurrent connections, you get reduced memory footprint. Is it worth the added complexity? Especially since, as you point out, the complexity is not confined to the core server (where the most attention can be focused) but leaks into all the modules?
Should anyone be running 12-way web servers? I worked for a company that ran NES on big Sun's. It made no sense to me since web serving is the most easily parallelizable computing function. Even worse, they used tons of straight CGI thinking that vendor-supplied magic would take the place of careful design on their part. Everyplace else, we've used load balanced PCs with Linux or FreeBSD and Apache. That delivers much more bang for the buck.
I guess the key to staying happy without threads is a good proxy server so slow connections can't tie up an expensive, fat process. Now, if the proxy is threaded, or just select()s over a bunch of sockets, doesn't matter - we don't have to extend and modify it. I'm curious if your Sun-using customers who saved money by using NES understood this.
Unix gives us a nice, clean process architecture. Why ruin it to get some marginal increase in performance when hardware is always getting cheaper and more powerful? As I see it, the threading mania came from Windows, where there wasn't a better way to do things.
We have enough things to troubleshoot without processes being able to invade each other's memory spaces.
I agree. But if they overfatten it, we can write the lean client as a Mozilla app. The hardest part will be getting momentum behind one specific standard.
By the way, I think it's important that the wire protocol specify display objects logically, not physically. It should be possible to write monochrome, or low-res, or character mode, or speech-driven clients that talk the same protocol. However it could contain hints for the most common platform (hi-res color GUI). And needless to say, such abstraction means any server-side app offering this interface lends itself to remote automation.
First, Joey has no known relationship to SPEWS. T3 deliberately or accidentally confused them because SPEWS does not publish contact info while Joey was visibly complaining about them. SPEWS almost certainly blacklisted T3 on their own without being told by anyone - they monitor spamtrap addresses.
Could SPEWS abuse their power? Well, MAPS and ORBS both abused their power at one point by adding 'spite listings'. This led to the downfall of ORBS and contributed to the irrelevance of MAPS. SPEWS is under a microscope - every one of their listings can be challenged on nanae. On the very rare occasions where they're wrong, the listings are quickly changed. If SPEWS ever has a single known persistent listing that is not justified in the eyes of the anti-spam community, there will be substantial protest and a serious loss of confidence in SPEWS. So far there has never been any mystery - every listed address is linked in some obvious way to persistent mail abusers.
Since you ask, the security of a safe is assured by its UL label. Construction labels, typically B and C, simply specify certain thickness of steel. Performance labels, such as TL15, TL30 specify resistance to expert attack for a certain time period. A safe rated TXTL-60 will:
(more here).
First, I'm not condemning Tomb Raider. Game makers have no obligation to cater to women, who in any event will not buy many games.
Having said that, there are fairly clear reasons why many women would not enjoy Tomb Raider, and I think the inability to grasp these reasons reflects badly on the maturity, sensitivity and empathy of some of the posters here.
First, game characters have personas which players are invited to identify with or work alongside. This is true although the player controls the character's actions. For example, Pacman is an opportunistic, greedy, but essentially nonviolent character. He is not paranoid or vengeful, but believes that "turnabout is fair play". Since he's constantly in motion, we can't tell if he's utterly relaxed or utterly frantic. When Pacman eats a ghost the result is a non-lethal stay in the "penalty box". Likewise, when Pacman is "tagged" by a ghost only one of three pacmans is consumed, like a pinball falling off the board. These softened deaths imply that the interaction between Pacman and his pursuers is merely a game, not a life and death struggle. Pacman is one of the few games that appealed to females.
The typical first person shooter projects a somewhat different character. Although he rarely appears on screen, his persona is clear. A ruthless killer hunted by ruthless adversaries, he is skilled in handling a variety of firearms. His body is a killing machine, not a sex object. He is not on display.
Consider Lara Croft in light of the above. She has the persona, in a way, of a young man - aggressive, exploratory, self-contained. But she has the body of an attractive young woman, complete with a tiny waist and large breasts. And that is also part of her persona - the panting after exertion that emphasizes her breasts. Lara is an attractive woman who is inherently amenable to a masculine style of thinking and action. To understand why this could irritate some women, consider her opposite number: the male hero of romance novels or of soap operas. If you're a man, don't you feel a kind of gut hatred for the blow-dried, earnest, wide-eyed soap character who makes heartfelt speeches about his feelings?
I think the reason is that he's a gender traitor, a man with the soul of a woman. Superficially masculine, he is overly melodramatic and concerned with relationships. Most of all, he hits the spot for millions of women who would like the men in their lives to be like that - handsome, well groomed, full of deep emotional conflicts that he's happy to air.
Lara, of course, is a male fantasy. She has, from our viewpoint, all the desirable characteristics of a woman with none of the unpleasant baggage. It's hard to imagine her asking if you think she's fat. In fact, it's hard to imagine her caring about your opinion at all.
Others in this thread have wondered how there can be any objection to Lara's breasts when male action heroes sport gigantic muscles which could also be considered sexy.
First of all, Lara is eroticized, placed on display for the player's enjoyment, in a way I haven't seen any male game character presented. Admittedly, I haven't played many games recently. I do agree with the feminists, however, that our cultural presentation of females as erotic objects is so ingrained that it's hard to notice. Can you imagine our musclebound action hero filmed from the side, panting in that delightful way Lara has? We simply don't detail, illuminate and present male bodies as we do female bodies.
Second, the muscles of a male hero are assets in his adventures. If combatting a city full of evil aliens, I'd like someone built like Duke Nukem to help. But if I had to pick a woman to help me raid a dangerous tomb, I'd rather have one of those granite-faced female Sherrif's deputies you see in L.A. than a slender, busty model. Lara isn't really built to fight - she's built to titillate.
Lastly, it's interesting to note that Lara, like many heroines designed to appeal to men, is quite a loner. She doesn't seem to have parents or siblings or a boyfriend or husband - any of the emotional connections that would be interesting to women, but a turnoff to men.
Even though I used a human "error" as the gateway to the hypothetical hack, such a hack could occur with little or no human error. The real lesson is that general purpose computers cannot be fully trusted. There's just too much going on between Tempest emissions, mysterious firmware in lots of peripherals, very complex modern operating systems with sometimes unpredictable faults. All usable OS's are crumbling piles of buffer overflows waiting to be exploited.
Remember, when DES was standardized NIST would not approve software implementations. It's generally believed that NIST was representing the NSA. Since then computers have not gotten simpler or more reliable.
Someone commented a few days ago that since the exploits are being squeezed out of the common daemons the attackers must eventually shift to client-side code which has received little scrutiny so far. Any estimates of how many exploitable buffer overflows are present in Mozilla? This will be a new era, because computers natted behind firewalls are typically much less secure than computers on the internet.
Verisign's not likely to be compromised by immediate-gratification kiddies who would harm their reputation. Although in fact this may have happened - if attackers stole card numbers by MITMing transactions with a fake Verisign certificate, it was probably never discovered. Someone who runs an e-commerce site told me that 25% of his transactions are fraudulent, with stolen card numbers. In other words, while abuse of a card number is obvious, it is not obvious where the card number came from.
Anyhow, if there are more dedicated groups who really want to compromise Verisign, they may well have done so. I'm afraid you will bridle at this comment, having experience in this area. Since I know nothing of Verisign's particular security arrangements, I'll just mention some general considerations:
- Security by routine gets rusty unless constantly probed by an adversary. The Air Force used to send phony relief crews to Titan missile bases to see if they could talk their way into the control center. Does Verisign continously attack its security arrangements with well-funded, independent, skilled adversaries who are thoroughly briefed on the security arrangements? I suspect a commercial organization finds it more profitable not to.
- Does Verisign monitor the personal lives of employees with access to cryptographic material? Many people in the valley are feeling the pinch of recession. If an employee can't make the mortgage payment due to a laid-off spouse, he could be pressured into selling out.
- How many copies of their private keys does Verisign keep? I assume that the primary copy is in tamperproof hardware used for signing. But there must be backups or the business is quite vulnerable to a bit changing in an EPROM. How are the backups stored, and what procedure is used to safely transport the backup data to the production equipment when necessary? Is this procedure drilled, examined, attacked?
- How does Verisign handle an audit, such as a BSA audit? How about fire inspection? Insurance inspection? What if a fire occurs inside the building? Won't they have to evacuate and give the fire department free reign?
- Under the USA PATRIOT Act, the FBI can demand Verisign's keys and they cannot tell anyone about it. Has it happened yet? If so, how did they authenticate the FBI agents?
- Would Verisign ever admit to being compromised?
All of these comments point to the same idea: serious cryptographic security is not possible for private commercial entities.Good point. I didn't realize you were beyond the reach of our splendid freedom-loving institutions. However, it looks like Canada will adopt some form of the DMCA (interesting article here), and if the Hollings bill passes there will surely be pressure on Canada to pass an equivalent.
As for customers pausing before buying DRM, I'm not hopeful. Palladium is poised to appeal deeply to the fears of the average computer-ignorant person. You can prevent a recipient from forwarding your email to a third party! You can send out a newsletter that's only readable for 7 days!
I guess you're not planning to buy an AMD or Intel PC or CPU after mid-next-year then. Will you start stockpiling obsolete computer parts? And if the Hollings bill passes and your stockpile becomes illegal contraband (after the grace period) will you trash it or live the hunted life of a drug dealer?
I appreciate the sentiment, but I'm not sure it's realistic. The folks we're up against are not going to leave any easy way out.
But will any patented algorithms be accepted going forward? The RSA patent caused enough annoyance that I think everyone adopting crypto is wary of patents. And one of the criteria for the AES was freedom from patent encumbrance. We already have more than enough unencumbered algorithms for the recognized tasks such as block cipher, stream cipher, public-key. I think a patented algorithm would only be used if it provides substantial capabilities beyond what we have now (very unlikely) or if the patent itself were desirable to ban interoperable implementations.