OFFSystem

History

OFF development started within the hacktivism group The Big Hack in 2003 by the hackers Cheater512, CaptainMorgan, Aqlo and WhiteRaven. In 2004, a rudimentary version was finished, written in PHP, which was distributed as two demo CDs. Following these, SpectralMorning re-implemented the functionality in 2004 in C++, which led to the current "mainline" OFF client.

On August 14, 2006, CaptainMorgan posted a letter of "closing" addressed to the "Copyright Industry Associations of America", such as the RIAA and MPAA, stating that they have created OFF with the purpose of ending "all of your problems with consumer copyright infringement."

In 2008, the network consisted of around 50 nodes. On April 11, 2008, a beta test was held with a network size of over 100 nodes. Since SpectralMorning stopped work on OFF in late 2008, only minor bug fix releases were made to mainline OFF.

Starting from 2007, an alternative, but compatible client was developed, called BlocksNet. Written in Ruby and well-maintained, it saw major improvements over recent time. It has been under development until 2011.

The client OFFLoad is a fork from mainline OFF, which seemingly adds no features. Reasons for the fork are unclear. Another distantly related program is Monolith, which uses a similar principle to OFF. It was created after OFF and features no multi-use of blocks and no networking.

Functional Principle

The OFF System is a kind of anonymous, fully decentralized P2P file sharing program and network. In contrast to other anonymous file sharing networks, which derive their anonymity from forwarding their data blocks via intermediate network nodes, OFF derives its anonymity from anonymizing the data files. Thus, the system refers to itself as a brightnet to contrast its method of operation with that of private file sharing systems known as darknets and with traditional, forwarding anonymous P2P programs.

Store Procedure

In order to store a file into the local OFF storage, resp. block cache, choose the tuple size t (default 3), split the source file s into blocks s i of size 128 KiB (pad with random data to fit) and for each, do the following:

1. Select t − 1 blocks for use as randomizer blocks, or for short, randomizers, from the existing OFF cache, which have not been used in previous iterations. If not enough randomizers exist in the cache, generate them using a random number generator.
2. Calculate o i = s i ⊕ r 1 ⊕ r 2 ⊕ . . . ⊕ r t − 1 and store the resulting block o i in the cache, ⊕ being the XOR operation.
3. Update the descriptor list, which contains the information on how to restore each source block s i , with a new entry, which is a set of size t : { o i , r 1 , r 2 . . . r t − 1 } .

Finally, store the descriptor list in its own block (or blocks, if the list is larger than 128 KiB) and insert these blocks d i into the block cache and generate an OFF URL for referencing the source file and output it to the user or into the local OFF URL database.

Retrieve Procedure

To retrieve, obtain the descriptor block or blocks and for each contained set of size t , do the following:

1. Obtain the listed blocks b 1 , b 2 . . . b t . Though they have no identity any more at this point, they could be called o i , r 1 , r 2 . . . r t − 1 .
2. Perform s i = b 1 ⊕ b 2 ⊕ . . . ⊕ b t and output the resulting source data block s i to a viewer program or to storage.

Anonymity

OFF derives its anonymity from the following:

1. No source file content is stored in the block cache, only blocks that consist of probably random data.
2. No source file content is searched for on the network.
3. No source file content is transmitted over the network.
4. (No block in the cache is copyrightable by itself, because numbers - however large - cannot be subject to copyright (and neither would be small parts of a copyrighted work).)
5. The original uploader remains unknown, because blocks are dispersed into the network and therefore downloading is done from multiple sources.
6. During disperse, the usage of the block cannot be stated, because blocks are re-used in other contexts to re-assemble other source file blocks. (TODO that is true also for retrieve)
7. (No block can be copyrighted without logical contradictions, because blocks used for re-assembling a source file block are re-used for re-assembly of other source file blocks. It is undecidable who would have copyright on a block, which has several meanings. Everyone would have copyright on everything.)
8. If the OFF-internal search function is used, search terms are untraceable to its originator, because the search request is forwarded to the next node and its results back to that node instead of directly to the originator. It is thus not possible to decide whether a node is the originating node or a node doing a search request on behalf of another node.
9. TODO add digital copyright note

Efficiency

Because OFF anonymizes the data blocks being exchanged instead of the network, no forwarding via intermediate nodes is required. Therefore, this method has a higher degree of efficiency than traditional, forwarding-based anonymous P2P systems.

The forwarding method requires that a data block is uploaded and downloaded several times before it reaches its destination, which happens between 5 and 15 times., which, according to the resulting formula s ∗ ( h i + h o + 1 ) ∗ 2 − s , is equivalent to an overhead of 900 to 2900%, while the overhead of OFF without optimizations is about 200%. ( s is the source file size, h i the inbound tunnel length and h o the outbound tunnel length. Plus 1 for the hop between the Outbound Endpoint and the Inbound Gateway.)

Efficiency can be further increased:

1. Re-use some of the result blocks o i and randomizer blocks, which reduces the overhead to s ∗ ( t − 1 ) ∗ e 100 , where s is the source file size, t the tuple size and e the percentage of unrelated blocks used in the randomizing step during the store procedure. By default, e is chosen 75 (and t chosen 3), which leads to an overhead of 150%.
2. If some of the blocks required to fully retrieve, resp. re-assemble, the source file are already present in the block cache from other transfers or stored files because of the multi-use nature of OFF blocks, the degree of efficiency is increased further.
3. Use of the targeted store feature leads to the blocks of specific other files to be chosen as randomizers for this file with higher probability and therefore a reduction in overhead. This is especially useful when storing a group of related files.