Air Gaps

Original source

Since I started working with Snowden’s documents, I have been using a number of tools to try to stay secure from the NSA. The advice I shared included using Tor, preferring certain cryptography over others, and using public-domain encryption wherever possible.

I also recommended using an air gap, which physically isolates a computer or local network of computers from the Internet. (The name comes from the literal gap of air between the computer and the Internet; the word predates wireless networks.)

But this is more complicated than it sounds, and requires explanation.

Since we know that computers connected to the Internet are vulnerable to outside hacking, an air gap should protect against those attacks. There are a lot of systems that use — or should use — air gaps: classified military networks, nuclear power plant controls, medical equipment, avionics, and so on.

Osama Bin Laden used one. I hope human rights organizations in repressive countries are doing the same.

Air gaps might be conceptually simple, but they’re hard to maintain in practice. The truth is that nobody wants a computer that never receives files from the Internet and never sends files out into the Internet. What they want is a computer that’s not directly connected to the Internet, albeit with some secure way of moving files on and off.

But every time a file moves back or forth, there’s the potential for attack.

And air gaps have been breached. Stuxnet was a US and Israeli military-grade piece of malware that attacked the Natanz nuclear plant in Iran. It successfully jumped the air gap and penetrated the Natanz network. Another piece of malware named agent.btz, probably Chinese in origin, successfully jumped the air gap protecting US military networks.

These attacks work by exploiting security vulnerabilities in the removable media used to transfer files on and off the air-gapped computers.

Since working with Snowden’s NSA files, I have tried to maintain a single air-gapped computer. It turned out to be harder than I expected, and I have ten rules for anyone trying to do the same:

  1. When you set up your computer, connect it to the Internet as little as possible. It’s impossible to completely avoid connecting the computer to the Internet, but try to configure it all at once and as anonymously as possible. I purchased my computer off-the-shelf in a big box store, then went to a friend’s network and downloaded everything I needed in a single session. (The ultra-paranoid way to do this is to buy two identical computers, configure one using the above method, upload the results to a cloud-based anti-virus checker, and transfer the results of that to the air gap machine using a one-way process.)

  2. Install the minimum software set you need to do your job, and disable all operating system services that you won’t need. The less software you install, the less an attacker has available to exploit. I downloaded and installed OpenOffice, a PDF reader, a text editor, TrueCrypt, and BleachBit. That’s all. (No, I don’t have any inside knowledge about TrueCrypt, and there’s a lot about it that makes me suspicious. But for Windows full-disk encryption it’s that, Microsoft’s BitLocker, or Symantec’s PGPDisk — and I am more worried about large US corporations being pressured by the NSA than I am about TrueCrypt.)

  3. Once you have your computer configured, never directly connect it to the Internet again. Consider physically disabling the wireless capability, so it doesn’t get turned on by accident.

  4. If you need to install new software, download it anonymously from a random network, put it on some removable media, and then manually transfer it to the air-gapped computer. This is by no means perfect, but it’s an attempt to make it harder for the attacker to target your computer.

  5. Turn off all autorun features. This should be standard practice for all the computers you own, but it’s especially important for an air-gapped computer. Agent.btz used autorun to infect US military computers.

  6. Minimize the amount of executable code you move onto the air-gapped computer. Text files are best. Microsoft Office files and PDFs are more dangerous, since they might have embedded macros. Turn off all macro capabilities you can on the air-gapped computer. Don’t worry too much about patching your system; in general, the risk of the executable code is worse than the risk of not having your patches up to date. You’re not on the Internet, after all.

  7. Only use trusted media to move files on and off air-gapped computers. A USB stick you purchase from a store is safer than one given to you by someone you don’t know — or one you find in a parking lot.

  8. For file transfer, a writable optical disk (CD or DVD) is safer than a USB stick. Malware can silently write data to a USB stick, but it can’t spin the CD-R up to 1000 rpm without your noticing. This means that the malware can only write to the disk when you write to the disk. You can also verify how much data has been written to the CD by physically checking the back of it. If you’ve only written one file, but it looks like three-quarters of the CD was burned, you have a problem. Note: the first company to market a USB stick with a light that indicates a write operation — not read or write; I’ve got one of those — wins a prize.

  9. When moving files on and off your air-gapped computer, use the absolute smallest storage device you can. And fill up the entire device with random files. If an air-gapped computer is compromised, the malware is going to try to sneak data off it using that media. While malware can easily hide stolen files from you, it can’t break the laws of physics. So if you use a tiny transfer device, it can only steal a very small amount of data at a time. If you use a large device, it can take that much more. Business-card-sized mini-CDs can have capacity as low as 30 MB. I still see 1-GB USB sticks for sale.

  10. Consider encrypting everything you move on and off the air-gapped computer. Sometimes you’ll be moving public files and it won’t matter, but sometimes you won’t be, and it will. And if you’re using optical media, those disks will be impossible to erase. Strong encryption solves these problems. And don’t forget to encrypt the computer as well; whole-disk encryption is the best.

