#FreeFortnite

Don’t underestimate what just happened: Epic remotely adding an in-app circumvention for in-app purchases in Fortnite on mobile is an engagement of hostilities on par with the bombing of Pearl Harbor. Or the people of Paris taking the Bastille, depending on your point of view. This isn’t just the Hey saga: the relationship between Epic and Apple (and Epic and Google) can never be the same after that.

What’s at stake? Just the whole principle of tight control of mobile platforms by their stewarts, that’s pretty much it. Indeed, you can’t keep the conversation on the “dirty percent” without then reviewing the agency model and the exclusivity (or extinguishing dominance, in the case of Android) of the platform application store, which brings into question app review, which leads us to Apple’s meddling and misguidance and around-pushing and self-dealing and feeding us garbage and capriciousness (too many incidents to list) and inconsistency and preferential treatments (again, too many) and dual-personality and overpowering control and petrification of developers (worth blowing one NYT free read).

Any single one of those is a fundamental injustice, in the sense that each of them represent a damned-if-you-do (Apple could catch you), damned-if-you-don’t (you have to take user criticism/you get punished by the market for being non-competitive/etc.) alternative for the developer. And yet with few exceptions (coverage by Charles Arthur at The Guardian comes to mind), this never reaches the mainstream. But Epic has accomplished that: the news has spread everywhere by now, leading to unprecedented scrutiny of Apple’s actions, and it’s not about to stop. For instance, we’ve always had to assume the best possible intentions from Apple whenever they introduced some restriction, because conspiratorial thinking leads to nowhere, but as Steve Troughton-Smith raises that which we could learn through the lawsuit could be very damaging through revealing what their planning was for introducing them. Yes, it’s a stunt. Of course it’s a stunt. Of course it’s self-serving. But many significant actions were initially dismissed as stunts; what matters is whether it brings us closer to justice.

I think Epic’s message is rather awkward and is preaching too much to the choir, and that them targeting the Play Store as well (which you could always circumvent through Android side-loading) is muddying the message. But not only did it reach the mainstream as mentioned, Epic is making an important point that through sheer airspace saturation has a good chance of reaching the rank-and-file at Apple (and Google): didn’t you become that which you fought? Such a targeting is something that I feel has been missing in the tech conversation. That’s the second thing they’re doing right.

I also hear they are a big faceless company, and I myself wouldn’t trust them any farther than I can throw them, but I can’t answer this argument better than mcc did: given the sheer size of Apple and Google, how could an indie possibly hope to meaningfully take on them? Still, that leaves the question of what will they actually do if they win… but, as it turns out, that doesn’t matter. It’s not a succession war with a zero-sum outcome of just determining who will lord over us: Epic can’t dethrone Apple as the platform stewart. The best they can hope for is having their own store as a peer to the Apple-managed iOS App Store, and if that happens, guess what will happen? Valve will be able to do so as well, and so will instantly bring Steam to iOS. Activision Blizzard will probably want in on the action, as well. etc. And now you have healthy competition of app stores on the platform, such that none of them has veto power over any developer. That is the third and most important reason for why their campaign deserves to be supported.

Look, it can simultaneously be true that Epic is full of shit when they “pass on” the savings for cosmetic add-ons for which they have full pricing power and zero fixed cost, and that they are in the right to take on this Apple policy, because that policy is abusive for the many, many cases where there are fixed costs and pricing power is more limited, so it is abusive in general. And while I think that Epic has little chance of winning their lawsuit given current U.S. law (or elsewhere, should they attempt in France or the E.U.), I also think they should eventually win this fight. So, yeah, #FreeFortnite.

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.

Bruno Le Maire, Apple, and Google

A quickie because everyone’s mentioning it: France’s finance minister Bruno Le Maire announced he’d be suing Apple and Google for anticompetitive behavior with regard to people developing apps for their respective smartphone platforms. Here is the source (via).

The translation in the Bloomberg article (via) is more or less correct, with the exception that Bruno Le Maire only mentions “the data”, not “all their data”. So you’re not missing out on much by not being able to listen to him in the original French.

