Trust - Split from: MOSS Test Shards

[Nalates]

You may want to split this off to its own thread... which is ok. I think it may fit here, so...

As we proceed some of the security issues from other places using open source will start to come up. Players will want to know who complied what and how to know which compiled executable they are downloading. There is really nothing to reference what code was used to compile a shard and client.

I haven't started reading code but I would assume the SSL keys make the MD5 and other hashes unique for each shard. If that is right I don't see how I can know that a CWE/client I am downloading is based on the code I can read in the repo. Is that correct?

For now it seems the only trust factor is the name of the shard owner. I can sort of deal with that and if it is all we have, we'll make it work.

For me the issue becomes having to know the shard owner. I know some of the bad apples and good peaches in the community. But, not all. So, that gives me some guide and I'll limit which shards I'll visit. But, for new people and those that hate drama and avoid the community politics it is going to be a risky place. They will have no clue who to trust.

So, is it possible to have something like an MD5 hash? IS there something we can do to provide some measure of safety assurance to users?

I think it would be part of the shard listings. That presents an updating issue for the wiki list... but I do think something is needed.

[branan]

You may want to split this off to its own thread... which is ok. I think it may fit here, so...

As we proceed some of the security issues from other places using open source will start to come up. Players will want to know who complied what and how to know which compiled executable they are downloading. There is really nothing to reference what code was used to compile a shard and client.

I haven't started reading code but I would assume the SSL keys make the MD5 and other hashes unique for each shard. If that is right I don't see how I can know that a CWE/client I am downloading is based on the code I can read in the repo. Is that correct?

For now it seems the only trust factor is the name of the shard owner. I can sort of deal with that and if it is all we have, we'll make it work.

For me the issue becomes having to know the shard owner. I know some of the bad apples and good peaches in the community. But, not all. So, that gives me some guide and I'll limit which shards I'll visit. But, for new people and those that hate drama and avoid the community politics it is going to be a risky place. They will have no clue who to trust.

So, is it possible to have something like an MD5 hash? IS there something we can do to provide some measure of safety assurance to users?

I think it would be part of the shard listings. That presents an updating issue for the wiki list... but I do think something is needed.

There's more to it than just the server keys and IPs - the exact versions of the 3rd party libraries and the compiler used also play a factor.

That being siad, the GoW team has added support for configuring server IPs and keys through a WDYS-encrypted ini file. The information on our wiki (and the libraries posted there) match exactly how I do my builds. I have the exact sources I used for that bundle of libraries available if anyone asks (though so far no one has). It should be possible for someone to exactly reproduce my build environment if they so choose, and create an exact duplicate of any executable I release.

For most people, though, this isn't a concern. We all know how well your average computer user handles security

[Mac_Fife]

Adding information on the public keys and IPs to the wiki list is no big deal if it helps people.

Although it'd be natural for most shard operators to make a client that matches their shard available for download, there's nothing that says some user can't truck up with their "own" client build and request the details to allow them to use that. And as more shards appear, then it'd be logical for the average user to want to avoid having seperate clients for every shard that they want to play on.

[DarK]

I can imagine eventually there will be a launcher which will make shard hopping simple, simlar to interfaces from times gone by .

Changes to the client can be made which make it universal in some respects and I am sure they will be welcome from a player point of view.

[Nalates]

I think one can look at SL and see how viewers (the client side) have developed. I expect we will see a similar set of preferences in our Uru community. I think DarK is right, players will appreciate it.

An often asked for feature is to add what we call grid (shards) hopping support. This is where the viewer remembers your ID and login for the target grid and has a section that allows one to supply grid connection data (developer does not have to track all grids the user can add their own). One can visit several grids/shards with the same viewer. Unfortunately that has a number of problems in SL/OS because of how caches and settings are handled. I expect the CWE to develop in that direction.

For now the shard's client is tied to a shard operator. So, I am probably overly concerned about ID'ing the CWE version for now. But, it leaves a security question as to what code they used to make a compile. And one does have to trust what they say. We've seen problems from people misrepresenting things in the past. I gather from Branan that creating a matching hash based on repo code is unlikely because of library and compile switches, and other differences in the local machine doing the compile.