One thing I didn’t do, although it’s worth considering, is use a stateless operating system like Tails. You can configure Tails with a persistent volume to save your data, but no operating system changes are ever saved. Booting Tails from a read-only DVD — you can keep your data on an encrypted USB stick — is even more secure. Of course, this is not foolproof, but it greatly reduces the potential avenues for attack.

Yes, all this is advice for the paranoid. And it’s probably impossible to enforce for any network more complicated than a single computer with a single user. But if you’re thinking about setting up an air-gapped computer, you already believe that some very powerful attackers are after you personally. If you’re going to use an air gap, use it properly.

Of course you can take things further. I have met people who have physically removed the camera, microphone, and wireless capability altogether. But that’s too much paranoia for me right now.

This essay previously appeared on Wired.com.

EDITED TO ADD: Yes, I am ignoring TEMPEST attacks. I am also ignoring black bag attacks against my home.

Responsive Navigation On Complex Websites

Original source


Central to a solid user experience is a well-structured, simple navigation system. Over the past few months, I’ve been involved in launching two large institutional websites with complex navigation systems. Maintaining simplicity on such large websites becomes increasingly difficult as content requirements grow and tiers of navigation are added, not to mention the extra complexity added by small screens.

To illustrate the techniques involved in implementing responsive navigation on a large website, I’ll refer to two actual clients of mine. I’ll start with the process and how to get through it with research and mockups, then later get into some of the actual code that was used.

Middlesex-London Health Unit

The Process

The key to success in every project, particularly a large website, is to work closely with the client, keeping them involved in as many aspects of the design process as possible. Before we get into code and how to build a website technically, we need to learn more about the project. At ResIM, we start with audience research, before progressing through information architecture, wireframing and wireframe usability testing.

In our latest project for a public health organization, the Middlesex-London Health Unit (MLHU), we started with audience research to find out the kinds of information that public users look for on health-related websites. Considering that MLHU’s website had over 1300 pages to be overhauled, we needed to make sure that priority content gets the focus it deserves.

As a design studio, we’ve tried different forms of audience research. One of our go-to methods is to bring in users to walk through a wireframe website, seeing how long it takes them to perform various tasks and to find various sections of the website, while video recording them. This style of testing doesn’t always yield perfect results because many inexperienced users will have problems understanding a website without graphics, colors, etc. But it still provides valuable insight into how easy or difficult content is to find.

This method works well when the structure and site map are defined, but we weren’t quite at that stage and needed to step back. MLHU has various committees and groups that had to be represented on the website, and we needed to make sure that everyone’s voice is heard.

We started by meeting with all of the committee members who were appointed to work on the website, to determine which parts of the website were most important. After hearing each group state its case as to why its information needed to be prominent on the website, we started to build a proper hierarchy. We realized there were a lot of different sections and areas, and we needed a way to group them into fewer parent items in order for the user to be able to interpret and navigate more quickly. We decided to piece together a lot of similar categories, and we named each of these groups; these would become our four main navigation items.

This was a great accomplishment, but we quickly realized that we needed to call attention to other important pages that weren’t necessarily grouped into those four sections. We created a supporting menu to accommodate and provide access to some of these non-health-related topics. Once we had built this streamlined navigation and worked it into our wireframes, we ran them through a testing period, in which we had users walk through areas of the website, performing tasks and finding information.

