Skip navigation

web server

warning: Creating default object from empty value in /var/www/vhosts/ on line 33.

snydeq writes "Stings, penetration pwns, spy games — it's all in a day's work along the thin gray line of IT security, writes Roger A. Grimes, introducing his five true tales of (mostly) white hat hacking. 'Three guys sitting in a room, hacking away, watching porn, and getting paid to do it — life was good,' Grimes writes of a gig probing for vulnerabilities in a set-top box for a large cable company hoping to prevent hackers from posting porn to the Disney Channel feed. Spamming porn spammers, Web beacon stings with the FBI, luring a spy to a honeypot — 'I can't say I'm proud of all the things I did, but the stories speak for themselves.'"

Your rating: None
Original author: 
Joshua Kopstein


Demand for encryption apps has increased dramatically ever since the exposure of massive internet surveillance programs run by US and UK intelligence agencies. Now Facebook is reportedly moving to implement a strong, decades-old encryption technique that's been largely avoided by the online services that need it most.

Forward secrecy (sometimes called "perfect forward secrecy") is a way of encrypting internet traffic — the connection between a website and your browser — so that it's harder for a third party to intercept the pages being viewed, even if the server's key becomes compromised. It's been lauded by cryptography experts since its creation in the early 1990's, yet most "secure" online services like banks and webmail still...

Continue reading…

Your rating: None
Original author: 
Jon Brodkin

Niall Kennedy

Todd Kuehnl has been a developer for nearly 20 years and says he's tried "pretty much every language under the sun."

But it was only recently that Kuehnl discovered Go, a programming language unveiled by Google almost four years ago. Go is still a new kid on the block, but for Kuehnl, the conversion was quick. Now he says "Go is definitely by far my favorite programming language to work in." Kuehnl admitted he is "kind of a fanboy."

I'm no expert in programming, but I talked to Kuehnl because I was curious what might draw experienced coders to switch from proven languages to a brand new one (albeit one co-invented by the famous Ken Thompson, creator of Unix and the B programming language). Google itself runs some of its back-end systems on Go, no surprise for a company that designs its own servers and much of the software (right down to the operating systems) that its employees use. But why would non-Google engineers go with Go?

Read 17 remaining paragraphs | Comments

Your rating: None
Original author: 
Peter Bright

Mozilla wants the Web to be a platform that's fit for any purpose. That's why the company is investing in Firefox OS—to fight back against the proliferation of platform-specific smartphone apps—and it's why the company has been working on WebGL, in order to bring 3D graphics to the browser, Emscripten, a tool for compiling C++ applications into JavaScript, and asm.js, a high performance subset of JavaScript.

The organization doesn't just want simple games and apps in the browser, however. It wants the browser to be capable of delivering high-end gaming experiences. At GDC today, the company announced that it has been working with Epic Games to port the Unreal 3 engine to the Web.

The Unreal 3 engine inside a browser.

With this, Mozilla believes that the Web can rival native performance, making it a viable platform not just for casual games, but AAA titles.

Read 4 remaining paragraphs | Comments

Your rating: None

Aurich Lawson / Thinkstock

The corporate data center is undergoing a major transformation the likes of which haven't been seen since Intel-based servers started replacing mainframes decades ago. It isn't just the server platform: the entire infrastructure from top to bottom is seeing major changes as applications migrate to private and public clouds, networks get faster, and virtualization becomes the norm.

All of this means tomorrow's data center is going to look very different from today's. Processors, systems, and storage are getting better integrated, more virtualized, and more capable at making use of greater networking and Internet bandwidth. At the heart of these changes are major advances in networking. We're going to examine six specific trends driving the evolution of the next-generation data center and discover what both IT insiders and end-user departments outside of IT need to do to prepare for these changes.

Beyond 10Gb networks

