Record Specification

This is the formal specification which Speech.js will look for when transcluding a domain, meaning that foo.bit would load bar.tld but display foo.bit. Support for other formats is best effort and may lead to inconsistent results if not downright errors.

"name" : "foo",
"value": {
  "http": {
    "foo" : "bar.tld"
    "bieber.foo" : "fever.bar.tld"
  }

Short-hand version which is translated to the above at runtime:

"name" : "foo",
"value": {
  "http": "bar.com"
}

Obfuscation and Stenography

The primary goal for Speech.js is to combat censorship. Most censorship is passive, no-one living in Britain is going to be locked up for visiting websites filtered by their ISP. Thus we only need to make the endpoint unknown to the censor, not hide all activity.

This requires that the website provide private entry points for each client at a website the censor does not know about. This means that the user must retrieve a custom record for the destination website through some out-of-band communication channel. Further discussion of such channels will be forthcoming (indolering is working on a literature review) but it could be a DHT, Email, Twitter, etc.

While a website could simply hand out a domain which is a mirror to the main website, those tend to be blocked fairly quickly. Instead, the website found at the bare root domain must be non-obvious while providing additional URL elements which allow the server to distinguish between legitimate users and censors. One way to accomplish this is using a nonce:

"name" : "wikileaks",
"value": {
  "http": "kittens.tld/nonce"
}

While this would defeat trivial OpenDNS-style filtering, a government could scan in real-time. HTTP auth can defeat this:

"name" : "wikileaks",
"value": {
  "http": "username:[email protected]"
}

But the bots could just report back that that HTTP authentication was being used and so pushing the nonce to the opaque part of the URL is probably a best-practice:

"name" : "wikileaks",
"value": {
  "http": "kittens.tld#[email protected]"
}

Overall, however, this ultimately relies on making censored content indistinguishable at a network level from uncensored content and then using some sort of authentication mechanism to prevent government censors from learning more about the network.

It should be noted that this is not a typical game of cat-and-mouse. The endgame is to force would-be censors to choose between white-lists or no censorship at all. We cannot get North Korea or Iran to connect their nation-state LANs to the internet, but we can make raise the political stakes in countries which do allow internet access to its citizens.

Encryption

Before graduating from developer preview to public beta status, cryptographic verification of custom records must be a adopted as a required component of the official specification. All public/non-custom records must include the full public key or a hash of the public key. If using Namecoin, this would mean that the original record would need to include a TLS or similar entry.

Speech.js will adopt the relevant specifications of the IETF Javascript Object Signing and Encryption (jose) working group. Deviations from the standard may be made to specify required algorithms, generally favoring shorter ECC keys combined with a shorter but cryptographically weaker non-ECC scheme. We may possibly use Ed25519 public-key signatures when this standard becomes more uniform, however, this will only be done as an optional component of the specification such that the only libraries required to verify a custom domain would be libraries which conform to the JOSE standards.