This time, it's personal.

A few people have asked me how secure CypherPoker is, and my reply is usually something along the lines of “that’s a tricky answer”.

The problem I have in explaining is two-fold: I’m not a cryptographer, and we’re not exactly comparing apples to apples when it comes to similar cryptosystems.

But I’ll give it the old college try :)

I’ve been coding for over a couple of decades now so I’m not exactly an amateur, but I’m not at any level that I could honestly provide a theoretically-sound answer.

Still, the fact that the SRA cryptosystem is a close cousin of RSA should provide some realistic answers provided by people far more knowledgeable than me.

Cryptographic Security

The current state-of-the-art for RSA security is 2048 bits. The equivalent to this is 256 CBL in my implementation of SRA (just divide the number of bits by 8). This is considered infeasibly difficult to crack using known attacks and so is considered secure. As computing power increases so will the ability to crack smaller keys so their length must be increased.

In SRA the key length, or CBL, is purposefully variable to accommodate a broad variety of processing power and desired performance. There is no bottom or top end so there is nothing to stop players from cranking it up really high, but the higher the security the lower the performance.

Because RSA and SRA are closely related they are both potentially susceptible to quantum attacks via something like Shor’s algorithm. In both cases this attack centers around finding the factors of the shared prime modulus value. The largest number factored so far is 56153, which is far below any current security threshold, but the eventuality looms nevertheless.

However, there are a couple of wrinkles with the quantum approach:

First, it still takes time to find the factors of the prime modulus value, albeit far less than by using classical computing. With RSA the public key doesn’t change very often so we have a large-ish window of time in which to find its private counterpart. With CypherPoker (SRA) the keys need to remain secret only for the duration of the game after which they must be revealed in order to verify the game. Although the re-keying protocol allows the game to continue whenever a player drops out of the game for any reason, it is still useful to have their missing encryption keys at the completion of the game if we want to be extra thorough in our post-game verification. In effect, breaking the encrypted session would have to be done while the game is still active, which is usually not a very long window of time. Once a game is complete, breaking the encryption is potentially beneficial.

Second, with RSA we know one half of the keys (public) used for crypto operations. Although SRA derives and uses its crypto keys in a similar way to RSA, both keys are private until the end of the game. Again, I’m not an expert in the field but it’s my understanding that this effectively removes one of the known values in Shor’s algorithm, and that sounds like a potential roadblock.

Additionally, with CypherPoker’s re-keying/dropout support the ability to generate new crypto keys at somewhat arbitrary intervals provides extra foils against attackers in games where cards are returned back to the deck. With certain games like Texas Hold’em this wouldn’t apply, but it’s certainly a plus for future implementations.

Software Security

Besides the security provided by the cryptosystem, the CypherPoker software provides a couple of additional security features.

These include storing sensitive data like crypto keys in secure locations when not actively in use, and the asynchronous Rochambeau protocol which prevents collusion when determining the initial dealer for a game.

There are other security features that can be added in future versions, some of which should be quite easy to implement. For example, we can automatically turn any visible private cards face down when the player is not viewing them. This would reduce the possibility of any malware on the player’s machine being able to send screen captures of the game window to attackers. Obviously this isn’t a perfect solution, but every little bit helps.

Finally, the fact that CypherPoker is entirely open source has two implications:

First of all, anyone can update and release the software with security features that I haven’t even thought of, and these features can be made available immediately. I genuinely don’t believe that established online poker sites promote cheating, but the fact that they use primarily proprietary software means that players are at their mercy to fix any software security problems.

Secondly, CypherPoker needn’t be exclusively for Adobe’s runtimes. Because the communication protocols are fairly generic I’ve pointed out that JavaScript would make a good candidate for an initial port of the software, and I see no reason why other languages and runtimes couldn’t be used as well. If a JavaScript version turned out to be riddled with security problems then players could easily switch to a C++ version, Python verison, Objective-C version, Java version, and so on. All of these versions should be able to talk to each other so players would be free to make informed choices about which implementations are suitable for them.

So … how secure is CypherPoker?

It would be irresponsible for me to claim that it’s perfect but from my analysis, for what it’s worth,  it’s pretty darned secure. I recognize that there’s always a need for improvement, but when CypherPoker is compared to similar software it’s clear that the product is operating on solid foundations.

October 8th, 2015

Posted In: Development / Coding, Security

Tags: , , , , , , , ,

Leave a Comment

It was me. I did the CypherPoker.

Don’t worry if you’ve never heard of it. Unless you’re not part of the humble 23-member CypherPoker subreddit or one of the 6 interested members following the Github repository, I can’t imagine how you’d be aware of the project’s existence let alone guess who done it.

I’m going to leave the project’s history and philosophy for my other blog so here I’ll just cover the more technical details.