Now as to the contents of the announcement… I sure hope the actual suit is drawn from better information than what we’ve been given here, because while I’m on the record as deeming the current system of exclusive distribution through an app store (something which Google isn’t even guilty of) as being unsustainable in the long run, to have any hope of improving the situation through a suit Apple should be blamed for things it is actually doing. For instance, developers do not sell their wares to Apple (or Google) by any definition of that word, they do have to use a price grid but have full latitude to pick any spot in that grid, and Apple at least does not get that much data from apps.

Beyond that, I believe there could be a case here, but I see many more matters where Apple could be, shall we say, convinced to act better through public action from consumer protection agencies, antitrust agencies, or tax enforcement agencies. Why aren’t there announcements about those too? At any rate, I’m not going to breathlessly pin my hopes on that action until I get more, and more serious, information about it.

On the management of the performance of older iPhone models

When the coverage that Apple had admitted to capping performance of older iPhone models (when it detects their battery may no longer be able to withstand the necessary power draw) reached the (French) morning radio news I usually listen to, I knew Apple had a PR crisis of epic proportions on their hands.

Much has been written about this covert update to these iPhones, but the most important lesson here is the illustration that, once again, Apple completely and utterly fails at communication. If that PR crisis is not taken by the higher echelons as a wake-up call for Apple to take communication seriously from now on, what will?

Let us back up a bit, at the time Apple engineering was devising this solution for the (real) issue of some devices spontaneously resetting because the battery could not sustain the instantaneous power draw. We know it is the case that this was a project of some sort, in particular because the solution was rolled out for some models first, then other models, etc. Such a thing was obviously documented internally, because it is an important change of behavior that their own QA teams will notice when qualifying the software for release, also because it resolves a support issue, so obviously customer support was in the loop so as to provide feedback on which compromises are acceptable, etc. And yet, at the end of the day, when the fix is about to widely land in people’s phones, the system inside Apple is so completely stuck up on secrecy that not even an extremely expurgated version of this documentation makes it out the door? What is wrong with you people?

As a developer-adjacent person, I can see many developers being affected by this when they can’t understand why the performance of their product has regressed, but this pales in front of the perception by the general public of the whole affair… Indeed, many perceive (with or without justification, doesn’t matter) their computing products as slowing down over time, and given a lack of an easy-to-pin-down cause (I think it’s partly perception, and partly the compounded effect of multiple reasonable engineering tradeoffs), they are more than ready to embrace conspiracy theories about this. And now you’ve given them an argument that will feed conspiracy theories about this for decades! Even for issues completely unrelated to this performance capping (e.g. more pervasive performance pathologies). Stellar job here, Apple! Engineering-wise, I can’t fault the technical solution, however faced with someone affected by the issue, I can’t see how I or anyone, even an army of Apple geniuses, could credibly defend Apple. For all of us who trust on Apple to make reasonable compromises on our behalf (because we want to buy a computer/tablet/phone, not a computer/tablet/phone-tinkering hobby), and who told their interlocutors to place the same trust, you have damaged our credibility — and yes, it is something that should worry you Apple, because our credibility is part of your brand, ultimately.

On this particular issue, now that it has reached criticality, I think Apple made the right call in offering to replace batteries for $29 when they are degraded enough to trigger the capping, but that of course reeks of PR damage control, because that is (also) exactly what it is, so the bigger question of Apple’s capability to communicate remains open.

And I can’t close without saluting the work by the Geekbench crew to narrow down and confirm this effect. I’ve been critical of their product in the past, and I still am, but I have to recognize that it has allowed to bring this action from Apple to light, and I am thankful to them for this.

The Mac App Store and long-term app preservation

I am fortunate enough not to have apps on the Mac App Store, and I have bought few enough apps on it (for reasons I previously exposed) that I initially missed the meltdown, due to the store, of many apps bought there. This is not an outage, in the sense that an outage implies the user is aware on some level on being dependent on an online resource; this is worse. This is not just unacceptable: this is a fundamental violation of the trust that both app developers and customers have placed in Apple, namely that bought, installed and compatible apps would keep working (short of any dramatic action taken for consumer protection so that they would not, such as revoking the certificate of a malicious developer).

