Improving OpenVPN security on Synology NAS

This guidance refers to DSM 5.2-5592 Update 4, with VPN Server 1.2-2456, and the official Android client v1.1.16 (build 74).

When setting up a VPN on a Synology NAS, you can make a choice between PPTP, OpenVPN, and L2TP/IPsec. For assorted reasons, I chose OpenVPN. However, I was underwhelmed with the security stance of the default Synology configuration. Specifically, the default was TLS/1.0, and used a username/password combo for authentication. TLS/1.0 has issues – the current best-practice is to use TLS 1.2. Just relying on a username/password opens you up to brute-force attacks, especially if you use a weak password as many people do in their intranet.

I have changed this configuration to use TLS 1.2, and TLS-authentication. I opted not to use a user key.

Below I have documented how to install and configure OpenVPN at this security level on a Synology NAS. I am using CloudStation to distribute files between my NAS and my clients – other approaches such as SMB shares would also work.

1) Install the VPN Server

Identify and set up a way to distribute files from the NAS to your client computers (e.g. phone, laptop, etc). I used CloudStation, with the Android and Windows DS Cloud clients.

Set up Dynamic DNS. Go to Control Panel, External Access, DDNS, and click Add. Follow the relevant instructions. Make a note of the hostname you pick. Alternately, from your home network browse to or similar and make a note of your public IP address. Note: Most ISPs will give you a dynamic public IP address, which can change over time, hence the recommendation for Dynamic DNS.

Install VPN Log onto the NAS with admin credentials. Go to Package Center, Utilities, and click on Install for VPN Server (by Synology Inc).

Set up Port Forwarding. If your home router supports UPnP, go to Control Panel, External Access, Router Configuration. Click on Set up router, if prompted. When set up, click Create, Built-in application, and check the row which says “VPN Server UDP 1194 1194”. Click Apply, and then Save. If you encounter problems with this, you may not be using a UPnP server. In which case you need to go into your home router config, and set up port forwarding. You’ll want to forward traffic from your external IP UDP/1194, to the IP address of your NAS (e.g. UDP/1194.

Optional: You may want to use a non-standard port rather than 1194. If so, you’ll either need to select a Custom Port in the router configuration page, or manually configure on your router. Just replace all mentions of 1194 in the above with the port you select, making sure you don’t use a port which is already in use.

Set up Auto Block. Go to Control Panel, Security, Auto Block. Check the “Enable auto block” checkbox, set the settings as appropriate. I recommend clicking on Allow/Block list, and adding the IP address of the computer you use to administer the NAS from to the “Allow List”. This will stop the NAS from blocking you even if you get the password wrong a few times. Click Apply when done.

2) Configure the VPN Server

GUI Setup

Go to VPN Server, General Settings, and uncheck “Grant VPN permission to newly added local users”. Verify that Auto Block is set up. Click Apply.

Go to VPN Server, Privilege, then uncheck all check boxes except the OpenVPN entries for the users you want to allow OpenVPN access. (Note: I’m assuming you’re not using PPTP/L2TP). I highly recommend you don’t allow admin to VPN in. Click Save when done.

Go to VPN Server, OpenVPN. Check the Enable checkbox, and set up your Dynamic IP address range etc. This must be a different subnet to your home network. If you chose to use a different port/protocol in step 1, change the Port and Protocol values. When complete, click Apply.

Click Export configuration – this will download a zip file to your local machine. Unzip that into your CloudStation folder.

Terminal Setup

SSH in. After doing the above, SSH into your NAS, as user “root”, using the same password as “admin”. If you cannot SSH in, go to Control Panel, Terminal & SNMP, and verify that “Enable SSH service” is checked, and configured as you expect.

Do the following commands, where $user is the username you’re using for cloudstation, and assuming the folders are in volume 1, and you unzipped the downloaded configuration into a folder called openvpn.

> cd /var/packages/VPNCenter/target/etc/openvpn/keys
> openvpn --genkey --secret ta.key
> cp ta.key /volume1/homes/$user/CloudStation/openvpn/
> chown $user.users /volume1/homes/$user/CloudStation/openvpn/ta.key
> vi /usr/syno/etc/packages/VPNCenter/openvpn/openvpn.conf

Add the following lines:-

tls-version-min 1.2
tls-auth /var/packages/VPNCenter/target/etc/openvpn/keys/ta.key 0

Save the changes (Esc, :wq), then optionally exit the SSH session.

Restart the VPN server. This can be done by going to Package Center, Installed, VPN Server, and Clicking Action->Stop, then when stopped clicking Action->Start.

3) Configure the client

Edit the openvpn.ovpn file in your CloudStation. Find the YOUR_SERVER_IP and replace it with the dynamic DNS hostname or IP address you identified in step 1. Then add the following line:

tls-auth ta.key 1

Save the file.

Upload the ca.crt, openvpn.ovpn, and ta.key files on to your phone – they all need to be in the same directory. If using CloudStation, this will be done automagically when your phone is on your home WiFi.

Install the client “OpenVPN Connect” package on Android. Run it. Press the three dots in the top right, and go to Preferences. Scroll down to Minimum TLS version, and set to TLS 1.2. Go back to the main screen.

Press the three dots again, and select Import. Then “Import Profile from SD Card”. Browse to wherever you downloaded the openvpn.ovpn file, and select it. Enter your username and password.

Disconnect your phone from your home WiFi, and make sure mobile data is enabled. Click Connect. Fingers crossed, after a few seconds, a connection should happen.

If you don’t connect, and no error is shown, try the following:-

  • Verify that you’re using the correct IP/hostname
  • Verify you’ve set up port forwarding correctly
  • If you can’t tell the above, try changing the protocol to TCP. This can be done via the Synology GUI, or by changing the “proto udp6” in the server file to “proto tcp-server”. You’ll also need to change the openvpn.ovpn line “proto udp” to “proto tcp-client”. Don’t forget to restart the server, and delete and reimport the client.
  • Verify that the changes you made manually to the server config are still present, by ssh’ing in and checking with vi. It’s possible that changing settings via the GUI will clobber any manual changes you have made.

4) Optional improvements

By using a non-standard port (i.e. not 1194) you’ll be less likely to turn up on port scans.

Using the ta.key with tls-auth means that anyone attempting to connect to your server will need that key. If you want to use a user key instead or as well as a password, that could add extra security.

By default, with TLS1.2, the connection seems to be TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 which should be sufficient. If you want a different TLS cipher, first identify the string by SSHing to the server and running: openvpn –show-tls You can then set the selection through adding a “tls-cipher <: delimited ciphers>” in both the server and client.


HoloLens – Some analysis

22/1/15 11:00 Updated with specs from [6], [7], [8], [9], a comment on resolution vs FOV, and an update on the HPU location from [12].

HoloLens blows me away with its possibilities. I love my Oculus Rift DK2, and Virtual Reality is perfect for when you want to just concentrate on the computer world, but I’ve always been keen to see a good Augmented Reality solution. HoloLens may be it – check it out at [5].

There had been rumours of MS working on something like this for a while – for example patent applications have been filed. [1][2] But no-one seemed to expect such a mature offering to be announced already, and with a possible early release in July 2015, with wider availability Autumn 2015 when Windows 10 is released. If the HoloLens, with the Windows 10 Holographic UI, deliver as announced then I’ll be buying.

Speaking of which, for all Microsoft’s talk of “Hologram” this and “Hologram” that, as far as I can see no holograms are being used. Instead, “Hologram” here is MS marketing speak for Augmented Reality. Their use of the word is innaccurate and misleading, but frankly is also more understandable to normal consumers, so it’s entirely understandable.

Figure 1: HoloLens

With that out of the way, here’s a bit of analysis of the HoloLens and the Windows Holographic UI. Note that I haven’t seen or touched one of these in person, so take everything with a big pinch of salt….


There are two sets of output supported – a “Holographic” display, and Spatial Audio.



Display type

The most stand-out feature is the “Holographic” display. This appears to be using an optical HMD with some kind of waveguide combiner. That’s what those thick lenses are. This is also touched on in the MS patent filing [2].

Focal length

An important question is what the focal length is set to? Does it vary? To explain the importance of this let’s do a quick experiment. Put your hand out in front of you. Look at it, and you’ll notice the background gets blurry. Look at the background behind your hand – now your hand gets blurry. That’s because the lenses of your eyes are changing to focus on what you’re looking at.

If the focal length on the display is fixed, then the display will be out of focus some of the time. Looking at write-ups, people appear to have used the display at ranges from 50cm up to several metres – and with no comments about blurry visuals. It appears therefore that the optics are somehow either changing the focal length of the display, or are “flattening” the world at large, so that your eyes don’t need to change focal length between short and long ranges.


The waveguide is a way to shine light into your eyes, but if the world outside is too bright then you would have problems seeing the display. Therefore the front screen is tinted. A question is how much it is tinted – too little and you won’t be able to see the display in bright conditions, and too much and you won’t be able to see the outside world in darker conditions. It’s possible they’re photochromic and get darker when exposed to bright light.


I’ve attempted to estimate the dimensions of the display, but these should be taken with a massive pinch of salt. See the Maths section below for where I got the numbers from. My estimate is that the display, per eye, is around 5.6cm wide and 4cm high, and are 1-2.1cm away from the users’ eyes. Given that, that equates to approximately 80-120 degrees vertical Field of View, and 100-140 degrees horizontal field of view. If accurate, then that’s pretty impressive, and is broadly on par with the Oculus Rift.

Since the initial presentation, other write-ups have implied my initial estimate was wildly optimistic. [6] asserts 40×22 degrees, whereas [9] provides two estimates of 23 degrees and 44 degrees diagonal. Descriptions state that the display appears to be quite small – much smaller than that of the Oculus Rift DK2.


I don’t have any information on the resolution of the display. Microsoft have stated “HD” however that can mean many things – for example is that HD per eye, HD split between the two eyes? It should be noted as well that HD is pretty rubbish resolution for a display with a large field of view – put your face right next to your laptop or tablet screen and see how pixellated things suddenly look. There are some tricks that could be done if eye tracker is being used (see the Eye Tracker section) to greatly improve apparent resolution.

The write-ups I’ve seen implied that resolution wasn’t bad at all, so this will be something to keep an eye on. [6] asserts somewhere between 4Mpx (2.5k) and 8Mpx (4k).