Since you probably don’t know what it is, CypherPoker is a peer to peer Texas Hold’em poker game based on the work of cryptographers Adi Shamir, Ron Rivest, and Leonard Adleman (“Mental Poker“). All of the gory details can be found on the GitHub wiki and for the squeamish there’s the lighter “Midnight” series.

To nutshell it, CypherPoker eliminates the need for a server (trusted third party) during game play. Through the dark magics of cryptography, players conduct games entirely between themselves. When not playing with known players (friends, for example), the game provides the foundation for anonymous third-party services like multi-signature cryptocurrency escrow, player introduction and reputation rating, and game verification.

I’ve read a bunch and asked some pretty specific technical questions at local Bitcoin meetups while simultaneously poking the client API; I have a pretty good handle on how to proceed there. Regarding the anonymity part, I’m pretty confident about that too. I’m presently finishing up the Rochambeau protocol which has so far demonstrated that the optimizations planned for the game will make things significantly faster, and I’ve collected the building blocks for verification and reputation rating services. Not just whistlin’ Dixie here.

There’s still a lot to do but the game part is just about done, at least in terms of functionality. Seeing a greater benefit, I spent more time creating a customizable skinning system than an actual skin so the game don’t look so great. But it needn’t not look so great and hopefully not for long.

Rather than discussing the other merits of the plan like I did through Subreddit comments I thought it would be better to jump directly into a direct, barrel-bottom-scraping example:

Since it’s easier and more familiar than doing calculations with 0.004237 Bitcoin, let’s say that the average buy-in for a 3-player game is $1. We’re really low-balling here.

The winner of our cheapie game would walk away with the equivalent of $3 minus the fee for any services we may have provided. Let’s say that our fee is a paltry 1% or $0.03. Balls are super low here.

Now let’s say that we have an old, slow, dual-core clunker lying around on which we can run the game introduction, verification, and escrow (GIVE) services. Our old beater can completely verify and dispatch a game roughly every 5 to 10 minutes per core. Maybe it’ll be faster if verification fails or the crypto being used is weaker but since our balls are already drooping so low we’ll assume the worst-case: 10 minutes per game per core.

This means that our computer will be able to verify up to about 12 games per hour, or 288 games per day. At $0.03 per game, that will produce a daily takeaway of $8.64. We can multiply by a chronically short 28-day month to arrive at a pessimistic total of $241 per month, or $2,892 per year.

We can use an electricity cost calculator to calculate the monthly cost for our highly inefficient box running non-stop in a secluded corner of our apartment at roughly $14 with taxes. Over the course of the year that’ll add up to $168.

In addition to electricity we’re paying for an expensive internet connection, and not with the cheapest provider either. We missed the cut-off date for the introductory discount and we’re paying the regular $108 per month after taxes. Yikes! And don’t forget the $75 we’re shelling out for installation and activation. In the end our internet connection will cost us $1,371 for the year.

Putting it all together, that’s: $2,892 – $1,371 – $168 = $1,353 per year or $112 per month.

If we want to withhold 40% of $2,892 for the maw of some licensing body or state or whatnot we can squeak by on $15.60 per month. After that, each additional processor core or machine would earn about $130.60 more per month (after all deductions), until we hit our bandwidth limit.

Even with fluctuations in the price of Bitcoin, this very pessimistic model could produce enough for an occasional beer. Or it could contribute to a bill payment or help put a little extra food on the table. Whatever turns you on.

But as I said, that’s the bottom of the barrel.

As soon as we adjust any of the unjustly inflated figures I used in my illustration, the outlook becomes rosier. With a more realistic $5 buy-in and a faster quad-core machine capable of verifying closer to the 5-minute limit (about 1100, 3-player games per day), we can calculate a profit of just over $2,600 per month even if all the other numbers and deductions stay the same – including the accursed 28-day month.

Of course this assumes that the machine operates at 100% capacity so we have to tamp down our optimism somewhat, but even if my late-night math is a bit off it’s numbers like these that make me believe that someone out there will find utility in running the GIVE services and in time expand them to include robust and open collusion detection. Chances are pretty good that the equipment that you may be reading this post on, and the connection over which it was delivered, are good enough to give it a whirl.

I’m also fairly certain that existing mainstream client-server operators would be able to fish some nice savings out of this idea but I wouldn’t expect that to happen overnight. The amount that they’ve invested in technology and ongoing operations, not to mention the pains of converting to something significantly different, are unlikely to make CypherPoker an attractive prospect in the short term.

On the player end of things I suspect that when not free, the idea of playing a provably fair game of poker with friends for only the cryptocurrency transaction fee, or with potentially anonymous strangers for a slightly larger one, might be attractive. As I’ve demonstrated, the buy-ins can be very small so no one needs to feel uncomfortable with how much Bitcoin they’re investing. In other words, the broad on-ramp slopes gently and is invitingly lit.