Worse, this has implications beyond the Mac App Store per se. As you know, Apple is reserving many APIs related to online services even in a remote fashion to Mac App Store apps: even when there is a non-Mac App Store version of the app available, it cannot make use of iCloud (is there a typo version of “revealing tongue slips”? Because I initially typed ”iCould”…) or Apple Maps. So, in turn, how am I supposed to trust iCloud or Apple Maps, if I am not sure I can run any app that can access it? As if these services did not already have a reputation…

But even more troubling are the implications for long-term usage and preservation of software and it data. The consumer issue of not being able to trust that a purchased app will keep running even when nothing else changes is bad enough (you could set back the system clock, but how realistic is that, even in an unconnected system? You would no longer be able to trust the creation or modification dates of any of your documents, for a start); but the implications on being unable to preserve running software on a cultural level is frightening. Even more so for the documents with proprietary formats created by that software. I’ve been following with interest the initiatives of Jason Scott in that area, I am definitely down with the need to preserve this software and data, not just for ourselves, but the future generations. And the Mac App Store (and the iOS App Store, the only difference being that we have not had any fire drill on that side. Yet.) is “not helping”. To put it mildly, because this blog tries to be family friendly.

I initially though there was no DRM component to this story: certificates, “damaged apps”, that sounded like code signature infrastructure, in other words protection of the consumer against malware, something that the user can disable (ostensibly, at least). But when I tried to convince my Mac to run this app as an unsigned app, I encountered what is extremely likely to be the store DRM: I initially got the “your app was bought on another machine” message, so I tried deleting the receipt, but then I got the dreaded “app damaged” message, at which point I removed the signature. But no way: in that case, what happens is that the app does not launch either, with the console printing:

13/11/15 15:36:23,608 com.apple.launchd.peruser.502: ([0x0-0x2cc2cc].com.tapbots.TweetbotMac[9317]) Exited with code: 173
13/11/15 15:36:23,663 storeagent: Unsigned app (/Applications/Tweetbot.app).

Since I removed the MAS receipt, how is storeagent getting involved? Probably in order to decode the app DRM, and as you see it refuses to do so due to the app being now unsigned. So now we have DRM preventing us from running our legitimately bought software. I have kept a pristine copy of the app in a safe location to make further attempts, but the only way I can see is to create a new root CA which I install on the machine as a trusted root, and redo the signing chain, and even that might not work if the DRM is somehow tied to the signature chain.

I was already wary of buying apps without trials; this event guarantees that I will never buy anything else from the Mac App Store (and will try to obtain direct licenses of apps already bought there). No direct version of your app? You don’t get my business. I would delete the Mac App Store app if I could. Apple could change my mind by providing verifiable commitments on the ability to disengage the signature checks and in operational service levels, and even then… Furthermore, Apple owes an apology to all the app developers who trusted them with the Mac App Store and who had a long day (and will continue to have long days) of customer support entirely due to Apple’s incompetence.

Apple later on sent emails to developers to explain themselves on the issue; I will count that as the aforementioned apology. I don’t mind that they took a few business days to react, as they themselves had to figure out what the problems were from the multiple reports; I do mind that, operationally, they allowed developers and themselves to be caught flat-footed in the first place: why isn’t there anyone at Apple checking that a sample of Mac App Store apps do run on a machine with the time perpetually set to one month in the future? Still, I guess I’m glad we got an answer in the first place. — November 19, 2015

~ Reactions ~

Rainer Brockerhoff, besides presenting some investigations and corrections, took some issue with my investigation methods, and we started exchanging in the comments there. Don’t miss it.

Apple is all grown up. It needs to act like it

Look. I have already argued about Apple reaching hubris. I have previously written about what seriously looked like power abuses, then chronicled in the past how their credibility may be eroding (while adding a jab at how I thought they were stretching the truth). And rest assured there are many other events I did not cover in this ongoing iPhone shenanigans category. But here I really have to wonder whether Apple is currently engaged in a oneupmanship match with itself in that regard.

