I signed up to hotmail simply to get access to one of their services that you can't use without a hotmail account. I selected the "don't send me any crap" option. I've never given than name to anyone ever. Yet, I get around 20-30 mails every day telling me that I have got a university diploma, or there's a hot girl waiting to just for me.
Aha. You're talking specifically about SOAP::Lite. That's a particular perl implementation of a form of SOAP. That particular bug is nothing to do with SOAP itself, just the way that this person has implemented it.
Using a normal SOAP message, on a properly secured web server, there is no way that you can call arbitrary methods of the server any more than you can call arbitrary methods of the server code behind an html web site.
There are security problems in this area (e.g., SOAP doesn't currently provide native services to allow you to turn on/off functions on an individual service based on user permissions), but these problems exist in html forms as well, and the current solution is the same - if you have a particular service that can be used by more than one role of user, with more than one set of permissions, then you have two different SOAP services. You CAN control the access to a particular service, and no-one gets access to a service that you didn't give them. You pass the name of the function in the SOAP header, and if it ain't on available on the services that you have access to, then it ain't going to get executed.
Another method is to put a bit of security directly into the service (e.g., through checking ACLs in the code). Not ideal, but not difficult.
Assuming either of these methods was used, and the SOAP service only offered a post method (and they didn't use the SOAP::Lite implementation), a Slashdot post service would not allow us to do anything more than post.
The post that I was responding to was the one with the statements
You're talking about the wrong kind of security. Think "bugs" instead of "encryption".
and
The difference is that SOAP and other web services add the extra abstraction layer that offers one more place for the developer(s) to screw up. And it makes it one step harder for a sysadmin or developer to find problems.T
This was, as I understanding it, claiming that additional security risks were being introduced because of the extra complexity of using web services. I don't get how having a site offering a cgi-generated web page is in some way more secure than one offering the same thing via web services.
The statement The issue is that SOAP exposes backend functionality to the end-user (or end-developer). is disingenuous. All (useful) web sites offer backend functionality to the end user - what else are they there for? I'm currently making use of slashdots backend database by posting this message. A SOAP service does nothing more than offer the same service via a mechanism that is easy for another application, rather than another user, to talk to. Assuming that the interface is properly designed, it should expose precisely no more functionality, and create precisely no more security issues, than the equivilant cgi-generated page. What extra security holes would there be is slashdot offered a "post your comments" web service?
Re:Design patterns and Lisp
on
Bitter Java
·
· Score: 1
I think you are missing the point of what a "pattern" is. It's nothing more than good practice to solve a particular problem. If, given a particular problem, there are two or more ways of solving it, then there's a good chance that one or other is better in a given situation. Patterns are just ways of describing what forces may lead you to use one or the other.
The phrase That kind of flexibility suggests that there is often more than one way of doing things in Lisp. How do you decide which one to pick? When is it a good idea to use macros etc?
Just because most of the patterns in the book "Design Patterns" may not apply to your language, don't think that the principle doesn't.
I've not used Lisp, but I've applied patterns in everything from x-86 assembler to unix shell scripts to SQL. The patterns vary per language (knowing when it is best to use an inner join in SQL is not much use in x-86), but each language quite clearly has its own "design patterns".
I would not want to work with any developer who seriously believes that patterns don't apply to his/her language of choice.
You server side system should be, but probably isn't doing any better a job than current Web based forms.
It's not just a case of doing a better job than the web based form. It's about checking the input in case someone has circumnavigated the form. This kind of server-side checking needs to be done whether you are working on a web-site or not. I insist that my developers have this kind of checking in their server code, and have reviews of the stuff that they develop partly to check for this kind of thing. Never trust the client application any more than you absolutely have to.
Most systems use a database driven method and combine it with user self-service for registration/authentication. Most professional web/application servers (e.g., WebLogic) provide pluggable security, where the server intercepts all calls and allows/prevents access to its resources(such as web pages), but delegates calls to an external module to actually do the checking of usernames/passwords/roles etc. These external modules can be linked into whatever security system you feel like using - lookup in database, LDAP, kerberos token etc. Usually there is no developer involvement in setting this up. You purchase the plug-in that you require to your security system of choice.
That's all well and good for creating the web client, but what about trying to integrate the service being offered into an external application?
For instance, I worked on a system a couple of years ago where we developed a sales/accounting system, and for one part we needed to go to an external vendor's web site and type in their details. Initially, this was done manually. We then automated it doing screen scraping. This meant ages spent writing the screen scraping code, and then altering it every time the redesigned the page. If this had been a web service, it would have simply been a case of calling it as a component within our overall system.
Web Services aren't designed with the intention on making it easier to build user accessable web pages. They are designed to make it easier to call the business functionality of an external system from an application.
SOAP is only part of the transport mechanism - specifically the application layer message protocol. It can use any transport binding that it wants (e.g., http,nntp,carrier pigeon).
A lot of people focus on port 80 specifically because they're planning on using a web server to also handle their SOAP traffic, and because they want to eliminate firewall issues.
That's their choice. They can do exactly the same thing with other services (e.g., WebLogic can have its t3 protocol broadcast on port 80, if you want to achieve this). It's not a feature of SOAP, its a feature of the developer's implementation.
All of the issues that have been dealt with in Web forms will reappear. Field type/length validation needs to occur, authentication, etc...
Your server side system should be checking for field type/length whatever source the data has come from. Relying on the client-side forms to guarantee the length/type of the field leads to buffer overruns - what happens if some hacker just types the url/params into the address bar in your browser?
And as for authentication, if you are broadcasting your web service using http or https, then the web server's authentication kicks in, in exactly the same way as if you were going via a browser. The request needs to pass the authentication details in the http header, just like a browser does.
SOAP exists (at least partly) as a languge-independent mechanism of performing remote procedure calls - allowing (for instance) a Visual Basic client to talk to java middleware without having to go through some kind of custom written munging layer in the middle.
There are other methods of doing this (e.g., XML-RPC), but SOAP was designed as an attempt to standardise the language (or at least the alphabet) for this kind of communication.
Most people seem to assume that SOAP (and Web Services in general) are all about exposing internal company functions to the outside world. The name Web Service is quite misleading, really, as the mechanisms that are used are extremely useful inside corporate networks where many different client applications need to talk to many different servers, and the use has absolutely nothing to do with firewall tunnelling.
I'm not sure what you're trying to say here. Are you saying that by creating components with clearly defined interfaces you are more likely to have errors than by building one big monolithic application?
Or are you claiming that it would be better for an external client application wishing to use the funcionality provided to use screen-scraping from the CGI output?
SOAP also uses the same port 80 (to sidestep firewalls)
Soap can use port 80 if it wants, but there is absolutely nothing stopping you having your SOAP server running on any port you want. There is nothing forcing you to even use http/https for the transport layer.
A SOAP message such as that in Example 1 may be transferred by different underlying protocols and used in a variety of message exchange patterns. For example, with a Web-based access to a travel service, it could be placed in the body of a HTTP POST request. In another transport binding, it can be sent in an email message (see section 3.2). Section 3 will describe how SOAP messages may be conveyed by a variety of transports.
There are security issues with SOAP, but this whole port 80/firewall thing is a red herring.
And if I insert cheddar cheese, I don't really expect the CD player to come up with a nice little box telling me it can 't read cheddar cheese.
True. But I also don't expect it to read the cheese, and attempt to execute it in a way that would break my computer.
If the cheese melted and gunked the computer up, that would be a different matter, but having the computer be able computer read arbitrary code and then break in an irrecoverable way is bad.
You probably own your own car. Does this mean that you are allowed to drive as fast as you want?
I suspect that technically they couldn't do anything to you for fiddling with the modem - like you say, it's yours. However, if you then use that modem to get more bandwidth than you are paying for, then that's probably theft (or something - IANAL).
It's not only the shops that don't believe in encryption. I recently worked on an electronic payment project, and we told the bank (Major UK high street bank, not saying which one) that we wanted to encrypt our connection to them. We were basically told "Don't be paranoid, no one does that. We don't accept encrypted links."!
Maybe you should read the books. There is nothing in XP against good design. What it isn't based on, however, is overdesign - attempting to design a system that will meet the (predicted) future requirements of the customer.
This issue of "hard" enginerring is clearly addressed. The point is that things like bridges, buildings etc, are not easy to alter once you have built them. If you find that the bridge was originally specified to be a footbridge and then the customer decides that what they really wanted was a road bridge, then it is very difficult to retrofit this new requirement. It has always been believed that software is the same - that changing it half way through is a very costly thing to do.
However, XP claims that with a good unit test harness, it should be, and in my experience is, very easy to change the underlying implementation of the code without breaking anything. You can't just rip out the entire ground floor of a building, but you can reimplement your decisioning code without the entire application falling down on you. This means that it becomes much easier to fit later requirements as and when they are needed. The XP project that I worked on had a major change to both the business requirements and, as a result, the whole way of interacting with an external system.
We had designed the package up front, but had designed it to do the requirements as they stood when we started. There was no suggestion to us of this other requirement at the start of the project, so no amount of analysis or clever design would have allowed us to code for it. However, once the new design was produced from these requirements, it was a trivial (1-2 days) task to recode several of the back-end classes to have the new flexibility in communication that was required (but with the same functionality). The unit tests allowed us to be confident that we had not broken anything. It was then another quick job to add the new functionaly, and we had a new working system.
None of this meant skipping design, or hacking. It just meant doing the amount of design that was appropriate at the time, and building a framework to allow us to change (hence "agile methodology") when requirements change.
I'm surprised it hasn't happened yet (or maybe it has and I haven't heard about it), but surely it won't be long before the RIAA and other anti-piracy groups get someone to start putting this sort of app onto P2P networks.
The problem is partly that estimation relies on previous experience of similar work. With a lot of software developments, the work is bespoke, in that the person/team has not produced anything similar before, and are solving problems for the first time.
I've also worked for places that basically knocked slightly different versions of the same system out for different companies. We were pretty good at estimating, because we'd done the same stuff before. But at the moment, I'm working on a system that is largely different to any project I've ever done before, so I have nothing to base my estimates on.
People often compare the software industry to builders, and point out that most houses are build (pretty much) on time and on budget. However, there is an interesting program on UK TV called "Grand Designs", where people design and build unique houses. Many of these people use experienced architects/builders but even so, most of them end up being well over budget and frequently late. This is usually because of some unforseen problem due to the uniqueness of the house. I think most software development that goes on is much closer to this type of building than the building of standard housing estates.
(2) If any person with the appropriate permission under Schedule 2 believes, on reasonable grounds-
(a) that a key to the protected information is in the possession of any person,
(b) that the imposition of a disclosure requirement in respect of the protected information is-
(i) necessary on grounds falling within subsection (3), or
(ii) necessary for the purpose of securing the effective exercise or proper performance by any public authority of any statutory power or statutory duty,
(c) that the imposition of such a requirement is proportionate to what is sought to be achieved by its imposition, and
(d) that it is not reasonably practicable for the person with the appropriate permission to obtain possession of the protected information in an intelligible form without the giving of a notice under this section,
the person with that permission may, by notice to the person whom he believes to have possession of the key, impose a disclosure requirement in respect of the protected information.
In other word, if they believe that your data is encrypted, then they can impose a disclosure requirement on you. Not supplying the key is an offence under the act. The only defence is to prove that the document isn't encrypted. This is one of the many problems with the act, that you have to prove that a random block of bytes that they have discovered on your hard disk is not really encrypted.
I agree with you about the amount of people posting that/. is crap, etc. They don't have to read the site.
But he does have a valid concern about bias. The site may be free, but it does have influence. A lot of people read the site, and (I suspect) are swayed by content on it. If the people running the site decide to present biased news, then this could have a significant effect on opinions within the IT community. In the same way, I complain about the biased news presented on TV and in the newspapers. I'm not complaining that I have wasted my money on a newspaper with junk news in (that's my option to buy/not but it), but I do complain when the media's spin on news controls public opinion.
On the other hand, however, I don't think there IS that much bias in/., I'm just pointing out that complaining about bias has nothing to do with whether you personally choose to look at the site or not.
If you are planning on patenting it so that when you offer it to some company to licence it from you, they don't steal it, then fine.
But if you are not planning on actually doing anything with it, then what would you want to patent something for? The only two purposes that I can think of are to be able to say "I've got a patent" to all your mates, or to stop anyone making it at all. And I don't think that there should be a mechanism in law that is designed with the purpose of stopping anyone at all making something useful.
Slashdot Mirror
I signed up to hotmail simply to get access to one of their services that you can't use without a hotmail account. I selected the "don't send me any crap" option. I've never given than name to anyone ever. Yet, I get around 20-30 mails every day telling me that I have got a university diploma, or there's a hot girl waiting to just for me.
Aha. You're talking specifically about SOAP::Lite. That's a particular perl implementation of a form of SOAP. That particular bug is nothing to do with SOAP itself, just the way that this person has implemented it.
Using a normal SOAP message, on a properly secured web server, there is no way that you can call arbitrary methods of the server any more than you can call arbitrary methods of the server code behind an html web site.
There are security problems in this area (e.g., SOAP doesn't currently provide native services to allow you to turn on/off functions on an individual service based on user permissions), but these problems exist in html forms as well, and the current solution is the same - if you have a particular service that can be used by more than one role of user, with more than one set of permissions, then you have two different SOAP services. You CAN control the access to a particular service, and no-one gets access to a service that you didn't give them. You pass the name of the function in the SOAP header, and if it ain't on available on the services that you have access to, then it ain't going to get executed.
Another method is to put a bit of security directly into the service (e.g., through checking ACLs in the code). Not ideal, but not difficult.
Assuming either of these methods was used, and the SOAP service only offered a post method (and they didn't use the SOAP::Lite implementation), a Slashdot post service would not allow us to do anything more than post.
The post that I was responding to was the one with the statements
You're talking about the wrong kind of security. Think "bugs" instead of "encryption".
and
The difference is that SOAP and other web services add the extra abstraction layer that offers one more place for the developer(s) to screw up. And it makes it one step harder for a sysadmin or developer to find problems.T
This was, as I understanding it, claiming that additional security risks were being introduced because of the extra complexity of using web services. I don't get how having a site offering a cgi-generated web page is in some way more secure than one offering the same thing via web services.
The statement The issue is that SOAP exposes backend functionality to the end-user (or end-developer). is disingenuous. All (useful) web sites offer backend functionality to the end user - what else are they there for? I'm currently making use of slashdots backend database by posting this message. A SOAP service does nothing more than offer the same service via a mechanism that is easy for another application, rather than another user, to talk to. Assuming that the interface is properly designed, it should expose precisely no more functionality, and create precisely no more security issues, than the equivilant cgi-generated page. What extra security holes would there be is slashdot offered a "post your comments" web service?
I think you are missing the point of what a "pattern" is. It's nothing more than good practice to solve a particular problem. If, given a particular problem, there are two or more ways of solving it, then there's a good chance that one or other is better in a given situation. Patterns are just ways of describing what forces may lead you to use one or the other.
The phrase That kind of flexibility suggests that there is often more than one way of doing things in Lisp. How do you decide which one to pick? When is it a good idea to use macros etc?
Just because most of the patterns in the book "Design Patterns" may not apply to your language, don't think that the principle doesn't.
I've not used Lisp, but I've applied patterns in everything from x-86 assembler to unix shell scripts to SQL. The patterns vary per language (knowing when it is best to use an inner join in SQL is not much use in x-86), but each language quite clearly has its own "design patterns".
I would not want to work with any developer who seriously believes that patterns don't apply to his/her language of choice.
You server side system should be, but probably isn't doing any better a job than current Web based forms.
It's not just a case of doing a better job than the web based form. It's about checking the input in case someone has circumnavigated the form. This kind of server-side checking needs to be done whether you are working on a web-site or not. I insist that my developers have this kind of checking in their server code, and have reviews of the stuff that they develop partly to check for this kind of thing. Never trust the client application any more than you absolutely have to.
Most systems use a database driven method and combine it with user self-service for registration/authentication. Most professional web/application servers (e.g., WebLogic) provide pluggable security, where the server intercepts all calls and allows/prevents access to its resources(such as web pages), but delegates calls to an external module to actually do the checking of usernames/passwords/roles etc. These external modules can be linked into whatever security system you feel like using - lookup in database, LDAP, kerberos token etc. Usually there is no developer involvement in setting this up. You purchase the plug-in that you require to your security system of choice.
That's all well and good for creating the web client, but what about trying to integrate the service being offered into an external application?
For instance, I worked on a system a couple of years ago where we developed a sales/accounting system, and for one part we needed to go to an external vendor's web site and type in their details. Initially, this was done manually. We then automated it doing screen scraping. This meant ages spent writing the screen scraping code, and then altering it every time the redesigned the page. If this had been a web service, it would have simply been a case of calling it as a component within our overall system.
Web Services aren't designed with the intention on making it easier to build user accessable web pages. They are designed to make it easier to call the business functionality of an external system from an application.
SOAP is just the transport mechanism
SOAP is only part of the transport mechanism - specifically the application layer message protocol. It can use any transport binding that it wants (e.g., http,nntp,carrier pigeon).
A lot of people focus on port 80 specifically because they're planning on using a web server to also handle their SOAP traffic, and because they want to eliminate firewall issues.
That's their choice. They can do exactly the same thing with other services (e.g., WebLogic can have its t3 protocol broadcast on port 80, if you want to achieve this). It's not a feature of SOAP, its a feature of the developer's implementation.
All of the issues that have been dealt with in Web forms will reappear. Field type/length validation needs to occur, authentication, etc...
Your server side system should be checking for field type/length whatever source the data has come from. Relying on the client-side forms to guarantee the length/type of the field leads to buffer overruns - what happens if some hacker just types the url/params into the address bar in your browser?
And as for authentication, if you are broadcasting your web service using http or https, then the web server's authentication kicks in, in exactly the same way as if you were going via a browser. The request needs to pass the authentication details in the http header, just like a browser does.
SOAP exists (at least partly) as a languge-independent mechanism of performing remote procedure calls - allowing (for instance) a Visual Basic client to talk to java middleware without having to go through some kind of custom written munging layer in the middle.
There are other methods of doing this (e.g., XML-RPC), but SOAP was designed as an attempt to standardise the language (or at least the alphabet) for this kind of communication.
Most people seem to assume that SOAP (and Web Services in general) are all about exposing internal company functions to the outside world. The name Web Service is quite misleading, really, as the mechanisms that are used are extremely useful inside corporate networks where many different client applications need to talk to many different servers, and the use has absolutely nothing to do with firewall tunnelling.
I'm not sure what you're trying to say here. Are you saying that by creating components with clearly defined interfaces you are more likely to have errors than by building one big monolithic application?
Or are you claiming that it would be better for an external client application wishing to use the funcionality provided to use screen-scraping from the CGI output?
SOAP also uses the same port 80 (to sidestep firewalls)
Soap can use port 80 if it wants, but there is absolutely nothing stopping you having your SOAP server running on any port you want. There is nothing forcing you to even use http/https for the transport layer.
To quote from section 2.1 of the SOAP standards
A SOAP message such as that in Example 1 may be transferred by different underlying protocols and used in a variety of message exchange patterns. For example, with a Web-based access to a travel service, it could be placed in the body of a HTTP POST request. In another transport binding, it can be sent in an email message (see section 3.2). Section 3 will describe how SOAP messages may be conveyed by a variety of transports.
There are security issues with SOAP, but this whole port 80/firewall thing is a red herring.
If you already own them all on CD, then why would you subscribe to the network?
And if I insert cheddar cheese, I don't really expect the CD player to come up with a nice little box telling me it can 't read cheddar cheese.
True. But I also don't expect it to read the cheese, and attempt to execute it in a way that would break my computer.
If the cheese melted and gunked the computer up, that would be a different matter, but having the computer be able computer read arbitrary code and then break in an irrecoverable way is bad.
You probably own your own car. Does this mean that you are allowed to drive as fast as you want?
I suspect that technically they couldn't do anything to you for fiddling with the modem - like you say, it's yours. However, if you then use that modem to get more bandwidth than you are paying for, then that's probably theft (or something - IANAL).
It's not only the shops that don't believe in encryption. I recently worked on an electronic payment project, and we told the bank (Major UK high street bank, not saying which one) that we wanted to encrypt our connection to them. We were basically told "Don't be paranoid, no one does that. We don't accept encrypted links."!
If you want to help people write better code then I'd suggest that you don't use variable names like arl and arl2.
Maybe you should read the books. There is nothing in XP against good design. What it isn't based on, however, is overdesign - attempting to design a system that will meet the (predicted) future requirements of the customer.
This issue of "hard" enginerring is clearly addressed. The point is that things like bridges, buildings etc, are not easy to alter once you have built them. If you find that the bridge was originally specified to be a footbridge and then the customer decides that what they really wanted was a road bridge, then it is very difficult to retrofit this new requirement. It has always been believed that software is the same - that changing it half way through is a very costly thing to do.
However, XP claims that with a good unit test harness, it should be, and in my experience is, very easy to change the underlying implementation of the code without breaking anything. You can't just rip out the entire ground floor of a building, but you can reimplement your decisioning code without the entire application falling down on you. This means that it becomes much easier to fit later requirements as and when they are needed. The XP project that I worked on had a major change to both the business requirements and, as a result, the whole way of interacting with an external system.
We had designed the package up front, but had designed it to do the requirements as they stood when we started. There was no suggestion to us of this other requirement at the start of the project, so no amount of analysis or clever design would have allowed us to code for it. However, once the new design was produced from these requirements, it was a trivial (1-2 days) task to recode several of the back-end classes to have the new flexibility in communication that was required (but with the same functionality). The unit tests allowed us to be confident that we had not broken anything. It was then another quick job to add the new functionaly, and we had a new working system.
None of this meant skipping design, or hacking. It just meant doing the amount of design that was appropriate at the time, and building a framework to allow us to change (hence "agile methodology") when requirements change.
I'm surprised it hasn't happened yet (or maybe it has and I haven't heard about it), but surely it won't be long before the RIAA and other anti-piracy groups get someone to start putting this sort of app onto P2P networks.
I quite regularly compile Java 2 apps on Windows and run them on HP-UX. What problems have you been having?
The problem is partly that estimation relies on previous experience of similar work. With a lot of software developments, the work is bespoke, in that the person/team has not produced anything similar before, and are solving problems for the first time.
I've also worked for places that basically knocked slightly different versions of the same system out for different companies. We were pretty good at estimating, because we'd done the same stuff before. But at the moment, I'm working on a system that is largely different to any project I've ever done before, so I have nothing to base my estimates on.
People often compare the software industry to builders, and point out that most houses are build (pretty much) on time and on budget. However, there is an interesting program on UK TV called "Grand Designs", where people design and build unique houses. Many of these people use experienced architects/builders but even so, most of them end up being well over budget and frequently late. This is usually because of some unforseen problem due to the uniqueness of the house. I think most software development that goes on is much closer to this type of building than the building of standard housing estates.
Or, of course, your phone is.
Yes we do. BT Together for example.
And as for unmetered access - my Cable Modem is £20/month totally unmetered.
I do agree with your point about considering the non-US world, though.
Unfortunately that doesn't help.
(2) If any person with the appropriate permission under Schedule 2 believes, on reasonable grounds-
(a) that a key to the protected information is in the possession of any person,
(b) that the imposition of a disclosure requirement in respect of the protected information is-
(i) necessary on grounds falling within subsection (3), or
(ii) necessary for the purpose of securing the effective exercise or proper performance by any public authority of any statutory power or statutory duty,
(c) that the imposition of such a requirement is proportionate to what is sought to be achieved by its imposition, and
(d) that it is not reasonably practicable for the person with the appropriate permission to obtain possession of the protected information in an intelligible form without the giving of a notice under this section,
the person with that permission may, by notice to the person whom he believes to have possession of the key, impose a disclosure requirement in respect of the protected information.
In other word, if they believe that your data is encrypted, then they can impose a disclosure requirement on you. Not supplying the key is an offence under the act. The only defence is to prove that the document isn't encrypted. This is one of the many problems with the act, that you have to prove that a random block of bytes that they have discovered on your hard disk is not really encrypted.
I agree with you about the amount of people posting that /. is crap, etc. They don't have to read the site.
/., I'm just pointing out that complaining about bias has nothing to do with whether you personally choose to look at the site or not.
But he does have a valid concern about bias. The site may be free, but it does have influence. A lot of people read the site, and (I suspect) are swayed by content on it. If the people running the site decide to present biased news, then this could have a significant effect on opinions within the IT community. In the same way, I complain about the biased news presented on TV and in the newspapers. I'm not complaining that I have wasted my money on a newspaper with junk news in (that's my option to buy/not but it), but I do complain when the media's spin on news controls public opinion.
On the other hand, however, I don't think there IS that much bias in
If you are planning on patenting it so that when you offer it to some company to licence it from you, they don't steal it, then fine.
But if you are not planning on actually doing anything with it, then what would you want to patent something for? The only two purposes that I can think of are to be able to say "I've got a patent" to all your mates, or to stop anyone making it at all. And I don't think that there should be a mechanism in law that is designed with the purpose of stopping anyone at all making something useful.