There are many additional opportunities that I can foresee around customizing and adapting the software that extend well beyond peer to peer poker but I don’t want to get ahead of myself; there is, after all, enough for me to be excited about right here. 😉

To verify the following message you can retrieve my public PGP key from the first Reddit post I wrote, the main source code license, or by key ID (677BCC9B) from most certificate repositories like,,, or

Version: GnuPG v2



September 19th, 2015

Posted In: Development / Coding, Internet / Web

Tags: , , , , , , , , , , , , , , ,


This is a somewhat tongue-in-cheek rebuttal to Curtis Franklin Jr.’s InformationWeek article, “9 Reasons Flash Must Die, and Soon“.

I’ve employed his article almost verbatim, changing only a few key terms and occasionally adding a few words to demonstrate how the current hysteria about Flash security could readily be turned against JavaScript, HTML5, and browsers. The major difference between Curtis’ post and mine, like most current articles critical of Flash, is that I provide links to back up all of my assertions whereas other articles rely primarily on ambiguous and sometimes entirely false rhetoric.

JavaScript is hungry

Let’s run this down: The world is going mobile. There’s no doubt that more and more of our computing lives happen on handheld devices. Those handheld devices are getting smaller. It won’t be long before you can use the edge of a smart phone to take care of unwanted body hair. And with the thinner devices comes a smaller set of batteries.

Because JavaScript is an interpreted language, it’s heavy — so heavy that, in conjunction with the way HTML renders video, it’s an absolute battery killer.

And it’s not just a battery killer on mobile devices. Want to see how quickly the battery on your laptop can run to zero? Load your browser with a bunch of JavaScript-heavy pages in tabs and let them all run. You can hear the giant electronic sucking sound as the battery winds toward zero.

JavaScript is naive

Many development systems have numerous internal checks to make sure that the code developed is safe for distribution to the big wide world. JavaScript isn’t one of those systems. JavaScript has, historically, allowed all kinds of code to run. To make life better, JavaScript has provided access to a variety of juicy system components in its attempt to allow the best and most impressive animation.

Now, the good folks at W3C have improved JavaScript and its security over the years, but there are still several qualities that make JavaScript a security weakness — we’ll get to those shortly. In the meantime, know that JavaScript’s naive trust in developers and code would be charming — if it were running on someone else’s system.

Many browsers are closed

There’s a lot of really good software out there that’s proprietary. There’s also a lot of very good software that comes from one or another open ecosystem. When you’re looking for weakness, though, a closed system can legitimately be considered a point that’s not particularly strong.

It’s not only that many popular JavaScript interpreters, the browsers, are closed: They’re really pretty darned closed. That closed nature means that many of the security researchers who might work on improvements in open systems are locked out — something that seems to be of little concern to criminals and hackers.

Funny, that.

H.264 is YAMF (Yet Another Media Format)

When you want to save a graphics file or animated selection, you’re generally presented with an extensive list of options. The newer* H.264 video format, with its lovely .mp4 (a format used by nothing else) presents you with yet another media file type to keep track of, store, and consider in the panoply of files that go into a modern website.

Is a file format inherently evil? Well, no, but life is complicated enough. When there are animation options available that don’t require you to use YAMF, do yourself a favor and cut through the media clutter.

* – Newer than Flash

JavaScript isn’t HTML5 isn’t ActionScript

HTML5 is erroneously typified as the new foundation of Web page development and that it eliminates virtually all need for Flash. And here’s the thing: HTML5 is not a programming language despite notable similarities to HTML4. Flash uses ActionScript which is a close cousin of JavaScript, the actual native programming language of the modern browser.

Flash isn’t the single most complicated programming environment to learn and use, but unless you live your entire professional life inside the Adobe Creative Cloud it’s different from any of the other languages you use (except JavaScript and other ECMAScript-inspired languages). Who really needs that kind of complication? Go with an established standard, and use the time you save for more productive activities — like watching more cat videos.

Browsers are Whack-A-Mole Central

Browsers have presented such a rich set of targets to hackers that developers have spent the last decade (and more) chasing an ever-evolving series of vulnerabilities and exploits. And the nature of browsers means that this game is going to continue.

To a certain extent, this is a game that every set of developers plays with the hackers determined to keep them busy. In browsers’ cases, though, their nature as integrated development systems, interpreters, and embedded technologies means many more holes in which those darned hacker-moles can hide. Not even W3C’s standards can provide enough recommendations to use on their pointy little heads.

Browsers let you be stupid

Remember that game of Whack-a-Mole we mentioned? One of the ways that browser programmers deal with the exploits is by releasing updates. And users of the browsers can blithely ignore each and every one of them.