It should be noted that the human eye has around a 0.3-0.6 arc-minute pixel spacing, which equates to 100-200 pixels per degree.[10] The “Retina” display initially touted by Apple was around 53 pixels per degree. [11]

Spatial Audio

The audio aspect of gaming and computers in general has been quite poor for a while now. The standard is stereo, maybe with a subwoofer in a laptop or PC. Stereo can give you some hints about location, but full 5.1 surround sound has been a rarity for most PC users. There are some expensive headphones which support it, but these don’t work properly when you turn your head away from the screen – not ideal with a head-mounted display. It’s notable therefore that HoloLens supports spatial audio right out of the box.

With spatial audio DSPs are used to simulate surround sound, and furthermore it will take into account the direction you’re facing. It’s amazing how useful this is for understanding your surroundings – a lesson that Oculus has also learnt with their latest prototypes of the Oculus Rift.

Reports from the HoloLens imply it’s using some kind of speaker(s) rather than headphones. Questions remain about how directional the sound is (i.e. can other people hear what you’re hearing), how loud the audio is, and how good the fidelity is.


The HoloLens appears to be festooned with sensors, which makes sense given that it is supposed to be a largely standalone device.

Outward facing cameras

Either side of the headset are what look like two cameras. Alternately they may be a camera and an LED transmitter, as used by the MS Kinect. Either way, these cameras provide two sets of information to the computer. Firstly they detect the background and must provide a depth map of some kind – likely using similar techniques and APIs to the Kinect. Secondly, they detect hand movement and so are one of the sources of user input.

The background detection is used for ‘pinning’ augmented reality to the real world – when you turn your head you expect items in the virtual world to remain in a fixed location in the real world. That’s really hard to do, and vital to do well. The simplest way to do it is through the use of markers/glyphs – bits of paper with specific patterns that can be easily recognized by the computer. HoloLens is doing this marker-less, which is much harder.Techniques I’ve seen use algorithms such as PTAMM to build a ‘constellation’ of edges and corners, and then lock virtual objects to these.

Reports seem pretty positive about how this works, which is great news. A big question though is how it works in non-ideal lighting – how well does it track when it’s dark/dim or very bright, there’s moving shadows, etc. For example, what if you’re in a dim room with a bright TV running in the background, casting a constantly changing mix of light and dark around the room?

As mentioned, the cameras are also used for hand tracking. The cameras are very wide angle apparently, to be able to watch hands in a wide range of movement, however many questions remain. These include how well the tracking works when hands cross over, become fists, and turn. Some finger tracking must be performed judging by the click movement used in many of the demos – are all fingers tracked? And how is this information made available to developers.

Eye tracker

During some of the demos the demonstrators have said that the HoloLens can tell where you’re “looking” – indeed that is used extensively to interface with the UI. This may be based on just the orientation of the head, or some reports seem to imply that there’s actual eye tracking.

If there is eye tracking, then there’s likely cameras (possibly in that protuberance in the center) tracking where the user’s pupils are. That would be very cool if so, as it provides another valuable interface for user input, but it could also provide even more.

When tracking the pupil, if the display can ‘move’ the display to different parts of the waveguide, then the display could do this to always provide higher resolution display at the location you’re looking at, without having to waste the processing power of having a high resolution over the whole display. Thus you could get an apparently high resolution over a broad field of view, with a display that only actually displays a high resolution over a small field of view.

Also, by analysis of how the pupils have converged, the computer can judge how far away your looking. For example – put your hand out in front of you and focus on one finger. Move the hand towards and away from your face, and you’ll feel your eyes converging as the finger gets closer – watch someone else’s eyes and you’ll see this clearly. If the computer can judge how far away you’re looking then it could change the focal length of the display itself, so that the display still appears in focus. It could also provide this information to any APIs – allowing a program to know for example which object the user is looking at when there’s a stack of semi-transparent objects stacked behind each other.


A microphone is built-in, which can be used both for VoIP such as Skype, and also as a source of user input using Cortana or similar. Questions include quality, and directionality – will the microphone pick up background noise?

Positional sensors

The headset obviously detects when you move your head. This could be detected by the cameras, but the latency would likely be too large – Oculus have found latency of 20ms is a target, and anything over 50ms is absolutely unacceptable. Therefore there are likely gyros and accelerometers to quickly detect movement. Gyros drift over time, and while accelerometers can detect movement they become innaccurate when trying to estimate the net movement after several moves. Therefore it’s likely the external cameras are periodically being used to recalibrate these sensors.

Given that this headset is supposed to be standalone, it’s possible the headset also includes GPS and WiFi for geolocation as well.


I would be amazed if HoloLens doesn’t include Bluetooth support, which would then allow you to use other input devices, most notably a keyboard and mouse. Using a mouse may be more problematic – you need to map a two dimensional movement into a three dimensional world, however mice are vastly more precise for certain things.

Processing unit

One surprise in the launch was that no connection to a PC/laptop was needed. Instead, the HoloLens is supposed to be standalone. That said, all the computing isn’t done in the handset alone. According to [4] there’s also a box you wear around your neck, which contains the processor. Exactly what is done where – in the headset or the box – hasn’t been described, but we can make some educated guesses. And all this is directly related to the new Holographic Processor Unit (HPU).


Latency is king in VR/AR – head movement and other inputs need to be rapidly digested by the computer and updated on the display. If this takes longer than 50ms, you’re going to feel ill. Using a general-purpose CPU, and graphics processor unit (GPU) this is achievable but not easy. If your CPU is also busy trying to understand the work – tracking hand movements, backgrounds, cameras, etc – then that gets harder.

Therefore the HPU seems to be being used to offload some of this processing – the HPU can combine all the different data inputs and provide them to applications and the CPU as a simple, low bandwidth, data stream. For example, rather than the CPU having to parse a frame from a camera, detect where hands are, then identify finger locations, orientation, etc, the HPU can do all this and supply the CPU with a basic set of co-ordinates for each of the joints in the hands.

Using a specialist ASIC (chip) allows this to be done fast, and in a power-efficient manner. The HPU does a small number of things, but does them very very well.

I mentioned bandwidth a moment ago, and this provides a hint of where the HPU is. Multiple (possibly 4-6) cameras at sufficiently high frame rates result in vast amounts of data being used every second. This could be streamed wirelessly to the control box, but that would require very high frequency wireless which would be wasteful for power. If, however, the HPU is in the headset then it could instead stream the post-processed low-bandwidth data to/from the control box instead.
Where to put the GPU is a harder question – a lot of data needs to be sent to the graphics memory for processing, so it’s likely that the GPU is in the control box, which then wirelessly streams the video output to the headset.

Since my writeup, [12] has come out which states that in the demo/dev unit they used the HPU was actually worn around the neck, with the headset tethered to a PC. It’s unknown what this means for the final, release, version, but it sounds like there’s a lot of miniaturisation and optimisation needed at the moment.

Other computers

While the HoloLens has been designed to be standalone (albeit with the control/processor box around your neck), a big question is whether it will support other control/processor boxes – for example will it be possible to interface HoloLens with a laptop or PC. This would allow power users willing to forego some flexibility of movement (depending on wireless ranges) to use the higher processor/GPU power in their non-portable boxes. This may require some kind of dongle to handle the wireless communication – assuming some non-standard wireless protocols are being used, possibly at a non-standard frequency – e.g. the 24GHz ISM band instead of the 2.4GHz used for WiFi and Bluetooth, or the 5.8GHz used for newer WiFi. My hope is that this will be supported.


Windows 10 Holographic UI

Windows 10 will support HoloLens natively – apparently all UIs will support it. This could actually be a lot simpler to implement than you’d imagine. Currently, each window on Windows has a location (X,Y) and a size(width,height). In a 3D display, the location now has to have a new Z co-ordinate (X,Y,Z), and a rotation around each axis (rX, rY, rZ). That provides sufficient information to display windows in a 3D world. Optionally you could also add warps to allow windows to be curved – that’s just a couple of other variables.

Importantly, all of this can be hidden from applications unless they want the information. An application just paints into a window, which Windows warps/transforms into the world. An application detects user input by mouse clicks in a 2D world, which Windows can provide by finding the intersection between the line of your gaze and the plane of the window.

So most applications should just work.

Furthermore, as the HoloLens will be using Windows 10, maybe it’s more likely that other platforms (e.g. laptops) also running Windows 10 will be able to interface with the headset.


That said, many developers will be excited to operate in a 3D world, and that’s where the APIs come in. The Kinect libraries were a bit of a pain to work with, so hopefully MS have learnt some lessons there. The key thing will be to provide a couple of different layers of abstraction for developers, to allow devs the flexibility to do what they want, but have MS libraries do the heavy lifting when possible. MS hasn’t a great history of this – with many APIs not providing easy access to lower level abstractions, so this will be something to watch.

It will also be interesting to see how the APIs and Holographic UI interoperate with other head mounted displays such as the Oculus Rift. Hopefully some standards can be defined to allow people to pick and choose their headset – there are some use cases that VR is better for than AR, and vice versa.


As ever with an announcement like this, there are many questions. However it’s impressive that Microsoft felt the product mature enough to provide journalists with interactive (albeit tightly scripted) demonstrations. Some of the questions, and things to look out for, include:-
– What is the actual resolution, Field of View, and refresh rate?
– Is there really eye tracking?
– How well does the AR tracking work, especially in non-ideal lighting?
– What is the battery life like?
– How well does the Holographic Interface actually work?
– What is the API, and how easy is it code against?
– What is the performance like, playing videos and games for example – given that games are very reliant on powerful GPUs?
– Can the headset be used with other Windows 10 platforms?
– Can other headsets be used with the Windows 10 Holographic UI?
– Patent arsiness: MS has filed several recent patents in this space, are they going to use these against other players in this space, or are they primarily for defensive use?

Some Maths

You may wonder how I came up with the estimate of Field of View. For source material I used several photos, some information on Head Geometry, and a bit of trigonometry.

Figure 2: HoloLens Front Dimensions
Figure 2: Front view – note estimated size in pixels
Figure 3: Worn
Figure 3: Worn view – note alignment with eyes
Figure 4: Side view
Figure 4: Side view – note distance of lenses vs nose

