A printer connects to one of the peripheral buses (simple I/O or USB, which ultimately is talked to through simple I/O ports). It needs kernel mode in order to do that. In the minimal case, you have a very simple kernel mode program which blindly passes unchecked data to the physical port (which is shut off from user mode programs) from some virtual port (to which user mode applications are allowed to talk, and which may look like a writable file). In the maximal case, you have an entire PostScript interpreter running in kernel mode.
That raises another favorite question of mine. Why do I need to tell the computer which printer is there and what driver to use at all?
There are at most 5 significantly different printer page description languages that cover 95% of printers on the market. The variations that the printers support are pretty trivial - number of paper trays, ink colours etc and can easily be described using a declarative script.
In the bad old days it was necessary to edit a file to enter the disk drive geometry into the O/S. Today any sane O/S simply asks the disk drive how it is configured. We should have the same for printers.
This has nasty implications for hobbyists who design custom assistive input devices for people with disabilities, as many cannot afford the $500 annual fee (plus whatever the state charge to establish and maintain a corporation) to get a VeriSign code signing certificate. Should such hobbyists band together and form a charity to administer code signing?
I don't think you get the proposal here. The idea seems to be that the only party that adds code to the kernel is Microsoft. Otherwise Symantec and McAfee would simply have bought the relevant cert.
I strongly suspect that most of the assistive devices simply emulate the existing keyboard serial interface and do not require any special device driver whatsoever. Its like the constant refrain heard in the IETF that we have to continue to support protocol X because it is still used in remote parts of Africa. People who have actually visited said parts of Africa then report back that the protocol is utterly irrelevant there because it was never deployed.
Unless the device is using some particularly exotic I/O system it should not be necessary for it to require a kernel mode driver.
Clearly Microsoft does not intend to write every device driver for every device imaginable. Ergo there will be device drivers but just not kernel mode.
The problem with microkernels is that you're putting the "fence" where it looks pretty -- not where it's practical. The appropriate place for the fence is where the minimum amount of data has to cross it, and that's not necessarily where it contains the minimum amount of code.
That is exactly the point I have heard made by the O/S designers. The other problem is that wherever you put the fence today it is likely to be in the wrong position tommorow. Windows NT and Linux were both developed in an era when a 50MHz workstation was considered fast.
Device drivers must, at some level, have a kernel component; because nothing in userland is allowed to talk to I/O ports. Only the kernel can do that. At the very least there must be a kernel component which accepts an instruction to read or write an I/O address and returns a result, via some method which is available to userland software. Of course, if you have a totally generic kernel driver which allows any userland program arbitrary access to any I/O ports without checking, then you have just knocked down the fence altogether. So a kernel driver needs to have at least some sanity-checking built into it.
It would be relatively easy to avoid this problem. You have a generic driver in the kernel that will accept authenticated requests from any source. The authentication mechanism does not need to be very sophisticated, a simple 128 bit cookie would be enough. The O/S already provides protections that prevents one process observing the memory of another (without appropriate permissions). The cookies are handed out through the security monitor.
oh yes. no kernel based drivers. now... how do you plan on getting that nice software like openVPN work? or how about those file-system readers such as e2fsd? locking the kernel is a very good thing but only to a certain extent.
Microsoft provides hooks for that very purpose.
There is no longer a performance constraint that requires code to be in the kernel. Modern processors are I/O bound on the vast majority of tasks for which kernel access is traditionally required.
if you want a kernel which only does the minimum and lets userspace do the rest (thus actually making a black box kernel usable) you need a micro-kernel and last time I checked, no MS OS used a micro-kernel design
Micro-kernels are like RISC processing, no modern processor is a RISC design but the principle of RISC inform the design of all modern processors. No second generation processor was ever a pure RISC design. Even the ARM and the Alpha are no longer pure RISC.
Windows NT has always had elements that are Micro-Kernel like. The original PRISM architecture at DEC was much more of a Microkernel. The Windows Kernel will always be much larger than the Micro-Kernel ideal but eliminating third party code is a good step in the right direction.
As I understand it, Windows Vista 64bit Edition will simply not allow kernel drivers to load unless they are signed with Microsoft's private key. Which means that you'll need to either exploit kernel bugs to load your own code (which they'll plug eventually) or boot off a CD and patch the kernel files on disk to disable this checking (which will be hard to do without destablizing the whole system). If that's what we're talking about (and I have no idea if it is) how can you possibly be in favour of it? I mean, it sounds like The Right To Read all over again.
Thats exactly what I want. I do not want to have any software patch the kernel.
If there is no way for the spyware to patch the kernel I don't need McAfee or Symantec there at all. First thing I do with a new home machine is to strip off the AV software provided by Dell as cramware. Machines run so much faster and more reliably without. Then I turn off AutoRun and hook it up to my internal network which has twin SPI firewalls.
I have never had a virus but I have had machines go wonky because of buggy AV code.
I want to have as few kernel mode device drivers as is possible. Printers should not require kernel mode, nor should video cameras etc. Only the bare essentials talking directly to the DMA interfaces should ever use kernel mode.
I don't need to run my code in kernel space and I don't think anyone else does either.
Given the mostly-free-software nature of the e-mail server world, I consider that a feature. But of course I'd prefer the IETF to adopt an institution wide free-software-compatible IPR policy.
The point is that there should be one definition of what royalty-free means and this should apply across the whole IETF. Piecemeal negotiations per working group make it harder to negotiate concessions.
Asking one party to unilaterally disarm does not provide a great incentive.
Nobody really cared why this requirement postulated by some wasn't met (i.e. whether it was due to Microsoft's marketing strategy or whatever), just that it wasn't met.
The fact is that Apache already had code under the license objected to. This problem first occurred in the WS-* context. The fact that nobody on the Open Source side cared to bother to understand the Microsoft position was very apparent.
Standards processes are a negotiation, the big problem that MARID faced was that the proportion of people in the group with experience of the process was much smaller than is usual.
B: people objected to their "v=spf1" records being deliberately misinterpreted, causing technical problems for them.
Please, I am still waiting for someone to demonstrate a single instance where this is a legitimate cause of concern for the sender. The two checks both have known failure modes but there is absolutely nothing that the sender can do to influence whether PRA succeeds or fails.
The trouble is that it's a "promise". A "promise" on a web page is not the same thing as a legally binding commitment.
That is not a concern. In this case the promise is legally binding. The point to consider here is not whether the promise is enforceable but whether the patent rights are.
If you build something that infringes the patent relying on the existence of the promise you have a clear case of detrimental reliance.
If you were concerned then you can always get a contract license under the promise. The promise is after all the offer of a contract. If you accept there is a contract.
But it's a huge difference for the receiver, whether or not you feel it's sane.
1) SPF regulates the envelope sender. Sender-ID regulates the TO: field.
Actually thats not the case. SPF/SenderID both use the same syntax to describe the configfuration of the outbound email edge servers.
Once you provide that data I may apply it in any way I damn well choose. In practice I am going to apply the fact that the legitimate email infrastructure causes the email messages to be transformed in known ways and that these in turn will have certain consequences for compatibility with the envelope From and From/Sender field.
The idea that the sender gets to choose how the information they supply is used by the receiver is complete nonsense.
The legitimate sender has zero control over the infrastructure the message passes through after it is sent. Only the ultimate recipient controls that part of the path.
Both the ASF and the Debian project classified the Microsoft's license for their patent as inherently incompatible with free software.
What you do not seem to be aware is that the ASF lawyer who raised the issue had previously conceeded the exact same patent terms in the World Wide Web Consortium.
What he was really up to was attempting to use the IETF and the MARID WG in particular as an opportunity to reopen a position he had already conceeded. Furthermore I think you fail to appreciate the extent to which he is personally invested in the whole issue and in particular to his own approach.
The problem with the ASF approach that they never accepted is that they were bearing absolutely none of the risk if the theory of enforceable sub-licensing turned out to fail.
The problem with doing this in the IETF is that the IETF does not have an institution wide patent policy. Every WG creates its own policy. That in turn means that if Microsoft was to conceed the principle in this specific case they could not expect other companies to conceed the principle in future cases. The prcedent would have been set that Microsoft waives those rights but this precedent would not apply to any other party.
A large part of the fault lies in the IETF IPR policy which is uninteligible. It should not be open for individual working groups to negotiate these issues. The individual WG can only ask Microsoft to make a concession, it cannot offer a precedent that Microsoft can rely on in future.
If you fail to understand what people really want from a political negotiation you will fail to persuade them. The ASF position was that there was no alternative but for Microsoft to change. The idea that ASF might change was refused out of hand. The problem might have been solved by the rule book proposal I raised but this was dismissed out of hand.
The idea that a license was unnecessary and that what was really needed was a cure clause did not occur to me until much later. As you know I am not a lawyer, this is not my specialty. I have no idea if the Microsoft lawyers acted on my proposal or came to the idea independently.
You correctly point out that a communication standard is little more than a silent agreement between senders and receivers that only works if the receiving party tries their best not to misinterpret what the sending party meant. But then you simply quit the subject, assuming that communication standards will work even with everyone interpreting stuff their way, because, after all, there is no protocol police, thank you. Sorry, but "compatible" means something else to me.
You keep returning to this hobbyhorse and you are still wrong.
In your model the sender of a message gets to decide how the information they provide will be used. Its absolutely the wrong model.
The obsession with blocking the PRA check only began when a few zealots started to worry about the fact that people might dare to check their email with Microsoft's patented PRA check.
Your emails to me go through multiple spam filters using patented techniques. The PRA has always been offered on royalty free terms. Why is that particular filter the one you make such a song and dance over rather than the royalty bearing ones?
However, Take-Two is just pointing out to the judge where Jack had been in contempt and the judge missed it.
IANAL, but: Thats not how the system works, it is not the responsibility of the courts to police court orders. No action can be taken unless someone complains to the court. So the court is not only allowed, it is part of the normal and required procedure.
There are two kinds of contempt that might be involved here, the first is disobeying a court order, the second is the litteral meaning of 'disrespect'. It looks as if the behavior complained of is disobeying a court order, a contempt hearing for disrespect is very rare, for disrespect outside the court even rarer. But it can happen and some of the statements made are certainly grounds.
In particular threatening the court with a lawsuit for finding against you is a very serious issue, particularly if you are a lawyer and thus an officer of the court. I don't like hearing about threats to bring civil rights cases against courts for finding against a plaintif.
A court does not have the power to disbar a lawyer but they can censure, fine or imprison them and any finding of that kind can be reported to the state bar for further action.
Actually Sender-ID and SPF are the exact same thing. Both allow the sender to describe their email sending configuration in identical terms. The only difference is what receivers decide to do with the information. That part is outside the scope of any sane spec since the whole point of spam control is that the recipients not the senders get to decide.
There is a big difference between Sender-ID and Domain Keys, Sender-ID uses the IP address of the outgoing email server. DKIM uses public key cryptography. We knew at the start that it would take about four years to agree a cryptographic standard hence the decision to adopt a two track approach.
This is not a VHS vs Betamax competition. There are genuine differences in the specs. If you are going to deploy one you have to do much of the work required for the other.
One of the core problems in MARID was that most of the people involved had little experience of the standards process and no inclination to accept reasonable compromises. Another problem is that the IETF rushed the formation of the group in order to prevent a rival standards body moving in on their turf. This pre-empted the negotiations I was moderating in an attempt to agree on a common proposal before the working group was chartered. As soon as the WG was chartered with an open charter the way was open for third party groups to introduce additional proposals even though they had no support from any constituency.
The original patent license terms were not unusual or unreasonable. It was just that a number of persons decided to make an objection in this case to a practice that nobody had objected to for over a decade. As a result of the SCO case the patent lawyers at several large companies (not just Microsoft) had determined that the reciprocation clause in the traditional open patent license was probably not enforceable if there was an open sublicense clause.
Some people decided to make SPF the place to fight this particular battle and started making unjustified accusations of bad faith on Microsoft's part. Then a splinter group decided to exploit the situation and propose a completely unrelated specification that had no commercial support whatsoever.
The point that was lost on many participants was that the only reason to go to a standards body is to get buy in for a proposal. If you want the best technical proposal you should not involve more than five people in the design.
Sender-ID is not incompatible with SPF as alleged. The only difference is at the recipient side and the recipient cannot be forced to interpret SPF or Sender-ID in any particular way. We had agreement in the WG to proceed on a common spec and nobody found any problems until the patent issue was raised.
The article should read 'upgrading all your computers to brand new ones, trashing all your old hardware and putting Vista and (for some reason) MS office on them will cost $3000'.
And it appears, new monitors. Hardware capable of running Aqua well is clearly going to be available in the $800 range at launch including the copy of Vista.
Like many Slashdot threads this turns out to be a rerun of 'the only editor to use is vi'.
We could use the same method of argument to say that moving to Linux costs $4,500 per seat because using Linux causes programers to enjoy their work so much that they sit glued to the screen for days on end, get no exercise causing their limbs to atrophy and making the purchase of a Segway essential for personal movability.
As for Windows server being obsolete, I am not aware of any large enterprises outside those that make a business out of selling Unix that use Unix servers for the purposes that Active Directory is used.
The term zero-day attack has become meaningless. In the days before there were mechanisms in place for rapidly distributing updates the majority of attacks used by hackers were age-old.
Today the hackers have to work a bit harder so zero-day attacks are no longer rare. The vast majority of attacks are still from hackers who are reverse engineering the patches and distributing attacks before the patches are implemented.
If someone reports a new attack against open source code it is by definition unknown before it is reported. Therefore all bug reports with security implications are 'zero-day'.
What the idiots who released this exploit mean by 'zero day' was that they didn't allow time for the problem to be fixed before releasing the exploit.
In law enforcement, they came to the conclusion long ago that the answer is no . Besides all the other qualifications for a police officer, they can't have a criminal record.
And the same is true in computer security firms. We do not need hackers to know how hackers think. Its easy enough working out what they are up to looking at what they do.
Most blackhat hackers are full of bullshit about their expertise and their motivations. Kevin Mitnick was never a hot programmer, his exploits were mostly social engineering. As for motivations there is a huge difference between the MIT hacker ethic and the perps who perform Internet crime. The typical perp has a vindictive streak a mile wide.
In fact, they are required to pass a 300-question polygraph to make sure that they haven't committed any crimes in which they haven't gotten caught.
The FBI beleives in polygraphs but most law enforcement knows that they are utter garbage. There are no independent scientfic studies that show the effectiveness of polygraphs to be better than an experienced human interviewer, most are worse. These days the ploygraph testers guild/union won't let their members participate in any scientific studies.
The article is idiotic. The CDA is a US law, it has absolutely no force in Ireland which has the right to treat the CDA as so much bogroll if it choses.
The CDA does not provide an exemption for an ISP after they have been put on notice that there is copyright infringing material. The UK equivalent does not provide an exemption for libel after notice. I would expect the Irish authorities to have taken a similar approach.
I am aware of this fraud. The response from the authorities is unacceptable.
We should just block all calls to the countries concerned until their govts stop taking kickbacks from the scammers and get their act together. Ireland did this. Good for them.
I have received several calls from someone calling themselves 'Paul from the Prize claim center'. I put the number on my blog and I now get something like 50 people a day finding the site by searching for the telephone number.
There is also a Markus from some mortgage company doing the same thing.
In each case the outbound calls are from a robo-dialer that only starts if it gets a voice mail. When I called up the telephone number they gave I got a real person which was something of a suprise. They hung up when I pointed out that their operation was facing huge civil and criminal penalties.
What I should have done but haven't got round to yet was to dial up the number several times to work out how many people are working for them.
There is one name system for the Internet: the DNS.
Establishing critical mass for a directory scheme requires a huge amount of work. Establishing critical mass for a proprietary scheme which is intended to displace a large, deployed and reasonably open scheme is doomed from the start.
The XDI scheme is controlled through a series of patents which have been vested in a 'non-profit' entity controlled by the original owners which in turn re-licensed them back to the original owners. This series of moves is alleged to make it an 'open standard'.
I think that we will end up using a range of URI identifiers with OpenID in different contexts. In the end though the email identifier is the simplest one for people to use and is the least cluttered. People understand username@example.com.
I don't think that the spam issue is a problem. I can use an identifier without accepting email from everyone who uses it. People want to provide a contact address, they just don't want it to be abused. Anyone could post annoynmous, contactless posts to USENET, people used Wizvax and Julf's annoynmous services because they could receive replies.
So one way for identity providers to compete would be by offering better, more effective means of filtering of contacts. Some identity providers would not accept any email at all, others would relay everything unfiltered. Most people would use (pay even) for services that provide filtering of contact requests.
So, can somebody tell me why you would have a patent if you are not going to enforce it?
To stop some bastard from reading the spec and patenting it.
This has happened to me a very large number of times. I am told there are roughly 100 US patents on work I have done filed by other people after the work was published.
So now I patent ideas aggresively as the only way to keep them open.
I do not worship at the shrine of RMS. I do not beleive that software patents are always a bad thing. The RSA and Diffie-Hellman patents were clearly for publishing innovative work.
I think that 95% of the issues open source has with software patents would be solved if the USPTO stopped handing them out like smarties to anyone who asks. Software is not the only area where the USPTO is causing serious problems. I wrote an essay proposing reforms.
The 'promise' of a license made in the context of a standards process is almost certain to be considered binding. The standard is agreed on the basis of the promise.
The problem that people have been facing is that the traditional IETF reciprocal licensing terms have turned out to be almost certainly unenforceable when they allow for a sublicensing term as people looked at the SCO case. Even if they are enforceable in theory they are not an effective way to pre-empt a case.
A lot of time was spent in rather unproductive discussions on how to fix the license. It was only recently that people started to realize that we didn't need to have a license at all and some form of promise of a license would be sufficient.
I guess we could go back and see if Microsoft would agree to offer their SenderID IPR on the same terms now that we have worked out the fix.
Slashdot Mirror
That raises another favorite question of mine. Why do I need to tell the computer which printer is there and what driver to use at all?
There are at most 5 significantly different printer page description languages that cover 95% of printers on the market. The variations that the printers support are pretty trivial - number of paper trays, ink colours etc and can easily be described using a declarative script.
In the bad old days it was necessary to edit a file to enter the disk drive geometry into the O/S. Today any sane O/S simply asks the disk drive how it is configured. We should have the same for printers.
I don't think you get the proposal here. The idea seems to be that the only party that adds code to the kernel is Microsoft. Otherwise Symantec and McAfee would simply have bought the relevant cert.
I strongly suspect that most of the assistive devices simply emulate the existing keyboard serial interface and do not require any special device driver whatsoever. Its like the constant refrain heard in the IETF that we have to continue to support protocol X because it is still used in remote parts of Africa. People who have actually visited said parts of Africa then report back that the protocol is utterly irrelevant there because it was never deployed.
Unless the device is using some particularly exotic I/O system it should not be necessary for it to require a kernel mode driver.
Clearly Microsoft does not intend to write every device driver for every device imaginable. Ergo there will be device drivers but just not kernel mode.
That is exactly the point I have heard made by the O/S designers. The other problem is that wherever you put the fence today it is likely to be in the wrong position tommorow. Windows NT and Linux were both developed in an era when a 50MHz workstation was considered fast.
Device drivers must, at some level, have a kernel component; because nothing in userland is allowed to talk to I/O ports. Only the kernel can do that. At the very least there must be a kernel component which accepts an instruction to read or write an I/O address and returns a result, via some method which is available to userland software. Of course, if you have a totally generic kernel driver which allows any userland program arbitrary access to any I/O ports without checking, then you have just knocked down the fence altogether. So a kernel driver needs to have at least some sanity-checking built into it.
It would be relatively easy to avoid this problem. You have a generic driver in the kernel that will accept authenticated requests from any source. The authentication mechanism does not need to be very sophisticated, a simple 128 bit cookie would be enough. The O/S already provides protections that prevents one process observing the memory of another (without appropriate permissions). The cookies are handed out through the security monitor.
Microsoft provides hooks for that very purpose.
There is no longer a performance constraint that requires code to be in the kernel. Modern processors are I/O bound on the vast majority of tasks for which kernel access is traditionally required.
if you want a kernel which only does the minimum and lets userspace do the rest (thus actually making a black box kernel usable) you need a micro-kernel and last time I checked, no MS OS used a micro-kernel design
Micro-kernels are like RISC processing, no modern processor is a RISC design but the principle of RISC inform the design of all modern processors. No second generation processor was ever a pure RISC design. Even the ARM and the Alpha are no longer pure RISC.
Windows NT has always had elements that are Micro-Kernel like. The original PRISM architecture at DEC was much more of a Microkernel. The Windows Kernel will always be much larger than the Micro-Kernel ideal but eliminating third party code is a good step in the right direction.
Thats exactly what I want. I do not want to have any software patch the kernel.
If there is no way for the spyware to patch the kernel I don't need McAfee or Symantec there at all. First thing I do with a new home machine is to strip off the AV software provided by Dell as cramware. Machines run so much faster and more reliably without. Then I turn off AutoRun and hook it up to my internal network which has twin SPI firewalls.
I have never had a virus but I have had machines go wonky because of buggy AV code.
I want to have as few kernel mode device drivers as is possible. Printers should not require kernel mode, nor should video cameras etc. Only the bare essentials talking directly to the DMA interfaces should ever use kernel mode.
I don't need to run my code in kernel space and I don't think anyone else does either.
Sounds like the right approach to me. We will soon find out whether Symantec and McAfee are helping or hindering security.
The point is that there should be one definition of what royalty-free means and this should apply across the whole IETF. Piecemeal negotiations per working group make it harder to negotiate concessions.
Asking one party to unilaterally disarm does not provide a great incentive.
Nobody really cared why this requirement postulated by some wasn't met (i.e. whether it was due to Microsoft's marketing strategy or whatever), just that it wasn't met.
The fact is that Apache already had code under the license objected to. This problem first occurred in the WS-* context. The fact that nobody on the Open Source side cared to bother to understand the Microsoft position was very apparent.
Standards processes are a negotiation, the big problem that MARID faced was that the proportion of people in the group with experience of the process was much smaller than is usual.
B: people objected to their "v=spf1" records being deliberately misinterpreted, causing technical problems for them.
Please, I am still waiting for someone to demonstrate a single instance where this is a legitimate cause of concern for the sender. The two checks both have known failure modes but there is absolutely nothing that the sender can do to influence whether PRA succeeds or fails.
That is not a concern. In this case the promise is legally binding. The point to consider here is not whether the promise is enforceable but whether the patent rights are.
If you build something that infringes the patent relying on the existence of the promise you have a clear case of detrimental reliance.
If you were concerned then you can always get a contract license under the promise. The promise is after all the offer of a contract. If you accept there is a contract.
Actually thats not the case. SPF/SenderID both use the same syntax to describe the configfuration of the outbound email edge servers.
Once you provide that data I may apply it in any way I damn well choose. In practice I am going to apply the fact that the legitimate email infrastructure causes the email messages to be transformed in known ways and that these in turn will have certain consequences for compatibility with the envelope From and From/Sender field.
The idea that the sender gets to choose how the information they supply is used by the receiver is complete nonsense.
The legitimate sender has zero control over the infrastructure the message passes through after it is sent. Only the ultimate recipient controls that part of the path.
What you do not seem to be aware is that the ASF lawyer who raised the issue had previously conceeded the exact same patent terms in the World Wide Web Consortium.
What he was really up to was attempting to use the IETF and the MARID WG in particular as an opportunity to reopen a position he had already conceeded. Furthermore I think you fail to appreciate the extent to which he is personally invested in the whole issue and in particular to his own approach.
The problem with the ASF approach that they never accepted is that they were bearing absolutely none of the risk if the theory of enforceable sub-licensing turned out to fail.
The problem with doing this in the IETF is that the IETF does not have an institution wide patent policy. Every WG creates its own policy. That in turn means that if Microsoft was to conceed the principle in this specific case they could not expect other companies to conceed the principle in future cases. The prcedent would have been set that Microsoft waives those rights but this precedent would not apply to any other party.
A large part of the fault lies in the IETF IPR policy which is uninteligible. It should not be open for individual working groups to negotiate these issues. The individual WG can only ask Microsoft to make a concession, it cannot offer a precedent that Microsoft can rely on in future.
If you fail to understand what people really want from a political negotiation you will fail to persuade them. The ASF position was that there was no alternative but for Microsoft to change. The idea that ASF might change was refused out of hand. The problem might have been solved by the rule book proposal I raised but this was dismissed out of hand.
The idea that a license was unnecessary and that what was really needed was a cure clause did not occur to me until much later. As you know I am not a lawyer, this is not my specialty. I have no idea if the Microsoft lawyers acted on my proposal or came to the idea independently.
You correctly point out that a communication standard is little more than a silent agreement between senders and receivers that only works if the receiving party tries their best not to misinterpret what the sending party meant. But then you simply quit the subject, assuming that communication standards will work even with everyone interpreting stuff their way, because, after all, there is no protocol police, thank you. Sorry, but "compatible" means something else to me.
You keep returning to this hobbyhorse and you are still wrong.
In your model the sender of a message gets to decide how the information they provide will be used. Its absolutely the wrong model.
The obsession with blocking the PRA check only began when a few zealots started to worry about the fact that people might dare to check their email with Microsoft's patented PRA check.
Your emails to me go through multiple spam filters using patented techniques. The PRA has always been offered on royalty free terms. Why is that particular filter the one you make such a song and dance over rather than the royalty bearing ones?
IANAL, but: Thats not how the system works, it is not the responsibility of the courts to police court orders. No action can be taken unless someone complains to the court. So the court is not only allowed, it is part of the normal and required procedure.
There are two kinds of contempt that might be involved here, the first is disobeying a court order, the second is the litteral meaning of 'disrespect'. It looks as if the behavior complained of is disobeying a court order, a contempt hearing for disrespect is very rare, for disrespect outside the court even rarer. But it can happen and some of the statements made are certainly grounds.
In particular threatening the court with a lawsuit for finding against you is a very serious issue, particularly if you are a lawyer and thus an officer of the court. I don't like hearing about threats to bring civil rights cases against courts for finding against a plaintif.
A court does not have the power to disbar a lawyer but they can censure, fine or imprison them and any finding of that kind can be reported to the state bar for further action.
There is a big difference between Sender-ID and Domain Keys, Sender-ID uses the IP address of the outgoing email server. DKIM uses public key cryptography. We knew at the start that it would take about four years to agree a cryptographic standard hence the decision to adopt a two track approach.
This is not a VHS vs Betamax competition. There are genuine differences in the specs. If you are going to deploy one you have to do much of the work required for the other.
One of the core problems in MARID was that most of the people involved had little experience of the standards process and no inclination to accept reasonable compromises. Another problem is that the IETF rushed the formation of the group in order to prevent a rival standards body moving in on their turf. This pre-empted the negotiations I was moderating in an attempt to agree on a common proposal before the working group was chartered. As soon as the WG was chartered with an open charter the way was open for third party groups to introduce additional proposals even though they had no support from any constituency.
The original patent license terms were not unusual or unreasonable. It was just that a number of persons decided to make an objection in this case to a practice that nobody had objected to for over a decade. As a result of the SCO case the patent lawyers at several large companies (not just Microsoft) had determined that the reciprocation clause in the traditional open patent license was probably not enforceable if there was an open sublicense clause.
Some people decided to make SPF the place to fight this particular battle and started making unjustified accusations of bad faith on Microsoft's part. Then a splinter group decided to exploit the situation and propose a completely unrelated specification that had no commercial support whatsoever.
The point that was lost on many participants was that the only reason to go to a standards body is to get buy in for a proposal. If you want the best technical proposal you should not involve more than five people in the design.
Sender-ID is not incompatible with SPF as alleged. The only difference is at the recipient side and the recipient cannot be forced to interpret SPF or Sender-ID in any particular way. We had agreement in the WG to proceed on a common spec and nobody found any problems until the patent issue was raised.
And it appears, new monitors. Hardware capable of running Aqua well is clearly going to be available in the $800 range at launch including the copy of Vista.
Like many Slashdot threads this turns out to be a rerun of 'the only editor to use is vi'.
We could use the same method of argument to say that moving to Linux costs $4,500 per seat because using Linux causes programers to enjoy their work so much that they sit glued to the screen for days on end, get no exercise causing their limbs to atrophy and making the purchase of a Segway essential for personal movability.
As for Windows server being obsolete, I am not aware of any large enterprises outside those that make a business out of selling Unix that use Unix servers for the purposes that Active Directory is used.
Today the hackers have to work a bit harder so zero-day attacks are no longer rare. The vast majority of attacks are still from hackers who are reverse engineering the patches and distributing attacks before the patches are implemented.
If someone reports a new attack against open source code it is by definition unknown before it is reported. Therefore all bug reports with security implications are 'zero-day'.
What the idiots who released this exploit mean by 'zero day' was that they didn't allow time for the problem to be fixed before releasing the exploit.
Only in the same sense that dowsing rods are used to find water and homeopathy is used to cure disease.
The British Intelligence services have never beleived in these pseudo-scientific witch smelling devices.
And the same is true in computer security firms. We do not need hackers to know how hackers think. Its easy enough working out what they are up to looking at what they do.
Most blackhat hackers are full of bullshit about their expertise and their motivations. Kevin Mitnick was never a hot programmer, his exploits were mostly social engineering. As for motivations there is a huge difference between the MIT hacker ethic and the perps who perform Internet crime. The typical perp has a vindictive streak a mile wide.
In fact, they are required to pass a 300-question polygraph to make sure that they haven't committed any crimes in which they haven't gotten caught.
The FBI beleives in polygraphs but most law enforcement knows that they are utter garbage. There are no independent scientfic studies that show the effectiveness of polygraphs to be better than an experienced human interviewer, most are worse. These days the ploygraph testers guild/union won't let their members participate in any scientific studies.
The material is published in Ireland and therefore comes under Irish law.
Actually Le Chiffre didn't cheat, he lost. Bond ended up in the chair because he won. In the end SMERSH shows up and offs LeChiffre because of a debt.
The CDA does not provide an exemption for an ISP after they have been put on notice that there is copyright infringing material. The UK equivalent does not provide an exemption for libel after notice. I would expect the Irish authorities to have taken a similar approach.
We should just block all calls to the countries concerned until their govts stop taking kickbacks from the scammers and get their act together. Ireland did this. Good for them.
I have been involved in patent cases where the cost to the defence has been over $5 million even when they 'won'.
Several of the bogus patents have been used to successfully extort tens of millions in damages and fees that are entirely unjustified.
Today I read a patent filled in 2004 that tries to claim a standard agreed in 1997.
I know that they can be shown to be invalid but it will cost millions to prove that and sometimes the courts get it completely wrong.
So now I apply for patents.
There is also a Markus from some mortgage company doing the same thing.
In each case the outbound calls are from a robo-dialer that only starts if it gets a voice mail. When I called up the telephone number they gave I got a real person which was something of a suprise. They hung up when I pointed out that their operation was facing huge civil and criminal penalties.
What I should have done but haven't got round to yet was to dial up the number several times to work out how many people are working for them.
Establishing critical mass for a directory scheme requires a huge amount of work. Establishing critical mass for a proprietary scheme which is intended to displace a large, deployed and reasonably open scheme is doomed from the start.
The XDI scheme is controlled through a series of patents which have been vested in a 'non-profit' entity controlled by the original owners which in turn re-licensed them back to the original owners. This series of moves is alleged to make it an 'open standard'.
I think that we will end up using a range of URI identifiers with OpenID in different contexts. In the end though the email identifier is the simplest one for people to use and is the least cluttered. People understand username@example.com.
I don't think that the spam issue is a problem. I can use an identifier without accepting email from everyone who uses it. People want to provide a contact address, they just don't want it to be abused. Anyone could post annoynmous, contactless posts to USENET, people used Wizvax and Julf's annoynmous services because they could receive replies.
So one way for identity providers to compete would be by offering better, more effective means of filtering of contacts. Some identity providers would not accept any email at all, others would relay everything unfiltered. Most people would use (pay even) for services that provide filtering of contact requests.
To stop some bastard from reading the spec and patenting it.
This has happened to me a very large number of times. I am told there are roughly 100 US patents on work I have done filed by other people after the work was published.
So now I patent ideas aggresively as the only way to keep them open.
I do not worship at the shrine of RMS. I do not beleive that software patents are always a bad thing. The RSA and Diffie-Hellman patents were clearly for publishing innovative work.
I think that 95% of the issues open source has with software patents would be solved if the USPTO stopped handing them out like smarties to anyone who asks. Software is not the only area where the USPTO is causing serious problems. I wrote an essay proposing reforms.
The 'promise' of a license made in the context of a standards process is almost certain to be considered binding. The standard is agreed on the basis of the promise. The problem that people have been facing is that the traditional IETF reciprocal licensing terms have turned out to be almost certainly unenforceable when they allow for a sublicensing term as people looked at the SCO case. Even if they are enforceable in theory they are not an effective way to pre-empt a case. A lot of time was spent in rather unproductive discussions on how to fix the license. It was only recently that people started to realize that we didn't need to have a license at all and some form of promise of a license would be sufficient. I guess we could go back and see if Microsoft would agree to offer their SenderID IPR on the same terms now that we have worked out the fix.