There are thousands of users now using versions of browsers that date back years — versions filled to overflowing with known vulnerabilities and problems. If some of those users are on your payroll, then they might well provide a path from their funny coffee-break animated shorts straight into your corporate files.

JavaScript makes browsers more complicated

JavaScript is most often deployed as an integrated interpreter. On one hand, that means that JavaScript elements can be active as soon as they load on a Web page. On the other, allowing that “always on” capability means your browser gets heavier and heavier, with a number of side effects — all of them bad.

Heavy browsers are less stable, more power-hungry, slower, and less secure. That combination is one of the reasons LinkedIn and Facebook announced that they’re dropping HTML5 and JavaScript in favour of native code by default.

Now, if you then want inetractivity, you have to go into the controls and re-enable JavaScript — yet another complication.

Browsers kill productivity

Have you ever found a great Web video and then another, and another? Then you looked up and an hour had passed? So have your employees. And we’re blaming browsers.

Cute Web video is the greatest enemy of productivity since March Madness. Without all those nifty singing cartoons about the latest crop of moronic politicians, we could all probably work three-day weeks and get as much done.

Darn you, brilliant video producers!

See, an article like this is proof positive that you don’t need Flash to take up your time. Great sarcasm can do that job just fine, thank you.

July 20th, 2015

Posted In: Development / Coding

Tags: , , , , , ,

Leave a Comment

As I was re-reading an earlier post about HTTPS I remembered one other point I wanted to make about encrypted web sessions: they’re not always necessary and may even be helping to crack security rather than enhance it.

First let’s put this into context:

“We can end government censorship in a decade,” [Google’s Eric] Schmidt said Wednesday during a speech in Washington, according to Bloomberg. “The solution to government surveillance is to encrypt everything.”

It’s interesting to point out that Schmidt is talking about censorship, not surveillance or attacks, but let’s leave this point to another day. Let’s also put aside the issues that I raised in the earlier post. Instead let’s look at the necessity to “encrypt everything”.

Sure it makes sense to encrypt packets going over a public network if you’re sending things like login credentials, but encrypting every single web request does absolutely nothing to protect your privacy. In theory, neither a third-party interloper nor the government would be able to read the contents of the exchanges, but information such as the source IP of requests and the target destination – the metadata – are still completely out in the open; they have to be in order for packets to be correctly routed (and easily blocked/censored). This information leakage is addressed by anonymizing networks like Tor but that gets a little too technical, not to mention laggy, for most people’s purposes.

Besides, if you like to browse the local news during your morning poop, do you really need to add the extra latency and overhead of HTTPS? Unless you’ve signed into the site or some related service provider, there is no advantage to encrypting something that every eavesdropper can inspect. They’d still know which site you’re accessing and can easily find out where from. The contents of message are plainly available for them to view from the host site, as they are for everyone. In fact, unnecessarily encrypting such data opens the door to known-plaintext attacks and potentially weakens security. With every new request attackers gain additional plaintext and ciphertext samples to work with while you’ve gained nothing but a few extra moments to yourself while your device negotiates the encryption.

I’m not a cryptographer but I have a good understanding of HTTPS and although I have no examples to demonstrate my final point it seems pretty self-evident. Unfortunately, I haven’t heard or read these “encrypt everything” criticisms anywhere and it’s concerning that this headlong plunge is being accepted with virtually no discussion.

That said, encryption is extremely useful and has many applications — but it’s also a tricky tool to wield. There are many ways that naive implementations and uses can undermine the security that encryption can supply and the “encrypt everything” movement doesn’t help matters with its broad-brush approach. What we really need is a nuanced discussion, not a sledgehammer.

March 25th, 2015

Posted In: Government, Internet / Web, Privacy / Surveillance, Security

Tags: , , , , ,

Leave a Comment

When I had to find a file in a remote SVN repository the other day I figured there had to be something a little easier than either downloading the entire repository and searching for the file locally, or using a convoluted command to grab the entire list of files. Unfortunately, I couldn’t find anything.

So I wrote this Adobe AIR thing:


For now the utility is very simple but I’m sure I’ll be adding more options as I need them. I kept the thing running for four days straight during my last bit of testing so I’m feeling pretty good about its reliability so far.

I’m planning to create a standalone Windows installer out of some future version so if you find this software useful and have suggestions on how to improve it I’d love to hear from you – please leave a comment below.

P.S. Thanks for another mention, Adobe. You’re starting to make me blush.

November 20th, 2014

Posted In: Development / Coding

Tags: , , , , , ,

Leave a Comment