The latest events, of which the Transmit iOS feature expulsion is but the most visible, have made me think and eventually reach the conclusion that the iOS (and Mac, to an extent) platform is not governed in a way suitable for a platform of this importance, to put it lightly; even less so coming from the richest company on Earth. Apple has clearly outgrown their capability to manage the platform in a fair and coherent way (if it ever was managed that way), at least given their current structures, yet they act as if everything was fine; the last structural change in this domain was the publication of the App Store Review Guidelines in 2010, and even then, those were supposed to be, you know, guidelines. Not rules or laws. And yet guidelines like those are used as normative references to justify rejections and similar feature removal requests. This is not sustainable.

Back at the time of the Briefs saga, I was of the opinion that the problem was not so much the repeated rejection decisions than the developer being repeatedly led to believe that with this change or maybe that change Briefs could be accepted, only for his hopes to be squashed each time. Look, I get that the Apple developer evangelists at DTS (Developer Technical Support) honestly thought Briefs would be a worthwhile addition to the iOS platform and genuinely were interested in this app seeing the light of the day on the iOS App Store; but at the end of the day, it was Rob Rhyne’s time and effort and livelihood that was on the line, not theirs, so yes, the fault for the whole Briefs debacle lies with them, not the iOS App Review Team. Today, the same way I wonder whether the fault really lies with the iOS App Review team. Okay, okay, before you go ahead and drown me under the encrypted core dumps reported from users of your iOS and Mac apps, hear me out. To begin with, no matter how desirable (including for some people at Apple) a rejected app is, if the higher ups at Apple were to start issuing executive orders overriding App Review Team decisions, or if pressure was put on reviewers by other Apple employees to accept an app, it would undermine the work of the App Review Team at a fundamental level, their authority would become a joke, and anyone worthwhile working there would quit, leaving the rest to handle the reviews. I don’t think that is what anyone wants. So yes, this means that regardless of the great work on new APIs from the OS software teams, regardless of the interest from Apple leaders to have on iOS, say, more apps for teaching computing, regardless of the desire of the iOS App Store editorial staff or Apple ad teams to feature innovative apps, regardless of the willingness of DTS to help quirky apps come to life, this means that regardless of all this, if the App Review Team isn’t on board, none of that will be of use. So its power needs to be limited, certainly, but not just about any random way.

“It is a timeless experience that any man with power is brought to abuse it […] So that power cannot be abused, the dispositions of things must be such that power stops power.” De l’Esprit des Lois, Livre XI, chapitre IV. I think it may be time for Apple to apply the rantings[fr] of an obscure magistrate from the Bordeaux area (link and expression courtesy Maitre Eolas[fr]). To begin with, all app review decisions must refer to normative texts published before the app was submitted (no retroactive application). I can already hear reviewers (even though I know they will never say it out loud) complain that they cannot possibly predict every situation in advance and need the flexibility to come up with new rules on demand, to which I answer: shut up, shut up, shut up. To me, that line of thinking (which just oozes out of the Introduction to the [iOS] App Store Review Guidelines) sounds suspiciously like a George III or Louis XIV. Even if you reviewer thinks an app should not be part of the App Store, if this app has to be accepted for lack of a rule prohibiting it, then so be it; if the rule makers (which are of course different from those applying these rules) are interested, they will come up with a new rule, at which point it can be enforced on new apps. Speaking of which, secondly, enforcing rules on app updates should not be done the same way as on new apps: blocking an app update must be balanced against the drawbacks, namely leaving a buggy, out-of-date version available on the iOS App Store; this goes especially if that previous version was already violating the rule in question (but on the other hand, they do need to be able to enforce the rules in some way even if previous app versions violating these rules were accepted, as otherwise rules would quickly become unenforceable). Third, the detailed reasoning of the rejection (with references to the relevant rules) will have to be provided to the developer, and app review decisions can only be overturned by a proper appeals process attacking this reasoning. Fourth, the person arguing against an app must be different from the person making the decision, and the app developer must be able to provide counterarguments. Fifth, for these violations that directly concern users, there has to be a way for these users to complain about such a violation so as to avoid inconsistent and unfair application of the rules (Ninjawords, anyone?). Etc. In short, at least a proper judicial process based on Rules and a proper process to come up with these rules.

