Avec Android 6.0, Google rend obligatoire le chiffrement intégral du stockage sur les nouveaux appareils qui en sont capables. Pour le constructeur, cela signifie tout terminal délivrant une puissance suffisante, afin que l’activation du processus ne provoque pas de ralentissement perceptible par l’utilisateur.
Quand Android 5.0 est sorti, le chiffrement intégral du stockage était déjà sur la table. On se rappelle d’ailleurs qu’entre l’annonce de Google et le renforcement du chiffrement dans iOS 8, le directeur du FBI, James Comey, s’était largement ému de ce virage : « Ce qui m’ennuie avec tout ceci est que des entreprises fassent expressément la promotion de quelque chose qui permettra aux gens de se placer hors de portée de la loi ». Depuis, le chemin s’est dégagé, la Maison Blanche ayant officiellement renoncé à affaiblir le chiffrement.
Chiffrement par défaut pour les nouveaux appareils s'ils ont assez de puissance
On ne sait pas si cette décision a joué, mais Google revient à la charge sur le chiffrement intégral des données dans la dernière version de son document « Compatibility Definition », daté du 16 octobre, et à destination des constructeurs équipant leurs terminaux du système mobile. Page 64, on trouve un chapitre particulièrement intéressant : si un appareil est capable de réaliser du chiffrement AES d’au moins 128 bits au rythme de 50 Mio/s (mébioctets par seconde), le chiffrement intégral doit obligatoirement être activé.
Plusieurs points sont à souligner. D’une part, cela ne concerne que les nouveaux appareils qui seront directement commercialisés avec Android 6.0. Pour rappel, le Nexus 6 lancé l’année dernière possédait bien un chiffrement activé par défaut. Il est donc logique de penser que les nouveaux modèles 5X et 6P l’ont eux aussi. D’autre part, la précision de performances minimales renvoie au demi-tour fait par Google sur Android 5.0, quand la puissance de calcul est devenu un problème réel. Le chiffrement de toutes les données en continu est en effet une opération gourmande, et certains appareils montraient clairement leurs limites, comme le montraient en mars dernier des tests réalisés par AnandTech et Ars Technica. Enfin, par chiffrement intégral, Google entend plus précisément les dossiers /data et /sdcard, tous ceux concentrant les données de l’utilisateur.
Personne ne doit posséder la clé de chiffrement
Enfin, et c’est un point crucial, le document précise bien que la clé de chiffrement ne doit jamais être donnée à l’utilisateur. Elle sera liée au mécanisme de déverrouillage de l’appareil et elle-même chiffrée via AES par un algorithme de « slow stretching » tel que PBKDF2 (pour rendre le mot de passe ou la séquence plus résistante aux attaques par force brute). En d’autres termes, si l’utilisateur a un trou de mémoire, la seule solution sera une réinitialisation complète de son appareil et donc la perte des données qui y seront stockées (si elles n’ont pas été sauvegardées ailleurs évidemment).
Les acheteurs de ces nouveaux portables ont donc intérêt à être informés des « risques ». Quant à ceux qui ont déjà un smartphone puissant, la question mérite d’être posée. Le chiffrement intégral permet de protéger efficacement les données en cas de perte ou de vol de l’appareil. Reste à voir si son activation provoque une chute visible des performances et/ou si cette sécurité supplémentaire vaut le risque de pertes des données en cas d’oubli du code de déverrouillage, quel qu’il soit.
On signalera quand même que si cette décision est importante, elle ne change rien pour l'écrasante majorité des smartphones actuellement en circulation. Il s'agit d'un souci récurrent sur le parc Android, comme on a pu le voir avec les failles Stagefright.
Commentaires (87)
#1
Si c’était “illégal” jusqu’à maintenant, pourquoi la Surface 2 le fait depuis le début et que c’est dans Windows 10 Mobile ?
#2
Je n’ai peut être pas tout à fait compris, mais ce qui me gêne, c’est que l’utilisateur ne puisse pas gérer ses propres clefs. De plus qu’est-ce qui nous dit que ces clefs ne sont pas envoyées à Google ? Bref à moins d’information complémentaire sur le sujet, je me montre méfiant quant à l’efficacité de ce chiffrage des données. Sachant que la NSA est soupçonnée de pouvoir déchiffrer de vastes quantités de connexions chiffrées (source :http://thehackernews.com/2015/10/nsa-crack-encryption.html )
#3
J’ai pas vu de différence quand j’avais testé ça l’année dernière sur un Nexus 5.
Sinon dans ce même document de référence il y un autre passage important (point 9.1 Permissions) :
Les OEM ne pourront plus donner des autorisations à leurs apps pré-installé (ouais les bloatwares) et ils devront demander à l’utilisateur, via la fenêtre de dialogue qu’on connait maintenant, s’il veut donner tel ou tel autorisation.
C’est dans les pré-requis non négociable du document.
Si Samsung, LG, ou autres veut remplacer par exemple l’application de dialer, l’utilisateur devra au premier lancement lui dire qu’il veut bien donner l’accès à ses contacts et à la fonction téléphone, sinon le constructeur ne pourra pas installer l’application.
C’est une bonne nouvelle pour les futurs acheteurs d’Androidphone autres que Nexus.
#4
Je trouve que c’est une très mauvaise idée de forcer le chiffrement intégral (carte sd y compris).
" />
Pour mon cas, je l’avais fait et le natel est tombé en panne. J’ai perdu toute les données de la carte SD car impossible à récupérer …
#5
Tu ne fais jamais de sauvegarde Nioniotte?
Par contre si on n’a pas la clef…
#6
Heu. Y a les photos qui étaient sauvegardée chez G.
" />
#7
J’espère que le chiffrement de la carte SD est optionnel. On fait comment pour partager une carde SD avec quelqu’un d’autre sinon ? Comme le dit Nioniotte, si le tel tombe en panne, on aurait l’air fin…
#8
Mais personne n’a jamais dit que c’était illégal
#9
#10
Qu’est-ce qui te le dit ? C’est dans le code open source d’Android, que des experts en sécurité passent leur temps à lire pour essayer de trouver des failles.
Que l’utilisateur ne puisse pas gérer ses propres clés, c’est un peu dommage, mais c’est aussi une garantie de sécurité supplémentaire.
Et la NSA peut déchiffrer de grosses quantités de données en exploitant les failles des chiffrements “faibles” qui sont utilisés encore sur beaucoup de sites. Je ne pense pas qu’ils aient accès ni même le besoin d’avoir les clés de chiffrement de tes données sur ton téléphone.
Pour rappel le chiffrement local n’est utile qu’en cas de vol du téléphone verrouillé ou éteint. Si le téléphone est allumé au moment du vol, les données sont déjà déchiffrées. S’il est verrouillé, il n’est normalement pas possible d’y accéder. Mais elles restent déchiffrées.
#11
Je ne comprends pas que ce ne soit toujours pas la norme sous Android.
Ca me parait tout de même vital de chiffrer ses données. Surtout sur un appareil qui peut être facilement perdu/volé.
#12
Tu m’as compris : “affaiblissement du chiffrement” pour être OK côté USA, donc ce que veut dire que soit le chiffrement était assez faible chez Microsoft, soit ils allait à l’encontre des directives américaines. On est proche d’une forme d’illégalité aux yeux des américains.
#13
ou alors le chiffrement de MS est bon, mais si la loi imposant l’affaiblissement du chiffrement était passée, Ms aurait été aussi impacté.
#14
Ils ont renoncé à mettre en place une loi qui allait en ce sens, dont ça n’a jamais été illégal.
#15
Non justement. Ça voulait dire qu’ils voulaient que le chiffrement “continue”, mais en mettant éventuellement en place des portes dérobées pour les forces de l’ordre. Lis le lien qui vient justement dans le passage de la Maison Blanche.
#16
Ok, bien compris.
#17
Et en parlant de sécurité sur Android, j’ai aussi vu passer cette news sur le capteur d’empreinte :
" />
http://www.engadget.com/2015/10/20/android-marshmallow-fingerprint-reader-requir…
qui indique que Google impose que la detection se passe en full hardware => au même niveau de sécurité qu’Apple grossièrement. Ce qui est une bonne chose
#18
#19
Chiffrement cosmétique car, boites américaine oblige, il y aura toujours des Backdoors pour ces messieurs des services pas si secrets que ça. L’espionnage est inscrit dans l’ADN des yankees.
#20
Reste à voir si son activation provoque une chute visible des performances
Quid de l’impact autonomie ?
#21
Quelle proportion de gens font des sauvegardes de leur téléphone ?
#22
#23
tu confonds toujours projet open source et projet libre ?
" />
" />
AOSP est un projet Open Source. Ce n’est pas un projet libre.
Android a une base open source sur lequel se rajoute plein de paquet/drivers/outils qui ne sont ni libre ni open source. Et ça a toujours été le cas …
De toute façon si la backdoor se situe dans le firmware de la puce radio, quel que soit l’OS au dessus il n’y aura rien à faire …
Mais bon de toute façon on peut dire qu’une chose : Android n’est “pas pire” que iOS / Windows sur ce point
#24
Bonne nouvelle que ça ne soit pas les services Google qui gèrent le chiffrement, mais la base “open source” d’Android AOSP
" />
#25
Une fois le téléphone déverrouillé, qu’est ce qui empêche les services Google Play (ou tout autre service) d’envoyer les clés où bon lui semble ?
#26
Attend, d’un coté on me dit que la NSA a tout pouvoir ils installent des backdoor partout, et de l’autre, il faut que ça soit Google qui upload ta clé ?
" />
Ils l’envoient en zip par mail toutes les clés de chiffrement à la NSA ?
#27
Je ne suis pas certain que ta question soit pertinente. A partir du moment où tu installes quelque chose sur ton téléphone qui a accès à tes données (dont les Google services), il faut que tu lui fasses confiance. Le chiffrement n’y change rien, ni en bien, ni en mal.
Dit autrement, si les Google services ne sont pas dignes de confiance, qu’ils transmettent la clé de chiffrement ou directement les données, pour toi, c’est du pareil au même. Le chiffrement ne te protègerait pas des états pour lesquels Google travaillerait, mais serait toujours bon à prendre contre les voleurs à la tire.
Si tu veux te protéger de façon fiable contre les états, il faut que tu utilise uniquement des composants sur lesquels tu as un contrôle ou une confiance totale, aussi bien hardware que software (bon courage!)
#28
#29
Je n’ai juste plus confiance en cette entreprise au vu de tout ce qu’elle récupère sur ses utilisateurs. D’ailleurs lors du flash de ma prochaine rom je n’installerai plus les Google Apps dans mon téléphone, j’ai trouvé des alternatives à la plupart de mes applications disponibles sur Google Play.
Dites-vous bien que si ça a été autorisé par le gouvernement US, c’est qu’ils ont les moyens de passer outre le chiffrage.
Après, en cas de vol, le chiffrage des données est bienvenu, c’est clairement une avancée. Si c’est pour ne pas se faire espionner par les gouvernements par contre, là ça me fait rigoler.
#30
Oui tu as raison, c’est plus ou moins ce que je dis dans mon précédent message. :-)
#31
#32
Le cas de l’OHA est un cas particulier. Ils ont le droit de forker, (et ne s’en privent pas), mais doivent juste assurer la compatibilité pour avoir le droit de dire que leur OS est un Android.
" />
Et dieu sait que Samsung ne s’en est pas privé pour le support du stylet ou du capteur d’empreinte (en faisant de la merde, mais bon, c’est Samsung)
Les OEM font ce qu’ils veulent, mais si tu ne fais pas un OS compatible avec l’OHA, tu sors de l’OHA, c’est tout.
Tout comme Linux est projet Libre et Open Source, mais pour pouvoir se nomer “POSIX” il y a une norme.
AOSP est à 100% Open Source. OHA est un club fermé avec des régles. C’est si compliqué ?
#33
Alors retire ta puce radio aussi parce que tu n’as aucune raison de faire confiance à Qualcomm (ou autre) non plus.
#34
#35
plus confiance en Google mais a quand même un smartphone Android même si c’est une ROM venant de x ou y, il reste toujours des petites choses de Google donc …
#36
Tu as mieux ? Un OS complémentent libre de tout code fermé dont on ne peut pas avoir confiance ?
#37
Doucement!^^ il ne disait pas ce que lui pense mais plutôt se moquais de ce que dis JCD… ^^
#38
Je plussoie .
Ils voulaient juste l’accès à la porte de la bonne ;)
#39
non et il n’y a pas en stock, puis comme tu as dit dans un autre commentaire il faut aussi voir pour la puce radio la puce truc la puce chose …. tout le smartphone quoi 
" />
Mais bon le coup de dire j’ai plus confiance en X et avoir un OS de X à la base …
#40
Et ? Parce que c’est rigolo, rigolo de se moquer, mais est ce qu’il a mieux ? C’est une vraie question … Est ce qu’on peut faire confiance en Firefox OS qui est lié aux mêmes contraintes que Google niveau NSA ? Tizen ? …
#41
#42
#43
Les données sont chiffrés sur la mêmoire et sur la carte SD.
" />)
Il n’y a qu’en ram qu’il y a des données déchiffrés. Donc si on te vole ton tél et qu’il est locké, alors tout ce que peut récupérer un voleur c’est les données “actuellement en RAM” (et en téhorie la clé de déchiffrement ne devrait pas rester en RAM
SI c’est bien fait, tant qu’il est délocké la clé de déchiffrement est en ram, et dés qu’il se lock la clé est vidée, en attente du prochaine délockage.
#44
#45
Bah il dis pas qu’il y a mieu! il dis juste que c’est débile de dire : “ je n’ai pas confiance en google” puis de dire “ j’ai un android”
" />
" />
Si on a pas confiance en google ben on prend pas google!^^ sur ebay il y a des 3310
Après pour moi les gens ne serons jamais content… Google ne chiffre pas, c’est pour facilité le taff de la nsa.
Google chiffre, oui mais ils vont donné les clé à la nsa…
Du coup google dois faire quoi?
#46
Sans vouloir trop m’avancer sur le mécanisme que je ne connais pas, il semble très improbable que les données soient déchiffrée au déverrouillage du téléphone.
En pratique, il doit y avoir un mécanisme qui ‘reconstitue’ la clé à partir de ton code de déverrouillage, et cette clé est utilisée pour chiffrer/déchiffer à la volée les données que tu lis/écrit. Donc sur la carte SD, tout est chiffré, tout le temps.
Par contre, si tu te fais voler ton téléphone déverrouillé, le voleur peut accéder aux données chiffrées via le téléphone, à condition qu’il ne le laisse jamais se reverrouiller. Même s’il sort la carte SD à chaud, il ne pourra pas l’utiliser ailleurs.
#overgrillé
#47
#48
En théorie, avec une partie dédiée dans le CPU, l’iNPact n’est pas violent. Mais en effet, ça coûte quand même…
#49
Il aurait été judicieux de donner quelques pré-requis hardware pour se faire une idée de quels smartphone deja commercialisés sont compatibles. Dommage que Google ne le fasse pas même si une puissance équivalente à un N6 donne plus ou moins une idée.
#50
Le souci c’est que ça ne dépend pas de la “puissance brute”, mais de la présence d’une partie de chiffrement/déchiffrement dans le SOC.
Tu peux avoir des CPU bas de gamme qui auront la puissance suffisante quand un processeur haut de gamme de génération précédente en sera incapable.
#51
Il a peut-être une ROM AOSP sans les GApps hein.
#52
#53
Les GApps ne sont pas les seuls apport de google à android hein.
#54
C’est quand même magique : on crypte tout, ça fait bien pour le client… il suffit d’une faille de l’OS pour accéder au données…
#55
La contribution au code ok peut-être mais une ROM AOSP ne communique pas avec Google, c’est ce que je voulais dire vu que c’est le sujet de la conversation.
#56
C’est toujours mieux que rien! ;)
#57
#58
Plasma Mobile
" />
Bon ok, c’est pas encore au point. Et dans tous les cas, il restera la composante matérielle qui restera toujours difficile à maitriser.
#59
#60
Pour les appareils ne disposant pas de puce dédiée pour le traitement de AES oui le proco doit faire ça lui-même.
Bien pour ça que ce n’est OBLIGATOIRE et AUTOMATIQUE pour Android 6.0 QUE sur les appareils disposant de cette puce qui permet d’être totalement fluide.
Les autres doivent l’activer volontairement “à la main” et assument les conséquences en cas de ralentissements.
#61
Ah merde, il va falloir que je m’achète une batterie portable supplémentaire…..
#62
#63
Sous android, il faut absolument que le téléphone soit déverrouillé ( donc selon le mode de déverrouillage facial, biométrique, un dessin, un code etc…) pour accéder aux fichier en USB. Donc pas un code particulier, faut pas que le téléphone soit verrouillé.
en plus, le protocole de communication entre le téléphone et le PC est le MTP, c’est le CPU du téléphone qui gère ( donc il prend en compte le cryptage)
#64
Ils auront bien du mal à trouver des fabricants de SoC qui tolèrent de fournir les sources des drivers qu’ils utilisent… d’habitude, ils fournissent sous la forme de blob binaire, et uniquement aux OEM
#65
Merci
" />
#66
Il y a en gros trois zones non open source:
Les firmwares du matériel (typiquement la radio), là le doute subsiste
Les firmwares/drivers du système, qui sont parfois open source selon le matériel
Les applis Google, qui n’ont a priori pas de passe droit et donc pas de possibilité d’aller tripatouiller la clé de chiffrement (ce qu’on peut vérifier en lisant le code source d’Android).
Il est tout à fait imaginable de concevoir un téléphone dont on maîtrise à la fois les firmwares radio et la recompilation des drivers matériel, et donc sur lequel on peut garantir que Google ne peut pas lire les clés de chiffrement de la partition data.
#67
La partition chiffrée est montée sur un emplacement qui est lisible “en clair” au moment ou tu tapes la clé au démarrage du système. Après ça, le point de montage n’est jamais démonté et les données sont donc théoriquement lisibles par n’importe quelle appli, même si le téléphone est vérrouillé.
#68
Les Google services ont accès aux données de la mémoire, pas besoin de la clé de chiffrement pour ça.
La clé de chiffrement ne sert qu’à empêcher les voleurs de lire tes données s’ils ont un accès matériel au téléphone.
Les applis ne sont pas impactées par le chiffrement, une appli qui peut lire ta mémoire interne pourra toujours le faire une fois le chiffrement activé. Idem pour les play services donc.
#69
D’ailleurs c’était l’origine d’une faille, la clé de chiffrement étant stockée en RAM, il suffisait d’exploiter une propriété physique des puces de ram qui est qu’elles conservent les données même lorsqu’on coup le courant si la température est suffisamment basse.
Il suffisait de laisser son téléphone au congélateur, et d’installer un recovery bidouillé qui permettait de dumper la ram dès le boot pour récupérer la clé de chiffrement.
Je ne pense pas que cette faille soit corrigée…
#70
#71
J’ai Cyanogenmod 12.1 avec les pico GApps. Et j’envisage de passer à Cyanogenmod sans installer les GApps.
#72
Se moquer de moi, si tu veux, rire, c’est important, même si ça n’apporte pas grand chose au débat.
#73
Hors de question. Chiffrer des données c’est long, surtout pour les gens comme moi qui regardent beaucoup de films, et le risque de perte de données est assez élevé.
J’espère que CyanogenMod n’obligera pas les utilisateurs à faire ça aussi.
Pour ce qui est du verrouillage du téléphone, moi j’utilise Cerberus, je peux changer mon code à distance à tout moment en cas d’oubli ou de changement non désiré par un tiers.
#74
Je trouve consternant que sur Next Inpact, depuis quelques temps, on ne peut plus avoir d’opinion sans avoir quelqu’un qui, d’un ton condescendant, s’en moque et dise que c’est débile. Le simple fait de souligner que l’on ne fait plus confiance à telle chose ou que l’on pense quelque chose, et ça y est, des hordes s’abattent sur toi pour te montrer que ce que tu dis, c’est débile !
On peut très bien ne plus avoir confiance en Google et utiliser Android tout de même, et j’imagine que c’est le cas pour pas mal de gens. Mais bien entendu y’a quelqu’un pour dire que c’est débile. Mais quel choix a t’on ? Apple ? Tizen ? BlackBerry ? Des projets à moitié finis ?
Pour ma part j’utilise Cyanogenmod, qui reste la solution la moins pire de l’univers Android, sur un OnePlus One. J’ai installé les pico GApps pour avoir uniquement le Play Store, afin de pouvoir utiliser quelques applications achetées auparavant. Malgré tout, cela installe les services Google Play, plus de 300 services qui tournent en permanence sur le téléphone, et je n’aime pas ça, et en plus ça me bouffe la batterie.
Oui on ne peut pas avoir confiance dans les pilotes propriétaires du matériel de son téléphone, oui les applications ont accès aux données non chiffrées, merci de ne rien m’apprendre. Et donc ? Je fais quoi avec ça ? Je m’isole dans une grotte ? J’utilise un 3310 ? Ah les belles remarques ! Merci pour votre sagesse.
Franchement j’ai même plus envie de commenter sur Next Inpact tellement c’est systématique cet acharnement contre ceux qui osent partager leur avis ou posent des questions légitimes. Qu’il est loin l’esprit PCI. Alors qu’il serait tellement plus convivial de partager cordialement son avis sans descendre celui d’un autre.
#75
Le pb est pas tant ton manque de confiance pour tel ou tel solution. J’ai pas “confiance” en eu non plus. le pb est de croire que parce que tu as pas les app google tu risque rien de la part de google en ayant un android.
Je n’ai pas d’android, je suis chez la pomme, je me dis pas “oulala j’espère qu’ils revendent pas mes info à la NSA”. Je me dis ben aujourd’hui si je veut etre sur que la NSA n’ai pas mes info ou tout du moins n’ai pas la possibilité d’avoir mes info bah soit j’ai un 3310 soit je met pas mes info dans mon tel…
Quand a Cyanogenmod les dernier écho que j’ai eut, depuis 1⁄2 ans sont très loin d’etre bon et assez loin de ce que c’était à la base mais je me suis pas penché plus que cela sur la question…
#76
Si je n’ai aucune application Google d’installée sur mon Cyanogenmod, je ne vois pas trop ce que je peux craindre de Google. Je sais par contre pertinemment que je ne suis pas à l’abri de l’espionnage et de la fuite de données personnelles, et n’ai jamais affirmé le contraire.
Quand à Cyanogenmod, tu confonds peut être avec Cyanogen OS, l’OS commercial de la société Cyanogen. Cyanogenmod est open source et fourni sans aucune application Google de base.
Beaucoup de matériels n’ont pas de pilote open source, donc bien souvent dans les distributions dédiées à un appareil particulier on inclut des blobs propriétaires dont on peut se questionner sur ce qu’ils font réellement. C’est cela, ou par exemple accepter de ne plus avoir de wifi.
Les opérateurs de téléphonie sont également autant d’yeux tournés vers votre appareil.
Le fait est, que l’on ne peut pas y faire grand chose dès lors que l’on possède un smartphone. La confiance est perdue, mais l’usage quasi-obligatoire.
#77
#78
Curieuse image d’illustration, en anglais le terme safety ne désigne pas la sécurité au sens ou on l’entend, et encore moins la sécurité informatique… :)
#79
Le constructeur doit activer le chiffrement par défaut, mais est-ce que l’utilisateur final a l’option pour le désactiver ?
Au pire, peut-il faire un factory reste et désactiver le chiffrement ?
Merci.
#80
#81
C.f lien que j’ai donné dans le post juste avant.
" />
ici
#82
Ca veut dire qu’on ne pourra pas récupérer nos photos en copiant sur carte sd ?
#83
Personne ne doit posséder la clé de chiffrement (..) le document précise bien que la clé de chiffrement ne doit jamais être donnée à l’utilisateur
Ok, l utilisateur n a pas la clef, mais est elle stockée qque part chez Google?
Si oui, le “Personne” est trompeur!
En comparaison, chez MS, un ordi ou tablette entièrement crypté sous BitLocker a une clef qu on peut récuperer sur son compte MS. Par contre, c est pas encore possible sous WP8.
Mais comme dit plus haut, le chiffrage ne protège que du vol physique, en aucun cas d un piratage ou action NSA like…
#84
Google n’a pas la clé vu qu’elle est stockée chiffrée (AES) sur le téléphone à l’aide du mot de passe de déverrouillage. Quand bien même Google aurait la clé chiffrée que ça ne lui servirait pas à grand chose non plus.
#85
J’ai un peu de mal à croire qu’une fois que le téléphone est locké, le déchiffrement est impossible. Sous Android, les applications peuvent lancer des services, qui peuvent effectuer un traitement quand le téléphone est locké, soit périodiquement (timer) soit en fonction d’un événement (réception d’un SMS de ta belle-mère). Ce serait étonnant que ces applications soient tout-à-coup bannies.
#86
Alors c’est moi qui me plante
" />
Mais en effet, ça serait le meilleur scénario … le souci restant toutes les taches de fond.
#87
On va dire que… peut-être … une appli lancée continue à pouvoir accéder au contenu, mais qu’il n’est pas possible de lancer une nouvelle appli.
" />
Enfin, tout ça pour dire qu’on ne sait pas le fin mot de l’histoire en fait.