Firstly, by looking at the photos in figures 2, 3, and 4 I estimated the following:-
– The display (per eyes) was around 110×80 pixels
– The display runs horizontally from roughly level with the outside of the eye, and is symmetrical around the pupil when looking dead ahead
– The display is somewhere between halfway between the depression of the nose between the eyes (sellion) and the tip of then nose, and the tip.

From this, we can get the following information, using the 50th percentile for women:-
– Eye width: 5.6cm (#5-#2 in [3], assuming symmetry of the eye around the pupil)
– Screen distance: 1cm to 2.1cm (#12-#11 in [3])

Figure 5: Trigonometry
Figure 5: Trigonometry

Given the 110×80 pixel ratio, that gives a height of around 4cm. Using the simple trig formula from figure 5, where tan X = (A/2)/B we can punch in some numbers.

Horizontally: A = 5.6cm, B=1 to 2.1cm, therefore C=70.3 to 53 degrees
Vertically: A=4cm, B=1 to 2.1cm, therefore C=63.4 to 43.6 degrees

Note that the field of view is 2 x C.

[9] provides a different estimate of the size of the display: “A frame appears in front of me, about the size of a 50-inch HDTV at 10 feet, or perhaps an iPad at half arm’s length.” This results in the following estimates:-
– 50-inch (127cm) (A) at 10 feet (305cm) (B) => C = 11.8 degrees diagonal
– iPad (9.7 inch, 24.6cm) (A) at half arm’s length (60cm/2) (B) => C = 22.3 degrees diagonal

[6] estimates 40×22 degrees, 60Hz 4Mpx(2.5k)/8Mpx(4k)

[3] Head Dimensions

MINERVA and the NCC Group’s Cyber10k

I have had the idea for a tool to automate, and optimise, threat modelling and related aspects of IT security for a while now. Over my many, many, years in IT security I’ve constantly been astonished how developers often couldn’t answer even quite simple questions about attack surfaces, and so the first several days of a gig would involve just trying to work out how a product works. In my certifications role, I was often tasked with explaining to some government how feature X worked, and why it was secure, and the often dire quality of documentation would regularly mean I’d have to go to the source code for answers. And I’ve lost count of the number of issues I’ve seen in programs and libraries written by SMEs and in the open-source world, that a simple and not-too-painful bit of targeted testing should have found.

A few months back, I resigned from my then employer, planning to take 6+ months off to work on my own projects, of which this is one. Around the same time I heard of the NCC Group’s Cyber10k. I decided to take a punt and enter my attack surface thingy idea, now called MINERVA, into the competition. I figured that if I won, then I’d have a few extra months to work on my projects before I had to get a real job. And irrespective, it would be good to get external validation of my ideas, and possibly also open up a pool of people who may be interested in alpha-testing.

Amazingly, I won!! And development is now proceeding at pace. The idea behind MINERVA has never been to make money from it (although that would be nice), but rather that I think there’s a real need for this tool. The status quo is shockingly poor, and my hope is that MINERVA will help the industry by automating something that is dull and slow to do, yet really useful. That said, what I’m trying to do is hard – I’ve estimated around a 75% chance of succeeding at all, and only 40% that it would meet it’s stated aims. This was recognised independently by the Cyber10k judges, and I’m extremely happy that they decided to take a punt anyway.

Following the Telegraph and NCC Group articles, I thought it would be useful to provide some more details on what MINERVA is, what problems it’s trying to fix, and overall what the design goals are. These have been extracted from my submission to the Cyber10k, albeit with assorted tweaks. When I submitted to the competition this whole product was purely theoretical, and there have unsurprisingly been design changes since then – no plan survives contact with the enemy – which I have noted below.

MINERVA Introduction

MINERVA is a proposed system which would address multiple issues found in today’s resource-constrained IT development environment. This represents the entry for the Cyber10k challenge “Practical cyber security in start-ups and other resource constrained environments”. It also partially addresses some aspects of other challenges.

The system makes the documentation of attack surfaces, and by extension threat models, easier to do by non-experts. It does this by simplified top-down tools, but primarily through the use of bottom-up tools which will attempt to automatically construct attack surface models based on the code written. Using these combination of tools, plus others, the system can correlate between high level design and low level implementation, and highlight areas these do not sync. It can also automatically detect and track changes in the attack surface over time.

By making the system scalable, MINERVA will allow integration of attack surface models from large numbers of components, allowing high level views of the attack surfaces of large systems up-to and including operating systems and mobile devices. Allowing cloud integration enables support even amongst third party and open source components, together with dynamic updating of threats when new vulnerabilities are identified.

This greater knowledge of attack surface can then be used to prompt developers with questions about threat mitigations, and help them consider security issues in development even without the input of security specialists, thus raising the bar for all software development which uses MINERVA. It can further be used by security specialists to identify areas for research, centrally archive the results of threat modelling and architecture reviews, and generally make more efficient use of their limited time.

Problem Definition

Threat modelling has been proven to be an excellent tool in increasing the security of software. It is built into many methodologies, most notably the Microsoft Security Development Lifecycle. A well written threat model, with good coverage, attention made to mitigations, and then with testing of those mitigations, will likely help lead to a relatively secure product – certainly above industry standards.

Unfortunately threat modelling is difficult, and generally requires security specialist involvement, and there is always a shortage of specialists with the correct skills. There have been numerous attempts to make the process simpler to allow developer involvement, and to educate developers, but these have had minimal impact in general – unfortunately developers are also regularly in short supply, are over worked, and so are unwilling to sink time into a process with, to their mind, nebulous benefits.

Indeed, it’s not uncommon for developers to barely document their work at all, let alone create security documentation. As developers move away from traditional waterfall design and development to newer methodologies such as AGILE, this problem is only getting worse, and even if written at some point, they rapidly fall out of date. Even under waterfall methodologies, where design documents exist, it is common for implementation itself to be quite different, and it’s rare for developers to go back and update the design documents. Even when threat modelling is performed, these are often stored in a variety of formats such as Word documents, as well as threat-modelling specific formats such as the Microsoft .tm4 files. These are rarely centrally stored and archived, and so it can be difficult to identify whether a threat model has been created, let alone how well it was written, and whether it was actually used for anything.

Furthermore, products are becoming more complex over time. Threat models are often written for a specific feature or component, but these are rarely linked with others. Assumptions made in one component, such as that another component is performing certain checks on incoming data, are not always verified leading to security vulnerabilities deep within a product. Even if the assumptions were correct initially, this does not mean the assumption will be correct several versions of software later.

Finally, open source and other third party components can lead to complications. These may be updated without the product developer being made aware, and this may be due to security issues. Developers rarely wish to spend time performing threat modelling and the like on code they do not own, and for non-open-source components it may not even be possible to do so due to a lack of product documentation.

Solution Objectives

MINERVA attempts to address the problems described above. Prior to the design itself, it is worthwhile to call out the high-level features the solution should have – what are the objectives of MINERVA.

Attack surface analysis
It must be possible for a user to create, view, and modify an attack surface model. This must include an interface which uses data flow diagrams (DFDs), and also via a text-based interface. Other diagrams such as UML activity diagrams may be supported.
Centralised storage
Attack surface models must be stored in a centralised location. This should be able to be used to provide a holistic view of an entire product. Change tracking must be supported, together with warnings when changes in one model impact assumptions made in another. Attack surface models must be viewable at different levels of granularity, from product/OS down to process or finer grained.
The centralised storage must support authentication and authorization checks. There must be administration, and audit logging.
It should be possible to perform an impact analysis of security issues found in third party bugs.
Distributed storage
It must be possible for different instances of MINERVA to refer to or pull attack surface models from each other, subject to permissions. For example, the attack surface model for a product which uses OpenSSL should be able to just refer to the attack surface model for OpenSSL, stored on a public server, rather than having to re-implement its own version.
This distributed storage must support dependency tracking and versioning, such that the correct versions of attack surface models are used, and also such that a warning can be provided if a security vulnerability is flagged in an external dependency.
External references should support both imports as well as references, allowing use by non-internet-connected instances of MINERVA. Generally the relationships between servers should be pull, rather than push.
Automated input
It must be possible for automated tools to import and modify attack surface models, or parts thereof. These tools should include the scanning of source code, binaries, and before/after scans of systems when a product is installed or run.
The protocol and API for these must be publicly documented and available, to allow third parties to extend the functionality of MINERVA.
Manual Modification and Input
It must be possible for users to manually create, edit, and view attack surface models. Different interfaces may be desired for developers, security specialists, and third party contractors. Threat models must also be editable.
Automated Analysis
It must be possible for automated tools to analyse stored attack surface models. The protocol and APIs for this must be publicly documented.
There must be a tool which takes an attack surface model, and generates a threat model, which a user can then modify. A tool should be able to generate test plans.
Tools must exist which detect changes in the implementation or design, and which identify where the design and implementation of a product differ.
A tool could be provided which would allow the application of design templates, for example Common Criteria Protection Profiles, which would be used to prompt the creation of an attack surface model, and allow exportation of parts of a Common Criteria Security Target.
Workflow fits in with standard methodologies
Where possible, use of MINERVA should fit in with standard development methodologies. For top down waterfall methodologies, the diagrams created within MINERVA should be the same as those used in design documentation – it should be possible to trivially import and export between MINERVA and design documentation. For Agile, this should mean dynamic creation of models based on source code, change tracking, and generation of test plans and the like.
Due to the plethora of design methodologies, this objective can be met if it will be feasible to write tools which provide the appropriate support, and some sample tools may be written for a subset of common methodologies – one top down, and one iterative/Agile – as proofs of concept.

Solution Design

High level design


The high level architecture for MINERVA is extremely simple, as shown in Figure 1. A database holds the attack surface models, threat models, and administrative details such as usernames and passwords. Access to the database is mediated by the MINERVA server itself. The server also performs validation of attack surfaces, authentication and authorization, and interpolation between attack surface levels – for example if a tool requests a high level simplified attack surface model, but the server only has a very low level detailed model, then the server will construct the high level model.

Figure 1: High Level Architecture
Figure 1: High Level Architecture

All tools (including the Inter-Service Interface) communicate with the server via the same SOAP over HTTPS interface (Note: Currently using json over HTTPS). An exception may be made for administration, restricting access to only a single port – thus allowing firewalls to restrict access to only an administration host or network. Authentication will initially be against credentials held in the database, however the aim is to allow HTTP(S) authentication, and thus allow Kerberos integration and the like.

The ISI will be used to pull data from remote instances of the MINERVA server. This will use the same protocol and authentication as other tools – it is essentially just another tool connecting to the external server.

Attack Surface Models

The main data stored within the database is the attack surface models. Figure 2 shows the structure of an attack surface model. The database schema will be based around this.

Under the preliminary model of an attack surface model, a solution is made up of a set of networks, appliances (which are situated on networks, and processes (within the appliances), and security domains. A network in this context is a logical group of components, which may or may not be on the same local network. An appliance is the hardware and operating system, although there will initially be an assumption that there is only one operating system on a set of hardware – i.e. virtualisation will initially not be supported. A process relates to an operating system process. In general, a security domain will align with a network, appliance, and/or process. Generally a security domain boundary can be present between processes, and/or between processes/components and assets.

Any time a dataflow crosses a security domain boundary, there is the opportunity to place a filter on either side of the boundary – for example for a network protocol dataflow, this could be a firewall, and for IPC it could be permissions.

A network is made up of Appliances, which contain processes. The network as a whole is deemed to have a set of users – these are abstract users used to differentiate between users with different permissions and capabilities, and in different security domains.

Figure 2: Attack Surface Model
Figure 2: Attack Surface Model

Appliances contain operating systems – these are used to define the allowable set of permissions, capabilities, and the like that a user or process may be given.

Processes have attributes, and are made up of threads. Threads have attributes and are made up of components. Components interact with each other, and with assets and dataflows such as files, IPC, network connections, and user interface. (Note: Currently I’m collapsing all threads in a process into a single thread – this is for simplicity sake).

Generally high level attack surface models are made up of networks, appliances, and optionally processes. Low level models are made up of components, threads, and processes. Of course, at each level there may be abstractions such as grouping several processes or appliances together. This structure is aimed at providing a framework, rather than mandating a format. The underlying database schema will necessarily need to be rather complex to deal with the multitude of different formats of attack surface model which may be designed.

For each asset or interprocess communication method, source and destinations are defined – this may be a many:many relationship. When these are in different security domains, a primary threat vector may be generated for threat modelling. When these do not cross a domain a secondary threat vector may be generated – for example where defence in depth may be involved.

It is planned that development will begin at the Process and below level, higher levels will not be addressed until later in the development process. (Note: Development has proceeded with this plan. There is support for networks etc but I’ve focused on processes and below, as well as the capabilities an OS may have.)

Example Attack Surface Model

We will now explore an example attack surface model, designed from the top down, using MINERVA as an example. Figure 3 shows the highest level architecture, which is made up of only two parts. Each of these would be stored as a separate process set, on an undefined appliance. By having the appliance undefined, this means that the processes may be on the same, or different, appliances. Each process set is in a different security domain, meaning that the SOAP over HTTPS (Note: JSON over HTTPS is actually being used) crosses between security domains and hence represents a threat.

Figure 3: High Level DFD
Figure 3: High level DFD

This high level data flow diagram (DFD) provides structure, but isn’t especially useful of itself. The MINERVA server can be further decomposed as in Figure 4. This takes the MINERVA server process, with a single thread, which contains the components described. It should be noted that the Database here is a component, rather than an asset – assets are specific, whereas components are generic.

Figure 4: MINERVA Server DFD
Figure 4: MINERVA Server DFD

The dotted part of the MINERVA Server DFD can be further decomposed, and made more specific, as shown in Figure 5. When decomposition occurs, stubs will be auto-generated based on the higher level, for example in Figure 5 the Verification and Read stubs are present. Normally the components defined in the higher level DFD would be sketched into the decomposed DFD, such that when the finer grained components are defined in the lower-level DFD then a relationship will be assigned between a higher level component, and the lower level subcomponents (which are just stored as components within the database, with a parent/child relationship).

Also of note in Figure 5 is that a package is defined (SQLite 3) which is a reference to a LIB or DLL – this would be stored as an attribute. A file asset is also defined, in a separate security domain.

Figure 5: Storage Decomposition
Figure 5: Storage decomposition

Where network components are involved, an alternate type of decomposition may be useful – stack based decomposition. MINERVA knows the network stack involved for an expandable set of well-known protocols, such as SOAP over HTTPS in this case. The user may be prompted with the stack as shown in Figure 6 (Original Version) and the user can then break the stack into relevant components. For example, in Figure 6 (Component Decomposed) the Operating System (defined by the Appliance) handles up-to and including TCP. The process then uses OpenSSL (with a specified version) for parsing of SSL, and the Connection Handler subcomponent is used for HTTP and SOAP parsing. Of course, MINERVA may also make a guess about the stack – for example if it knows HTTPS is in use, and also notes that OpenSSL is an included DLL.

Figure 6: Connection Handler Decomposition
Figure 6: Connection Handler Decomposition

The Connection Handler in the decomposed version is a different Connection Handler to that in the Original Version. The system is aware of this because it has different connections – it communicates with OpenSSL rather than ‘Tools’. The name of a component is stored as metadata, rather than it being the identifier.

An alternate method for decomposing is shown in Figure 6 (Alternative Component Decomposed). This doesn’t use the stack decomposition method, but rather appears more as a protocol break. This display may be more appropriate for display when numerous components are shown rather than just the high level Connection Handler, however it will be less common for attack surface model creation by novices. This is an example of how different types of display may be used for different scenarios.

What can be done with this information

When constructing an attack surface model from the top down, the data collected can be used to verify the low level implementation.


  • What dynamic libraries should be loaded?
  • What files should be opened, and in what mode (r/w/x)?
  • What network connections should be opened/listened for?
  • What IPC methods should be defined, with what permissions?
  • What OS privileges/permissions should the process have?


  • What firewall rules should apply?
  • Similarly, what Intrusion Detection System rules could apply?
  • Should the connection be encrypted? This can be tested for.
  • Should there be authentication? This may be tested for.
  • File

  • What files are opened, and how (exclusive access?, r/w/x)
  • What permissions should any files have (vs the user the process is running as, and vs other users which may need to access the file)
  • Lib and DLL/SO files

  • What versions are in use? These could be used for bug tracking.
  • Import attack surfaces and threat models for these products from other MINERVA servers
  • For a bottom up attack surface model, all the above may be collected, and used to construct the attack surface model. For example a scan may find that ProcessX.exe has:-

  • Network: Listening on tcp/8001
  • File: wibble.db (identified as a SQLite3 Database by tools such as file or TrID)
  • DLL: OpenSSL version a.b.c, importing functions to do with SSL
  • LIB: SQLite version d.e.f (learnt from the build environment)
  • Makeflags: ASLR (-fPIE), -fstack-protector, -FORTIFY_SOURCE, -Wformat, -Wformat-security
  • RunAs: UserX, who has standard user permissions
  • The import tool could take this information, and use this to prompt for the following:-

    • Net
      • What protocol is on tcp/8001?
      • Where are connections from tcp/8001 expected from? What security domains?
    • Files
      • For wibble.db, confirm that it is a SQLite 3 file
      • What assumptions are made about access to the file, which users, apps, etc should have access?
      • What data is stored – is it sensitive?
      • Should it be encrypted? Should it hold data that is encrypted by the app?

    This can all be used to define an attack surface model, with minimal overhead.

    Once an attack surface model has been defined, this could also be used to perform “what if” analyses. For example, what if component X was compromised, and hence the security domain it is in changes?

    Something that may also be attempted would be to take an attack surface model for a product for a given OS, and change the OS. Different operating systems have different privileges, capabilities, and permissions, and MINERVA could help prompt for and define those which should be used for new and different operating systems.

    Design Decisions

    The MINERVA server will be written in C#, due to familiarity with the language, cross platform support, and extensive tooling already existing for it. Tools will be written in whichever languages make sense. C# will be the default choice with native extensions where needed, however the Linux application will likely be Perl due to ease of programming.

    The network protocol used will be HTTPS, as it is a standard and will support all necessary requirements. SOAP may be used over this, again for standards requirements. REST was considered, however the authentication requirements and large payloads mean that SOAP will be the most suitable. This decision may be revisited when development is under way. (Note: Currently using JSON, as it’s vastly easier to code for).

    Authentication will initially be against credentials held in the database, as this will be the easiest mechanism to implement and non-enterprise customers may prefer it. HTTP(S) authentication, against OS/AD credentials, is a stated aim for the future, to facilitate enterprise use.

    The database will be SQLite initially due to ease of use. There are scalability concerns with SQLite however, which may require support of an enterprise grade database in the future. All database operations must therefore go through an abstraction layer in order to ensure that any future changes are as painless as possible. (Note: Doing code-first database development, it was easiest to use MS SQL.)

    The main OS to be targeted for development will be Windows 7 and later, although where possible the design and implementation should be host OS agnostic. v1.0 should also include support from Linux clients/targets, and possibly also Android.

    Minimum Features

    As seen in the high-level design, the majority of the functionality of the solution depends on external tools. The following tools and features are the minimum desired set which must be in place before it can be deemed to be version 1.0.

    Graphical UI for creation of attack surface models diagrammatically
    People are used to drawing attack surfaces, and for simple systems this may still be the easiest way for knowledgeable users to create high level threat models. The Microsoft TM tool has become the de-facto standard for this, and so a similar tool will be needed for MINERVA. This tool would allow the graphical representation, as a data-flow-diagram of attack surface models, for viewing, creation, and modification of attack surfaces at all levels. (Note: Currently just using exports from the MS tool, but there are serious problems when deeper integration is desired. For example, having the ability to right-click on a graphical node, and then automatically scan the associated process/file).
    UI for creation of attack surface models textually
    For larger and more complex attack surfaces, creating attack surface models diagrammatically isn’t necessarily ideal. Furthermore, while a drawing canvas is good for people versed in the creation of these diagrams, for non-security-specialists a text-based input method may be best. This would allow users to list, for example, all the different interfaces, IPC, etc used, and then describe how these are implemented by different components. This would also allow a tool to prompt the user for more information, and make them think in a certain way. (Note: Currently implemented in a datagrid)
    Windows Process Scanner
    One way to identify an attack surface is to scan a running system. This can work in several ways: by analysing a system before and after an application is installed and then comparing these, or by monitoring a processes execution to detect files, IPC, network connections and the like that are created dynamically. Realistically both will need to be used.
    The Microsoft Attack Surface Analyzer performs the former task already – the MINERVA tool will allow the import and parsing of these. There are a number of different tools which provide the latter functionality, however it is most likely that something custom will be written, albeit using commonly known and used techniques to gain the desired information. (Note: Currently using text output from Sysinternals Process Explorer etc – although the plan is to write a more tightly-coupled tool in the future)
    Linux Process Scanner
    This would be the Linux equivalent to the Windows Process Scanner. For version 1.0 it will only include support for a couple of the more common distributions.
    Stupid Source Scanner
    Some components, such as static libraries, cannot be scanned using the previous tools. Therefore a basic tool will need to be written to grep through source code and development environments to try to generate an attack surface. There already exist tools which spider source code, looking for security issues for example, however few of these allow third party plugins or extensions.
    While the preferred solution for this tool will be to extend an existing third party tool, a custom tool may need to be written. The tool would need to be able to handle the following for version 1.0: parsing of Makefiles, MS .VSProj, C/C++, C#, and Java. For version 1.0 the quality of the parsing/spidering will be very basic – essentially grepping for specific APIs, and identifying linked libraries.
    Use may also be made of code annotations for the likes of Lint, and C# Contracts. It should be noted that the aim of the Stupid Source Scanner is not, certainly initially, to be anything like complete, rather it is to get quick and dirty information out of the codebase with minimum involvement of developers.
    Microsoft Threat Model (.tm4) Import Tool
    The Microsoft TM tool is the standard for creation of attack surface diagrams, and using this to create threat models. These are saved in .tm4 files, which are simple XML. As a lot of security-aware enterprises may have already attempted to create threat models using this tool, for a subset of their components, it is vital to be able to import these into MINERVA. For version 1.0, attack surfaces must be imported, however the threat models themselves do not need to be parsed – they can just be stored until support is added with a later version of MINERVA.
    Support for exporting as a .tm4 may also be added, depending on ease.
    Administration Tool
    Any product whose aim is to hold security-sensitive information, and be used by large numbers of users, must support authentication and authorization checks. These in turn require administration. Likewise and administrator must be able to decide which attack surface models, for which components, and to what level of detail, may be shared externally. The administration tool will provide a mechanism to perform these administrative functions, as well as access to logging including security audit logs.
    Inter-Service Interface
    A stated aim of MINERVA is to allow sharing of attack surface models between different instances of MINERVA. Rather than building support for this into the MINERVA server itself, a separate tool is desirable for security reasons as well as to simplify implementation. The ISI will essentially just be another tool, running with its own credentials, and so even if the ISI were to be compromised then that wouldn’t lead to compromise of the server itself.
    Threat Model Generation
    An obvious use for an attack surface is to automate generation of threat models. This tool will perform this generation, and could potentially allow user interaction with the threat models themselves – although this could be implemented as a separate tool.
    Test Plan and Coverage Generation
    Once an attack surface has been designed, test plans and coverage analysis may be an alternate way to convey to developers the same information as a threat model would. This tool could list, for example, the different tests which should be performed to gain assurance that the implementation is secure – for example it may call out the network interfaces to fuzz, the files to try modifying, and the like. By conveying the information in a way that developers are more used to understanding, this may help increase coverage of security-relevant testing – for example many developers do very little ‘negative’ testing, and instead rely on ‘positive’ testing.
    Firewall Exception Generation
    Through analysis of network connections/interfaces, a list of expected firewall rules together with protocols may be generated. This would be of use to customers, where a developer has used MINERVA, for example to know what firewall exceptions to put in together with what network traffic their Network-IDS should be detecting. It will also be useful for developers to detect and enumerate unexpected network connections, for example debug support which have accidentally be left in.

    Development Order

    A proposed order for the development of the minimum features is below. For each feature, support will be added to the main server as needed. The first step will of course be to create the server itself, with backing database and network APIs. Following this, a rough administration tool will be written – this will allow testing of the network APIs. The UI tool for textual creation/representation of models will be next, due to ease of implementation, and to allow further testing of the server, and then threat model import in order to be able to quickly fill in examples. The Stupid Source Scanner, and either the Windows or Linux Process Scanner will be next, to test bottom-up attack surface construction. At this point the solution will in some ways be surpassing what is currently available in the public domain.

    The Inter-Service Interface will next be stood up, to test being able to import/export between MINERVA instances. Writing a Graphical UI for attack surface diagrams will likely be non-trivial, and so until this point the MS TM tool will have been used extensively. However, this is a necessary tool to have, and so it would be written at this point. This is the last tool to input attack surfaces. The generation and analysis tools will finally be written, as these are dependent on a number of previous features.

    So, in summary, the rough order for development will be as follows, although of course there will likely be overlap between all of these.

    1. MINERVA server
    2. Administration Tool
    3. UI for creation of attack surface models textually
    4. Microsoft Threat Model (.tm4) Import Tool
    5. Stupid Source Scanner (Note: I’m doing a v0.1 of the Windows Process Scanner first)
    6. Windows Process Scanner (Note: v0.1 takes the text output from existing tools such as Sysinternals Process Explorer)
    7. Inter-Service Interface
    8. Graphical UI for creation of attack surface models diagrammatically
    9. Linux Process Scanner
    10. Test Plan and Coverage Generation
    11. Firewall Exception Generation
    12. Threat Model Generation

    Stretch Goals

    While the above are the minimum features, there are several other tools and ideas that may prove desirable at some point.
    Binary Analysis
    Parsing of DLL/SO or LIB files to look for interfaces, for example looking at import tables to identify APIs in use.
    Common Criteria Security Target Generation
    Common Criteria relies on a Security Target document, which states how a product meets certain design requirements. This document is very onerous to create, but there are some aspects which could be automated based on attack surface diagrams and mitigations called out in threat models.
    Graphical UI for other diagram types
    The standard diagram type for attack surface diagrams is the dataflow diagram. However, other diagrams may be useful at times, for example UML Class, Package, and Activity diagrams may all be useful at certain levels of attack surface model.
    Taint Tracking
    If there could be some standardisation of attack surface model components, plus the expected contents of files, IPC, and network traffic, then some form of taint tracking may be possible. For example, if a file should be encrypted, and a high-level component is flagged as performing encryption, then the low level analysis could perform source code or dynamic analysis to identify whether encryption APIs are in fact being used. If there was no high-level component which was flagged as performing encryption, then that could be identified as an issue.

    Current Status

    Since submitting to Cyber10k, I have begun actual development of MINERVA – as noted before, winning Cyber10k would be a bonus but I was planning to give it a stab anyway. Of course, finding out I won has added a certain impetus.

    The Minerva server is currently operational, albeit with no concept of user controls (for administration), or data versioning. Nonetheless, attack surface models can be stored and queried, and the combination of separate threat models has been proven – for example when two ‘solutions’ read/write from the same file, or listen/connect to a network connection, then correlation can be performed and arbitrary attack surface models drawn which may include some of each solution.

    I used code-first database design techniques with Visual Studio, in C#, and so have used MS SQL, with JSON as a protocol just because it’s so damned easy. I have an administration client which also allows me to manually add/delete/modify attack surface models via a table-like UI. I can import MS .tm4 files, but this hasn’t been tested with the newest generation of the Microsoft Threat Modelling tool. Export to .TM4 isn’t yet supported either. I’m currently working on using the text/CSV output from existing tools such as dumpbin, and Process Explorer, as a temporary stopgap for proof-of-concept of the Windows Process Scanner. The next steps will be to export threat models, perform a few bits of analysis, and then have a custom-written Windows Process Scanner.

    Fingers crossed, I’m hoping to be alpha-testing in November, with a v1.0 by March 2015 (by which point I may need to get a real job again :( ). Still, things are looking remarkably good at the moment.

    Anyway, I hope this was of some interest to some people. Please feel free to hit me up if you’re interested in alpha- or beta-testing Minerva, or have any other queries – always happy to chat. In addition to the blog, feel free to email me at minerva at

    A bit of Orbital Mechanics

    When I read about the failed insertion [1] of several Galileo satellites, I was intrigued whether they would have enough propellant on board to sufficiently alter their orbit. My gut said no, but I decided to do the math to find out. Below is my working – note though that I’m self taught so this may be wrong :) Also note that the numbers I’ve given below are rounded, so there may be rounding errors, and I’ve made numerous simplifying assumptions such as not needing to fix the LAN or Mean anomaly.

    The TLDR is that nope, they’re way short (assuming my maths works out). DeltaV requirements are as follows (m/s):-

    • Best case deltaV needed: 587+70=657
      • Fix inclination: 432
      • Fix Perigee: 369
      • Fix Inclination+Perigee at the same time: 587
      • Fix Apogee: 70
      • Fix Apogee+Perigee at the same time: 675
    • Best case available deltaV: 250

    Intro to terms

    For those not familiar with orbital mechanics etc, I thought I’d define a few terms:-
    Delta V (dV): Change in velocity needed/available.
    Apogee (s_a): The furthest point of an orbit from the earth
    Perigee (s_p: The closest the orbit gets to the earth
    Inclination (i): The angle between (in this case) the rotation of the earth, and the orbit. 0 degrees means the orbit is around the equator, whereas 90 degrees means a polar orbit, going over the n/s poles
    Semi-Major Axis (a): All non-escape orbits are ellipses. The Semi-Major Axis is half the distance between extremes of the orbit.
    Isp (I): The Isp is a measure of the efficiency of an engine, in units of seconds.
    Gravitational Coefficient (G): A constant you need to know
    Mass of the earth (M): Another constant you need to know
    Radius of the earth (R): Another constant. We’ll assume the earth is a sphere.
    x,y,z: X is parallel to earth’s surface, in line with equator, Y is parallel to earth’s surface, towards the north pole. and z is towards the center of the earth.
    Eccentricity (e): A measure of how far from a circle the orbit is – 1 is a circle.

    A quick aside – all the formulae use SI units (kg, m, s), hence don’t forget to change km to m… And note that the Apogee and Perigee are altitudes above the earth’s surface, so you need to remember to add the radius of the earth a lot of the time.

    dV needed

    So, first of all, let’s extract some of the numbers we need from the article, and a couple of other pages.
    Current Apogee: 25922km
    Current Perigee: 13700km
    Current Inclination: 47
    Desired Apogee, Perigee: 26189km
    Desired Inclination: 55.04
    Eccentricity (e): 0.23

    The most efficient way to fix the orbit will to a) change the inclination at apogee, then b) raise the perigee, then c) drop the apogee. A lot of burns combine (b) and (c) into a single circularisation burn, which is generally inefficient. An alternative is to combine (a) and (b).

    The formulae we’ll need here are:-
    Semi-major axis: a = R+(s_a+s_p)/2 [4]
    Velocity in orbit: v = \sqrt{GM[2/r-1/a]} where r is current radius, i.e. distance from center of earth


    When at Apogee, the satellite is moving parallel to the earth’s surface. Its velocity v will have north/south and east/west components of v_y and v_x respectively.
    v_x = v.cos(i),  v_y = v.sin(i)
    Plugging numbers in, we get the following current situation:
    a = 26189km, v_a=3076ms^{-1}  => v_x=2099ms^{-1}, v_y=2251ms^{-1}

    Using the same v_a but changing i, we can get the new v_x, v_y:
    v_{x\_new} = 1763, v_{y\_new} = 2522

    Therefore, we can see the burn we need is (dv_x, dv_y) = (v_x, v_y) - (v_{x\_new}, v_{y\_new})
    (dv_x,dv_y) = (-335, 271) => dv = \sqrt{dv_x^2+dv_y^2} = 431ms^{-1}

    Raise Perigee

    To raise the perigee, we burn along the line of the velocity vector, injecting energy into the orbit. So, we start with the current velocity at apogee v, then find out the new velocity needed v_{a\_new} for the new semi-major axis a_{new}.
    First we computer a_{new} using the desired perigee rather than the current perigee. We then calculate what velocity we’d have at apogee using a_{new}.
    That gives us: a_{new} = 31100km, v_{new\_peri} = 3446 therefore dv = 369ms^{-1}

    Changing inclination and raising perigee

    We can combine the previous steps into a single step. To do this we take the v_{new-peri} from the “Raise Perigee” step, and use that instead of v_a in the calculations used for the “Inclination” step. This gives the following results:
    v_{x\_new2}=1975, v_{y\_new2}=2825 => dv=(-124,574) => dv = 587ms^{-1}

    As we can see, it’s more efficient to do this than separate – 587 vs 431+369

    Drop Apogee

    At this point, the perigee is at the correct altitude, but the apogee is too high. To fix this, at the perigee we do a retro burn to remove energy from the orbit. Using the semi-major axis calculated at the “Raise Perigee” step, we calculate the new semi-major axis for a circular orbit a_{circ} and use this to calculate v_{circ\_peri} at the perigee. Subtracting v_{circ\_peri} from v_{peri} we can get the dv needed.
    Plugging the numbers in: a_{circ}=29900, v_{circ\_peri}=3653, v_{cur\_peri}=3723 => dv = 70ms^{-1}

    Circularise Perigee+Apogee in one step

    An alternative to separately raising the perigee and then dropping the apogee (the traditional hoffman transfer), a burn can be made when the satellite is at the correct altitude, to change both the perigee and apogee at the same time. This is normally sub-optimal, but let’s see what happens.

    We start with the orbit after the inclination is fixed. When the satellite is between apogee and perigee, it has a velocity vector which is both parallel to the earths’ surface (v_{xy}) and towards the earth v_z. To calculate this, we need the angle down at which the satellite is travelling (\theta). To calculate this, we start with the specific angular momentum of the satellite [5]:
    h = \sqrt{ a(1-e^2)GM } (where M is the mass of the earth+satellite)
    The angle \theta = cos^{-1}(h/rv) where r = radius at desired apogee/perigee, v is velocity magnitude at that point.
    This angle can then be used to get v_{xy} and v_z in the same way as we did in the inclination. The desired v_{z-desired} = 0 as we want a circular orbit, with v_{xy\_desired} = v_{circ\_peri} i.e. the velocity of a circular orbit.
    Plugging in the numbers, we get:
    \theta=10.5, v_{xy}=3327, v_z=619, v_{xy\_desired}=3653, v{z\_desired}=0
    We can therefore calculate the needed delta-v:
    dv=(269, 619) = 675

    As can be seen, the 675 ms^{-1} needed to do both is much greater than the 369+70 needed to do a Hoffman transfer.

    Available dV

    Looking at the above, the best case scenario is to fix the inclination and perigee at the same time, and then the apogee. That would take 587ms^{-1} + 70ms^{-1} = 657ms^{-1} deltaV.

    The galileo satellites have an empty mass of 660kg, and carries 73kg of Hydrazine. It uses MONARC-1 [2] motors, each developing 1N of thrust with an Isp of 230s.
    To find the flow rate (i.e. mass of Hydrazine per unit time) we use the following (from [3]): \dot{m} = F_{thrust} / I_{sp} . g_0
    Using that we can get a total burn time t_{burn-max} = m_{fuel} / \dot{m}
    Plugging in numbers, that gets us a burn time of t_{burn-max} = 16710s for a single motor. Using multiple motors will increase the thrust, but decrease the burn time by the same ratio.

    While F_thrust may be constant over time, mass doesn’t. However, we’ll simplify with a best-case scenario, using the empty mass with F=ma for t_{burn\_max} seconds.
    This gives us dv_{empty} = (F_{thrust}/m_empty) * t_{burn\_max} = 250ms{-1}

    This is much less than any basic maneuvers – a best case of 657 is needed.



    Data Retention and Investigatory Powers Bill

    The leaders of the three main parties in the UK parliament are in the process of railroading a bill through parliament which supporters claim are vital for public safety and national security, and detractors claim is an unnecessary and undemocratic power grab by the security agencies.

    The truth, as ever, lies somewhere between these two extremes. Most of the reporting on this is very much of the he-say-she-say type, with little or no actual referral to actual facts. I thought it may be worthwhile to look at this myself.

    My position

    I believe that wiretaps, monitoring, and the like are absolutely vital powers, but there must be excellent oversight, and these powers must only be used in a proportionate manner.

    I think it’s disgusting that this bill is being rushed through. Yes, it likely took a while for civil servants to review what the ECJ ruling meant, and then draft the bill, but that’s no a good enough justification. I do agree that part of the delay in this was due to incompetence, rather than malice, however that’s no excuse for the power grab that’s enshrined in this bill.

    Furthermore, the bill does a lot more than just meet the issues arising from the ECJ ruling, and in fact it alone doesn’t even meet those issues – some future regulations will be needed first, and these will need to be passed by parliament. So it doesn’t even meet it’s stated aims.

    The bill as written has a number of areas that concern me. The Secretary of State gets a lot of extra powers in the form of regulations, which given the current views of the Home Office are likely to be abusive and expansive. The assertion that only metadata is covered is potentially false. The expansion beyond UK borders is very troubling, badly drafted, and when combined with the existing shortcomings in RIPA clarifies that any UK citizen using a non-UK-based server has essentially zero protections against their data being queried by the UK government without a warrant.

    Many of the assertions being made by the government are false, and I think it’s disgusting that they are willing to lie in this manner. Protections being lauded by some politicians, such as oversight boards and the like, are not enshrined in the Bill.

    This bill doesn’t address the shortcomings highlighted in the ECJ ruling, and so it would inevitably be over-ruled in the future.

    Overall, this Bill shouldn’t be passed in its current form – the fact that it likely will is a sad indictment of the lack of  backbone amongst current politicians when faced with privacy or security concerns.



    What is it?

    One big source of confusion is that the bill addresses two different things. Firstly, it addresses retention notices – this is what the ECJ ruled on. The second is warrants for obtaining the information. These two are different, and relate to different data.

    On the retention front, the government can issue a retention notice to a public telecommunications operator to retain relevant communications data.

    A public telecommunications operator is anyone who operates a public telecoms service (DRIP 2(1)), which is (RIPA 2(1)) any system which exists for the purpose of facilitating the transmission of communications by any means involving the use of electrical or electro-magnetic energy. [amended by DRIP 5 to include:  any case where a service consists in or includes facilitating the creation, management or storage of communications transmitted, or that may be transmitted, by means of such a system.] i.e. anything which moves data from one place/person to another, or does any storage of such. So this includes not just ISPs, and internet pipes, but also the likes of Facebook and Google.

    The key word above was “relevant”. There’s a big difference between “relevant communications data” and “communications data”. It appears that “relevant communications data” is used when referring to retention, and “communications data” for obtaining the information – the latter is much broader than the former.

    Relevant communications data is the metadata “of the kind” currently specified in the 2009 EC Data Retention Directive schedule. The schedule data is basically addressing, date/time, and duration of communications. A big area of danger is the “of the kind” phrase – that’s seriously vague and could be used for a lot.

    Communications data is concretely much broader, from RIPA 21(4):

    1. any traffic data comprised in or attached to a communication (whether by the sender or otherwise) for the purposes of any telecommunication system by means of which it is being or may be transmitted; i.e. this is horrendously drafted and could mean anything. I think it’s supposed to mean addresses etc, but also includes hashes, routing info, etc.
    2. any information which includes none of the contents of a communication (apart from any information falling within paragraph (a)) and is about the use made by any person (i)of any postal service or telecommunications service; or (ii)in connection with the provision to or use by any person of any telecommunications service, of any part of a telecommunication system; i.e. Basically anything other than content. This includes subscriber information, billing addresses and details, etc. Any service which does analysis of message contents, for example Google and Facebook extracting data for advertising purposes, may also be fair game, although a case could be made that this includes the contents of comms.
    3. any information not falling within paragraph (a) or (b) that is held or obtained, in relation to persons to whom he provides the service, by a person providing a postal service or telecommunications service. i.e. essentially a catch-all which includes absolutely everything _except_ message data.

    It expressly doesn’t include “data revealing the content of a communication” (DRIP 2(2)).

    What data will be covered?

    See the previous section for details, but basically it depends on whether you’re talking about retention, or what the government can request.

    Retention: Definitely addresses, dates, times, and durations for any communication, and possibly much more.

    Acquisition and Disclosure: Absolutely everything to do with internet comms and data, except the contents of the comms data itself. This includes who talks to whom, when, and how much is said. It also includes any details the service provider may keep about you, including billing information, addresses, etc. For ISPs this may not sound too bad, but things get more complicated with services such as Facebook and Google. They build up analyses of your behaviour for advertising – that may be in scope. They keep track of who you ‘Like’, groups you join, websites you visit, and so on. So, pretty much everything is fair game. Note though that this is broadly an already existing power under RIPA.

    Where is covered?

    Everywhere. Or more specifically, every service that offers any service to the UK public.

    DRIP 4(6) can also be used to require a foreign person/company to maintain an interception capability, including for conduct outside the UK. So, the very equipment and capabilities which the EU and UK have an embargo on for Syria (and others), can be mandated (and subsidized (DRIP 1(4(g)), RIPA 14)) in other countries by the UK government.

    DRIP extends or clarifies this extra-territoriality for interception, requiring that an interception capability be maintained, and also for retention and disclosure.

    Who is covered?

    Everyone, of any nationality. Nothing has changed there since RIPA/Data Retention Directive. Under DRIP section (4) this has been expanded (or clarified, as the government would have you believe) to include non-UK people, not in the UK, on non-UK servers.

    Other powers and regulations?

    One of the areas of concern relates to DRIP 1(3), which allows “The Secretary of State [to] by regulations make further provision about the retention of relevant communications data.”  DRIP 1(4) does call out the restrictions on what may be in these regulations, and these don’t look too broad at a first glance, but I’m not holding my breath. One concern is that these regulations can be used to require telecoms operators to give retained data to the government without needing a warrant (DRIP 1(6)(b)), although to be fair that was already the case under RIPA section 22.

    The regulations “may refer to communications data that is of the kind mentioned in Schedule to the 2009 Regulations”, which to my mind also means that it may be able to refer to other data.

    DRIP 2(5) does at least require that any such regulations must be passed by parliament, however there have been no assurances provided that these won’t also be rushed through. Such regulations will have to be passed soon, and I wouldn’t be surprised if they are also rushed through: DRIP 1(4)(h) states that the regulations may include a provision that “the 2009 Regulations ceasing to have effect and the transition to the retention of data by virtue of this section.” – given that that is the stated aim of this Bill being rushed through, as the ECJ ruling has overruled the 2009 Regulations.

    Extraterritorial extensions

    Section 4 of DRIP expands (or clarifies) how the retention notices and RIPA may be used outside the UK. Much of section 4 details who to address the notices to, etc. Basically, section 4 states that retention notices and warrants may be issued to non-UK companies and people, with no UK presence, if they offer a public service on the internet.

    DRIP 4(4) does give some protection to foreign companies/people who receive a retention notice/warrant – local laws can be taken into account when deciding whether implementing such a warrant/notice is ‘reasonable’ and hence whether they have to comply.

    RIPA 1(1) and 1(2) expressly state that it is only illegal to perform interception without warrant within the UK.

    Therefore, interception can be performed on UK citizens using non-UK-based servers without a warrant, retention notices need to be issued by a Secretary of State, and access to retained and other non-interception data needs to be requested by one of a long list of designated persons.


    Government Assertions

    Home secretary Theresa May has stated that lives will be lost if the legislation does not go through.

    David Cameron repeatedly saying that it was essential to track and catch “terrorists, paedophiles and criminals” and warned that the “consequences of not acting are grave”.

    “I want to be very clear that we are not introducing new powers or capabilities – that is not for this parliament. This is about restoring two vital measures ensuring that our law enforcement and intelligence agencies maintain the right tools to keep us all safe.

    “As events in Iraq and Syria demonstrate, now is not the time to be scaling back on our ability to keep our people safe. The ability to access information about communications and intercept the communications of dangerous individuals is essential to fight the threat from criminals and terrorists targeting the UK.”

    Simon Hughes MP asserted, on Murnaghan, Sky News, “We are limiting the number of people who can ask for data, fourteen bodies are no longer able to ask for data at all, all the councils in the country, every council in Britain at the moment can ask for data and that’s been consolidated into only one place for request.  David Anderson, a really good guy, who is there making sure that our terrorism legislation is working, has been given additional powers, we have a new scrutiny committee – those are Lib Dem gains.”

    My response

    At no point has the government explained why they need 12 months of data. Why not 11, or 13? Or 6? The ECJ ruling called out this shortcoming in the EC Directive, and it still hasn’t been addressed.

    Using Iraq and Syria as examples of why this is needed is disingenuous at best, and outright attempt to play on our fears at the worst. The government can already use warrants to target collection of both data and metadata against individuals and groups involved in both of these conflicts. Why, therefore, do they need these extra powers?

    The assertion that they are not introducing new powers is demonstrably false. The bill allows the Secretary of State (which actually means any one of a number of individuals) to create regulations which may vastly broaden current law – the scope allowed under section 1(3)-1(7) and 2(4), although with the caveat that such regulations would need to be approved by parliament (2(5)). Note however that such approval is often rather pro-forma.

    Furthermore, while DRIP is allegedly just targeted at fixing the retention law issues resulting from the ECJ ruling, it does much more. While sections 1 and 2 of DRIP deal with retention notices, sections 3-5 deal with warrants under RIPA.

    The largest power grab relates to extra-territorial aspects of RIPA. The argument is that this was implicit already in RIPA, and that’s possibly accurate. However, the specific area of concern is 4(8) amendment (5A) – this seems to allow retention/disclosure requests, on foreign companies who have any offices or offer any services in the  UK, but covering conduct that occurs outside the UK by non-UK nationals. So can the UK government make a request against Facebook for the monitoring of a US citizen in the US, and punish Facebook if they don’t comply?

    As for Simon Hughes’s claims, absolutely none of these are detailed in DRIP. While they may be good in theory, these are currently paper tigers against threats to privacy.


    ECJ Ruling

    ECJ ruling is all about proportionality:-

    1. No “differentiation, limitation or exception” on types of traffic data
    2. No “objective criterion” to ensure that authorities only have access as needed
    3. No “objective criteria” on basis of period of retention
    4. “Risk of abuse” – not sufficient safeguards, nor ensure that data destroyed at end of retention period
    5. No requirement that data be “retained within the EU”

    So how does DRIP measure up?

    1. DRIP refers to “relevant communications data”, by which it means the Data Retention Regulations 2009 Schedule. This specifically calls out what metadata should be retained. So the type of data is limited. In theory DRIP 1(1) also limits collection to only that which is proportionate under RIPA 22(2). However, the list of grounds are so broad that I wouldn’t be surprised if retention notices are issued against all users, “in the interests of national security” or similar. So DRIP probably passes the ECJ test, but it’s hardly reliable.
    2. Within the UK, access is limited under RIPA 22(2), and may only be granted by a “designated person” (of which there are rather a lot). This is probably sufficient, although as noted in (1) these are so broad that they can apply to a lot of situations.
    3. There is still no objective criteria for period of retention, so this is a fail. This may be coming in the regulations mentioned in DRIP 1(3) and 1(4).
    4. The protections in RIPA may be sufficient for the “Risk of abuse”, although there is no mention of oversight. There’s currently nothing ensuring destruction, although this may be coming in the future regulations, so currently this is a fail.
    5. There’s still no requirement that data be retained within the EU, although this may be clarified in the future regulations.

    For (1), (2), and (4), the important question is one of oversight. The justifications for retention and disclosure are so broad that anyone can be caught up with them – any oversight body must ensure the proportionality of both retention and disclosure.
    For (3), (4), and (5), the future regulations are vital – and we’ve no idea what they say until they are published.

    So, overall, DRIP does not currently address the issues within the ECJ ruling, although it may do so in the future, when the Secretary of State publishes some new regulations, which are allowed under DRIP, but which must also be passed by parliament. Given this, it makes you wonder why the rush to pass DRIP, if the ECJ issues won’t be addressed until the regulations are published, at some future date.


    Relevant Links

    Data Retention and Investigatory Powers Bill – the draft bill being proposed by the government

    Regulation of Investigatory Powers Act 2000 – the act being amended by this bill

    Anti-terrorism, Crime and Security Act 2001 (Part 11) – Required retention of communications data, and in section 102 defines “communications data”

    ECJ Ruling – This is the ruling which ruled that blanket collection was illegal, and which allegedly forced the government to push this bill through

    Data Retention (EC Directive) Regulations 2009 Schedule – Lists the data to be retained


    FYI, I have just sent my MP the below email.

    Dear Paul Burstow,

    RE: Data Retention and Investigatory Powers Bill

    I am writing to ask you to consider voting against the upcoming Data
    Retention and Investigatory Powers Bill, or as a minimum vigorously
    participating in the debate against it.

    I think it is highly undemocratic and frankly disgusting that the Bill
    is being rushed through in this manner. The government has been aware
    of the issue arising from the ECJ ruling since April and have done
    nothing to address them – although maybe this should be ascribed to
    incompetence rather than malice. The Bill as drafted will not even
    address all the current shortcomings highlighted by the ECJ ruling –
    rather a Secretary of State will need to create, and parliament pass,
    additional regulations, so there should be no need to push through the
    retention parts of the Bill so urgently, without also making the
    proposed regulations available even in draft form.

    Liberal Democratic MPs have been trumpeting additional protections they
    have wrestled from the Tories, however only two of these are actually
    present in the Bill – that of a maximum twelve month retention period
    and an expiry in 2016. For the former, as this is something the ECJ
    ruling had already hinted at, it was hardly a major win. For the
    latter, that’s a valid win, although also not a major one – the Bill
    may be reinstated in the future without any guarantee of a larger
    debate on privacy versus security, and the roles of RIPA, CMA, DRIP,
    the Anti-terrorism, Crime and Security Act, and others. As stated, any
    other protections are not in the Bill, and so could be dropped,
    amended, or varied as desired by the whim of any government.

    Contrary to claims being made by both LD and Tory MPs, the Bill does do
    more than just deal with the retention issues arising from the ECJ
    ruling. Three of the five main sections deal with investigatory powers,
    and not retention. The Bill is rather confusing because of this, as it
    contains and doesn’t clearly differentiate between retention,
    acquisition of retained (or other) data, and interception, nor
    differentiate between the different data (“relevant communications
    data” versus “communications data”) which may be requested for each,
    plus it uses vague terms such as “data of the kind mentioned”.

    To summarise, the Bill doesn’t just do what the government says it
    does, and doesn’t fully do what the government says it does. The
    protections being trumpeted cannot be relied upon. And finally, even if
    there is need for an urgent Bill to meet the ECJ ruling, this isn’t it.

    For more details on my thoughts, please feel free to see my blog post
    at or  contact me via email or telephone.

    Yours sincerely,


    Oculus and Facebook

    I’m a fan of the potential of VR. The cyberpunk genre has spoken to me loudly, and VR is an exciting tech that always gets me excited when reading this genre.
    Because of this, I’ve been an Oculus Rift follower since the kickstarter, and have been an evangelist since receiving my development kit (now called the DK1). I’ve already ordered a DK2, and am looking forward to seeing the consumer version (CV1) when it is released.
    Waking up to the Facebook deal announcement, my first reaction was one of shock – in common with pretty much everyone online. Shock, and dismay. But I decided to take a few minutes to think before posting online. On reflection, all may not be doom and gloom.

    The Deal

    My understanding is that the deal is for $400M cash, and $1.6B stock. A large part of that will likely go to the Venture Capitalists who had already invested $75M. And that’s the first important point:

    • OculusVR was already not a master of its own fate. VCs gain a lot of control when they invest, and often expect to get their returns within 3 years, irrespective of the negative impact in the long-term. So the FB deal is in many ways just OculusVR trading one master for another.

    Now when an acquisition happens, there is normally an earnout period. What this means is that the company being bought, and the execs who have signed on to the deal, must hit certain targets within certain timeframes. For OculusVR that may mean CV1 being released in certain timeframes, for example. Often it also means that senior leadership cannot leave without huge penalties. So the odds of anyone senior leaving soon are negligible, even if FB does start interfering. In general though, unhappy people will leave immediately after the earnout, which raises point 2:

    • John Carmack, Palmer Luckey, and other senior leadership are useful canaries for how the relationship is going. If they leave before earnout ends, then the Rift is dead. If they leave shortly after, then that’s a really bad sign that Facebook’s and OculusVR’s vision of the future is incompatible. If they’re still there 3-6 months after earnout, then the future looks promising.

    Note though that earnout restrictions work both ways, so if FB breaks its contractual obligations, then it may face large penalties – those obligations may be things like no interference in design, manufacture, etc – the sorts of things Palmer, Carmack etc care about. That sort of thing may even have to appear in FB public earnings statements, if the penalties and write-downs are large enough.

    Impact of the Purchase

    One point Palmer has made is that the FB purchase, and subsequent investments, will help with future scaling issues. This is a really important point – businesses are expensive to run, especially when manufacturing hardware. And all companies go through an existential crisis when then stop being little 5-30 person teams, and start suddenly having wage bills of over $1M a month.
    Suddenly you start having to get good legal, accounting, HR people. Tax becomes more complex. FB already has teams who can do all that non-VR work, and so OculusVR no longer has to spend time and effort hiring them, installing HR systems and software, being overcharged to put in some over-the-top SAP system, etc. So, another point:

    • The FB purchase allows OculusVR to focus on VR, and let Facebook handle all the dull crap that comes with running a company.

    Also on the question of scaling is the cost of manufacturing hardware. For DK1, OculusVR covered the cost through kickstarter – people like me donated money so that OculusVR could write a big-ass check to a Chinese manufacturer to make X devices, and then having the tooling and spare parts to make Y more in batches of Z.
    For DK2, the funding presumably came from the Venture Capitalists, and of course from pre-orders. That’s all well and good, but note that they haven’t really _sold_ much yet. The margins on DK1 and DK2 are likely not especially large, so profits on each sale will be low, if any. Furthermore, they aren’t selling that many devices – for example 60k units, at $330 ea, assuming a 10% margin, would only mean $1.98M profit. That sounds like a lot, but really it isn’t, given that we’re not factoring in R&D, wages, legal, taxes, etc. And 10% is likely waaaaay too high.
    So what does all this mean for scaling and CV1. Well, let’s assume they want to sell 200k of these worldwide on launch. That’s a pretty low target. And let’s say the manufacture cost is $200 a unit. That means that several months before launch, with no real revenue coming in, they need to go to the manufacturer and cut a check for $40M. That’s a lot of money, and they likely wouldn’t have been able to do it without taking on more investors or some big ass loans (with interest). Now though, they’ve Facebook’s deep pockets to help them, and Facebook will be keen to help as it will reduce their own tax bill. Win/win! So, another point:

    • With FB’s deep pockets, OculusVR can now easily afford to go large with the launch of CV1, and potentially have a lower price by being able to manufacture in larger batches.

    So, what does Facebook get out of all this, and what negative impact may this have on OculusVR and VR in general?
    Well, here I’m a bit vague. There’s a load of ideas floating around, but everything is rather nebulous. Some of my thoughts are:-

    1. FB may just be diversifying. If VR is successful then they’ll have a foot in the door and a new revenue stream. This is not a bad thing.
    2. FB want Augmented Reality (AR) and this is a way forward. AR means overlaying and interacting with the real world, and this would open up all sorts of new sources of revenue for advertising and data mining. This is quite a ways off though – OculusVR is about good seated VR at the moment – AR brings vast numbers of new challenges so I wouldn’t expect anything serious, and certainly not consumer grade, for a good 3-5 years.
    3. FB want to pop up adds in games. While they may want this, I doubt they’ll get it. There are a load of other upcoming VR platforms and if OculusVR did this then people would flock away from them. And game designers would leave as well – with good reason as who wants your carefully crafted story interrupted by an Ad for a dating site.
    4. FB wants to add adverts to games. Now this is a different thing. Having an SDK to allow injection of FB adverts into games opens up new revenue for game designers themselves. Mediaspike is already doing that sort of thing, and it could be a really unintrusive idea. However, it’s the game engines, and not the VR hardware and SDK, that would do this, so really FB could do this irrespective of OculusVR.
    5. FB want to own the portal and lock-in gamers. Based on the investors call I heard, FB may well want to become the go-to portal for VR games, in the same way as Steam are for PC games (sorry, EA Origin). I see no problem with this, as long as it’s not mandatory. Making the user experience of installing and running VR games easier is an absolute necessity for consumer take-up, and so FB may really help adoption here. However, lock-in, such as that Apple helped create, is baaaad, and if FB do this then I will leave Oculus, simple as that. Unfortunately, consumers may not – look at how well Apple have done…
    6. FB wants the patents for offensive/defensive purposes. I’m not sure what patents OculusVR actually own though. It may be that they have instead relied on prior art. If that’s the case, then FB doesn’t have anything with which to sue other VR hardware manufacturers and the point is moot. If there are patents, then I’m not sure how much of a chilling effect that will have on VR either – AFAIK Facebook haven’t been the litiginous beasts that Apple and the wider smartphone industry seem to have become over the last few years. Still, something to keep an eye on.

    Notch and community reactions

    My first action after hearing of the purchase was to check out the OculusVR forums, and reddit. Wow! I was more shocked and dismayed by the vituperation on those than by the purchase itself! But I shouldn’t have expected anything else from the internet – where people reach for keyboards before they’ve taken a breath and had a cup of tea.
    To be fair, some of the concerns are valid, and there are well organised thoughts here and there, but overall the reaction reminded me of nothing as much as when a band signs up with a big label.
    One potentially valid complaint is in reference to kickstarter. People feel like they have invested their money into an indie, and that OculusVR have broken their word and even worse, made in unethical decision. I must admit to feeling this a little myself, and I do think that OculusVR should give back to the community, maybe by giving all kickstarter followers a free CV1 or similar. But at the same time, everyone must remember what kickstarter is:

    • Kickstarter is not an investment vehicle. It’s a way of making donations to things you care about, and potentially getting rewards. Once you’ve received your reward, the recipient of your donations owes you nothing.

    Another complaint is that senior OculusVR leadership have stated in the past that they wouldn’t sell. Well, they shouldn’t have said that. But what they probably meant was that they wouldn’t sell just because of the money, and with the Facebook deal they’ve explicitly stated that nothing is going to interfere with their vision.
    I’ve seen some posts by people stating they are cancelling their DK2 order, and going for Sony instead. Well, more fool you if that’s truly the case – this is the same Sony who has a patent for pausing games in order to show you adverts…
    As for Notch’s statement about Minecraft for OculusVR, it’s not as big a deal as people seem to be making out. Firstly and most importantly, because nothing has been cancelled. According to Notch’s statement, they were only “in talks” about bringing “a slimmed down version” of Minecraft to OculusVR. I agree with him on some things – I find Facebook creepy as well, and am regularly disgusted by their behaviour regarding privacy and API changes – but his statement will have little to no effect on OculusVR itself.
    Overall, I think the community itself should give itself a communal kick in the genitals about their over-reaction. The sort of incoherent argument, invective, and insults which have been flying around make us sound like a group of spoilt 16 year old hipsters, and is frankly more likely to damage VR in the short term than anything OculusVR and Facebook will likely do.

    In summary

    Overall, my gut feel is that this acquisition will be good for the Oculus Rift product, and VR in general, for the next 1-2 years. Most of the worst-case predictions that people are coming up with online are too far-fetched to be realistic. But there are definitely areas for concern, especially if the Rift becomes too tied into Facebook, and if the worst case scenario of curated app stores and vendor lock in happen. Depending on the patent situation though, any such idiocy by Facebook/Oculus would not harm the overall VR industry too much – there will be competitors to pick up where OculusVR left off.

    Oculus Rift resources

    I’ve just arrived home following an excellent weekend at the Nine Worlds convention ( I strongly recommend that anyone in UK/Europe look into it, and consider going next year.

    On a whim I decided to bring my Oculus Rift to the con, and let attendees try it out. It turns out there was rather a lot of interest – my best guess is 125+ people tried it out over the three days. For those who want more information, I thought I’d collate some links.

    You can currently buy the developer kit from the Oculus website (follow the pre-order link), for 300USD. For those in the UK, expect to be stung by VAT+Customs – IIRC overall it cost around 300GBP total.

    A really important note is that this is a developer kit – the consumer version will be higher resolution, won’t show the gaps between pixels, and will generally be more user friendly. Similarly, a lot of the games and demos are alpha/beta quality code, so expect bugs, issues, and weirdness. If you’re not willing to accept these issues, I recommend waiting for the consumer version. I expect Rift support to be quite niche, with mainly indie games supporting it for a fair while, but the 3rd party drivers work relatively well and may work for future AAA titles.