137 replies to this topic

[KaoS]

Sebra, on 01 December 2012 - 12:57 AM, said:

problems with trust. -> less fun

I d'no about that, that is what PvP is for, if you want a friendly server that is great (I think you should be able to choose that) but factions and Pvp bring a lot to the game, competition man: it rocks

[Cloudy]

Sebra, on 01 December 2012 - 12:57 AM, said:

Oh, I'm afraid developers going to break working things
Now it is impossible to protect computers from external startup Soon no link will be safe
Do not force other players to play the way, you want. Crypto-programs is unneeded load for servers and problems with trust. -> less fun

You mean, rednet isn't broken already? Someone would STILL need to guess which frequency you were using - and if you're clever you can cycle frequencies. Broadcast is a broken concept that isn't needed with these changes. I'd prefer it was removed altogether, but it all depends on how Dan wants to do things. We may add ports protected with a password for example - it just depends.

Besides, even basic Crypto (or just not making the message human readable for control systems) would suffice. Crypto can be done quite fast, with the addition of Java native binary operators which we have already added.

JJRcop, on 30 November 2012 - 09:17 PM, said:

Cloudy, can you tell us if this may be optional or not? We would really like to know.
I would personally prefer it to not be optional.

I don't know. And stop it with the annoying hidden text. Protip - it isn't hidden on mobile devices, or once you're quoted.

[Sebra]

In my opinion vulnerability in connection, needed to be attacked and protected, is not a good thing for connection itself. Adding it will shift attention from creativeness to confrontation.
I think worst thing in rednet now is unability to use any peripheral except modem. Allow it so people will be able to make rednet peripherals.
Now rednet remember side for each id. It would be broken if message source unknown.

[Cloudy]

Sebra, on 01 December 2012 - 08:51 AM, said:

I think worst thing in rednet now is unability to use any peripheral except modem. Allow it so people will be able to make rednet peripherals.
Now rednet remember side for each id. It would be broken if message source unknown.

Yes, because something that isn't a modem needs to have modem capabilities. Makes sense.

We may open it up to others in the future, we may not.

[KillaVanilla]

Sebra, on 01 December 2012 - 08:51 AM, said:

In my opinion vulnerability in connection, needed to be attacked and protected, is not a good thing for connection itself. Adding it will shift attention from creativeness to confrontation.
I think worst thing in rednet now is unability to use any peripheral except modem. Allow it so people will be able to make rednet peripherals.
Now rednet remember side for each id. It would be broken if message source unknown.

Or perhaps it will shift the attention to creative confrontation.

One of the main things that makes a game fun is how challenging it is.
A game is no fun if you can just zip through without a care in the world about how you're going to run things.
Also, what purpose would another rednet peripheral serve?

[CoolisTheName007]

But...but...argh, I can't code networks like this! One day everyone has an unique way to prove it's identity (by receiving the ID of the sender no matter what) and now 'everything' wants to change...Had just started coding routing protocols and now I must go through the trouble of security... Please consider that reliable authentication will be an extra burden on the processor. I will proceed to cease activity on networking until there's...well, I know no one has to promise anything, but, comm'on, some projects rely heavily on the present state of things.

[GopherAtl]

unless I'm mistaken, you would still get the id of the sender as the first parameter, not the frequency, so you would still know who sent the data, you just can't be sure others aren't listening in. Unless you're sending passwords or account information, it's not an issue. If you are.. start researching cryptography I guess XD

[Pharap]

Personally I see the frequency thing as more of a convenience for less experienced players and lazy players.
Whether it's a benefit or detriment to security is irrelevant. Sure you'll always have users who want maximum security and you'll always have players who like to be able to break security.

But what of the beginners who aren't experienced with programming or encryption?
Yes this mod is designed for programmers, but by the same token, it should be a 'pick up and play' mod that can be used without needing masses of programming +knowledge. Ultimately, being advanced with programming will still be an advantage because you can do more, but some people want to use this mod but just can't be bothered to learn to program. It's like real world computers, you can send emails and play games and all that without knowing how to program, or you can learn to program and make some of your own tools to use (much like indie gamers and open source software developers).

