Trust & safety

Worlds was designed in 1995 and it shows in exactly the places you would not want it to. Two things about it are not opinions, not rumours and not about anybody in particular — they are in the protocol, and they apply to every server you will ever connect to.

1. An unmodified client runs code any server hands it

This is the big one, and almost nobody knows about it.

Worlds has a feature called WorldScripts: small Java classes that make a world do things. The client downloads WorldScript*.class files from whatever address is currently set as its content server, and passes them straight to defineClass. There is no signature check, no sandbox, and no prompt.

Those classes then run with your full user rights. Your files, your network, your machine. Any server — a hostile one, or merely one whose content host has been taken over by someone else — can run whatever it likes on the computer of everyone who visits it.

Note what that means in practice: you do not have to install anything suspicious for this to happen. A stock, untouched WorldsPlayer visiting a world is enough. It is not a question of whether a particular operator is trustworthy today; it is that the design gives every operator, and anyone who takes over their content host, that power by default and forever.

What to do about it

Use a client that refuses downloaded code unless you allow it. The modified client does — the server you deliberately connected to counts as allowed, everything else has to be permitted on purpose, and the original behaviour is still available but labelled for what it is.
If you are running the stock client, understand that visiting a world is trusting whoever controls that world's content host, right now, with code execution.

2. Your password travels in clear text

The protocol sends it in the clear during login. That is how it was designed and no change to any client can fix it — the server has to be able to read what the client sends, and there is no key exchange in the protocol to hide it behind.

Use a password you use nowhere else. Anyone on the network path can read it, and so can the server operator, on any server, always. A well-run server stores it hashed — which protects the account file, not the session.

The chat encryption in the modified client does not help here either, and it says so: it protects message contents between people sharing a passphrase, and it cannot protect a login that happens before any of that exists.

3. What a server operator can see

Worth stating plainly, because it is true of every Worlds server including ones run by lovely people:

They see	Because
Your IP address	you opened a TCP connection to them
Everything you type in public	the server relays it
Your whispers	whispers are routed by the server, not peer to peer
Your password	see above
Where you are and when you log in	that is what presence is

The modified client's chat encryption removes the middle two from that list for people who share a passphrase, and nothing removes the others.

4. Judging a client or a server you did not build

The general rule, which is not specific to Worlds: software you cannot inspect is software you are taking on trust, and a binary redistribution of a client cannot be checked against the original by looking at it.

Questions worth being able to answer before you run something:

Can I see what changed? A modification that publishes its patches can be verified by anyone who decompiles their own copy. One that ships only a built binary cannot be, by anyone, ever — that is not an accusation, it is arithmetic.
Does it need to run as me? Anything that asks for more access than "draw a world and open one socket" is worth a second look.
What does it do about the WorldScript hole? If the answer is nothing, then whoever operates the content server it points at has code execution on your machine.
Where does my password go, and is it reused anywhere? The correct answer to the second half is always no.

This project answers those the only way it can: the servers are source, the client modification ships as patches you apply to your own copy, and every patch is listed with the exact before-and-after text so you can check it yourself. It touches the client in seven places and each one only calls into its own package.

On accusations against specific people or services. Claims get made in this community about particular operators and particular builds. Anything of that kind that is not backed by evidence a reader can check themselves is not going on this page — not because nothing ever happened, but because an unverifiable accusation helps nobody and puts real people at risk. If you have documentation of a specific incident, bring it and it will be written up with its sources attached.

In the meantime the useful advice does not depend on who you trust: run a client that will not execute what it is handed, use a unique password, and prefer software whose changes you can read.