Network connections are getting faster to be sure. Today it's common to find 10-gigabit Ethernet (GbE) connections to some large servers. But even 10GbE isn't fast enough for data centers that are heavily virtualized or handling large-scale streaming audio/video applications. As your population of virtual servers increases, you need faster networks to handle the higher information loads required to operate. Starting up a new virtual server might save you from buying a physical server, but it doesn't lessen the data traffic over the network—in fact, depending on how your virtualization infrastructure works, a virtual server can impact the network far more than a physical one. And as more audio and video applications are used by ordinary enterprises in common business situations, the file sizes balloon too. This results in multi-gigabyte files that can quickly fill up your pipes—even the big 10Gb internal pipes that make up your data center's LAN.

Read 34 remaining paragraphs | Comments

Your rating: None

Aurich Lawson

My family has been on the Internet since 1998 or so, but I didn't really think much about Internet security at first. Oh sure, I made sure our eMachines desktop (and its 433Mhz Celeron CPU) was always running the latest Internet Explorer version and I tried not to use the same password for everything. But I didn't give much thought to where my Web traffic was going or what path it took from our computer to the Web server and back. I was dimly aware that e-mail, as one of my teachers put it, was in those days "about as private as sticking your head out the window and yelling." And I didn't do much with that knowledge.

That sort of attitude was dangerous then, and the increasing sophistication of readily available hacking tools makes it even more dangerous now.  Luckily, the state of Internet security has also gotten better—in this article, the first in a five-part series covering online security, we're going to talk a bit about keeping yourself (and your business) safe on the Web. Even if you know what lurks in the dark corners of the Internet, chances are you someone you know doesn't. So consider this guide and its follow-ups as a handy crash course for those unschooled in the nuances of online security. Security aficionados should check out later entries in the series for more advanced information

We'll begin today with some basic information about encryption on the Internet and how to use it to safeguard your personal information as you use the Web, before moving on to malware, mobile app security, and other topics in future entries. 

Read 21 remaining paragraphs | Comments

Your rating: None

aaron swartz lead

I met Aaron Swartz in Cambridge shortly after he’d been indicted for downloading lots of JSTOR articles on MIT’s network in 2011. My Wired colleague Ryan Singel had been writing about his story, and I’d talked a lot with my friends in academia and publishing about the problems of putting scholarship behind a paywall, but that was really the level at which I was approaching it. I was there to have brunch with friends I’d known a long time only through the internet, and I hadn’t known Aaron that way. I certainly didn’t want to use the brunch to put on my journalist hat and pepper him with questions. He was there primarily to see his partner Quinn Norton’s daughter Ada, with whom he had a special bond. The two of them spent...

Continue reading…

Your rating: None

How to Animate Transitions Between Multiple Charts

Sometimes one chart just isn’t good enough. Sometimes you need more.

Perhaps the story you are telling with your visualization needs to be told from different perspectives and different charts cull out these different angles nicely. Maybe, you need to support different types of users and different plots appeal to these separate sets. Or maybe you just want to add a bit of flare to your visualization with a chart toggle.

In any case, done right, transitioning between multiple chart types in the same visualization can add more insights and depth to the experience. Smooth, animated transitions make it easier for the user to follow what is changing and how the data presented in different formats relates to one another.

This tutorial will use D3.js and its built in transitioning capabilities to nicely contort our data into a variety of graph types.

If you're a FlowingData member, you might be familiar with creating these chart types in R.We will focus on visualizing time series data and will allow for transitioning between 3 types of charts: Area Chart, Stacked Area Chart, and Streamgraph. The data being visualized will be New York City 311 request calls around the time hurricane Sandy hit the area.

Check out the demo to see what we will be creating, then download the source code and follow along!

The Setup

Before we dive in, let’s take a look at the ingredients that will go into making this visualization.

D3 v3

Recently, the third major version of D3.js was released: d3.v3.js. Updates include tweaks and improvements to how transitions work, making them easier overall to use.

If you have used D3.js previously, one significant change you will want to know about is that the signature of the callback function for loading data has changed. Specifically, when you load data, you now get passed any errors that have occurred during the data request first, and then the actual data array. So this:

d3.json('data', (data) -> console.log(data.length))

Becomes this:

