OK I'm going to come up with a different angle of encryption for the Java clients. I think I may an idea which seems good, and will post for review. Since this is a rather difficult topic, I'm not immediately able to solve it. -Bob Dang ----- Original Message ----- From: ". ." <msucka0xff at programmer.net> Date: Wed, 24 Mar 2004 07:29:59 -0800 To: vanilla-devel at us.netrek.org, vanilla-clients at us.netrek.org,vanilla-metaserver at us.netrek.org Subject: [Netrek Clients] Add Java Key (Again) > Carlos, > I believe it is time again to ask to get the Java key back into the main key chain. The reason being that there are many benefits to using the Java programming language include the 3d graphics, and general client enhancement possibilities. The availability of a large development community, and a broad range of code libraries adds value to its proposition. As a distributed client that can demo netrek to new users from a webbrowser, it is unparalleled. There are certain features such as XML that provide proxy-server and firewall traversal without requiring adminstrative level adjustments. A further survey of the Java-Byte codes, the security model, and other mechanisms like Java to Native Interface can be explored to improve the prevention of client compromise. Also with a beta test group we can iron out the bugs. The primary concern of key compromise has been sufficiently addressed in the sense that the key is not exposed to reverse decompiling. The Java Keys are not exposed i > n the Obstrek observer client because they are not in the applet that runs on the users desktop, and the code is obfuscated making it especially difficult to create any borgs from this. Also since it runs in through a redirector, it is unlikely that anyone would want to create a borg. I think we can provide better solutions over time to this concern, but it really needs to move from a dead project to something that developers can continue to evolve. Also the issue of anonymous spamming can easily be fixed, and would improve as well. Here (again) is the java key. Please add it. I think most developers and people that play netrek would agree that there is real value of a Java based observer client and the security measures are sufficient and will continue to improve. I think for an early stage client, the acid test should be not immediately applied, since other early clients were given time to evolve, the same leeway can be taken for all due fairness. > -Bob Dang > > Obstreks-RSA-Key-Java1.4:ct=Obstrek:cr=msucka0xff at programmer.net:\ > :cd=March 2004:ar=Java1.4:cl=inl,standard2:\ > :cm=Java 1.4:\ > :gk=b1183209e283c57baac600b893e4457780d5dbe897e72271f8f4e275bc8bf725:\ > :pk=197118a5329b1f04917ce899df47dfba20017d2fa965e5f6e474d04cc5c14a25: > > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > _______________________________________________ > vanilla-clients mailing list > vanilla-clients at us.netrek.org > https://mailman.real-time.com/mailman/listinfo/vanilla-clients -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ vanilla-metaserver mailing list vanilla-metaserver at lists.real-time.com https://mailman.real-time.com/mailman/listinfo/vanilla-metaserver