Watching people use this streamlined navigation, we noticed that each of them was able to quickly find the section of the website they were looking for and then effortlessly find the particular page and information they were after. These results from real-world users reinforced the decisions we had made in the information architecture.

MLHU site map
MLHU’s site map. ( Larger view | Source)

From here, we were able to move into the interface design phase, which included mocking up the responsive mobile view. Many clients struggle with the concept that a responsive mobile website is, in fact, the same website they see on their desktop, and not a whole new skin for mobile. Showing these clients a little less in the mockup phase is sometimes valuable.

For this reason, we typically leave tablet views out of this step, to enable us to control how the website transitions from the big “desktop” view down to the small “mobile” view. In the case of MLHU, I realized with the older ages of some of our target users, we couldn’t rely on typical top-right hamburger-style navigation.

Feeling that this solution would have been more difficult for certain users, I opted instead for vertical text-based navigation. This gave the second level of navigation a better layout, by allowing users to view all menu options before making a selection.

MLHU website on mobile
MLHU’s website on mobile. ( Larger view | Source)

Implementation

Our initial concern in the MLHU project was whether we could keep the mobile navigation structure congruent with the desktop version. Typically, one can hide navigation under a hamburger-style button, a common design pattern. However, our target audience included a wide age range, and we felt that displaying the full text of the navigation would be more user-friendly.

If we were to keep the navigation the same and then make some CSS adjustments to wrap the navigation in a box and stack the navigation vertically instead of horizontally, we could achieve the solution we were looking for.

@media only screen and (max-width: 600px) { nav li { width: 100%; box-sizing: border-box; } nav a { background: rgba(0,0,0,0.5); padding: 10px 12px; text-align: left; margin: 0; box-sizing: border-box; } } 

MLHU Mobile Navigation
MLHU’s mobile navigation. (Source)

A JavaScript-based solution for our desktop navigation interaction was in place, using the hoverIntent plugin, but we needed to adjust it to work properly on mobile. Our solution was to add a condition to check the screen’s size and, if small, to switch to a toggle slide instead of a hover fade in/out. A toggle slide gives a more native feel to the website, making it fit in and feel quicker on a mobile device, whereas a fade can feel slow and unresponsive when interacted with on a touchscreen.

function navIn() { [...] } else if($(window).width() < 600) { /* Here's where we check for the screen size and do a slide instead. */ $(this).children('ul').slideDown(); $(this).addClass('hovering'); } [...] } 

Seneca College

The Process

A second instance of our process was the design and UX overhaul of Seneca College’s public website. We couldn’t reduce the main navigation as we did with MHLU because of different content requirements and organizational constraints. We didn’t need to work through an information architecture phase because the navigation was already set for us by the client; so, we moved right into wireframing and interface concepts. Similar to MLHU, we also mocked up a responsive mobile view and explored ways to display the navigation in an effective format.

Recognizing that this target audience is much younger, I felt strongly about using a streamlined navigation that is revealed via a hamburger-style vertical side menu. The hamburger icon has become popular through its use in many mobile applications, and it frees up space in the website’s header for the logo and search icon. A lot of sublevel pages needed to be displayed on Seneca College’s website, and showing them all at once in the header navigation would have been a bit too much.

My solution was to display sectional navigation at the top of every inner page. This secondary navigation would allow the user to quickly move through sections of the website without having to scroll through a long menu. With the complexity of a large website, making it navigable before showing the main content on the inner pages is sometimes necessary.

If you’re unsure of which route to take, try doing some extra audience research using mobile wireframes, and get a feel for how real-world users respond to the solutions.

Seneca website on mobile
Seneca’s website on mobile. ( Larger view | Source)

Implementation

Seneca’s navigation system is more complex and its mobile and desktop versions more different from each other than MLHU’s. We needed to find a way to replace the main navigation with a hamburger icon once the screen reaches a certain size. We started with a div for the mobile navigation that sits inside the header, but we didn’t want it to show up in the desktop view, so we hid it with CSS.

<div id="mobileNav"> <a id="searchIcon" href="#"><img src="http://media.smashingmagazine.com/images/searchIcon.png" width="24px" height="24px" alt="" /></a> <a id="mobileNavIcon" href="#"><img src="http://media.smashingmagazine.com/images/mobileNav.png" width="38px" height="20px" alt="" /></a> </div> 

