The recent attacks on Tor and incidents with Bitcoin are putting pressure on us to release.
- Standardizing serialization formats.
- Finishing documentation.
- Changes to internal organization of /src/visor (which runs the blockchain). The wallet manager is moved out of visor. Visor has golang interface based upon the Obelisk Darkwallet API, then another module will run a web-server and manage your local wallets and checks for balances and so on. This makes it more flexible for using visor as a library without running a full node.
- All the branches are on same version of networking library now. We are going to branch that off into its own repo. I think we can pull that in as dependency from the public repo and see what is left in the daemon module, then move that somewhere. Then everything should be in order.
When documentation is done, there are a small series of golang libraries that need to be developed. This is great project for anyone who knows golang.
Darknet/Distribution Application Security Concerns
Google intends to compile and run Blink and V8 inside of Portable Native Client (PNaCl). This would solve the security problems and ensure sandboxing regardless of exploits in V8 or Blink. However, Google is not ready with this yet and it may be a few months. V8 appears to be running in NaCl however.
Portable Native Client, PNaCl is a subset of LLVM Bitcode (the binary representation of LLVM intermediate form). It is compiled down by LLVM to a machine dependent format. There are checks to ensure that the program cannot perform operations that would escape sandbox.
PNaCl takes C/C++ (gcc toolchain) and outputs a subset of LLVM Bitcode. Then the bitcode is compiled to native code with LLVM. The compiled binary is verified and modified so that it cannot break out of sandbox if executed. The slowdown from V8 inside of NaCl sandbox is 50%, but this is acceptable for the security.
Network and file access occur through an API. The application does not have native access to network or file system. This prevents the application from being able to find the IP of the machine it is run on or other identifiable information.
This type of high security browser would be good frontend for rendering and interacting with darknet applications. It is also relevant for the Tor project, as there is less room for meta-data leaks and browser exploitation.
Another concern is browser fingerprinting. A darknet application should be unable to identify a computer uniquely, by running a program on it. We are not sure if LLVM Bitcode to NaCl bitcode is deterministic. Run times for various operations will vary between different CPUs and this can be used to finger print. If the compilation from Bitcode to NaCl is not deterministic, then a specific cached compilation of a darknet app can be fingerprinted.
Interpretation of the LLVM Bitcode on an emulator type virtual machine, eliminates finger printing but slows it down. V8 uses runtime code generation which makes this approach frustrating, because it now requires implementing a secure x86 emulator rather than a simpler and more flexible emulator that implements LLVM Bitcode.
That was our original approach, but I dont see how it will work with Blink/V8 as the frontend for the application.
What we can now works and its very secure, but in long term we have to work out these problems.