Great idea, but how about instead of having it at your desk to let you know you've got mail, mount it in the rear window of your car for those times when the horn just isn't enough:-)
I've been thinking of doing the same for years, but never got around to doing it. But not just for the rear window. If you h-flip the output, you can have one installed behind your windshield, facing forward, and the message will read nicely on others' rear-view mirrors.
Use both, and you've turned your car into the ultimate expression device! Maybe we could even sell them retail... (Kit includes: two text-scrolling-gizmos, one controller-box, one easy-touch message selection keyboard, one serial programming cable, one baseball bat)
(Don't ask what the bat is for. If you can't think of just how people would react if you HAD one of these... well, don't get one...)
Come to think of it, THIS is where a speech-to-text device would come in handy...;)
I wonder what the relation of UFO sightings to whisky drinking might be...
It is mentioned that the number is three times larger than in France. That is to be expected, since whisky has three to four times more alcohol in it than the equivalent quantity of wine. The same rationale may be used for Italy, also an established wine producer.
(Yes, France makes cognac and Italy makes grappa, but these are mostly export products;) )
Does anyone know what the number of UFO sightings is like in Lynchburg, Tennessee?
world- first plan that legalises [sic] music piracy
It's spelled "legalizes" in America, but it's spelled "legalises" in Britain, Australia, Canada, et al. There is no need for the "[sic]".
And it's spelled "sick", not "sic". Altough I wouldn't go so far as saying that the whole concept of legalising-an-illegal-activity-that-was-legal-most -of-the-time-after-all is "sick". Stupid, yes, but sick is maybe a bit too much.
[sorry, too much time without my red pill... and yes, I do know what "sic" means. It's something about that girl, Gloria Mundi, right?]
DRM is probably _the_ hot topic right now. Everyone seems to be designing and proposing DRM schemes. And the Open Source community has found serious flaws in both design and intention in every scheme proposed so far.
The community complains loudly about companies that want to forcefully restrict liberty for users and developers alike. But has the community come forth with its own proposal?
How do we implement rights management for the independent author? How do we support code signing for the independent programmer? I should have an Open system that allows me to produce my documents, write my code, distribute what I want, and have everything appropriately signed by me.
Are we up to this? Are we able to propose alternates? Instead of just saying "no", shouldn't we be constructive and say "this is how to do it"?
I'm willing and able to work towards this, altough it's not something I can/want to do alone. Any takers? Let me know.
"Ease of use" does not exist. "Ease of use" comes from habit. Quoting from someone's sig: "The only natural interface is the nipple, everything else has to be learned"
I believe shifting gears with my right hand is the natural way to do it, an English reader would think that the left hand is much more natural, an American reader probably doesn't even know what a gearshift is, let alone which hand to use it with...
I'm sorry if I seemed to imply that an XBox network is "fundamentally less secure because it is one system".
The thing that will make the XBox less secure is if Microsoft assumes that it will only ever interact with other XBoxes, and forgets to test for vulnerabilities that involve
a) Systems that are not XBoxes
b) Modified XBox hardware
c) XBoxes running modified software
All of these will, no doubt, be found "in the wild" inside Microsoft's XBox-only-no-modded-consoles-allowed Disneysoft.net . We will then see if Microsoft designed and tested the XBox to interact (and endure interaction) with anything other than itself.
The difference of attitude between MS and Sony is striking: Sony chosses to "open" its system, letting developers implement new things, potentially allowing
devices other than Sony consoles to access their network. Microsoft, on the other hand, chooses to "close" their system, specifying their own methods and protocols, and creating a supposedly XBox-only network. What is wrong with this picture?
In fact, this looks very much like the Unix-Windows security arena. Unix has been traditionally open. All the protocols are open, and, especially, the implementations never assume that they know who or what is on the other side. This, in fact, is one of the critical aspects of security. Never trust the remote. Ever. Always assume that things can be spoofed, always assume that all and every piece of data you receive has NOT been validated by the remote. This is the Unix way of doing things. This, in fact, is the right way of doing things.
Alternatively, you can start "trusting" the untrustable. You can build a single platform network and assume that all data sent from the remote is "good data". This is naive, and leads to disaster.
Remember the "ping of death" vulnerability that existed on Windows machines: why did it exist? The simple answer is that it was there because the ICMP stack was badly coded. Right. But that's only half of the story. In fact, it was there because of Microsoft's way of thinking. Microsoft always assumes that things are under full control. The ping of death vuln existed because the Windows version of "ping" did not allow for larger-than-a-given-number packets to be sent. And the Microsoft way of thinking is "if the client can not send it, the server can neglect checking for it". That way of thinking has lead to many of the security flaws in Microsoft products.
The truth is, things are not always under full control. The XBox can be hacked locally, changed into allowing modifications to be performed on the "Microsoft trusted" software components. Other kinds of machines can be connected to the network and made to pretend to be XBoxes, while still allowing full control by the owner on what gets sent and to where.
In short, by choosing to create an "XBox-only network", Microsoft has taken the step that will make its network fundamentally insecure. If you still can't see why, think of it in the Disneyland way Microsoft suggests. What they are in fact saying is that "since the Disneysoft is secure, you can trust everyone there". The things you normally tell kids to do, like "never take candy from strangers", are no longer in effect inside the Disneysoft. Inside Disneysoft, you can take candy from anyone. What is the rationale behind this? That "bad people" can't go inside? Wrong. That "bad people", once inside, can't give you candy because "giving candy" is not an option? Wrong - if you own the box, everything is an option. That if "bad people" do this, they will be expelled? Sure. They can expell all they want. That won't prevent them from coming back, and it certainly won't prevent your kid from being dead.
A last thought: People go around saying "what can happen? someone steals your save game? so what?".
Well, on one side, the XBox is being touted as a future "computing/internet/browsing platform". That means all kinds of sesitive information is going to get stored in its hard disk. And while having your save game stolen can be little more than a nuisance, having your personal data, personal files and credit card information stolen can be a bit more serious than that.
On the other side, the XBox has a network adapter. And guess where it is going to sit? Right on your home network. Together with your PC. Together with your other local devices. Probably inside your firewall? Great target for a hacker to attack and, from there, jump on to your private network. Sure, you can always firewall it, put it on a DMZ. Sure...
Microsoft does not have a good security record.
This would have been good for everyone, I think - sure you could write something for Microsoft's JVM that wouldn't run on Sun's JVM.. but I can still do that today if I really want to (tie my code to a particular VM or a particular set of native code).
It's not just a matter of extending. It's a matter of leveraging another tool (IE) into making your JVM the de facto standard. If the number of MS JVM installed outnumber the Sun JVM installed, MS gets to be the standard. If they provide a useful, updated JVM, laced with a few "extensions", users are lured into using it. If developing with the extensions makes it easier to cut corners than to write correct code, developers do exactly that. Slowly, many applets start working only in the MS JVM. Since MS has most of the market, the Sun JVM will appear to be "broken" (yes, that's the difference between "X has additional features" and "Y is broken", it only depends on who is more popular). Suddenly, it's Microsoft that has the leading JVM. And how did they do it? By "embracing and extending". Not by giving back to the community, not by "making a better product". If they can "make a better product than the standard product" let them make one that is the same, but better implemented. Not by adding proprietary features and using their browser/OS market leader position to stronghold everyone into their implementation.
All in all, this is not good news for anyone. Since they won't ship a decent, updated, standard JVM, it's better that they don't ship a JVM at all. Shipping a broken, "mutant" version (think of the MS JVM as a person with an extra arm coming out of their back - funny, but still...) will only contribute to kill Java - oh wait a minute... could it be that's what they're after?
When I saw "products by Docomo and Sony" I couldn't help it... My thoughts just went "booth babes"... I clicked the links so fast I didn't even think about what I was doing...
The site was a bit on the slashdotted side... but i insisted. And guess what. The guys actually took pictures of the phones! of the silly phones! Now who on earth goes all the way to Asia to get pictures of phones? Boy, I sure liked E3 better than this fair...
Back in the sixties, rumor has it that men tended to view their motobikes as something of a sexual nature, perhaps equating it with a woman.
They cared for it, they made it beautiful, they rode it, they rode it, they rode it...
This comment on chastity belts brings back to light the much debated issue of the hacker's liaison with his computer. He cares for it, makes it beautiful (case mods), sometimes prefers it naked (no case), install the latest software (XP) and then it crashes and he gets screwed, screwed, screwed...
I guess if they had porn on bikes we'd never had gotten this far.
I don't imagine a world where software has no flaws, in the same way that I don't imagine cars or houses without flaws.
My last car used to go "beep" when it ran low on gas. I hated it. I wished it had a parameter somewhere that I could tweak and make it not beep. But having that parameter would mean increased complexity for the car. And complexity would mean more things to break, more places where bugs could creep in.
Software engineering is a relatively young discipline. Still, it exists, and it lays down rules and methods for creating software.
The reason most software has as may bugs as it does is not a matter of not having the tools or the methods, it's largely a matter of not using them.
Take the smallest piece of software possible, a "hello world" program, for instance. It it takes no input and just prints the string, there are very few places a bug can creep in. Even so, you have to be able to ascertain that you do have a standard output on which to write. But the minute you have to process the command line, you start increasing the complexity of your program, and immediately raise the risk for bugs.
Many bugs happen at software interconnections. The calling of functions, the invocation of an API, the parsing of inout, the access of files and devices. Why does this happen? Largely, because there is no clear contract on what the caller is supposed to do, and what the called function is supposed to accept.
One of the largest causes for bugs is lack of a formal contract between every two pieces of software, between every two parts of code.
Lack of existance, and lack of enforcement. If a function is supposed to return a positive integer between 2 and 8, why does the function itself not validate that its output is always within the range?
Some languages, namely Eiffel, impose a form of "programming by contract", in which both parties of any software interaction validate their own inputs and outputs, and check each other's, as well. But we can take this a lot further. Capabilities based operating systems. Deep granularity in software capability attribution. If a piece of code never needs to access the file I/O functions, don't let it do so.
One idea that comes to mind is the notion of a public key based operating system. Issue key pairs to every piece of harware, to every device, to every directory. Then issue key pairs to every program, to every major block inside every program. And then use a broker to validate every program's access to every device. If a piece of code wants to write to memory, it must code the data in its own private key, and access the memory using the memory block's public key. But don't just make public keys available. Grant them only after approved requisition, as you would in a capabilities OS.
There are many ways to improve overall quality and safety of sofware. most of them already exist. It's a matter of using them. It's a matter of getting powerful buyers to enforce the usage of advanced engineering practices. The government should set the example.
The Chinese government has always had a problem with internet cafes. Especially because they are anonymous, surfing from a cafe is quite different from surfing from your own home. If you surf from home, you can be held liable for what you download and what you access. At a cafe, you can never be sure about who does what. And that, of course, drives any control-freak internal intelligence agency quite mad.
Of course they could have shut down most of the cafes before, since they were illegal, but that would expose them to international pressure and make them look like tyrants deemed to deny freedom and anonymity.
Now, they have the perfect excuse. Under the banner of "think of the fires", they can close down most of the cafes and start imposing strict regulations and control on the remaining ones. If any of the remaining ones fails to comply, they can always audit them for fire regulations compliance, and subsequently shut them down.
And what will the international community say? Nothing. What can you say?
Any kind of totalitary regime comes with its own risks. Abuse of power comes to mind as a prominent one. The Chinese government will always leverage their existing power in order to maitain and obtain more power. Frankly, I don't know how a one-billion-people country can be ruled. I don't even know if a democratic regime as we know it would ever work there. But I'm sure that it can't be much worse than it already is.
Ethical considerations towards disclosure are quite good, from an abstract point of view. Nevertheless, every professional must take into account who it is they are effectively working for. The line must be drawn somewhere. Drawing the line between "legal" and "illegal" is frequent. You are ethically bound not to do any illegal action, even if requested by your employer. You are also ethically bound not to do any legal action at the request of your employer if by doing it you knowingly act as a tool of your employer in performing an illegal action.
The admin has no obligation towards the credit card holder. The admin has no commercial or professional relationship with the credit card holder. If a sysadmin called me at home and told me he knew my credit card number had been stolen, I'd probably think he was trying to fool me into some kind of scam, or blackmailing me, and would probably sue him. If a sysadmin informed anyone that MY credit card number had been stolen, I'd probably want to sue him, too, since I'd consider that an unlawful intrusion into my privacy.
The holder has a relationship with the credit card company. No one but the credit card company can tell the user that his card number has been stolen. And the credit card company's customer is the commerce company, not the sysadmin. The flow must be sysadmin->corporation->credit card company->card holder. There can be no other flow. Your ethical duty is to report to your immediate management. If your immediate management does not report it further, you may be inclined to "leak" that there is something management should know about, and let top management start investigating. All of this within your company. It's the company's liability, never yours, once you reported to immediate management.
And if by any reason you feel that someone else should know, all you can do is "hint" that someone should look into things. If you want more than hinting, file a formal complaint and force an inquest to start. But don't just "disclose" to whomever you want to. By doing that, you are violating a few ethical codes yourself...
I wrote a comment on the AdTI paper, trying to outline, paragraph by paragraph, what I think is wrong with the assumptions and claims made, and offering counter examples and alternate visions on the claims made and the truth of the open source movement.
Maybe you think it't worth a read.
I am available for criticism and comment, and will produce a revised version if enough people show interest and provide constructive criticism.
I hope that worm wasn't GPL'ed!
After all, that would mean that MS would have to distribute the source to VS.NET!
Well, quoting from the GPL:
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
No, they wouldn't have to release the source to vs.nyet. And if they did, what would you want it for?
Hmmm... would any kind of password system in, say, Unix, Linux, Windows, MVS, etc. count as an "american password system"? My guess is "yes", regardless of where the system itself is installed (Norway, for instance) and of who owns the information inside... Sklyarov was arrestes at the request of Adobe, not any e-book "copyright holder"...
Slashdot Mirror
I've been thinking of doing the same for years, but never got around to doing it. But not just for the rear window. If you h-flip the output, you can have one installed behind your windshield, facing forward, and the message will read nicely on others' rear-view mirrors.
Use both, and you've turned your car into the ultimate expression device! Maybe we could even sell them retail... (Kit includes: two text-scrolling-gizmos, one controller-box, one easy-touch message selection keyboard, one serial programming cable, one baseball bat)
(Don't ask what the bat is for. If you can't think of just how people would react if you HAD one of these... well, don't get one...)
Come to think of it, THIS is where a speech-to-text device would come in handy... ;)
It is mentioned that the number is three times larger than in France. That is to be expected, since whisky has three to four times more alcohol in it than the equivalent quantity of wine. The same rationale may be used for Italy, also an established wine producer.
(Yes, France makes cognac and Italy makes grappa, but these are mostly export products ;) )
Does anyone know what the number of UFO sightings is like in Lynchburg, Tennessee?
Built a spaceship called the Ark and came to Earth.
Don't you people read the bible?
And it's spelled "sick", not "sic". Altough I wouldn't go so far as saying that the whole concept of legalising-an-illegal-activity-that-was-legal-most -of-the-time-after-all is "sick". Stupid, yes, but sick is maybe a bit too much.
[sorry, too much time without my red pill... and yes, I do know what "sic" means. It's something about that girl, Gloria Mundi, right?]
The community complains loudly about companies that want to forcefully restrict liberty for users and developers alike. But has the community come forth with its own proposal?
How do we implement rights management for the independent author? How do we support code signing for the independent programmer? I should have an Open system that allows me to produce my documents, write my code, distribute what I want, and have everything appropriately signed by me.
Are we up to this? Are we able to propose alternates? Instead of just saying "no", shouldn't we be constructive and say "this is how to do it"?
I'm willing and able to work towards this, altough it's not something I can/want to do alone. Any takers? Let me know.
Of course it's cool. It's a godddamn fridge!
Man, God forbid you from ever falling asleep...
I believe shifting gears with my right hand is the natural way to do it, an English reader would think that the left hand is much more natural, an American reader probably doesn't even know what a gearshift is, let alone which hand to use it with...
QED?
Windows: every now and then, you pay for what you don't get
I'm sorry if I seemed to imply that an XBox network is "fundamentally less secure because it is one system".
The thing that will make the XBox less secure is if Microsoft assumes that it will only ever interact with other XBoxes, and forgets to test for vulnerabilities that involve
a) Systems that are not XBoxes
b) Modified XBox hardware
c) XBoxes running modified software
All of these will, no doubt, be found "in the wild" inside Microsoft's XBox-only-no-modded-consoles-allowed Disneysoft.net . We will then see if Microsoft designed and tested the XBox to interact (and endure interaction) with anything other than itself.
Don't look for music online, unless you're willing to obtain it illegally.
The best place to legally buy music is still a record shop.
Import albums give you more rights than most US releases.
Summing it up, if you want your rights back, stay offline and move abroad.
(Does anyone still remember the analog pulse phones?)
In fact, this looks very much like the Unix-Windows security arena. Unix has been traditionally open. All the protocols are open, and, especially, the implementations never assume that they know who or what is on the other side. This, in fact, is one of the critical aspects of security. Never trust the remote. Ever. Always assume that things can be spoofed, always assume that all and every piece of data you receive has NOT been validated by the remote. This is the Unix way of doing things. This, in fact, is the right way of doing things.
Alternatively, you can start "trusting" the untrustable. You can build a single platform network and assume that all data sent from the remote is "good data". This is naive, and leads to disaster.
Remember the "ping of death" vulnerability that existed on Windows machines: why did it exist? The simple answer is that it was there because the ICMP stack was badly coded. Right. But that's only half of the story. In fact, it was there because of Microsoft's way of thinking. Microsoft always assumes that things are under full control. The ping of death vuln existed because the Windows version of "ping" did not allow for larger-than-a-given-number packets to be sent. And the Microsoft way of thinking is "if the client can not send it, the server can neglect checking for it". That way of thinking has lead to many of the security flaws in Microsoft products.
The truth is, things are not always under full control. The XBox can be hacked locally, changed into allowing modifications to be performed on the "Microsoft trusted" software components. Other kinds of machines can be connected to the network and made to pretend to be XBoxes, while still allowing full control by the owner on what gets sent and to where.
In short, by choosing to create an "XBox-only network", Microsoft has taken the step that will make its network fundamentally insecure. If you still can't see why, think of it in the Disneyland way Microsoft suggests. What they are in fact saying is that "since the Disneysoft is secure, you can trust everyone there". The things you normally tell kids to do, like "never take candy from strangers", are no longer in effect inside the Disneysoft. Inside Disneysoft, you can take candy from anyone. What is the rationale behind this?
That "bad people" can't go inside? Wrong.
That "bad people", once inside, can't give you candy because "giving candy" is not an option? Wrong - if you own the box, everything is an option.
That if "bad people" do this, they will be expelled? Sure. They can expell all they want. That won't prevent them from coming back, and it certainly won't prevent your kid from being dead.
A last thought: People go around saying "what can happen? someone steals your save game? so what?".
Well, on one side, the XBox is being touted as a future "computing/internet/browsing platform". That means all kinds of sesitive information is going to get stored in its hard disk. And while having your save game stolen can be little more than a nuisance, having your personal data, personal files and credit card information stolen can be a bit more serious than that.
On the other side, the XBox has a network adapter. And guess where it is going to sit? Right on your home network. Together with your PC. Together with your other local devices. Probably inside your firewall? Great target for a hacker to attack and, from there, jump on to your private network. Sure, you can always firewall it, put it on a DMZ. Sure... Microsoft does not have a good security record.
All in all, this is not good news for anyone. Since they won't ship a decent, updated, standard JVM, it's better that they don't ship a JVM at all. Shipping a broken, "mutant" version (think of the MS JVM as a person with an extra arm coming out of their back - funny, but still...) will only contribute to kill Java - oh wait a minute... could it be that's what they're after?
The site was a bit on the slashdotted side... but i insisted. And guess what. The guys actually took pictures of the phones! of the silly phones! Now who on earth goes all the way to Asia to get pictures of phones? Boy, I sure liked E3 better than this fair...
</kidding>
People keep abusing my profession, next time I tell them I'm a security expert they're going to ask me if I can please go and close the door...
They cared for it, they made it beautiful, they rode it, they rode it, they rode it...
This comment on chastity belts brings back to light the much debated issue of the hacker's liaison with his computer. He cares for it, makes it beautiful (case mods), sometimes prefers it naked (no case), install the latest software (XP) and then it crashes and he gets screwed, screwed, screwed...
I guess if they had porn on bikes we'd never had gotten this far.
My last car used to go "beep" when it ran low on gas. I hated it. I wished it had a parameter somewhere that I could tweak and make it not beep. But having that parameter would mean increased complexity for the car. And complexity would mean more things to break, more places where bugs could creep in.
Software engineering is a relatively young discipline. Still, it exists, and it lays down rules and methods for creating software.
The reason most software has as may bugs as it does is not a matter of not having the tools or the methods, it's largely a matter of not using them.
Take the smallest piece of software possible, a "hello world" program, for instance. It it takes no input and just prints the string, there are very few places a bug can creep in. Even so, you have to be able to ascertain that you do have a standard output on which to write. But the minute you have to process the command line, you start increasing the complexity of your program, and immediately raise the risk for bugs.
Many bugs happen at software interconnections. The calling of functions, the invocation of an API, the parsing of inout, the access of files and devices. Why does this happen? Largely, because there is no clear contract on what the caller is supposed to do, and what the called function is supposed to accept.
One of the largest causes for bugs is lack of a formal contract between every two pieces of software, between every two parts of code.
Lack of existance, and lack of enforcement. If a function is supposed to return a positive integer between 2 and 8, why does the function itself not validate that its output is always within the range?
Some languages, namely Eiffel, impose a form of "programming by contract", in which both parties of any software interaction validate their own inputs and outputs, and check each other's, as well. But we can take this a lot further. Capabilities based operating systems. Deep granularity in software capability attribution. If a piece of code never needs to access the file I/O functions, don't let it do so.
One idea that comes to mind is the notion of a public key based operating system. Issue key pairs to every piece of harware, to every device, to every directory. Then issue key pairs to every program, to every major block inside every program. And then use a broker to validate every program's access to every device. If a piece of code wants to write to memory, it must code the data in its own private key, and access the memory using the memory block's public key. But don't just make public keys available. Grant them only after approved requisition, as you would in a capabilities OS.
There are many ways to improve overall quality and safety of sofware. most of them already exist. It's a matter of using them. It's a matter of getting powerful buyers to enforce the usage of advanced engineering practices. The government should set the example.
In the case of IIS exploits, for instance, it has nothing to do with it whatsoever.
Of course they could have shut down most of the cafes before, since they were illegal, but that would expose them to international pressure and make them look like tyrants deemed to deny freedom and anonymity.
Now, they have the perfect excuse. Under the banner of "think of the fires", they can close down most of the cafes and start imposing strict regulations and control on the remaining ones. If any of the remaining ones fails to comply, they can always audit them for fire regulations compliance, and subsequently shut them down.
And what will the international community say? Nothing. What can you say?
Any kind of totalitary regime comes with its own risks. Abuse of power comes to mind as a prominent one. The Chinese government will always leverage their existing power in order to maitain and obtain more power. Frankly, I don't know how a one-billion-people country can be ruled. I don't even know if a democratic regime as we know it would ever work there. But I'm sure that it can't be much worse than it already is.
Nevertheless, every professional must take into account who it is they are effectively working for.
The line must be drawn somewhere. Drawing the line between "legal" and "illegal" is frequent. You are ethically bound not to do any illegal action, even if requested by your employer. You are also ethically bound not to do any legal action at the request of your employer if by doing it you knowingly act as a tool of your employer in performing an illegal action.
The admin has no obligation towards the credit card holder. The admin has no commercial or professional relationship with the credit card holder. If a sysadmin called me at home and told me he knew my credit card number had been stolen, I'd probably think he was trying to fool me into some kind of scam, or blackmailing me, and would probably sue him. If a sysadmin informed anyone that MY credit card number had been stolen, I'd probably want to sue him, too, since I'd consider that an unlawful intrusion into my privacy.
The holder has a relationship with the credit card company. No one but the credit card company can tell the user that his card number has been stolen. And the credit card company's customer is the commerce company, not the sysadmin. The flow must be sysadmin->corporation->credit card company->card holder. There can be no other flow. Your ethical duty is to report to your immediate management. If your immediate management does not report it further, you may be inclined to "leak" that there is something management should know about, and let top management start investigating. All of this within your company. It's the company's liability, never yours, once you reported to immediate management.
And if by any reason you feel that someone else should know, all you can do is "hint" that someone should look into things. If you want more than hinting, file a formal complaint and force an inquest to start. But don't just "disclose" to whomever you want to. By doing that, you are violating a few ethical codes yourself...
I wrote a comment on the AdTI paper, trying to outline, paragraph by paragraph, what I think is wrong with the assumptions and claims made, and offering counter examples and alternate visions on the claims made and the truth of the open source movement.
Maybe you think it't worth a read.
I am available for criticism and comment, and will produce a revised version if enough people show interest and provide constructive criticism.
Thank you for your advice on not travelling to the United States. I do appreciate it.
Hmmm... would any kind of password system in, say, Unix, Linux, Windows, MVS, etc. count as an "american password system"? My guess is "yes", regardless of where the system itself is installed (Norway, for instance) and of who owns the information inside... Sklyarov was arrestes at the request of Adobe, not any e-book "copyright holder"...