Tor in a safer language: Network team update from Amsterdam • Hacker News Board

Re: Tor in a safer language: Network team update from Amsterdam

#211

Post by fauigerzigerk » Sun, Apr 02, 2017, 2:08 PM UTC

microtonal wrote: post #207

fauigerzigerk wrote: post #202

Earlier quoted context omitted.

I agree that mutability constraints are a major weakness of Go. Interestingly, they did make string immutable and added []byte as a mutable alternative. It's unfortunate that string and []byte are so similar and yet it's impossible to treat a []byte as a string without copying (with the exception of looping over runes). This leads to massive code duplication and/or lack of functionality (byteconv where are you??). Ju…

There's no time for explanation. So what they do is read code to acquaint themselves with the codebase and hopefully become productive before they move on to the next job. And that is the one task where Go really shines. Reading arbitrary pieces of code. Definitely. This really shines in the standard library, it consists of extremely readable code and is a good way to get up to speed on canonical Go. We all want to b…

I'm comparing to other widely used languges like C++, C#, Swift, Scala, Java or Python. I don't think any of them allow as few possible meanings of any given language expression as Go does. And I don't think any of them requires as little non-local information to find all code that gets called by any particular expression (perhaps with the important exception of Go's structural interfaces).

I wonder whether it is simply a theoretical tautology that the more abstraction features you have in a language, the more different possible meanings any particular syntactical expression can have, and the more effort it requires to figure out its true meaning, assuming you're not familiar with the codebase.

Or is that a false dichotomy? I am unfortunately not familiar with Ada or Oberon and Pascal is but a faint memory.

Re: Tor in a safer language: Network team update from Amsterdam

#212

Post by bostik » Sun, Apr 02, 2017, 2:10 PM UTC

im_down_w_otp wrote: post #78

mahyarm wrote: post #72

Earlier quoted context omitted.

Golang is simpler java, and that is it's target. It even has the same perf profile as java. Erlang does have a worse perf profile.

Yes Erlang does, strictly for execution throughput, but less so for concurrency handling. That is also a solveable problem. It just so happens to be a problem neither Ericsson nor ESL have been interested in solving.

Remember, Erlang was first and foremost developed as a programming language (and runtime) to run Ericsson's phone switches.

Session establishment for PSTN can be relatively expensive (much in the way of TLS handshakes), so concurrency and shared-nothing memory model together allowed for real-time streaming to keep on working no matter what else happened. The three main features of a PSTN switch are, after all:

1. Reliable call switching

2. Reliable real-time throughput

3. Reliable billing and accounting data generation

We don't think much of throughput these days, when any home office switch has gigabit ports and 40Gb+ backplane. As far as I know, maximising throughput bandwidth was not a primary consideration with Erlang. Reliable real-time streaming is much more about guaranteed latency - and incidentally, optimising between latency and throughput tends to be all about tradeoffs.

Re: Tor in a safer language: Network team update from Amsterdam

#213

Post by microtonal » Sun, Apr 02, 2017, 2:14 PM UTC

burntsushi wrote: post #208

microtonal wrote: post #190

Earlier quoted context omitted.

But C code may not keep a Go pointer that persists between calls (because GC). I can imagine that this is a problem for gradually converting code bases.

Sure but that's not what I was replying to? I was only talking about Go->C FFI. If someone didn't know about finalizers, then I've might be trying to insert `free` calls everywhere in their Go code, which could become quite annoying. But yes, Go pointers in C code is bad juju.

Sure but that's not what I was replying to? I was only talking about Go->C FFI.

Sorry, my reply was too brief. I wanted to add that the ergonomics are bad, not just because of freeing memory (for which the inconvenience can indeed be reduced with finalizers and/or Close() methods plus defer). But rules such as this one make Go->C FFI unergonomic as well. To give one example: many linear algebra libraries (e.g. Tensorflow) have their own wrappers around raw arrays to represent tensors (with their dimensionality) [1]. As a consequence of this rule, one cannot just a pointer to the first slice element to such functions (since a pointer to a Go object would be stored in a C struct), but have to malloc an array and copy over data from the slice to the C array.

[1] There are other issues, such aligning slice memory to 16-byte boundaries.

Re: Tor in a safer language: Network team update from Amsterdam

#214

Post by pjmlp » Sun, Apr 02, 2017, 2:31 PM UTC

dllthomas wrote: post #209

pjmlp wrote: post #188

Earlier quoted context omitted.

Galois, Facebook and Microsoft are some examples, and all ML derived languages tend to be used for data modelling in the financial sector. https://wiki.haskell.org/Haskell_in_industry https://ocaml.org/learn/companies.html

It seems wrong to call Facebook and Microsoft "built on" Haskell, even if they are using it effectively for some important things. Galois, of course, is very much built on Haskell. And there are certainly other examples.

Still their money is certainly landing in some pockets relevant to those communities.

A company doesn't need to be built on a single language.

Re: Tor in a safer language: Network team update from Amsterdam

#215

Post by oddthink » Sun, Apr 02, 2017, 2:58 PM UTC

microtonal wrote: post #183

oddthink wrote: post #167

Earlier quoted context omitted.

I like it. My brain's already pretty full with trying to get a ML pipeline optimized and launchable, and if I need to write something to read a CSV file, make some RPC calls to a service for each row, and dump the results to a file, go just works. Sure, I could use something like Haskell, but then I'd have to worry about whether I'm accumulating a giant stack of thunks that'll blow up. go just works, and less of it w…

