I can understand the disbelief over the "maximalist" approach that suggests that regulations, government intervention, taxes, etc. will be circumvented by decentralized companies running on blockchains. Yet I believe that this efforts should be encouraged as they are exploring the kind of wild, uncharted territory in which the most exciting innovations can unexpectedly arise.
I also believe that some of the tools these guys are building can be very useful for conventional companies too. There's a whole lot of bureaucracy and inefficiency in running a company.
See eShares and his elegant and simple solution for cap management. I believe there are many other areas in which similar improvements can be made, and software needed to run a blockchain company could also be used to improve procedures at conventional companies.
a) You should use log scale[1]
b) The same "hype cycle" has been repeated in 2011 (bottom $0,001, top $32, crash to $2) 2013 (bottom $10ish, top $266, crash to $55) and 2014 (bottom $70ish, peak $1200ish, crash to $350ish) - always reaching higher highs and bottoming out to higher lows.
Therefore, zoom out and you will see that Bitcoins has "interim bubbles", but the long time trend has nothing to do with Gartner's hype cycle.
There will always be smaller price fluctuations than the long-term trend. I'm not sure why you think a log scale is a better comparison either. Note I wasn't just comparing the shape of the curves, the actual descriptions of the hype cycle match the bitcoin story fairly well. Anyway it was just a curiosity, eyeballing price charts and thinking you see meaning is a time-tested method for being wrong...
If you use the log chart you can see the fractal nature of the price curve, which has multiple instances of the hype cycle.
Edit: I don't think fractal is the right word. But if you are using the log scale you can see the fluctuations of relative value and the hype cycles become much more clear. There have been several. Also, GP is saying that if you average out the spikes and dips you lose the "rise and fall of bitcoin" angle.
Does Subgraph isolate USB and network? The isolated serviceVMs for USB and network are in my opinion a very strong value proposition of Qubes.
Furthermore, is Subgraph supposed to be an OS for everyday use, like Qubes, or just for anonymous usage like Tails or Whonix? If its the former I don't understand why all traffic should be routed via Tor by default - it wouldn't make sense to route non-anonymous traffic (banking, personal mail, etc.) via Tor. It wouldn't be anonymous anyway and also because of the unnecessary risk of exposure to malicious exit nodes. In this sense I believe the Qubes approach with its optional WhonixVM is superior.
If Subgraph is supposed to be for anonymous usage I'd like to read more about what kind of threat model it is trying to address. I don't think there are any amnesic features like in Tails nor strong isolation between gateway and workstation to prevent IP leaks like in Whonix.
> Does Subgraph isolate USB and network? The isolated serviceVMs for USB and network are in my opinion a very strong value proposition of Qubes.
According to Joanna Rutkowska, developer of Qubes: "Unlike Qubes OS, Subgraph doesn't (cannot) isolate networking and USB stacks, or other devices and drivers."[1]
On Qubes OS the networking VM runs a standard Linux kernel with no special security hardening at all apart from the simple fact that it runs in a separate Xen VM. If an attacker is able to compromise NetVM, they may not have direct access to user data, but they have dangerous access to perform further attacks:
- Attacks against hypervisor to break isolation
- Side channel attacks against other Qubes VMs to steal cryptographic keys
- Interception and tampering with networking traffic
- Attacks against any internal network this Qubes OS computer connects to.
So if you assume that remote attacks against the Linux kernel networking stack are an important threat, the consequences of a successful attack even against Qubes are pretty bad.
Subgraph OS hardens the Linux kernel with grsecurity, which includes many defenses against exploitation which have historically prevented local exploitation of most security vulnerabilities against the kernel. Exploiting kernel vulnerabilities locally is so much easier, probably never less than an order of magnitude easier. It's so rare to reliably exploit kernel vulnerabilities remotely even against an unhardened kernel that teams present papers at top security conferences about a single exploit:
I know it's contentious to say so, but I don't believe that anybody will ever remotely exploit a kernel vulnerability against a grsecurity hardened Linux kernel, especially since RAP was introduced:
The threat of remotely attacking the Linux kernel through the networking or USB stack was always low in my opinion, but as the threat approaches zero it raises some questions about how justifiable the system VMs are in Qubes OS considering the system complexity and usability impairment they introduce.
I agree with your comments about grsecurity making the kernel much more secure. However your comments about remote exploits and Qubes are somewhat contradictory. You claim that a remote kernel exploit is very rare/difficult, therefore the Qubes NetVM must be very difficult to attack because it runs no applications or services. It functions as a router and does essentially nothing else. By your own argument it would be very difficult to attack the NetVM. It is only the AppVMs or any others which run applications that are vulnerable, and if these are attacked, Qubes's design will likely prevent a permanent backdoor from being installed in that VM and make it difficult for the attacker to gain access to any of the other AppVMs.
I still think Subgraph looks promising and I look forward to your future work.
I'm answering a comment chain about how Subgraph OS does not 'isolate' the network or USB stacks which is frequently brought up as an important deficiency in comparison to Qubes OS. My point is that this isn't a significant advantage of Qubes because such attacks are rare and difficult, and because they're even harder to perform against Subgraph OS.
I wasn't talking about AppVMs at all, but you can of course persistently backdoor Qubes AppVMs in numerous ways by writing to the user home directory. In Subgraph OS we design our application sandboxes to prevent exactly this.
Thank you for your answer, I'll definitely look further into SubgraphOS and grsecurity. I nevertheless believe that the kind of attacks you describe, specially the one against hypervisor in NetVM to break isolation, are quite unlikely in Qubes.
Could you also answer my question about SubgraphOS main use case and threat model?
Is it mainly for anonymous and pseudonymous usage?
If it is designed mainly for everyday use (including non-anonymous use cases like banking, social media, personal/work email, etc.) as it seems to me I don't quite understand the design choice to enforce all traffic via Tor by default. That seems unnecessary as anonymity is not needed and even dangerous.
Yeah, we agree, actually. Tor probably won't even be the default. We are adding flexibility to network support right now. Soon you'll be able to have just cleartext SGOS, or be able to send sandboxed apps through different paths: one app might exit through a VPN, another through Tor only, another through i2p maybe, etc, enforced by the sandbox.
> I don't think there are any amnesic features like in Tails nor strong isolation between gateway and workstation to prevent IP leaks like in Whonix.
Subgraph sandboxes run in a network namespace with no direct access to the network or ability to view any of the physical network interfaces on the system. There is no way for an attacker to send network traffic directly or to discover the real IP address of the system without breaking out of the sandbox.
Most people selling "private blockchains" are just trying to sell a (hopefully) better database system to a customer that doesn't really understand what a blockchain is. Sometimes they are adding a messaging system to the equation, and sometimes they are just trying to sell another CRM system. But it's definitely not a blockchain.
Furthermore all this constant search about "uses cases for blockchains" is ridiculous. You simply do not go looking for use cases for technology - that's a recipe for unsuccess unless your business is to make money on consulting hours - what you do is to simply build technology to solve specific problems. As you said the blockchain was invented to solve a very specific problem: sending value from A to B without the intervention of a financial institution or any other third party.
Thank you! We focused on building a product that is very easy to extend. Smart policies bringing the functionalities you describe can and will be built.
