That's part of the Unix philosophy, so some old farts will defend you to the death (:-))
Joking aside, Unix approaches to problems often forked initially and then joined over time. Consider, for example, sockets -> (sockets and tls) -> sockets. That might well happen to desktops if the commonalities outnumber the differences.
[I commented on part of this below, but wan't logged in...] Blocking infected PCs is a new problem for computer science to debate, but it's very similar to long-solved "public health" problems in the world where viruses are composed of atoms, so we can borrow some of the cures from there. This is also a good way to keep from looking stupid in front of the courts!
People who are being spammed by your PC can legitimately use the minimum force necessary to stop the harm, not including shooting it or you. This is the starting point in law: a harmed individual, who has some limited rights to respond in self-defense.
If your PC is trying to infect theirs, they can tell the local board of health, and have have you asked to quarantine yourself until the disease is cured. In this case, the board of health is the ISP, and they're asking you every time you try to send spam/viruses. They're allowed to wear a surgical mask while asking, as well, in this case over their port 25. They're not allowed to put you in an impervious plastic bag to stop you from breathing: that's not minimum force.
If you or your PC resists being quarantined, they can apply to the courts for an order to have the PC locked up and treated against it's will. That'a a real court, with real judges and court orders, not an ISP. In that case you can argue against it, but you'd better have a legally valid reason, not "you can't do that to me". And if necessary you can object, and argue it out before a judge.
One suggestion to Slashdot readers. If you're in a situation like this, do your best to use your phone to record what's happening without being noticed.
As I'm in Toronto, I have the 1.4 (early) release of the "Crimestoppers" app on Android.
It gives me the option to record a video, a picture or find the nearest police station, etc. The tips are submitted semi-anonymously to the "crimestoppers" organization, who can pass them on to the police or courts.
Because it doesn't have a link, just the usual kind of language you see when it's a non-commercial entity: "choose a reliable provider of antivirus programs, and follow their instructions for the removal of the DNS Changer virus".
In a discussion with a network capacity planning firm some time ago, the discussion turned to the amount of outgoing spam that ISPs let flow out of their systems, while at the same time madly filtering incoming spam.
A defence in depth would arguably be more effective, as much as four times as effective for the same amount of work, and probabilistically even better.
The arguments we heard were that the ISPs could not legally block their customer's outgoing mail. In fact, the same applied to blocking their incoming mail, it's just that customers are inured to having to go looking for mail in the spam-bucket.
As some customer's email systems are already refusing to send various sorts of attachment, like.zip files, because they may contain viruses, individual customers are now beginning to become inured to having to take special steps in order to send mail.
Logically, a wise ISP could take advantage of that and start returning messages like:
Your message was marked "spam" by the security scanner, and will be rejected by the recipient. Please read the attached spam report and, if this is a legitimate message, correct it so it is not rejected as spam.
... as one can chose "safe search" or not. It seem like a good option for search engines, a possible-but-onerous one for browsers (ask Google if a page is safe?) and a huge expensive kludge for ISPs.
In fact, she proposes that supply management, supported by her own party, is badly broken and needs to be fixed. One of the side-effects was to cause massive consolidation in the industry, displacing individual farmers. A second was to make Canada look like it wasn't playing fair in international trade, her area of expertise. A third was to drive up the cost of milk.
The PR benefits, alas, go the the government of the day. The real benefits go to the dairy farmers, who also get a reduction in the cost of (re-)entry into the market. Ditto to the consumers, who get cheaper milk.
It's not bad when your proposal addresses harm to the farmers, harm to the consumers and unfairness to our trading partners. That's it benefits a political (as opposed to real) opponent is just a cost of doing business.
To get into the trade "club", we have to give things up that we consider inalienable. Rock, meet hard place.
As the government of the day is more concerned with trade and less with issues of care/harm, they chose the rock.
A wise government would chose neither, but instead move the subject sideways to a place where both trade and rights are honoured. For example, they could honour DRM only if the company held a Canadian copyright, and agreed to make excerpts available, for a nominal fee, whenever the use was legal in Canada.
A follow-on thought: there is really no reason why ISPs can't mimic the libraries and pick software that makes it easy to obey the law, and hard for people without search warrants to get information they shouldn't have.
As I said, this can be done with DHCP servers, and most of the statistical information an ISP needs can have the identifying material stripped out. It's only the information you need for debugging that you need to keep after a session is over. That's a lot like keeping "user X hasn't paid for lost book Y yet": at some point it goes away!
For example, I might keep a cache of MAC address to IP address in between sessions, to save a DHCP re-assignment and give a customer a pseudo-static IP if they requested it. Every other IP given to a cable-modem would be dynamic, and not useful for snooping. The users of static and semi-static addresses would have to make a deliberate choice to give away privacy in order to have stability. Those customers would presumably be small businesses, and not individuals with privacy concerns.
For debugging, I might keep a further cache of recently-used MAC/IP bindings, but I'd be mildly reluctant to disclose that to any random request.
ISPs are relatively new, and haven't had the problem for most of a century (:-))
When I was at York University, we were next door to the Science Library, and when we had a problem about people objecting to things on the 'net, we went next door and asked our colleagues. They pointed us to a big poster from the Canadian Library Association, that said (in much nicer terms) "You legitimately feel bad, but you can't just tell people to shut up".
Someone always want to be able to ask if a particular person has read "Steal This Book", or "How to Build an Atom Bomb". Librarians get that kind of demand all the time, and have successfully fought it at the personal and also at the technical level.
I once worked on library software, and it was a prerequisite in the business that, as soon as a book was returned or the non-return fine was paid, the record that "user X borrowed book Y" was deleted, and a counter of completed transaction was incremented. The latter was necessary for funding and statistical purposes.
This was a norm because the library community actively went out and found a number of states, Germany among them, that protected library patrons from snooping without a warrant. They then made that know to their software suppliers. As the software had to be legal in all the countries where it was to be sold, it was written to meet the highest legal standards, which included the highest privacy standards.
If a legitimate investigation needed to track a library patron's reading, and the investigator could convince a judge, then the library could put a watch on a patron in exchange for a warrant. The watch could not start in the past, of course, but a daily sql query could find out the books a patron currently had out.
There is at least one DHCP program around, written by an ex-librarian, that behaves just this way...
One of the best approaches was to create a TLD for each of the major categories one can get a trademark in. For example, airlines, shipping lines, etc. Then one could have Olympic.Airlines, Olympic.Shipping and so on, without the current problems of the Olympic Organizing Committee getting all the "Olympic"s in the world.
One of my papers on the subject was D. Collier-Brown, On Experimental Top Level Domains, Rev 0, Internet Draft, draft-collier-brown-itld-exper-00.txt, Sept 1996, which may still be findable. Much of the other work seems to have been expunged...
Numerous approaches were debated by the international ad-hoc committee on domain names, but the most profitable to the registrars "won", leading to the current mess. In retrospect, we needed a stringently fair, non-commercial process to make the decision.
In ARPA-speak,that would be
4 -- temporary error
9 -- OS problem, not application
9 -- a unique number
followed by a blank and a human-readable message in ascii,
This is from memory, you understand, but it expresses the basic idea: your country doesn't let you connect, so it's a tempoirary failure until such time as you fix the political problem or move.
The way the "common criteria" are defined, you need to be an accountant or a logician to figure out just what feature set they claim a high security on. I usually wasl "would it meet B2?" If they can't answer, it won't (;-))
--dave (and yes, on good days I am a logician) c-b
B2, from the Orange Book, is an old military standard, approximately what SELinux meets. C means crappy, and there were a very few people who got an A
Whether or not you virtualize a given workload, you need to manage its resource usage. In the trivial case, you can see your CPU used up by some other program unless you provide your program a guarantee of enough CPU for the actual number of users who will be employing it.
Ditto memory, disk and networ I/O, bus bandwidth, etc, etc.
A more surprising case is putting two workloads together that formerly worked properly on an older, slower machine. If you increase the amount of a critical resource, both programs under load will start using more of every resource. For example, a batch job that got 30% more CPU increased the amount of disk I/O it did by several times. An interactive program on the same machine was rendered almost completely unusable because it couldn't do the I/O it needed. The customer in that case thought the vendor was lying about the speed of the machine, and demanded his old one back.
Linux is a hotbed of resource management experimentation, so you can statically size and configure a program (workload) to be able to withstand a given load. Commercial Unixes have good enough controls to do most common cases. I can't speak about Windows and BSD, as I've not researched them (yet). Mainframes, not surprisingly, have the best controls for what in their days were exceedingly precious resources.
If your OS doesn't have good resource controls, or if you don't know how to use them well, you'll end up splitting up the virtual machines onto a undesirably large number of physical machines, just in order to do the management the hard way.
The difficulty, by the way, varies as something like the square of the number of machines and the resources used, so virtualization and consolidation is easy for well-behaved, small and unimportant programs, and can be evil for anything that turns out to be big, resource-intensive or important. Think of that as a lemma used to derive Murphy's law (:-)).
Slashdot Mirror
That's part of the Unix philosophy, so some old farts will defend you to the death (:-))
Joking aside, Unix approaches to problems often forked initially and then joined over time. Consider, for example, sockets -> (sockets and tls) -> sockets. That might well happen to desktops if the commonalities outnumber the differences.
--dave
People who are being spammed by your PC can legitimately use the minimum force necessary to stop the harm, not including shooting it or you. This is the starting point in law: a harmed individual, who has some limited rights to respond in self-defense.
If your PC is trying to infect theirs, they can tell the local board of health, and have have you asked to quarantine yourself until the disease is cured. In this case, the board of health is the ISP, and they're asking you every time you try to send spam/viruses. They're allowed to wear a surgical mask while asking, as well, in this case over their port 25. They're not allowed to put you in an impervious plastic bag to stop you from breathing: that's not minimum force.
If you or your PC resists being quarantined, they can apply to the courts for an order to have the PC locked up and treated against it's will. That'a a real court, with real judges and court orders, not an ISP. In that case you can argue against it, but you'd better have a legally valid reason, not "you can't do that to me". And if necessary you can object, and argue it out before a judge.
--dave
One suggestion to Slashdot readers. If you're in a situation like this, do your best to use your phone to record what's happening without being noticed.
As I'm in Toronto, I have the 1.4 (early) release of the "Crimestoppers" app on Android. It gives me the option to record a video, a picture or find the nearest police station, etc. The tips are submitted semi-anonymously to the "crimestoppers" organization, who can pass them on to the police or courts.
--dave
Because it doesn't have a link, just the usual kind of language you see when it's a non-commercial entity: "choose a reliable provider of antivirus programs, and follow their instructions for the removal of the DNS Changer virus".
--dave
Don;t make them click anything, and include a warning about fake virus checkers asking them to click...
Yup: I saw the Paul Vixie quote and read it for the first time. Too bad it wasn't a more substantiative article... --dave
Point to a "you need to fix your computer page?" is brilliant and obvious. Darn, why didn't I think of that!
--davecb
No, because it's the old conservative government's task to punish malefactors.
--dave
In a discussion with a network capacity planning firm some time ago, the discussion turned to the amount of outgoing spam that ISPs let flow out of their systems, while at the same time madly filtering incoming spam.
A defence in depth would arguably be more effective, as much as four times as effective for the same amount of work, and probabilistically even better.
The arguments we heard were that the ISPs could not legally block their customer's outgoing mail. In fact, the same applied to blocking their incoming mail, it's just that customers are inured to having to go looking for mail in the spam-bucket.
As some customer's email systems are already refusing to send various sorts of attachment, like .zip files, because they may contain viruses, individual customers are now beginning to become inured to having to take special steps in order to send mail.
Logically, a wise ISP could take advantage of that and start returning messages like:
Your message was marked "spam" by the security scanner, and will be rejected by the recipient.
Please read the attached spam report and, if this is a legitimate message, correct it so it is not rejected as spam.
--dave
Does "cloud sourced" also imply "buy my product?" --dave
... as one can chose "safe search" or not. It seem like a good option for search engines, a possible-but-onerous one for browsers (ask Google if a page is safe?) and a huge expensive kludge for ISPs.
--dave
In fact, she proposes that supply management, supported by her own party, is badly broken and needs to be fixed. One of the side-effects was to cause massive consolidation in the industry, displacing individual farmers. A second was to make Canada look like it wasn't playing fair in international trade, her area of expertise. A third was to drive up the cost of milk.
The PR benefits, alas, go the the government of the day. The real benefits go to the dairy farmers, who also get a reduction in the cost of (re-)entry into the market. Ditto to the consumers, who get cheaper milk.
It's not bad when your proposal addresses harm to the farmers, harm to the consumers and unfairness to our trading partners. That's it benefits a political (as opposed to real) opponent is just a cost of doing business.
--dave
To get into the trade "club", we have to give things up that we consider inalienable. Rock, meet hard place.
As the government of the day is more concerned with trade and less with issues of care/harm, they chose the rock.
A wise government would chose neither, but instead move the subject sideways to a place where both trade and rights are honoured. For example, they could honour DRM only if the company held a Canadian copyright, and agreed to make excerpts available, for a nominal fee, whenever the use was legal in Canada.
For an example of a seriously wise move, have look at Politicians need courage to dismantle supply management by Martha Hall Findlay
--dave
ps: Martha is my former MP
A follow-on thought: there is really no reason why ISPs can't mimic the libraries and pick software that makes it easy to obey the law, and hard for people without search warrants to get information they shouldn't have.
As I said, this can be done with DHCP servers, and most of the statistical information an ISP needs can have the identifying material stripped out. It's only the information you need for debugging that you need to keep after a session is over. That's a lot like keeping "user X hasn't paid for lost book Y yet": at some point it goes away!
For example, I might keep a cache of MAC address to IP address in between sessions, to save a DHCP re-assignment and give a customer a pseudo-static IP if they requested it. Every other IP given to a cable-modem would be dynamic, and not useful for snooping. The users of static and semi-static addresses would have to make a deliberate choice to give away privacy in order to have stability. Those customers would presumably be small businesses, and not individuals with privacy concerns.
For debugging, I might keep a further cache of recently-used MAC/IP bindings, but I'd be mildly reluctant to disclose that to any random request.
-dave
ISPs are relatively new, and haven't had the problem for most of a century (:-))
When I was at York University, we were next door to the Science Library, and when we had a problem about people objecting to things on the 'net, we went next door and asked our colleagues. They pointed us to a big poster from the Canadian Library Association, that said (in much nicer terms) "You legitimately feel bad, but you can't just tell people to shut up".
Librarians are your friends!
--dave
Someone always want to be able to ask if a particular person has read "Steal This Book", or "How to Build an Atom Bomb". Librarians get that kind of demand all the time, and have successfully fought it at the personal and also at the technical level.
I once worked on library software, and it was a prerequisite in the business that, as soon as a book was returned or the non-return fine was paid, the record that "user X borrowed book Y" was deleted, and a counter of completed transaction was incremented. The latter was necessary for funding and statistical purposes.
This was a norm because the library community actively went out and found a number of states, Germany among them, that protected library patrons from snooping without a warrant. They then made that know to their software suppliers. As the software had to be legal in all the countries where it was to be sold, it was written to meet the highest legal standards, which included the highest privacy standards.
If a legitimate investigation needed to track a library patron's reading, and the investigator could convince a judge, then the library could put a watch on a patron in exchange for a warrant. The watch could not start in the past, of course, but a daily sql query could find out the books a patron currently had out.
There is at least one DHCP program around, written by an ex-librarian, that behaves just this way...
--dave
Thanks! --dave
Yup, same in Canada. I used them because they were such a bizarre case (:-))
--dave
One of the best approaches was to create a TLD for each of the major categories one can get a trademark in. For example, airlines, shipping lines, etc. Then one could have Olympic.Airlines, Olympic.Shipping and so on, without the current problems of the Olympic Organizing Committee getting all the "Olympic"s in the world.
One of my papers on the subject was D. Collier-Brown, On Experimental Top Level Domains, Rev 0, Internet Draft, draft-collier-brown-itld-exper-00.txt, Sept 1996, which may still be findable. Much of the other work seems to have been expunged...
Numerous approaches were debated by the international ad-hoc committee on domain names, but the most profitable to the registrars "won", leading to the current mess. In retrospect, we needed a stringently fair, non-commercial process to make the decision.
--dave
The canonical ones (ftp, smtp, etc) are
1yz Positive Preliminary reply
2yz Positive Completion reply
3yz Positive Intermediate reply
4yz Transient Negative Completion reply
5yz Permanent Negative Completion reply
HTTP bent it, but a 400 might still imply one should change countries (;-))
--dave
In ARPA-speak,that would be
4 -- temporary error
9 -- OS problem, not application
9 -- a unique number
followed by a blank and a human-readable message in ascii,
This is from memory, you understand, but it expresses the basic idea: your country doesn't let you connect, so it's a tempoirary failure until such time as you fix the political problem or move.
--dave
I suspect I know the name of *one* of the main influencers...
--dave
The way the "common criteria" are defined, you need to be an accountant or a logician to figure out just what feature set they claim a high security on. I usually wasl "would it meet B2?" If they can't answer, it won't (;-))
--dave (and yes, on good days I am a logician) c-b
B2, from the Orange Book, is an old military standard, approximately what SELinux meets. C means crappy, and there were a very few people who got an A
The busy little beavers who track bills now include committee hearings. For example, here's some of the debate on the Copyright Act, C-11
--dave
Whether or not you virtualize a given workload, you need to manage its resource usage. In the trivial case, you can see your CPU used up by some other program unless you provide your program a guarantee of enough CPU for the actual number of users who will be employing it.
Ditto memory, disk and networ I/O, bus bandwidth, etc, etc.
A more surprising case is putting two workloads together that formerly worked properly on an older, slower machine. If you increase the amount of a critical resource, both programs under load will start using more of every resource. For example, a batch job that got 30% more CPU increased the amount of disk I/O it did by several times. An interactive program on the same machine was rendered almost completely unusable because it couldn't do the I/O it needed. The customer in that case thought the vendor was lying about the speed of the machine, and demanded his old one back.
Linux is a hotbed of resource management experimentation, so you can statically size and configure a program (workload) to be able to withstand a given load. Commercial Unixes have good enough controls to do most common cases. I can't speak about Windows and BSD, as I've not researched them (yet). Mainframes, not surprisingly, have the best controls for what in their days were exceedingly precious resources.
If your OS doesn't have good resource controls, or if you don't know how to use them well, you'll end up splitting up the virtual machines onto a undesirably large number of physical machines, just in order to do the management the hard way.
The difficulty, by the way, varies as something like the square of the number of machines and the resources used, so virtualization and consolidation is easy for well-behaved, small and unimportant programs, and can be evil for anything that turns out to be big, resource-intensive or important. Think of that as a lemma used to derive Murphy's law (:-)).
--dave