Detailed project description
From The Okopipi Wiki
|
Note to reporters: The information contained on this wiki page is not official documentation. |
Too much to read? Check out the easier-to-digest project description.
Contents |
Introduction
This is just a bunch of ideas taken off of the CastleCops discussion thread as well as various other sources. This is by no means a representation of the majority. I just took all the ideas and tried to make them work together. In the future, this page should only be edited by the project leader.
Opting Out
Currently there are two proposals for opting out: Opting out as single e-mails or using a do-not-intrude registry.
Opting out as single e-mail
Opt out request can be a single hashed e-mail address. The request will indicate what algorithm is used to hash the email address. Spammers will have ten days to stop spamming those who have opted-out. Afterwards, they will be reported to the appropriate authorities. In any case, further opt-out requests will be performed if necessary.
- Note: the discussion on this topic has moved.
Using the Do-Not-Intrude Registry
The registery will likely be generated on-the-fly by periodically querying users and updating the list on the admin handlers. If this method is used, the registry will likely be stored and dowloaded via bittorrent. This is currently under heavy discussion.
- Note: the discussion on this topic has moved.
Users
authentication
Each user has a unique ID and must authenticate themselves by a hash and PGP signature. These signatures are obtained from the core cluster (see the network section below) via the handler servers. All data submitted must be signed by the user and must match a user list maintained by the handler server(s) that the user is assigned to (a full copy is kept at the core cluster). An unsigned or invalid data submission will be marked as a warning after a number of warnings, the user (IP?) will be banned and blocked for a predetermined time.
abilities
Users will only be able to submit a certain number of spams per hour. Once that quota has been reached, the user will have to wait for its next opportunity. If a server starts to get overloaded, it will impose a low-bandwidth mode which will limit or reduce the number of submissions per second (or per minute or hour) to prevent DOS'ing. Users will be allowed to submit opt-out links. These will be compared against the known links and problem spammers. If there is already a working opt-out link in existence, the new one will be ignored. All new links must be verified and accepted by one the staffers at the CO.
Network
servers
There will be no visible central server. Instead, there will be a core cluster of servers that have a high level of redundancy and security. Each core server will store all information, maintaining address and data about all known servers in the cluster, all known handling servers, new attack info, registered email address and reported spam. These servers will be inaccessible and undetectable to the public, requiring users to report spam to trusted handler servers which then sign and send the data up to the cluster. The cluster servers will reject connections from everyone except the handler servers which authenticate themselves by their IP and key. Handler Servers would be assigned one or more nodes from the cluster which gets regularly checked against a list maintained at the central cluster. Handler Servers would known some of the nodes of the core cluster, but top admins will be the only people to know the entire list. Handling servers and top admins are the only IPs allowed entrance into the cluster. Due to the high level of redundancy, nodes can be switched out / DOS'ed and the network will automatically reconfigure and heal itself.
clients
Client software will be assigned a set number of handler servers based on their geographical placement. The client software will attempt to connect to each server one by one until a connection is successful. After a connection is established, spam is reported and attack information, messages, and instructions are downloaded. Clients will download instructions on how to opt-out of the emails and then ask the servers to opt-out on its behalf. If it cannot contact the servers, it will use previously downloaded opt-out instructions to proceed instead of the servers.
Plugins
submission
Users can submit a script that deals with specific problematic spam sites. The script will be available for peer review by the Okopipi community. Members will suggest improvements and vote on its acceptance into the system. If accepted, it will be signed by an admin and distributed from the core cluster to the handling servers to the clients.
removal
Users can not only remove plugins but also submit requests for the removal of scripts from the network. This will come to a vote and if passed, the plugin will be removed. Grounds for requesting the removal of a plugin will be malicious scripts and also scripts that work on sites that no longer send spam. Users that abuse their voting privileges will have their voting rights revoked.
Security
authentication
All commands to clients from the CO (central office) will be signed with private keys. These keys will be managed at the CO. Two thirds of available private keys will be used to sign commands. Mechanisms will be in place that commands signed with a number of secret keys could revoke a compromised key. Clients will then be forced to synchronize the list of trusted keys with the copy kept at the CO.
management
The CO network will start with a very small group of individuals who are known to be trustworthy. These members will hold some of the secret keys and can induct a certain number of other members to join the CO. After these new members have proven themselves and a certain amount of time or events have passed, they will receive a secret key. If a CO member's key is compromised, that key will be revoked and the member will be stripped of his or her position.
