Dear Mr. Cédric O

Ce billet est également disponible en Français

Dear Mr. Cédric O

Small aside for my regular readers: Cédric O is in charge of digital matters in the French government. Of France. No, I am not reducing his name to its initial, this is indeed his name. So while I’ve got your attention, allow me to state that when requested to add name validation that mandates a minimum number of characters, the only ethical solution for a software developer is to refuse to implement that. Back to the matter at hand.

First, thank you for your recent public pronouncements (of which iMore provides good English-language coverage, in my opinion), which allow me to give a theme to this post I intended to write down: that of the open letter.

Indeed, I want to react to the direction you want to steer the StopCovid project towards, which is that of direct standoff with Apple. Now I will readily admit to a bias in favor of Apple, as the coverage of this blog shows: a lot of it centers on Apple technologies, with a focus on iOS. But I hope to convince you anyway that entering a public standoff with Apple would be futile, even if you’d wished for Apple to be pilloried.

Why

It was basically an excellent idea to start and develop the StopCovid project, don’t get me wrong, but I think it’s useful to go over exactly why. Indeed, some observers (some of which I have a lot of respect for, such as Bruce Schneier) have dismissed this kind of computer-based contact tracing infrastructure as being tech solutionism, and these accusations deserve closer scrutiny. I don’t feel the need to go over the principle and usefulness of contact tracing, not only to warn those a newly diagnosed individual could have infected without his knowledge, but also to attempt to figure out the individual who himself infected the newly diagnosed one, if not known already, and thereby potentially walk back the contamination chain.

However, I do feel it is useful to restate the main use case, which is containment of reemerging outbreaks, be it upon the easing of lockdown or imported from endemic areas. As a result, we can assume being a context of a breach that needs repair, and therefore (as an example) means that see little use in the observation phase, such as tests on asymptomatic people, can suddenly be deployed on a large scale as soon as a confirmed case is raised. One of the aims of the lockdown (along with easing the pressure on hospital care) is precisely to get back to a situation where repairing the breaches is feasible anew, as opposed to a situation where there are more breaches than digits available to plug them.

But as we saw when looking for the index case in the Oise (where I’m told it is still being searched for; more than two months after the fact, the expected benefit seems rather thin in my opinion), current techniques appear to be outmatched in the case of Covid-19. And research coming from Oxford university confirms that assessment, as it suggests the inferred epidemiological characteristics of Covid-19 squash any hope of efficient contact tracing by traditional techniques, validating the need for an automated contact recording solution within a more general effort.

That qualification is useful to make, as no application will be a panacea, but rather a link in a chain where all elements must be present. Such as widely available testing (as France appears to be ready to provide as May begins) that also has quick turnover: if the swab result does not come back until three days later, we reach the contacts, and the tests of those don’t come back until three days after that, it is obvious that even if the application allowed for instant contact tracing, the disease would nevertheless outpace us. As a result, the buildup of a waiting list for testing must be avoided at any cost (PCR itself taking only a few hours), and we must ensure the swabs can be quickly taken to PCR spots. And no application can ever replace actual tracing squads, if only in order to trace contacts not covered, those where one of the two is not equipped with a compatible mobile phone, or any mobile phone at all, for instance. That is why it makes sense to display tracing capabilities at the départemental scale, rather than at the regional scale.

How: the physical layer

All that having been said, we can now start going over the different methods for automatically establishing a contact has occurred. Geolocation can be dismissed outright: it is simultaneously not accurate enough for the need: as GPS is not available everywhere or instantly, smartphones often fall back to cell tower or Wifi hotspot geolocation, and too invasive, for obvious reasons. Bluetooth, on the other hand, is designed to allow direct transmission between digital devices, including peripherals, and its low energy variant has even been designed to support very constrained environments such as being integrated in a key fob, thus enabling it to be found by proximity detection. This notion of proximity is essential: for determining potential contamination, we don’t so much want to compute an exact distance as to reduce testing to a list of potential contacts, erring on the side of caution, rather than having to test everyone in a 100 miles radius in case of a confirmed case.

How: Data processing

OK, so we will retrospectively determine a contact by the fact the mobile phones of the parties in question have been able to exchange (or “exchange strongly enough” by measure of signal intensity among other means) data through Bluetooth. But how should this data be kept (and which data), and where should that computation be performed when the time comes?

Any mobile phone already broadcasts Bluetooth messages to any interested party for various reasons (that is what allows them to appear in the list of reachable devices on the selection interface of a personal computer, for instance). So a first idea would be to set up passive listening of broadcast Bluetooth messages and locally store the Bluetooth identifier of the emitter. But that quickly runs into some issues: for privacy reasons, as it happens, that identifier rotates at regular intervals for implementations of recent versions of the standard, such that being forgotten by is own emitter, it becomes useless; furthermore, many mobile phones will throttle if not stop broadcasting when they are not in active use so as to save battery life, which has never ceased to be an important design constraint on mobile phone design.

So it seems necessary to install a change of behavior on both sides of the contact, which shifts the problem space: now both sides have to be modified for even either side to benefit from the system. As a result, it’s kind of like masks: if the source of the contamination did not previously install the application, the contaminated will get no benefit from having installed the application, so a reaching a sufficient density of participants is paramount. That could lead to consider providing smart watches (which are harder to forget at home) to those who, as is their right, do not own a compatible mobile phone.

Now that we can freely design the software on both sides of the interaction, the design space is greatly expanded, too much to explore it here. However, one significant choice is that of the processing which determines whether a contact previously occurred with a newly diagnosed individual, processing which therefore needs access to any necessary information for that purpose: should it occur on the mobile phone (either one: the two now being “hermaphroditic”, what one can determine, symmetrically the other will be able to, as well), or on a central server?

In the second case, since the aim is to warn the bearer of the phone involved in the contact, that would by all appearances entail that the server has the means to contact any user of the system (directly or indirectly: if every user must regularly query the server by asking “I am the user with pseudonym x, is there anything new for me? Send the answer to IP address 192.0.2.42”, that is equivalent to being reachable).

In the first case, however, it is impossible to prevent the user from figuring out on which occasion he has been in contact with a newly diagnosed person (though still coming short of directly informing of his identity): even if the processing which determines contact were a difficult to reverse cryptographic function, it would suffice for him to run that function on subsets of his contact database, through dichotomy if need be, until the single event sufficient to make the function return a positive is found.

The Apple and Google system

That having been established, let us look at the choices made by Apple and Google, as well as the API provided, over which an application will be able to be built.

