Excuse me, but what in the hell are you talking about? Are you perchance referring to their SenderID system? If so, you need to head over to spf.pobox.com and read the archives on what happened there.
SenderID was not a solution to spam and forgers, it was a poorly implemented layer on top of SPF to block joe jobs, forgery of MAIL FROM addresses. This is not the header: it's not even in the header people normally see, it's the email address the bounces go to and is useful for tracking forgeries.
Given the trivial ease of purchasing SenderID keys from Microsoft and their lack of association with an actual From: header line, and the ease of breaking into many thousands of zombied Windows machines worldwide and sending spam from them now, it's a trivial matter to simply steal SenderID keys from small corporate Windows servers. The SenderID key only proves that the IP address sending the email is authorized to use that "MAIL FROM" line, not the "From:" line which is entirely different.
Now, if Microsoft wants to get out of the way of real SPF and encourage its corporate clients to use the DNS TXT record authorization of "MAIL FROM" senders that SPF actually uses, then that would be a very helpful step in blocking a lot of the current phishers. Email from "mybank.com" could be checked against what the DNS for "mybank.com" claims, which is considerably tougher to steal, and mail filter software could even compare the "MAIL FROM" information against the "From:" line to get some additional spam or fraud testing information.
First, I'd make the actual email headers more available and legible, to see if email is from where it claims. Second, I'd implement SPF by default on all Microsoft DNS servers, mail servers, and the clients. (Note, I mean SPF, not the SenderID software that Microsoft tried to turn it into and broke badly.) Third, I'd discourage the sending of HTML email by making it no longer a default in all Microsoft mail clients. TXT should be the default, not HTML, it's too easy to hide cruft and phishing based links in the email. Fourth, I'd fix all those stupid mail client that auto-diaplay URL-looking words in email as clickable links, since their common use is part of how many phishers work their schemes. Fifth, I'd simplify the auto-clicking and wackiness and web browser hiding-of-what-you-typed that allows Internet Explorer to hide the first part of the actual URL, leaving only the last part displayed and looking like what the phisher wants it to look like.
Shall I go on?
And remember, Microsoft is not just a software company. They run a quite large set of email services at hotmail.com and msn.com, and they need to protect themselves from incoming spam, and they need to protect themselves from outgoing spam forged to look like it's from those domains, as it so often is, lest people say "block all email from those domains". In fact, I find that blocking all email from hotmail.com and msn.com and aol.com helps cut quite a bit of email that I don't want, from spammers and clueless people who mistype my name.
Nonsense. The "cost of finding a bug" is incredibly variable, and the cost of developing the full benchtest setup of every possibility is often much higher than that of releasing a beta and letting people hammer at it to find some of the interesting corner cases you'd spend millions to workk through in iterative tests in the lab.
Finding it in advance is good, but human review and test benches also add up.
The contract wasn't amended. Fortunately, Bind and most other fully capable DNS servers were tweaked to disallow this nonsense within days of Verisign trying it. Unfortunately, it's the little home and small network setups of DNS that will suffer from the re-routing when Verisign tries it againi.
Remember, that little stunt gave Verisign not only lots of salable traffic data about mistyped URL's, but it allowed them to route other people's mis-addressed email to their own mail servers. The stunt was very nasty and very dangerous.
Full fancy PDF form creation takes Adobe Acrobat, but creating and displaying PDF documents simply takes the "display" command from ImageMagick or other ghostscript based tools, available via CygWin for Windows users. The interface takes time to learn, but no longer than the weird interface of the Adobe Acrobat program itself.
Yes, it's important. Yes, it's proprietary. And their ability to ignore and mutilate their own API's is pretty impressive, given what they do to the Postscript output of Adobe Acrobat based print jobs. Adobe is very good at inventing cool protocols, then feature-filling them right into the dumpster.
They helped create Postscript: now no one sane uses Adobe Postscript except printer manufacturers trapped in licensing deals, everyone else uses ghostscript because it works more reliably and actually follows the specs. They helped create DPS, Display Postscript, which chould have been the video display format of the UNIX world except that MIT licensed X11 in an open way and instead we have X-Windows all over the UNIX and open source world, which is slower and causes printing problems for X displays but is open to free use.
We also have Photoshop, which continues to be a good standard for graphics but whose cost and cross-platform failure to standardize and closed source nature are still driving people over to use GIMP every year. Adobe is a stable company, but they could have even better market share by learning to play nice with the open source people and take over the display world.
Also, in the Linux or Mac world, almost any application can print PDF output using ghostscript. In the Windows world, people expect you to buy Adobe Acrobat and use that to generate new PDF's.
Instead, add PDFcreator from sourceforge.net to your toolkit. PDFcreator can generate high-quality viewable PDF documents, for Windows users, from any application, for free instead of paying the $500 license fees for Adobe Acrobat from Adobe. It breaks the cycle of addiction that Adobe Reader is supposed to create, to sell you on the "light stuff" of viewing PDF, then later hook you on the "hard stuff" of generating PDF.
PDFcreator is also open source, lighter weight, runs on top of ghostscript, and doesn't generate PDF documents that will crash a Windows computer trying to print them.
Their later standard is still patent encumbered. They're also now claiming all the SPF users as SenderID users, which is blatantly false.
Looking at the SPF archives, it's fun to watch Meng try and make Microsoft sound like they were ever reasonable. It's like a battered child, making excuses for their molesting parent and pretend that the violations were their own fault while their friends, teachers, and social workers say "report them and get out of that house!"
Microsoft is pulling the same kind of sleaze with SPF and their patented XML based SenderID, trying to wedge SenderID into an open standard and saying "pay no attention to that patent behind the curtain".
With enough lawyers, yes. They can drag a defendent through the courts and use such fraudulent patents to counter-sue anyone who sues *them* for patent violation.
It's a fun hobby for lawyers of companies that engage in monopolistic behavior to crush opponents.
In the short term, with the amazingly bad implementations used, this is true.
However, as the Palladium initiative progresses under its new name of "Trusted Computing", expect the device itself to incorporate hardware keys, that can be used to authenticate a private key exchange with the server. Neither side needs to know the other's private key: they simply need to be able to exchange keys encrypted with the other site's public key, and verify that the decryption with their own private keyb matches what they expect. This all got hashed out in Kerberos years ago for user authentication. The missing part for DRM is the actual local hardware key to authenticate the local client.
There are still key management issues, but they're much smaller than the political issues of implementing such hardware, especially if Palladium is allowed to slip by unnoticed and evade the political concerns such as those raised here, that it will prevent people from lawful of the very products they've purchased.
Remember, the DVD encryption exposed by the libdvdcss software would have been secure for vastly longer if they'd simply used longer keys, at little or no expense to the DVD performance or the actual DVD players.
They seem to be providing quite a lot of driver and management information to the UNIX community. Maybe they don't want to bother with another open-source project where the founders bitch at them, get their employees email bombed, and where the return on investment is miniscule because the deployed base of OpenBSD machines is so much smaller?
Exactly. Plus, those who have legal and legitimate uses for ripping their own DVD's or duplicating or even viewing them under Linux have no legal way to do so. *NONE*, except for buying a Windows software package and using an emulator with it.
Some music is available this way, true. I was referring more the problems of playing it under Linux, especially DVD's for which there are no legal tools to play or re-burn them. And the vast amount of "public domain" music and video and other documents are not easy to access or release because of the patent issues of formats such as MP3, and the DVD generation and encryption issues of video DVD's.
Not at all. I'm saying that because they lie and cheat and do ludicrous restrictions on legitimate usage, that the rise of and support for illegal usage is a direct and predictable result. By loosening their grip and making it reasonable, they can stop frightening people away from legitimate use and driving it underground.
As their policy currently stands, there is no legal DVD viewing software for Linux. None: all the packages I've been able to find use the libdvdcss package. That library is also built into lots of DVD duplication tools, and it's legal to duplicate a DVD for backup purposes. But they refuse to even ackowledge the existence of the issue and of the need, or of the legality of tools for making "Fair Use" of their copyrighted works for education, review, or analysis. So to do a legal thing, I have to get illegal tools because there is no legal tool.
This is, of course, insane, but it matches what RIAA and MPAA want from a business point of view. They want you to always buy a new copy, from them, and have you be unable to use even "Fair Use" excerpts of their work for anything else.
The resulting revolt from free speech advocates is predictable, as is the fairly trivial software decoding of their ludicrously badly done copy protection.
No, there's an underlying problem in that there is no way to legally access these materials and pay for them. RIAA and the MPAA refuse to acknowledge the existence of the market of legitimate downloaders, since it would eliminate much of their middle management and executive staffs, and have thus made it artificially difficult to legally obtain these materials.
For examples of this, see the lawsuits about the libdvdcss software. There was previously no software available for accessing encrypted DVD's for Linux, and the software authors tried to negotiate a way to license the necessary tools. They were repeatedly blown off and told "the tools already exist for Linux", which they absolutely did not.
So the authors cracked the amazingly poor excuse for copy protection on DVD's, and wound up in court for doing it. This is silly, of course, but is the result of an executive policy ignoring the reality of the marketplace and of the software.
Right. And autoconf has nice structures to test for things like kernel versions, the presence of any specific libraries, GCC versions which can affect code compilation, the presence of x86 or ppc or x86_64 or ia64 hardware, etc., etc., etc.
It even has nice structures for building one version of a kernel module that's not the one you're running at the moment, or building RPM or.deb installation packages. But hey, if you want to write magical mystery Makefiles and #ifdef statements to deduce what the person doing the compilation actually wanted to do, go for it. Have fun re-inventing the wheel for every single program you write.
NVidia's case is even worse. The kernel driver is just a hook for their closed-source OpenGL libraries. The company prevents other software from being able to use the various 3D and animation features of their cards by hiding them inside the OpenGL library, and the open source community has no opportunity to contribute or gain from that software.
Because the OpenGL libraries are closed source and the licensing does not allow even binary distribution without individuals signing the NVidia agreement, they can't be directly integrated into any package management system and updating the OpenGL packages will also break the NVidia usage. It also means that X Windows configuration tools can't be written to fully detect and use the NVidia cards, the X configuration files have to be manipulated by hand or by the NVidia installation tool.
For an example of this approach, go look at the old software for HylaFAX. The "configure" script for that was written by hand by Sam Leffler, one of the original authors of BSD and the creator of TIFF.
Now try writing that thing by hand, yourself, for every single software author. They will break things, they will write incompatible tools, and maintaining them will be nightmarish.
Using autoconf is like using standard size screw holes: it's not the optimum for every job, but it's necessary to allow using standard tools and replacements, or you'll waste all your repair or development time hand-crafting tools.
Bless you for doing this. And if your tools are built on top of someone else's tools, such as hardware driver patches on top of someone else's work in the kernel source trees, pretty please eliminate silly white space differences between your code and the author's code, generate clean diffs, and apply those on top of the original source. Then publish, to ease reading of the actual diffs.
If you require software to accompany the kernel modules such as the way PCMCIA drivers are integrated with the PCMCIA management and detection software, make sure you synchronize the additional software with your kernel modules. Then publish them together. This will help people from trying to stuff your kernel changes in with a software package it doesn't work with, and vice versa.
Sure, if you want to maintain a parallel port printer on every desk, or a teletype printer. Those are tough to find now, though, and they're breaking down fast.
I agree with your point, but I've had too many cases where someone is tooling along fine refusing to update and making me put the servers through hoops to support their antiquated clients, and finally they find some feature that makes them *have* to upgrade.
And such institutions consider the manpower to maintain and repair these things "overhead". It comes out of a different pocket, not the same pocket as "capital" which new equipment would come from. And picking up used equipment is a paperwork nightmare for such workplaces.
And please note: a lot of groups used the Y2K risks as an opportunity to upgrade a lot of systems to something modern, but those systems are now unsupportable. (VMS on Alpha, anyone? NT 4.0 on anything?)
Slashdot Mirror
Excuse me, but what in the hell are you talking about? Are you perchance referring to their SenderID system? If so, you need to head over to spf.pobox.com and read the archives on what happened there. SenderID was not a solution to spam and forgers, it was a poorly implemented layer on top of SPF to block joe jobs, forgery of MAIL FROM addresses. This is not the header: it's not even in the header people normally see, it's the email address the bounces go to and is useful for tracking forgeries. Given the trivial ease of purchasing SenderID keys from Microsoft and their lack of association with an actual From: header line, and the ease of breaking into many thousands of zombied Windows machines worldwide and sending spam from them now, it's a trivial matter to simply steal SenderID keys from small corporate Windows servers. The SenderID key only proves that the IP address sending the email is authorized to use that "MAIL FROM" line, not the "From:" line which is entirely different. Now, if Microsoft wants to get out of the way of real SPF and encourage its corporate clients to use the DNS TXT record authorization of "MAIL FROM" senders that SPF actually uses, then that would be a very helpful step in blocking a lot of the current phishers. Email from "mybank.com" could be checked against what the DNS for "mybank.com" claims, which is considerably tougher to steal, and mail filter software could even compare the "MAIL FROM" information against the "From:" line to get some additional spam or fraud testing information.
First, I'd make the actual email headers more available and legible, to see if email is from where it claims. Second, I'd implement SPF by default on all Microsoft DNS servers, mail servers, and the clients. (Note, I mean SPF, not the SenderID software that Microsoft tried to turn it into and broke badly.) Third, I'd discourage the sending of HTML email by making it no longer a default in all Microsoft mail clients. TXT should be the default, not HTML, it's too easy to hide cruft and phishing based links in the email. Fourth, I'd fix all those stupid mail client that auto-diaplay URL-looking words in email as clickable links, since their common use is part of how many phishers work their schemes. Fifth, I'd simplify the auto-clicking and wackiness and web browser hiding-of-what-you-typed that allows Internet Explorer to hide the first part of the actual URL, leaving only the last part displayed and looking like what the phisher wants it to look like.
Shall I go on?
And remember, Microsoft is not just a software company. They run a quite large set of email services at hotmail.com and msn.com, and they need to protect themselves from incoming spam, and they need to protect themselves from outgoing spam forged to look like it's from those domains, as it so often is, lest people say "block all email from those domains". In fact, I find that blocking all email from hotmail.com and msn.com and aol.com helps cut quite a bit of email that I don't want, from spammers and clueless people who mistype my name.
You don't drink good booze much, do you?
Nonsense. The "cost of finding a bug" is incredibly variable, and the cost of developing the full benchtest setup of every possibility is often much higher than that of releasing a beta and letting people hammer at it to find some of the interesting corner cases you'd spend millions to workk through in iterative tests in the lab. Finding it in advance is good, but human review and test benches also add up.
The contract wasn't amended. Fortunately, Bind and most other fully capable DNS servers were tweaked to disallow this nonsense within days of Verisign trying it. Unfortunately, it's the little home and small network setups of DNS that will suffer from the re-routing when Verisign tries it againi.
Remember, that little stunt gave Verisign not only lots of salable traffic data about mistyped URL's, but it allowed them to route other people's mis-addressed email to their own mail servers. The stunt was very nasty and very dangerous.
Full fancy PDF form creation takes Adobe Acrobat, but creating and displaying PDF documents simply takes the "display" command from ImageMagick or other ghostscript based tools, available via CygWin for Windows users. The interface takes time to learn, but no longer than the weird interface of the Adobe Acrobat program itself.
Yes, it's important. Yes, it's proprietary. And their ability to ignore and mutilate their own API's is pretty impressive, given what they do to the Postscript output of Adobe Acrobat based print jobs. Adobe is very good at inventing cool protocols, then feature-filling them right into the dumpster. They helped create Postscript: now no one sane uses Adobe Postscript except printer manufacturers trapped in licensing deals, everyone else uses ghostscript because it works more reliably and actually follows the specs. They helped create DPS, Display Postscript, which chould have been the video display format of the UNIX world except that MIT licensed X11 in an open way and instead we have X-Windows all over the UNIX and open source world, which is slower and causes printing problems for X displays but is open to free use. We also have Photoshop, which continues to be a good standard for graphics but whose cost and cross-platform failure to standardize and closed source nature are still driving people over to use GIMP every year. Adobe is a stable company, but they could have even better market share by learning to play nice with the open source people and take over the display world.
Also, in the Linux or Mac world, almost any application can print PDF output using ghostscript. In the Windows world, people expect you to buy Adobe Acrobat and use that to generate new PDF's.
Instead, add PDFcreator from sourceforge.net to your toolkit. PDFcreator can generate high-quality viewable PDF documents, for Windows users, from any application, for free instead of paying the $500 license fees for Adobe Acrobat from Adobe. It breaks the cycle of addiction that Adobe Reader is supposed to create, to sell you on the "light stuff" of viewing PDF, then later hook you on the "hard stuff" of generating PDF.
PDFcreator is also open source, lighter weight, runs on top of ghostscript, and doesn't generate PDF documents that will crash a Windows computer trying to print them.
Their later standard is still patent encumbered. They're also now claiming all the SPF users as SenderID users, which is blatantly false. Looking at the SPF archives, it's fun to watch Meng try and make Microsoft sound like they were ever reasonable. It's like a battered child, making excuses for their molesting parent and pretend that the violations were their own fault while their friends, teachers, and social workers say "report them and get out of that house!"
Microsoft is pulling the same kind of sleaze with SPF and their patented XML based SenderID, trying to wedge SenderID into an open standard and saying "pay no attention to that patent behind the curtain".
With enough lawyers, yes. They can drag a defendent through the courts and use such fraudulent patents to counter-sue anyone who sues *them* for patent violation.
It's a fun hobby for lawyers of companies that engage in monopolistic behavior to crush opponents.
In the short term, with the amazingly bad implementations used, this is true.
However, as the Palladium initiative progresses under its new name of "Trusted Computing", expect the device itself to incorporate hardware keys, that can be used to authenticate a private key exchange with the server. Neither side needs to know the other's private key: they simply need to be able to exchange keys encrypted with the other site's public key, and verify that the decryption with their own private keyb matches what they expect. This all got hashed out in Kerberos years ago for user authentication. The missing part for DRM is the actual local hardware key to authenticate the local client.
There are still key management issues, but they're much smaller than the political issues of implementing such hardware, especially if Palladium is allowed to slip by unnoticed and evade the political concerns such as those raised here, that it will prevent people from lawful of the very products they've purchased.
Remember, the DVD encryption exposed by the libdvdcss software would have been secure for vastly longer if they'd simply used longer keys, at little or no expense to the DVD performance or the actual DVD players.
They seem to be providing quite a lot of driver and management information to the UNIX community. Maybe they don't want to bother with another open-source project where the founders bitch at them, get their employees email bombed, and where the return on investment is miniscule because the deployed base of OpenBSD machines is so much smaller?
Exactly. Plus, those who have legal and legitimate uses for ripping their own DVD's or duplicating or even viewing them under Linux have no legal way to do so. *NONE*, except for buying a Windows software package and using an emulator with it.
Some music is available this way, true. I was referring more the problems of playing it under Linux, especially DVD's for which there are no legal tools to play or re-burn them. And the vast amount of "public domain" music and video and other documents are not easy to access or release because of the patent issues of formats such as MP3, and the DVD generation and encryption issues of video DVD's.
Not at all. I'm saying that because they lie and cheat and do ludicrous restrictions on legitimate usage, that the rise of and support for illegal usage is a direct and predictable result. By loosening their grip and making it reasonable, they can stop frightening people away from legitimate use and driving it underground.
As their policy currently stands, there is no legal DVD viewing software for Linux. None: all the packages I've been able to find use the libdvdcss package. That library is also built into lots of DVD duplication tools, and it's legal to duplicate a DVD for backup purposes. But they refuse to even ackowledge the existence of the issue and of the need, or of the legality of tools for making "Fair Use" of their copyrighted works for education, review, or analysis. So to do a legal thing, I have to get illegal tools because there is no legal tool.
This is, of course, insane, but it matches what RIAA and MPAA want from a business point of view. They want you to always buy a new copy, from them, and have you be unable to use even "Fair Use" excerpts of their work for anything else.
The resulting revolt from free speech advocates is predictable, as is the fairly trivial software decoding of their ludicrously badly done copy protection.
No, there's an underlying problem in that there is no way to legally access these materials and pay for them. RIAA and the MPAA refuse to acknowledge the existence of the market of legitimate downloaders, since it would eliminate much of their middle management and executive staffs, and have thus made it artificially difficult to legally obtain these materials.
For examples of this, see the lawsuits about the libdvdcss software. There was previously no software available for accessing encrypted DVD's for Linux, and the software authors tried to negotiate a way to license the necessary tools. They were repeatedly blown off and told "the tools already exist for Linux", which they absolutely did not.
So the authors cracked the amazingly poor excuse for copy protection on DVD's, and wound up in court for doing it. This is silly, of course, but is the result of an executive policy ignoring the reality of the marketplace and of the software.
Right. And autoconf has nice structures to test for things like kernel versions, the presence of any specific libraries, GCC versions which can affect code compilation, the presence of x86 or ppc or x86_64 or ia64 hardware, etc., etc., etc.
.deb installation packages. But hey, if you want to write magical mystery Makefiles and #ifdef statements to deduce what the person doing the compilation actually wanted to do, go for it. Have fun re-inventing the wheel for every single program you write.
It even has nice structures for building one version of a kernel module that's not the one you're running at the moment, or building RPM or
NVidia's case is even worse. The kernel driver is just a hook for their closed-source OpenGL libraries. The company prevents other software from being able to use the various 3D and animation features of their cards by hiding them inside the OpenGL library, and the open source community has no opportunity to contribute or gain from that software. Because the OpenGL libraries are closed source and the licensing does not allow even binary distribution without individuals signing the NVidia agreement, they can't be directly integrated into any package management system and updating the OpenGL packages will also break the NVidia usage. It also means that X Windows configuration tools can't be written to fully detect and use the NVidia cards, the X configuration files have to be manipulated by hand or by the NVidia installation tool.
For an example of this approach, go look at the old software for HylaFAX. The "configure" script for that was written by hand by Sam Leffler, one of the original authors of BSD and the creator of TIFF. Now try writing that thing by hand, yourself, for every single software author. They will break things, they will write incompatible tools, and maintaining them will be nightmarish. Using autoconf is like using standard size screw holes: it's not the optimum for every job, but it's necessary to allow using standard tools and replacements, or you'll waste all your repair or development time hand-crafting tools.
Bless you for doing this. And if your tools are built on top of someone else's tools, such as hardware driver patches on top of someone else's work in the kernel source trees, pretty please eliminate silly white space differences between your code and the author's code, generate clean diffs, and apply those on top of the original source. Then publish, to ease reading of the actual diffs.
If you require software to accompany the kernel modules such as the way PCMCIA drivers are integrated with the PCMCIA management and detection software, make sure you synchronize the additional software with your kernel modules. Then publish them together. This will help people from trying to stuff your kernel changes in with a software package it doesn't work with, and vice versa.
Sure, if you want to maintain a parallel port printer on every desk, or a teletype printer. Those are tough to find now, though, and they're breaking down fast.
I agree with your point, but I've had too many cases where someone is tooling along fine refusing to update and making me put the servers through hoops to support their antiquated clients, and finally they find some feature that makes them *have* to upgrade.
Until the day you need to print with it, or send an email based on the information. Then you need to do a forklift upgrade of the whole system.
And such institutions consider the manpower to maintain and repair these things "overhead". It comes out of a different pocket, not the same pocket as "capital" which new equipment would come from. And picking up used equipment is a paperwork nightmare for such workplaces.
And please note: a lot of groups used the Y2K risks as an opportunity to upgrade a lot of systems to something modern, but those systems are now unsupportable. (VMS on Alpha, anyone? NT 4.0 on anything?)
Get Muhammed Ali's daughter. She's black, but she's *gorgeous*, and she can hit like a really fast jackhammer.