The Diametric Safety Case Manager

In my work life I have spent the past two years writing the Diametric Safety Case Manager (DSM). This uses Goal Structuring Notation to represent safety arguments and bow-tie diagrams to represent the relationships between events and hazards.

Underlying these diagrams is a safety model; everything on a diagram is represented by an entity in the underlying model. A graphical query notation lets the user create tables and reports based on the contents of the model. Here is an example showing how a Failure Modes and Effects Analysis (FMEA) can be constructed from data entered in bow-tie diagrams.

The DSM is written in Haskell using GTK3 and Reactive Banana. I've blogged about the underlying mechanism here.

Donald Trump is Zaphod Beeblebrox

Here are some quotes from the Hitchhikers Guide to the Galaxy, lightly edited...

One of the major difficulties Trillian Theresa May experienced in her relationship with Zaphod Donald Trump was learning to distinguish between him pretending to be stupid just to get people off their guard, pretending to be stupid because he couldn’t be bothered to think and wanted someone else to do it for him, pretending to be outrageously stupid to hide the fact that he actually didn’t understand what was going on, and really being genuinely stupid.

It is a well known fact that those people who most want to rule people are, ipso facto, those least suited to do it. To summarize the summary: anyone who is capable of getting themselves made President should on no account be allowed to do the job.

The President in particular is very much a figurehead — he wields no real power whatsoever. He is apparently chosen by the government voters, but the qualities he is required to display are not those of leadership but those of finely judged outrage. For this reason the President is always a controversial choice, always an infuriating but fascinating character. His job is not to wield power but to draw attention away from it. On those criteria Zaphod Beeblebrox Donald Trump is one of the most successful Presidents the Galaxy United States has ever had — he has already spent two of his ten presidential years in prison for fraud..

A very long Haskell type

For GUI programming I've migrated from the gtk2hs library to the gi-gtk library. This uses overloaded labels to access the properties of GTK3 objects.

I wanted a function which would set the background and foreground colours of a widget. Rather than simply have it modify the object I decided to have it return a list of property setters. It looks like this (the function "contrastText" just returns either white or black):

