Well, I must admit that I know next to nothing about the case. But if, as you assert, he didn't do any harm, then I reckon his punishment, if any, shouldn't be very harsh.
Actually, I'm curious how this is supposed to work. Aside from people always finding something to do, I really can't see why we couldn't be sitting by the pool. I mean, obviously, work still needs to be done. But if we get more efficient at that (e.g. by building machines that then do the work with fewer human hours involved), we _should_, on average, have more free time for a given level of prosperity, right?
``or [...] should be praised for finding security faults in what should be extremely secure systems.''
That one is really easy. Finding said security flaws is an accomplishment, but that isn't the issue here. The issue is what you do once you find them. You get praise for actions that lead to improved security (reporting them to the vendor, fixing them, reporting them to users, etc.). You get condemnation for exploiting them for selfish goals. Same as always: do something for the common good? Praise on you. Screw someone over for your own advantage? Damnation on you.
``I'm sure they'll still have AA batteries 25 years from now.''
And even if not, if you indicate the required voltage and polarity, I'm sure people will be able to figure out how to power it 25 years from now. I don't think our alphabets or units of electricity are going to change, and, even if they do, people will still know the old ones.
``I'm sure many/.ers will have a problem with this, but how else is wikileaks going to be able to defend themselves from lawsuits designed to shut them down through ridiculous, unpayable court fees?''
Well, Wikileaks provide a much needed way for whistleblowers to safely blow their whistles. This is an invaluable service, and should be judged as such by the courts.
The problem is, before there can be such a ruling, Wikileaks will have to pay a lot. This is a fundamental problem, and one that affects everyone, not just Wikileaks. There is something very wrong about being able to be ruined by the courts, without the courts actually ruling against you. That is something that needs to be solved.
Finding funds to pay whatever fees are necessary to actually win your case is no solution. Doing so through questionable means is worse. Isn't there any way Wikileaks can fight these legal battles, without needing money they don't have?
"In the Netherlands, the public administration, one of the most modern in the world, has decided to forbid the use of proprietary software in the public sector."
Actually, I don't think that is correct. What I know is that a motion has been passed that requires the government to consider alternatives, and give preference to open software when it is equally suitable. The government subsequently ordered a lot of software from Microsoft, without investigating alternatives. This stirred up some commotion, after which a motion was adopted that requires the government to carry out the previous motion. I don't know what has happened since then, but I don't think forbidding proprietary software actually happened.
I attack the problem at its root and have a whitelist of connectors I am willing to use. Anything that doesn't have such a connector, I don't buy. Everything I have that needs charging can be charged either with a universal adapter, or by taking out the batteries and putting them in a battery charger. Manufacturers who insist on making up their own proprietary and incompatible junk when there are existing standards available can stuff it.
You got modded funny, but I really think it is a good idea. And, as another poster suggested, we should think hard about making it usable. Perhaps something simple to be found first, which then contains instructions for getting at the actual wealth of data inside.
What do you use to get the video from the YouTube URL? I wrote a program for that a while back, but YouTube changed, and now my program doesn't work anymore.
``Only the FSF would remove functionality and consider that to be a feature rather than a bug...''
Actually, no. Less functionality means (ceteris paribus) less complexity. Less complexity has a very beneficial effect on various aspects; for example, security and learning curve.
I am happy when I can get systems with less functionality. Provided, of course, that they can still do what I need them to do. As Albert Einstein put it: make it as simple as possible, but not any simpler.
``If you are a student, you can see if your school offers zSeries courses''
If IBM is blocking access to their mainframe technology as rigorously as you say, I would object to universities offering courses on it. That is them helping lock the world into proprietary technology. No, thanks.
Aren't there any more open systems that have similar benefits to IBM's mainframe technology?
``Technology most of the time is really nothing more than a machine that takes advantage of some principle of nature, and is often very, very simple at it's core.''
You are right. But being simple at the core doesn't mean actually simple. At its core, software is just a bunch ones and zeroes. It couldn't be that complicated, could it? Now you go and write a real-time operating system, please.
It's very impressive that all the hardware is hot-swappable. Unfortunately, that doesn't mean you will never have downtime. You need the right software for that, too. It either needs to be hot-updatable, or you need redundancy. Redundancy is the more realistic...and if you have that, anyway, why do you still need 99.999999% uptime hardware? In the end, your uptime is determined by the weakest link.
I'm working on a backup solution that allows people to back up their data to a remote server securely and efficiently. For "efficiently", think rsync: only the differences are sent (and some information necessary to identify what the differences are). For "securely", think assymetric cryptography: your backup is stored in encrypted form, so that only someone who possesses your private key can use it.
All this is currently in very early stages of design. I'd welcome any suggestions for protocols or software I could use. Currently, I am thinking to implement a transactional network block device protocol, and implement the backup protocol on top of that. I still need to decide on a programming language I can use for parts I need to write myself, too (something safe (no buffer overflows, please), yet with byte level access...and no Java or.NET, please).
By the way, this is going to be a commercial product, but the code and the protocols will be open. I'll charge for the storage and bandwidth.:-D
Spot on on both counts. SVG isn't a Flash competitor. And as for video...we have HTML for that which has worked since some time in the 1990s...there's no need to add Flash to that and break compatibility.
This is something I have recently been thinking about quite a lot. I am used to being able to easily debug software and watching what it is doing, and I had always considered logging as something you do because...well, I actually didn't really know why.
Now that I have done commercial development on larger project for a while, I have developed a somewhat better understanding of what you want logging for. I am still figuring it all out, but these are my current rules:
- Log event-related information. When your program receives input that causes it to start doing something, log that. If there is something strange or wrong about the input, log that. Once you stop processing (because you're done, or because you can go no further), log that. This way, you can see what your program has been doing. You can see that it received input (very important), you can tell if your program thought the input was correct or not, and you can see that it finished processing the input, and whether processing was successful or not.
- Provide for the option to log information about decisions your program makes. This is particularly useful for finding out why your program did not take action on something. This shouldn't always be enabled (unless, perhaps, for high-level decisions), because it would make logging overly verbose, but you should be able to enable it (preferably, focused on a specific part of the program) if you think the program is not behaving as it should.
- Last but not least, log every error condition. This should be obvious, but it is very important, so it's worth stating explicitly. You want to know if something went wrong, you want to know what went wrong, and you want to know where in your code it went wrong. Backtraces are very helpful here.
A large part of this is actually Cover Your Ass. If you log all events, and you didn't log anything, you can tell the Exalted User that the program didn't do anything, because it didn't receive anything from said user. If you validate input and log errors, even non-serious ones, you can tell the user "try with valid input", while you think about the problem and look through the code, seeing if anything is wrong on your end. If you log all errors, you can say "well, it says here there was a problem with the database connection, have a look at that", or "hmm, that value wasn't filled in, but should have been. are you sure you filled out all required fields?"
The above might sound disrespectful, but it really isn't. Very often, the users actually are doing something wrong, and they would be happy to know how they should do things to make it work, if only you could tell them. Logging everything you need to establish exactly where the problem is is invaluable for this. Your logging should tell you if the error lies inside your program or outside it. This makes your life easier, but your users', as well.
Additionally by saying "He added that in such cases, the goal of those issuing gag orders often seems to be to further their own agendas instead of helping others fix problems." shows a complete lack of understanding of market forces. Yes they are furthering his own agendas, and in the process, they benefit us. It's the market you commie bastard, it isn't evil, we all win, get over it.
Acting in ones own interest doesn't always benefit the common good.
``However... what is it really good for? A phone? Because it really looks like the typical "you can run Linux on it" thingie: you spend 95% of your time tinkering with it and the remaining 5% using it... if you're lucky.''
Not the way I see it. To be completely honest, that used to be the way I used Linux on my PC. Perhaps it used to be the way anyone used Linux on their PC. But it's not like that anymore. Nowadays, I use Debian, because:
1. It costs me less time in maintenance than any other operating system I have experienced.
2. If something doesn't work the way I want it to, or some functionality I want isn't there, I can change that.
3. I spend less time waiting for my system to complete a task then on certain other systems.
All of these improve my user experience and productivity compared to various alternatives. All this has been accomplished thanks to years of hard work by numerous people, who were allowed to perform that work, thanks to Debian being open source.
When a device runs open source software, that is a great plus to me.
First amendmend rights are a red herring. The fact that you have a right to say something doesn't make it a good idea to say it.
Publicity-hungry researchers trying to grab a few headlines also aren't the issue here.
The issue here is security. And that raises the question of who we are trying to protect. As far as I am concerned, we _should_ be trying to maximize overall security. I think the best way to do that is to protect the users of products. So, the question then becomes: What kind of disclosure yields the best security for users?
Unfortunately, the answer to that question depends on a variety of factors. I think the three most important ones are:
1. How will the vendor react to being informed of the vulnerability? 2. How will the users react to being informed of the vulnerability? 3. How will the black hats (bad guys) react to being informed of the vulnerability?
None of these questions can be answered generally. In particular, in general, you cannot know how the black hats will react, because you cannot know if the black hats were already aware of the vulnerability. If they weren't, you have just given them a new attack vector. This is a Bad Thing, and one of the most common arguments against full disclosure. On the other hand, if they were already aware of the vulnerability, you have just told them nothing they didn't already know. Since you can't know, in general, if the black hats already know of a vulnerability, it seems that full disclosure is a bad idea, overally. But that's if you only consider point 3.
Once you factor in points 1 and 2, the picture changes. The fact that you found a vulnerability is always interesting news to the vendor and the users. If they didn't know about it already, the vendor now knows that they have a problem that affects their users and that they need to fix, and the users know they have a problem that the vendor hasn't fixed yet, and that they should protect themselves against. If the vendor or the users did know about the vulnerability, they now know that _another_ person has found it, and that, perhaps, more priority should be given to fixing it and protecting against it. In case of full disclosure, everybody now knows for sure that the black hats know about the vulnerability, that they _will_ use it to attack systems, and that it _must_ be protected against and fixed as soon as possible.
Now, I am going to say a couple of things that aren't really factual, but that seem reasonable to me.
First of all, protecting yourself from vulnerabilities and getting them fixed is _always_ the right way to deal with vulnerabilities. Doing so as soon as possible minimizes the time you are vulnerable, and thus is a Good Thing. Not everyone realizes the importance of this. But, once a vulnerability has been announced publicly, you _know_ that the black hats know about it, so it is clearly risky to not protect yourself against it.
Secondly, in general, you will never make all users aware of a vulnerability. It may seem that a vendor could inform the users of their product of a vulnerability. However, vendors are notoriously reluctant to provide their users with information about vulnerabilities. If they provide information at all, it is usually not detailed enough to allow users to take protective measures, or comes long after the black hats have already started exploiting the vulnerability. Moreover, even the vendor will not know everyone who uses a product. And nobody can exclude the possibility that some of these users may be black hats, or that the information may leak to the black hats. Public disclosure at least gives every user of the product the possibility to inform themselves of a vulnerability.
Thirdly, historically, vendors have been reluctant to fix vulnerabilities unless they were publicly known. This is a Bad Thing, because the fact that a vulnerability is not publicly known does not mean it is not being exploited. Now, of course, vendors could change. And some of them have changed. But, hi
``Don't you hate it that you have to deal with this sort of thing because some other mail server isn't configured correctly?''
I do. But really, the problem is more fundamental. The problem is that email protocols do not reliably identify the sender of a message. If the message states it comes from "fred@example.com", it is assumed that it actually does come from this email address and that domain. Replies and bounces will then go to the MX for example.com and an attempt will be made to deliver them to the mailbox for fred. But really, "fred@example.com" is just a string anyone could have put there. It doesn't mean anything at all.
You are right, for some value of "doesn't work". The trick is in designing the system in such a way that it causes egoistic people to do things that are beneficial to others.
A free market does that, because it provides an incentive for you to produce what others want, so you can trade it for things they have that you want. And it provides an incentive for you to charge a reasonable price for it, because, if you don't, someone else will produce the same thing and trade it for less, and you will be left with a stock of things you have produced, but none of the things you wanted. In a way, it is very beautiful, because you get all this by doing nothing; that is, not imposing any rules.
However, the system is definitely open to abuse. Instead of producing the chairs that people want and trading them for the meat you want, you can produce a wooden club and threaten to beat people to death unless they give you meat. This is probably something that should be regulated. In a sense, without regulation, the system "doesn't work".
On the other hand, regulation can also cause problems. At a minimum, regulations are useless without enforcement, and enforcement diverts resources away from production, which reduces the efficiency of the system. Regulations can also actively reduce the efficiency of the system, for example, by disallowing certain exchanges. An extreme case of this could be found in many Eastern Bloc countries, where you basically weren't allowed to decide what to produce, who to sell it to, and in exchange for what. The result was that the incentive to produce was lost, there was a mismatch between what was produced and what was needed, and a vast amount of work went into enforcing regulations, rather than production.
I think there needs to be regulation, but there is good regulation and bad regulation. On the whole, I think Western countries have done a good job of enacting good regulation. There is some bad regulation as well (I am sure we all have our favorite examples), and some countries do a better job than others, but I think, at the end of the day, there is much production and little abuse.
Slashdot Mirror
Well, I must admit that I know next to nothing about the case. But if, as you assert, he didn't do any harm, then I reckon his punishment, if any, shouldn't be very harsh.
Actually, I'm curious how this is supposed to work. Aside from people always finding something to do, I really can't see why we couldn't be sitting by the pool. I mean, obviously, work still needs to be done. But if we get more efficient at that (e.g. by building machines that then do the work with fewer human hours involved), we _should_, on average, have more free time for a given level of prosperity, right?
``or [...] should be praised for finding security faults in what should be extremely secure systems.''
That one is really easy. Finding said security flaws is an accomplishment, but that isn't the issue here. The issue is what you do once you find them. You get praise for actions that lead to improved security (reporting them to the vendor, fixing them, reporting them to users, etc.). You get condemnation for exploiting them for selfish goals. Same as always: do something for the common good? Praise on you. Screw someone over for your own advantage? Damnation on you.
Ok, so no Flash. How about ROM? Surely, a ROM chip can last more than 25 years, especially if it isn't used during that time.
Why? What's so bad about AA batteries?
``I'm sure they'll still have AA batteries 25 years from now.''
And even if not, if you indicate the required voltage and polarity, I'm sure people will be able to figure out how to power it 25 years from now. I don't think our alphabets or units of electricity are going to change, and, even if they do, people will still know the old ones.
``I'm sure many /.ers will have a problem with this, but how else is wikileaks going to be able to defend themselves from lawsuits designed to shut them down through ridiculous, unpayable court fees?''
Well, Wikileaks provide a much needed way for whistleblowers to safely blow their whistles. This is an invaluable service, and should be judged as such by the courts.
The problem is, before there can be such a ruling, Wikileaks will have to pay a lot. This is a fundamental problem, and one that affects everyone, not just Wikileaks. There is something very wrong about being able to be ruined by the courts, without the courts actually ruling against you. That is something that needs to be solved.
Finding funds to pay whatever fees are necessary to actually win your case is no solution. Doing so through questionable means is worse. Isn't there any way Wikileaks can fight these legal battles, without needing money they don't have?
"In the Netherlands, the public administration, one of the most modern in the world, has decided to forbid the use of proprietary software in the public sector."
Actually, I don't think that is correct. What I know is that a motion has been passed that requires the government to consider alternatives, and give preference to open software when it is equally suitable. The government subsequently ordered a lot of software from Microsoft, without investigating alternatives. This stirred up some commotion, after which a motion was adopted that requires the government to carry out the previous motion. I don't know what has happened since then, but I don't think forbidding proprietary software actually happened.
I attack the problem at its root and have a whitelist of connectors I am willing to use. Anything that doesn't have such a connector, I don't buy. Everything I have that needs charging can be charged either with a universal adapter, or by taking out the batteries and putting them in a battery charger. Manufacturers who insist on making up their own proprietary and incompatible junk when there are existing standards available can stuff it.
You got modded funny, but I really think it is a good idea. And, as another poster suggested, we should think hard about making it usable. Perhaps something simple to be found first, which then contains instructions for getting at the actual wealth of data inside.
What do you use to get the video from the YouTube URL? I wrote a program for that a while back, but YouTube changed, and now my program doesn't work anymore.
``Only the FSF would remove functionality and consider that to be a feature rather than a bug...''
Actually, no. Less functionality means (ceteris paribus) less complexity. Less complexity has a very beneficial effect on various aspects; for example, security and learning curve.
I am happy when I can get systems with less functionality. Provided, of course, that they can still do what I need them to do. As Albert Einstein put it: make it as simple as possible, but not any simpler.
``If you are a student, you can see if your school offers zSeries courses''
If IBM is blocking access to their mainframe technology as rigorously as you say, I would object to universities offering courses on it. That is them helping lock the world into proprietary technology. No, thanks.
Aren't there any more open systems that have similar benefits to IBM's mainframe technology?
``Technology most of the time is really nothing more than a machine that takes advantage of some principle of nature, and is often very, very simple at it's core.''
You are right. But being simple at the core doesn't mean actually simple. At its core, software is just a bunch ones and zeroes. It couldn't be that complicated, could it? Now you go and write a real-time operating system, please.
It's very impressive that all the hardware is hot-swappable. Unfortunately, that doesn't mean you will never have downtime. You need the right software for that, too. It either needs to be hot-updatable, or you need redundancy. Redundancy is the more realistic...and if you have that, anyway, why do you still need 99.999999% uptime hardware? In the end, your uptime is determined by the weakest link.
``A small change in a source file will likely change everything following it in the encrypted version.''
Yes, of course. This is one of the main challenges. :-D
No, but I will. It looks like it could be very useful to me. Thanks for the pointer!
I'm working on a backup solution that allows people to back up their data to a remote server securely and efficiently. For "efficiently", think rsync: only the differences are sent (and some information necessary to identify what the differences are). For "securely", think assymetric cryptography: your backup is stored in encrypted form, so that only someone who possesses your private key can use it.
All this is currently in very early stages of design. I'd welcome any suggestions for protocols or software I could use. Currently, I am thinking to implement a transactional network block device protocol, and implement the backup protocol on top of that. I still need to decide on a programming language I can use for parts I need to write myself, too (something safe (no buffer overflows, please), yet with byte level access...and no Java or .NET, please).
By the way, this is going to be a commercial product, but the code and the protocols will be open. I'll charge for the storage and bandwidth. :-D
Spot on on both counts. SVG isn't a Flash competitor. And as for video...we have HTML for that which has worked since some time in the 1990s...there's no need to add Flash to that and break compatibility.
This is something I have recently been thinking about quite a lot. I am used to being able to easily debug software and watching what it is doing, and I had always considered logging as something you do because...well, I actually didn't really know why.
Now that I have done commercial development on larger project for a while, I have developed a somewhat better understanding of what you want logging for. I am still figuring it all out, but these are my current rules:
- Log event-related information. When your program receives input that causes it to start doing something, log that. If there is something strange or wrong about the input, log that. Once you stop processing (because you're done, or because you can go no further), log that. This way, you can see what your program has been doing. You can see that it received input (very important), you can tell if your program thought the input was correct or not, and you can see that it finished processing the input, and whether processing was successful or not.
- Provide for the option to log information about decisions your program makes. This is particularly useful for finding out why your program did not take action on something. This shouldn't always be enabled (unless, perhaps, for high-level decisions), because it would make logging overly verbose, but you should be able to enable it (preferably, focused on a specific part of the program) if you think the program is not behaving as it should.
- Last but not least, log every error condition. This should be obvious, but it is very important, so it's worth stating explicitly. You want to know if something went wrong, you want to know what went wrong, and you want to know where in your code it went wrong. Backtraces are very helpful here.
A large part of this is actually Cover Your Ass. If you log all events, and you didn't log anything, you can tell the Exalted User that the program didn't do anything, because it didn't receive anything from said user. If you validate input and log errors, even non-serious ones, you can tell the user "try with valid input", while you think about the problem and look through the code, seeing if anything is wrong on your end. If you log all errors, you can say "well, it says here there was a problem with the database connection, have a look at that", or "hmm, that value wasn't filled in, but should have been. are you sure you filled out all required fields?"
The above might sound disrespectful, but it really isn't. Very often, the users actually are doing something wrong, and they would be happy to know how they should do things to make it work, if only you could tell them. Logging everything you need to establish exactly where the problem is is invaluable for this. Your logging should tell you if the error lies inside your program or outside it. This makes your life easier, but your users', as well.
Finally, I will add that I very much agree with AaronLawrence's comment.
While I agree with you, it needs to be said:
Additionally by saying "He added that in such cases, the goal of those issuing gag orders often seems to be to further their own agendas
instead of helping others fix problems." shows a complete lack of understanding of market forces. Yes they are furthering his own agendas, and
in the process, they benefit us. It's the market you commie bastard, it isn't evil, we all win, get over it.
Acting in ones own interest doesn't always benefit the common good.
``However... what is it really good for? A phone? Because it really looks like the typical "you can run Linux on it" thingie: you spend 95% of your time tinkering with it and the remaining 5% using it... if you're lucky.''
Not the way I see it. To be completely honest, that used to be the way I used Linux on my PC. Perhaps it used to be the way anyone used Linux on their PC. But it's not like that anymore. Nowadays, I use Debian, because:
1. It costs me less time in maintenance than any other operating system I have experienced.
2. If something doesn't work the way I want it to, or some functionality I want isn't there, I can change that.
3. I spend less time waiting for my system to complete a task then on certain other systems.
All of these improve my user experience and productivity compared to various alternatives. All this has been accomplished thanks to years of hard work by numerous people, who were allowed to perform that work, thanks to Debian being open source.
When a device runs open source software, that is a great plus to me.
My thoughts:
First amendmend rights are a red herring. The fact that you have a right to say something doesn't make it a good idea to say it.
Publicity-hungry researchers trying to grab a few headlines also aren't the issue here.
The issue here is security. And that raises the question of who we are trying to protect. As far as I am concerned, we _should_ be trying to maximize overall security. I think the best way to do that is to protect the users of products. So, the question then becomes: What kind of disclosure yields the best security for users?
Unfortunately, the answer to that question depends on a variety of factors. I think the three most important ones are:
1. How will the vendor react to being informed of the vulnerability?
2. How will the users react to being informed of the vulnerability?
3. How will the black hats (bad guys) react to being informed of the vulnerability?
None of these questions can be answered generally. In particular, in general, you cannot know how the black hats will react, because you cannot know if the black hats were already aware of the vulnerability. If they weren't, you have just given them a new attack vector. This is a Bad Thing, and one of the most common arguments against full disclosure. On the other hand, if they were already aware of the vulnerability, you have just told them nothing they didn't already know. Since you can't know, in general, if the black hats already know of a vulnerability, it seems that full disclosure is a bad idea, overally. But that's if you only consider point 3.
Once you factor in points 1 and 2, the picture changes. The fact that you found a vulnerability is always interesting news to the vendor and the users. If they didn't know about it already, the vendor now knows that they have a problem that affects their users and that they need to fix, and the users know they have a problem that the vendor hasn't fixed yet, and that they should protect themselves against. If the vendor or the users did know about the vulnerability, they now know that _another_ person has found it, and that, perhaps, more priority should be given to fixing it and protecting against it. In case of full disclosure, everybody now knows for sure that the black hats know about the vulnerability, that they _will_ use it to attack systems, and that it _must_ be protected against and fixed as soon as possible.
Now, I am going to say a couple of things that aren't really factual, but that seem reasonable to me.
First of all, protecting yourself from vulnerabilities and getting them fixed is _always_ the right way to deal with vulnerabilities. Doing so as soon as possible minimizes the time you are vulnerable, and thus is a Good Thing. Not everyone realizes the importance of this. But, once a vulnerability has been announced publicly, you _know_ that the black hats know about it, so it is clearly risky to not protect yourself against it.
Secondly, in general, you will never make all users aware of a vulnerability. It may seem that a vendor could inform the users of their product of a vulnerability. However, vendors are notoriously reluctant to provide their users with information about vulnerabilities. If they provide information at all, it is usually not detailed enough to allow users to take protective measures, or comes long after the black hats have already started exploiting the vulnerability. Moreover, even the vendor will not know everyone who uses a product. And nobody can exclude the possibility that some of these users may be black hats, or that the information may leak to the black hats. Public disclosure at least gives every user of the product the possibility to inform themselves of a vulnerability.
Thirdly, historically, vendors have been reluctant to fix vulnerabilities unless they were publicly known. This is a Bad Thing, because the fact that a vulnerability is not publicly known does not mean it is not being exploited. Now, of course, vendors could change. And some of them have changed. But, hi
``Don't you hate it that you have to deal with this sort of thing because some other mail server isn't configured correctly?''
I do. But really, the problem is more fundamental. The problem is that email protocols do not reliably identify the sender of a message. If the message states it comes from "fred@example.com", it is assumed that it actually does come from this email address and that domain. Replies and bounces will then go to the MX for example.com and an attempt will be made to deliver them to the mailbox for fred. But really, "fred@example.com" is just a string anyone could have put there. It doesn't mean anything at all.
You are right, for some value of "doesn't work". The trick is in designing the system in such a way that it causes egoistic people to do things that are beneficial to others.
A free market does that, because it provides an incentive for you to produce what others want, so you can trade it for things they have that you want. And it provides an incentive for you to charge a reasonable price for it, because, if you don't, someone else will produce the same thing and trade it for less, and you will be left with a stock of things you have produced, but none of the things you wanted. In a way, it is very beautiful, because you get all this by doing nothing; that is, not imposing any rules.
However, the system is definitely open to abuse. Instead of producing the chairs that people want and trading them for the meat you want, you can produce a wooden club and threaten to beat people to death unless they give you meat. This is probably something that should be regulated. In a sense, without regulation, the system "doesn't work".
On the other hand, regulation can also cause problems. At a minimum, regulations are useless without enforcement, and enforcement diverts resources away from production, which reduces the efficiency of the system. Regulations can also actively reduce the efficiency of the system, for example, by disallowing certain exchanges. An extreme case of this could be found in many Eastern Bloc countries, where you basically weren't allowed to decide what to produce, who to sell it to, and in exchange for what. The result was that the incentive to produce was lost, there was a mismatch between what was produced and what was needed, and a vast amount of work went into enforcing regulations, rather than production.
I think there needs to be regulation, but there is good regulation and bad regulation. On the whole, I think Western countries have done a good job of enacting good regulation. There is some bad regulation as well (I am sure we all have our favorite examples), and some countries do a better job than others, but I think, at the end of the day, there is much production and little abuse.