To begin with, “Exposure Notification” is a service as far as Bluetooth Low Energy is concerned, that is to say a protocol relying on BLE for over the air data exchange, as HTTP is a protocol relying on TCP for over the Internet (usually) data transmission. It is documented here as I type this; as such, the consortium managing Bluetooth has provided a protocol identifier specifically for its use. The format as it appears on the wire (so to speak) is simple: beyond the mandatory Bluetooth framing, it’s mostly the rotating proximity identifier, but it comes with a metadata field, whose only purpose so far (beyond versioning the protocol, allowing to confirm implementation compatibility) is the improve signal intensity loss computations.

As the name suggests, the rotating proximity identifier rotates at more or less regularly: more or less because if rotation was too regular, that would make it easier to trace people, and render these changes useless: rotation occurs at most every ten minutes, and at most every 20 minutes. All this is properly detailed in the crypto document, which describes how data sent by the protocol mentioned above is generated, how data sent and received is stored, and in particular how to determine a potentially contaminating contact has occurred.

The most important property of the “Exposure Notification” system is that this determination is performed locally. The system assumes the presence of at least one server, but the latter only broadcasts non-nominative data collected (with permission) from diagnosed individuals so as to enable the recipient to make this determination: nothing is uploaded for users that have not been positively diagnosed yet. Even the data that does get uploaded reveals little, to the extent that it amounts to revealing the randomly generated data that was used for sending the rotating proximity identifiers, without any personal data, least of all identifying data, being involved.

The system credibly claims other properties: for instance, it would appear to preclude the collection of information emitted by others, only to later make that be broadcast by passing it off as one’s own information (innocents won’t be the only people positively diagnosed with Covid-19, you have to assume adversaries will too, and as a result minimize their nuisance potential).

That being said, the system does not ensure by itself that only positively diagnosed individuals will be able to upload their alleged contamination information: I have a hard time seeing how it could provide any control in this area, therefore it relies on the health authorities for such a filter.

That is apparent in the third and last document, which describes the API an application (here for an Apple device running iOS) will have to use for interfacing with the service. The API manages in the background everything in relation with the Bluetooth service and data storage, but does not involve itself with network interactions, which is the responsibility of the application proper: parts of the API consists of explicitly taking this data, or providing data to be sent; this is more explicit in the API documentation for a Google device running Android, which otherwise describes the same API, apart from the use of the Java language, as required by Android.

Aside from that, the API in general is unsurprising: it is modern Objective-C, with blocks used for callbacks when data processing is complete for example. It seems to provide good coverage for the future applications usage scenarios: an ENManager class for interaction with the system as a whole such as displaying the current status (allowed or not, mostly) and recover data to be uploaded in case of a positive test result, and a ENExposureDetectionSession to be used when checking whether the latest batch of uploaded data would not trigger an exposure when combined with the internally stored data. The only surprise being Objective-C: we would have expected Swift instead, given how trendy the language is for Apple, but that does not affect the interface functionally, it is even likely that it can directly be used from Swift.

The API reveals one final intriguing functionality, which is the possibility to declare your risk level to the system as soon as any contamination is suspected, before even a formal positive test result, so as to recursively warn contacts; with a lower intensity, of course. That will nevertheless have to go through the health authorities, so it remains to see what they will use this for.

The Apple and Google system: the unsaid

As we see, while the documentation mentions the role played by the server, it remains silent as to how many there will be, how it or they will be managed, and by whom. Multiplying the servers would be unfortunate to the extent it would force the installation of as many apps as there would be applicable servers in order to be properly covered (as much to receive the information broadcast by each server, as to be able to send to each of these servers should it become necessary); that could be acceptable (though we would rather do without) in specific cases, such as that of commuters who cross a border, it is however completely unacceptable for the average user.

Both companies intend to severely restrict access to this API: quoting from their commen document gathering answers to frequently asked questions:

10.How will apps get approval to use this system?

Apps will receive approval based on a specific set of criteria designed to ensure they are only administered in conjunction with public health authorities, meet our privacy requirements, and protect user data.

The criteria are detailed separately in agreements that developers enter into to use the API, and are organized around the principles of functionality and user privacy. There will be restrictions on the data that apps can collect when using the API, including not being able to request access to location services, and restrictions on how data can be used.

Apple in particular has the means to enforce these restrictions: an application in general not only cannot be distributed (beyond a handful of copies) without their permission, but it is certain that a sandbox entitlement (the sandbox being the environment in which an iOS app runs, restricting their access to the operating system to the necessary services with some exceptions, only recognized with a signed waiver from Apple) will be necessary, with very few entities being able to claim such an entitlement (state actors, mostly); sorry for those who would like to play with it: com.apple.developer.exposure-notification will be the most restrictive entitlement ever available for the iPhone… It is a sure bet that Apple will not hesitate to invalidate an entitlement that would have leaked or become abused.

Given the arbitrator position at least Apple holds, I therefore wonder about the lack of any rule or even recommendation on the multiplication of servers. I can conceive that neither Apple nor Google want to expose themselves even more to charges that they are holding themselves as above states, but a confirmation that one server at most would be allowed per country (defined as an entity with diplomatic representations or equivalent) would be desirable, while still allowing each country to have multiple apps if needed, as long as they are all based on the national server. I of course hope that the EU will set up a common server that all member states will adopt, and ideally you would only need one per continent, but it would seem difficult designate for each continent the political entity that would be able to be put in charge of that (as for having a single global server, if that were viable politically as well as technically, Apple and Google would already have handled that).

Additionally, the documentation mentions a second phase where the system will be able to be activated out of the box through the operating system without requiring any app to be installed, with the suggestion to install one appearing once the system has determined a potentially contaminating contact; but if the system can determine that out of the box, that implies the ability to recover data from a server without any previously installed app, so which one is used?

And for that matter, there is no guidance on the role of health authorities to ensure the reliability of data that their servers would broadcast. I recall an incident that was reported to me while working in the telecommunication industry: wireless networks used by police, firefighters, EMT, etc. provide a “distress call” functionality these customers take seriously, you can understand why. In practice, it is a voice call, but flagged so as to trigger some specific processing (in relation to priority, in particular) and raises alarms at many levels. And when initially interconnected with the system covering a neighboring district, it did not go over exactly as planned. Indeed, even though the interconnection protocol did specify how to transmit the distress status of the call, it left a lot of leeway in how to react to such a status; and as it happens, at least one of the systems would consider that distress status to matter so much as to make it sticky for the channel in question, up until explicitly cleared by a supervisor. Which by itself can make sense, but in the case where the channel would belong to the other interconnected system, that one having a different configuration would as a result never send such a confirmation, such that the channel would perpetually be considered in distress after that, even for ordinary calls. Pretty quickly, all channels in this situation ended up flagged as in distress without any way to clear them, and when all calls are distress calls, well none are any more. They had to be supplied an emergency patch.

