A modest proposal: ECI in a box

I described earlier why the existing European Commission campaign is not and won't be a campaigning tool, and a way of provide an out of the box solution that costs a fraction of the existing one.

Signature collection as a Software as a Service (SaaS)

Our goal is to put in place an infrastructure to collect signatures online in a secure, cheap and campaign friendly. This should be open to all ECI that are members.

To be trustable, the software must be open-source so everyone can examine and evaluate it. It must be developed and aimed primarily for an open source infrastructure (operating system linux, database msql or postgress, webserver nginx or apache...).

The software has obviously to satisfy all the legal requirements but to be successful, it has to focus on the goal of the campaign first and be done for and by campaigners.

From a technical point of few, the task at hand (recording a few 1000th new signatures per day) is not complicated, and even considering that they will be peaks of usage, it would be easy to share a server and have dozens of ECI on it.

The rest of this document describes what is needed in this new software and infrastructure to make easier and cheaper to start ECIs.

Most of the quotes come from the non legislative act “laying down technical specifications for online collection systems pursuant to Regulation (EU) No 211/2011 of the European Parliament and of the Council on the citizens’ initiative ” or Directive 95/46/EC as published by the European commission.

Streamline the certification process

Implementation by the organisers of the technical spec­ ifications should guarantee certification of the online collection systems by the Member States’ authorities, and contribute to ensure the implementation of the appropriate technical and organisational measures required to comply with the obligations imposed by Directive 95/46/EC of the European Parliament and of the Council“

The certification process requires a risk analysis covering not only the software, but the hardware, hosting environment, business processes and staff. This is a very expensive to produce document and very expensive and time consuming for the member states to validate too. But assuming the same hosting environment, it would need to be written only once, provided each ECI organiser follow the same ”business processes”.

We have the risk analysis done and approved by a member state (Germany). Most of the risk analysis for the European Commission software could be re-used too. For this project, we need to work closely with one of the member state, that would want to certify rapidly a new ECI that uses the same infrastructure and processes as defined by our “ECI in a box”.

If you are or know a person in charge of the certification in one of the member state, please contact us to see how to make it faster and more efficient to certify, both for the member state and the campaign.

Work hand in hand with the campaign site

For a successful campaign, an online collection system can't be isolated from the campaigning website. It should by default being able to integrate with social media, newsletters and CRM of the campaign website as much as possible given the existing regulations. The split between the two sites and mostly something the citizen signing shouldn't be concerned about.

the data provided online are securely collected and stored, in order to ensure, inter alia, that they may not be modified or used for any purpose other than their indicated support of the given citizens’ initiative and to protect personal data against accidental or unlawful destruction or accidental loss, alteration or unauthorized disclosure or access;”

The European Commission has interpreted this data as being the personal data about the citizen. So the name or passport number are stored encrypted, but the country isn't.

Unfortunately the easiest way to make something secure is to isolate it and this one is one of the main reasons the software provided by the EC isn't appropriate for a successful campaign: they interpreted it as “it must be no communication whatsoever between the online collection and the campaign website”

It is our understanding that the regulation only require that the data for the signature itself can't be reused and personal data unauthorized disclosure prevented, but doesn't stop to ask extra data to be used by the campaigners.

We are going to add two fields in the form on the top of the required onces:

  • a simple checkbox “would you like to be informed of the progress of the campaign and when it has succeeded?”
  • an email field (not mandatory)

The signature itself is still securely collected and stored, but this extra email is transmitted back to the external contact database/newsletter on the campaign website (if the person signing wants it) and be used to inform her about the progress of the campaign.

the OCS forms must be aligned with Annex III to Regulation EU 211/2011 and should at least include all the fields as required by each member state.