Seneca Mobile Nav DIV
Seneca’s div for mobile navigation. (Source)

#mobileNav { display: none; } 

For screens that are big enough, we display the aforementioned hidden div using media queries.

@media only screen and (max-width: 600px) { #mobileNav { display:block; } } 

At the same time, we restyled the navigation and hid it. Feel free to get creative with restyling the navigation for mobile. I wanted full-width navigation that slides down, pushing the rest of the content, but you could instead absolutely position the menu to overlap the main content, or achieve an off-screen push effect using something like PageSlide. Many different techniques are possible; experiment with what you like and what feels best for the website.

@media only screen and (max-width: 600px) { nav { display: none; width: 100%; background: #000; margin-left: -20px; padding-right: 40px; } nav li { display: block; margin: 20px 0 20px 20px; width: 100%; } nav a { color: #FFF; margin: 0; width: 100%; } } 

Lastly, completing our toggle is simply a matter of adding some JavaScript, similar to the example above.

$('#mobileNavIcon').click(function () { $('nav').slideToggle(); return false; }); 

Seneca mobile navigation opened
Seneca’s mobile navigation opened. (Source)

It’s imperative to make design decisions that enhance the user experience by considering the results of usability testing, the perceived skill level of all user sets, and the general characteristics of the audience. As demonstrated in the cases above, even though a hamburger-style menu icon has become the industry standard, it might not be the best approach given the age or competency of the target audience.

Other Techniques

I’m always looking for new solutions to the problem of complex navigation. Below are a few examples that could be really useful, depending on the requirements of the project.

PageSlide

I like that PageSlide follows the current mobile app trend with a pull-out side menu. Users are getting more comfortable with these menus and how they work. The benefit is a much taller scrollable menu that doesn’t push content too far down.

Responsive Multi-Level Menu

Responsive Multi-Level Menu is great for a few reasons. It mimics normal drop-down navigation, which is usually triggered by mouse hovering, and implements it effectively for touchscreens. It also makes it easy for users to jump down a few levels without forcing new pages to load.

Conclusion

Making design decisions based on your users should be paramount. If you aren’t involved in the initial design phase, then at least try to get involved in the responsive portion of the project. You need to help make sure that the direction taken is in the best interest of users, based on their comprehension of the systems you plan on using and their ability to access content.

Next, determine what code is needed to make a smooth transition from desktop to mobile. Does it require some JavaScript to animate nicely? Does its orientation need to change from horizontal to vertical? What can you do with the initial CSS to allow for an even smoother transition that requires fewer adjustments to media queries?

Lastly, don’t let a complex navigation system or information architecture intimidate you. There’s always a way to simplify it to its core and to provide those layers to the user in a way that is non-threatening and easy to understand. Take on the challenge and have fun with it!

Other Resources

You may be interested in the following articles and related resources:

(al) (ea)


© Jon Rundle for Smashing Magazine, 2013.

Stunning supersonic snapshot

Original source

And a little something from NASA today showing schlieren photographs – a technique allowing imaging of soundwaves – capturing supersonic shockwaves emanating from NASA Boeing F-15 and F/A-18 aircraft flying at supersonic speeds. The images were gathered by a twin telescope and digital camera system on the ground at NASA’s Dryden Flight Research Center to manually test the Ground-to-Air Schlieren Photography System, or GASPS.

NASAshockwaves

Sony Unveils the PS Vita TV and Slimmer Vita Handheld

Original source
Dave Knott writes “Sony today announced the PS Vita TV box. Measuring 6.5cm by 10.5cm, it can play Vita games on your television, stream content via HDMI or wirelessly, and play all the existing PlayStation Network content available on the standard Vita platform. This is seen by some analysts as an attempt by Sony to compete with such devices as the Ouya and Apple TV. The PS Vita TV is so far announced for a Japan-only release in early 2014 at a price of approximately $100 US. In related news, Sony also announced a lighter, slimmer, more colorful iteration of the standard Vita handheld console.” The $100 model does not come with a controller; a $150 model was also announced that will include a Dualshock 3 and an 8G memory card.

Read more of this story at Slashdot.