So it would appear risky to invest resources (engineering, quality assurance, etc.) setting up a system without derisking the possibility that it be for naught if it ends up giving back too many false positives to remain usable. I can’t imagine doing without rules to ensure the reliability of information broadcast by the server or servers.

Finally, still in the geographical matter a risk (raised by Moxie Marlinspike) exists where the database to download could become too heavy (in particular in case the epidemic flares back up) to be practical to download, such that it would become necessary to partition it according to location… thus reintroducing geolocation for this purpose, ruining part of the assurances offered. Similarly to server multiplication, I think this is a matter for which Apple and Google should state their intentions.

The standoff

StopCovid, as with many other projects, was started before the Apple/Google initiative was made public; the project has followed different principles, a process which I respect; the protocol, called ROBERT, is documented. The choice was notably made of an architecture where contamination determination is centralized, with the benefits and drawbacks this entails, I won’t go over them again.

As for the matter of server multiplication, we could question already the necessity of protocol multiplication: will the average user need to install one application for each protocol? But that is not where the issue currently lies: since the ROBERT protocol relies on Bluetooth as expected, its implementation on iPhone meets well-established restrictions by Apple on the ability to use Bluetooth by an app which is not in active usage; these restrictions are documented by Apple, even if in vague terms; I have no doubt the project was able to assess them first hand. They aim at preserving battery life and protecting privacy. They drastically reduce the viability of the solution.

Technologically, it was important to try, if only in order to be credible and not depend on a partner that would have been chosen out of a lack of any alternative. The StopCovid project, notably through its experiments on (approximate) distance measurement using Bluetooth, has already accomplished advances which will be more generally useful, and as a project it could go forward within the framework of a more general protocol, with it adopting another protocol not being synonymous with the end of the project.

Because let’s be clear: I can hear media mention systems that could be “made compatible”, but the only way I know of to make two systems communicate is to have them implement the same protocol. It can consist of two different implementations, but they must be of the same protocol.

For when confronted with these longstanding restrictions, you have chosen the path of the standoff with Apple: you express surprise that Apple would not lift these restrictions on demand, and you insist that the project be delivered in production according to its current principles, invoking a matter of technological sovereignty.

Such a standoff is futile and even harmful, and for at least two reasons.

Futile for now

Beyond these restrictions, Apple has more generally asserted the principle that they control the software that can be distributed on the mobile devices showing their brand. As time went on this control sat less and less well with me, such that I have looked for alternatives, in particular through the web, to be able to distribute my personal projects. This is becoming viable for some applications, such as file processing, but when it comes to Bluetooth there is no alternative to the “native” SDK.

So even if I personally object to some of Apple policies, do you seriously believe that after 12 years of dictating their conditions as they saw fit for iPhone software, witout exception, except those they defined themselves (there are a few more, less well documented), you were going to be able to just walk in and convince them or force their hand just like that? That is delusional.

It is all the more delusional as in other situations where they were largely more exposed (I am referring in particular to a decryption request from the FBI), Apple did not cave in to pressure, and they were proud of it and they still are. That is a matter among others of professional pride, as much in relation to the preservation of battery life as it is of privacy protection. Do you really think big words will be enough to make them change their minds?

If at least you were to invoke some argumentation, such as on the potential advantages for privacy of a centralized solution like ROBERT when compared to their solution, that could make them think twice about it. But instead, only denunciation of their financial health (insolent for sure, but what is the relationship with the matter at hand?) or invocation of technological sovereignty is brought.

You could get the upper hand through legal constraints, but its is certain it will take time, a lot of time. So defending technological sovereignty of France could make sense… in other circumstances. Because, I don’t know if you noticed, but France is in the middle of a pandemic right now. And France will only be able to eventually get rid of it through herd immunity; and I don’t know about you, but I’d rather acquire it through a vaccine, or failing that as late as possible. But by the time you’d have forced Apple’s hand through legal means, I think a vaccine will have been found.

Therefore, your insistence on technological sovereignty tells me that attempting to enforce it in the immediate situation is more important for you than having an efficient contact tracing solution, able to save lives. These priorities are backwards. Technological sovereignty matters, but there will be opportunities to enforce it later, or in other ways.

Maybe it’s unfair for Apple to be dictating their terms in such a way. Maybe it ought to be otherwise. But in the meantime, in the here and now, they hold the keys to the system.

Futile in the long run

Let us now assume Apple has given you the keys. Your troubles are not over. As the reasons for which they have set up these restrictions in the first place have not gone away, especially that of battery preservation.

So what is to say your solution will not excessively drain the battery? In particular, you will have a hard time finding skilled developers on the market when it comes to reasonable usage of Bluetooth when unshackled from these restrictions: even those who are currently doing so on Android may come to a few surprises once on iPhone.

This is particularly important as some iPhones remain in active usage for far longer than Android devices, so often with a degraded battery. I personally still haven’t replaced my 6-year-old iPhone 5S which still works fine, except its autonomy is no longer what it once was, and I don’t think I am alone. The matter isn’t merely that I will have to pay more attention to my battery level once StopCovid will be installed; the matter is how will the general public react to an application that, once installed, will cause the battery to drain more quickly, leading it to become fully drained if not carefully watched? A fraction at least will disable the application. And did not we tell earlier how important sufficient penetration was for the system to function?

Once again, the established situation matters, and the established situation is that Apple keeps maintaining many devices in the wild that others would consider obsolete (but which do feature Bluetooth Low Energy), and any shift in this equilibrium will be noticed. For instance, do you really want to expose yourself to accusations of trying to drive premature device renewal, when the additional battery drain of StopCovid will be realized, thus potentially forcing some to renew hardware that was previously more functional?

You could respond that Apple itself will encounter the same challenges and risk increasing the battery drain when they will implement their own system. That may be the case, but I would rather trust them in that domain than I do the developers of StopCovid, no offense meant.

Conclusion

I refuse the false dichotomy brought by some commenters, who would reduce the choice to the entity to which I would have to confide myself. With the right protocol, the right architecture, we can avoid having to trust any particular party more than we are comfortable with, and reconcile seemingly opposite requirements.