However, nothing prevents us to ask for extra information like the email (provided it isn't mandatory), especially if it helps preventing automated submissions.

If adding a field was illegal, then why would the captcha field (where you need to type in the text in the image next to it) be legal? This isn't part of the Annex III.

Prevent automated submission

In order to prevent automated submission of a statement of support using the system, the signatory goes through an adequate verification process in line with current practice before submission of a statement of support. One possible verification process is the use of strong ‘captcha’.

To evaluate the best options to prevent automated submissions, one has to study first the existing solutions to circonvolute these protections.

Captcha (the twisted word you are required to retype) is the most visible way of protecting a form. if the website is willing to take the risk of rejecting real humans, it can be make complicated enough so it won't be deciphered automatically by a computer (this is probably not going to last, some researchers have already been able to implement solutions that are better than human to read captcha). However, the “bad people” found an easier and cheaper solution to workaround this protection: hire cheap labor to solve the captcha manually for a few cents.

At the beginning, they used existing websites like mechanical turk by amazon, that let you upload a list of small tasks (tell me if this picture is a male of female, find the address of the company...) and distribute them to a large number of workers, often in developing countries that are willing to take one or several of these tasks and get paid a small amount for them. They started to upload tasks “fill this form and retype the captcha”. When this illegal usage became more common on mechanical turk, amazon became better at stopping them. However you can know find the same type of services in more “underground” places, where they don't care if it's legal or not.

So in theory and provided you can get a list of name+address (plenty of commercial companies sell them, probably yours if you ever signed to any fidelity program) and upload them to such a service and for a few cent per “signature”, you can hire a small army in Philippine, India or anywhere in the world willing to fill the form on the online collection of the ECI and decipher the captcha.

This is obviously illegal and I'm suggesting anyone to do it, but that would be rather trivial to put in place and impossible to detect as the software from the EC doesn't track the IP address of the visitor that filled the form.

So beside being terribly intrusive for honest citizen, we have a solution that doesn't do efficiently what it's supposed to.

We are going to take a different and more effective approach:

  • get rid of the spambot. The biggest problem solved by captcha is not to protect your site against targeted approach, but against software that try to fill every form they can find on the internet to put links to their site selling viagra or fake luxury products (it increases their visibility in the search engines). They are simple solutions (honeypots) that rely on simple differences between how a “usual” spambot and a normal visitor view the form (using a mix of css and javascript so the bot it tricked into filling fields that an normal human wouldn't). This will block 95% of the automatic signatures without disturbing honest citizen
  • Datamining in real time. We need to collect and store more technical information (eg. IP address of the visitor) and analyse the data in real time and counteract. If a single address in Bangladesh has filled 3 signatures in the past 5 minutes, it should be considered suspect. In general, a different usage pattern (higher number of visitors from a single place, higher number of people that don't abandon the signatures process when they see they need to provide a passport number, IP addresses from outside of europe....) will trigger an alert and acted upon accordingly
  • Proportional counter-mesure: Each suspect behavior is not necessarily a fraud, but an indication it could be. We have an arsenal of measure to make it harder to sign and validate more and more the signature is valid. For instance, we could start by slowing down the page (bots want to sign as much as possible, so tend to leave slow sites), display a second page that ask to confirm, make the email mandatory and send an email containing a link that needs to be clicked to validate, add a captcha to a more radical banning the IP address.

This is the same approach taken by the police force, they have a variety of response between their mere presence, pepper spray, water cannon to lethal weapons. They will not start by shooting; we shouldn't start with a captcha. One size doesn't fit all and you can't limit the counter mesure to a single tool.

As an interesting benefit of having several ECIs sharing the same tool and platform, it makes it easier to compare the signature patterns between campaigns to help identifying what's normal or what isn't. It would for instance allow to see if the same person is signing several ECIs at the same time.

Online signature/identity

This is a complex problem that doesn't have a simple solution available and massively deployed.

For the ECI, each member state has defined what they require to validate the signature and the software complies. We will focus on these as what is needed to validate that a real citizen has signed. However, everyone is probably aware that requiring personal data is either too easy to find through other means (as the growing problem of identity being stolen illustrates) increases the “value” of such a database of signatures, and therefore its risk and makes it harder to sign (the citizen might not have the required form of ID when she wants to sign).

The rest of this paragraph describes various projects and methods to have online signature. They won't be implemented in this version of the software, but are provided as interesting to examine as a way of improving the regulation when it will be evaluated in a few years) several initiatives in various countries:

  • in Finland (eg avoin ministerio.fi) it is possible to identify yourself by using your bank and bank account. To validate yourself, you need to use the same authentication method as you use for your bank – a list of single usage pin codes.
  • in Estonia, the ID card is a smart card and you can use a smartcard reader on your computer to authenticate
  • in Brasil, they plan to use public social networks, you will be “identified” by the people that know you.
  • in almost all the online shops, the credit card is used as a proxy to confirm your ID
  • in most of the public wifi (eg. Airport), they are sending an sms to your gsm and “identify” you through your mobile.
  • In the Open source world, we use GPG (a crypto system used mostly for emails) to confirm the authenticity of a software (eg. Linus Torvald signs each version of the linux kernel that you can verify against his public key).

None of these external proof of ID should be mandatory (I must be able to sign without having a credit card or bank account). However, It is quite interesting as an approach to rely of external services, even some provided by private companies.

I would personally like to see the member states stepping up and providing services (API) to offer realtime validation service for the ECI organisers, but another alternative would use existing solutions for securing emails, like GPG.

To need to communicate securely by email, you need to use your (private) key and the recipient public key, and the recipient needs to know your public key. If you want to contact John Doe and have his key and vice-versa, this works well and no matter who can read the email in between, it won't be able to alter or decrypt it. However, If you want to contact Jane Roe for the first time, you need her key, and you need to be sure that's really hers. The solution is to use a web of trust: if I know John Doe and I trust his key and he knows Jane and trust her key. I can automatically trust her key too.

If we can get a critical mass of users of these technologies, we could have a big enough network to know someone that knows someone that knows the signataire public key, and uses that as a way to confirm the validity of the signature.

As an aside, I would love to see direct democracy at the European level being the vector to massively deploy electronic signatures/encryption that could be used for plenty of other usages.

The next few points are going to be more technical and would need broader exposure and peer review.

Embedding the form in the campaign website

Albeit the signature is stored on a secure place, the signature form should be easy to embed into the campaign website (or even several campaign websites, if they are national/local ones). These websites are not going to be audited for security, and are potentially insecure and should be considered as such from the online collection signature.

How to ask securely something from a website that is potentially not secure is a problem that exists in another domain and have been addressed for decades now: the credit card data.

This is essentially the same technical problem as our online signature: how to let the e-shop ask for the visa card, even so it might not be secure?

They have been several solutions. The most common is to have a secure server from a trusted third party (payment provider or bank) that only collects credit card data and payment requests.

It works in conjunction with the shop, that provides the basket and checkout and then redirect the payment to the bank or payment provider site to enter the credit card informations and get redirected to the shop. This solution is as secure as the payment provider is. The merchant doesn't see nor store any payment information. If just get the less sensitive data (delivery address...) and an information from the payment provider if the payment has been approved or rejected.

The usability problem is that the order form is then a wizard of several steps (enter the name and address, get redirected to the payment page on the secure site, return for a thank you/error on the shop). To make it more user friendly yet without compromising security, several technical solutions have been put in place.

In my opinion the most interesting one is done by stripe.com: their solution is that the shop can have the form with all the fields, including the credit card information, but that the more sensitive information are never sent not stored on the shop servers (technical: the fields have no name). To make it work, the form needs to include from stripe.com a javascript program that takes the sensitive data, retrieve them securely (ajax call) and make a “token” with them that allows the shop to finish the transaction without ever knowing any sensitive data. it means that the server hosting the shop will never see these information even so they are in the order form, and the user will never see the secure site from stripe, even so it will directly communicate with it and the communication between the user and the secure server is done in a secure way.

We will use the same model: The (insecure) campaign website can contain the signature form and style it exactly the way the campaign wants and includes a javascript program coming from our secure online connection site.

When the citizen sign, the highly sensitive data (name, passport number...) are sent directly to our secure website, while the less sensitive ones (eg the email) are sent to the campaign.

Embedding the results (counter) in the campaign website

Is is important to make easy to embed a counter (or visual representation like a thermometer) into the campaigning website, or into any partner website. The total should be either the european total or the total of a specific country

Securing access to the back office and signatures

A real campaigning software must have different users and different access rights and will implement it out of the box (eg people that can only see an overview of the result or people that can retrieve the list of signatures). This again sounds obvious, but unfortunately has been implemented by the EC with a single user.

the storage of the signatures

This needs a peer review by an as wide as possible number of people in the open source and crypto community.

Albeit the regulation focuses on getting and storing the signatures in a secured way, a more complete security model should be taken into account, and security should as well address how to transmit the signatures in a secure way to the member states.

The simplest part if to store the data in an encrypted way. One option might be to host the database on an encrypted volume (but means that each reboot needs a manual intervention and that the data can be read when the system is normally running). This should be a solution that comply with the regulation.

As for the needs, we aim at setting a higher standard than the legal requirement:

  • The system should make possible that the data is sent encrypted to the member states and provide them the key to decrypt them separately (or use their existing keys)
  • One member state shouldn't be able to decrypt data from another member state.
  • The campaigners should NOT be able to decrypt the signatures, unless highly special cases

A solution might be to have a master key for the organiser that can be split between several members of the committee, and one key for each of the 27 member state (either provided by us or by the member state).

Everytime there is a signature (or list of signatures) that needs to be encrypted for download/transfer, this content is encrypted for both the master key and the key of the member state. It is like if you are sending an encrypted message to “master@my.eci and france@my.eci for a french signature. Only master and france can decrypt it.

The private key of each country should either not be known by the organisers (if the member state provided the key) or transmitted securely (and not a the same time as the signatures) to each state.


A key tool for a successful campaign is a proper dashboard. We are going to provide a dashboard so the campaign organisers can see how the number of signatures evolve, see if there is an abnormal change -eg the number of new signatures drops significantly in the UK or if there is a new website sending new supporters.

Data-mining and anti-spam/fraud

The signature will contain the IP address and referer. We expect the software and data-mining to evolve during the campaign, based on real attacks. We are implementing a geomapping of the IP addresses, so we can know that the person signing is using a computer in a country within the EU or elsewhere. One key metric will be how many signatures come from a same IP address, another if the signatures from an IP in one country (eg from a computer in germany) are for citizen of that country.

We should have mostly single or two (a couple) signatures from a single IP address. We are going to see some exception (people in a meeting sharing a network, a single IP address from a big organisation...). These should mostly be during offices hours.

More unusual patterns (eg. Multiple signatures from IP addresses outside of europe) will trigger specific mesures, eg. Requesting the signataire to fill a captcha or banning signatures for a set amount of time).

Intergration with CiviCRM

This is the most often use CRM by NGOs and civil society. This will be hosted on a separate server and will be used as an option by ECI and example of integration with campaigners CRM.

CiviCRM will handle organising events in the real world (to collect signatures) and newsletter sending.

On the water ECI, it is as well used to manage supporting organisations and "ambassadors", VIP publicly supporting the campaign and to manage some projects (preparation of specific actions)

Structure and funding

We have talked about our project with various NGOs interested in launching an ECI. They love the idea, but would prefer to have this ECI in a box service offered and supported by another NGO rather than a commercial company.

We discussed having each of the 7 members of the committee paying a membership to this organisation, and allowing their ECI to get hosted and an amount of 100 euros per member for the duration fo the campaign seemed realistic.

This might cover the hosting cost (and certification process) when they is a significant number of ECIs running on this service, but won't cover the development cost.

The European Commission has budgeted 500'000 euros for the first year to deliver what they did.

By re-using other open source projects and learning from this failure, we are going to be able to deliver the above described software for a 10th of the price.

Post your comment

Anti-spam image(This is to avoid automated comments used to spam)

"Changing the world, one byte at a time."