All of this might seem outlandish for a company to implement: to the best of my knowledge, this has never been put in place by a private entity before. But as long as Apple has these claims to try and dictate large aspects of which features apps should and should not provide to users, I see no way they can sustainably avoid such a separation of powers given how large and incoherent in this regard Apple has become; and this is even if they were allow iOS apps outside the iOS App Store and give up on Mac App Store exclusive APIs (e.g. iCloud), as the iOS App Store and Mac App Store have become too important for them to avoid such a rationalization. Look, I’m not asking for anything like a full due process or enforced independence of judges. No one’s liberty (or, God forbid, life) is at stake here. But the livelihood of developers and the credibility of the iOS platform certainly are. Apple has too many responsibilities and has grown too much to keep acting like an inconsequential teenager. Apple is all grown up, and it needs to act like it.

Did Apple just cargo cult the iPhone platform?

This post is, in fact, not quite like the others. It is a parody of Coding Horror I wrote for parody week, so take it with a big grain of salt…

In The iPhone Software Revolution, I proclaimed that the iPhone was the product Apple was born to make:

But a cell phone? It’s a closed ecosystem, by definition, running on a proprietary network. By a status quo of incompetent megacorporations who wouldn’t know user friendliness or good design if it ran up behind them and bit them in the rear end of their expensive, tailored suits. All those things that bugged me about Apple’s computers are utter non-issues in the phone market. Proprietary handset? So is every other handset. Locked in to a single vendor? Everyone signs a multi-year contract. One company controlling your entire experience? That’s how it’s always been done. Nokia, Sony/Ericsson, Microsoft, RIM — these guys clearly had no idea what they were in for when Apple set their sights on the cell phone market — a market that is a nearly perfect match to Apple’s strengths.

Apple was born to make a kick-ass phone. And with the lead they have, I predict they will dominate the market for years to come.

But never mind the fact a similar reasoning could have been made of the Macintosh when it came out. What bothers me today is the realization Apple might have handled the opening of the iPhone platform like a cargo cult:

The term “cargo cult” has been used metaphorically to describe an attempt to recreate successful outcomes by replicating circumstances associated with those outcomes, although those circumstances are either unrelated to the causes of outcomes or insufficient to produce them by themselves. In the former case, this is an instance of the post hoc ergo propter hoc fallacy.

cargo cult phone

cargo cult phone by dret, on Flickr; used under the terms of the Creative Commons CC BY-SA 2.0 license

By which I mean that Apple decided they needed to open the iPhone as a development platform, but I wonder to which extent they then did so by giving it the trappings of a platform more than the reality of a platform: third parties can sell their apps for running on it, right? So it must be a platform, right? Well… And I don’t mean the APIs are the problem either, it’s more like… everything else:

  • Apple has a very restrictive idea of what kind of use cases third parties are allowed to provide solutions to: everything that does not fit their idea of an app is rejected, or is impossible. For instance, installing third-party keyboards is not possible on iPhone:

    But sometimes, an Apple product’s feature lands at the wrong side of the line that divides “simple” from “stripped down.” The iPhone keyboard is stripped-down.

    If you don’t like how Android’s stock keyboard behaves, you can dig into Settings and change it. If you still don’t like it, you can install a third-party alternative. And if you think it’s fine as-is, then you won’t be distracted by the options. The customization panel is inside Settings, and the alternatives are over in the Google Play store.

    This? It’s from Andy Ihnatko, in an article in which he explains why he switched from iPhone to Android. Andy. Ihnatko. When Mac users of 25 years start switching away from the iPhone, I’d be very worried if I were in Cupertino.

  • Even for these use cases third-parties are allowed to provide solutions to, they are quite restricted: when Apple added support for multitasking, in iOS 4, they more or less proclaimed they had covered for every desirable multitasking scenario, and have not added any since. This feels a tad preposterous to me that there would have been no need for even a single new multitasking scenario in the two years since.

  • Even when third parties can sell their wares, they do so at the pleasure of the king. Apple seems to consider iPhone developers to be contractors/authors developing solely for Apple purposes. And paid by commission. Without any advance. And without any assurance when they begin developing that their app will be accepted in the end.

  • Apple apps do not play by the same rules other apps do. They are not sandboxed, or not as much. They use private APIs off-limits to other apps. They get a pass on many iOS App Store restrictions. In short, Apple eats People Food, and gives its developers Dog Food:

    Microsoft has known about the Dogfood rule for at least twenty years. It’s been part of their culture for a whole generation now. You don’t eat People Food and give your developers Dog Food. Doing that is simply robbing your long-term platform value for short-term successes. Platforms are all about long-term thinking.

  • In the same spirit, Apple introduced iCloud, gave users the perception Apple did the hard work and that apps would merely have to opt in, sold it to developers as the best thing since sliced bread, then promptly went and not used it themselves in combination with er, the technology they have consistently recommended be used for persistent storage (while ostensibly supporting this combination), without giving the ability to audit synchronization issues either. And now it turns out, and people come to the realization, that iCloud Core Data syncing does not work. Shocker.

  • Apple even tried at some point to prohibit non-C programming languages for iPhone development, with a clear aim to ban a number of alternative development environments, not just Flash. But just like Apple cannot provide all the software to fulfill iPhone user needs, Apple cannot provide all the software to fulfill iPhone developer needs either. A platform is characterized not just an by ecosystem of apps, but also by an ecosystem of developer tooling and libraries behind the scenes. They ended up relenting on this, but if I were an iPhone developer, I would not be very reassured.

