With my company we now have fully moved out of Slack and into Rocket.Chat. We’re hosting our own Rocket.Chat instance on a server in an Amsterdam data center.
We had been using Slack since 2016, and used it both for ourselves, and with some network partners we work with. Inviting in (government) clients we never did, because we couldn’t guarantee the location of the data shared. At some point we passed the free tier’s limits, meaning we’d have to upgrade to a paid plan to have access to our full history of messages.
Rocket.chat is an open source alternative that is offered as a service, but also can be self-hosted. We opted for a Rocket.chat specific package with OwnCube. It’s an Austrian company, but our Rocket.chat instance is hosted in the Netherlands.
Slack offers a very well working export function for all your data. Rocket.chat can easily import Slack archives, including user accounts, channels and everything else.
With the move complete, we now have full control over our own data and access to our entire history. The cost of hosting (11.50 / month) is less than Slack would already charge for 2 users when paid annually (12.50 / month). The difference being we have 14 users. That works out as over 85% costs saving. Adding users, such as clients during a project, doesn’t mean higher costs now either, while it will always be a better deal than Slack as long as there’s more than 1 person in the company.
We did keep the name ‘slack’ as the subdomain on which our self-hosted instance resides, to ease the transition somewhat. All of us switched to the Rocket.chat desktop and mobile apps (Elmine from Storymines helping with navigating the installs and activating the accounts for those who wanted some assistance).
The move to Rocket.chat is part of a path to more company-wide information hygiene (e.g. we now make sure all of us use decent password managers with the data hosted on EU servers, and the next step is running our own cloud e.g. for collaborative editing with clients and partners), and more information security.
Just a month ago I wrote here about my reservations concerning the use of mobile phones as hotel room key. A hotel I will be staying at in the near future yesterday started sending me multiple (unasked) SMS’s to download their hotel app to ‘make my stay smarter’. Sure, I will trust download links in unrequested SMS! Today as I’ve ignored their messages I received an e-mail imploring me to do the same.
The app they ask me to use is called Aeroguest, and their pitch to me is about easier check-in/out, using chat to contact staff, and using my phone as door key. The first two I’d rather do in person, and the last one is not a good idea as explained in the above link.
Why such an app might be seen as attractive to the hotel, becomes clear if you look at the specifications of the app. A clear benefit is direct repeat bookings, saving the expensive middle men that booking sites are. In my case I almost always book through the hotel’s website directly. And if I enjoyed my stay I usually book the same hotel in a city for my next visit. I do use booking sites to find hotels. In this case I’ve stayed in this hotel several times before.
The stated benefits for the guest (key, chat, check-in/out, choosing your room) are a small part of the listed benefits for hotels in using the app, such as up-selling you packages before and during your stay. An ominous one, when seen from the guest’s perspective, is ‘third party services’ access presumably meaning potential access to your booking / stay history and maybe even payment / settlement information, requested preferences etc. Another, more alarming one, is “advanced indoor mapping” which I take means tracking of guests through the hotel which can yield information on time spent in hotel facilities, time spent in the room, how often / when the key was used, and by matching it with other guests, whom you might be meeting with that is also staying in the hotel. In Newspeak on the apps website in the data and analytics section this is described as “With transparency, you can proactively accommodate your guests’ needs.” Note that the guest is the one who is being made transparant. That is quite a price in exchange for being able to choose your specific room when checking in with the app.
I’ve replied to the hotel my reasons for not wishing to use the app (linking to my previous blogpost), and told them I look forward to checking in at reception in person when I arrive. When I arrive I am curious to hear more about their usage of the app. For now “making my stay smart” reads like the “smart cities” visions of old, it may be smart, but not for the individuals involved, merely for the service provider.
Hotel keys, photo by Susanne Nilsson, license CC BY-SA
Everybody hates the keycard, says the NYT, and talks about using your phone instead. There are a few reasons why using your phone as a hotel key is not something I do, or would do.
One reason is provided by the hotels promoting this themselves:
“And, since the keys are downloaded electronically through a hotel app, the host has a presence on the guests’ phones, and can offer other exclusive services, like promotions and a chat feature.”
Presence on my phone, that sounds rather ominous. Let me count the hotel apps I currently allow on my phone…. 0.
Unless there’s an opt-in for each single additional ‘service’ as part of a hotel’s ‘presence’ on my phone, it is in breach of the GDPR wherever I travel. Do hotel chains really want to expose up to 4% of their annual turnover to liability risks?
The ones I’ve encountered worked through bluetooth. That opens up a wide range of potential vulnerabilities. I never have bluetooth switched on (nor wifi when not in active use, for that matter), and there are very good reasons for that. There might be other bluetooth devices nearby pretending to be my hotel door to get access to my phone, or piggyback on my room door’s communication. A plastic card and a room door never have that issue. NFC based ones have less of these issues, but still bring their own issues.
A vulnerability in a hotel’s mobile app now also becomes a vulnerability for your hotel key as well as for your phone. It also means a phone will contain data traces of any hotel you may have used it as a key. That is a privacy risk in itself, not only to yourself, but potentially as well to people you have encountered. (E.g. investigative journalists would be risking the anonymity and privacy of their sources that way.)
Another reason is, also when I travel alone I have 2 plastic key cards. I keep them in different places, so I have a back-up if one of them gets out of my hands. Having just my phone is a single point of failure risk. Phones get left in hotel bars. Phones slip out of pockets in taxi back seats. Phone batteries die.
That is the third reason, that phone batteries die, especially on intensive work days abroad. Already that is sometimes problematic for mobile boarding passes for e.g. a second leg of a trip after a long haul flight (such as last month on a trip to Canada), or an evening flight home.
When staying in a hotel, after a long day, I sometimes need to leave a phone to charge in my room (sometimes the room safe has a convenient power outlet), while I go have a coffee in the lobby. This month during holidays I left my phone charging during dinner in a hotel in Rouen, as well as in an apartment on the Normandy coast, while we headed out for a walk on the beach.
So when I read in the article “What is also great is that I don’t find myself forgetting my key in the room as I always have my phone with me“, I take that to mean “you can’t leave your room when your phone needs charging” and “you can’t return to your room if your phone battery died”.
Phones and hotel keys all have their vulnerabilities. Putting a key card on your phone doesn’t remove the existing vulnerabilities of existing key card systems, but transfers and adds them to the vulnerabilities of your phone, while also combining and increasing the potential negative consequences of one of those vulnerabilities becoming actualised.
Yesterday we had our monthly all hands meeting at my company. In these meetings we allocate some time to various things to increase our team’s knowledge and skills. This time we looked at information security, and I gave a little intro to start a more long term discussion and effort to raise information security in our company.
When people discuss information security it’s often along the lines of ‘if you want to do it right I’d have to go full paranoid, and that is completely over the top, so I won’t bother with it at all’. This is akin to saying that because it makes no sense to turn your home into an impenetrable fortress against invaders, you’ll just leave the door standing open. In practice you’ll do something in between those two extremes, and have locks on the door.
Fortress or open door? That’s a false dilemma. (fortress by Ryan Lea, CC-BY, open door by Hartwig HKD, CC-BY-SA and locked door by Robert Montalvo CC-BY)
You know the locks on your door won’t keep out very determined burglars or say a swat team, but it will raise the time and effort needed for less determined invaders to a point they will be discouraged.
At the same time keeping the door closed and locked isn’t just useful to keep out burglars but also serves as a way to keep out the wind, rain and leaves and dust blowing in from the street.
Similarly in information security you won’t keep out determined government three letter agencies, but there too there are basic hygiene measures and a variety of measures to raise the cost of more casual or less determined attacks. Like with preventative measures at home, information security can be viewed in layers on a spectrum.
I tried to tease out those layers, from the most basic to the most intensive:
keeping your files available
basic steps against loss or theft, also on the road
protect client information, and compliance
secure communication and exchanges
preventing danger to others
traveling across borders outside of the Schengen area
active defence against being targeted
active defence against being targeted by state actors
For each of those levels there are multiple dimensions to consider. First of all in recent years a new group of actors interested in your data has clearly emerged. The tech companies for whom adtech is their business model started tracking you as much as they can get away with. This adds the need for measures to all but the most intensive levels, but especially means the basic levels intensify.
Then there’s the difference between individual measures, and what can be arranged at the level of our organisation, and how those two interplay.
Practically each level can be divided first along the lines of our two primary devices, laptop and phone. Second, there’s a distinction between technological measures, and behaviour (operational security).
the list of levels, and the distinction in dimensions as I showed them yesterday
I provided examples of how that plays out on the more basic levels, and on the most intensive level. E.g. on the level of hygiene, technological measures you can think of are firewalls, spam and virus filters, a privacy screen, ad blockers and tracker blockers, using safer browsers. Behavioural measures are not clicking links before checking what they lead to, recognising phishing attempts, not plugging in usb sticks from others, using unique user names and passwords, using different browsers for different tasks, and switching off wifi, bluetooth and gps (on mobile) when you’re not specifically using them.
Over the years working on open data I’ve increasingly become aware of and concerned about information security, and since early 2014 actively engaging with it. I’m more or less at level 7 of the list above, and with the company I think we need to be at level 5 at least, whereas some of us haven’t quite reached level 1 at the moment. From the examples I gave, and showing some of the (simple) things I do, we had a conversation about the most pressing questions and issues each of us has. This we’ll use to sequence steps. We’ll create short faq’s and/or how-to sheets, we’ll suggest tools and behavioral measures, suggest what needs a collective choice, and provide help with adoption / implementation. I feel with this we have a ‘gentle’ approach, that avoids overwhelm that leads to not taking measures at all.
The first things people mentioned because they were worried about it are: usernames/passwords, e-mail, trackers, vpn, and handling copies of ID’s.
So we’ll take those as starting points.
If you want to read up on information security and operational security around your devices, dearly missed Arjen Kamphuis’s book on information security for journalists is a very useful resource. My approach as described is more geared to the actual context of the people involved, and what I know about their habits and routines, and to the context of our work and typical projects.
The quality of information households in local governments is often lacking.
Things like security, openness and privacy are safeguarded by putting separate fences for each around the organisation, but those safeguards lack having detailed insight into data structures and effective corresponding processes. As archiving, security, openness and privacy in a digitised environment are basically inseparable, doing ‘everything by design’ is the only option. The only effective way is doing everything at the level of the data itself. Fences are inefficient, ineffective, and the GDPR due to its obligations will show how the privacy fence fails, forcing organisations to act. Only doing data governance for privacy is senseless, doing it also for openness, security and archiving at the same time is logical. Having good detailed inventories of your data holdings is a useful instrument to start asking the hard questions, and have meaningful conversations. It additionally allows local government to deploy open or shared data as policy instrument, and releasing the inventory itself will help articulate civic demand for data. We’ve done a range of these inventories with local government.
1: High time for mature data governance in local and regional government
Digitisation changes how we look at things like openness, privacy, security and archiving, as it creates new affordances now that the content and its medium have become decoupled. It creates new forms of usage, and new needs to manage those. As a result of that e.g. archivists find they now need to be involved at the very start of digital information processes, whereas earlier their work would basically start when the boxes of papers were delivered to them.
The reality is that local and regional governments have barely begun to fully embrace and leverage the affordances that digitisation provides them with. It shows in how most of them deal with information security, openness and privacy: by building three fences.
Security is mostly interpreted as keeping other people out, so a fence is put between the organisation and the outside world. Inside it nothing much is changed. Similarly a second fence is put in place for determining openness. What is open can reach the outside world, and the fence is there to do the filtering. Finally privacy is also dealt with by a fence, either around the entire organisation or a specific system, keeping unwanted eyes out. All fences are a barrier between outside and in, and within the organisation usually no further measures are taken. All three fences exist separately from each other, as stand alone fixes for their singular purpose.
The first fence: security
In the Netherlands for local governments a ‘baseline information security’ standard applies, and it determines what information should be regarded as business critical. Something is business critical if its downtime will stop public service delivery, or of its lack of quality has immediate negative consequences for decision making (e.g. decisions on benefits impacting citizens). Uptime and downtime are mostly about IT infrastructure, dependencies and service level agreements, and those fit the fence tactic quite well. Quality in the context of security is about ensuring data is tamper free, doing audits, input checks, and knowing sources. That requires a data-centric approach, and it doesn’t fit the fence-around-the-organisation tactic.
The second fence: openness
Openness of local government information is mostly at request, or at best as a process separate from regular operational routines. Yet the stated end game is that everything should be actively open by design, meaning everything that can be made public will be published the moment it is publishable. We also see that open data is becoming infrastructure in some domains. The implementation of the digitisation of the law on public spaces, requires all involved stakeholders to have the same (access to) information. Many public sector bodies, both local ones and central ones like the cadastral office, have concluded that doing that through open data is the most viable way. For both the desired end game and using open data as infrastructure the fence tactic is however very inefficient.
At the same time the data sovereignty of local governments is under threat. They increasingly collaborate in networks or outsource part of their processes. In most contracts there is no attention paid to data, other than in generic terms in the general procurement conditions. We’ve come across a variety of examples where this results 1) in governments not being able to provide data to citizens, even though by law they should be able to 2) governments not being able to access their own data, only resulting graphs and reports, or 3) the slowest partner in a network determining the speed of disclosure. In short, the fence tactic is also ineffective. A more data-centric approach is needed.
The third fence: personal data protection
Mostly privacy is being dealt with by identifying privacy sensitive material (but not what, where and when), and locking it down by putting up the third fence. The new EU privacy regulations GDPR, which will be enforced from May this year, is seen as a source of uncertainty by local governments. It is also responded to in the accustomed way: reinforcing the fence, by making a ‘better’ list of what personal data is used within the organisation but still not paying much attention to processes, nor the shape and form of the personal data.
However in the case of the GDPR, if it indeed will be really enforced, this will not be enough.
GDPR an opportunity for ‘everything by design’
The GDPR confers rights to the people described by data, like the right to review, to portability, and to be forgotten. It also demands compliance is done ‘by design’, and ‘state of the art’. This can only be done by design if you are able to turn the rights of the GDPR into queries on your data, and have (automated) processes in place to deal with requests. It cannot be done with a ‘better’ fence. In the case of the GDPR, the first data related law that takes the affordances of digitisation as a given, the fence tactic is set to fail spectacularly. This makes the GDPR a great opportunity to move to a data focus not just for privacy by design, but to do openness, archiving and information security (in terms of quality) by design at the same time, as they are converging aspects of the same thing and can no longer be meaningfully separated. Detailed knowledge about your data structures then is needed.
Local governments inadvertently admit fence-tactic is failing
Governments already clearly yet indirectly admit that the fences don’t really work as tactic.
Local governments have been loudly complaining for years about the feared costs of compliance, concerning both openness and privacy. Drilling down into those complaints reveals that the feared costs concern the time and effort involved in e.g. dealing with requests. Because there’s only a fence, and usually no processes or detailed knowledge of the data they hold, every request becomes an expedition for answers. If local governments had detailed insight in the data structures, data content, and systems in use, the cost of compliance would be zero or at least indistinguishable from the rest of operations. Dealing with a request would be nothing more than running a query against their systems.
Complaints about compliance costs are essentially an admission that governments do not have their house in order when it comes to data.
The interviews I did with various stakeholders as part of the evaluation of the PSI Directive confirm this: the biggest obstacle stakeholders perceive to being more open and to realising impact with open data is the low quality of information systems and processes. It blocks fully leveraging the affordances digitisation brings.
Towards mature data governance, by making inventory
Changing tactics, doing away with the three fences, and focusing on having detailed knowledge of their data is needed. Combining what now are separate and disconnected activities (information security, openness, archiving and personal data protection), into ‘everything by design’. Basically it means turning all you know about your data into metadata that becomes part of your data. So that it will be easy to see which parts of a specific data set contain what type of person related data, which data fields are public, which subset is business critical, the records that have third party rights attached, or which records need to be deleted after a specific amount of time. Don’t man the fences where every check is always extra work, but let the data be able to tell exactly what is or is(n’t) possible, allowed, meant or needed. Getting there starts with making an inventory of what data a local or regional government currently holds, and describing the data in detailed operational, legal and technological terms.
Mature digital data governance: all aspects about the data are part of the data, allowing all processes and decisions access to all relevant material in determining what’s possible.
2: Ways local government data inventories are useful
Inventories are a key first step in doing away with the ineffective fences and towards mature data governance. Inventories are also useful as an instrument for several other purposes.
Local is where you are, but not the data pro’s
There’s a clear reason why local governments don’t have their house in order when it comes to data.
Most of our lives are local. The streets we live on, the shopping center we frequent, the schools we attend, the spaces we park in, the quality of life in our neighbourhood, the parks we walk our dogs in, the public transport we use for our commutes. All those acts are local.
Local governments have a wide variety of tasks, reflecting the variety of our acts. They hold a corresponding variety of data, connected to all those different tasks. Yet local governments are not data professionals. Unlike singular-task, data heavy national government bodies, like the Cadastre, the Meteo institute or the department for motor vehicles, local governments usually don’t have the capacity or capability. As a result local governments mostly don’t know their own data, and don’t have established effective processes that build on that data knowledge. Inventories are a first step. Inventories point to where contracts, procurement and collaboration leads to loss of needed data sovereignty. Inventories also allow determining what, from a technology perspective, is a smooth transition path to the actively open by design end-game local governments envision.
Open data as a policy instrument
Where local governments want to use the data they have as a way to enable others to act differently or in support of policy goals, they need to know in detail which data they hold and what can be done with it. Using open data as policy instrument means creating new connections between stakeholders around a policy issue, by putting the data into play. To be able to see which data could be published to engage certain stakeholders it takes knowing what you have, what it contains, and in which shape you have it first.
Better articulated citizen demands for data
Making public a list of what you have is also important here, as it invites new demand for your data. It allows people to be aware of what data exists, and contemplate if they have a use case for it. If a data set hasn’t been published yet, its existence is discoverable, so they can request it. It also enables local government to extend the data they publish based on actual demand, not assumed demand or blindly. This increases the likelihood data will be used, and increases the socio-economic impact.
More and more new data is emerging, from sensor networks in public and private spaces. This way new stakeholders and citizens are becoming agents in the public space, where they meet up with local governments. New relationships, and new choices result. For instance the sensor in my garden measuring temperature and humidity is part of the citizen-initiated Measure your city network, but also an element in the local governments climate change adaptation policies. For local governments as regulators, as guardian of public space, as data collector, and as source of transparency, this is a rebalancing of their position. It again takes knowing what data you own and how it relates to and complements what others collect and own. Only then is a local government able to weave a network with those stakeholders that connects data into valuable agency for all involved. (We’ve built a guidance tool, in Dutch, for the role of local government with regard to sensors in public spaces)
Having detailed data inventories are a way to start having the right conversations for local governments on all these points.
3: Getting to inventories
To create useful and detailed inventories, as I and my colleagues did for half a dozen local governments, some elements are key in my view. We looked at structured data collections only, so disregarded the thousands of individual once-off spreadsheets. They are not irrelevant, but obscure the wood for the trees. Then we scored all those data sets on up to 80(!) different facets, concerning policy domain, internal usage, current availability, technical details, legal aspects, and concerns etc. A key element in doing that is not making any assumptions:
don’t assume your list of applications will tell you what data you have. Not all your listed apps will be used, others won’t be on the list, and none of it tells you in detail what data actually is processed in them, just a generic pointer
don’t assume information management knows it all, as shadow information processes will exist outside of their view
don’t assume people know when you ask them how they do their work, as their description and rationalisation of their acts will not match up with reality,
let them also show you
don’t assume people know the details of the data they work with, sit down with them and look at it together
don’t assume what it says on the tin is correct, as you’ll find things that don’t belong there (we’ve e.g. found domestic abuse data in a data set on litter in public spaces)
Doing an inventory well means
diving deeply into which applications are actually used,
talking to every unit in the organisation about their actual work and seeing it being done,
looking closely at data structures and real data content,
looking closely at current metadata and its quality
separately looking at large projects and programs as they tend to have their own information systems,
going through external communications as it may refer to internally held data not listed elsewhere,
looking at (procurement and collaboration) contracts to determine what claims other might have on data,
and then cross-referencing it all, and bringing it together in one giant list, scored on up to 80 facets.
Another essential part, especially to ensure the resulting inventory will be used as an instrument, is from the start ensuring the involvement and buy-in of the various parts of local government that usually are islands (IT, IM, legal, policy departments, archivists, domain experts, data experts). So that the inventory is something used to ask a variety of detailed questions of.
We’ve followed various paths to do inventories, sometimes on our own as external team, sometimes in close cooperation with a client team, sometimes a guide for a client team while their operational colleagues do the actual work. All three yield very useful results but there’s a balance to strike between consistency and accuracy, the amount of feasible buy-in, and the way the hand-over is planned, so that the inventory becomes an instrument in future data-discussions.
What comes out as raw numbers is itself often counter-intuitive to local government. Some 98% of data typically held by Dutch Provinces can be public, although usually some 20% is made public (15% open data, usually geo-data). At local level the numbers are a bit different, as local governments hold much more person related data (concerning social benefits for instance, chronic care, and the persons register). About 67% of local data could be public, but only some 5% usually is. This means there’s still a huge gap between what can be open, and what is actually open. That gap is basically invisible if a local government deploys the three fences, and as a consequence they run on assumptions and overestimate the amount that needs the heaviest protection. The gap becomes visible from looking in-depth at data on all pertinent aspects by doing an inventory.
(Interested in doing an inventory of the data your organisations holds? Do get in touch.)