Recently, the American public has been forcefully made aware of the existence of various programs by the NSA- including massive infrastructure for intercepting all domestically routed communications to better protect us from imminent foreign threats. With legions of patriotic analysts, the NSA methodically ranks communications on the basis of their “foreignness“ factor to determine candidacy for prolonged retention. Although it was developed with the best interests of the American people at heart, this program unwittingly ensnares communications of purely domestic nature on the order of tens of thousands of incidents per day. These innocent mistakes are putting the agency at a great risk because the 4th Amendment of the Constitution expressly prohibits such affronts to American privacy. Making determinations of foreignness is hard, but to prevent further inconvenience to the American way of life, we should take these leaks as an opportunity for us on the civilian front to aid the NSA by voluntarily indicating citizenship on all our networked communications.

Here, we define the syntax and semantics of X-No-Wiretap, a HTTP header-based mechanism for indicating and proving citizenship to well-intentioned man-in-the-middle parties. It is inspired by the enormously successful RFC 3514 IPv4 Security Flag and HTTP DNT header.

Syntax

The HTTP header, “X-No-Wiretap” takes the value of the current user’s given name under penalty of perjury. The full name must be immediately followed by identity verification in the form of a standard U.S. Social Security Number, formatted with a hyphen “-“ after every third and fifth digit.

Future revisions of the protocol may introduce additional forms of verification, as while the presence of an SSN should be able to lower the foreignness coefficient of the vast majority of domestic communications to well below 51%- initial research seems to indicate that the combination of full first name and SSN is able to reduce an associated message’s foreignness factor by over 76.8% for 99.997% of Americans. However, there is a chance that certain instances may additional require Passport, Driver’s License, Address, Birthdate, Mother’s Maiden Name, and Childhood Best Friend’s Name to further lower the foreignness factor. This capability will be addressed in future versions of the protocol.

What about SSL/TLS?

Of course adding encryption makes it substantially more difficult for the NSA to interpret the content of what a user is sending, and increases the chance that they may unwittingly collect and retain your communications. In order to address these concerns, this proposal necessarily deprecates all the SSL/TLS ciphers in favor of Double CAESAR’13, a thoroughly studied and well-known military-grade solution which offers excellent modes for graceful redegradation.

Isn’t it dangerous to send your social security number in plaintext along with every request?

Conventional security warns of the possibility of man-in-the-middle attacks, but these new intelligence revelations require entirely new types of cryptographic thinking. Here, the trusted entity is not the server acting at one end, it’s not even the user issuing the requests- but rather, it’s the bureaucracy sitting in the middle politely intercepting all traffic for benevolent analysis- protecting your way of life.

One may be tempted to characterize this as a sacrifice of privacy in order to optimize security, but this position is simply naive. Every new progressive initiative of the government advances both fronts- both security and liberty, never at the expense of either. If you take a holistic long term perspective on the impact on a global scale with a vast array of (classified) information sources, there is very little question that you too would arrive at the same conclusions on the genuine merits of this surveillance system.

In this case, the removal of encryption ensures that the government is able to parse the content of messages to identify terrorists. At the same time, the inclusion of the citizenship identification information should give citizens the safety of mind, knowing that their messages will not be stored indefinitely in a NSA datacenter.

What about Identity Theft?

What if you set up a server to transparently capture the browser headers? Any malicious entity could then collect all the social security numbers and real identities of everyone who happened to stumble onto their websites and use the information to sign up for credit cards, create hazardous investments, threaten or blackmail loved ones, and masquerade as a citizen while doing terrorist activities! There isn’t any real evidence that such sweeping surveillance will even substantially reduce the chances of events that are intrinsically outliers anyway. On the other hand, identity theft is a real world issue which affects millions of Americans on a daily basis- and these changes will only make our real problems worse. — Short-Sighted Critic

Our government has to reconcile with the fact that the flow of information has radically shifted in the past few decades- all the previous paradigms of privacy, security and adversaries have been obsoleted. Understandably, they need to create infrastructure to tackle this next generation of attacks. This could mean highly orchestrated attacks being planned online, and the government is justified in trying to exercise every available option to avert the next cyber-9/11. Our adversaries may have no limits to their capabilities, and so waiting for definitive evidence on the efficacy of counter-intelligence approaches is giving them an opportunity to plan their next attack.

When what’s at stake is the American way of life, it’s easy to put aside things that don’t really matter.

