ablankst

I'm on the engineering team at Blockstack, and wrote the client-side encryption functions used by applications.

I totally agree with the idea that if software uses encryption, it should be documented, open-source, and ideally use a standard encryption protocol. Being able to say "this is exactly how encryption works" in a system is important, and I'm glad you're asking these questions.

Encryption in Blockstack apps is performed client-side via library calls in blockstack.js (our javascript library). The encryption routines are implemented here [1], and implement ECIES, using the user's application-specific private key. That private key is passed to an application during the application authentication process [2]. All a blockstack application has to do is pass { "encrypt": true } in the storage routines, and this is invoked.

We definitely would like to provide better documentation and messaging around how applications engage and use our client libraries -- and documenting our encryption routines is part of that. However, in the meantime, you can feel free to check out or codebase (it's all open source), and we'd always welcome any kind of feedback!

[1] https://github.com/blockstack/blockstack.js/blob/master/src/...

[2] https://github.com/blockstack/blockstack.js/blob/feature/aut...

The following example is pretty much the chief reason why I will not be porting much software to Python 3:

  $ python3 
  Python 3.6.3 (default, Oct  3 2017, 21:45:48)
  [GCC 7.2.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> 4/3
  1.3333333333333333

Even if thousands of developers from HN switch, that would hardly move the needle. Ordinary users just won't care about any of this.

Thousands of developers from HN make websites. If they switch to Firefox, at the very least, the websites they make will support Firefox. This won't necessarily make Mozilla commercially viable, but if people are really that concerned about it, they can donate to the Mozilla Foundation.

I agree about this ethical concern, but this attack also shows that reporting the holes to manufacturers is of limited use -- these exploits have been known to manufacturers since at least March, and while patches have shipped, the computers remain vulnerable. Clearly, automatic security updates are still not aggressive enough to prevent these kinds of problems. Though it isn't clear from the article how out-of-date the vulnerable systems are, which would help in planning for the future. For example, Windows 10 pushes security updates very aggressively, and I wonder how many of the infected computers were running Windows 10 -- health care providers' computer systems are often notoriously out-of-date.

From [1] "in the case of blocking workloads, it’s extremely difficult to determine the number of threads that optimizes overall throughput because it’s hard to determine when a request will be completed." So the argument they make is that responding to the number of blocked threads directly could lead to an over-correction, where you add a lot of threads to the thread pool when threads are about to unblock. This reduces throughput because you now suffer context switches and poor cache locality.

[1] https://msdn.microsoft.com/en-us/magazine/ff960958.aspx

Have you thought much about address space randomization? It's a reasonably effective security strategy, but it essentially requires enough unused bits in the address space. If you have a system with one big memory space, presumably your address space is now more precious, or do you still have enough bits for randomization (both in the local and the global spaces).

This is actually an interesting point. A compromised user table could conceivably be used for all sorts of nefarious purposes. If the attackers "having access" to the information in that table includes the ability to modify that table, then it is pretty much open season on Slack. For example, an attacker could replace a target user's password-hash with a hash that the attacker knows the plaintext of. Depending on the implementation of the random salt, the attacker may have to replace the salt as well. Then, the attacker logs in as the user, downloads the desired chat history, logs out, and sets the password hash to the original. Not enough information was really given in the blog post, but by the sounds of it, some teams experienced more targeted attacks.

What about this exploit really requires a US supply chain? Why do you believe that the Five Eyes have fewer exploits for hardware originating from BRICS nations? Don't intelligence agencies have explicit missions to spy on those countries?

If you think that because you are running less popular hardware, that the NSA wouldn't bother obtaining exploits for them, you may be right. In that case, though, you're simply making a popularity trade-off. (And it is a trade-off, more popular hardware is more popular for a reason.)

Let the switch cost something like 1 unit and the analysis on the Wikipedia example still holds - at the switch, drivers face a choice between a 41 minute route and a 45 minute route. Yes, this paradox is a property of the specifics of the network in question, but it may hold for real networks is the claim.

In Go, and other type-safe languages, the compiler usually knows exactly which ints are being used as pointers. This is the difference between "precise" and "conservative" GC and is one of the reasons that comparing GC performance in C++ to GC performance in other languages is difficult.

If you check out the draft (http://tools.ietf.org/html/draft-ietf-httpbis-http2-04), it looks like either the client or the server is able to initiate and send data along the HTTP/2.0 streams.

And in Section 2.2:

HTTP/2.0 provides the ability to multiplex multiple HTTP requests and responses onto a single connection. Multiple requests or responses can be sent concurrently on a connection using streams (Section 5).

This requires supporting client-initiated requests over an established connection.