While Germany initially had its own project, it has recently announced joining the Apple and Google system, but that will not prevent it from proposing its own application based on that system. What is to prevent France from following the same path? We will all benefit by avoiding balkanization of solutions, and France here is not in a position of strength.

Cher M. Cédric O

This post is also available in English

Cher M. Cédric O,

Petite parenthèse à l’intention de mes lecteurs habituels: Cédric O est le secrétaire d’état au numérique du gouvernement français. De France. Non, je ne suis pas en train de réduire son nom à une initiale, c’est bien le sien. J’en profite donc pour dire que si on demande la mise en place d’une validation qui exige un nom d’au moins N caractères, la seule solution éthique pour un développeur est de refuser de l’implémenter. Fin de la parenthèse.

D’abord, je vous remercie pour vos récentes interventions, qui me permettent de donner un thème à ce billet que je souhaitais écrire: celui de la lettre ouverte.

Je souhaite donc réagir à la direction que vous voulez faire prendre au projet StopCovid, celle de la confrontation avec Apple. Je confesse volontiers un biais envers Apple, comme le montrent les sujets traités sur ce blog, qui tournent beaucoup autour des technologies Apple, iOS en particulier. Mais j’espère tout de même vous convaincre que aller à la confrontation avec Apple serait futile, quand bien même vous voueriez Apple aux gémonies.

Pourquoi

C’était à la base une excellente idée de démarrer et de développer le projet StopCovid, soyons clair, mais je pense qu’il est utile de développer pourquoi. En effet, certains observateurs (dont des que je respecte beaucoup, comme Bruce Schneier) ont dénoncé ce genre de système informatique de suivi de contacts comme étant du solutionnisme technologique, et cette accusation mérite donc d’être examinée. Il est inutile de rappeler ici le principe et l’importance du suivi de contacts, non seulement pour avertir ceux qu’un individu nouvellement diagnostiqué a pu contaminer à son insu, mais aussi tenter de retrouver l’individu ayant contaminé celui nouvellement diagnostiqué s’il est inconnu, et ainsi potentiellement remonter les chaines de contamination.

Par contre, il est utile de repréciser le cas d’utilisation principal, qui est de contenir des réémergences de l’épidémie, que ce soit en sortie du confinement ou importées de zones endémiques. On peut donc supposer qu’on est dans le cas d’une brêche qu’il faut colmater, et donc par exemple que des moyens peu déployés lors de la phase d’observation, comme les tests sur personnes non symptomatiques, peuvent être subitement largement mobilisés dès la première contamination diagnostiquée. L’un des buts du confinement (avec la diminution de la pression sur les services hospitaliers) est d’ailleurs de se ramener à une situation où le colmatage des brêches redevient gérable, au lieu d’une situation où il y a plus de brêches que de doigts disponibles pour les boucher.

Mais comme on l’a vu dans la recherche du patient zéro dans l’Oise (où il parait qu’on cherche encore; plus de deux mois après, l’utilité me semble limitée), les méthodes actuelles semblent défaillantes dans le cas du Covid-19. Et c’est ce que confirment des recherches venant de l’université d’Oxford, qui suggèrent que les caractéristiques épidémiques supposées du Covid-19 rendent futile l’espoir d’un suivi par les méthodes traditionnelles, confirmant le besoin d’un suivi automatisé dans le cadre d’un dispositif plus général.

Cette précision n’est pas inutile, car aucune application ne sera une panacée, mais plutôt le maillon d’une chaine dont tous les éléments doivent être présents. A commencer par des test massifs (ce que la France semble pouvoir fournir en ce début mai) mais aussi à retour rapide: si le résultat du prélèvement ne revient que trois jours après, qu’on prévient les contacts, et que les tests de ceux-ci ne parviennent que trois jours après cela, il est évident que même si l’application permet de déterminer instantanément les contacts, on se ferait distancer par la maladie. Il faut donc éviter à tout prix la constitution de listes d’attente pour les tests (la PCR elle-même ne prenant que quelques heures), et faire en sorte que les prélèvements puissent être rapidement apportés aux lieux de PCR. Et une application dispense moins que jamais la constitution d’équipes d’enquêteurs, ne serait-ce que pour tracer les contacts non couverts, lorsque l’un des deux ne dispose pas d’un téléphone compatible, ou pas de téléphone du tout, par exemple. C’est d’ailleurs pour tout cela qu’il n’est pas absurde de représenter la capacité de suivi département par département, plutôt que région par région.

Comment: la couche physique

Cela étant dit, on peut maintenant envisager les différentes manières d’enregistrer automatiquement les contacts. Ecartons d’emblée la géolocalisation: c’est à la fois pas assez précis pour les besoins: le GPS n’étant pas disponible partout ou instantanément, les smartphones se basent souvent sur la localisation par émetteur cellulaire ou Wifi, et trop invasif, pour des raisons évidentes. Le Bluetooth, lui, est conçu pour permettre des communications directes entre des appareils numériques, y compris des périphériques, et sa variante basse energie a même été conçue pour supporter des applications très contraintes comme être intégrée dans une étiquette de porte-clés, permettant ainsi d’en déterminer la proximité. Cette notion de proximité est essentielle: pour la recherche de contagions potentielles, on cherche moins à déterminer la distance exacte qu’à réduire le dépistage à une liste de contacts potentiels, quitte à ce qu’il y en ait un peu trop, plutôt que de devoir dépister tout le monde à 100km à la ronde en case de contamination confirmée.

Comment: le traitement des données

OK, donc un contact se déterminera rétrospectivement par le fait que les téléphones portables des intéressés ont été en mesure d’échanger (ou « d’échanger suffisamment fort » par mesure d’intensité du signal entre autres) des données par Bluetooth. Mais comment conserver ces données (et lesquelles), et où faire ce calcul le moment venu?

N’importe quel téléphone portable diffuse déjà des messages Bluetooth à qui veut les entendre pour des raisons diverses (c’est ce qui leur permet d’apparaitre dans la liste des périphériques joignables sur l’écran de sélection d’un ordinateur de bureau, par exemple). Donc une première idée est de mettre en place l’écoute des messages Bluetooth diffusés et stocker localement l’identificateur Bluetooth de l’émetteur. Mais cela montre assez rapidement ses limites: précisément pour des raisons de protection de la vie privée cet identificateur change régulièrement dans les mises en place des versions récentes de la norme, de sorte qu’étant oublié par son propre émetteur, il devient inutile; de plus, beaucoup de téléphones vont limiter si ce n’est arrêter les émissions lorsqu’ils ne sont pas activement utilisés afin d’économiser la batterie, qui n’a jamais cessé d’être une contrainte importante sur la conception des téléphones mobiles.