If the terrorists do find a way to cheat the foreignness heuristic, that’s not a problem, because this proposal is backwards compatible with the existing catch-all NSA policy. They can always, in the end, ignore the X-No-Wiretap header, but we wouldn’t know so it’d be okay.

When can I use this?

It’s expected that this proposal will breeze through the standardization process- because we as Americans can always get together and do that which must be done in these times which try men’s souls. Browsers should implement the feature as soon as possible, so that people can make use of the increased sense of security and privacy it affords.

If you’re truly eager to try it out, you can contribute to the prototype chrome extension which supports the header injection (the reversal of HTTPS Everywhere, a feature called HTTPS Nowhere hasn’t been implemented yet, but we’re accepting pull requests!). Since this extension is still experimental, inserting your personal identifiable information must be done by editing the source code, but you should expect a more user friendly interface in the next revision. Since it isn’t thoroughly tested, there may be a chance that it fails to leak the user’s personally identifiable information with every networked request, but rest assured this will be fixed as soon as the bugs are made aware to us.

We should all rally behind this proposal for a simple technical solution which will go a great length to simultaneously enhancing both privacy and security, while overall preserving the only thing which matters, our American way of life.

392722_2010404474880_380090264_n

You might have noticed that I haven’t written much for this blog in the past few months. In truth, it’s because of school work, which has never really been something of an issue before. This is, quite probably the least productive stretch of time in my life thus far. I have a suspicion that this issue stems more psychologically than due to some radical increase in work load, but I haven’t looked in to testing that hypothesis (I’ve been collecting data hour-by-hour about what I’ve been doing in the past two years, so I could probably look into it if I were actually interested in that matter). But school’s nearing a close, and hopefully I can get back to a more productive lifestyle, maintaining my blog and most importantly, trying out cool things. I have a few things which I am working on at the moment which should be completed in the coming weeks (though I make no assurances). But since I have an internal goal for writing one blog post per month, I’m going to recycle a project from December of 2011.

Nearly every day, I inevitably end up glancing at my Facebook “buddy list” of sorts, wondering how many people are online. It’s a figure which almost always seems to depend on the time of day, and behaves almost like clockwork, there’s always a massive swarm of people online around 10-11pm, and hardly anyone is ever online at 4 in the morning. I guess the problem with drawing any conclusions from this in particular is how specific a group this graphic represents. It constitutes my friends, and in particular, my Facebook friends. Essentially all of them are people I’ve encountered in real life, and may or may not actually find interest in. But the thing that unites just about everyone is that they’re generally high school aged.

Before going on discussing how pretty of a chart this is, I think it’s worth going through what this chart actually represents. It’s quite easy to tell that this is in fact a polar chart, and on the inner circle, you can tell that it’s a 24 hour clock. Each of the rings represents a friend, and the rings are sorted by the total amount of time spent on Facebook in the given period. So you can see that toward the middle, the graph is almost opaque at every time, whereas on the fringes, the online activity is quite erratic and infrequent.

So, where does this data come from? It’s actually quite simple to get from the Facebook API. I have a cron job which runs every minute to run a FQL request and save the results to a specific log file.

The actual FQL which runs in order to retrieve the list of online users is

SELECT uid, name, online_presence FROM user WHERE online_presence IN (‘active’, ‘idle’) AND uid IN (SELECT uid2 FROM friend WHERE uid1 = me())

Basically, get the User ID, the name, and their online presence state for friends who are either active or idle in the list of the logged-in user. Since Facebook is an OAuth2-type API, you need an access token in order to do anything cool. I just use the Facebook Graph API Explorer to generate my access tokens. Just go press “Get Access Token”, and select (at minimum) the permissions “user_online_presence”, “friends_online_presence” and “offline_access”. Then copy and paste the revealed token into some authkey.txt and you should be set.

I have a python script to go through the log file and to render it as the polar chart which is depicted on the top of the page. The code used for that is frankly atrocious and the output is even more so. Python Imaging Library is used, which is a lovely library, except not for drawing graphics. There isn’t any smoothing or anti-aliasing on the arcs drawn by PIL and they all look hideous. So I render the chart at some absurdly high resolution and down-resize it in GIMP while adding layering, blurs and opacity in order to make the picture somewhat less atrocious. Also, it does’t support restricting the app to drawing a specific day of the week, even though it might be interesting to see the how the trend differs on a weekday versus weekend.

