srollyson

I remember hearing about the WikiReader [1] a few years back and thinking it would be great for this sort of use. It's basically a cheap handheld device with an LCD display and a local Wikipedia text-only cache that runs off of AAA batteries. Might be useful for delivering Wikipedia content to places where there's no cell phone infrastructure.

[1]: http://en.wikipedia.org/wiki/WikiReader

Here's the overview page for the Galileo board: http://www.intel.com/support/galileo/index.htm

It has links for downloads, specs, tutorials, etc. Looks like they won't be available for sale until November, though.

Well how about that. Thanks for the link.

I remember reading an article in 2600 where someone figured out that quite a few websites took a PHP filename as a query arg to be eval'd... and some subset of those had no mechanism in place to restrict it to local files. Needless to say, they could point that arg to example.com/malicious.php and have it run on the vulnerable box.

The best part was that they constructed a Google query to find sites that would eval remote PHP code. It was something else!

Yeah, that was a bit of a logical leap. I can see that the code analysis was probably done after getting a disk image now. I think the original lead probably came from his second bitcointalk "altoid" post, though.

Haven't finished the complaint yet, but it looks to me like the FBI found a security vulnerability in the Silk Road website itself. More specifically, it looks like they found a way to have the PHP source code sent as an HTTP response rather than have that PHP code executed and send its output. From page 27 of the complaint:

  Further, based on forensic analysis of the Silk Road
  Web Server, I know that the server includes computer
  code that was once used to restrict administrative
  access to the server, so that only a user logging
  into the server from a particular IP address,
  specified in the code, could access it.

The report later goes on to say that they mapped that IP address to a VPN provider whose account was set up from an internet cafe near the house of a friend of DPR.

It looks like they first started suspecting Ulbricht when one of the forum account usernames he used to market Silk Road, "altoid", posted the GMail address "rossulbricht@gmail.com" when looking for technical help. From page 26 of the complaint:

  From further reviewing the Bitcoin Talk forum,
  Agent-1 located another posting on the forum by
  "altoid," made on October 11, 2011, approximately
  eight months after his posting about Silk Road.
  In this later posting, made in a separate and
  unrelated discussion thread, "altoid" stated that
  he was looking for an "IT pro in the Bitcoin
  community" to hire in connection with "a venture
  backed Bitcoin startup company." The posting
  directed interested users to send their responses
  to "rossulbricht at gmail dot com" - indicating
  that "altoid" uses the e-mail address 
  "rossulbricht@gmail.com" (the "Ulbricht Gmail
  Account").

After DPR's mistake of using the same account to market Silk Road and solicit help with an email address, the FBI seems to have used good old-fashioned legwork to subpoena records and build a case against DPR.

Super interesting read!

I am so happy they decided to include comparison operators in text/template and html/template [1]. It drove me nuts to have to write comparison functions and call them from within the template. Yes, it kept some logic out of the template but in my opinion it added an unnecessary layer of indirection.

[1]: http://tip.golang.org/doc/go1.2#text_template

Incidentally, most deadbolts are ridiculously easy to pick. I can get into my front door deadbolt in about a minute with a multitool and a safety pin bent into the shape of a pick with said multitool [1]. Unless you've upgraded your typical run-of-the-mill deadbolt to one with mushroom, spool, or serrated pins [2] it will take roughly the same effort. Those higher-security locks typically run over a hundred bucks and as such aren't what most house builders would put in a front door.

[1]: http://www.crypto.com/papers/notes/picking/

[2]: http://www.lockwiki.com/index.php/Security_pin

Can never turn down an opportunity for a one-liner.

  $ perl -E 'open(my $fh, "<", "/usr/share/dict/words"); my @words = map {chomp; $_} <$fh>; close $fh; say join " ", map {$words[int rand @words]} 1..4'
  menu chemists administrative seeps

Might have to run it a couple of times before you get something that you can memorize.

You may find sshuttle interesting [1]. It's essentially VPN implemented via SSH tunnel.

[1]: https://github.com/apenwarr/sshuttle

That's all well and good, but I have still not given authorization for the use of my network to the malicious user. An open network invites legal dispute as to whether the lack of encryption constitutes implicit permission to use the network [1]. By having encryption, even if easily cracked, I have let the malicious user that they are not welcome on my network and have absolved myself of any responsibility for their actions.

Following your reasoning, my background means that I should know that I shouldn't have a wireless network at all. There are vulnerabilities for just about any method I would use to secure a wireless network.

My important stuff is firewalled within the network. I use WEP because it's the easiest way to give network access to folks I've authorized to use my network while still letting unauthorized users know they're not welcome.

[1]: http://en.wikipedia.org/wiki/Legality_of_piggybacking

Honestly, I use WEP encryption because I know that WiFi security is a house of cards in general. As you've said, it's enough to prevent the typical user from leeching bandwidth.

The nice thing about using WEP is that if someone does end up using my network for something nefarious and I end up holding the bag for it, I (or an expert witness) can point out that WEP is known to be vulnerable in court giving me an out.

Looks like I might end up working Cap'n Proto after all. I've no experience with 0MQ, but it seems if Cap'n Proto's RPC is designed flexibly enough it would at least be able to support exclusive pairs as described on 0MQ's Wikipedia page [1]. I'll try to keep it in mind in whatever proposals I have w.r.t. the RPC design. Thanks for the suggestion, Ben!

[1]: https://en.wikipedia.org/wiki/%C3%98MQ#Technology

I'm not going to lie; it took me a little while to wrap my head around those stubs before implementing a TCP transport and semaphore triggers to unblock outstanding RPC function calls. However, it seemed much easier to do that than write a plugin for protoc to generate code that did roughly the same thing.

I'm currently considering RPC implementations for a personal project I'm working on. Right now I may end up trying Thrift since it seems to support RPC out of the box, but my ultimate goal is to have a WebSockets transport which Thrift doesn't provide. I may end up contributing to Cap'n Proto if it looks like the effort required to get RPC up and running has at least some parity with the effort required to extend Thrift for my needs.

It's clear from your planned use of futures and shared memory that your goal for Cap'n Proto is to make it the go-to library for communication in parallel computing. I'm definitely eager to see Cap'n Proto succeed in that endeavor. JSON is great for readability but it really isn't going to cut the cake when efficiency matters!

Hi, Kenton.

First: thanks for your work on Protocol Buffers. I've used it fairly extensively for RPC communications between C++/Java clients and a Java service. It made things so much easier to get native objects in each language using a well-defined protocol.

One thing that bugged me about Protobuf is that it provided a skeletal mechanism for RPC (e.g. RpcController/RpcChannel) but later deprecated the use of that mechanism in favor of code-generating plugins. Since Cap'n Proto is billed as an "RPC system", do you have plans to include a more fleshed-out version of RPC than was provided in Protocol buffers? Having abstract classes for event-handling and transport mechanisms is a good idea for extensibility but it sure would make it easier for your users if there was at least one default implementation of each.

I imagine that Google has standard implementations of these things internally but balked at trying to support them for multiple languages as an open source project.