Donc, il semble indispensable de mettre en place une modification de comportement des deux côtés du contact, ce qui change les données du problème: il faut maintenant que les deux côtés soient modifiés pour que ne serait-ce qu’un côté bénéficie du système. En conséquence, c’est comme pour les masques: si son contaminateur n’avait pas l’application installée, son contaminé ne tirera aucun bénéfice d’avoir installé l’application, il importe donc grandement qu’une densité suffisante de participants soit atteinte. Cela conduirait à envisager la fourniture de montres connectées (qu’il est plus difficile d’oublier chez soi) à ceux qui, comme c’est leur droit, ne disposent pas d’un téléphone portable compatible.

Maintenant que nous avons la liberté de concevoir le logiciel des deux côtés de l’interaction, les possibilité de conception augmentent grandement, trop pour revenir dessus. Cependant, un choix significatif est celui du traitement permettant de déterminer si un contact avec un individu nouvellement diagnostiqué a eu lieu, traitement qui doit donc disposer des données nécessaires à cette détermination: doit-il se faire sur le téléphone (n’importe lequel: les deux étant désormais « hermaphrodites », ce que l’un peut déterminer, symmétriquement l’autre le pourra aussi), ou sur un serveur central?

Dans le deuxième cas, le but étant de prévenir le porteur du téléphone en contact, cela emporte a priori que le serveur dispose du moyen de contacter n’importe quel utilisateur du système (directement ou indirectement: si chaque utilisateur doit, à intervalle régulier, interroger le serveur avec « je suis l’utilisateur avec le pseudonyme x, y a-t’il du nouveau pour moi? Envoyez la réponse à l’addresse IP 192.0.2.42 », c’est équivalent à pouvoir être retrouvé).

Dans le premier cas, par contre, il est impossible d’empêcher l’utilisateur de déterminer à quelle occasion il a été en contact avec une personne nouvellement diagnostiquée (à défaut d’être informé directement de l’identité de celle-ci): quand bien même le traitement de détermination serait une fonction cryptographique difficile à inverser, il lui suffirait de la faire tourner sur des sous-ensembles de sa base de contacts, par dichotomie si besoin, jusqu’à trouver l’évènement unique suffisant pour que le traitement sorte qu’il y a contamination potentielle.

Le système d’Apple et Google

Cela étant établi, examinons maintenant les choix effectués par Apple et Google, ainsi que l’API fournie, par dessus laquelle une application pourra être réalisée.

Pour commencer, « Exposure Notification » est un service du point de vue de Bluetooth Low Energy, c’est-à-dire un protocole utilisant BLE pour la transmission radio des données, comme HTTP est un protocole utilisant TCP pour effectuer la transmission des données sur (généralement) Internet. Il est documenté ici à l’heure où j’écris ces lignes; en tant quel tel, il a été enregistré auprès du consortium gérant Bluetooth, avec son propre identifiant. Le format tel que transmis est simple: outre la trame Bluetooth obligatoire, c’est surtout l’identifiant de proximité en vigueur, mais celui-ci est accompagné par un champ de métadonnées, dont la seule utilité actuellement (outre versionner le protocole, ce qui permet de confirmer que les implémentations sont compatibles) est d’affiner le calcul de perte d’intensité du signal.

Comme son nom l’indique, l’identifiant de proximité en vigueur change à intervalles plus ou moins réguliers: plus ou moins car si le changement était trop régulier, cela faciliterait le pistage et rendrait ces changements inutiles: le changement s’effectue au plus toutes les 10 minutes, et au moins toutes les 20 minutes. Tout cela est décrit plus précisément dans la documentation cryptographique, qui décrit la génération des données envoyées par le protocole ci-dessus, comment sont stockées les données reçues et envoyées, et surtout comment déterminer qu’il y a eu contamination potentielle.

La propriété la plus importante du système « Exposure Notification » est que cette détermination est effectuée localement. Le système suppose la présence d’au moins un serveur, mais celui-ci ne fait que diffuser des données non-nominatives collectées (volontairement) auprès des individus diagnostiqués afin de permettre cette détermination par le récepteur: rien n’est remonté pour les utilisateurs tant qu’ils ne sont pas diagnostiqués positivement. Même les données envoyées révèlent peu, dans la mesure où elles reviennent à révéler les données générées aléatoirement qui ont servi pour l’envoi des identifiants de proximité en vigueur, sans qu’aucune autre donnée personnelle, notamment d’identification, ne soit impliquée.

Le système revendique de manière crédible d’autres propriétés: il semble par exemple impossible de collecter des information émises par d’autres, pour ensuite faire diffuser que ces autres ont été contaminants en faisant passer ces informations pour siennes (il n’y a pas que les innocents qui seront diagnostiqués positifs au Covid-19, il faut supposer que des adversaires le seront aussi, et en conséquence minimiser leur pouvoir de nuisance).

Cela étant, le système ne garantit pas en soi que seuls les individus diagnostiqués positivement pourront envoyer leurs informations: je vois difficilement comment il pourrait contrôler quoi que ce soit dans ce domaine, il repose donc sur les autorités sanitaires pour effectuer ce filtrage.

Cela est manifeste dans le troisième et dernier document, qui décrit l’API qu’une application (ici pour appareil Apple sous iOS) devra utiliser pour servir d’interface au service. L’API gère en coulisses tout ce qui est protocole Bluetooth et stockage des données, mais ne s’occupe d’aucune interaction réseau, l’application devant effectuer ces tâches elle-même: une partie des fonctions de l’API consiste à se faire fournir explicitement ces données, ou fournir les données devant être envoyées; c’est plus explicite dans le documentation d’API pour appareil Google sous OS Android, qui décrit par ailleurs la même API, langage Java mis à part, Android oblige.

Mis à part cela, l’API en général ne présente pas de surprise: c’est de l’Objective-C moderne, avec des blocs utilisés pour que l’application puisse se faire rappeler une fois le traitement des données complété par exemple. Elle semble bien couvrir les modes d’utilisation des futures applications: une classe ENManager pour les interactions avec le système en général comme afficher le statut (autorisé ou pas, principalement) et récupérer les données à envoyer au serveur en cas de diagnostic, et une classe ENExposureDetectionSession à utiliser au moment de vérifier si la dernière fournée d’informations de diagnostic ne déclencherait pas une exposition lorsqu’on les combine avec les données enregistrées en interne. La seule surprise étant l’Objective-C: on se serait plutôt attendu à du Swift vu comme le langage est à la mode chez Apple, mais cela ne change pas la fonctionnalité de l’interface, il est même probable qu’elle puisse être utilisée directement depuis Swift.

