Tag Archives: blog


I’m very excited to have two talks at CCC at the end of the month. The bulk of accepted talks can be seen and voted on at the CCC “halfnarp”.

The first talk is on the Internet in Cuba. It expands upon the recent talk I presented at IMC last month, to provide additional color on what Internet access is really like in Cuba, and what the community there is doing to create LANs and other alternatives to the official but expensive ETECSA service.

The second talk looks again at technology in Pyongyang. Since 2014, there have been a number of talks about the totally closed off tech ecosystem there, but as it ramps up we continue to only get a few glimpses into what’s going on, and it’s getting only harder as the broader tensions ramp up. My goal is to propose a path for getting more rather than less transparency into the picture, because it is a really fascinating place.

The talks should both be recorded, and might even be streamed. If you’re one of the (I hear it could be up 16,000) participants, I hope to see you in Leipzig!

China in 2017

I had the chance to visit China last week and tag along with the tail-end of a longer trip organized around various Makerspaces around the region. This is the first time in several years that I’ve spent a prolonged amount of time in the dense population areas of Beijing and Shanghai, and it was fascinating to watch the evolution that continues in this majority of Chinese life.

The most noticeable change from my perspective is that Beijing and Shanghai are effectively almost cashless. The use of Alipay and wechat pay are ubiquitous, to the point that you feel that you are creating an imposition to shop keepers by paying with cash. While funding your account on either of these services requires a chinese bank account (which itself requires a mainland cellphone number), the process can be short-circuited by making an unofficial exchange with someone willing to send you a personal transfer within the systems. It remains easy enough to find people at hostels, (as well as localbitcoins, I hear) who are willing to trade.

The systems themselves are fascinating to use. Payment to a merchant will automatically cause you to follow the merchants account, typically leading to messages about member cards and discounts. These messages seemed to only be pushed directly in response to a purchase, and weren’t overly intrusive. It seems to be the realization of the business-to-consumer engagement systems facebook and google have been struggling and so far failing to build in the US. Smaller vendors often operate directly as individuals – you type in how much money the bill is, and send it as a direct transfer to an account specified by the waiter or merchant.

This payment structure has resulted in a secondary industry of android-based devices dedicated to sales and scanning QR codes for these systems, as well as receipt printers that turn app orders into printed requests for food or similar.

Apart from the payment evolution, it is really interesting to watch China modernize. Life there now is much more comfortable from a western perspective than it has been in the past, with both a larger presence of foreigners visible and more english available to help navigate. Some distinctive characteristics remain, including a self-interested approach to queuing and different expectations of personal space. Prices in Shanghai have reached parity with those in the west, although cheaper options remain if you look for them.

In terms of Internet connectivity, I was surprised to find that connectivity remained quite similar to what I had experienced in the past. An SSH tunnel to a foreign server was sufficient to maintain email access while I was there, and disruptions I experienced seemed to be much more a function of over-loaded local networks than of more restrictions for international traffic. I talked with a couple different people who mentioned that Astrill continues to not be blocked, and seemed surprised that something so well known continues to operate without disruption.

Privacy issues for City Wi-Fi Deployments

At the end of last month, Seattle posted a request for information exploring the feasibility of a municipal Wireless deployment. With others at the Seattle Privacy Coalition, I draft a response to the city flagging some of the major privacy issues that we hope they will consider in the initiative. I believe these are much broader than just our specific case, and hopefully can help others when navigating the landscape of business models and privacy risks in this area.

Pitfalls of Public Wi-Fi: data selling, tracking of nonusers, injecting ads

Freely available municipal wireless Internet is an exciting service, but there have also been Wi-Fi deployments that have had significant, unintentional impacts on citizen privacy. This brief from the Seattle Privacy Coalition attempts to highlight some of the hidden costs that the City of Seattle should watch out for.

Many freely offered commercial wireless systems make money by selling analytics about customer behavior. An example is the Google-sponsored Wi-Fi provided at SeaTac airport and used in Starbuck’s coffee shops around town. While free to users, these services make money through the sale of user data to third-party advertisers.

This practice is especially questionable when low-income communities are targeted with ‘free’ services, greatly increasing the surveillance burden for an already vulnerable population.

Tracking and profiting from the sale of people’s behavior for advertising or other commercial purposes is a troubling practice at best, but it clearly goes against the public interest when it targets communities depending on a service as their primary or only access to the Internet.

Another threat to privacy found in commercial wireless deployments is the ability to track and analyze the behavior and location of every person in the vicinity, whether they are using the service or not. Cisco’s Meraki, a popular retail wireless product, advertises that it can “Glean analytics
from all Wi-Fi devices connected and unconnected.”

The city, perhaps unlike a business, has a responsibility to protect citizen privacy, and we think it would be irresponsible to track the locations of unconnected devices that have not explicitly opted-in to such a program.

From the start, the City must have a clear understanding of how collected data will be used, and it must not collect any data without the consent of the people tracked. Few citizens will welcome long-term, involuntary behavioral and location logging of their personal electronic devices by the government.

Finally, there are instances of wireless service which are based on a business model of injecting advertisements into web browsing. We merely note this is impossible to do without severely compromising the security of the Internet experience, and we do not believe that any trade off of benefits involving such approaches are justified.

We welcome additional digital connectivity through the city, and are especially excited by the potential for more equitable accessibility. There’s great potential in this technology, and while some incarnations impinge user privacy, many others have found successful models that avoid
such pitfalls.


I’ve started to dive once again into the mess of connection establishment. Network address translation (NAT) is a reality today for most Internet users, and poses a significant hurdle in creating the user-user (or peer-peer) connections. NAT is the process used by your router to provide multiple internal (192.168.x.x) addresses that are all only visible as a single external address on the Internet. The challenge caused by this device is that if someone outside wants to connect to your computer, they have to figure out how to get the router to send their traffic back to you, and not just drop it or send it to another computer on your network.

Without configuring your router to add a ‘port forwarding’ rule, it isn’t supposed to do this, so many of the connection establishment procedures are really ways to trick your NAT into forwarding traffic without realizing what’s happening.

There are two main protocols on the Internet today: UDP and TCP. UDP is stateless, each “packet” of data is its own message, and is self contained. In contrast, TCP is a representation of a longer “stream” of data – many messages are sent with an explicit ordering . TCP is much harder to trick routers into establishing, and there has been little work there.

The current generation of p2p systems are led by high-bandwidth applications that want to offload traffic from central servers in order to save on bandwidth costs. Good examples of these are Google’s hangouts and other VOIP (video over IP) traffic.

These systems establish a channel to send UDP traffic between two computers both behind NAT routers using a system called ICE (interactive connectivity establishment). This is a complex dance with multiple sub-protocols used to try several different ways of establishing connectivity and tricking the routers.

One of the key systems used by ICE is a publicly visible server that speaks a protocol called STUN. STUN servers provide a way for a client to open a UDP connection through their router to a server that is known to be able to receive messages, and then learn what that connection looks like outside of its router. It can then provide that external view of how it’s connected to another peer which may be able to send messages to the same external address and port and have them forwarded back to the client.

One of the unfortunate aspects of this situation is that the complexity of these systems has led to very few implementations. This is unfortunate, since the existence of libraries making it easy to reuse these techniques can allow more p2p systems to continue working in the modern Internet without forcing users to manually configure their routers.

I’ve started work on a standalone go implementation of the ICE connectivity stack. Over the weekend I reached the first milestone – The library can create a STUN connection, and learn the external appearance of the connection as reported by the STUN server.