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.
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.
Where in the complaint do you see evidence of a website vulnerability? The part you quoted just reads to me as describing DPR's use of a VPN, with the "forensic analysis" part referring to analysis of the disk image after the server had already been identified and imaged.
That said, a security vulnerability in the website does seem like a really plausible conjecture: it's hard to write that much PHP code and not screw up somewhere, especially given that he was probably doing most of it himself, without anyone to do independent QA. And even if the site code itself was fine, the Silk Road is a high-enough value target that the FBI might have thought it worth using a PHP 0-day. Once they're into the site, it's probably not hard to get it to dump an IP address or other externally identifying information.
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.
I'm not super familiar with this case or the ATT vs weev one, but I thought I read that the prosecution in the weev trial made the argument that accessing information in the open, like that of server logs is hacking? If that precedent was set, wouldn't that have an effect on when a warrant is required or no? Just curious
No. A warrant means you can do extra special stuff, like search someone's house. With a warrant, you can search for whatever you like, however you like.
... I know that, on May 24, 2013, a Silk Road user sent
him a private message warning him that "some sort of
external IP address" was "leaking" from the site, and
listed the IP address of the VPN Server.
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!
That was my first lesson in validating any external input. Learned the hard way, in my first six months of building websites professionally. Happily, the hosting provider put me onto a helpful tech guy who walked me through what I'd done and how to avoid it. There was a lot less 'common knowledge' and 'everyone knows' in 2001.
...a vulnerability that affected near zero actual servers. (I know because I scanned for it shortly after the announcement) Everyone uses FastCGI or mod_php and friends.
The agent is discussing source code he inspected likely after acquiring an image of the server. The vulnerability you described isn't how they got their information.
I'm reading through it now, but it's still not 100% clarified how they originally determined the true IP and provider of the server. There are a myriad of different ways, though.
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.
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.
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.
> Following your reasoning, my background means that I should know that I shouldn't have a wireless network at all.
It would be argued that you should have taken 'reasonable' measures to prevent unauthorized access. It could then be argued that using WEP is not reasonable, especially it you know it is easily crackable.
Should we lock our doors with bank-vault locks, since we know how easily most common door locks are picked? The fact that an attacker would have to actively bypass the security should be enough for legal purposes. It is not like an attacker could accidentally crack a WEP-protected network and not know they were doing it.
No, nor should we uninstall the default deadbolt that comes with the house and replace it with a simple gate-style lock (you know, the kind you can reach over and unhook).
We should use the default standard method of locking our doors. And our Wi-Fi access points.
Except he's enabled WEP because it's "more convenient" for him. It's still a strong signal that he doesn't want outsiders on the network.
A better door analogy is replacing the deadbolt with a slightly crappier one that unlocks whenever you're in bluetooth range (for "convenience"). Just because the system is "easily broken into" doesn't mean that you're not "breaking and entering" when you break the security and enter the house.
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.
Unfortunately, I have had to enable WEP a few times for certain OS / network card / router configurations, so there are or can be compelling reasons to do this. Pretty sure it was XP though my wife's XP box is working fine with WPA2 on my current router.
However, I try to treat even my home WIFI as if it were a coffee shop. The password is there to keep leechers out, but I still vpn into a more secure location for some tasks, use SSL when connecting to sensitive services, and keep my ports locked down.
The one annoying thing is that you can't do selectively do DNS over the VPN, but that's really only useful when you want to separate work / personal on the same machine at the same time.
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.
Yes, in fact, the next release of Cap'n Proto (v0.4) is slated to include RPC support. There are some hints on what it might look like in the docs already:
The reason Google never released an RPC system together with protobufs is because Google's RPC implementation simply had too many dependencies on other Google infrastructure, and wasn't appropriate for use outside of Google datacenters. There were a few attempts to untangle the mess and produce something that could be released, but it never happened.
The public release had support for generating generic stubs, as you mentioned, but it was later decided that these stubs were actually a poor basis for implementing an RPC system. In their attempt to be generic, their interface ended up being rather awkward. We later decided that it made more sense to support code generator plugins, so that someone implementing an RPC system could provide a plugin that generates code ideal for that particular system. The generic interfaces were then deprecated.
Cap'n Proto also supports code generation plugins. But, as I said, we will soon also have an "official" RPC layer as well -- and it will hopefully be somewhat plugable itself, so that you can use a different underlying transport with the same generated interface code. Anyway, this will all become clearer with the next release, so stay tuned!
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!
I hope you haven't forgotten to see if ICE might work for you, before you go looking at these "new" things (Not assuming you haven't, but it seems ICE fell a little out of hype from the day protobuf launched. I'm not convinced that fall from hype was entirely justified):
I look forward to hearing from you, should you decide to contribute. :) A web socket transport for Cap'n Proto would make a lot of sense, particularly if paired with a Javascript implementation, which one or two people have claimed they might create. I expect it will be easy to hook this in as a transport without disturbing much of the RPC implementation.
One random idea that just hit me if you're thinking about RPC layers anyways. Make sure that Cap'n Proto plays well with 0MQ. They probably do already, but a published example or two demonstrating it would not be a bad thing.
You can certainly send Cap'n Proto messages over 0MQ (or nanomsg) pretty easily -- Cap'n Proto gives you bytes, 0MQ takes bytes. Done deal.
However, supporting Cap'n Proto's planned RPC system on top of 0MQ may not work so well. The thing is, 0MQ implements specific interaction patterns, such as request/response, publish/subscribe, etc. Meanwhile, Cap'n Proto RPC is based on a different, more fundamental object-oriented model that doesn't fit into any of these patterns. A Cap'n Proto connection does not have a defined requester or responder -- both sides may hold any number of references to objects living on the other side, to which they can make requests at any time. So it fundamentally doesn't fit into the req/rep model, much less things like pub/sub. On the other hand, you can potentially build a pub/sub system on top of Cap'n Proto's model (as well as, trivially, a req/rep system).
At least, this is my understanding based on what I've managed to read so far of 0MQ's docs. I intend to investigate further, because it would be great to reuse existing work where it makes sense, but at the moment it isn't looking like a good fit. If I've missed something, definitely do let me know.
The killer feature that I like for 0MQ is that you can support message passing asynchronously, even when the other side is not currently up. For instance in a request/response pattern, one side might go away, get restarted, reinitialize, and then they carry on as if there wasn't a period in the middle where there was no connection. This kind of robust handling of network interruptions is very convenient for many use cases.
However what you describe isn't necessarily going to fit into that. The #1 thing that your description makes me wonder about is whether RPCs are going to be synchronous or asynchronous. So, for instance, if you hand me a data structure with a list objects that are references to data that I want to have, and I decide that I need 10 of them, do I have to pay for the overhead of 10 round trips, or can I say, "I need these 10" and get them all at once?
> support message passing asynchronously, even when the other side is not currently up.
That's probably something that could be implemented in Cap'n Proto as some sort of a persistent transport layer. But since the connections are stateful, it does require that when one end goes down, it comes back up with its state still intact. I have a lot of ideas for how to make this possible it big systems but it's a long way off.
Of course, in the simple case where you do have a defined client and server and the server is only exporting one stateless global service object that the client is using -- which is roughly what 0mq req/rep sockets are for -- then it should be no problem to support this.
> whether RPCs are going to be synchronous or asynchronous
The interface will be asynchronous based on E-style promises (similar to futures). In fact, say you call an RPC which returns a remote object reference, and you immediately want to call another method on that reference. With Cap'n Proto's approach, you will be able to do this whole interaction in one round trip instead of two. This is called "Promise Pipelining". There's a bit (just a bit) more detail here:
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]: http://en.wikipedia.org/wiki/WikiReader