L’API révèle une dernière fonctionnalité intéressante, qui est la possibilité de déclarer son risque au système en cas de suspicion de contamination, avant même le diagnostic formel, afin d’avertir en cascade les contacts; avec une intensité moindre, bien entendu. Cela devra tout de même passer par les autorités sanitaires, reste à voir ce qu’elles vont en faire.

Le système d’Apple et Google: les non-dits

Comme on le voit, si la documentation du système mentionne le rôle du serveur, elle reste muette sur combien existent, comment il sera géré ou ils seront gérés, et par qui. Multiplier les serveur serait dommageable dans la mesure où cela obligerait à installer autant d’applications qu’il y aurait de serveurs en vigueur pour bénéficier d’une couverture correcte (tant pour pouvoir récupérer les informations diffusées par chacun de ces serveurs, que pour pouvoir envoyer à chacun de ces serveurs le cas échéant); cela pourrait être acceptable (mais on pourrait s’en dispenser) dans des cas particuliers, comme les travailleurs transfrontaliers, c’est par contre complètement inacceptable pour l’utilisateur moyen.

Les deux compagnies ont indiqué l’intention de sévèrement restreindre l’accès à ces API: je cite leur document commun regroupant les réponses au questions fréquemment posées:

10. Comment les applications obtiendront-elles l’autorisation d’accéder à ce système?

Les applications recevront cette autorisation selon un ensemble déterminé de critères choisis pour s’assurer qu’elles ne seront administrées qu’en relation avec les autorités de santé publiques, atteignent nos exigences de protection de la vie privée, et protègent les données utilisateur.

Ces critères sont spécifiés séparément dans des accords que les développeurs ont à accepter afin d’utiliser les API, et sont organisés autour des principes de fonctionnalité et de protection de la vie privée. Il existera des restrictions sur les données que les applications seront en mesure de collecter lorsqu’elles utiliseront l’API, y compris l’impossibilité d’accéder aux services de localisation, ainsi que des limitations sur l’usage qui pourra être fait des données.

Apple en particulier dispose de mesures de contraintes pour que cela soit appliqué: non seulement une application en général ne peut être distribuée (au-delà d’une poignée d’exemplaires) sans leur aval, mais il est certain qu’une permission pour accéder au service depuis le sandbox (« bas à sable » qui héberge les applications dans iOS, restreignant leur accès au système d’exploitation aux services nécessaires hors passe-droit, reconnu uniquement si signé par Apple) sera nécessaire, avec fort peu d’entités pouvant éventuellement y prétendre (étatiques, principalement); désolé pour ceux qui voudraient jouer avec: com.apple.developer.exposure-notification sera la permission distribuée de manière la plus restrictive de toutes celles disponibles pour l’iPhone… Il y a fort à parier qu’Apple n’hésitera aucunement à invalider une permission qui aurait fuité ou aurait été abusée.

Vu la position d’arbitre d’au moins Apple, l’absence de régle ou même de recommandation sur la multiplication des serveurs m’interroge, donc. Je peux concevoir que ni Apple ni Google ne souhaitent s’exposer plus encore à des accusations de se placer au-dessus des états, mais il serait souhaitable d’avoir confirmation que pas plus d’un serveur ne serait autorisé par pays (défini comme une entité disposant de représentations diplomatiques ou assimilées), sans que cela obère la capacité de chaque pays a avoir plusieurs applications selon les besoins, tant que celles-ci se basent sur le serveur national. J’espère bien sûr que l’UE mettra en place un serveur commun que tous les pays adopteront, et idéalement il en faudrait un seul par continent, mais il semble difficile de désigner pour chaque continent l’entité politique qui pourrait prendre cela en charge (quant à avoir un serveur mondial, si cela était viable tant politiquement que techniquement, Apple et Google s’en seraient déjà chargés).

De plus, la documentation mentionne une deuxième phase où le système pourra être activé « de base » par le système d’exploitation sans aucune application installée, avec suggestion d’installer une des application si le système détermine un contact potentiellement contaminant; or si le système « de base » peut déterminer cela, ça implique la récupération de données depuis un serveur sans qu’une appli n’ait été installée, alors lequel est utilisé?

Et sinon, aucune précision sur le rôle des autorités de santé pour s’assurer de la fiabilité des informations diffusées par leur serveur. Je pense à un incident qui m’a été rapporté lorsque je travaillais dans les télécoms: les réseaux de communications sans fil pour policiers et pompiers ont une fonctionnalité « appel de détresse » que ces clients prennent très au sérieux, on peut comprendre pourquoi. En pratique, c’est un appel vocal, mais avec un drapeau qui déclenche certains traitements spécifiques (de priorité notamment) et soulève des alarmes un peu partout. Et lors d’une première interconnexion avec le système du district venant d’un concurrent, tout ne s’est pas passé comme prévu. En effet, même si la norme d’interconnexion précisait comment faire passer l’information qu’un appel était de détresse, elle laissait beaucoup de liberté sur comment prendre en compte cette information; et il s’avère qu’au moins un des deux systèmes considérait le statut détresse comme sufisamment important pour qu’il doive être mémorisé pour le canal en question, jusqu’à ce que ce statut soit explicitement levé par un superviseur. Ce qui n’est pas absurde en soi, mais si le canal appartient à l’autre système en interconnexion, celui-ci n’ayant pas la même configuration n’envoyait jamais une telle confirmation, de sorte que le canal était dorénavant considéré comme étant perpétuellement en détresse, même pour les appels ordinaires. Assez rapidement, tous les canaux dans ce cas ont fini par passer en détresse sans pouvoir les faire redescendre, et lorsque tous les appels sont de détresse, eh bien plus aucun ne l’est. Il a fallu envoyer une correction en urgence.

Il semble donc risqué d’investir des ressources (d’ingénieurie, validation, etc.) dans la mise en place d’un système sans écarter le risque que cela ne soit pour du beurre s’il finit par donner trop de faux positifs pour rester utilisable. Des règles pour assurer la fiabilité des informations diffusées par le ou les serveurs me semblent indispensables.

Enfin, pour rester dans la question géographique, un risque (soulevé par Moxie Marlinspike) est que la base de données à télécharger pourrait devenir trop grosse (en particulier en cas de reprise de l’épidémie) pour être pratique à télécharger, de sorte qu’il faille la partitionner selon la localisation… et réintroduire de la géolocalisation pour ce faire, ruinant une partie des garanties offertes. Comme pour la multiplication des serveurs, je pense que c’est quelque chose au sujet duquel Apple et Google doivent déclarer leurs intentions.