Something interesting about the appearance of the polar graph is that it almost resembles something of a digital fingerprint, and that brings up some interesting privacy considerations. Inside that graphic are the Facebook browsing habits of some two hundred people. There’s the question of how much this changes day by day for users, and to what extent this can be used to identify people. And even if a single ring doesn’t unambiguously represent a single person, the two hundred or so rings of their friends probably goes pretty far into identifying people. There’s also a striking amount of uniformity that says a lot about the type of people who I tend to associate with. Just at a glance, one can tell that there are very few people I’m friends with on Facebook who live in different timezones. Maybe what’s more dangerous than being able to identify a person is to be able to identify what kind of groups that person belongs to. And over the course of a day, just about everyone checks Facebook a few times.

I’ve set some tiny goals for Ajax Animator 0.21/0.22/0.23/0.24/0.25. I’m not really good with version numbers.

0.21 is mostly to work on the collaborative, online, web 2.0 aspect of it. Enabling collaboration is important, and I’m a huge supporter of User Created content (virtually all my projects are open source, and they include some entirely user-created things like my MMORPG, Project Wikify, and a few others). At one point, since the old ajax animator (not anymore) would keep logs of everything previewed (as we needed to convert it to flash to preview). I would enjoy people trying out how things were like. That was in the day where there were to tools: rectangles and sticks, and the lines didn’t tween well. Color picking was unnecessarily complicated, the tweening engine crashed every minute, and couldn’t do anything, etc. Since the 0.2 rewrite, things are much better, but I still miss having those user-management features.

If you didn’t know that, User Management/Sharing has been in the ajax animator for a while. It was frequently added, removed, mutilated, upgraded, etc. I think it was there since the DHTML Goodies days (0.08?). It got removed for a while, got added again, removed, rewritten, and now removed again. I look forward to adding it again.

I guess much of it is already there. The login should look pretty much the same as the old one, but with the whole login thing replaced with a single OpenID box and a login button. I’m not exactly sure what to do after this. I think there should be a little profile box that replaces the login panel. I’m debating whether the profile should house a list of your saved animations, or if it should be nested into that Animation browser (that actually works!). I’m leaning towards the latter. The profile may house a link to your folder in the animation directory, a button to save your edits (as with File->Save->Webserver). Etc.

With that, it would include some form of user management system. I’ve almost completely settled on OpenID because of it’s flexibility, futuristicity, freaking-awesomeness (getting a bit overboard…). I’ve just been surfing the web (Wikipedia stuff) and I’m increasingly interested in OpenID, as it seems much more “ajax-friendly” than I previously thought.

Some time, i’d like to switch to a more scalable app-engine oriented system (it’s already serving up static JS now). I’ll use my server at antimatter15.com more (Java-Enabled), so there can finally be decent flash export :)

One thing that i’d really like, that’s really probably painful, is to better support IE. There’s no problem with IE support in the general components of the Ajax Animator (Tweening/UI/Save/Format/Abstraction Layer/etc), but rendering isn’t very good. I’d like for it to be better. OnlyPaths is already great, but IE support is big for it to become mainstream. I’d like it for use in a more educational and amature(ish) setting, where people have the most use for free/opensource/easy-to-run apps. In education, many people are still using IE, and that’s a big problem.

I’ve been looking into other renderers for the future of the Ajax Animator to run on. For the forseeable future, the editor will be OnlyPaths, because it is the only one that really fits the needs of the project. But it’s built on a less-clean, prototype-like (non-namespaced) foundation, and isn’t built exactly as it should. It’s not up to me, but I think that OnlyPaths should be an editor, rather than a renderer, or at least the renderer and the editor to have very visible lines between. Right now, much of the editor interface is in the renderer. That means a lot of unnecesary work. The addTracker function is currently in the renderer, this is completely the wrong thing. It was fine in the days when it was Richdraw and the tracker was just a blue square, but that’s not scalable. On this trend, you would need 2 copies of essentially the same code (VML/SVG) for the tracker/etc. I’d much prefer to have a interactive-less renderer and addTracker function in the editor, where all the actions are calls to the drawing API. Either Onlypaths has to get a better VML renderer, or we have to switch rendering engines to something like Dojo.GFX or Raphael and port the editor over to the new renderers. I like the current OnlyPaths one a lot. It’s been developed side-by-side with the Ajax Animator, and is very well integrated. I dont like Dojo.GFX too much, because it’s dojo-dependencies, but it’s a very solid and stable framework. And Raphael isn’t as powerful as the current OnlyPaths engine yet.