trying to get a ML pipeline optimized I wrote some machine learning tools in Go and the experience is quite bad. The lack of operator overloading and parametric polymorphism make most ML code ugly. It also does not help that Go's compiler backend does not optimize very strongly and calling out to C comes with a relatively large overhead. Sure, I could use something like Haskell, but then I'd have to worry about wheth…

Yeah, the ML parts aren't in Go. I'm working in TensorFlow, so it's C++ scripted by Python. But there's a lot of incidental stuff that needs to be done, most of which I don't want to spend cycles on thinking hard about, and Go does a good job there, in that narrow niche where I want something that runs on one machine but find python too slow.

At a previous gig, I had done a lot of F#, and I think that's close to my personal sweet spot, but I'd have to use it frequently to keep it in my head. Go is small enough that I can load it into cache when I need it.

Re: Tor in a safer language: Network team update from Amsterdam

#216

Post by burntsushi » Sun, Apr 02, 2017, 3:46 PM UTC

microtonal wrote: post #213

burntsushi wrote: post #208

Earlier quoted context omitted.

Sure but that's not what I was replying to? I was only talking about Go->C FFI. If someone didn't know about finalizers, then I've might be trying to insert `free` calls everywhere in their Go code, which could become quite annoying. But yes, Go pointers in C code is bad juju.

Sure but that's not what I was replying to? I was only talking about Go->C FFI. Sorry, my reply was too brief. I wanted to add that the ergonomics are bad, not just because of freeing memory (for which the inconvenience can indeed be reduced with finalizers and/or Close() methods plus defer ). But rules such as this one make Go->C FFI unergonomic as well. To give one example: many linear algebra libraries (e.g. Tenso…

Ah yes, you are absolutely right. I actually modified Rust's regex C API in part because of this problem in Go. I can't remember the details, but they were similar to your example where the only way to work around it was an unavoidable additional allocation.

(Of course, I think the change led to a better overall API. Go just helped me get there in a circuitous way.)

Re: Tor in a safer language: Network team update from Amsterdam

#217

Post by Jweb_Guru » Sun, Apr 02, 2017, 3:47 PM UTC

_0w8t wrote: post #203

mahyarm wrote: post #72

Earlier quoted context omitted.

Golang is simpler java, and that is it's target. It even has the same perf profile as java. Erlang does have a worse perf profile.

Golang performance profile is very different from Java. It's speed is closer to C++, garbage collection optimized for latency, not bandwidth, very low startup time comparable with typical native code.

You can actually get a performance profile very much like Go's out of Java...

* Inasmuch as you can make a blanket statement like this about a language, Go's speed is very much comparable to Java's.

* Java has a huge number of garbage collectors available. You're just talking about the default, but there are extremely low-latency GCs.

* Java has a bunch of ahead-of-time compilers; thanks to Android this might be the most common deployment of Java.

Even green threads were tried (and sensibly abandoned) in Java before.

I think people may not be aware of all the options available in the Java ecosystem, but other than sized types, which are theoretically coming to Java 10, there isn't much performance-wise that Go does and Java doesn't.

Re: Tor in a safer language: Network team update from Amsterdam

#218

Post by dguido » Sun, Apr 02, 2017, 4:04 PM UTC

steveklabnik wrote: post #174

dguido wrote: post #169

Literally none of this matters. None of the flaws exploited in Tor are memory corruption flaws. They are entirely architectural and design flaws. No attacker cares if they move to Rust. _NO ONE_.

> None of the flaws exploited in Tor are memory corruption flaws. http://www.cvedetails.com/product/5516/TOR-TOR.html?vendor_i... This list is full of memory safety issues.

> None of the flaws exploited in Tor are memory corruption flaws

_exploited_ is the operative word here.

Show me the list where people wrote exploits for the bugs you point out, or where someone abused them to de-anonymize a Tor user? There aren't any.

Re: Tor in a safer language: Network team update from Amsterdam

#219

Post by seibelj » Sun, Apr 02, 2017, 4:33 PM UTC

Tempest1981 wrote: post #173

seibelj wrote: post #132

Earlier quoted context omitted.

You cannot use Netflix with any non-self-hosted VPN service, they have put a lot of effort into getting around it. We use PIA's DNS for anonymity.

So do you have a workaround? Can you bypass VPN routing for Netflix and other specific domains?

Interesting idea - adding whitelisted domains to bypass the VPN. We will investigate this. Currently we recommend running 2 routers simultaneously (which do not interfere because of automatic channel switching) with the VPN chained after the normal one. This allows you to choose when to use VPN. Basically the Easy VPN Router is designed to be super easy so that non-technical people don't mess anything up. Building one yourself is tricky, especially to cover edge cases like the VPN dropping, the internet going in and out, etc.

Re: Tor in a safer language: Network team update from Amsterdam

#220

Post by seibelj » Sun, Apr 02, 2017, 4:35 PM UTC

m-j-fox wrote: post #182

seibelj wrote: post #132

Earlier quoted context omitted.

You cannot use Netflix with any non-self-hosted VPN service, they have put a lot of effort into getting around it. We use PIA's DNS for anonymity.

I'd be cool with whitelisting a couple of URLs, such as netflix.com. Or google, hacker news, whatever. Who cares if comcast sells the fact that I use a service everyone uses? I really just want things that I access in Private Browsing, or using a service other than http/https, not to be recorded. I understand that people in various countries want to use the Netflix from another country. But I'm representing the 99%.

As I said in the other comment, right now we recommend running 2 routers, and connecting to the normal router when you want to access VPN blocked services or want low-latency connections for online gaming. But we will investigate white-listing IP addresses, that would be very useful.