First, determine if you really need to distribute this via HTTP. It is far easier to secure other protocols (eg scp), so if there's another way of doing this, do it.
Second, if the sensitive information is going to a select few people, consider PGP encrypting the data, and only putting the encrypted version online. Doing this makes many of the HTTP security issues less critical.
Assuming you still have to put something sensitive online, make sure of the following:
Only use HTTPS, never use just plain HTTP.
Use CGI, Java Servlets, or some other server-side program technology to password-protect the site. I will refer to the resulting program(s) as the security program
Never accept a password from a GET request, only accept them from POST requests.
Never make the user list or password list visible from the internet, not even an encrypted password list.
Never place the sensitive information in a directory the web server software knows how to access. Only the security program should know how to find the info.
Review all documentation for your web server software and the platform used for the security program. Pay special attention to seciurity issues, make sure you aren't inadvertently opening up holes. Keep current, do this at minimum four times a year.
Subscribe to any security mailing lists for your web server platform operating system web server software, and for the programing platform you used for the security program. If there is anything else running on this machine, subscribe to their security mailing lists too.
Subscribe to cert-advisory and BugTraq. Read in detail all the messages that are relevant to your setup. Review your setup after each relevant message.
Don't use IIS.
Don't use Windows 95/98/Me. Don't use Windows XP Home Edition.
Don't use any version of MacOS before OS X.
Don't use website hosting services for sensitive information.
Never connect to this webserver using telnet, ftp or FrontPage. SSH is your friend.
Never have Front Page Extensions (or its clones or workalikes) installed on a webserver with sensitive data.
If there is anything above that you don't understand, or if you can't afford the time for any of the above, hire a professional with security experience and recommendations from people you trust who have used his or her services. It's bad enough that amateurs are running webservers, much less running ecommerce sites and other sites with sensitive data.
The above is an incomplete list. It is primarly there to start giving people an idea of how much effort they should expect to put into a properly administered secure website with sensitive information. Do you really need to distribute this via a web browser?
and here is a gem for the minimalistic: did you know that "vi" in debian is a script that runs a version of vi accordingly to the user's preferences? Really. When you type 'vi' you fork another bash!
I don't know if that was the case ages ago, but in Potato and later vi is not a script, and doesn't fork an additional bash.
Debian does give people a choice of vi's (vim, nvi, elvis and elvis-tiny, possibly more). It does it with simple symbolic links./usr/bin/vi is a link to/etc/alternatives/vi, which is itself a link to the vi-compatible binary of your choice. There's a tiny bit of overhead to bounce through the two symbolic links, but no extra processes are generated and you run a binary executable directly.
Re:Debian vs Slack for the 'unix-like' crown?
on
Is Slackware Fading Away?
·
· Score: 4, Interesting
I started with Slackware, moved to RedHat at version 4.1, tried to move to Debian when Hamm was released (gave up in frustration), and then moved to Debian sucessfully when Potato was released. I am definately happy with Debian. I still use Slackware for rare installations (I certainly use it more than I use RedHat).
Reasons I prefer Debian over Slackware for most systems:
* Fastest path from bare metal to rock-solid stable server
* Easier to maintain, particularly security updates
* Well thought out system configuration files and scripts
* Debian puts more development manhours into making sure the packages are debugged and working well together
* I prefer modular System V-style init scripts to Berkeley-style huge rc files
* Closer to LSB and FHS standards
* Lots of stuff (both good and fun) for my GNOME Woody desktop without a lot of work
I use Slackware instead of Debian for the following:
* Floppy-only machines that have little or no internet connectivity
* Excellent for fire-and-forget machines that will never get maintained
* UMSDOS installations (Remember UMSDOS? Slackware still supports it well)
* I need a quick root/boot disk combo for an obscure legacy system
The obvious response is to try to talk them out of this misguided path. Failing that, there's something more to do than putting out your resume (I'd still put out my resume, working for bad management sucks, but there's fewer instant jobs out there lately).
If the policy requires your development machine be locked down, let it be locked down. Everytime your job requires you to do something you're not allowed to do (change a registry key, install the new compile of your program, etc), follow whatever procedure they have in place to modify your machine.
Document the time you spend filling out the paperwork, sending it to the systems administratiors, talking on the phone regarding the request, waiting for a response from systems administration, getting them back when they didn't install your program properly, and so on. Then, when they complain that your project is behind schedule, you can show them that 80% of your time is spent complying with their policy rather than doing the work you were hired for. That will go a long way towards getting control of your machine back.
This sounds like a marketing payoff, where the publisher of Quake is paying ATI to slow down competing games. I can't think of any other rational explanation for the drivers to care about the name of the executables.
Alternate suggestion: The driver surely has performance tradeoffs that need to be tuned, many complex performance-critical drivers do. Perhaps when ATI got the driver tuned well for general purpose applications, they found it worked badly for Quake. Rather than make everything work less well so Quake could be happy, they watch for quake.exe and give Quake its own custom tuning.
I'm not saying this is the case, it's merely another rational explanation, in my opinion.
There are two huge daunting problems with DRM, both technical and social in nature.
Technical Issues:
Most DRM suffer from a fatal flaw. They trust the client (hardware, software or individual) to manage rights properly. For example, CSS counts on the DVD player to keep both the CSS algorhithm and the encryption keys secret. Any such system will be cracked eventually. Once cracked, the only way to keep it from being worthless is to legally enforce totalitarian control over information distribution.
For DRM to function as advertised, there needs to be a server in place to handle authentication and authorization of clients. Few DRM systems are set up this way (Two examples: Automated Cable TV Pay-Per-View systems and Circuit City's Divx system being one example).
Social Issues:
People don't like to have rights taken away. If they've been able to do something before, and they're told they aren't allowed to anymore, they get upset. DRM systems will not be accepted if they're being used to remove rights.
Similarly, if there is are two competing systems, and one uses DRM to make things more restrictive than the other system, it will greatly hurt acceptance. For example, DVDs and Divx disks were in direct competition. Both use DRM, but DVD's DRM system is much less intrusive than Divx's was. The only advantage Divx offered was slightly better prices (at least when first introduced). Most people are willing to pay a little bit extra to not have to worry about making phone calls and expiration dates.
Let's look at a successful DRM system. Most cable companies allow you to purchase pay-per-view events through the cable box, this is a DRM system. You hit a couple of buttons, your cable box contacts the server, the server verifies that you are allowed to view pay-per-view, charges your next bill, and sends your cable box the key to access the particular show you requested.
While the system isn't perfect, it shows the halmarks of what I consider to be requirements for a successful DRM system:
* It allows you to do something you otherwise couldn't do (watch almost new movies or events without leaving your sofa).
* All critical security issues are handled on the server side (yes, except for channel lockout, I said it wasn't perfect)
* It's easy to use (12:00 flashers can even order pay-per-view)
* It makes use of an existing business arrangement, so there are not financial or contractual issues to iron out
* It makes use of an existing data connection, so there are no privacy issues to iron out (they already know who you are and what you're watching)
I think we are going to see more and more DRM systems in the near future. Assuming that most civil liberties stand in most countries (at least most of those with a consumer market), I think most DRM systems will fail, badly. The few that survive will have many of the same things going for it that pay-per-view has now.
There have been substantial advances in materials. In addition, the following technological advancements have greatly improved the usage of wheels:
* spokes
* axles
* tires
* brakes
* roads
* suspension systems
* rails
* motors
* streamlined coverings
CD sales increased both in volume and dollars. Same with DVD sales.
The two biggest drops are in Cassette sales and Music Video sales.
Casette sales have been dropping since 1992, and has nothing to do with file sharing. I'd say the biggest factor there is increasing quality and decreasing price of CD players for cars.
Music Video sales have been dropping since 1998. Don't have a good reason for that, but I'd suspect the decline of MTV/VH-1 can't be helping.
Personally, even on the CD Sales front, I've found many fewer interesting CD's being released by RIAA publishers in 2000 than in prior years. The more interesting stuff I've seen has been on independant labels (which aren't included here).
Regardless, I'm not going to cry for an industry that made only 14.3 billion dollars last year, and is using that as an excuse for screwing with my civil liberties.
I'm happy if they're lazy about making a flexible user interface while they get the functionality correct. I don't care if it's ugly if it gets the job done.
Ok, this is getting a little absurd, this is my last explanation:
Agreed, this is absurd, this is my last explanation too.
It wouldn't use as much bandwidth because the corrective worm would only fix machine it knows to have the virus, by analyzing the servers log files to see what machines have infected it and then making sure those machines are no longer infected.
This is not a feasable answer. Windows NT/2000 logs do not contain the information you seek. Even if you can point a specific log entry that would implicate, for example, a Code Red infection, there is no guarantee that future worms will cause log entries or even leave the log files intact. Windows has particularly bad logging, but even Linux/BSD/Unix machines cannot protect the log files from a worm with root access.
I snipped the rest of your post, since it all hinges on the assumption that your worm knows which machines are infected without scanning.
I would still call these people admins (clueless, incompetant admins, but admins nonetheless). In my book anybody in charge of a machine (i.e has the root/admin password and doesn't have someone else to admin for them) that is directly connected to the internet is an admin, whether they know it or not. This includes anyone who plugged their new Windows ME Gateway machine into their cable modem just to play Everquest.
I call them admins because they are in a position where they need to be responsible about how their computer is configured and interacts with other computers on the internet. The fact that they haven't the faintest idea what they've gotten themselves into is very sad.
This is why, in an earlier post, I advocated having broadband services by default seting people up with fake addresses and transparent proxy servers. People (like me) who need or want direct connections would have to know enough to at least ask for them. This measure alone would reduce some of the worst stupidity on the internet (eg. huge Zombie farms).
Don't give me "it's a symptom of the problem" bullshit. The PROBLEM as it is right now, is the worm itself. Stop this worm, stop the next, give the people time to make the server secure and all the idiots time to figure out what they've gotten themself into by assuming they can run w2k.
OK, we disagree on what the basic problem is. No big deal, we can talk about how to deal with an arbitrary worm (the worm du jour seems to be Nimda).
So your plan would be to just wait for MS to fix ALL their security holes and make it so my grandma can setup a W2k box and never have a problem? How long will that take, 5, 10, 15 years? And the fixes will introduce new bugs. So the answer is to do what gives the biggest response NOW, not a decade from now.
That wasn't my plan, although a piece of what I was discussing does involve Microsoft (and other vendors) streamlining their security patch process. There is no way that *any* vendors can fix *all* security holes. Waiting for that would be ludicrous. Regardless, I was referring to how to reduce the impact of future worms (and other internet badness), not how to deal with a worm in the wild now.
Worm in the wild now: As of this writing, the last three major worms were "Code Red", "Code Red II" and "Nimda". All three of these exploit holes in Microsoft software, and these holes were discovered and a patch written months ago. In addition, Nimda exploits holes opened up by an active Code Red II infection. Any competent administrator unfortunate enough to have to manage an IIS installation has taken their machine offline, made sure their machine is worm-free, patched NT/2000 and IIS, and put it back online. Your main concern is those admins who have not done this, and there are a disappointingly large number of them.
I don't know what you're referring to in saying that I want everybody to waste their bandwidth. Somebody would need to release a worm that fixes the whole, spreads itself, and removes itself.
Where do you think the bandwidth issue comes from? When a worm scans host machines to look for places to spread, it uses a lot of bandwidth. This is what most people here are complaining about. Your proposed worm may fix bad IIS installations, but it would have to use at least as much bandwidth as the worm it's designed to fix.
The people here (me included) won't thank you, since they care more about how these worms impact bandwidth than whether someone has an infected machine somewhere. The administrator of the machines you've "fixed" won't thank you, because now they've had two or three intrusions while they were napping, rather than one.
If the repair worm has a minor bug in it, it could potentially do more damage than the original worm, or open up a new security hole as it fixes the others. In such a case, at best you are looking at a lawsuit against you; at worst, multiple felony convictions in multiple countries.
I'm not saying everybody should install the script that simply reboots the machine, that does nothing but give the machine a 2 minutes break in between infections.
Good, because while I'm not sure what you're talking about here, it doesn't sound like a good idea.
I'm not saying the worm should scan a thousand IP addressed to see what machines are infected.
In order for a worm like you describe to work, it probably would have to scan thousands of machines for a vulnerability, infect the machine with your worm, and then detect whether or not the worm is present from the inside.
You *might* be lucky and target a worm which leaves external evidence so you can scan thousands of machines for the presense of the worm. Both Code Red II and Nimda can be detected from the outside, but the check I know of for Nimda uses a lot of bandwidth. Regardless, a worm would have to scan thousands of machines to impliment your idea, it's just a question of what it scans for.
Let it check log files if they exist, find any machines that tried to infect it, check and see if those are still infected, if not the worm should delete itself.
What log files are you talking about? None of the worms leave a log that I know of. Neither NT nor 2000 log intrusion attempts without extra software. I would wager that very few of the infected machines have IDS software installed. In order to write a worm to effectively track down and eliminate worms, you have to use scans at least as extensive as the ones the target worms are using. Unless the target worm has a buggy scanning algorhithm, any repair worm would kill at least as much bandwidth as the original worm.
This cure is worse than the disease, in my book. I'd rather focus my attention on long-term solutions that will reduce the overall problem.
Disclaimer: I am not a lawyer, the below is the personal opinion of a layman, and is not legal advice.
I agree that Microsoft != Congress, and it is perfectly legal for a contract to include terms restricting behavior in a way that would be unconstitutional were it a law produced by Congress. It happens all the time, and the courts uphold such contracts.
On the other hand, I would argue that an EULA is not a voluntarily entered contract. Valuable consideration has changed hands (i.e. you've paid for the software) before any terms of the contract are even revealed. There certainly is no opportunity to negotiate terms. There is no signature indicating assent.
In the FrontPage 2002 packaging I've seen, there is not even a EULA envelope around the software. The license document is sandwitched between other pieces of paper. You can literally install the software without even seeing that there is a license document in the box. I do not see how any terms on such a license could possibly be a "voluntarily entered contract".
It's a cool little program. It's purpose, to use up your own resources to prevent other peoples resources from being used up. There seems to be a little flaw in that logic to me.
It's a program to use a little bit of resources on one machine to reduce large resource impacts on many other machines. In addition, it allows you to detect and contact the owner of the infected host, hastening repair of the system and speeding up recovery of the net.
If you have a large network, you might very well be helping yourself far in excess of the bandwith used by the tarpit, certainly a win in my book. Even for those with small networks, some people might well be interested in sacrificing a small, controllable amount of bandwidth to help the general health and well being of the internet as a whole.
Why has nobody either sent out a worm to patch machines, or created a script to patch the sender of a worm? The bandwidth used would be minimal to what is being eaten by these worms,
That is highly debatable.
and it would SOLVE the problem.
But the problem isn't "Code Red", that's just a symptom of the problem. The problem is a combination of low security on the internet and the fact that Microsoft's monopoly has the side effect of making many identical security holes on thousands of machines.
Of course, in this day and age, nobody wants to actually solve a problem,
Nobody particularly wants to waste a great deal of bandwith to put a band aid on other people's sites for each worm that comes out, which is what you seem to recommend.
Real solutions to the problem aren't easy, but most of them are being actively worked on:
* Increase competition in internet server platforms and applications;
* Improve the distribution of security information and patches to the end users;
* More commercial internet monitoring and response services (eg. Counterpane);
* Security-conscious internet insurance plans
* Segregate the typical broadband customer behind transparent firewalls (I'd pay extra for a premium broadband service to give me a real IP if it would get the bozos who shouldn't have a computer much less an internet server off the real IP space).
You make some valid points, but what exactly do you see as the D.W.-II (to use your terminology) equivalent of crack houses, drive-by shootings, and monies spent cleaning up after people whose meth labs go up in flames [cnn.com] and result in the deaths of totally innocent people?
Note that all three of those examples are examples of the dangers of criminalization of drugs.
If meth were legal, production would be regulated, and meth labs wouldn't go up in flames any more than any other pharmaceutical production does.
If drugs were legal, there would be no incentive for drug dealers to do drive-by shootings. Criminal businesses cannot use most legal means to protect their business, hence criminal violence. Take the business away from the criminals, and it will become no more violent than any other legal enterprise.
If crack were legal, distribution would be regulated. You wouldn't have crack houses, you'd probably have closer to the crack equivalent of a dive bar (still not pretty, but crack is not the most socially endearing drug, criminal or not).
I'm not trying to argue that drugs should be legalized (I'll save that for another day), but I am pointing out that the strongest examples of how bad drugs are direct results of the fact that they are criminal, not that they are drugs.
If you make encryption (or some other aspect of software) criminal, than the nature of criminalization will permit bad things to be associated with it. This, in turn, will be used as an example of why encryption is bad, and should remain illegal.
Um, being arrested for holding a copyright does qualify as a speech crime. Freedom of speech has always included more than just the spoken word.
Also, I assume the ACLU, like any organization with a website, takes their online feedback page with a grain of salt. They're not going to decide to ignore an issue just because someone represented it imperfectly on the feedback page. While I won't speculate as to why, I'm sure they are ignoring the case for completely different reasons than this feedback entry.
Re:notoriously buggy?
on
Netscape 6.1
·
· Score: 4, Informative
The Dev asks:
Um, what exactly don't you like about Netscape 4.x (now 4.78)? It's stable (as least on windows and FreeBSD), fast and a nice integrated mail client (sucky for newsgroups though).
(Note: I am not an IE fan, in fact I use Mozilla as my main browser; also note: most of my Netscape 4.x experience is with the Linux version, your mileage may vary).
Here's a quick, of the top of my head, list of some things I don't like about Netscape 4.x
* Pathetically non-standard CSS implementation
* Annoyingly quirky DOM implementation
* Crashes more than Mozilla 0.9.2 and above (at least for me)
* Mail client can't handle multiple accounts
* Does not properly handle being executed more than once at a time
* Pointless HTML editor that just takes up space
* Awkward rendering; particularly bad handling of fonts and text placement
* Badly chosen or missing keyboard shortcuts
* Occasionally corrupts downloaded binaries
Yes, some of these gripes also carry over to Mozilla (eg integrated HTML editor), but it's already pretty much surpassed 4.x in features (it's missing a few, but has many that 4.x couldn't even think about), and blown way past it in standards compliance and ease to develop for.
IE 5.x is (mostly) more standards compliant than Netscape 4.x, but at the expense of security (on windows) or performance (on unix). It is also, in my experience, far less stable than Netscape 4.x.
I'm looking forward to the day when I can focus my website development on looking good on IE 5.0+, Netscape 6.1+ (6.0 is best forgotten) and Mozilla 1.0+, and dump support for both Netscape and IE's obnoxious 4.x browsers.
Problem is, XML is one of the latest forms of fairy dust that Management has latched onto. "Sprinkle this on your project and it will fly!" So programs have XML grafted onto them anywhere it might fit.
XML is no magic bullet; however, that doesn't change the fact that it is incredibly useful in many different circumstances. XML, realistically used, can make some projects simpler, and data transfers much more comprehensible.
A particularly cute example is SOAP (Microsoft's firewall-bypass protocol) It's going to be fun to watch people try to squeeze some performance out of a SOAP based system that tries to do something interactive.
SOAP, XML-RPC and similar protocols are designed for generic, highly interoperable, communications, not performance. Anybody who expects blinding performance out of an XML encoded procedure call shouldn't be programming. You want performance, use a custom protocol, or at least CORBA. SOAP is for when you can sacrifice performance to gain interoperability.
I'd even go a step farther: anything that can be done using an XML-based data format can be done smaller and faster by some other design. However, as machines get larger, faster and cheaper, getting that last bit of performance becomes less and less important for most computing tasks. XML is great for tasks that don't need every last ounce of speed. Save the custom-tuned binary formats and protocols for the few apps that really need them.
Might as well be running Lynx then. That's even faster *and* more stable than Netscape 4.xx with everything off. Plus, it has handy keyboard shortcuts to make quick browsing easier.
If I were an insurance adjuster trying to insure peoples' information technology assets, I would have my own experts supervising everyone who was on the insurance plan to ensure that they patched their fucking software.
Good! Poor security needs to hit companies where not only it hurts, but boards of directors and shareholders will see it: in the insurance premium line on their budget.
Or I would make it against the law not to patch one's software, similar to the laws ensuring the vaccination of children, and for the same reasons; such an epidemic, viral or virtual, delivers a powerful blow to our economy and is a matter of national security.
This I would be going far. Every business should be allowed to make their own stupid decisions. Save regulation for where it actually can do some good; for example, keeping businesses from harming consumers or each other.
Slashdot Mirror
Second, if the sensitive information is going to a select few people, consider PGP encrypting the data, and only putting the encrypted version online. Doing this makes many of the HTTP security issues less critical.
Assuming you still have to put something sensitive online, make sure of the following:
- Only use HTTPS, never use just plain HTTP.
- Use CGI, Java Servlets, or some other server-side program technology to password-protect the site. I will refer to the resulting program(s) as the security program
- Never accept a password from a GET request, only accept them from POST requests.
- Never make the user list or password list visible from the internet, not even an encrypted password list.
- Never place the sensitive information in a directory the web server software knows how to access. Only the security program should know how to find the info.
- Review all documentation for your web server software and the platform used for the security program. Pay special attention to seciurity issues, make sure you aren't inadvertently opening up holes. Keep current, do this at minimum four times a year.
- Subscribe to any security mailing lists for your web server platform operating system web server software, and for the programing platform you used for the security program. If there is anything else running on this machine, subscribe to their security mailing lists too.
- Subscribe to cert-advisory and BugTraq. Read in detail all the messages that are relevant to your setup. Review your setup after each relevant message.
- Don't use IIS.
- Don't use Windows 95/98/Me. Don't use Windows XP Home Edition.
- Don't use any version of MacOS before OS X.
- Don't use website hosting services for sensitive information.
- Never connect to this webserver using telnet, ftp or FrontPage. SSH is your friend.
- Never have Front Page Extensions (or its clones or workalikes) installed on a webserver with sensitive data.
- If there is anything above that you don't understand, or if you can't afford the time for any of the above, hire a professional with security experience and recommendations from people you trust who have used his or her services. It's bad enough that amateurs are running webservers, much less running ecommerce sites and other sites with sensitive data.
The above is an incomplete list. It is primarly there to start giving people an idea of how much effort they should expect to put into a properly administered secure website with sensitive information. Do you really need to distribute this via a web browser?There also exist small generators that work well off of LP Gas or even Alcohol. Not saying that's what he uses, but it's another possibility.
A professional programmer in Afghanistan is likely to have access funds and resources that the average person does not.
And people say it's easy to install windows. Two days and there's still more work to do.
Anonymous Coward writes:
/usr/bin/vi is a link to /etc/alternatives/vi, which is itself a link to the vi-compatible binary of your choice. There's a tiny bit of overhead to bounce through the two symbolic links, but no extra processes are generated and you run a binary executable directly.
and here is a gem for the minimalistic: did you know that "vi" in debian is a script that runs a version of vi accordingly to the user's preferences? Really. When you type 'vi' you fork another bash!
I don't know if that was the case ages ago, but in Potato and later vi is not a script, and doesn't fork an additional bash.
Debian does give people a choice of vi's (vim, nvi, elvis and elvis-tiny, possibly more). It does it with simple symbolic links.
I started with Slackware, moved to RedHat at version 4.1, tried to move to Debian when Hamm was released (gave up in frustration), and then moved to Debian sucessfully when Potato was released. I am definately happy with Debian. I still use Slackware for rare installations (I certainly use it more than I use RedHat).
:-)
Reasons I prefer Debian over Slackware for most systems:
* Fastest path from bare metal to rock-solid stable server
* Easier to maintain, particularly security updates
* Well thought out system configuration files and scripts
* Debian puts more development manhours into making sure the packages are debugged and working well together
* I prefer modular System V-style init scripts to Berkeley-style huge rc files
* Closer to LSB and FHS standards
* Lots of stuff (both good and fun) for my GNOME Woody desktop without a lot of work
I use Slackware instead of Debian for the following:
* Floppy-only machines that have little or no internet connectivity
* Excellent for fire-and-forget machines that will never get maintained
* UMSDOS installations (Remember UMSDOS? Slackware still supports it well)
* I need a quick root/boot disk combo for an obscure legacy system
The rest of the time, I use TomsRtBt
It seems more like some badly informed member of Verisign management. Shit flows downhill, and Thawte was bought out by Verisign a while ago.
The obvious response is to try to talk them out of this misguided path. Failing that, there's something more to do than putting out your resume (I'd still put out my resume, working for bad management sucks, but there's fewer instant jobs out there lately).
If the policy requires your development machine be locked down, let it be locked down. Everytime your job requires you to do something you're not allowed to do (change a registry key, install the new compile of your program, etc), follow whatever procedure they have in place to modify your machine.
Document the time you spend filling out the paperwork, sending it to the systems administratiors, talking on the phone regarding the request, waiting for a response from systems administration, getting them back when they didn't install your program properly, and so on. Then, when they complain that your project is behind schedule, you can show them that 80% of your time is spent complying with their policy rather than doing the work you were hired for. That will go a long way towards getting control of your machine back.
Another workaround:
$ lynx -useragent="Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)" http://msn.com
Works good, and doesn't require you change configuration options of your browser. Fewer annoying MSN addvertisements to bug you as well.
StenD writes:
This sounds like a marketing payoff, where the publisher of Quake is paying ATI to slow down competing games. I can't think of any other rational explanation for the drivers to care about the name of the executables.
Alternate suggestion: The driver surely has performance tradeoffs that need to be tuned, many complex performance-critical drivers do. Perhaps when ATI got the driver tuned well for general purpose applications, they found it worked badly for Quake. Rather than make everything work less well so Quake could be happy, they watch for quake.exe and give Quake its own custom tuning.
I'm not saying this is the case, it's merely another rational explanation, in my opinion.
There are two huge daunting problems with DRM, both technical and social in nature.
Technical Issues:
Most DRM suffer from a fatal flaw. They trust the client (hardware, software or individual) to manage rights properly. For example, CSS counts on the DVD player to keep both the CSS algorhithm and the encryption keys secret. Any such system will be cracked eventually. Once cracked, the only way to keep it from being worthless is to legally enforce totalitarian control over information distribution.
For DRM to function as advertised, there needs to be a server in place to handle authentication and authorization of clients. Few DRM systems are set up this way (Two examples: Automated Cable TV Pay-Per-View systems and Circuit City's Divx system being one example).
Social Issues:
People don't like to have rights taken away. If they've been able to do something before, and they're told they aren't allowed to anymore, they get upset. DRM systems will not be accepted if they're being used to remove rights.
Similarly, if there is are two competing systems, and one uses DRM to make things more restrictive than the other system, it will greatly hurt acceptance. For example, DVDs and Divx disks were in direct competition. Both use DRM, but DVD's DRM system is much less intrusive than Divx's was. The only advantage Divx offered was slightly better prices (at least when first introduced). Most people are willing to pay a little bit extra to not have to worry about making phone calls and expiration dates.
Let's look at a successful DRM system. Most cable companies allow you to purchase pay-per-view events through the cable box, this is a DRM system. You hit a couple of buttons, your cable box contacts the server, the server verifies that you are allowed to view pay-per-view, charges your next bill, and sends your cable box the key to access the particular show you requested.
While the system isn't perfect, it shows the halmarks of what I consider to be requirements for a successful DRM system:
* It allows you to do something you otherwise couldn't do (watch almost new movies or events without leaving your sofa).
* All critical security issues are handled on the server side (yes, except for channel lockout, I said it wasn't perfect)
* It's easy to use (12:00 flashers can even order pay-per-view)
* It makes use of an existing business arrangement, so there are not financial or contractual issues to iron out
* It makes use of an existing data connection, so there are no privacy issues to iron out (they already know who you are and what you're watching)
I think we are going to see more and more DRM systems in the near future. Assuming that most civil liberties stand in most countries (at least most of those with a consumer market), I think most DRM systems will fail, badly. The few that survive will have many of the same things going for it that pay-per-view has now.
Not the concept, but the implementation.
There have been substantial advances in materials. In addition, the following technological advancements have greatly improved the usage of wheels:
* spokes
* axles
* tires
* brakes
* roads
* suspension systems
* rails
* motors
* streamlined coverings
Looking at the chart:
CD sales increased both in volume and dollars. Same with DVD sales.
The two biggest drops are in Cassette sales and Music Video sales.
Casette sales have been dropping since 1992, and has nothing to do with file sharing. I'd say the biggest factor there is increasing quality and decreasing price of CD players for cars.
Music Video sales have been dropping since 1998. Don't have a good reason for that, but I'd suspect the decline of MTV/VH-1 can't be helping.
Personally, even on the CD Sales front, I've found many fewer interesting CD's being released by RIAA publishers in 2000 than in prior years. The more interesting stuff I've seen has been on independant labels (which aren't included here).
Regardless, I'm not going to cry for an industry that made only 14.3 billion dollars last year, and is using that as an excuse for screwing with my civil liberties.
I'm happy if they're lazy about making a flexible user interface while they get the functionality correct. I don't care if it's ugly if it gets the job done.
scott1853 wrote:
Ok, this is getting a little absurd, this is my last explanation:
Agreed, this is absurd, this is my last explanation too.
It wouldn't use as much bandwidth because the corrective worm would only fix machine it knows to have the virus, by analyzing the servers log files to see what machines have infected it and then making sure those machines are no longer infected.
This is not a feasable answer. Windows NT/2000 logs do not contain the information you seek. Even if you can point a specific log entry that would implicate, for example, a Code Red infection, there is no guarantee that future worms will cause log entries or even leave the log files intact. Windows has particularly bad logging, but even Linux/BSD/Unix machines cannot protect the log files from a worm with root access.
I snipped the rest of your post, since it all hinges on the assumption that your worm knows which machines are infected without scanning.
I would still call these people admins (clueless, incompetant admins, but admins nonetheless). In my book anybody in charge of a machine (i.e has the root/admin password and doesn't have someone else to admin for them) that is directly connected to the internet is an admin, whether they know it or not. This includes anyone who plugged their new Windows ME Gateway machine into their cable modem just to play Everquest.
I call them admins because they are in a position where they need to be responsible about how their computer is configured and interacts with other computers on the internet. The fact that they haven't the faintest idea what they've gotten themselves into is very sad.
This is why, in an earlier post, I advocated having broadband services by default seting people up with fake addresses and transparent proxy servers. People (like me) who need or want direct connections would have to know enough to at least ask for them. This measure alone would reduce some of the worst stupidity on the internet (eg. huge Zombie farms).
scott1853 writes:
Don't give me "it's a symptom of the problem" bullshit. The PROBLEM as it is right now, is the worm itself. Stop this worm, stop the next, give the people time to make the server secure and all the idiots time to figure out what they've gotten themself into by assuming they can run w2k.
OK, we disagree on what the basic problem is. No big deal, we can talk about how to deal with an arbitrary worm (the worm du jour seems to be Nimda).
So your plan would be to just wait for MS to fix ALL their security holes and make it so my grandma can setup a W2k box and never have a problem? How long will that take, 5, 10, 15 years? And the fixes will introduce new bugs. So the answer is to do what gives the biggest response NOW, not a decade from now.
That wasn't my plan, although a piece of what I was discussing does involve Microsoft (and other vendors) streamlining their security patch process. There is no way that *any* vendors can fix *all* security holes. Waiting for that would be ludicrous. Regardless, I was referring to how to reduce the impact of future worms (and other internet badness), not how to deal with a worm in the wild now.
Worm in the wild now: As of this writing, the last three major worms were "Code Red", "Code Red II" and "Nimda". All three of these exploit holes in Microsoft software, and these holes were discovered and a patch written months ago. In addition, Nimda exploits holes opened up by an active Code Red II infection. Any competent administrator unfortunate enough to have to manage an IIS installation has taken their machine offline, made sure their machine is worm-free, patched NT/2000 and IIS, and put it back online. Your main concern is those admins who have not done this, and there are a disappointingly large number of them.
I don't know what you're referring to in saying that I want everybody to waste their bandwidth. Somebody would need to release a worm that fixes the whole, spreads itself, and removes itself.
Where do you think the bandwidth issue comes from? When a worm scans host machines to look for places to spread, it uses a lot of bandwidth. This is what most people here are complaining about. Your proposed worm may fix bad IIS installations, but it would have to use at least as much bandwidth as the worm it's designed to fix.
The people here (me included) won't thank you, since they care more about how these worms impact bandwidth than whether someone has an infected machine somewhere. The administrator of the machines you've "fixed" won't thank you, because now they've had two or three intrusions while they were napping, rather than one.
If the repair worm has a minor bug in it, it could potentially do more damage than the original worm, or open up a new security hole as it fixes the others. In such a case, at best you are looking at a lawsuit against you; at worst, multiple felony convictions in multiple countries.
I'm not saying everybody should install the script that simply reboots the machine, that does nothing but give the machine a 2 minutes break in between infections.
Good, because while I'm not sure what you're talking about here, it doesn't sound like a good idea.
I'm not saying the worm should scan a thousand IP addressed to see what machines are infected.
In order for a worm like you describe to work, it probably would have to scan thousands of machines for a vulnerability, infect the machine with your worm, and then detect whether or not the worm is present from the inside.
You *might* be lucky and target a worm which leaves external evidence so you can scan thousands of machines for the presense of the worm. Both Code Red II and Nimda can be detected from the outside, but the check I know of for Nimda uses a lot of bandwidth. Regardless, a worm would have to scan thousands of machines to impliment your idea, it's just a question of what it scans for.
Let it check log files if they exist, find any machines that tried to infect it, check and see if those are still infected, if not the worm should delete itself.
What log files are you talking about? None of the worms leave a log that I know of. Neither NT nor 2000 log intrusion attempts without extra software. I would wager that very few of the infected machines have IDS software installed. In order to write a worm to effectively track down and eliminate worms, you have to use scans at least as extensive as the ones the target worms are using. Unless the target worm has a buggy scanning algorhithm, any repair worm would kill at least as much bandwidth as the original worm.
This cure is worse than the disease, in my book. I'd rather focus my attention on long-term solutions that will reduce the overall problem.
Disclaimer: I am not a lawyer, the below is the personal opinion of a layman, and is not legal advice.
I agree that Microsoft != Congress, and it is perfectly legal for a contract to include terms restricting behavior in a way that would be unconstitutional were it a law produced by Congress. It happens all the time, and the courts uphold such contracts.
On the other hand, I would argue that an EULA is not a voluntarily entered contract. Valuable consideration has changed hands (i.e. you've paid for the software) before any terms of the contract are even revealed. There certainly is no opportunity to negotiate terms. There is no signature indicating assent.
In the FrontPage 2002 packaging I've seen, there is not even a EULA envelope around the software. The license document is sandwitched between other pieces of paper. You can literally install the software without even seeing that there is a license document in the box. I do not see how any terms on such a license could possibly be a "voluntarily entered contract".
scott1853 writes:
It's a cool little program. It's purpose, to use up your own resources to prevent other peoples resources from being used up. There seems to be a little flaw in that logic to me.
It's a program to use a little bit of resources on one machine to reduce large resource impacts on many other machines. In addition, it allows you to detect and contact the owner of the infected host, hastening repair of the system and speeding up recovery of the net.
If you have a large network, you might very well be helping yourself far in excess of the bandwith used by the tarpit, certainly a win in my book. Even for those with small networks, some people might well be interested in sacrificing a small, controllable amount of bandwidth to help the general health and well being of the internet as a whole.
Why has nobody either sent out a worm to patch machines, or created a script to patch the sender of a worm? The bandwidth used would be minimal to what is being eaten by these worms,
That is highly debatable.
and it would SOLVE the problem.
But the problem isn't "Code Red", that's just a symptom of the problem. The problem is a combination of low security on the internet and the fact that Microsoft's monopoly has the side effect of making many identical security holes on thousands of machines.
Of course, in this day and age, nobody wants to actually solve a problem,
Nobody particularly wants to waste a great deal of bandwith to put a band aid on other people's sites for each worm that comes out, which is what you seem to recommend.
Real solutions to the problem aren't easy, but most of them are being actively worked on:
* Increase competition in internet server platforms and applications;
* Improve the distribution of security information and patches to the end users;
* More commercial internet monitoring and response services (eg. Counterpane);
* Security-conscious internet insurance plans
* Segregate the typical broadband customer behind transparent firewalls (I'd pay extra for a premium broadband service to give me a real IP if it would get the bozos who shouldn't have a computer much less an internet server off the real IP space).
Anonymous Coward wrote:
You make some valid points, but what exactly do you see as the D.W.-II (to use your terminology) equivalent of crack houses, drive-by shootings, and monies spent cleaning up after people whose meth labs go up in flames [cnn.com] and result in the deaths of totally innocent people?
Note that all three of those examples are examples of the dangers of criminalization of drugs.
If meth were legal, production would be regulated, and meth labs wouldn't go up in flames any more than any other pharmaceutical production does.
If drugs were legal, there would be no incentive for drug dealers to do drive-by shootings. Criminal businesses cannot use most legal means to protect their business, hence criminal violence. Take the business away from the criminals, and it will become no more violent than any other legal enterprise.
If crack were legal, distribution would be regulated. You wouldn't have crack houses, you'd probably have closer to the crack equivalent of a dive bar (still not pretty, but crack is not the most socially endearing drug, criminal or not).
I'm not trying to argue that drugs should be legalized (I'll save that for another day), but I am pointing out that the strongest examples of how bad drugs are direct results of the fact that they are criminal, not that they are drugs.
If you make encryption (or some other aspect of software) criminal, than the nature of criminalization will permit bad things to be associated with it. This, in turn, will be used as an example of why encryption is bad, and should remain illegal.
Um, being arrested for holding a copyright does qualify as a speech crime. Freedom of speech has always included more than just the spoken word.
Also, I assume the ACLU, like any organization with a website, takes their online feedback page with a grain of salt. They're not going to decide to ignore an issue just because someone represented it imperfectly on the feedback page. While I won't speculate as to why, I'm sure they are ignoring the case for completely different reasons than this feedback entry.
The Dev asks:
Um, what exactly don't you like about Netscape 4.x (now 4.78)? It's stable (as least on windows and FreeBSD), fast and a nice integrated mail client (sucky for newsgroups though).
(Note: I am not an IE fan, in fact I use Mozilla as my main browser; also note: most of my Netscape 4.x experience is with the Linux version, your mileage may vary).
Here's a quick, of the top of my head, list of some things I don't like about Netscape 4.x
* Pathetically non-standard CSS implementation
* Annoyingly quirky DOM implementation
* Crashes more than Mozilla 0.9.2 and above (at least for me)
* Mail client can't handle multiple accounts
* Does not properly handle being executed more than once at a time
* Pointless HTML editor that just takes up space
* Awkward rendering; particularly bad handling of fonts and text placement
* Badly chosen or missing keyboard shortcuts
* Occasionally corrupts downloaded binaries
Yes, some of these gripes also carry over to Mozilla (eg integrated HTML editor), but it's already pretty much surpassed 4.x in features (it's missing a few, but has many that 4.x couldn't even think about), and blown way past it in standards compliance and ease to develop for.
IE 5.x is (mostly) more standards compliant than Netscape 4.x, but at the expense of security (on windows) or performance (on unix). It is also, in my experience, far less stable than Netscape 4.x.
I'm looking forward to the day when I can focus my website development on looking good on IE 5.0+, Netscape 6.1+ (6.0 is best forgotten) and Mozilla 1.0+, and dump support for both Netscape and IE's obnoxious 4.x browsers.
StormyMonday writes:
Problem is, XML is one of the latest forms of fairy dust that Management has latched onto. "Sprinkle this on your project and it will fly!" So programs have XML grafted onto them anywhere it might fit.
XML is no magic bullet; however, that doesn't change the fact that it is incredibly useful in many different circumstances. XML, realistically used, can make some projects simpler, and data transfers much more comprehensible.
A particularly cute example is SOAP (Microsoft's firewall-bypass protocol) It's going to be fun to watch people try to squeeze some performance out of a SOAP based system that tries to do something interactive.
SOAP, XML-RPC and similar protocols are designed for generic, highly interoperable, communications, not performance. Anybody who expects blinding performance out of an XML encoded procedure call shouldn't be programming. You want performance, use a custom protocol, or at least CORBA. SOAP is for when you can sacrifice performance to gain interoperability.
I'd even go a step farther: anything that can be done using an XML-based data format can be done smaller and faster by some other design. However, as machines get larger, faster and cheaper, getting that last bit of performance becomes less and less important for most computing tasks. XML is great for tasks that don't need every last ounce of speed. Save the custom-tuned binary formats and protocols for the few apps that really need them.
Flash works fine for me. Mozilla 0.9.3 (Build 2001080104), Shockwave Flash 5.0r47.
:-)
Macromedia said they'd never support Mozilla, they never said anything about not supporting Netscape 6, and Mozilla uses the same plugins
Might as well be running Lynx then. That's even faster *and* more stable than Netscape 4.xx with everything off. Plus, it has handy keyboard shortcuts to make quick browsing easier.
perdida writes:
If I were an insurance adjuster trying to insure peoples' information technology assets, I would have my own experts supervising everyone who was on the insurance plan to ensure that they patched their fucking software.
Good! Poor security needs to hit companies where not only it hurts, but boards of directors and shareholders will see it: in the insurance premium line on their budget.
Or I would make it against the law not to patch one's software, similar to the laws ensuring the vaccination of children, and for the same reasons; such an epidemic, viral or virtual, delivers a powerful blow to our economy and is a matter of national security.
This I would be going far. Every business should be allowed to make their own stupid decisions. Save regulation for where it actually can do some good; for example, keeping businesses from harming consumers or each other.
----