Let's say you're in a situation where you write code for others to use. You design APIs and code the underlying frameworks, and your goals have been to provide powerful tools that are easy for people to understand and use. Much like what I do for a living. :-P
Now let's say you're able to take a concept that's really hard and expose an easy, intuitive and powerful API for it. Normally, this would be a very good thing. You're making something accessible to the masses which they probably wouldn't have been able to use before.
Here's where the ethical question comes in: what if you just made it very easy to write malicious code? Would you still want to expose this API and give it out to users?
I bring this up because I've been toying with the idea of writing a RawSocket class for REALbasic in my spare time. But this provides people with the means to do some pretty scary stuff in a really easy way. For example, IP spoofing just became as easy as setting the .SourceAddress property on a socket.
I've already been working on an ICMPSocket class with Charlie (which is coming along really well and is almost ready for release!), and I'm a little scared about releasing that into the wild for much the same reasons. But raw sockets scare me even more than ICMP does...
So, oh wise readers... if you were in my shoes, would you release a library that is useful to about 1% of the population for constructive purposes, but useful to a much larger audience for malicious purposes?
I'm leaning on making there be some sort of application process. You know, email me and explain why you need this class, and I'll supply it to you. But I reserve the right to turn you down because I don't think you should have it. But the downside to that is I make legit people feel like criminals for wanting the classes...
Well as a certified gun nut I'm going to have to say that "code doesn't behave maliciously - people behave maliciously". I suppose it depends on whether you will feel responsible in that 'worst case scenario.' Beyond that simply consider the paucity of innovation and freedom if every technology had to pass the worst case scenario test. For example: thousands die in car wrecks due to poor/inattentive drivers... should we abandon the auto due to the wreckless abandon of a few? I should think not... Whatever you decide I agree that you should go with the "gatekeeper" system. What if someone gets through your extensive vetting process? There are lawyers out there that would argue that your culpability is lower if you simply make it available without vetting...
dim should as string
should=shouldn't
All the functionality is there in C, all you're doing is providing an easy way to access it in REALbasic. If someone was desperate enough to do it, they'd do it in C.
If you're worried about kiddies and idiots misusing it, just don't expose the 'SourceAddress' property for outgoing packets. Furthermore, hide how you do it in some complex memoryblock code or encrypt the class. Then, you can argue that anyone who finds their way round it is clever enough to have been able to do it in C anyway.
I'd personally love a raw socket in RB. Would it be just IP, or could we do raw ethernet broadcasts?
@Joe -- I agree, it's not that a gun (or raw socket) is inherently evil -- it's people's intentions. My issue is that there are constructive uses for many people with guns. Protection, hunting, etc. However, there is such a small percentage of the world that can use a raw socket for constructive purposes compared to guns. I liken raw sockets to things like C4. Yes, people can make it. People can buy it. But it's rare that it's going to be used for good purposes.
No vetting process is going to be fool-proof -- there's always ways around it. But I think I can at least sleep better at night knowing that I tried to stop people from doing bad things instead of just wiping my hands and saying "the code doesn't do bad things, it's people that make the code do bad things." That just seems too.... indifferent.
@Charlie -- it wouldn't be a straight port of the C APIs though. This would be an easier implementation. Kind of like how our TCPSocket is a much easier implementation than what you would need to do in C. And not putting functionality in strikes me as counter-productive. I want to make the class useful, and setting the source property is useful (even spoofing is useful -- I can use it to test whether my application disallows connections not on the local LAN without setting up a computer outside the LAN to do the test, for example).
I don't know whether I want to make it do IP only or use raw ethernet. I'm leaning towards IP since that's pretty easy cross-platform code. Doing ethernet requires 3rd party libraries to get around the myriad of platform differences.
Release it... information is powerful... VB used to get a lot of flack (and still does) because it was a favorite for script kiddies to quickly produce little hacks/virii to spread around...
and said.. How about.. a revolution...
@Jake -- Information *is* powerful, which is why I'm having ethical reservations.
Information is intangible and can be passed around indescriminately. But with information of how to build physical things (guns, nukes, bombs, etc) there's always a physical cost involved. You have to get the supplies to build these things from somewhere. So knowledge by itself isn't dangerous. But when it comes to computers, the barrier for entry is *much* lower -- you just need a computer (which everyone already has) and nothing more. So information on how to create "bad" things on a computer is much more dangerous because there's little or no barrier from information to production.
What I'm trying to figure out is what sort of a barrier to put in place to make the production harder for people trying to do malicious things without making people with good intentions feel like a criminal. Or whether such a barrier is even possible (or practical), or needed.
Not mentioning the destructive capability might be a sufficient barrier. The old "hidden in plain sight" trick. Honestly, I think that vetting sets the feature up as a *must have* simply because it's 'naughty'. I have no use for it but have this adolescent desire to get a hold of that baby... Come on Aaron - I'll be goooood! I proooooomise! No evil here just a juvenile desire to play with fire...
@Joe -- Interesting point. Making people ask for it draws attention to the fact that it's not something for everyone. But I've never been a big proponent of security thru obscurity, so I have a hard time convincing myself of your idea (though I do agree with your point).
I could do raw sockets now with declares right? I think it should be released. Just like in real life, anything can be a weapon. Should you also remove folderitem.delete?
-- SirG3
@SirG3 -- Apples and oranges on both your points. Doing it via declares is what provides the barrier for most users. Raw sockets aren't easy -- I'm proposing a way to make them easy. Making them easier means the weapon becomes more accessible to people who probably shouldn't be using it. As for FolderItem.Delete... that can only affect the local machine. I can't say FolderItem.Delete( SirG3's File ) and it goes out and does it. However, I can easily beat your computer to death with a raw socket (depending on the OS and the version of the OS) and then delete your files.
Keep in mind, that with RB an inexperienced programmer can make a very simple, and "harmless" looking application, that at some point, using a mechanism like applescript, email itself to your address book contacts, and proceed to delete your entire user directory without a users knowledge (unless he was really paying attention). At the end of the day, anytime you provide access to a systems capabilities, you expose risks. Personally, I wouldn't have any reason to use this feature, but I don't think reducing RB's power is the answer. Once you decide to go down the "censorship" route based on your (non-universal) morals and ethics, it's a very slippery path. If the option is available in the system, I believe RB should have access to it to.
@CR -- The ability is there (and always will be) to write your own raw socket code in REALbasic. So it's not a matter of limiting what the user can do. The question is, *should* I provide an easier way for the user to write malicious code than what's already available to them. Do I have a moral obligation to protect other people's machines?
This isn't a question of whether it's possible to do. You can already use REALbasic to write a virus. But REALbasic doesn't expose a Virus class for you to subclass and implement. That would be unethical, and people would undoubtedly complain (and rightfully so!) if we did expose a Virus class. How is a RawSocket class different? Perhaps a Virus class is a poor example -- a better one might be a Spam class. Some people view spam as a horrible thing, others view it as a viable marketing technique. Is it ethical to write a Spam class to make it easier for users to spam people?
There's no censorship involved -- they can still do it if they want to. It's a question of how easy should things be made?
Hi Aaron and All,
Your ethical question is common, but can unfortunately be answered by only one person.
The real question is do YOU believe it is going to make the world a worse place.
As a bit of an old time purist (ah the Sinclair ZX80 – things were simple then) , I hope you will look at the benefits to the good people rather than those who would use it for evil, but as a realist I say don’t do it. RB does everything it needs to for TCP (well for me anyway). To be honest I don’t even get the theory behind the RAW socket’s purpose, so what do I know. Just remember that for every true there is a false - i.e. is spam bad - YES, is it bad to use spam to find a missing childs parents - ethicaly Spam is bad, so is this too bad???
Best Regards
Damon
@Damon -- I think you hit the nail on the head, does the good outweigh the bad? There's a lot of grey area on this topic because there are great uses for raw sockets (I would use them for easier testing purposes to make sure things are functioning properly for example) as well as it allows you to write other functionality (cross-platform SCTP protocol, etc). Then again, I can crash your Windows 98 machine with 3 lines of code...
I'm a realist by nature, but I really want to be an idealist -- I want to believe that people will use it for good uses and there'll be some great things that come from it. But realistically, I can picture more script kiddies picking it up, grabbing a warezed version of REALbasic and writing stupid little hacks with it than people who use it to write an SCTP implementation.
The implication here (while not intentional) is that RB shouldn't be as capable as other programming languages. The slippery slope here is that you may help feed the idea that RB is just a "toy" language. If a legitimate purpose exists (thus nullifying the virus class as a viable parallel) then withholding any feature seems to imply that:
1)your nefarious customers lack the intellectual wherewithal to execute their evil plans
2)your cognitively savvy customers are more prone to moral terpitude.
3)your customers are both depraved and ignorant.
So which is it Aaron? Huh? Huh?
;-)
Dude I don't care what you say...we are putting a big screen television in the house...yeah I know i'll be the one to buy it...but still imagine the possibilities playing video games on it ::drools::
and of course movies
@Joe -- LoL, that's an interesting way of looking at things. :-) As for #1 -- the barrier for entry is high enough that the people who can understand how to do it typically aren't script kiddies, #2 wasn't an issue that I was imagining, #3 wellllll.... Just kidding! :-P
But you are right, legitimate uses do exist for this class (otherwise why would I want to write it in the first place?). They're just few and far betweeen when compared to the illigitimate uses it could be used for, which is why the question of ethics in the first place.
Unfortunately, everyone's brought up great points and I'm more confused now than when I started! I suspect I'll end up providing the classes without making people jump thru hoops to get them. But I may leave out the more devilish details in a public release and let it be known that if you need that functionality, you can ask me for it and I'll give you a set of classes that include it. This way people who want to use it for good purposes can use it without issue, people who want to use it for bad purposes still have to ask to get the good stuff (or understand enough to implement it themselves, which they could do anyway today), and people who have good reason to want the bad stuff can still get it without too much pain.
Hi, I thought I'd just make you an even 20. Want to see a movie with me Friday?
Here's a twist. I could really use an RB raw ethernet class to read (only!) some network traffic. Maybe it's less than 1/2% of us who need that capability, but would that pose a security issue?
It's certainly possible to do malicious things with that, but I'd be a lot more apt to write something like that and release it.
Btw, if you just need capturing abilities, you can use libpcap already with declares.