brl

Why would anybody censor the viewpoint of a woman scientist in this particular debate? How much cognitive dissonance is too much?

> I would love to hear his side of the story.

Some of his side of the story has been told in the leaked emails:

https://www.hdevalence.ca/etc/34de2f3c2a48f7da/EmAiLs.txt

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.

> 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.

I'm from Subgraph and I disagree.

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:

https://www.blackhat.com/presentations/bh-usa-07/Ortega/Whit...

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:

https://grsecurity.net/rap_announce.php

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.

> imho the qubes approach is more viable and exposes far less attack surface.

I don't know what you base that opinion on since it's not an easy comparison to reason about. One metric you could use would be actual vulnerabilities. In the last year there have been several hypervisor escape vulnerabilites that compromised Qubes OS VM isolation completely, most (all?) of which have been present in Xen for the entire lifetime of the Qubes project.

By contrast during the same period only one Linux kernel vulnerability (DirtyCow) affected Subgraph sandboxed applications, and it would only have been exploitable using techniques which have not been disclosed in any public exploit so far.

Two people published open letters resigning from their involvement in Tor yesterday:

https://www.oneeyedman.net/?p=2581

https://shiromarieke.github.io/tor

Sandbox implementation is described here:

https://github.com/subgraph/oz/wiki/Oz-Technical-Details

Well there was this survey:

https://en.wikipedia.org/wiki/Syrian_presidential_election,_...

Also surveyed at that time were the million Syrian refugees living in Lebanon:

https://www.washingtonpost.com/news/worldviews/wp/2014/05/28...

http://www.voltairenet.org/en is a good site with many essays on these themes.

Check out the 'more details on Convertible Notes' link for the answer to your question.

Escalation to root from an active admin user account is trivial. Use your imagination.

Even if you validate certificates an active attacker can return false MX records and direct the sending MTA to connect to an attacker-controlled server which presents a perfectly valid certificate.

I would love for this to exist. I've thought about streaming on twitch before but it is apparently against their ToS to stream anything which isn't video games.

You can copy your private keys to another device obviously, and eventually Nyms can help you do this by brokering an end-to-end encrypted tunnel between devices to transfer keys securely.

Maintenance of public keys is automated, by which I mean the user does not need to do anything manually for them to be published and recertified before they expire.

Private keys don't need maintenance after generation since they are simply stored on the user's computer.

The user only needs to install a Nyms supporting email client or webmail browser extension and they're good to go for transparent communication with any other Nyms user.

Registration and maintenance of keys is entirely automated. Making everything as easy as possible for users without compromising on strong guarantees about key authenticity is the whole point of this project.

I'll be pushing some initial code to github soon for the first stage of the project which is a locally running agent that provides encryption service to email clients over a json-rpc interface. We're also building our own email client, however the agent is designed to facilitate easy integration into any other client.

Hi, I'm the author of this document and principal developer of the project. This is a somewhat detailed design overview for a proposed alternative to the PGP keyserver system that I'm building and I didn't really write it for a general audience to avoid cluttering it up with too much background information.

Sometime soon we're going to improve the website with a friendlier high-level description of the goals of the project and the problems that it solves. For now, I apologize that this rather dense document is the only information available.

It might be easier to understand what I'm trying to achieve by reading a post I made yesterday to the modern crypto mailing list which summarized the important features of Nyms:

https://moderncrypto.org/mail-archive/messaging/2014/000602....

Yawn. Let me know when you're ready to announce a project to competently sign and verify artifacts.

Even if you have carefully installed the correct key from the author, if your download is intercepted and an attacker sends you a bogus artifact and signature it looks like Lein will just retrieve the attackers key from the keyserver and validate the signature.

How does it know what the correct signing key is?

edit: Looked up answer myself. Lein downloads whatever key the signature claims to be made with from public keyservers. How does this provide any additional security over not bothering to verify signatures?

RSA has this property, but the public and private keys are not chosen arbitrarily. The public key can easily be derived from the private key, but there is no obvious way to determine the private key from the public key.

I'll admit that it's the most exceptional trademark violation that I've seen today:

http://www.dsource.org/projects/dwt/wiki/Logo

I use SWT quite a lot and while it's not perfect I find that it works brilliantly in most cases. I encourage the authors of this Go UI library to study SWT and crib heavily from the library internals. Otherwise they'll be sorting out bugs and corner cases that IBM has fixed in SWT long ago.

Yes, Subgraph OS is meant to be used as a general purpose desktop operating system. There is pressure on TAILS to evolve in this direction by people who like TAILS and want to use it as their main everyday OS, but this conflicts with the 'amnesic' philosophy and vision of TAILS as an ephemeral read-only system. One of the objectives of Subgraph OS is to provide something more convenient to users who wish to use TAILS persistently.

Hi Bruce from Subgraph here.

Yesterday we updated our website with information about a new project that we've been working on since December and made a very small announcement on Twitter about the website change and this generated more attention than we were expecting.

So I should clarify the status of the project which is that we haven't released anything yet, but we've been working on what is described on our website for the last 6 months. We predict but can't promise that we'll have something available for brave enthusiastic people to test by the end of summer. That's the point at which we normally would have announced our project here.

> Some developers have noted Go’s lack of features or a few other things: no exceptions, nils instead of options, inability to specify dependency versions, mark and sweep GC, no macros, no generics.

Not having exceptions is one thing and probably a valid opinion, but specifying library dependencies as whatever today's HEAD commit is on a GitHub project always seemed to me incompatible with writing reliable software. Until reading this article (and learning about godep) I thought that I must be misunderstanding how dependencies are managed in Go, because how could that possibly work? In practice how have people been dealing with this before tools like godep?

> The only other option is that it wasn't random, but some event led to both discoveries. Perhaps a hint was around, a new method of

> finding vulnerabilities, or anything at all that could nudge people's minds in that direction.

As somebody who has witnessed several cases of simultaneous discovery of security vulnerabilities, this is exactly how it happens. Some vaguely related event happens which causes multiple researchers to all start looking in the same place.