But wait, surely, that can’t be. Apple knows all about platforms and the value of platforms, right? VisiCalc, right? But that encouraged Apple to provide something that looks like a platform, rather than a platform. As for the iPhone not being Apple’s first platform, there is a school of thought that says Steve Jobs did not build platforms, except by accident; so according to this line of thought, the Apple II and the Mac became honest-to-God platforms not because of Apple, but in spite of Apple. And now for the first time we would get to see the kind of platform Apple creates when it actually calls the shots. It looks like a platform, sounds like a platform, has the taste of a platform, smells like a platform, walks like a duck platform… but the jury is still out on whether it is actually a platform.

There is a case to be made for reducing your dependencies. Apple clearly is not going to let anyone hold it back; but as incredibly skilled as the people working at Apple are, is “not being held back” going to be enough to keep up when Android, propelled by being a more complete and inclusive platform, will threaten to move past Apple?

Apple can still turn this around. Indeed, the issue lies not so much in these restrictions being present at first, than in so few of them having been lifted since then. The key, of course, will be in figuring out which ones they need to lift, and how to do so. And this will require Apple to reconsider the motions it does to bring cargo, regardless of the cargo these actions have brought, and instead focus on improving their limited understanding of what it is that actually makes a platform. In order to really bring in the cargo.

No, Apple does not pay developers

Enough is enough. For a few years already Apple has been boasting at WWDC and various other events (earning calls, etc.) about paying however billions dollars to developers; more recently, they have put this page where they proudly proclaim their contribution to the (U.S.) economy with, among others, the “App Economy” (they insist there: “And Apple has paid more than $4 billion in royalties to developers through the App Store”). If Apple has been criticized for this claim, I have not come across such criticism, which is a shame because Apple is not paying iOS or Mac application developers by any reasonable sense of the word “pay”. This is money that the developers have earned from users, and Apple is but an intermediary in this transaction.

All definitions and usages of the word “pay” (at least when one entity is subject, as opposed to say, an investment) that I could find imply either an opposite movement of goods or services, or an existing debt the payment exists to settle; as far a I can tell neither of these is the case: is Apple borrowing money from developers, then paying them back? Is Apple placing bulk orders of apps that it then redistributes? Is Apple commissioning the development of apps? No, no, and no, and quite the opposite in fact in the last case, as not only developers figure out themselves what to produce, but Apple has been known to reject the outcome, after it was done, in ways that have sometimes lacked transparency. In the context Apple uses it, “pay” implies there is a supplier/buyer business relationship, but Apple has none of the characteristics of a buyer: it is not the one that needs to be courted, it is not the one making the buying decision, it is not the one deciding how much to buy, it is not the one providing the money. The definition with which I could most charitably interpret their usage of “pay” would be “hand over or transfer the amount due of (a debt, wages, etc.) to someone” (New Oxford American Dictionary), in which case the amount due would be the remainder after commission that Apple owes developers, and transfers at the end of the month, which is not something particularly worthy to boast about.