setColour c = do
      bg <- colourToRGBA c
      fg <- colourToRGBA $ contrastText c
      return [#backgroundRgba := bg, #foregroundRgba := fg]

However when I couldn't get it to type-check I asked ghci what the type should be. Here is the reply!

> :type setColour
setColour
  :: (Data.GI.Base.Attributes.AttrOpIsAllowed
        tag
        (Data.GI.Base.Attributes.AttrAllowedOps
           (Data.GI.Base.Overloading.FindElement
              "foregroundRgba"
              (Data.GI.Base.Overloading.AttributeList obj)
              (((('GHC.TypeLits.Text "Unknown attribute \8216"
                  'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "foregroundRgba")
                 'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217 for object \8216")
                'GHC.TypeLits.:<>: 'GHC.TypeLits.ShowType obj)
               'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217.")))
        (Data.GI.Base.Attributes.AttrLabel
           (Data.GI.Base.Overloading.FindElement
              "foregroundRgba"
              (Data.GI.Base.Overloading.AttributeList obj)
              (((('GHC.TypeLits.Text "Unknown attribute \8216"
                  'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "foregroundRgba")
                 'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217 for object \8216")
                'GHC.TypeLits.:<>: 'GHC.TypeLits.ShowType obj)
               'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217.")))
        (Data.GI.Base.Attributes.AttrOrigin
           (Data.GI.Base.Overloading.FindElement
              "foregroundRgba"
              (Data.GI.Base.Overloading.AttributeList obj)
              (((('GHC.TypeLits.Text "Unknown attribute \8216"
                  'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "foregroundRgba")
                 'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217 for object \8216")
                'GHC.TypeLits.:<>: 'GHC.TypeLits.ShowType obj)
               'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217.")))
        obj
      ~
      'Data.GI.Base.Attributes.OpIsAllowed,
      Data.GI.Base.Attributes.AttrOpIsAllowed
        tag
        (Data.GI.Base.Attributes.AttrAllowedOps
           (Data.GI.Base.Overloading.FindElement
              "backgroundRgba"
              (Data.GI.Base.Overloading.AttributeList obj)
              (((('GHC.TypeLits.Text "Unknown attribute \8216"
                  'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "backgroundRgba")
                 'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217 for object \8216")
                'GHC.TypeLits.:<>: 'GHC.TypeLits.ShowType obj)
               'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217.")))
        (Data.GI.Base.Attributes.AttrLabel
           (Data.GI.Base.Overloading.FindElement
              "backgroundRgba"
              (Data.GI.Base.Overloading.AttributeList obj)
              (((('GHC.TypeLits.Text "Unknown attribute \8216"
                  'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "backgroundRgba")
                 'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217 for object \8216")
                'GHC.TypeLits.:<>: 'GHC.TypeLits.ShowType obj)
               'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217.")))
        (Data.GI.Base.Attributes.AttrOrigin
           (Data.GI.Base.Overloading.FindElement
              "backgroundRgba"
              (Data.GI.Base.Overloading.AttributeList obj)
              (((('GHC.TypeLits.Text "Unknown attribute \8216"
                  'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "backgroundRgba")
                 'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217 for object \8216")
                'GHC.TypeLits.:<>: 'GHC.TypeLits.ShowType obj)
               'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217.")))
        obj
      ~
      'Data.GI.Base.Attributes.OpIsAllowed,
      Data.GI.Base.Attributes.AttrInfo
        (Data.GI.Base.Overloading.FindElement
           "foregroundRgba"
           (Data.GI.Base.Overloading.AttributeList obj)
           (((('GHC.TypeLits.Text "Unknown attribute \8216"
               'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "foregroundRgba")
              'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217 for object \8216")
             'GHC.TypeLits.:<>: 'GHC.TypeLits.ShowType obj)
            'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217.")),
      Data.GI.Base.Attributes.AttrInfo
        (Data.GI.Base.Overloading.FindElement
           "backgroundRgba"
           (Data.GI.Base.Overloading.AttributeList obj)
           (((('GHC.TypeLits.Text "Unknown attribute \8216"
               'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "backgroundRgba")
              'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217 for object \8216")
             'GHC.TypeLits.:<>: 'GHC.TypeLits.ShowType obj)
            'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217.")),
      Control.Monad.IO.Class.MonadIO m,
      Data.GI.Base.Overloading.HasAttributeList obj,
      Data.GI.Base.Attributes.AttrBaseTypeConstraint
        (Data.GI.Base.Overloading.FindElement
           "backgroundRgba"
           (Data.GI.Base.Overloading.AttributeList obj)
           (((('GHC.TypeLits.Text "Unknown attribute \8216"
               'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "backgroundRgba")
              'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217 for object \8216")
             'GHC.TypeLits.:<>: 'GHC.TypeLits.ShowType obj)
            'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217."))
        obj,
      Data.GI.Base.Attributes.AttrSetTypeConstraint
        (Data.GI.Base.Overloading.FindElement
           "backgroundRgba"
           (Data.GI.Base.Overloading.AttributeList obj)
           (((('GHC.TypeLits.Text "Unknown attribute \8216"
               'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "backgroundRgba")
              'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217 for object \8216")
             'GHC.TypeLits.:<>: 'GHC.TypeLits.ShowType obj)
            'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217."))
        GI.Gdk.Structs.RGBA.RGBA,
      Data.GI.Base.Attributes.AttrBaseTypeConstraint
        (Data.GI.Base.Overloading.FindElement
           "foregroundRgba"
           (Data.GI.Base.Overloading.AttributeList obj)
           (((('GHC.TypeLits.Text "Unknown attribute \8216"
               'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "foregroundRgba")
              'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217 for object \8216")
             'GHC.TypeLits.:<>: 'GHC.TypeLits.ShowType obj)
            'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217."))
        obj,
      Data.GI.Base.Attributes.AttrSetTypeConstraint
        (Data.GI.Base.Overloading.FindElement
           "foregroundRgba"
           (Data.GI.Base.Overloading.AttributeList obj)
           (((('GHC.TypeLits.Text "Unknown attribute \8216"
               'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "foregroundRgba")
              'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217 for object \8216")
             'GHC.TypeLits.:<>: 'GHC.TypeLits.ShowType obj)
            'GHC.TypeLits.:<>: 'GHC.TypeLits.Text "\8217."))
        GI.Gdk.Structs.RGBA.RGBA) =>
     Reactive.Banana.Common.Colour
     -> m [Data.GI.Base.Attributes.AttrOp obj tag]

Why I don’t believe in the Second Amendment (and neither do you or the Supreme Court)

The second amendment says:

A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed.

This consists of two parts, the preamble “A well regulated Militia, being necessary to the security of a free State” and the effective part “the right of the people to keep and bear Arms, shall not be infringed”.
The meaning of the effective part is very straightforward: “arms” means any kind of weapon. A bowie knife is “arms”, and during the Cold War the superpowers engaged in “Strategic Arms Limitations Talks” (SALT). Although military technology has changed beyond all recognition, the use of the word “arms” to mean any kind of weapon has not changed since 1791 when the Bill of Rights was ratified. Had James Madison and the other framers of the constitution been shown the modern world they would have had no hesitation in agreeing that any form of modern weaponry from a bowie knife to a nuke was included in the definition.

So it would seem that anyone in the United States of America has the constitutional right to purchase, say, a shoulder launched surface to air missile, and to bear that armament anywhere they wish, such as near the end of a runway where large passenger jets are taking off. That would not be a good idea. If military weapons were widely available then they would be used for mass murder of unarmed civilian targets. Stephen Paddock, the Las Vegas shooter, seems to have set out to kill as many people as possible, and he managed to kill 58. An Airbus A-380 typically has a maximum capacity of 525 plus crew, and if one were bought down over the right bit of city then the body count could go into the thousands. Given the opportunity Paddock would surely have done so, and he is not unique.

The Courts

Today the original intent of the Second Amendment is dead as a matter of established law. It is not legal for anyone within the United States to make or buy heavy weapons except under the most stringent and careful of controls.

This would have surprised and disappointed the framers. They had just fought a war in which ordinary armed citizens had beaten off the professional British army. The framers saw this as an important lesson; the liberty of their new nation would be assured by having an armed citizenry who could be relied upon to form a militia and fight against any future tyrant, foreign or domestic. This is what the preamble part of the Second Amendment is about.

I haven’t been able to find any case in which the constitutionality of this ban on heavy weapons has ever been truly tested. However the courts have found that bans on semi-automatic rifles and the carrying of handguns in public are constitutional, and the Supreme Court has declined to review these decisions.

In the case of the Maryland ban on assault rifles, the 4^th Circuit Court of Appeals decided 10-4 that the ban was constitutional. The judgement explains this with “Put simply, we have no power to extend Second Amendment protections to weapons of war”. The framers of the constitution would have found that bizzare; to them the Second Amendment was precisely about weapons of war.

On the other hand back in 1939 in the Miller case the Supreme Court decided that a sawn-off shotgun was not protected by the Second Amendment because it was not potentially a military weapon, and this is still a valid precedent (they may have been wrong about the military use of sawn-off shotguns in particular, but the principle still stands). So the 4^th Circuit has decided that military weapons are unprotected, and the Supreme Court has decided that non-military weapons are unprotected. According to these precedents it would seem that Americans have the constitutional right to keep and bear arms, except for military weapons and non-military weapons.

Self Defense

The most recent case on the Second Amendment that reached the Supreme Court was District of Columbia v Heller in 2008, which was about the constitutionality of a ban on handguns and a requirement that larger guns be kept unloaded and locked. The Court found 5-4 that this ban violated the Second Amendment.

The Heller case was about restrictions on small arms rather than heavy weapons, and the decision is rightly focussed on that. So the question of whether it is constitutional to own heavy weapons was not directly considered. However if the Court had found that small arms are protected by the plain meaning of the Second Amendment, then someone would have used this to challenge laws banning heavy weapons on the grounds that they are equally protected by the Second Amendment. So to overturn the handgun ban the Court had to do two things. First, they had to ignore the plain meaning of the words they were analysing, and second they had to find some other right to keep small arms.
They managed the first part by finding that the Second Amendment is not an unlimited right. They dispose of this in one brief paragraph:

Like most rights, the Second Amendment right is not unlimited. It is not a right to keep and carry any weapon whatsoever in any manner whatsoever and for whatever purpose: For example, concealed weapons prohibitions have been upheld under the Amendment or state analogues. The Court’s opinion should not be taken to cast doubt on longstanding prohibitions on the possession of firearms by felons and the mentally ill, or laws forbidding the carrying of firearms in sensitive places such as schools and government buildings, or laws imposing conditions and qualifications on the commercial sale of arms. Miller’s holding that the sorts of weapons protected are those “in common use at the time” finds support in the historical tradition of prohibiting the carrying of dangerous and unusual weapons.

It is true that, as with other parts of the Bill of Rights, the government can restrict the scope of a right where it has a pressing need to do so. Thus, for instance the First Amendment has at various times been limited to exclude the publication of libel, copyright infringement, certain secrets, and various kinds of pornography. However the scope of First Amendment restrictions has only rarely been allowed to extend beyond those areas. The only significant case in modern times was the Sedition Act of 1918, which the Supreme Court found constitutional the following year. However this is now considered to be a mistake; today the heart of the First Amendment is seen as political speech and any speech touching on politics enjoys the highest level of constitutional protection. The framers of the Constitution would surely agree that this is the proper state of affairs.

However the restrictions on the right to keep and bear arms are not so limited. The Second Amendment is primarily about military weapons, but under federal law today only weapons of little military use may be legally held by civilians. Imagine if the First Amendment were restricted to stating opinions that are in "common use", with citizens only allowed to comment on local politics and speech on state and national affairs being restricted to those government officials employed to do so. That would not be freedom of speech as it is understood in most of the world; indeed it would resemble many dicatorships.

So having found that the Second Amendment does not in fact protect the right to keep and bear most arms, the Supreme Court in 2008 had to find a right that protected handguns. They found this in the right to self defense.

Unlike the right to keep and bear arms, the right to self defense is not enumerated in the Bill of Rights. This is not a problem because the Ninth Amendment specifically says that this “shall not be construed to deny or disparage others retained by the people”. Anyone being attacked has the right to defend themselves with whatever means may be at hand; if you are faced with an attacker then you may pick up a golf club and swing at their head, or try to stab them with a kitchen knife, or just use your fists. The question in such cases is not whether the weapon is legal but whether it is used in a legitimate act of self defense. The same argument applies to guns; if you are forced to defend yourself then using a gun is as reasonable as using a knife, even if that gun was not one you were legally permitted to have.

However in Heller the Supreme Court, after exhaustive analysis of the history of self defense law in both the United States and the United Kingdom, concluded that the right to self defense included the right to keep a hand gun in your house for that purpose.

As an aside, I should say that some state constitutions provide a right to bear arms in self defense. Obviously in those states the situation is different, but this post is about the US constitution.

I’m not going to go any further into this question of personal self defense because this essay is not about that; its about the Second Amendment. Heller is not about the general right to keep and bear arms, its about the right to keep a hand gun as self defense against home invasions. The fact that the Supreme Court found it necessary to invoke a different right to protect hand guns shows that they don’t believe in the Second Amendment either; they actually upheld something different.

The NRA Version of the Second Amendment

The original purpose of the Second Amendment was not individual defense against home invasion, it was collective defense against tyranny. Despite a long consideration of the “well regulated militia” the Heller decision is silent on this question.

Supporters of the NRA are not silent on this question; when asked to justify the right to keep and bear small arms they claim that their guns are a bulwark against government over-reach. Some go so far as to claim that overturning the Second Amendment is the first step in a deep and dark plot to overthrow the rest of the Bill of Rights and institute a socialist tyranny.

However the historical facts do not support the NRA rhetoric on this. Since 1776 the US government has been responsible for a long and sad list of human rights violations, but civilian firearms have never prevented any of them. The last century alone saw the following:

• The Sedition Act of 1918, which directly violated the First Amendment by restricting political speech.
• The internment of Japanese Americans in World War II, in violoation of pretty much every constitutional right they had.
• The “Jim Crow” laws of the southern states, finally abolished in 1964. Not only were these laws themselves an infringement on the constitutional rights of many citizens, but they went alongside a grossly biased justice system that somehow never got around to prosecuting white perpetrators of violence against blacks.
• The Chicago “machine” rigging elections and protecting corrupt politicians.
• The FBI investigating and undermining lawful civil rights movements under J. Edgar Hoover
• Guantanamo Bay.
• Civil forfeiture used to seize property under mere suspicion.
  
• Pretextual traffic stops and “parallel construction” used to cover violations of the Fourth Amendment.
  
• A national security apparatus that routinely scans the email and other private communications of many American citizens without any effective oversight.
  

In all of this list civilian guns were never used to defend the rights of anyone. In the few cases where civilian guns appeared, such as Jim Crow lynch mobs, they were on the wrong side.

Has there ever been a case where guns held by civilians were effective in preventing a violation of constituional rights? I doubt it. The fact is that if the American government decides to act in violation of the constitution then there is nothing that a small band of gun owners can do to stop them. The government can always bring in bigger guns and more of them. Various small bands have tried to defy the government; it always ends badly. Today the only ways to change the way the American government behaves are the ballot box, the courts, and bribery making political donations. Pointing guns at government employees will simply get you shot.

Edit:  This Stack Exchange question  points to the Wounded Knee incident in 1973, which was indeed a case where civilians with guns prevented the infringement of constitutional rights by the government. Another answer to the same question also cited the Bundy standoff of 2014 and the related Malheur occupation of 2016, but they are not good examples. The Bundy standoff seems to have been driven by Cliven Bundy's fringe beliefs about federal land ownership rather than a real infringement of constitutional rights, and the Malheur occupation ended with the shooting of one participant and the arrest of everyone else.

The Second Amendment Today

The Bill of Rights was written at a time when there was little difference between military and civilian firearms, military ships were in civilian hands (“privateers”), and the fastest means of communication was a rider on horseback. Firearms were mostly muzzle-loading flintlocks; a skilled gunman might get off two or three rounds per minute and for an individual they were effectively single-shot weapons. They were also not very accurate. Effective use of such weapons required collective action to keep the enemy at bay while you reloaded. The only thing bigger than a rifle was a cannon, which was also muzzle loading and inaccurate.

Today the scope of military weapons has expanded along with the rest of our technology. If the Second Amendment were taken at face value today then many high explosive ranged weapons capable of major destruction would be within the financial reach of much of the population. I opened this essay by inviting you to consider a shoulder launched surface to air missile. I’d like to close by inviting you to consider a school shooter with a bazooka firing a white phosphorus munition.

Most of the Bill of Rights has fared surprisingly well with time; the First Amendment right to free speech now applies to film, television, web sites and computer software, but the basic principle is still the same. This is equally true of Amendments 3 to 10. The Second stands out as a product of its time, overtaken by changes in technology and society.

If you truly believe in the Second Amendment then you believe that any military weapon held by the armed forces of the United States should also be legally available to most civilians. I think the number of people who really believe that is very small. Even the National Rifle Association only believes in the right to keep rifles. There is no National Bazooka Association (actually that’s not true, but it seems to be only one person and may just be a joke).

Haskell with Reactive Banana and GTK3

I've been doing some GUI coding recently using a combination of Reactive Banana and GTK3. I started out with just GTK3, but I could see it wasn't going to scale because everything GTK3 does is in the IO monad. I found I was having to create IORefs to track the application state, and then pass these around for reading and writing by various event handlers. While the application was small this was manageable, but I could see that it was going to grow into a pile of imperative spaghetti as time went on.

I knew about functional reactive programming (FRP), and went on the hunt for a framework that would work with GTK3. I chose Reactive Banana despite the silly name because it seemed to be targeted at desktop GUI applications rather than games and simulations.

Connecting to GTK3

FRP is based around two key abstractions:

• Events are instants in time that carry some data. When the user clicks on a button in a GUI you want an event to denote the fact that the button was clicked. If the user moves a slider then you want an event with the new position of the slider.

• Behaviors carry data that changes over time. In theory this change can be continuous; for instance if you simulate a bouncing ball then the position of the ball is a behavior; at any point in time you can query it, and queries at different times will get different answers. However Reactive Banana only supports behaviors that change in response to events and remain constant the rest of the time. Thats fine: my application responds to user events and doesn't need continuous changes. Take the slider event I mentioned above: when the user moves the slider you want to update a sliderPosition behavior with the latest position so that other parts of the program can then use the value later on.

In Reactive Banana you can convert an event into a behavior with the "stepper" function. You can also get an event back when a behavior changes

Behaviors are a lot like the IORefs I was already using, but events are what make the whole thing scalable. In a large application you may want several things to happen when the user clicks something, but without the Event abstraction all of those things have to directly associated. This harms modularity because it creates dependencies between modules that own callbacks and modules that own widgets, and also causes uncertainty within callbacks about which other callbacks might already have been invoked. With FRP the widget creator can just return an Event without needing to know who receives it, and behaviours are not updated until all events have been executed.

There is already a binding between Reactive Banana and WxHaskell, but nothing for GTK. So my first job was to figure this out. Fortunately it turned out to be very simple. Every widget in GTK3 has three key lists of things in its API:

• IO functions. These are used to create widgets, and also to get and set various parameters. So for instance the slider widget has functions like this (I'm glossing over some typeclass stuff here. For now just take it that a slider has type Range):

     rangeGetValue :: Range -> IO Double
     rangeSetValue :: Range -> Double -> IO ()

• Attributes. These are kind of like lenses on the widget, in that they let you both read and write a value. However unlike Haskell lenses this only works in the IO monad. So for instance the slider widget has an attribute:
  

     rangeValue :: Attr Range Double

  You can access the attributes of a widget using the get and set functions. This is equivalent to using the two IO functions above.

• Signals. These are hooks where you can attach a callback to a widget using the on function. A callback is an IO monad action which is invoked whenever the signal is triggered. This is usually when the user does something, but can also be when the program does something. For instance the slider widget has a signal

     valueChanged :: Signal Range (IO ())

  The last argument is the type of the callback. In this case it takes no parameters and returns no value, so you can hook into it like this:

     on mySlider valueChanged $ do
        v <- rangeGetValue mySlider

One subtlety about GTK3 signals is that they are often only triggered when the underlying value actually changes, rather than every time the underlying setter function is called. So if the slider is on 10 and you call "rangeSetValue 9" then the callback is triggered in exactly the same way as when the user moves it. However if you call "rangeSetValue 10" then the callback is not triggered. This lets you cross-connect widgets without creating endless loops.

Connecting GUI Inputs

The crucial thing is that GTK signals and attributes are isomorphic with Reactive Banana events and behaviors. So the following code gets you quite a long way:

   registerIOSignal :: (MonadIO m) =>
      object
      -> Signal object (m a)
      -> m (a, b)
      -> MomentIO (Event b)
   registerIOSignal obj sig act = do
      (event, runHandlers)
      liftIO $ obj `on` sig $ do
         (r, v) <- act
         liftIO $ runHandlers v
         return r
      return event

There are a few wrinkles that this has to cope with:

First, a few signal handlers expect the callback to return something other than "()". Hence the "a" type parameter above.

Second, the callback doesn't usually get any arguments, such as the current slider position. Its up to the callback itself to get whatever information it needs. Hence you still need to write some callback code.

Third, some signals work in monads other than just "IO". Usually these are of the form "ReaderT IO" (that is, IO plus some read-only context). The "m" type parameter allows for this.

So now we can get a Reactive Banana event for the slider like this:

   sliderEvent <- registerIOSignal mySlider valueChanged $ do
      v <- rangeGetValue mySlider
      return ((), v)

The two values in the "return" are the return value for the callback (which is just () in this case) and the value we want to send out in the Event.

Some signals do provide parameters directly to the callback, so you need a family of functions like this:

   registerIOSignal1 :: (MonadIO m) =>
      object
      -> Signal object (a -> m b)
      -> (a -> m (b, c))
      -> MomentIO (Event c)
   registerIOSignal2 :: (MonadIO m) =>
      object
      -> Signal object (a -> b -> m c)
      -> (a -> b -> m (c, d))
      -> MomentIO (Event d)

And so on up to registerIOSignal4, which is the longest one I have needed so far.

Connecting Outputs

Outputs are simpler than inputs. Reactive Banana provides a function for linking an event to an IO action:

 reactimate :: Event (IO ()) -> MomentIO ()

This takes an event carrying IO actions and executes those actions as they arrive. The "MomentIO" return value is the monad used for building up networks of events and behaviors: more of that in "Plumbing" below.

Events are functors, so the usual pattern for using reactimate looks like this:

   reportThis :: Event String -> MomentIO ()
   reportThis ev = do
      let ioEvent = fmap putStrLn ev
      reactimate ioEvent

The argument is an event carrying a string. This is converted into an event carrying IO actions using "fmap", and the result is then passed to reactimate. Obviously this can be reduced to a single line but I've split it out here to make things clearer.

So we can link an event to a GTK attribute like this:

   eventLink :: object -> Attr object a -> Event a -> MomentIO ()
   eventLink obj attr =
      reactimate . fmap (\v -> set obj [attr := v])

Whenever the argument event fires the attribute will be updated with the value carried by the event.

Behaviors can be linked in the same way. Reactive Banana provides the "changes" function to get an event whenever a behavior might have changed. However this doesn't quite work the way you would expect. The type is:

   changes :: Behavior a -> MomentIO (Event (Future a))

The "Future" type reflects the fact that a behavior only changes after the event processing has finished. This lets you write code that cross-links events and behaviors without creating endless loops, but it means you have to be careful when accessing the current value of a behavior. More about this in "Plumbing" below.

To cope with these "Future" values there is a special version of "reactimate" called "reactimate' " (note the tick mark). You use it like this:

   behaviorLink :: object -> Attr object a -> Behavior a -> MomentIO ()
   behaviorLink obj attr bhv = do
      fe <- changes bhv
      reactimate' $ fmap (fmap (\v -> set obj [attr := v])) fe

This will update the attribute whenever an event occurs which feeds in to the behavior. Note that this will still happen even if the new value is the same as the old; unlike GTK the Reactive Banana library doesn't cancel updates if the new and old values are the same.

Plumbing

The Basic Concepts

Reactive Banana events and behaviors are connected together in the MomentIO monad. This is an instance of MonadFix so you can use recursive do notation, letting you create feedback loops between behaviors and events. MomentIO is also an instance of MonadIO, so you can use liftIO to bring GTK widget actions into it.

To set up a dialog containing a bunch of GTK widgets you do the following things in the MomentIO monad:

• Use liftIO on GTK functions to set up the widgets and arrange them in layout boxes in the same way you would if you were just using bare GTK.

• Use registerIOSignal to get Reactive Banana events from the widgets.

• Use the Reactive Banana combinators to create new events and behaviors reflecting the application logic you want.

• Use eventLink and behaviorLink to update widget attributes.

 For instance you can have a pop-up dialog containing a bunch of input widgets with events attached to their values. Lets say these fields are arguments to the "FooData" constructor, and you also have a function "fooValid :: FooData -> Bool". You can then write your code like this:

   fooDialog :: FooData -> MomentIO (Widget, Event FooData)
   fooDialog (FooData v1 v2)= do

      -- Create GTK widgets w1, w2 and okButton.
      -- Put them all in a top-level "dialog" container.
      .... your GTK code here.

      -- Connect events ev1, ev2 to the values of w1 and w2.
      .... your calls to registerIOSignal here.
      okClick <- registerIOSignal okButton buttonActivate $ return ((), ())
      bhv1 <- stepper v1 ev1
      bhv2 <- stepper v2 ev2
      let
         fooB = FooData <$> bhv1 <*> bhv2
               -- Behavior is an Applicative, so fooB :: Behavior FooData
         validInput = fooValid <$> fooB
         result = const <$> fooB <@> okClick

      behaviorLink okButton widgetSensitive validInput
      return (dialog, result)

The last line but one links the "validInput" behavior to the OK button sensitivity. So if the input data is not valid then the OK button is greyed out and will not respond to clicks. You can use the same technique do other more informative things like highlighting the offending widget or displaying a helpful  message in another widget.

The "result =" line needs a bit of explanation. The "<@>" combinator in Reactive Banana works like the applicative "<*>" except that its second argument is an event rather than a behavior. The result is an event that combines the current value of the "fooB" behavior with the value from the "okClick" event. In this case the button click carries no information, so we use the function "const" to just take the current behavior value.

One tip: when writing pure functions that are going to be called using the "<@>" combinator its a good idea to put the argument that will come from the event last.

Keeping it Modular

I have found that these are good rules for designing applications in Reactive Banana:

• Functions in the MomentIO monad should take events and behaviors as parameters, but only return events.

• Avoid returning a behavior unless you are sure that this is the only function that needs to change it.

• Keep the behavior definitions at the top of the call stack where they are used. If in doubt, defer the job of defining the behavior to your caller.

This lets you write independent modules that all have a say in updates to some shared value. The shared value should be represented as a Behavior, and updates to it as Events which either carry new values or (better) update functions. So you have a bunch of independent editor functions and a top level function which looks like this:

   editor1, editor2, editor3 ::
    Behavior FooData -> MomentIO (Event (FooData -> FooData))

   fooDataManager :: FooData -> MomentIO ()
   fooDataManager start = mdo    -- Recursive do notation.
      edit1 <- editor1 fooB
      edit2 <- editor2 fooB
      edit3 <- editor3 fooB
      fooB <- accumB start $ unions [edit1, edit2, edit3]
     -- accumB applies each event function to the accumulated behaviour value. 

What duties to software developers owe to users?

I was reading this blog post, entitled "The code I’m still ashamed of". 

TL; DR: back in 2000 the poster, Bill Sourour, was employed to write a web questionnaire aimed at teenage girls that purported to advise the user about their need for a particular drug. In reality unless you said you were allergic to it, the questionnaire always concluded that the user needed the drug. Shortly after, Sourour read about a teenage girl who had possibly committed suicide due to side effects of this drug. He is still troubled by this.

Nothing the poster or his employer did was illegal. It may not even have been unethical, depending on exactly which set of professional ethics you subscribe to. But it seems clear to me that there is something wrong in a program that purports to provide impartial advice while actually trying to trick you into buying medication you don't need. Bill Sourour clearly agrees.

Out in meatspace we have a clearly defined set of rules for this kind of situation. Details vary between countries, but if you consult someone about legal, financial or medical matters then they are generally held to have a "fiduciary duty" to you. The term derives from the Latin for "faithful". If X has a fiduciary duty to Y, then X is bound at all times to act in the best interests of Y. In such a case X is said to be "the fiduciary" while Y is the "beneficiary".

In many cases fiduciary duties arise in clearly defined contexts and have clear bodies of law or other rules associated with them. If you are the director of a company then you have a fiduciary duty to the shareholders, and most jurisdictions have a specific law for that case. But courts can also find fiduciary duties in other circumstances. In English law the general principle is as follows:

"A fiduciary is someone who has undertaken to act for and on behalf of another in a particular matter in circumstances which give rise to a relationship of trust and confidence."

It seems clear to me that this describes precisely the relationship between a software developer and a user. The user is not in a position to create the program they require, so they use one developed by someone else. The program acts as directed by the developer, but on behalf of the user. The user has to trust that the program will do what it promises, and in many cases the program will have access to confidential information which could be disclosed to others against the user's wishes.

These are not theoretical concerns. "Malware" is a very common category of software, defined as:

any software used to disrupt computer or mobile operations, gather sensitive information, gain access to private computer systems, or display unwanted advertising.

Sometimes malware is illicitly introduced by hacking, but in many cases the user is induced to run the malware by promises that it will do something that the user wants. In that case, software that acts against the interests of the user is an abuse of the trust placed in the developer by the user. In particular, the potential for software to "gather sensitive information" and "gain access to private computer systems" clearly shows that the user must have a "relationship of trust and confidence" with the developer, even if they have never met.

One argument against my thesis came up when I posted a question about this to Legal forum on Stack Exchange. The answer I got from Dale M argued that:

Engineers (including software engineers) do not have this [relationship of confidence] and AFAIK a fiduciary duty between an engineer and their client has never been found, even where the work is a one-on-one commission.

I agree that, unlike a software developer, all current examples of a fiduciary duty involve a relationship in which the fiduciary is acting directly. The fiduciary has immediate knowledge of the circumstances of the particular beneficiary, and decides from moment to moment to take actions that may or may not be in the beneficiary's best interest. In contrast a software developer is separated in time from the user, and may have little or no knowledge of the user's situation.

I didn't argue with Dale M because Stack Exchange is for questions and answers, not debates. However I don't think that the distinction drawn by Dale M holds for software. An engineer designing a bridge is not in a position to learn the private information of those who cross the bridge, but a software engineer is often in a position to learn a great deal about the users of their product. It seems to me that this leads inescapably to the conclusion that software engineers do have a relationship of confidence with the user, and that this therefore creates a fiduciary duty.

Of course, as Dale M points out, nobody has ever persuaded a judge that software developers owe a fiduciary duty, and its likely that in practice its going to be a hard sell. But to go back to the example at the top, I think that Bill Sourer, or his employer, did owe a fiduciary duty to those people who ran the questionnaire software he wrote, because they disclosed private information in the expectation of getting honest advice, and the fact that they disclosed it to a program instead of a human makes no difference at all.

Addendum: Scope of duty

This section looks at exactly what the scope of the fiduciary duty is. It doesn't fit within the main text of this essay, so I've put it here.

Fortunately there is no need for a change in the law regarding fiduciary duty. The existence of a fiduciary duty is based on the nature of the relationship between principal and agent, although in some countries specific cases such as company directors are covered by more detailed laws.

First it is necessary to determine exactly who the fiduciary is. So far I have talked about "the software developer", but in practice software is rarely written by a single individual. We have to look at the authority that is directing the effort and deciding what functions will be implemented. If the software is produced by a company then treating the company as the fiduciary would seem to be the best approach, although it might be more appropriate to hold a senior manager liable if they have exceeded their authority.

As for the scope, I'm going to consider the scope of the fiduciary duty imposed on company directors and consider whether an analogous duty should apply to a software developer:

• Duty of care: for directors this is the duty to inform themselves and take due thought before making a decision.  One might argue that a software developer should have a similar duty of care when writing software, but this is already handled through normal negligence. Elevating the application of normal professional skill to a fiduciary duty is not going to make life better for the users. However there is one area where this might be applied: lack of motive to produce secure software is widely recognised as a significant problem, and is also an area where the "confidence" aspect of fiduciary duty overlaps with a duty of care. Therefore developers who negligently fail to consider security aspects of their software should be considered to have failed in their fiduciary duty.
• Duty of loyalty: for directors this is the duty not to use their position to further their private interests. For a software developer this is straightforward: the developer should not use their privileged access to the user's computer to further their private interests. So downloading information from the users computer (unless the user explicitly instructs this to happen) should be a breach of fiduciary duty. So would using the processing power or bandwidth owned by the user for the developers own purposes, for instance by mining bitcoins or sending spam.
• Duty of good faith: the developer should write code that will advance the user's interests and act in accordance with the user's wishes at all times.
• Duty of confidentiality: if the developer is entrusted with user information, for example because the software interfaces with cloud storage, then this should be held as confidential and not disclosed for the developer's benefit.
• Duty of prudence: This does not map onto software development.
• Duty of disclosure: for a director this providing all relevant information to the shareholders. For a software developer, it means completely and honestly documenting what the software does, and particularly drawing attention to any features which a user might reasonably consider against their interests.  Merely putting some general clauses in the license is not sufficient; anything that could reasonably be considered to be contrary to the user's interests should be prominently indicated in a way that enables the user to prevent it.

One gray area in this is software that is provided in exchange for personal data. Many "free" apps are paid for by advertisers who, in addition to the opportunity to advertise to the user, also pay for data about the users. On one hand, this involves the uploading of personal data that the user may not wish to share, but on the other hand it is done as part of an exchange that the user may be happy with. This comes under the duty of disclosure. The software should inform the user that personal data will be uploaded, and should also provide a detailed log of exactly what has been sent. Thus users can make informed decisions about the value of the information they are sending, and possibly alter their behavior when they know it is being monitored.

Letter to my MP about the Investigatory Powers Bill

I've just sent this email to my MP. Hopefully it will make a difference. I've asked for permission to post her reply.

---------------------------

Dear Ms Fernandes,

I am a resident of [redacted]. My address is [redacted]. I am writing to you a second time about the proposed Investigatory Powers Bill. I wrote to you about this on 5th November 2015 urging you to try to mitigate the worst aspects of this bill, and now I am writing to urge you to vote against this bill when it comes to Parliament.

I am deeply concerned about the powers that this bill would give to the Home Secretary. However in order to keep this email reasonably short I will concentrate on one particularly dangerous power.

If this bill becomes law then the Home Secretary would be able to order any "communications company" (the term could mean anyone involved in providing software or equipment that enables communication) to install any surveillance feature the Home Secretary wishes. The recipient of this order would be unable to appeal against it, and would be prevented from revealing the existence of the order. There is no sunset time on this gag clause: it will last as long as the Home Secretary and the security services wish to maintain it.

It is true that these orders will also have to be signed off by a judge, but that will only verify that the order complies with whatever procedures are in place at the time. Furthermore these judges will only ever hear one point of view on the reasonableness and proportionality of the orders, and this can only result in the erosion of these safeguards over time.


I want to illustrate the danger of this power to weaken security by showing how it would impact a common method of selecting encryption keys called Diffie-Hellman Key Exchange. This method is used by web browsers and email programs whenever they make a secure connection (e.g. to web addresses starting "https"). It is also used by "Virtual Private Networks" (VPNs) which are widely used by businesses to allow employees to work remotely, and I expect that Parliament has one to allow MPs to access their email. You may even be using it to read this.

I want to show that any attempt to intercept messages where Diffie-Hellman is used will greatly weaken it, and that this will worsen our security rather than improving it. I will show this by linking the NSA to the compromise of the Office of Personnel Management (OPM) in America last year.

I don't propose to explain the technical details of Diffie-Hellman. What it means is that two computers can exchange a few messages containing large random numbers, and at the end of this they will share a secret key without that key ever having been sent over the Internet.

Suppose that a communications company provides software that uses Diffie-Hellman, and receives an order from the Home Secretary that they must make the encrypted messages available to law enforcement and the intelligence agencies. What are they to do? They never see the secret keys, so they must do one of the following:

1: Modify the software to send a copy of the chosen key to someone. This is far less secure, and also very obvious. Anyone monitoring the packets sent by the programs will instantly see it.

2: Modify the software to make the keys or the encryption weak in a non-obvious way so that the UK intelligence agencies can determine what the key is. For instance, the random numbers might be made more predictable in a subtle way.

These are the only two ways in which the communications company can comply with the order.

We have seen what happens when Option 2 is chosen, because this was done to Juniper Networks firewall product [see ref 1 below]. Someone deliberately inserted "unauthorised code" which weakened the encryption used by this product in a very specific and deliberate way. There is no possibility that this was an accidental bug. The responsible party is widely believed to be the NSA, because secret briefings released by Edward Snowden made reference to the ability to intercept data sent via this product [ref 2], and it would be much easier for the NSA to infiltrate an American company than for anyone else to do it.

However there is something important that happens when software is updated: hackers (including foreign governments) scrutinize the updates to see what has changed. Normally they find that the old version of the software had a security hole which is now patched, so the patch flags up a way to attack computers that haven't been updated yet. But in this case when Juniper issued an update to their firewall software these hackers found the security hole in the *new* software.

Doing this kind of analysis in a systematic way for many security products is a very large job. Doing it in secret requires the resources of a government. So now not only could the NSA intercept communications sent via Juniper firewalls, but so could an unknown number of foreign governments. The Chinese were almost certainly one of them. Other nations known to have invested in  cyber-attack capabilities include the Russia, Israel and North Korea (although the last is probably not as capable yet).

Juniper products are widely used by the US Government. This is likely to have been one of the ways in which the Office of Personnel Management (OPM) was penetrated last year [ref 3]. The Chinese government is the prime suspect in this hack, through which the attackers have obtained copies of the security clearance applications of everyone who has ever worked for the US government.

So it seems that the NSA, by introducing a supposedly secret "back door" into a widely used product, cleared the way for the Chinese to obtain secret files on everyone who has ever worked for their government, including all of their legislators and everyone who works at the NSA. Nice job breaking it, Hero!


Now it is true that this is circumstantial; we have no hard evidence that the Juniper back door was inserted by the NSA, no hard evidence that the Chinese found it, and no hard evidence that this contributed to the OPM hack. But each of these is a big possibility. Even if the OPM hack didn't happen in exactly that way, deliberately weakening security makes events like this much more likely. If the Home Secretary orders a company to introduce weakened security, that fact will become apparent to anyone with the resources to dig for it. Once armed with that fact, they can attack through the same hole.

Furthermore, we would never find out when a disaster like the OPM hack happens under the regime described in the Investigatory Powers bill.  Suppose that, thanks to the weakened security ordered by the Home Secretary, secret government files are obtained by a hostile power, and the communications company executives are called before a Parliamentary Inquiry to account for their negligence; how can they defend themselves if they are legally prohibited from revealing their secret orders?

More generally, we will never be allowed to learn about the negative effects of these secret orders. It would embarrass those who issued them, and they are exactly the people who would have to give permission for publication. So if Parliament passes this bill it will never be allowed to learn about the problems it causes, and hence never be able to remedy the mistake.

I have focused on only one of the measures in the Investigatory Powers bill here, but there are many others in the bill that cause me great concern. To go through the whole bill in this level of detail would make this email far longer, and I know that you have many calls on your time. I can only ask you to believe that there are many similar issues. For these reasons I must urge you to vote against the bill when it reaches the House of Commons.

Yours sincerely,

Paul Johnson.


[1] http://forums.juniper.net/t5/Security-Incident-Response/Important-Announcement-about-ScreenOS/ba-p/285554

[2] https://assets.documentcloud.org/documents/2653542/Juniper-Opportunity-Assessment-03FEB11-Redacted.txt

[3] https://en.wikipedia.org/wiki/Office_of_Personnel_Management_data_breach