When OOo came, I was thrilled to hear there was an alternative to MS-Word. It turned out to be a bloated MS-Word clone, just orders of magnitude slower, and filled with bugs.
Indeed. EVERYONE seems to be cloning the worst features of Word, because that's apparently by far the easiest way to create a program that can roundtrip to Word and back without losing formatting. And that's apparently the only critical feature.
So I've given up. By preference I write documents in HTML+CSS now. I'd use Docbook or something similar, if there were good tools available.
Don't even talk to me about TeX. Been there, done that, got the incomprehensible error messages.
I don't know the details of the way Microsoft's gateway between the Win32 subsystem and the POSIX subsystem works. You'll have to ask someone like Steve Walli for the details. There are many possibilities, and various ways of testing them... for example you could distinguish between whether the gateway reparsed it using a stub in win32 or simply called something like { exec(bin_shell, "sh", "-c", commandline) } on the POSIX side by seeing if the quoting followed MS-DOS or/bin/sh behaviour.
The point is that there are mechanisms in NT to support executing a program without requiring that the command line be reparsed.
Anyway posix->posix calls are probably in a tiny minority of exec calls.
I was recommending that Microsoft implement the equivalent semantics in an API within the Win32 subsystem, bypassing ShellExecute, and suggested that the code they already have for the POSIX exec may be useful: it may be useful as a model, it may be useful in porting the API or something similar to Win32, or they could even allow closer integration of POSIX and Win32 (as Softway Systems did in Interix) so that helper applications could be implemented as POSIX subsystem components and browsers could use the POSIX exec API to call them.
All the changes that I'm suggesting require action from Microsoft. They can't be implemented purely by third parties in any case, because many of the applications that would need to use the more secure methods and APIs are by Microsoft. EVERYONE would have to make complementary changes to make it work. It's not a small problem, it's one that's getting bigger every year, but it's the only way to get the malware problem on Windows under control. Bandaids like the leaky sandbox they added in Vista or any number of "are yousue you want to explode" dialogs won't solve the problem, and I'm still amazed that Microsoft didn't see these problems after the FIRST flood of malware taking advantage of the desktop-browser integration hit in 1997 and 1998.
But in any case, since these would by necessity be new APIs, whether any existing programs are using the model I'm recommending Microsoft follow seems more or less irrelevant. I only brought up the fact that they have implemented the kind of API I'm suggesting to indicate that it's something they DO have the expertise to do.
Your argument sounds convincing but I'd like to see some proof that copyright law in the US *or* the UK actually says what you're suggesting. But in any case, I'm not the one you should be debating that with: it's buelba's comment that goes into the issue of Prince's copyrights... I'm just responding to the suggestion that the fact that Radiohead is a UK band has anything to do with it.
Here's the sequence...
Radiohead is saying "that's our music, so we're saying it's OK".
In the US, Radiohead isn't in a position to say that, because Prince has a performance copyright. (buelba's message).
Then Threni claimed that this didn't matter, because Radiohead are a UK band.
My response was that (a) I don't think UK law differes from US law in a way that would matter here, and (b) Youtube aren't a UK company.
Your response was that YouTube did business in the UK as well.
My response was sarcastic, yes, pointing out that a company that does business in multiple countries is subject to all those countries laws. That should be obvious, so if Prince has a copyright in the US it doesn't matter whether he does or doesn't in the UK, YouTube's operating out of the country where he does.
So now... you're saying that Prince doesn't actually have a performance copyright. I don't know the particulars of the music festival, or whether the video was taken by someone who didn't have a ticket and thus was not beholden to any clauses in the contract (if that is even, as you argue, relevant). You may be right, I don't know, take that up with buelba. It's got nothing to do with me. I'm just the guy pointing out that YouTube has to follow US law, and if US law gives Prince the right to say it goes down, it's going down. No matter what the law in the UK says.
Unfortunatly the Posix subsystems exec call just pastes the argv back together with spaces and passes it to the next program (it has to, it runs through the normal Windows API at some point)
No, the POSIX subsystem doesn't go through the Win32 subsystem. It is still, even in Vista, a separate subsystem that runs directly on top of the NT kernel. POSIX API programs calling POSIX API programs with EXEC do not, at any point, interface with Win32.
I was trying to imply that they may indeed be beholden to more than just US law.
Doesn't matter. US law is the one that's got the slack you'd need in it, and that slack runs the wrong way for it to make any difference. Unles, as I pointed out, UK law has some kind of compulsory license that's a kind of complement to the US license, there's nothing to force Prince to allow his performance to be distributed.
Interesting comment here: I didn't bother contacting Apple, as they've told Nitesh that they consider this as an "enhancement request" and will not bother to fix this issue any time soon.
Aviv's smart enough to find an IE exploit to target, but he's not smart enough to understand that because a company doesn't care about a really ineffective denial of service that doesn't mean they don't care about a real problem.
It certainly opens the possibility for some "fun" denial of service attacks.
Assuming you don't respond to the download manager popping up and showing you it downloading several files (to start with) by closing the malicious page.
The old "open up a zillion nested iframes" attack is much more effective.
What if I was on linux and the file uploaded was.bashrc or.profile or any number of old school ini files windows still activly looks for and parses?
If your browser's default download folder is your home directory, or a directory where putting a file named "autoexec.bat" will be executed when you boot, then you have bigger security problems than this.
One of the things that pissed me off about Google buying YouTube is Google Video didn't used to use any obfuscation. And they ended up re-encoding a bunch of videos that were already working just fine.
Flickr is your example.
Then there's places like Ocean Footage who seem to still be using redirection tricks for obfuscation.
Flash behaves much better than Quicktime or embedded Windows Media Player.
Where "behaves much better" means "hangs more often"?
Btw, both Quicktime and Windows Media try to make downloading streaming media hard
View Source, search for ".mov" or ".wmv" is "hard"?
Vendor first doesn't mean "vendor only", and nobody says you need to sit on a flaw forever if the vendor doesn't fix it. You're giving them advance notice, not carte blanche.
I don't trust Pay Pal (and I've read many stories of people who have been done over by Pay Pal - there's an "Informative" comment (ie. rating 5) somewhere in this thread giving an example).
This is why I keep my paypal linked to a bank account that only ever has minimum balance in it.
It's Radiohead's song, but it's Prince's performance.
On the other hand, if it was Radiohead doing a cover of Prince's song, I don't think Prince could stop them because of the compulsory license. They'd probably have to pay some license fees to do so, but they can probably afford it.
Unless the UK has a compulsory performance license, which I don't believe is the case, the only thing they could gain from the difference in US and UK law would be the right to refuse distribution of the video.
I think you're missing the point that Apple has refused to patch their browser.
No they haven't. They have simply refused to treat a potential denial of service attack as a security hole.
Microsoft refused to fix the design of their HTML control even when maintaining the integration of the browser and the desktop that is at the core of many of their problems was putting them under risk of being broken up by the US Department of Justice. Apple has merely declined to treat a problem (one that is not, in fact, a security hole) as a security hole. They haven't said they wouldn't fix it, they said that it wasn't a critical problem.
The difference in the level of arrogance here is dramatic. On the one hand you have Apple saying "that's not as serious as you think it is", on the other you have Microsoft deliberately installing a deep and unfixable security flaw in order to create a loophole in their agreement with the DoJ, and not only refusing to fix it but deliberately insulting the judge who's telling them to fix it.
1. ActiveX is insecure because (a) the installation of an ActiveX control is initiated by the remote site, not by a request by the user, therefore the malicious site gets to install its own plugin, (b) there is no easy revocation mechanism (other that a blacklist in an IE update, perhaps), and a malicious site can provide an old exploitable version of an apparently ordinary plugin, and (c) there are normal "insecure" ActiveX components in the system and there have been attacks that exploited this... ordinary browser plugins don't have any of these holes.
2. ShellExecute() takes a single string that is interpreted by cmd.exe, similar to the UNIX library routine system(). exec() takes a *preparsed* list of files and options, received directly by the called program. This means that ShellExecute() is subject to quoting attacks, and exec() isn't.
In addition, while it was once common to find "." in the path it's been at least 20 years since that was considered good practice, and I haven't run into it in at least a decade. In any case, exec() doesn't use the path to locate the command, that's the responsibility of the calling program... the first argument to exec() is an actual executable file.
Look up how "Proected Mode" works on IE runnining on vista and you'll be pleasently suprised.
Protected mode in IE makes it harder for a compromised instance of IE to attack objects outside this additional sandbox layer. It doesn't do anything to prevent that compromised instance from performing secondary attacks in the local network, or on stealing security tokens such as passwords and account numbers and PINs when you use it to access a website, and the protected mode sandbox is leaky... there has already been one demonstrated compromise.
Security is like sex, once you're penetrated you're ****ed. Microsoft needs to remove the mechanisms that allow malicious content to not just set you up for an exploit but actually perform an exploit, not just wrap a second leaky sandbox around the first.
ShellExecute() passes a single string to the called program that then has to be reparsed by that program. There is no standard for how these strings are parsed, how quotes need to be escaped, and so on. There have been a number of attacks that took advantage of this.
fork()/exec() allows the calling program to completely parse the command line into separate file names and options, and to control the environment of the called program in a number of other ways that limit the ability of a potential attacker to change the behavior of the application being called. The closes equivalent to ShellExecute() on UNIX is system(), and the use of system() by security-critical programs has been involved in exploits and is normally considered a red flag in security audits.
If a browser (any browser) allows a website to randomly download files without the user's explicit permission, regardless of the location, it is a security issue in my opinion.
It's a minor issue compared to a number of others that ALL browsers on Windows have. If Microsoft is serious about security then they need to:
1. Immediately transition away from ActiveX, with as short a timeframe as possible. 2. Replace ShellExecute() with something similar to UNIX's exec(). They already HAVE the code, in the POSIX subsystem. 3. Eliminate "security zones" as a security model - there must be no circumstance in which the location of an object named in a web page automatically grants it privileges. 4. Provide an alternate API for browsers to use to find and run helper applications that is not based on the desktop helper application bindings.
All four of these are far bigger problems than having files downloaded without a prompt. Not only do they all provide paths to direct execution of untrusted code without user interaction, but they have all BEEN used for that purpose hundreds of times over the past decade.
I am not sure it's possible to implement a really secure browser on Windows without completely bypassing all of Microsoft's recommended APIs.
Recent usage favors the term "isolated" rather than "uncontacted" as few peoples have remained totally uncontacted by modern civilization, but a number have chosen to make contact either exceedingly difficult or dangerous. Many indigenous rights activists call for such groups to be left alone in respect of their right to self-determination.
You can get higher capacity drives than that in more compact packages. It's a little cheaper than the 4G version of this drive but the Sandisk product's got it beat to hell for coolness.
It's possible to obfuscate HTML/Javascript to some extent, and yet, no one bothers to.
People do it all the time. Just about every site that streams music or video has some kind of scheme to obscure the actual URL from casual readers. Over time most of them have switched from HTML and Javascript to Flash, even though they don't actually do much more in the flash interface than the controls you get by default when you embed Quicktime or Windows Media players in the page.
Other common places you see this is in ads and other places that have a reason to force people to follow a link to find out what they are, or to hide viewer-tracking code in web bugs.
Or worse: the only place I've seen more deliberate obfuscation of code than pre-flash streaming sites is in phishing sites... and the kind of obfuscation in both places is similar... decoding it generally involves running through a couple of layers of "take a hex-coded string, insert '%' between every third character in this string, use the URL decoder function, look up part of the name in a table of hex coded strings and do the same thing to them, and paste them all together with a partial URI...".
If average Flash sites looked just like average HTML sites, I would've thought you had a point.
Most flash isn't in flash-based sites, it's little panels in regular sites. Little panels that often have simple graphics and not even any animations, doing things that are trivial in CSS, but that require you to actually interact with them to find out what they're all about.
For all these things obfuscation is far more important than ease of generating fancy transitions.
"Clearly there are powerful core concepts of transparency and sharing at the heart of this movement. However, it's starting to blur the original ideas articulated by Eric Raymond, Danese Cooper, et al, which are about the source code itself and the developers who share it. The risk is that the term itself loses meaning over time, which would be unfortunate as it's a powerful idea. So one very important thing that's missing in 'the community as a whole' is a common philosophy that is clear and broad enough to be embraced by everyone and allows some of the factional arguments to be settled peacefully."
Eric Raymond and the rest weren't creating a movement, they were describing one, and the core concepts of transparency and sharing are old as programming. The idea that code shouldn't be shared didn't really take any kind of strong hold until the '70s, really. Not only was most code written because it had to be there to sell the hardware, but much of it was so primitive in many ways that you needed access to the source code to get it to work. You had commentators in th '60s and '70s assuming that programming, or at least code literacy, would be as common as literacy itself by the turn of the century. On top of that you had the academic world where publishing enough information to reproduce an experiment was simply what you did.
So the movement that can't be named has been around longer than Microsoft, let alone the FSF or the OSI. The common philosophy is that sharing code is a good thing... the biggest differences are all about how much sharing is enough.
Slashdot Mirror
When OOo came, I was thrilled to hear there was an alternative to MS-Word. It turned out to be a bloated MS-Word clone, just orders of magnitude slower, and filled with bugs.
Indeed. EVERYONE seems to be cloning the worst features of Word, because that's apparently by far the easiest way to create a program that can roundtrip to Word and back without losing formatting. And that's apparently the only critical feature.
So I've given up. By preference I write documents in HTML+CSS now. I'd use Docbook or something similar, if there were good tools available.
Don't even talk to me about TeX. Been there, done that, got the incomprehensible error messages.
How do you run a posix program from cmd.exe?
/bin/sh behaviour.
I don't know the details of the way Microsoft's gateway between the Win32 subsystem and the POSIX subsystem works. You'll have to ask someone like Steve Walli for the details. There are many possibilities, and various ways of testing them... for example you could distinguish between whether the gateway reparsed it using a stub in win32 or simply called something like { exec(bin_shell, "sh", "-c", commandline) } on the POSIX side by seeing if the quoting followed MS-DOS or
The point is that there are mechanisms in NT to support executing a program without requiring that the command line be reparsed.
Anyway posix->posix calls are probably in a tiny minority of exec calls.
I was recommending that Microsoft implement the equivalent semantics in an API within the Win32 subsystem, bypassing ShellExecute, and suggested that the code they already have for the POSIX exec may be useful: it may be useful as a model, it may be useful in porting the API or something similar to Win32, or they could even allow closer integration of POSIX and Win32 (as Softway Systems did in Interix) so that helper applications could be implemented as POSIX subsystem components and browsers could use the POSIX exec API to call them.
All the changes that I'm suggesting require action from Microsoft. They can't be implemented purely by third parties in any case, because many of the applications that would need to use the more secure methods and APIs are by Microsoft. EVERYONE would have to make complementary changes to make it work. It's not a small problem, it's one that's getting bigger every year, but it's the only way to get the malware problem on Windows under control. Bandaids like the leaky sandbox they added in Vista or any number of "are yousue you want to explode" dialogs won't solve the problem, and I'm still amazed that Microsoft didn't see these problems after the FIRST flood of malware taking advantage of the desktop-browser integration hit in 1997 and 1998.
But in any case, since these would by necessity be new APIs, whether any existing programs are using the model I'm recommending Microsoft follow seems more or less irrelevant. I only brought up the fact that they have implemented the kind of API I'm suggesting to indicate that it's something they DO have the expertise to do.
Your argument sounds convincing but I'd like to see some proof that copyright law in the US *or* the UK actually says what you're suggesting. But in any case, I'm not the one you should be debating that with: it's buelba's comment that goes into the issue of Prince's copyrights... I'm just responding to the suggestion that the fact that Radiohead is a UK band has anything to do with it.
Here's the sequence...
Radiohead is saying "that's our music, so we're saying it's OK".
In the US, Radiohead isn't in a position to say that, because Prince has a performance copyright. (buelba's message).
Then Threni claimed that this didn't matter, because Radiohead are a UK band.
My response was that (a) I don't think UK law differes from US law in a way that would matter here, and (b) Youtube aren't a UK company.
Your response was that YouTube did business in the UK as well.
My response was sarcastic, yes, pointing out that a company that does business in multiple countries is subject to all those countries laws. That should be obvious, so if Prince has a copyright in the US it doesn't matter whether he does or doesn't in the UK, YouTube's operating out of the country where he does.
So now... you're saying that Prince doesn't actually have a performance copyright. I don't know the particulars of the music festival, or whether the video was taken by someone who didn't have a ticket and thus was not beholden to any clauses in the contract (if that is even, as you argue, relevant). You may be right, I don't know, take that up with buelba. It's got nothing to do with me. I'm just the guy pointing out that YouTube has to follow US law, and if US law gives Prince the right to say it goes down, it's going down. No matter what the law in the UK says.
Sheesh.
Follow up to buelba, OK?
Unfortunatly the Posix subsystems exec call just pastes the argv back together with spaces and passes it to the next program (it has to, it runs through the normal Windows API at some point)
No, the POSIX subsystem doesn't go through the Win32 subsystem. It is still, even in Vista, a separate subsystem that runs directly on top of the NT kernel. POSIX API programs calling POSIX API programs with EXEC do not, at any point, interface with Win32.
I was trying to imply that they may indeed be beholden to more than just US law.
Doesn't matter. US law is the one that's got the slack you'd need in it, and that slack runs the wrong way for it to make any difference. Unles, as I pointed out, UK law has some kind of compulsory license that's a kind of complement to the US license, there's nothing to force Prince to allow his performance to be distributed.
Interesting comment here: I didn't bother contacting Apple, as they've told Nitesh that they consider this as an "enhancement request" and will not bother to fix this issue any time soon.
Aviv's smart enough to find an IE exploit to target, but he's not smart enough to understand that because a company doesn't care about a really ineffective denial of service that doesn't mean they don't care about a real problem.
It certainly opens the possibility for some "fun" denial of service attacks.
Assuming you don't respond to the download manager popping up and showing you it downloading several files (to start with) by closing the malicious page.
The old "open up a zillion nested iframes" attack is much more effective.
What if I was on linux and the file uploaded was .bashrc or .profile or any number of old school ini files windows still activly looks for and parses?
If your browser's default download folder is your home directory, or a directory where putting a file named "autoexec.bat" will be executed when you boot, then you have bigger security problems than this.
I don't know... do you have any common examples?
YouTube?
One of the things that pissed me off about Google buying YouTube is Google Video didn't used to use any obfuscation. And they ended up re-encoding a bunch of videos that were already working just fine.
Flickr is your example.
Then there's places like Ocean Footage who seem to still be using redirection tricks for obfuscation.
Flash behaves much better than Quicktime or embedded Windows Media Player.
Where "behaves much better" means "hangs more often"?
Btw, both Quicktime and Windows Media try to make downloading streaming media hard
View Source, search for ".mov" or ".wmv" is "hard"?
And Google doesn't have to follow Chinese law in China, right? By your logic, they'd be home free.
Vendor first doesn't mean "vendor only", and nobody says you need to sit on a flaw forever if the vendor doesn't fix it. You're giving them advance notice, not carte blanche.
I don't trust Pay Pal (and I've read many stories of people who have been done over by Pay Pal - there's an "Informative" comment (ie. rating 5) somewhere in this thread giving an example).
This is why I keep my paypal linked to a bank account that only ever has minimum balance in it.
It's Radiohead's song, but it's Prince's performance.
On the other hand, if it was Radiohead doing a cover of Prince's song, I don't think Prince could stop them because of the compulsory license. They'd probably have to pay some license fees to do so, but they can probably afford it.
Unless the UK has a compulsory performance license, which I don't believe is the case, the only thing they could gain from the difference in US and UK law would be the right to refuse distribution of the video.
And in any case, YouTube isn't in England.
I think you're missing the point that Apple has refused to patch their browser.
No they haven't. They have simply refused to treat a potential denial of service attack as a security hole.
Microsoft refused to fix the design of their HTML control even when maintaining the integration of the browser and the desktop that is at the core of many of their problems was putting them under risk of being broken up by the US Department of Justice. Apple has merely declined to treat a problem (one that is not, in fact, a security hole) as a security hole. They haven't said they wouldn't fix it, they said that it wasn't a critical problem.
The difference in the level of arrogance here is dramatic. On the one hand you have Apple saying "that's not as serious as you think it is", on the other you have Microsoft deliberately installing a deep and unfixable security flaw in order to create a loophole in their agreement with the DoJ, and not only refusing to fix it but deliberately insulting the judge who's telling them to fix it.
1. ActiveX is insecure because (a) the installation of an ActiveX control is initiated by the remote site, not by a request by the user, therefore the malicious site gets to install its own plugin, (b) there is no easy revocation mechanism (other that a blacklist in an IE update, perhaps), and a malicious site can provide an old exploitable version of an apparently ordinary plugin, and (c) there are normal "insecure" ActiveX components in the system and there have been attacks that exploited this... ordinary browser plugins don't have any of these holes.
2. ShellExecute() takes a single string that is interpreted by cmd.exe, similar to the UNIX library routine system(). exec() takes a *preparsed* list of files and options, received directly by the called program. This means that ShellExecute() is subject to quoting attacks, and exec() isn't.
In addition, while it was once common to find "." in the path it's been at least 20 years since that was considered good practice, and I haven't run into it in at least a decade. In any case, exec() doesn't use the path to locate the command, that's the responsibility of the calling program... the first argument to exec() is an actual executable file.
Firefox and Opera use Microsoft's helper application database, which includes applications that DO use ActiveX.
Yes they've done most of these things.
They have done none of them.
Look up how "Proected Mode" works on IE runnining on vista and you'll be pleasently suprised.
Protected mode in IE makes it harder for a compromised instance of IE to attack objects outside this additional sandbox layer. It doesn't do anything to prevent that compromised instance from performing secondary attacks in the local network, or on stealing security tokens such as passwords and account numbers and PINs when you use it to access a website, and the protected mode sandbox is leaky... there has already been one demonstrated compromise.
Security is like sex, once you're penetrated you're ****ed. Microsoft needs to remove the mechanisms that allow malicious content to not just set you up for an exploit but actually perform an exploit, not just wrap a second leaky sandbox around the first.
ShellExecute() passes a single string to the called program that then has to be reparsed by that program. There is no standard for how these strings are parsed, how quotes need to be escaped, and so on. There have been a number of attacks that took advantage of this.
fork()/exec() allows the calling program to completely parse the command line into separate file names and options, and to control the environment of the called program in a number of other ways that limit the ability of a potential attacker to change the behavior of the application being called. The closes equivalent to ShellExecute() on UNIX is system(), and the use of system() by security-critical programs has been involved in exploits and is normally considered a red flag in security audits.
If a browser (any browser) allows a website to randomly download files without the user's explicit permission, regardless of the location, it is a security issue in my opinion.
It's a minor issue compared to a number of others that ALL browsers on Windows have. If Microsoft is serious about security then they need to:
1. Immediately transition away from ActiveX, with as short a timeframe as possible.
2. Replace ShellExecute() with something similar to UNIX's exec(). They already HAVE the code, in the POSIX subsystem.
3. Eliminate "security zones" as a security model - there must be no circumstance in which the location of an object named in a web page automatically grants it privileges.
4. Provide an alternate API for browsers to use to find and run helper applications that is not based on the desktop helper application bindings.
All four of these are far bigger problems than having files downloaded without a prompt. Not only do they all provide paths to direct execution of untrusted code without user interaction, but they have all BEEN used for that purpose hundreds of times over the past decade.
I am not sure it's possible to implement a really secure browser on Windows without completely bypassing all of Microsoft's recommended APIs.
The Wikipedia entry seems more honest:
You can get higher capacity drives than that in more compact packages. It's a little cheaper than the 4G version of this drive but the Sandisk product's got it beat to hell for coolness.
It's possible to obfuscate HTML/Javascript to some extent, and yet, no one bothers to.
People do it all the time. Just about every site that streams music or video has some kind of scheme to obscure the actual URL from casual readers. Over time most of them have switched from HTML and Javascript to Flash, even though they don't actually do much more in the flash interface than the controls you get by default when you embed Quicktime or Windows Media players in the page.
Other common places you see this is in ads and other places that have a reason to force people to follow a link to find out what they are, or to hide viewer-tracking code in web bugs.
Or worse: the only place I've seen more deliberate obfuscation of code than pre-flash streaming sites is in phishing sites... and the kind of obfuscation in both places is similar... decoding it generally involves running through a couple of layers of "take a hex-coded string, insert '%' between every third character in this string, use the URL decoder function, look up part of the name in a table of hex coded strings and do the same thing to them, and paste them all together with a partial URI...".
If average Flash sites looked just like average HTML sites, I would've thought you had a point.
Most flash isn't in flash-based sites, it's little panels in regular sites. Little panels that often have simple graphics and not even any animations, doing things that are trivial in CSS, but that require you to actually interact with them to find out what they're all about.
For all these things obfuscation is far more important than ease of generating fancy transitions.
"Clearly there are powerful core concepts of transparency and sharing at the heart of this movement. However, it's starting to blur the original ideas articulated by Eric Raymond, Danese Cooper, et al, which are about the source code itself and the developers who share it. The risk is that the term itself loses meaning over time, which would be unfortunate as it's a powerful idea. So one very important thing that's missing in 'the community as a whole' is a common philosophy that is clear and broad enough to be embraced by everyone and allows some of the factional arguments to be settled peacefully."
Eric Raymond and the rest weren't creating a movement, they were describing one, and the core concepts of transparency and sharing are old as programming. The idea that code shouldn't be shared didn't really take any kind of strong hold until the '70s, really. Not only was most code written because it had to be there to sell the hardware, but much of it was so primitive in many ways that you needed access to the source code to get it to work. You had commentators in th '60s and '70s assuming that programming, or at least code literacy, would be as common as literacy itself by the turn of the century. On top of that you had the academic world where publishing enough information to reproduce an experiment was simply what you did.
So the movement that can't be named has been around longer than Microsoft, let alone the FSF or the OSI. The common philosophy is that sharing code is a good thing... the biggest differences are all about how much sharing is enough.
they'd risk further massive DDoS attacks in retaliation if they did file a lawsuit.
That would be the best thing that could happen. Judges have absolutely no sense of humor about people who pull shit like that.