Pogoplug, the little gadget that turns any USB-enabled drive into a personal storage locker accessible over the Internet, impressed me as much as it did Kevin over at our sister site jkOnTheRun. But I really wanted to learn how exactly it worked. So I reached out to Pogoplug maker Cloud Engines’ chief technology officer, Brad Dietrich, who in the past has worked in digital device startups such as Mediabolic (which has since been bought by Macrovision (s mvsn)). He shared some insights with me via email as the innards of this device, which is a computer in its own right.
Om: Are you using an embedded Linux on this device?
Brad Dietrich: Yes, we are running a Linux 126.96.36.199 kernel on a Marvell ARM SOC. My team and myself have been working in the embedded Linux world for well over 10 years now (my background was at Mediabolic and the digital home) and we are very good at stripping things down to a bare minimum.
Om: Can you share some details?
Dietrich: Since we are so familiar with Linux’s kernel and networking stack, we rely on very little other software than the Linux kernel and the C library. Although the hardware will run the full version of Ubuntu for ARM (and some of our users are running it on their Pogoplugs), we took the approach of owning the majority of the feature stack ourselves so we could produce a good user experience that was fully integrated. We believe that seamless end user integration and location independence is absolutely critical to bringing the complexity of networking devices mainstream.
Om: How does it auto-configure the network connection and overcome some of the challenges posed by firewalls and the heterogeneous nature of home and broadband networks?
Dietrich: First of all, we make some assumptions about what most consumer networks look like today. We have worked with many of the mass market retail routers for many years, and know their idiosyncrasies and standard configurations. As you probably are aware, the security model that many of these devices have always taken is that devices that are physically connected to the LAN side of the Ethernet are implicitly trusted and can immediately receive DHCP addresses and route outbound connections to the Internet. Inbound packets are always denied unless they are responses to outbound-initiated requests. This security model is one of the reasons we chose to make the Pogoplug use only wired Ethernet. Wi-Fi has so many legacy configuration complexities that are nowhere near as transparent to set up.
Om: What happens when Pogoplug is connected to the Internet?
Dietrich: Once the Pogoplug has received a DHCP address and verifies it can speak out to our service on the Internet, technically the device is fully configured and nothing is required to configure. The service will tunnel all requests back from the Internet to the Pogoplug through this outbound connection that is established. If the device is unable to receive DHCP, yet we still have functioning Ethernet, we at least can communicate to the PC over the LAN, and there are fall-back steps to accommodate these more sophisticated network configurations.
Om: How do you ensure that Pogoplug is secure and is accessible for the users?
Dietrich: The only other step that is required in our “activation” is the process of ensuring that a user has access to the device. For this, we make similar security assumptions that the consumer-grade firewall is already making, namely that if the user has physical access to the device at the time the device is first turned on, then they must own the device. We guarantee this physical access by two methods. One, the Pogoplug is on the same LAN as the customer’s PC attempting to activate the Pogoplug; and two, the user has the security code (a 26-digit code) that is unique to the Pogoplug. The result of the user proving this access is to grant that user as the primary owner of the Pogoplug in question, and it is unable to be activated by anyone else until that user unregisters the device from their account.