d3.json('data', (error, data) -> console.log(data.length))

Not a huge deal, as the old API is still supported (though deprecated), but one that gives you enough advantages that you should start using it.

For More on D3.v3, check out the 3.0 upgrading guide on the D3.js wiki.

A Big Cup of CoffeeScript

And again, please feel free to compile to javascript if that will make you happy. But before you do, give CoffeeScript 5 minutes of your time – who knows, you just might fall in love.As in my previous tutorial on interactive networks , I’ll be writing the code in CoffeeScript . I recommend going back to that tutorial if you aren’t familiar with CoffeeScript to get some notes on its syntax. But just in case you don’t want to click that link, here’s the 3 second version:

functions look like this:

functionName = (input1, input2) ->
  console.log('hey! I'm a function')

We see that white space matters – the indentation indicates the lines of code inside a function, loop, or conditional statement. Also, semicolons are left off, and parentheses are sometimes optional, though I usually leave them in.

A Little Python Web Server

The README in the source code also has instructions for using Ruby.Because of how D3.js loads data, we need to run it from a web server, even when developing on our own local machine. There are lots of web servers out there, but probably the easiest to use for our development purposes is Python’s built in Simple Server.

From the Terminal, first navigate to the source code directory for this tutorial. Then check which version of Python you have installed using:

python --version

If it is Python 3.x then use this line to start the server:

python -m http.server

If it is Python 2.x then use

python -m SimpleHTTPServer

In either case, you should have a basic web server that can serve up any file from the directory you are in to your web browser, just by navigating to

The simple python web server running on my machinepython server running

But What About Windows

On Linux or Mac systems, you will already have python installed. However, it takes some moxie to get it working on a Windows machine. I would suggest looking over this blog post, to make sure you don't overlook something.

If you aren't in the mood for some python wrangling, you might take the advice of this getting started with D3 guide and try out EasyPHP. With this installed and running, you can host your D3 projects out of the www/ directory in the root of the installation location.

A Dash of Bootstrap

While we will use D3.js for the actual visualization implementation, we will take advantage of Twitter’s Bootstrap framework to make our vis just a bit more attractive.

Mostly, it will be used to make a nice toggle button that will used to transition between charts. This might not be the most efficient method for getting a decent looking toggle on a site, but it is very easy to implement and will give you a chance to check out Bootstrap, if you haven’t already. It is quite lovely.


Before we start using them, lets talk a bit about what D3 transitions are and how they work.

Think of a transition as an animation. The staring point of this animation is the current state of whatever you are transitioning. Its position, color, etc. When creating a new transition, we tell it what the elements should end up looking like. D3 fills in the gap from the current state to the final one.

D3 is built around working with selections. Selections are arrays of elements that you work with as a group. For example, this code selects all the circle elements in the SVG and colors them red:

  .attr("fill", "red")

It might then come as little surprise that transitions in D3 are a special kind of selection, meaning you can effect a group of multiple elements on a page concisely within a single transition. This is great because if you are already familiar with selections, then you already know how to create and work with transitions.

There are a few more differences between selections and transitions – mainly due to the fact that some element attributes cannot be animated.The main difference between regular selections and transitions is that selections modify the appearance of the elements they contain immediately. As soon as the .attr("fill", "red") code is executed, those circles become red. Transitions, on the other hand, smoothly modify the appearance over time.

Here is an example of a transition that changes the position and color of the circles in a SVG:

# First we set an initial position and color for these circles.
# This is NOT a transition
  .attr("fill", "red")
  .attr("cx", 40)
  .attr("cy", height / 2) 

# Here is the transition that changes the circles
# position and color.
  .attr("fill", "green")
  .attr("cx", 500)
  .attr("cy", (d, i) -> 100 * (i + 1))

I’ve coded up a live version of this demo (in JavaScript), to get a better feel for what is going on.

The functions called on the transition can be separated into 2 groups: those modifying the transition itself, and those indicating what the appearance of the selected elements should be when the transition completes.

The delay() and duration() functions are in the former category. They indicate how long to wait to start the transition, and how long the transition will take.

The attr() calls on the transition are in the later category. They indicate that once the animation is done, the circles should be green, and they should be in new positions. As you can see from the live example, D3 does the hard work of interpolating between starting and ending appearance in the duration you’ve provided.

There are lots of interesting details you can learn about transitions. For a more through introduction, I’d recommend Jerome Cukier’s introduction on

Custom interpolation, start and end triggers, transition life cycles, and more await you in this great guide!To really rip off the covers, check out Mike Bostock’s Transitions Guide , which exposes more of the nitty gritty details of transitions and is required reading once you start needing their more advanced capabilities.

For now, let’s stop with the prep work and get going on more of the specifics of how this visualization works.

A Peak at the Data

When I discovered the NYC OpenData site provided access to raw 311 service request data, I had visions of recreating the classic 311 streamgraph from Wired Magazine originally created by Pitch Interactive.

Alas, my dreams were dashed upon the realization that the times reported for all the requests was set to midnight! I assume some sort of bug in the export process is currently preventing the time from being encoded correctly.

Not wanting to give up on this interesting dataset, I decided to switch gears and instead look at daily aggregation of requests during an interesting period of recent New York history: hurricane Sandy. This tells, I think, an interesting, if not surprising, story. Priorities change when a natural disaster strikes.

Here is what the data looks like:

    "key": "Heating",
    "values": [
        "date": "10/14/12",
        "count": 428
        "date": "10/15/12",
        "count": 298
      // ...
    "key": "Damaged tree",
    "values": [
      // ...
  // ...

In words, our array of data is organized by 311 request type. Each request object has a key string and then an array called values. Values has an entry for each day in the visualization. Each day object has a string representation of the date as well as the number of this type of request for that day, stored in count.

You could use d3.nest to convert a simple table into a similar array of objects, but that is a tutorial for another day.This format was chosen to match up with how the visualization will be built. As we will see, the root-level request objects will be represented as SVG groups. Inside each group, the values array will be converted into line and area paths.

A Static Starting Point

To create movement, one must begin with stillness. How’s that for sage advice? Not great? Well, it will work well enough for us in this tutorial.

Transitions don’t deal with the creation of new elements. An element needs to exist already in order to be animated. So to begin our visualization, we will create a starting point from which the visualization can transition from.

Layouts and Generators

First let’s setup the generators and layout we will use to create the visualization. We will be using an area generator to create the areas of each chart, a line generator for the detail on the regular area chart, and the stack layout for the streamgraph and stacked area chart, as well as some scales for x, y, and color.

Here is what the initialization code looks like:

x = d3.time.scale()
  .range([0, width])

y = d3.scale.linear()
  .range([height, 0])

color = d3.scale.category10()

# area generator to create the
# polygons that make up the
# charts
area = d3.svg.area()
    .x((d) -> x(

# line generator to be used
# for the Area Chart edges
line = d3.svg.line()
    .x((d) -> x(

# stack layout for streamgraph
# and stacked area chart
stack = d3.layout.stack()
  .values((d) -> d.values)
  .x((d) ->
  .y((d) -> d.count)
  .out((d,y0,y) -> d.count0 = y0)

The stack layout could use a bit more explanation.

Unlike what its name might imply, this layout doesn’t actually move any elements itself – that would be very un-D3 like. Instead, its main purpose in this visualization is to calculate the location of the baseline – which is to say the bottom – of the area paths. It computes the baseline for all the elements in the values array based on the stack’s offset() algorithm.

The out() function allows us to see this calculated baseline value and capture it in an attribute of our value objects. In the code above, we assign count0 to this baseline value. After the stack is executed on a set of data, we will be able to use count0 along with the area generator to create areas in the right location.

Loading the Data

Ok, we need to load the JSON file that contains all our data.

This is done in D3 by using d3.json:

$ ->
  d3.json("data/requests.json", display)

Load the requests.json file, then call the display function with the results.

Here is display:

display = (error, rawData) ->
  # a quick way to manually select which calls to display. 
  # feel free to pick other keys and explore the less frequent call types.
  filterer = {"Heating": 1, "Damaged tree": 1, "Noise": 1, "Traffic signal condition": 1, "General construction":1, "Street light condition":1}

  data = rawData.filter((d) -> filterer[d.key] == 1)

  # a parser to convert our date string into a JS time object.
  parseTime = d3.time.format.utc("%x").parse

  # go through each data entry and set its
  # date and count property
  data.forEach (s) ->
    s.values.forEach (d) -> = parseTime(
      d.count = parseFloat(d.count)

    # precompute the largest count value for each request type
    s.maxCount = d3.max(s.values, (d) -> d.count)

  data.sort((a,b) -> b.maxCount - a.maxCount)


The requests.json file has data for every request type, which would overload our visualization. Here we perform a basic filter to cherry pick some interesting types.

d3.time.format and the other time formatting capabilities of D3.js are great for converting strings into JavaScript Date objects. Here, our parser is expecting a date string in the %m/%d/%y format (which is what %x is shorthand for. We use this formatter when we iterate through the raw data to convert each string into a date and save it back in the object.

Then we call start() to get the display ball rolling.

The Start of the Visualization

Finally, we are ready to create the elements needed to get our charts going. Here is the start() function which sets up these elements:

start = () ->
  # x domain setup
  minDate = d3.min(data, (d) -> d.values[0].date)
  maxDate = d3.max(data, (d) -> d.values[d.values.length - 1].date)
  x.domain([minDate, maxDate])

  # I want the starting chart to emanate from the
  # middle of the display. 
  area.y0(height / 2)
    .y1(height / 2)

  # now we bind our data to create
  # a new group for each request type
  g = svg.selectAll(".request")

  requests = g.append("g")
    .attr("class", "request")

  # add some paths that will
  # be used to display the lines and
  # areas that make up the charts
    .attr("class", "area")
    .style("fill", (d) -> color(d.key))
    .attr("d", (d) -> area(d.values))

    .attr("class", "line")
    .style("stroke-opacity", 1e-6)

  # default to streamgraph display

We still haven’t drawn anything, but we are getting close.

The data array is bound to the empty .request selection. Then, as mentioned in the data section above, a g element is created for each request type.

Finally, two path elements are appended to the group. One of which is for drawing the areas of the three charts. The other, with the class .line, will be used to draw lines in the regular area chart.

Without this, the first transition will just cause the areas to appear immediately.
As a little detail, I’ve started the .area paths in the center of the display, so the first transition to the first chart will grow out from the center.

A Movement in Three Parts

Now that we have the basic visualization framework, we can focus on developing the code for each chart.

We want the user to be able to switch back and forth between all the graph styles, in a non-linear manner. To accomplish this, the functions implementing each chart needs to accomplish 3 things:

  1. Recompute values that might get changed by switching to the other charts.
  2. Reset shared layouts and scales to handle the selected chart.
  3. Create a new transition on the elements making up each chart.

With this consistent structure in mind, let’s start coding up some charts.


The initial streamgraph displayStreamgraph display

We will start with the streamgraph – because of my original dreams to emulate Wired, and because it is pretty easy to create with the stack layout.

streamgraph = () ->
  # 'wiggle' is streamgraph offset

  # reset our y domain and range so that it 
  # accommodates the highest value + offset
  y.domain([0, d3.max(data[0] -> d.count0 + d.count))])
    .range([height, 0])

  # setup the area generator to utilize
  # the count0 values created from the layout
  area.y0((d) -> y(d.count0))
    .y1((d) -> y(d.count0 + d.count))

  # here we create the transition
  t = svg.selectAll(".request")
  # D3 will take care of the details of transitioning"path.area")
    .style("fill-opacity", 1.0)
    .attr("d", (d) -> area(d.values))

Its all a bit anticlimactic, right? The shape of the path is defined by the attribute d. See the MDN tutorial if you aren’t familiar with SVG paths.Look at that. We didn’t even have to get our hands dirty with creating SVG paths. The area generator did it all for us. Nor did we have to deal with any of the animation from current state to final streamgraph. The transition helped us out there. So what did we do?

The initial call to stack(data) causes the stack layout to run on our data. Its setup to use wiggle as the offset, which is the offset to use for streamgraphs.

The y scale needs to be updated to ensure the tallest ‘stream’ is accounted for in its calculation.

Again, check out that Transition Guide for more clarity on how this works.The last section of the streamgraph function is the transition. We create a new transition selection on the .request groups. Then we select the .area path’s inside each group and set the path and opacity they should end up using the attr() calls.

D3 will interpolate the path’s values smoothly over the duration of the transition to end up at a nice looking streamgraph for our data. The great thing is that this same code will work for transitioning from the initial blank display as well as from the other chart types!

Stacked Area Chart

The stacked area chart provides a new view with little code.Stacked area chart

I’m not going to go over the code for the stacked area chart – as it is near identical to the streamgraph.

The only real difference is that the offset used for the stack layout calculations is switched from wiggle to zero. This modifies the count0 values when the stack is executed on the data, which then adjusts the area paths to be stacked instead of streamed.

Area Chart

With the overlapping area chart, we reduce opacity to prevent from obscuring ‘short’ areasArea chart

Our last chart is a basic overlapping area chart. This one is a little different, as we won’t need to use the stack layout for area positioning. Also, we will finally get to use that .line path we created during the setup.

Here is the relevant code for this chart:

areas = () ->
  g = svg.selectAll(".request")

  # as there is no stacking in this chart, the maximum
  # value of the input domain is simply the maximum count value,
  # which we precomputed in the display function 
  y.domain([0, d3.max( -> d.maxCount))])
    .range([height, 0])

  # the baseline of this chart will always
  # be at the bottom of the display, so we
  # can set y0 to a constant.
    .y1((d) -> y(d.count))

  line.y((d) -> y(d.count))

  t = g.transition()

  # partially transparent areas"path.area")
    .style("fill-opacity", 0.5)
    .attr("d", (d) -> area(d.values))

  # show the line"path.line")
    .style("stroke-opacity", 1)
    .attr("d", (d) -> line(d.values))

The main difference between this chart and the previous two is that we are not using the count0 values in any of the area layouts. Instead, the bottom line of the areas is set to the height of the visualization, so it will always stay at the bottom of the display.

The .line is adjusted in the other charts too (just not shown in these snippets). It is just always set to be invisible in the transition.In the transition, we set the opacity of the area paths to be 0.5 so that all the areas are still visible. Then we do another selection to set the .line path so that it appears as the top outline of our areas.

Switching Back and Forth

As each of these charts is contained in its own function, transitioning between charts becomes as easy as just executing the right function.

Here is the code that does just that when the toggle button is pushed:

transitionTo = (name) ->
  if name == "stream"
  if name == "stack"
  if name == "area"

Each of these functions creates and starts a new transition, meaning switching to a new chart will halt any transition currently running, and then immediately start the new transition from the current element locations.

The Little Details

There are some finishing touches that I’ve made to the visualization that I won’t go into too much depth on. D3’s axis component was used to create the background lines marking every other day.

Shameless plug: Check out my tutorial on small multiples if you want to take a deeper look into the implementation of this great pieceA little legend, inspired by the legend in the Manifest Destiny visualization. It is also an SVG element and the mouseover event causes a transition that shifts the key into view. The details are in the code.

Finally, like I mentioned above, the toggle button to switch between charts was created using bootstrap. Checkout the button documentation for the details.

Wrapping Up

Well hopefully now you have a better grasp on using transitions to switch between different displays for your data. We can really see the power of D3 in how little code it takes to create these different charts and interactively move between them.

Thanks again to Mike Bostock, the creator of D3. His presentation on flexible transitions served as the main inspiration for this tutorial.

Now get out there and start transitioning! Let me know when you create your own face melting (and functional) animations.

Your rating: None