Monday 30 September 2013

Freedom of speech in companies

The concept of freedom of speech has strong ties to the history of distrust of government. Whilst a healthy distrust of government is a good thing, governments aren't the only entities that we should be wary of: our corporations have a lot of power too.

It would be interesting to explore what extent the principles of freedom of speech could be incorporated into companies. Typically companies work much like a tin pot dictatorship: there is much behind closed doors mutterings about leadership and strategy, but public criticism is frequently met with persecution.

A typical response might be: but how can companies remain successful if their leadership is openly criticised from within? The answer to that is: how has the USA been so successful when its leadership is only criticised from within.

The culture of persecution of free speakers within companies has led to a weak corporate culture, and weak corporations. Good leadership can still lead even when many of their flock openly criticise them.

So how might democratic principles be brought into companies? The big challenge is culture - there needs to be a top-down acceptance of democratic principles. Other levers include the employment contracts, which should be encouraged to state more employee rights about freedom of speech, and also through legislation. (In respect of the latter we do already have whistle-blowing legislation, which is a step in the right direction.)

Who's talking to who encryption

The problem: how to ensure that the "who" is just as private as the "what" of communication

The idea:

  • There exists a voluntary network of nodes that all have public key encryption systems, and published public keys.
  • The sender sends a message to the first intermediate node, encrypted with that intermediate node's public key.
  • The first intermediate node decrypts the message, which contains the second intermediate node's address and a payload that's encrypted with the second intermediate node's public key. The first intermediate note sends the payload to the second intermediate node.
  • The second intermediate node decrypts the message, which contains the third intermediate node's address and a payload that's encrypted with the third intermediate node's public key. The second intermediate note sends the payload to the third intermediate node.
  • The third intermediate node decrypts the message, which contains the final recipients node's address and a payload that's encrypted with the final recipients's public key. The third intermediate note sends the payload to the final recipient.
  • The final recipient decrypts the message.


Key points about this system:

  • the sender needs the public keys of all intermediate nodes (a published database would be needed of addresses and public keys)
  • I was originally thinking of this in respect of email, but it should work with any communication, e.g. snail mail, IP packets, etc
  • on a computer it should be fairly easy to automate the multiple layers of encryption
  • the number of intermediate nodes can be manually selected, or selected at random
  • the intermediate nodes themselves should be selected at random
  • the communication could contain multiple next-hop nodes with a priority order, in case nodes fail. The nodes could provide an acknowledgement message back to the node they received communication from
  • the messages could potentially be randomly padded to ensure that the reducing size of the message over time (as address headers are removed) does not give a clue to the communication direction
  • random communication could be added to the network to further confuse snoopers
  • to prove the source of the correspondence to the sender, the sender and recipient would need to pre-agree a secret that the sender would include in the message. Alternatively, the entire system could be set up such that each node gives a secret to each other node encrypted using that node's public key. This would establish encrypted relationships by default, without the need for pre-agreeing, and wouldn't allow anyone to infer relationships from the establishment of the original secret


Challenges

  • as the network scales, the database of addresses and public keys becomes potentially too large
  • if the secret sharing mentioned in the key points is employed, the number of secrets each node would need to hold could get prohibitively large if the network gets large

Questions

  • Does this exist already?
  • Would it work?