Apple cannot even technically be said to be paying developers. The business and legal relationship iOS and Mac App Store developers have with Apple is, to sum it up, that Apple represents the developers in front of the customers, it acts as the developer agent (hence the agency model) and among other things collects customer payments on behalf of the developer and then forwards the payment to the developer (minus the commission Apple takes). The end user is the customer in this transaction, and she pays the seller, that is the developer; Apple does not. Apple merely transfers money that the developer earned from customers, nothing more. So it makes sense to say Apple transfers money to developers, amounting more than $4 billion; it doesn’t make sense to say Apple “pays” developers, even less so to speak of “royalties”.

Even worse yet, what kind of organization would boast about creating an “industry” of 210,000 unstable, underpaid jobs? Indeed, these jobs have no long term business visibility as any one of them could be the subject of a random Apple edict in the next few years; and clearly not everyone is earning a wage from the iOS App Store, as even if you assume all $4 billion have gone to the 210,000 U.S. developers, this works out at about $20,000 on average per such “job” since the introduction of the iPhone in 2007…

To me, this is symptomatic of a level of contempt towards third party developers not seen since the contempt of Nintendo towards third party developers at the heyday of the NES. This may or may not be anything new, but Apple should take care. iOS developers are a proud, independent bunch, and it is hard enough by itself to create apps that users will buy; telling them that it is Apple that pays them is not a good tactic. One day or another, Apple will meet its Playstation, and then everything will hinge on the attitude of developers.

Don’t get me wrong, Apple has made a lot of good things with iOS and enabled a lot of possibilities, and I am thankful for that. It’s just that “paying developers” is just not something Apple does; this is money from end users that developers have earned.

“translation layers”, externally sold content, and unsandboxed apps

So Apple ended up relenting on most of the requirements introduced at the same time as subscriptions. Apple does still require that apps not sell digital content in the app itself through means other than in-app purchases, or link to a place where this is done, however. I would say this is a reasonable way to provide an incentive for these products to be offered as in-app purchases, were it not first for the fact the agency model used for ebooks in particular (but I’m sure other kind of digital goods are affected) does not allow for 30% of the price to go to Apple, even if the price used in-app is 43% higher than the price out of the app, and second for the fact some catalogs (Amazon’s Kindle one, obviously, but it must be a pain for other actors too) cannot even be made to fit in Apple’s in-app database.

John Gruber thinks this is not Apple’s problem, but at the same time Apple has to exist in reality at some point. Besides, I don’t think Apple is entitled over the whole lifetime of an app to 30% of any purchase where the buying intent originated from the app. Regardless of whether you think it’s fair or not, competitors will eventually catch up in this area and offer better conditions to publishers, making it untenable for Apple to keep this requirement. But it’s not fair either for Apple to shoulder for free the cost of screening, listing, hosting, etc. these “free” clients that in fact enable a lot of business. Maybe apps could be required to ensure the first 10$ of purchases made in the app can be paid only using tokens bought through in-app purchase (thus avoiding the issue of exposing all SKUs to Apple), then only could they directly take users’ money.

But what this edict has done anyway—besides making the Kobo, Kindle, etc. apps quite inscrutable by forcing them to remove links to their respective stores—is hurt Apple’s credibility with respect to developer announcements. Last year they prohibited Flash “translation layers”, and this prohibition had already been in application (to the extent that it could be enforced, anyway) for a few months when they relented on it. This year they dictated these rules for apps selling digital content, rejecting new apps for breaking them before these rules were even known, with existing apps having until the end of June to comply, only for Apple to significantly relax these rules at the beginning of June (and leave until the end of July to comply). This means that in both cases developers were actually better off doing nothing and waiting to see what Apple would actually end up enforcing. I was about to wonder how many Mac developers were actually scrambling to implement sandboxing, supposed to be mandatory in the Mac App Store by November, but it turns out Apple may have jumped the gun at the very least here too, as they just extended the deadline to March. In the future, Apple may claim that they warned developers of such things in advance but the truth is most of the stuff they warned about did not come to pass in the way they warned it would, so why should developers heed these “warnings”?