Without the frequency system, you have to keep track of who you do and don't want to send the messages to, which while being secure, can be difficult for beginners and time-consuming for the lazy. With frequency systems, beginners will see it as being easy and be more inclined to use the mod and lazy programmers won't have to keep retyping the same code every time they go to a different CC server. It is less secure as people can listen in, but generally hacking is against server regulations, and on the ones it isn't, it adds a reason for people to develop security systems even further. Making it optional will of course ensure that people (and servers) don't have to use it, but the option is always there, just like with the fuel divide.

[Sebra]

KillaVanilla, on 02 December 2012 - 10:53 AM, said:

Spoiler

Sebra, on 01 December 2012 - 08:51 AM, said:

In my opinion vulnerability in connection, needed to be attacked and protected, is not a good thing for connection itself. Adding it will shift attention from creativeness to confrontation.
I think worst thing in rednet now is unability to use any peripheral except modem. Allow it so people will be able to make rednet peripherals.
Now rednet remember side for each id. It would be broken if message source unknown.

Or perhaps it will shift the attention to creative confrontation.
One of the main things that makes a game fun is how challenging it is.
A game is no fun if you can just zip through without a care in the world about how you're going to run things.
Also, what purpose would another rednet peripheral serve?

1.War is reason for most inventions, but still very bad thing.
2.Yes, but challenge to create some beauty is better than challenge to break some. You already able to hack any CC comp, you have access. You want just wireless way to do it.
3.If your "zip through" means "break anything" then I'm sorry about you.
4.LAN cables, WR inter-dimensional modems (if Chicken Bone add it you get frequencies also), inter-MC-world communicators ... Use constructive creativeness, not destructive.

[Pharap]

KillaVanilla, on 02 December 2012 - 10:53 AM, said:

Or perhaps it will shift the attention to creative confrontation.

One of the main things that makes a game fun is how challenging it is.
A game is no fun if you can just zip through without a care in the world about how you're going to run things.
Also, what purpose would another rednet peripheral serve?

'Creative confrontation' is no good unless both parties are willing, otherwise it becomes a game of 'beat someone up, watch them leave the server in despair' or 'beat someone up, get kicked off the server'. Also, I find it hard to believe that the majority of the people on this server would use frequencies purely as a way of causing grief to other players.

I beg to differ, the whole idea of sandbox is to have fun without there being an actual goal and without having to worry about things like taking damage or getting hungry - you can do whatever you like without having to worry about 'how you're going to run things'.

[KaoS]

@Pharap I prefer the case of 'beat someone up, get away with it'

[Cloudy]

Nothing is set in stone. Work hasn't even STARTED on rednet modifications - but I definitely want broadcast to die. By die I don't mean crash programs - I mean "don't send to every computer and it's mother".

I think you're all exaggerating the security concerns - before someone can listen on your frequency they have to know it first. This is not a way to cater to users laziness - lazy users already use broadcast which has absolutely no security whatsoever.

I will however take people's concerns into account when me and dan are designing this feature. Maybe we'll add a way to secure your channels, maybe we won't.

[BigSHinyToys]

local function broadcast(message)
	for i = 1,channels do
		 rednet.send(i,message)
	end
end

... and even before broadcast is removed it is bypassed.

The current method of rednet messaging is simple adding additional problems to connectivity will force a standard of some kind to be formed for secure network traffic. This could both be seen as a good thing and a bad thing. servers with low hardware specks will not run as well if all computers are running encryption / decryption on every packet. personaly being able to capture all traffic and analyze it will be a fun activity. compromising systems by broadcasting Spam on one channel could be by passed by having the program just channels if there is to much activity. I'm kinda iffy about this will have to wait and see how the exact implementation is and if all programs are broken.

[ChunLing]

