Network Access

[D'Lanor]

Sadly anything can be abused but should that stand in the way of progress? Saying no now probably means that we'll never see any kind of streaming content in Uru. And what about the KI pidgin plugin? Doesn't it require some kind of network access?

So maybe Python is not the safest way to establish network access but it is what's available now and I would like to further explore this to develop interesting content. For example members of GoMe have expressed interest in a newspaper age to deliver the latest news. Wouldn't that be cool?

[nathan2055]

Sadly anything can be abused but should that stand in the way of progress? Saying no now probably means that we'll never see any kind of streaming content in Uru. And what about the KI pidgin plugin? Doesn't it require some kind of network access?

So maybe Python is not the safest way to establish network access but it is what's available now and I would like to further explore this to develop interesting content. For example members of GoMe have expressed interest in a newspaper age to deliver the latest news. Wouldn't that be cool?

Yes, it would!

Points 2 and 3 apply to Drizzle as well.

No, because you need only trust one person: Dustin (me). And I've been doing this since the start of homemade Uru Ages, and obviously by installing Drizzle (like any software) they are trusting the software's author. The NetworkAccess package requires them to trust every Age author. And even if I weren't trustworthy, the only info I would have access to is that they installed a particular Age at a particular time, and not details about where and when they visited, nor who with, nor any other details about them that can be passed around by the NetworkAccess package.

And I can guarantee that not everyone in the community is trustworthy: there was an incident with a trojan designed to bring down other shards (and in particular Pelishard), made to look like a bug. (And it was entirely successful: Dhel and Mystler don't know the true cause to this day.) The only reason I was aware of this trojan was because the author told me they had created it with this purpose. (I think they thought I would be proud of them ) Fortunately, we got that person to revert it, and that version of their package is no longer on UAM. Now whenever there is an update to their package, I go over it with a fine-toothed comb, analyzing all changes to all the files before allowing it onto UAM.

Phew. Nothing to worry about unless I get that.

[Lontahv]

*Privacy: this is perhaps the biggest danger. Having NetworkAccess enabled allows any Age author to spy on you, and there is no way, even in principle, for you to distinguish malicious from non-malicious behavior.
might be considered abuse.

The last bit is only true if you believe you're being spied upon every time you visit a website.

The principle with which the web is built on in one way data transfer. Servers SERVE. Since the code needed for dynamic journals does not involve the requesting of cookies, the only data that is transferred to the server is that which is in the GET header. Just look on wiki and it will tell you that GET is considered a safe method because it:

should not have side effects, beyond relatively harmless effects such as logging, caching, the serving of banner advertisements or incrementing a web counter.

source

I find it very annoying when people try to scare new users into doing something that has the possibility of limiting their enjoyment of fan-made content. People should be given links to valid information on which they can form their own conclusions rather than being only subjected to the opinion of one individual.

[ddb174]

You're entirely wrong Lontahv. (For one thing, you can encode arbitrary information into a GET request as part of the URL; ask even an inexperienced web-dev.) Even if it were just limited to GET requests (it's not), and only used to get updates to journals when linking into the Age, even that small usage is enough to construct a list of what IP addresses were in what Age and when. And since you can get rough geographical location from the IP address, you can easily construct a map of who linked where and when, as well as what city they live in. And cross-indexing this little bit of information even lets you guess who went where with who, if a shard is foolish enough to have this enabled. And all this *just* from the simplest of uses! Yes, there can be similar privacy problems with websites, and that's a problem. In any event, there's no need for an offline game to violate your privacy. And I already know that such abuses have and continue to go on in this community, so it's a no-go.

The people who want NetworkAccess enabled by default seem to just be saying: "Yes it will violate your privacy, but there are worse things out there." So what? A person shouldn't say "Well, everyone else is bad, so I might as well be too" :P

If you want NetworkAccess enabled on *your* installation, you can easily do so.

[Lontahv]

So, basically you're basing the privacy issue completely on geographical location from an IP in your argument. I think you may have misread the part of my post that said:

The last bit is only true if you believe you're being spied upon every time you visit a website.

If you are in any doubt of this, please take the time to look at any Apache log and you'll see IP addresses, regardless of whether the clients are using Python HTTP modules from inside Plasma Boost or not.
You are correct in saying that having a socket module of any sort is somewhat of a danger, however, if limited to the current applications (getting text from http servers), there is a limited amount of danger. This is because opening a server-style port would involve activity that would automatically be blocked by the built-in windows firewall.

Saying that I am "entirely wrong" and saying I have less training than an "inexperienced web-dev" is considered ad hominem abuse, which is frowned upon on this board. In the future please try to debate ideas rather than belittling your opponent. Using these tactics puts your whole argument (even if it is a good one), in a bad light.

[Tsar Hoikas]

You're entirely wrong Lontahv. (For one thing, you can encode arbitrary information into a GET request as part of the URL; ask even an inexperienced web-dev.) Even if it were just limited to GET requests (it's not), and only used to get updates to journals when linking into the Age, even that small usage is enough to construct a list of what IP addresses were in what Age and when. And since you can get rough geographical location from the IP address, you can easily construct a map of who linked where and when, as well as what city they live in. And cross-indexing this little bit of information even lets you guess who went where with who, if a shard is foolish enough to have this enabled. And all this *just* from the simplest of uses!