La confrontation

StopCovid, comme de nombreux autres projets, a été démarré avant la publication de l’initiative d’Apple et Google; le projet est parti sur des principes différents, ce que je respecte en soi; le protocole, appelé ROBERT, est documenté. Le choix a notamment été fait d’une architecture où la détermination de contamination est centralisée, avec les avantages et inconvénients que cela comporte, je ne reviendrai pas dessus.

Déjà, comme pour la question de la multiplication des serveurs, on peut se poser la question de la multiplication des protocoles: faudra-t’il que tout un chacun s’équipe d’une application pour chaque protocole? Mais ce n’est pas là où le bat blesse dans l’immédiat: le protocole ROBERT utilisant, comme attendu, Bluetooth, son implémentation sur iPhone rencontre des restrictions établies de longue date par Apple sur les possibilités d’utilisation du Bluetooth par une application non-active; ces restrictions sont documentées par Apple, même si de manière peu précise; je ne doute pas que la projet ait pu les mesurer par lui-même. Elles ont pour objet la préservation de la batterie et la protection de la vie privée. Elles réduisent drastiquement la viabilité de la solution.

Technologiquement, il était important d’essayer, ne serait-ce que pour être crédible et ne pas dépendre d’un partenaire qui aurait été choisi faute d’alternative. Le projet StopCovid, notamment par les expérimentations de mesure (approximative) de distance par Bluetooth, a déjà accompli des avancées qui serviront plus généralement, et en tant que projet il pourrait continuer dans le cadre d’un protocole plus général, l’adoption d’un autre protocole ne signifiant pas la fin du projet.

Parce que soyons clairs: les médias parlent de systèmes qui pourraient être « rendus compatibles », mais la seule manière que je connaisse de faire communiquer deux systèmes, c’est qu’ils implémentent le même protocole. Il peut s’agir de deux implémentations différentes, mais il doit s’agir du même protocole.

Car le choix que vous avez fait, devant l’existence de ces restrictions qui ne sont pas nouvelles, est celui de la confrontation avec Apple: vous vous étonnez qu’Apple ne lève pas ces restrictions à la demande, et vous insistez pour que le projet puisse arriver en production selon ses principes actuels, invoquant une question de souveraineté technologique.

Une telle confrontation est futile et même nuisible, et ce pour au moins deux raisons.

Futile dans l’immédiat

Au-delà de ces restrictions, Apple a plus généralement établi le pricipe qu’ils contrôlent les logiciels pouvant être distribués sur les appareils mobiles de leur marque. Au fil des années ce contrôle m’a de moins en moins plu, de sorte que je cherche des alternatives, notamment par le web, pour distribuer mon travail personnel. Cela devient viable pour certaines applications, comme le traitement de fichiers, mais dans le cas du Bluetooth il n’y a pas d’alternative au SDK « natif ».

Donc même si j’objecte moi-même à certaines des politiques d’Apple, croyez-vous sérieusement qu’après qu’ils aient passé 12 ans à avoir dicté leurs conditions comme ils l’entendaient pour les logiciels iPhone, sans exception, à part celles dont ils ont eux-même défini les termes (il en existe quelques autres, moins documentées), vous alliez pouvoir les convaincre ou leur forcer la main si rapidement? C’est illusoire.

C’est d’autant plus illusoire que dans d’autres situations où ils étaient autrement plus exposés (je pense notamment à une requète de déchiffrage venant du FBI), Apple a résisté aux pressions visant à les faire céder, et ils en étaient fiers et le sont toujours. C’est entre autres une question de fierté profesionnelle, tant pour ce qui est de la préservation de la batterie que la protction de la vie privée. Croyez-vous que des mouvements de menton vont suffire à leur faire changer d’avis?

Si encore vous vous prévaliez d’arguments, comme les avantages potentiels d’une solution centralisée comme ROBERT sur la protection de la vie privée face à leur solution, c’est quelque chose à laquelle ils pourraient être sensibles. Mais non, il n’est question que de dénoncer leur santé financière (insolente certes, mais quel est le rapport?) ou de souveraineté technologique.

Vous pourriez obtenir gain de cause par l’une ou l’autre contrainte légale, mais il est certain que cela prendra du temps, beaucoup de temps. Défendre la souveraineté technologique de la France pourrait donc avoir du sens… dans d’autres circonstances. Car je ne sais pas si vous avez remarqué, mais il y a une pandémie qui touche actuellement la France. Et la France ne pourra s’en débarasser à terme qu’en ayant l’immunité collective; et je ne sais pas vous, mais je préfèrerais l’acquérir moi-même par un vaccin éventuel, ou le plus tard possible le cas échéant. Or le temps que vous contraigniez Apple par la voie légale, je pense que le vaccin aura été trouvé.

Votre insistance sur la souveraineté technologique m’indique donc que faire valoir celle-ci dès maintenant est pour vous un objectif plus important que d’avoir une solution efficace de suivi des contacts, susceptible de sauver des vies. Ces priorités sont dans le désordre. La souveraineté technologique est importante, mais il sera toujours temps de la faire valoir plus tard, ou autrement.

Il est peut-être injuste que Apple dicte ainsi ses termes. Il devrait peut-être en être autrement. Mais en attendant, là, ici, et maintenant, ils ont les clés du système.

Futile à terme

Supposons maintenant qu’Apple vous donne les clés. Vos ennuis ne sont pas finis. Car les raisons pour lesquelles ils avaient posés ces restrictions à la base n’ont pas disparu, notamment la préservation de la batterie.

Donc, qu’est-ce fera que votre solution ne va pas drainer trop rapidement la batterie? En particulier, il vous sera difficle de trouver des compétences sur le marché des développeurs pour ce qui est d’utiliser raisonnablement le Bluetooth une fois ces restrictions levées: même ceux qui le font déjà sur Android pourront avoir des surprises une fois sur iPhone.

C’est particulièrement important parce que des iPhones restent en activité beaucoup plus lontemps que les appareils Android, avec souvent donc une batterie dégradée. Je n’ai moi-même toujours pas remplacé mon iPhone 5S d’il y a plus de 6 ans qui fonctionne très bien, sauf que son autonomie n’est plus ce qu’elle était, et je pense ne pas être le seul. La question n’est pas juste que je devrai faire plus attention à ma batterie une fois StopCovid installé; la question est comment le public va réagir à une application qui, après installation, va drainer plus rapidement sa batterie, pouvant conduire à son épuisement s’il n’y prend pas garde? Une partie au moins va désactiver l’application. Et on n’avait pas dit qu’une pénétration suffisante était importante pour que le système fonctionne?