Maybe rednet.send(nil,message) could cause the message to only travel the minimum range (like during a thunderstorm). You could have something like interference so that the number of discrete rednet.send()'s from a given modem in the current tick would each degrade the effective altitude by 1, so by the 255th message in a single tick the range would be the same as for sending from bedrock or during a thunderstorm.

That would mean that the limitation wouldn't be too easy to bypass, but wouldn't overly affect intelligently designed systems that avoided spamming.

[CoolisTheName007]

In general, one needs:

send(group of computers, msg)
setListenTo(group of computers)

where 'group of computers' can be defined in many ways, e.g. a table of computer ID's, a frequency, a range; a pair (frequency, password), ect.

We have several factors at play here:
-efficiency
-security
-ease of use
-realism

In terms of efficiency, by sending messages to the desired target exactly:
- a substitute of broadcast() that restricts itself to a subgroup of computers (maybe determined by those listening for a frequency, as suggested) would allow better neighborhood detection;
- for simple computer A to computer B communication, with send(freq,msg) and listen(freq,msg) one would have to set up a frequency for each pair of computers. This is not difficult, but:
- listening for different frequencies is then necessary if we are to have computers listening to their neighbors. So I would still prefer to have send(id,msg); however, if a computer is hosting more than a network, e.g. it's a gateway linking two networks, it needs to listen to different broadcasts, and consequently different frequencies, at the same time. at least listening for 2 frequencies should be allowed.

To conclude, I would prefer having:
broadcast(freq,msg)
setFreqToListen(set of frequencies)
send(id,msg)
so that a message is sent either if:
-there was a broadcast in a frequency set by setFreqToListen(set of frequencies);
-there was a direct message by send.
'rednet' event parameters would have to distinguish between frequencies and direct sends, and also pass the id of the sender.

There is a loss of realism here: every computer has already a unique id and it is passed through messages, but, also, every computer may be forced to listen to a limited amount of frequencies, which in my opinion is unrealistic.
I recognize that some people might find it fun to find security solutions for authenticating ID's and ect. It is entirely a matter of opinion whether or not to sacrifice efficiency, ease of use and security for the sake of realism. Either one may lead to interesting programs, but IMO considering that the main bulk of ComputerCrafters are not expert programers, I would prefer the first one.

In terms of security:
- there would be little originality here: encryption. Instead of just increasing server load with it, why not to abstract it in the java side:
assuming there's a get_key(id,freq) function implemented Lua side and passed to rednet for each computer:
send/broadcast(id/freq,msg,key) would , for each target in range and matching id/freq, pass the message if key==get_key(id,freq) of the target.

Replies:

ChunLing, on 03 December 2012 - 02:36 AM, said:

You could have something like interference so that the number of discrete rednet.send()'s from a given modem in the current tick would each degrade the effective altitude by 1

This would limit speed in transmissions, not sure if it would be enough for networks or terminal redirection.

[Sebra]

What is wrong with broadcast? If you know receiver ID, use it. If not - use broadcast.
Broadcast definitely needed for GPS. You do not need to know host's ids.

I do not need really to hide my messages. Most wanted feature for me is reliable sender id. Let anyone decipher anything as long as I can filter out enemy commands.

If you allow rednet to use any peripheral (with methods "open", "send", "receive", "close"), you can apply frequencies to modems only by adding optional "setup" method. In "setup" method any specific options can be tuned. You can set output frequency, input frequency diapason, transmission speed if you want... More input frequency diapason means less range. Less transmission speed means more range but delivery delay. Each peripheral can treat "setup" as it want, frequency for modem only.

edit: found an error in my post plus short answer.

@PixelToast So real need is to try to isolate your input from spammed channel, not to enable hacking and encourage cryptowars.

And yet another idea to look:
Use string as a channel id. Modem should receive messages iv receiver tuned with substring of transmitted channel. For example modem, tuned with "PixelToast" would recieve messages on "PixelToast 1", "PixelToast going to win", but not "GPS" channel. To receive all channels you can tune receiver with "".