Individual developers in SL do or don't include a security hash. Most of us ignore the hash and only download, say Kirsten's Viewer, from Kirsten's site. So, most of us operate on a matter of who we trust rather than knowing the code and checking a hash. Since a client would seem to be tied to the shard for now, the same personal trust is likely to be the preferred and adequate way to decide on safety, especially for the non techie.

The Emerald Scandal created quite an atmosphere of developer distrust in SL. I would like to head that off in Uru. Developers in SL are placing their code, libraries, and compile instructions in repo's of their own so people can see them and duplicate their compile and match their hash. Not something I ever bother to do. But in a large community there are enough that do.

When a client can connect to multiple shards and manage files for different shards, we may see the separation of the shard and client. That presents a whole new range of problems but those are future bridges. However, that will break the link to shard operators and clients may come from various developers.

It just seems that we need a way to establish trust. May be it is just figuring out how deal with these issues transparently. ...and may be it is too soon.

[semplerfi]

It just seems that we need a way to establish trust.

DING!

But how?

By making one's self vulnerable and see if you get your head chopped off? (a little humor & serious here)

Works but, comes with a price.

Who is willing?

[Mac_Fife]

I decided it was indeed best to split out this discussion, to leave the purpose of the other thread clear for anyone joining in fresh.

I don't put a whole lot of faith in hashes to verify downloads at the best of times, especially MD5s which have been shown to be poor in that respect: There are easily obtainable instructions on how to "adjust" a file to produce the same MD5 hash as some other file.

As Branan suggests, getting the build environment right is essential to getting the hashes to be comparable - Heck, I even found that the version of the MS DirectX 9.0c SDK I had on my PC (which came off an "official" CD some years back) didn't match the web downloadable version on MS' website, even though both reported the same version numbers .

So, for people who can't do their own build, i.e. most people, they're left with needing to "trust" whoever did the builds. You tend to "trust" a commercial entity like Cyan, because if they "harm" a user then it follows that it harms their reputation and their business. To some extent, the same will hold true for fan shards, etc.: If it becomes apparent that some shard or some client version is abusing it's users then it'll likely get dropped like a hot potato.

There's maybe a place for something like a "Good shard guide" or "Good Client Guide" to be published and maintained by one or more "trusted" bodies who could inspect shards or repeat builds and give some level of independent review. Semplerfi asks "Who is willing?" The most obvious suggestion might be the Maintainers, but equally,collective opinions from the wider community could be used, akin to the "customer reviews" that are so popular on online sales websites these days - Contrary to the suggestion in semplerfi's post, I suspect a lot of the fans in our community are quite prepared to stick their neck out and risk an axe. Meh! Anyone who's ever alpha or beta tested anything is used to taking that risk!

[semplerfi]

Who is willing?

Was a challenge!

No contrary and or not a negative put down.

If you look at my siggy you will see that ette (wife) and I are not afraid. My fanboy shard site, with around 75 shards explored, link is below.
http://www.jamercer.com/uu/semplers_shards.htm

Trying to see positive side of things is a good start to developing trust.

Let the Shard Hoppin' begin... and I'll see you on the Shards...

[MercAngel]

as i started to read i was thinking from the client side that having the public keys on wiki a good. but then i start thinking form the shard owner side and have info about the public keys was a bad. now i do not know how hard it is to extract the keys from the client but i think the normal uses would not be able to do that.

but the normal use may be able to write code and compile there own client. so with info on a shard public keys the could make a client that could harm a shard like bypassing the python.pak download and loading a local copy and i think most of the old Until URU shard owners know what can be done.

The one client fits all works great from the users side but from the server side this is got to be hard to pull off.

the only way i can see for this to work right now is for the server to read 2 sets of keys, one that the shard owner creates and one the comes form a source that every one can trust along with a compiled client form that same source.

[Nalates]

If one uses a public key to control access to the data then anyone can access the data. Whether you place the public key in a wiki or bury it in the code, people can retrieve the key and use it as they please.

If two key sets are used, it would seem you still have the same problem. Everyone is going to have the keys used in the CWE.

The current security system is just not very secure.