MovieClips have been the stalwart workhorse of Flash since the very earliest days of ActionScript, so I’ll skip the details and gushing adoration and instead move on to some of the shortcomings:

  • MovieClips only play forward from the current frame. When building out animations without extra MovieClip functionality, playing animations backwards — a character in a game reversing, for example –requires a whole new timeline with the animation reversed. This produces a little extra memory overhead, even if symbols are re-used, but more importantly makes cross-linking the “forward” and “backward” clips challenging. For example, if a character is in a specific position on frame 5 of a “forward” animation, that frame might appear in frame 45 of the “backward” animation.
  • MovieClips only play at the global frame rate. Effectively, your game character can only run at one speed unless you include other MovieClips and then match them up, as best as possible, to the target speed.
  • MovieClips play holistically. When you play them, you must monitor their current frame if you want to stop at a specific point otherwise they’ll play all the way through. If you want to do this backwards, that’s even more work. If you want to play at a specific rate, ditto.
  • MovieClips have no triggers. If you want to know if frame 5 (or some label) has been reached, for example, you once again need to monitor the clip. Setting up multiple playback monitors is a bit of a pain.

So you can now probably guess what SwagMovieClip does.

As with most of the SwAG classes, SwagMovieClip doesn’t make assumptions about how it’s going to be used. You can either extend it:

