poobrains devlog #7

Greetings fellow intertube traveller,

While this site hasn't seen many updates in terms of content, poobrains development is still continuing, if at a slower pace.

The biggest news in the department of shit that's been done is that poobrains has been completely ported over to python 3(.6), with support for python 2.7 being dropped.

We also added two performance tweaks, which is caching permission checks per request and the compiled SCSS for SVGs for the whole execution time (except when in debug mode).

But alas, there are a few reasons for the relative slowdown in development, besides our current unfortunate lack of living quarters.

Since the W3C dropped <keygen> from HTML5 (more accurately 5.3), we have thought and re-thought the direction we want poobrains' development to take.

Given that one of the core tenets of poobrains is avoiding any javascript, the death of <keygen> leaves us without any way of doing client certificate provisioning that offers reasonable security, usability and integration.

Poobrains already does offer generating the keypair completely server-side, but this was only ever meant as a fallback, because it means the secret key is known to the server and transmitted over the internet. Still better than passwords, but it doesn't utilize the real strength of public-key cryptography, which is that the server never ever needs to know the clients secret key.

We could just tell users to upload manually generated Certificate Signing Requests, but this would constitute a laughably bad user experience.

We could also create a companion application to automate this step and thus offer acceptable usability but requiring users to install an external application on their devices means broken integration, especially if we want to handle both desktop and mobile devices.

Both of these solutions present poobrains with pretty big hurdles to adoption, especially seeing as its no-js approach already made it a niche project from the outset.

The only logical step, to us, seems to be to fully embrace the niche nature of poobrains and use this opportunity to specialize even further.

As such, we feel that the natural direction for poobrains is that of a tool for small-scale DIY data journalism.

To a degree, this always was the plan, but a lot of features were meant to only be implemented specifically on this site, not in poobrains itself. Some of these features, like scored links and the sourcing model will be ported into poobrains, better integrated and extended.

The data visualization capability already saw some changes due to this decision with the mapping feature being changed to use geoJSON and plotting now being able to not only render data as a line plot, but also as scatterplot or barchart with more to follow.

But before that will be tackled, we will first go for the next big thing, which is actual data analysis using pandas, which – as things stand now - is the last principal hurdle to make poobrains actually qualify as a tool for data journalism (albeit then still a pretty bad one).

One step towards enabling this, that has already been implemented, is the relocation of sessions to the server to accomodate putting large-ish datasets to be analyzed into them. In an effort to lessen the impact of potential compromises, sessions are encrypted with a key stored as a cookie on the client-side, so the server can only access the content of users that are actually connected for a request.

After the initial integration of analysis capabilities, we will in all likelyhood decide on whether and in what scope we want to add automated data acquisition.

This just in: We have boiled brains and are currently unable to come up with a proper closing statement to this. Stay hydrated!