Posted on
by

A long time ago, in a galaxy not too far away, I took part in a JISC funded research project. The purpose of the project was to investigate and develop solutions for some of the issues associated with securing email.

It was a fun project to be involved with (not least because I got to pretend to be a student again for a little while), and I believe the solution we built – the Secure Email Proxy – was a good one with a lot of potential.

The project finished in 2003, and the website (hosted on an old Sun Pizza box in my lab) has long since vanished, along with the code for the project. I think this is a shame, so I’ve stuck my old development code up on Github. The proxy was under active development since I left the project, but I’ve not go access to the code. If you do, then please feel free to fork and update it.

Anyway, the proxy works by sitting on your local machine between your mail client and your mail server. It manages keys on your behalf, and encrypts/signs/verifies/decrypts messages and attachments on the fly as email passes through it. This means that you don’t need to have any native plugin to work, and it’ll work with virtually any mail client.

Enjoy!

» Visit the project on Github…

Posted on
by

Jurisdiction The other day, in response to Ben’s suggestion, I declared my data jurisdiction, so that those wishing to contact me knew exactly what risks their data could be exposed to.

It occurred to me that simply naming the jurisdiction wasn’t really much good unless I could also point to something that would explain the risks in plain English, so, the other afternoon, I took some time out and put together Data-Jurisdiction.org.

Data-Jurisdiction.org is a community project that anyone can contribute to (either by submitting a patch for, or raising an issue on, the GitHub project) so get hacking! It is my hope that as more people declare their data jurisdiction the site will become a handy source of information.

As a reminder of my jurisdiction; I am based in the UK, with servers in the US and Germany.

Posted on
by

Current-Cost This is just a quick note to spotlight the fact that Home.API now has native support for the Current Cost EnviR smartmeter.

Setting it up

Check out the latest version of Home.API from the Github repository, and then attach the plugin to an endpoint by adding a definition to a .conf file in your def directory. E.g.

# Current cost envir
/power/smartmeter
     class \power\smartmeters\CurrentCostEnviR

This will install the plugin using the default parameters, but you can override these by specifying them in your definition. Available parameters are:

  • port, which defaults to '/dev/ttyUSB0'
  • baud, the baud rate to connect to, defaulting to 57600
  • timeout, defaulting to 10 seconds.

Your Current cost meter should be connected to the same machine as your Home.API install, and the web server user granted access to the comm port the device is connected to.

Exposed API

Once you have enabled the Current Cost plugin, you should see a new entry appear on your Home.API dashboard which gives a quick summary of the information retrieved from the device. It also makes available a number of functions which you can query at your endpoint (http://home.api/api/path/to/endpoint/), and these are:

  • time.json: Retrieve the time from the device.
  • temp.json: Retrieve the temperature from the device.
  • power.json: Retrieve the power in watts from the device.
  • latest.json: Retrieve all of the above at once, and return them as an array.

Visit the endpoint in your browser and see it working!