Encore une fois, la situation existante compte, et la situation existante est que Apple continue à entretenir de nombreux appareils dans la nature que d’autres considèreraient obsolètes (mais qui sont équipés du Bluetooth Low Energy), et tout changement dans cet équilibre se remarquera. Voulez-vous par exemple vous exposer à des accusations de vouloir encourager le renouvellement prématuré, lorsqu’on s’apercevra du drain de la batterie induit par StopCovid, susceptible de contraindre à un renouvellement d’un matériel auparavant plus fonctionnel?

Vous pourrez me dire qu’Apple eux-mêmes risque de susciter aussi un drain augmenté de la batterie avec l’implémentation de leur système. C’est possible, mais je leur fais plus confiance dans ce domaine qu’aux développeurs de StopCovid, sans vouloir les offenser.

Conclusion

Je refuse la fausse alternative proposée par certains commentateurs, qui voudraient réduire la choix à l’entité à laquelle on accepte de se confier. Avec le bon protocole, la bonne architecture, on peut éviter de devoir faire confiance à quelqu’un plus qu’on le voudrait et concilier des exigence apparemment opposées.

L’Allemagne, après avoir commencé de son côté, a annoncé rejoindre le système de Apple et Google, mais cela ne l’empêchera pas de proposer son application sur la base de ce système. Qu’est-ce qui empêche la France de faire de même? Il est de l’intérêt général d’éviter la balkanisation des solutions, et la France n’est pas ici en position de force.

Slight Pause

(Yes, as if I had published any post in the last three months, in the first place…)

If you’re looking for software development treatises or Apple nerdery, I’m afraid I haven’t been able to focus on writing on these matters recently. I do have posts in the pipeline, but I don’t know when I will manage to publish them.

Meanwhile, the action is happening elsewhere.

To arms, citizens!

To arms, I say! I just realized the enormous scandal that is the presence in Unicode of the emoji character TOKYO TOWER (U+1F5FC), which you should be able to see if you are equipped with a color set after the colon: 🗼. Scandal, I say, as this thing, which we never talk about at home whenever we talk about Tokyo, and for good reason, as it is in truth a pale imitation of our national tower, the Eiffel tower, that the Japanese made at a time when they found success in imitation… Where was I? Oh, yes, so, that thing managed to steal a spot in Unicode even though our Eiffel tower isn’t in there! Scandal, I say!

Worse yet, this was done with the yankees’ complicity, who shamelessly dominate the Unicode consortium; the collusion is obvious when we see they themselves took advantage of it to slot in the statue of liberty. And I say, no, this shall not pass! Say no to the US-Japan cultural domination! That is why, from now on, my blog will be in French. Too bad for you if you can’t read it. I even started translating my previous posts, starting with my greatest hits, namely A few things iOS developers ought to know about the ARM architecture, Introduction to NEON on iPhone, Benefits (and drawback) to compiling your iOS app for ARMv7 et PSA: Do not release ARMv7s code until you have tested it. And I have no intent of stopping there.

Join me in the protest to demand that the Eiffel tower be added to Unicode! To arms!

(disclaimer)

Je Suis Charlie

Today, in France, freedom of expression was attacked. For through their odious act today, the perpetrators did not merely target Charlie Hebdo. They targeted Siné Hebdo. They targeted Le Canard Enchaîné. They targeted Le Monde. They targeted TF1. They targeted RTL. They targeted Maitre Eolas. They targeted Cyprien. They targeted the press, the radio, the television, the blogs and all of Internet. They targeted the whole of the media, the freedom of expression of us all and through it, our Republic.

And we will not back down.

This evening, I am on the place de la République, because as a Frenchman, as a blogger, as a person, I benefit from freedom of expression and I will stand by it. And even if I did not, in fact, buy or read Charlie Hebdo, today #JeSuisCharlie, and this site is blacked out.

And we also will not take any shortcut. Today our enemy is not Islam, or Muslims, or Arabs, or any religious, ethnic, national or other group. Today our enemy is terrorism.

We will not “remember” Charlie Hebdo, because rest assured that Charlie Hebdo will live. But we will remember Cabu, Charb, Wolinsky, Bernard Maris, and the others I am less familiar with (sorry) or who were not mentioned on the radio. Today my deepest condolences go to their families.

image

Our Republic is looking extra significant tonight.

Vote

This post, I’m afraid, will only be of interest to my European Union readers. If you are not a E.U. citizen, sorry, and thanks for visiting.

Fellow Europeans, it is very important for you to go and vote in the coming European elections. Indeed, the European parliament in Strasbourg is the only democratically elected European institution, and it is important in this specific opportunity to make our voice and our vote heard.

  • It is important because, following the 2008 financial crisis, the Union had to take a more important role in order to help the countries most affected by the crisis, and this revealed the need for a more transparent and more democratic E.U. decision process.
  • It is important because we now realize that a common market will end up implying common food and product safety services, among others: when the next food safety crisis occurs, it will make no sense to have state-specific reactions for products that circulate in the whole of the Union.
  • It is important because subjects that matter a lot in technology, such as privacy, net neutrality, or competition regulation, are by necessity increasingly decided at the E.U. level, when they aren’t already.
  • It is important because, in contrast with the common market, we still have made little to no progress on common social protections and labor laws, and the contrast between these two situations is more and more noticeable, hampering development of a common personal services market.
  • It is important so that, as the geopolitical situation evolves, we can have a credible E.U. foreign affairs department that can claim to represent the European people.

But most importantly, it is important for as many of you as possible to cast your vote, in order to make the parliament’s legitimacy indisputable so as to give it real decision power over E.U. affairs, rather than have our fates decided by less democratic, parochially charged negotiations between the head of states. So for these reasons, and many others, go vote for your European parliament representatives in the next few days1.

And be wary of these sovereignty parties who promise you a better tomorrow but in fact only offer at best unconstructive criticism of the unification process, and do not detail how they could possibly manage either (depending on the situation) getting out of the Euro, or out of the Schengen zone, or out of any other E.U. commitment, as their cure could very well be worse than any disease.


  1. In fact, while I vote this Sunday, May the 25th 2014 in France, I learned today that some countries, including the United Kingdom, are voting today already, which is another thing we may need to agree on: how can we have a pan-European election campaign if not every country votes at the same time?