Edited by Sebra, 03 December 2012 - 07:27 AM.

[PixelToast]

Sebra, on 03 December 2012 - 04:30 AM, said:

What is wrong with broadcast? If you know receiver ID, use it. If not - use broadcast.
Broadcast definitely needed for GPS. You do not need to know host's ids.

and thats why you need frequencies
each program will have its own frequency
so anyone who does not want to receive those annoying ping messages dont have to

[CoolisTheName007]

Sebra, on 03 December 2012 - 04:30 AM, said:

What is wrong with broadcast?

Efficiency: everyone in range of the broadcaster will get a new event in their event queue; that means, java side, that a lot of coroutines, each representing a computer waiting for an event, will be woken up. By using frequencies, you wake up exactly those who want to hear the broadcast.

Security: the main issue it that you want a set of computers S to be able to communicate without any external interference from other computers.
One solution is to keep a whitelist, a list of the computers in S, in each computer of S. Now that I think about it, it wouldn't be difficult to keep a whitelist in a large network if the network was divided in smaller networks, each with it's whitelist, and there weren't connection issues. However, imagine a computer wants to move from a network to another. It would have to know where it would be next, and inform the corresponding subnetwork.

I think that a realist, safe, easy to use, and lag-free system would be the one I described previously, but without the possibility of sending directly to an ID. Why not send the ID? Well,
-it's superfluous, since after sharing keys, computer A should trust computer B to send it's ID in the rednet message;
-the ID's existence it's a 4th wall breaker, and here is a chance to reduce their importance.
Zebra remembered me that send(id,msg) is essential; so:

send(id,msg) would be just like the normal send.

broadcast(freq,msg,key) would:
-first check range;
-then check if @freq is in the target listening frequencies (one frequency only would not allow a computer to participate in two networks at the same time; listening to two frequencies would be enough)
- then it would call get_key(@freq) (or access a previously set key for that frequency) from the target and check if it matched @key
- if yes, it would queue a rednet event to the target event queue with the parameters @freq, @msg, distance.

IMO, the question remains whether or not send() should return false in case the message isn't delivered. It isn't difficult to implement a handshake, such as send(id,msg), wait(timeout, id=id,msg=='i got it'), what got me thinking that maybe that should be done in Java too. It would reduce network traffic caused by handshakes.
Some may say that, if it send does provides that information, an attacker could iterate over the possible keys and know when it got to the right one by getting true from send(). But that's very unlikely to happen: on CCEmulator, I took some measurements and got an upper bound of 10^8 operations per second. Now, imagine your key is a 10 char string, each one is a byte. That gives (256)^10/10^8~10^19 seconds to check all combinations. That is, 317097919 millenniums Sure, this isn't the same as the expected time to get the right answer, which is at least the number of combinations/2 and which I've sampled with this code:

j=tonumber(...)
s=0
for i=1,j-1 do
s=s+i/(j-i)
end
print(s)

So, my opinion is that there are some procedures in real-life networking that I would rather skip in ComputerCraft, because:
- they are both non-original and have standard implementations;
- they can be simulated in the Java side much more efficiently, consequently reducing server lag.
- because they are simulated exactly as they happen in real-life, e.g. both low processing cost and behavior, we keep the experience realist.

[Sebra]

@CoolisTheName007
So effectively you want _only_ broadcast but with divided networks. It works against your efficiency thesis.
Also "without the possibility of sending directly to an ID" works against security thesis too.
Forced encryption do not fit in "Ease of use" unlike sending to ID.
Realism? Look for it outside the game. Why you call it "frequency"? Who can measure it?

As I said rednet uses sender id internally for routing needs. You want to break it. And all it just to allow hacking and force all CC users to cryptography.

[CoolisTheName007]

Sebra, on 03 December 2012 - 10:05 AM, said:

snip

Your comment is in general incompletely justified, but did remembered me that I forgot that send(id,msg) is essential for efficiency. I will include it in my post. Thanks!