I read this, and all I can think of is "So what?" I could easily put a Google script on this forum and get that information. In other words, you're sensationalizing the issue much like FOX News does. Wouldn't it be a better approach to establish a trusted framework for fetching updates from internet locations? (Or in my not-caring did I miss this?) If such a framework is in place, ages that do not utilize it or use other untrustworthy mechanisms can be barred from whatever age database we're using.

Just my $0.02

[Luna]

on a side note, your IP adress is visible for moderators/admins/etc. on some forums too.

Opening email involves a risk, downloading stuff involves a risk, going out on the street involves a risk. That does not mean you shouldn't leave your house(especially not in the case of fire) or destroy your internet connection, but it is good to be aware that there is a risk.

[diafero]

lets you guess who went where with who, if a shard is foolish enough to have this enabled.

Actually, your arguments apply even less to a Shard, which is by design connected to the net, so people know data is sent and most likely logged. Naturally, even the most basic technical logs Alcugs makes allow me to see who linked where when, if I had any interest in aggregating that. So, nothing new here, and nothing "foolish".

Wouldn't it be a better approach to establish a trusted framework for fetching updates from internet locations? (Or in my not-caring did I miss this?) If such a framework is in place, ages that do not utilize it or use other untrustworthy mechanisms can be barred from whatever age database we're using.

Sounds like a good idea - if it can be done so that age authors can easily and directly put their data into their part of the network/server/whatever.
However, we have to be careful that we do not end up with only a single server controlled by a single person being "trusted".

Just for the record: Deep Island has network access for fan-ages installed.

[Chacal]

Forgive these stupid questions, for I am only a security professional, not a Python programmer:

1- Does this thing let Python scripts included in the Age open a connection on any protocol? For example, can the script do this:
- open an FTP connection to a server on the internet and upload the contents of "My documents"?
- open an FTP or http connection to a server on the internet, download arbitrary code (exe or another Python script) and run this code?

2- Do Python scripts in Ages already have this capability, without needing this network access package?

[D'Lanor]

Yes, an age could download and execute code with this package. That is what Drizzle means when it speaks of a security risk.

However, it is easy to spot an age which uses this package, which btw consists of (or at least should consist of) modules already present in any standard Python installation (but not in the default Uru Python distribution). The Python code of such an age would show import statements for the modules from the network access package.
The question is, who should do be doing the police work of checking this? Should this burden rest on the shoulders of those who distribute fan ages? I believe that is where Dustin's concern comes in. I would not be surprised though if Dustin already scans for this and is flashing a warning sign only to tell us that we should not hold him responsible just in case something slips by him.

IMO an age builder who is making use of network access should notify the distributor (Drizzle, shard admins or Pahts assemblers) of this when the age is submitted for release. It may also be a good idea to have a wiki page with a list of ages using the network access package, explaining what they are using it for.