import core.instances.SwagMovieClip;
public class myMovieClip extends SwagMovieClip {

…or you can instantiate it (just make sure to pass a reference to the MovieClip instance you want to control to the constructor):

import flash.display.MovieClip;
import core.instances.SwagMovieClip;
public class myMovieClip extends MovieClip {
   var swgClip:SwagMovieClip;
   public function myMovieClip() {
      this.swgClip=new SwagMovieClip(this);

If you’re extending SwagMovieClip, all of the class’ methods can be invoked using simply “this”. For example, to play the clip 3 times at double speed from the “startAnimation” frame to the “endAnimation” frame would look like:

this.playRange("startAnimation", "endAnimation", false, true, 3, 2);

Using the instantiation method, this would be:

swgClip.playRange("startAnimation", "endAnimation", false, true, 3, 2);

As you can probably guess, the playRange method plays from a starting frame (label or index), to an ending frame (label or index), optionally resetting to the start of the animation when done, optionally looping (including a specified number of loops), and at an optional playback speed (2 for double speed, 0.5 for half speed, etc.) This works just as well if the starting frame comes after the ending frame — the clip will play backwards with the specified parameters. Essentially, this one function covers the first three shortcomings I mentioned above.

A related method is playToNextLabel which, as the name suggests, will play the clip from its current position with the supplied parameters until the next label is detected. As with the playRange method, the label might precede the current (starting) frame. Here’s the method signature from the SwagMovieClip class showing all the parameters:

playToNextLabel(startFrame:*, includeLabelFrame:Boolean=false, resetOnEnd:Boolean=false, loop:Boolean=false, repeatLoops:uint=0, playSpeed:Number=1)

The addition of a pause method might seem a little redundant but it comes in handy when you need to determine if an active animation is currently in progress (and paused), or simply stopped. One great reason for wanting this information is to know whether to play out the remaining animation loop such as when a game character is coming to a rest after moving. In fact, games are primarily why I built SwagMovieClip (I used similar functionality to control the animations in the Sidekicks vs. Villains game).

Along these lines I also added a frame trigger mechanism, a method call that’s made whenever a target frame is reached during an animation. Here’s an example (minus the “this” or “swgClip” part):

public function myFrameTrigger():void {
 trace ("Frame 9 was just reached in the animation");
 addFrameTrigger(9, myFrameTrigger);

Obviously I skipped a detail; the addFrameTrigger call belongs in a function somewhere, but otherwise this is pretty much all you’d need. In this case, the myFrameTrigger method will be triggered any time frame 9 of the animation is reached. Since the other methods (playRange, etc.) are responsible for actually starting the animation, all of their features can be used in combination with addFrameTrigger. Here’s a slightly extended example from the one above:

public function myFrameTrigger():void {
 trace ("Frame 9 was just reached in the animation");
 addFrameTrigger(9, myFrameTrigger);
 playRange (10, 8);

Here we’re playing the clip backwards from frame 10 to frame 8 (all other parameters are default — no looping or custom speed), and the myFrameTrigger method should be invoked on frame 9 of the animation. To loop the animation 7 times (stopping on the last frame), at half the current frame rate, the same code would be updated to:

public function myFrameTrigger():void {
 trace ("Frame 9 was just reached in the animation");
 addFrameTrigger(9, myFrameTrigger);
 playRange (10, 8, false, true, 7, 0.5);

Every time frame 9 is encountered here during playback our trigger will be invoked.

Triggers are useful for figuring out how a game character is supposed to be interacting with an environment, for example. If your game character is picking something up from a table, the target object should be “attached” to the character’s hand only when the hand animation is at a certain position. This isn’t hard to achieve by hardcoding frame values into your code but becomes cumbersome if you need to change the animation length, and even more difficult when you need to start playing the animation in various non-standard ways.

Most of SwagMovieClip‘s other functionality comes straight from MovieClip along with expected behaviours. As with any other SwAG class, I won’t recommend using SwagMovieClip unless you actually have a need for such functionality (why bloat your code?) but if you find you’re struggling with customizing your MovieClip animations then this might be worth a gander.

P.S. Thanks for another mention, Adobe!

September 19th, 2014

Posted In: Development / Coding, Internet / Web

Tags: , , , , , , , ,

One Comment

SocialCastr is, in a nutshell, a censorship-resistant, peer to peer, personal broadcasting system.

You can grab yourself a compiled copy here:
And you can download the source code here: (you’ll need Adobe Flash to compile it at the moment)

SocialCastr works with Adobe’s RTMFP, a UDP-based protocol for low-latency peer to peer data delivery. The latency is low enough that you can comfortably transmit audio/video streams from a home computer (with a typical residential network connection), among other neat things — I covered a few in a previous post.

What makes RTMFP especially interesting is how it’s able to propagate things like audio/video streams to other peers. When doing so, you only need to send data to two or three peers and they in turn re-distribute that data to a few others peers, effectively amplifying your bandwidth. This means that you can send data (like an audio/video stream), using a standard computer with a basic internet connection to a potential audience of millions. At least in theory (I was never able to get an audience of millions to test with).

Like most peer to peer protocols, RTMFP depends on a centralized host to introduce peers to each other — the Rendezvous Server. I went over a few options for this in that previous post I’d mentioned above. For the SocialCastr project I decided to test with Cumulus since it’s open source and can eventually be bundled into the application package. Plus, Cumulus is programmable via LUA so it’s a really nice option. You’ll find Cumulus (including the C++ source code), in the GitHub repository for SocialCastr. You can also go with Cirrus or Adobe Media Server, and ArcusNode for Node.js seems like another good alternative (though I haven’t tested it).

SocialCastr uses a “Live Timeline” system — synchronized events like live audio and video effects. The audio and video stream continue to run as-is “beneath” the Live Timeline with the effects applied in realtime on the peer’s computer/device. Although I’ve only tested a couple of effects like video fades and blurs, it can support much more: subtitles, picture in picture, starting or cueing pre-recorded video/audio,  Pixel Bender filters, graphical overlays, audio effects (echo, pitch shift), and so on. Creating a LiveTimeline effect requires only that your class extends the socialcastr.core.timeline.BaseTimelineEffect class and that it then be triggered somehow during a broadcast (I used keystrokes for this). You can see this in action in the socialcastr.core.timeline.SimpleVideoEffect class.

On top of this, I built SocialCastr to be very customizable. The web-based SocialCastr player (Receivr), for example, can be entirely stripped of any identifying UI elements. You don’t like the logo I designed? No problem, just tell the player to strip it out. Or use your own. Up to you.

With SocialCastr I had to deal with the problem of connecting people to each other. Basically, once connected to the Rendezvous Server (to which everyone is connected), how do you establish private or semi-private groups without first agreeing to specific group names or specs?

I did this in one-and-a-half ways:

  1. The AnnounceChannel (socialcastr.core.AnnounceChannel), which all peers join in order to get a list of broadcasters. It’s essentially a public directory of everyone who’s currently connected and broadcasting.
  2. The SocialCastr ID system (socialcastr.core.SCID), which is used to connect a peer directly to an existing stream identified by the SCID (read more about it here). The SCID system runs on top of the AnnounceChannel (hence the “half”), but bypasses the AnnounceChannel’s default “list all broadcasters” call.

This is something that sometimes trips people up when they first start working with RTMFP (or any p2p technology, actually). I don’t know if the AnnounceChannel is the most elegant solution, but it certainly works so I figure it might be a good launchpad for someone trying to do the same thing.

So as with all the other projects I’ve posted about, even if SocialCastr isn’t the type of software you might end up using, it might at least help you to work around some of the hurdles and headaches of getting a robust peer to peer network up and running with RTMFP. If you’ve read about how peer to peer networking works in SwAG, you’re already halfway there.

P.S. Thanks for the mention, Adobe!

September 4th, 2014

Posted In: Internet / Web, Privacy / Surveillance

Tags: , , , , , , , ,

Leave a Comment


Node-RED in a Nutshell

Roughly a year ago the folks at IBM Emerging Technology started work on Node-RED, a solution to the problem of a lack of “tools that make it easier for developers at all levels to bring together the different streams of events, both physical and digital, that make up the Internet of Things.”

This was a bit too heady for me so I decided instead to look at some of the “flows”, the projects that Node-RED uses, as a sampling of what the software can do. Here are a few:

  • Weather reports to SMS and MQTT topic: “…a couple of flows to read weather forecast info from the BBC weather site using RSS. The feeds are specific to my location so should be changed for your own. The output is directed to 2 nodes, one for Twilio to send a SMS, the other to publish to a MQTT topic that in my case has a printer listening to it.”
  • Twitter Sentiment Analysis: “This flow listens for tweets mentioning a specific term, passes it through sentiment analysis and then routes the messages to one of three outputs depending if the sentiment is positive, neutral or negative.”
  • Turn off HDMI connected TV when leaving WIFI + presence dashboard: “If the user leaves home with the phone and gets disconnected from the WIFI the attached TV gets turned off over HDMI CEC. All tested with a Nexus5, Raspberry Pi and a old Philips LCD TV.”

Clearly Node-RED has a wide range of applications, but what makes it truly unique is that it simultaneously eschews traditional code while favouring visual design. Some JavaScript is still in there, but it’s minimized.

Furthermore, once a flow has been created and tested, it can be packaged into independent npm modules (for Node.js), to distribute and use outside of Node-RED. I think that’s pretty neat.


The one downside was that it’s a bit tricky to get running if you’re not up to snuff with Node.js, so I whittled it down a bit (results below).

It made me wonder if standalone flows couldn’t be distributed with Node.js in the same way; I think this makes for some neat projects and interesting opportunities.


Step 1: Download: Node-RED_0.8.1ws (The “ws” stands for Windows Standalone — it should theoretically run from a thumb drive).

Step 2: Unzip anywhere you like and run the included “Launch.cmd” file.


Step 3: Use it.

The launcher will open Node-RED in a new process window…


…and then launch your default browser to connect to it. If your browser opens too fast you might get a “connection rejected” error; just wait a few moments for the Node-RED server to start and reload the page.

To disconnect and shut down Node-RED, simply close the open process window.

After you’ve tried this out you might want to swing on by the “Creating your first flow” page to get better acquainted.

N.B. I’m not affiliated with either Node.js or the Node-RED project so everything here is 100% unofficial.

Update, October 23: I’ve re-packed the standalone with the newest version of Node-Red (0.9.0): Node-RED 0.9.0ws

August 27th, 2014

Posted In: Development / Coding, Internet / Web

Tags: , , ,



When the ActionScript VM gets it wrong, sometimes it gets it really wrong. Makes you wanna drink.

Take the following runtime error:

TypeError: Error #1034: Type Coercion failed: cannot convert to ca.patrickbay.MyClass.
 at ca.patrickbay::MyClass/onTimerEnd()[C:\Users\patrick\Desktop\project\ca\patrickbay\]
 at flash.utils::Timer/tick()

Okay, obviously MyClass has a problem on line 375. Seems it should be using a CustomEvent type but it’s using a MyClass type instead. Clearly this is an easy fix. Here’s around line 375 of MyClass:

 var event:CustomEvent = new CustomEvent(CustomEvent.NOTIFY); 

Hmm, looks okay. I check both this class and CustomEvent to make sure they’re both actually the same thing … only one file of each, and renaming causes the compiler to complain, so they’re okay. Custom event does have a NOTIFY property. All good there.

The class paths are all okay and there are definitely no other conflicts. MyClass is extending EventDispatcher and being properly instantiated, so no issues there.

And here’s the weird part — I use this dispatch call liberally throughout MyClass, often verbatim, and it appears to work everywhere else except in this one enclosing function:

public function onTimerEnd(eventObj:TimerEvent):void {
   trace ("This appears in the trace log. eventObj is "+eventObj);
   var event:CustomEvent = new CustomEvent(CustomEvent.NOTIFY);
   trace ("This doesn't appear!");

The output log shows that, indeed, this function is invoked and that eventObj is an actual TimerEvent. Except that once I try to dispatch this one event, from this one function, the event dispatcher throws a runtime error. And did I mention that it’s only this one function?

Okay, so at least I can catch that sucker:

public function onTimerEnd(eventObj:TimerEvent):void {
   trace ("This appears in the trace log, part 2. eventObj is "+eventObj);
   try {
      var event:CustomEvent = new CustomEvent(CustomEvent.NOTIFY);
   } catch (err:*) {
      trace ("Here's what I caught: "+err);
   trace ("This doesn't appear!");

I clear all the compiler caches, wipe the SWFs, make sure everything is fresh. I even update the trace log, as you may note.

And the error isn’t caught.

The “This appears…” line shows up but no “Here’s what I caught…”. Instead I get the same runtime error.

So it seems that I’ve encountered a non-catchable, fatal application error being thrown by the event dispatcher. I’ve gone over both classes – MyClass and the document class listening to it – about 15 times now, even going so far as to just accept any type of anything on the listener:

public function onCustomEvent(... args):void {
   trace ("Why won't I get called?!");

Again, wipey wipey. Re-compile and … the same runtime error.

The Flash VM is telling me that on line 375 of MyClass, I am providing a CustomEvent, which I head-shakingly re-verify, and that that event can’t be converted into a MyClass type.

But why … why is the event dispatcher trying to do this?

My listener’s wide open, it’ll take ANYTHING, and the event dispatcher is still trying to do something weird. Seriously … what does it have against me?

So I comment out that event dispatch, in that one function, and sure enough the application works again, albeit without this very necessary event dispatch. So that’s not a solution.



Well, I felt kinda dumb after figuring out this one. But, in my defense, the runtime error message was not at all clear.

In fact, the error originated in an entirely different class that I had imported at some point and that also happened to be listening to that CustomEvent from MyClass.

In this entirely different class, the listener was declared like so:

private function onTimerEventNotification(eventObj:MyClass):void {
   trace ("Timer has completed");

Late night, drink, code … I tell ya.

Anyway, as soon this was corrected, everything ran as expected.

The takeaway here is that if you’re seeing an error like this from EventDispatcher, it’s probably not giving you the whole story. A project-wide search may save you from the torment I’ve described.

Remember my anguish, drink to my memory.

August 19th, 2014

Posted In: Development / Coding

Tags: , , , ,

One Comment

Capitalizing on the fear of near-daily revelations of data breaches and widespread government surveillance, companies like Google, Microsoft, and Yahoo! are implementing so-called “end-to-end” encryption to much applause. Unfortunately, this provides a false sense of security.

That’s not to say that encrypting data for transit is a bad thing — not at all. That’s also not to say that, despite problems, I know of any gaping, insurmountable flaws in TLS.

However, consider how a typically HTTPS handshake is carried out: the browser negotiates the initial symmetric key exchange using a locally generated asymmetric key. Both the fast symmetric key and the asymmetric key are at some point stored, either in memory, or in a security container on disk. In order to be able to successfully continue to communicate with the remote server, the browser must then have access to the symmetric key at all times.

While there are chances that the keys or pre-encrypted communications may be intercepted by malware running on the host computer, little consideration is given to the browser, operating system, or hardware. We may have some protection against nefarious outside forces, but what about the fact that Google or Microsoft have potentially full access to all of our communications, encrypted or not?

This is a perfectly reasonable point to raise; Microsoft regularly co-operates with the NSA, as does Google, and with Yahoo! not far behind.

So if Google’s Chrome browser, for example, encrypts your communication, Google has full access to not only the unencrypted communication but also any and all keys used during the crypto operation(s). Microsoft can do one better since they run the underlying operating system. That means that they can capture key strokes, web requests, key storage, and pretty much anything else they like at their whim — in any software. They can also hide network transactions from software like Fiddler or Wireshark; Microsoft provides the network stack, after all.

Naturally, the hardware running the OS and browser, or really any network hardware, are equally as capable of spying on you without your knowledge. In reality we have a three-deep layer of “just trust us” security over which is slapped HTTPS. The HTTPS part is great, but what about the other pieces? As the Wikipedia entry on “end-to-end encryption” points out, “[this] paradigm does not directly address risks at the communications endpoints themselves…”

So HTTPS really only protects you from outside, third-party interlopers, not in any meaningful way from government or corporate surveillance. Heck, they come right out and tell us that this is so — all for our benefit, of course.

Unfortunately, discussion on this topic is often lacking from online security and privacy forums yet this is perhaps a more vital topic than protecting your data in transit. While it’s great that we have improved security to deal with Man In The Middle techniques, privacy and anonymity in corporate and government spheres are essentially non-existent.

This is daunting problem recognized by professional cryptographers and security experts but there doesn’t seem to be much in the way of solutions. We can use something like Tails or Subgraph OS to secure the operating system level but we’re still faced with the hardware both at the host and at the networking level (the router, for example).

Does this mean that there’s practically nothing that can be done? I don’t believe this and there are some proposals that I think are worth discussing, if for no other reason than to inspire imaginations. While this is a somewhat steep uphill climb, it’s also an opportunity for the creation of a whole new class of security-minded software, hardware, and services. If the corporate-government surveillance news did anything, at the very least it made more people aware of just how precious and fragile their own privacy and anonymity are.

In the meantime, by all means keep insisting on HTTPS, just don’t be lulled into a false sense of security.

August 16th, 2014

Posted In: Government, Internet / Web, Privacy / Surveillance

Tags: , , , , , , , , ,

Leave a Comment

Next Page »