gouttegd a écrit 1805 commentaires

Si je ne m'abuse, la valeur par défaut du noyau est 128

Dans la version que j’utilise actuellement (3.15.2), c’est bien 896, définie dans drivers/char/random.c :

#define OUTPUT_POOL_SHIFT   10
#define OUTPUT_POOL_WORDS   (1 << (OUTPUT_POOL_SHIFT-5))

static int random_write_wakeup_bits = 28 * OUTPUT_POOL_WORDS

Par curiosité, c'est quelle distribution ?

Slackware, mais elle ne touche pas à cette valeur.

je soupçonne que read_wakeup_threshold est configuré relativement haut aussi ?

Non, 64. Là encore, c’est la valeur par défaut du noyau.

Microsoft announced last year that it was moving its German headquarters to Munich. This move is planned to take place in 2016. […] Reiter was involved in the deal that precipitated the move and describes himself as a "Microsoft fan" […]

http://arstechnica.com/business/2014/08/linux-on-the-desktop-pioneer-munich-now-considering-a-switch-back-to-windows/

Ceci dit, ça ne me semblerait pas délirant que scdrand respecte cette constante […] Même si le seuil est relativement bas

Je trouve au contraire que le seuil est un peu trop haut.

Chez moi, il est à 896 (valeur par défaut, je n’y ai pas touché). Or d’après ce que j’ai constaté, il arrive très régulièrement que l’entropie disponible tombe légèrement en-deça, même si ça ne dure jamais très longtemps. En fait, en utilisation « normale » de la machine (i.e., même en l’absence de gros consommateurs d’entropie comme GnuPG), l’entropie disponible oscille constamment quelque part entre 800 et 1000, comme on le voit d’ailleurs sur le graphe inclus dans le journal.

Mais comme on le voit aussi, l’entropie disponible remonte toujours assez rapidement, donc déclencher une intervention de scdrand à chaque petite « excursion » en dessous du seuil de 896 me paraît exagéré.

Cela étant, utiliser la valeur de write_wakeup_treshold comme seuil d’intervention pourrait très bien être un comportement optionel (à la discrétion de l’utilisateur), je vais envisager ça.

Je sais bien que ce n’est pas possible, c’est pour ça que ce n’est pas adapté à la situation. Je préfère poller « manuellement » plutôt que de toucher un paramètre affectant le système entier.

Par ailleurs, même à l’intérieur du noyau, il n’y a pas de mécanisme prévu pour informer automatiquement un module que l’entropie disponible dans le pool tombe en-dessous d’un certain seuil

Correction, je viens de voir qu’un tel mécanisme existe et est même accessible depuis l’espace utilisateur. Il faut ouvrir /dev/random en écriture et utiliser poll(2) ou select(2) sur le descripteur de fichier, le noyau signalera alors au processus (par retour de poll ou select) dès que l’entropie disponible tombe en-deça du seuil défini dans /proc/sys/kernel/random/write_wakeup_treshold (896 par défaut, chez moi).

Ce qui est dommage, c’est que ce seuil, même s’il est modifiable, est défini pour tout le système, il n’est pas possible de le modifier pour un seul processus. Du coup je ne pense pas utiliser ce mécanisme, il ne me paraît pas approprié que scdrand modifie un paramètre system-wide pour son seul bénéfice.

C’est déjà (parfois) « intégré dans nos ordinateurs » :

• dans certains processeurs Intel (instruction RDRAND) ;
• sur certaines carte-mères ;
• dans les « Trusted Platform Modules » (TPM) ;
• sur des cartes PCI spécifiques, par exemple les cartes d’accélération SSL.

Le noyau Linux utilise automatiquement l’instruction RDRAND si elle est supportée par le processeur (dans ce cas c’est une des sources d’entropie alimentant les pools derrière /dev/random et /dev/urandom). S’il y a un RNG sur la carte mère ou dans le TPM, le noyau le met à disposition directe de l’espace utilisateur via /dev/hw_random, mais ne l’utilise pas lui-même.

Quant aux principes de fonctionnement des RNG matériels, tout ce que je sais, c’est que ça repose sur la mesure de phénomènes physiques imprévisibles (quantiques notamment). Si quelqu’un d’autre dans le coin est capable d’en dire plus…

En quelques mots, pourquoi je n’ai pas fait ni n’envisage de faire de scdrand un module noyau.

Vouloir faire ce que fait scdrand dans le noyau impliquerait, entre autres choses, de déplacer les pilotes de lecteurs de carte dans le noyau (actuellement, ils sont en espace utilisateur, gérés par le projet pcsc-lite notamment), ainsi que toute la logique de communication avec les cartes. C’est faisable, certes, mais c’est pas mal de boulot. Si je suis passé par scdaemon, c’est justement pour ne pas avoir à implémenter tout ce qu’il fait moi-même.

Ensuite, si c’est un module qui prend désormais en charge la communication avec les cartes à puce, ça veut dire que les programmes en espace utilisateur ne peuvent plus le faire directement. Tous les projets concernés par les cartes à puce (comme GnuPG et son programme scdaemon) devraient revoir complètement leur architecture pour utiliser une interface exportée par le noyau plutôt que d’utiliser l’API de pcsc-lite.

Ça fait de gros changements juste pour éviter à un programme d’interroger régulièrement l’état du pool d’entropie…

Par ailleurs, même à l’intérieur du noyau, il n’y a pas de mécanisme prévu pour informer automatiquement un module que l’entropie disponible dans le pool tombe en-dessous d’un certain seuil, ce serait encore une autre chose à changer.

Enfin, une considération un peu moins technique : la carte à puce appartient à un utilisateur donné, ce n’est pas un périphérique appartenant à l’ordinateur. J’estime que ce n’est pas au noyau de décider arbitrairement de solliciter ma carte quand bon lui semble.

Pour moi, un moyen de communication est acceptable s’il laisse à ses utilisateurs le choix de son prestataire de service et de son outil, sans que les choix d’un utilisateur ne soient contraignant pour les autres utilisateurs.

Par exemple, je peux choisir un téléphone Sagem (l’outil) et passer par Bouygues Telecom (le prestataire), ça ne m’empêche pas de contacter un abonné SFR qui a un téléphone Nokia, ni n’oblige ceux qui me veulent me contacter à faire les mêmes choix.

En pratique, ce n’est possible que si :
* il y a un protocole clairement défini et publié pour la communication entre l’utilisateur et son prestataire ;
* il y a un protocole clairement défini et publié (pas forcément le même) pour la communication entre les prestataires ;
* il n’y a pas de barrière arbitraire (non technique) entre les prestataires.

Parmi les moyens de communication listés dans le sondage, lesquels satisfont ce critère ?

• FB/G+/équivalent privateur : non. On peut éventuellement choisir l’outil (il y a d’autres clients que l’interface web), mais pas le prestataire de service.

• Twitter/équivalent privateur : non. Comme ci-dessus.

• Diaspora : oui.

• XMPP : oui.

• pump.io : oui.

• Skype/équivalent privateur : non.

• Retroshare : le choix du prestataire ne se pose pas ici, il n’y en a pas. À ma connaissance il n’y a qu’un seul client, mais a priori rien n’empêche qu’il y en ait d’autres.

• IRC : non. On peut choisir le client et le réseau, mais les différents réseaux ne sont pas connectés entre eux. (Cela dit le lien entre l’utilisateur et le prestataire est beaucoup moins fort qu’avec la plupart des autres moyens cités, on peut changer de réseau très facilement.)

• le courriel classique : oui.

• la poste/le téléphone : oui depuis l’ouverture à la concurrence.

• Friendica : oui.

• Bitmessage : comme pour Retroshare a priori.

• Tox/Newebe/Lorea/Twister/Elgg/seenthis : je passe, je ne connais pas ou trop peu.

• StatusNet/GNU Social : oui.

• pigeons/bouteilles à la mer : oui.

• Troubles dans la Force et hologrammes après le décès : probablement pas, apparemment le protocole est propriétaire vu que seuls les Jedi et les Sith peuvent l’utiliser.

Mais ce type de carte ne marche qu'avec GNUPG?

Non. Les cartes cryptographiques obéissent généralement au standard PKCS#15 de RSA Laboratories. N’importe qui peut écrire un programme interagissant avec une carte de ce genre.

La carte OpenPGP est une application spécialement conçue pour fonctionner avec GnuPG (ce sont les mêmes développeurs qui en sont à l’origine), mais à ma connaissance elle est aussi conforme au standard PKCS#15 et devrait donc pouvoir être utilisée avec tout programme supportant ce standard.

Inversement, GnuPG supporte aussi les cartes PKCS#15 standards et non pas seulement « sa » carte spécialisée.

Ça empêche pas de faire aussi un article séparé sur GNUPG si vous voulez, mais je ne voudrais pas que cela éclipse le sujet de ce type de carte, perso.

Je comprends, mais pour ma part mon expérience avec les smartcards cryptographiques se limite à la carte OpenPGP couplée à GnuPG…

pour les utilisations "routinières" dont tu parles (signer, déchiffrer, authentifier), s'il n'y avait pas la carte, les logiciels de cryptage (GnuPG en tête donc) tirerait profit de /dev/(u?)random, non?

Non. Quand GnuPG a besoin de nombres aléatoires, il va toujours les chercher dans /dev/(u)random, présence d’une smartcard ou pas. C’est justement pour ça qu’il faut un programme comme scdrand si on veut tirer profit du générateur de nombres aléatoires embarqués sur la carte.

L’utilité principale d’une smartcard cryptographique est de stocker des clefs privées, pas de générer des nombres aléatoires. Il se trouve qu’une carte de ce genre contient un générateur matériel de nombres aléatoires, pour deux raisons : pour pouvoir générer des clefs directement sur la carte, et pour pouvoir générer des « challenges » utilisés dans les protocoles d’authentification.

Donc finalement, ton programme ne pourrait-il pas tout simplement remplacer Scdaemon de manière transparente?

Non. scdaemon est le démon en charge de communiquer avec la smartcard. Il interagit directement avec le lecteur de carte, transmets les messages APDU à destination de la carte et reçoit les réponses. Il permet aux programmes voulant exploiter une smartcard (que ce soit GnuPG ou scdrand) de ne pas avoir à se soucier des pilotes de lecteurs de carte ni du protocole APDU, en exposant une API assez simple.

scdrand pourrait faire tout ça et remplacer complètement scdaemon, mais quel serait l’intérêt ? scdaemon fait très bien le job.

GnuPG ne communiquerait plus directement avec la carte, mais en cherchant de l'aléa dans les /dev/(u?)random

Comme dit ci-dessus, GnuPG va toujours chercher l’aléa dont il a besoin dans /dev/random, jamais sur la carte. Lorsque GnuPG communique avec la carte (ce qu’il ne fait jamais directement, mais par l’intermédiaire de scdaemon), ce n’est pas pour obtenir de l’aléa mais pour lui confier les opérations cryptographiques que seule la carte peut faire, c’est-à-dire les opérations qui nécessitent les clefs privées.

Ou alors la carte a d'autres fonctionnalités et son rôle n'est pas uniquement de produire de l'aléa rapidement. Y a un processeur dédié pour accélérer des calculs de crypto aussi, peut-être?

C’est presque ça, sauf que les calculs de crypto sont fait sur la carte non pas pour les accélérer (c’est peut-être plus rapide sur la carte, je n’ai pas vérifié mais ce n’est pas le but premier), mais pour protéger les clefs privées : en réalisant les opérations cryptographiques sur la carte, on évite d’avoir à faire sortir les clefs de la carte, même temporairement.

Si tu as envie de partir sur une dépêche collaborative, j'en suis. En fait je penserai même à une dépêche générale GnuPG, avec clefs, certifications, signatures, chiffrement, sous-clefs, et smartcard. Si ça te tente, vas-y, j'arrive.

Why not? OK, je vais commencer quelque chose dans mon coin (probablement ce week-end) et initier une dépêche avec.

De mon côté, je suis à la recherche d'une clé USB que je pourrai toujours avoir sur moi et contenant ma/mes clés privées. Auriez vous connaissance d'un tel dispositif ?

KernelConcepts fournit une version de la carte OpenPGP découpable au format ID-000 (format « carte SIM »). Combinée avec un lecteur spécialement adapté pour ce format de cartes, ça peut correspondre à ce que tu cherches.

je me demandais si le but est seulement d'améliorer la vitesse d'utilisation des logiciels qui utilisent /dev/random et /dev/urandom ou si cela en améliorait aussi la "qualité" d'aléatoire. De l'aléa de meilleur qualité que ce qu'il y a en général dans ces interfaces.

Je ne pense pas que ça en améliore la qualité.

Dans le meilleur des cas (si le générateur de nombres aléatoires de la carte est correct), logiquement la qualité est la même. Un bit d’entropie en provenance de la carte revient au même qu’un bit d’entropie en provenance des autres sources utilisées normalement par le noyau, c’est juste que la carte est capable d’en délivrer plus rapidement.

Dans le pire des cas (si le générateur de la carte est mauvais — ce que je suis incapable de déterminer, mais qui peut arriver), la qualité serait a priori réduite, mais l’effet devrait être mitigé par les traitements réalisés aussi bien en entrée qu’en sortie du pool.

À noter que dans le noyau Linux, c’est à celui qui ajoute de l’aléa dans le pool qu’il revient d’estimer quelle est l’entropie réellement ajoutée. Pour cette première version de scdrand, je suis parti du principe que le générateur de la carte est correct et produit bien des octets complètement aléatoires. En conséquence, scdrand estime qu’un octet en provenance de la carte = 8 bits d’entropie. Une évolution possible de scdrand serait de permettre à l’utilisateur de modifier ce comportement et d’estimer lui-même la « valeur » des octets générés par la carte.

Aussi quand tu crées une clé, pour reprendre ton exemple, la clé peut-elle être plus "sûre" avec du bon aléa? Y a-t-il une notion de qualité d'une clé, deux clés de la même taille peuvent-elles avoir intrinsèquement une sécurité différente?

Oui.

Une clef se doit d’être unique. L’unicité est normalement assurée par le fait de tirer la clef au hasard dans un très grand espace, la probabilité que deux personnes tirent la même clef étant virtuellement nulle. Mais si les clefs sont générés avec une entropie insuffisante, cette probabilité augmente, et avec elle le risque d’avoir des clefs dupliquées dans la nature. Ce risque n’est pas que théorique.

Les clefs RSA sont particulièrement vulnérables, car leur génération nécessite non pas un mais deux grands nombres premiers. Ces deux nombres sont supposés être uniques à chaque clef. Si, en raison d’un mauvais RNG, plusieurs clefs RSA partagent un même facteur, elles sont toutes trivialement cassables.

Sinon oui, comme le commentaire au dessus, je suis curieux de connaître l'utilité générale d'une telle carte, car je n'ai jamais eu affaire à quiconque qui en avait une. Comment ça s'utilise, etc.

Il y a l’air d’avoir du monde intéressé (je vois que le commentaire du dessus est à 10…), je vais voir si je peux écrire quelque chose là-dessus.

En tous cas, ton outil a quand même l'air extra et améliore grandement l'utilité existante de ces cartes en les rendant utile génériquement (transparent pour toute application qui utilise /dev/(u?)random et qui utilisera donc la carte indirectement sans le savoir). C'est génial.

Pour bien rendre à César ce qui lui appartient, l’idée géniale d’alimenter le pool d’entropie du noyau vient de l’auteur de TokenTools. Je n’ai écrit scdrand que parce qu’une utilisation simultanée de GnuPG (donc de scdaemon) et de TokenTools semble impossible.

Pour la sous-clef de signature, ça ne pose aucun problème particulier.

En revanche, il ne serait en effet plus possible de déchiffrer tout ce qui aurait été chiffré avec l’ancienne sous-clef de chiffrement — par exemple, d’anciens e-mails reçus que tu aurais gardé sous forme chiffrée, ou même des e-mails récents que l’on t’aurait envoyé entre le moment où tu perds l’usage de la carte et le moment où tu mets en circulation les nouvelles sous-clefs.

Impossible aussi de s’authentifier sur un serveur où la seule clef acceptée serait celle présente sur la carte.

L’implémentation actuelle ne permet pas un intervalle inférieur à la seconde (le code utilise sleep(3), il faudrait le remplacer par usleep(3) ou nanosleep(2) pour descendre en-deçà de la seconde).

Avec un poll toutes les secondes, un test fait à l’instant me donne :

# temps     entropy_avail
00:31:40    945
00:31:41    964
00:31:42    989
00:31:43    1002
00:31:44    955
00:31:45    961
00:31:46    985
00:31:47    1013
00:31:48    963
00:31:49    4
00:31:50    780
00:31:51    781
00:31:52    797
00:31:53    802
00:31:54    803
00:31:55    804

La génération de la clef est lancée à 00:31:49, l’entropie disponible chute immédiatement à 4. Une seconde plus tard, elle est déjà repassée au-dessus du seuil d’intervention.

Ne pourrait on pas utiliser ce programme pour générer de l'entropie par exemple depuis une simple webcam?

Ce programme, non, il n’utilise qu’une smartcard comme seule source d’aléa. Mais si tu veux réutiliser juste le bout de code qui s’occupe d’ajouter les données aléatoires au noyau (pour le combiner avec un code qui obtient des données en provenance d’une webcam), ne te prive pas, c’est libre. :) (Et le bout de code en question ne fait de toute façon que quelques lignes, en fait c’est essentiellement un appel à ioctl(2) sur un descripteur de fichier sur /dev/random.)

la première question que je me pose c'est sur la qualité de l'aléa généré par le RNG de la smartcard

C’est évidemment une bonne question, mais à laquelle je ne suis pas du tout qualifié pour répondre. Je ne sais ni comment fonctionne le RNG, ni s’il a été conçu avec soin, ni s’il n’a pas été dûment « backdooré » par la NSA — mais sur ce dernier point, j’ai personnellement un tout peu plus confiance dans le RNG d’une smartcard conçue par une société allemande (g10code, qui est aussi derrière GnuPG) que dans celui intégré par un fondeur américain dans ses processeurs.

Ce site est tout simplement magnifique, un bel exemple de ce que les standards du web permettent de faire actuellement

Un contre-exemple, tu veux dire ?

• Javascript désactivé → écran noir complet, même pas un message. La graceful degradation, l’accessibilité… c’est pour les tapettes.
• Sous Firefox 30, tout ce que j’ai c’est une sorte de barre de chargement (je suppose) qui ne va pas jusqu’au bout et un message « Move your cursor to explore »… Sauf que je peux bien faire ce que je veux sur la page, il ne se passe rien du tout.
• Sous Webkit, je peux aller un plus loin (et apprendre que ce site est une « expérience Chrome » — vous pouviez pas le dire plus tôt connards !), mais j’ai quand même l’impression de ne pas tout voir (certaines actions ne sont pas suivies d’effets).

Heureusement que c’est seulement une « expérience », parce que si c’est à ça que les sites de demain, respectueux des standards, interopérables, et accessibles, seront supposés ressembler, ben merde.

Pourquoi on passerait pas à un truc comme ça ?

Ça existe, c’est le DNS-based Authentication of Named Entities. Mais ce n’est ni répandu dans les domaines ni supporté nativement par les navigateurs (je n’en connais aucun qui supporte ça nativement — il y a une extension Firefox, et je suis en train de bidouiller un plugin pour Uzbl).

En plus, ça dépend de DNSSEC, qui lui aussi n’est ni largement répandu ni bien supporté par les clients.

Je crois quand même pas mal à ce système, même si au final je penche plutôt pour une cohabitation entre plusieurs méthodes d’authentification, et laisser le client utiliser celle(s) qu’il veut. Par exemple, sur ma machine j’ai quatre méthodes pour vérifier un certificat :

• le système PKIX (l’infrastructure actuelle basée sur des « autorités de certifications » jugées dignes de confiance par les navigateurs) ;
• Monkeysphere (validation par la toile de confiance OpenPGP) ;
• DANE ;
• le « suivi de certificat » (modèle « trust on first use », à la manière de SSH : on garde une trace du certificat associé à chaque hôte, et on vérifie à chaque nouvelle connexion que le certificat présenté est bien le même que celui précédemment associé à cet hôte).

J’accepte automatiquement un certificat s’il est validé par au moins une des méthodes sans être strictement invalidé par aucune autre.

Mais il est absurde de critiquer les masques jetables (il n’a jamais été aussi simple d’échanger des clés : je te passe une clé de 16G, on peut s’envoyer des mails pendant 5ans).

Tu proposes de générer 16 Go de masque jetable pour chacun de mes correspondants ? Qu’il faudra conserver aussi longtemps que nécessaire ? Qu’il faudra donc aussi sauvegarder ? Et il faudra s’assurer que ces N × 16 Go (où N est le nombre de correspondants) restent à l’abri des regards indiscrets pour toute la durée d’utilisation prévue ?

C’est peut-être « un milliard de fois plus simple que RSA et PGP », mais c’est un milliard de fois moins pratique à manipuler qu’une paire de clef RSA.

Parce que le signe dollar apparait comme prompt ne signifie pas forcément que le compte est root même si c'est une vieille habitude.

D’une part, non justement, le signe $ signifie habituellement que c’est un compte utilisateur normal, c’est # qui dénote typiquement le superutilisateur. Mais ce n’est qu’une habitude.

D’autre part, le fait de procéder à la compilation directement dans le répertoire /usr/src/linux-3.12.24 suppose que l’utilisateur a le droit d’écrire dans cette arborescence, privilège normalement réservé au superutilisateur. Et comme il n’y a de plus aucun changement d’identité entre les commandes de configuration/compilation et les commandes d’installation, il est logique de conclure que c’est bien toute l’opération que l’on est supposé faire sous l’identité du superutilisateur, peu importe quel est le symbole du prompt.

Tiens c'est drôle il y a le signe dollar partout. ;)

Oui, le signe $ qui dénote typiquement un utilisateur non-privilégié.

L’installation du noyau passe donc par un procédé standard :

$ cd /usr/src/linux-3.12.24
$ make menuconfig
$ make all
$ make modules_install
$ cp arch/x86/boot/bzImage /boot/vmlinuz
$ cp System.map /boot

Tout ceci est supposé être fait en tant que root ? Alors ce n’est pas le procédé standard. Il n’y a aucune raison de configurer et compiler le noyau sous l’identité du superutilisateur, et les développeurs du noyau le déconseillent formellement.

Extrait du README à la racine des sources du noyau :

To do the actual install, you have to be root, but none of the normal build should require that. Don’t take the name of root in vain.

Greg Kroah-Hartman en particulier insiste lourdement là-dessus, dans une page de « Linux Kernel in a Nutshell » que je me permets de citer largement (vu que la page en question est dans un PDF et que je ne peux donc pas y faire de lien direct) :

Do not configure or build your kernel with superuser permissions enabled!
[…]
Only the two or three commands it takes to install a new kernel should be done as the superuser.
There have been bugs in the kernel build process in the past, causing some special files in the /dev directory to be deleted if the user had superuser permissions while building the Linux kernel.¹
[…]
Do not do any kernel development under the /usr/src directory tree at all, but only in a local user directory where nothing bad can happen to the system.

¹ This took quite a while to fix, as none of the primary kernel developers build kernels as root, so they did not suffer from the bug. A number of weeks went by before it was finally determined that the act of building the kernel was the problem. A number of kernel developers half-jokingly suggested that the bug remain in, to help prevent anyone from building the kernel as root, but calmer heads prevailed and the bug in the build system was fixed.

Trop tard pour éditer, je voulais juste ajouter le lien vers la dernière spécification XFA.

Vous reprendrez bien un peu de XML, DOM, Javascript, XML Schema, XSL/Transform dans votre document PDF ?

Est-ce que ces formulaires utilisent des fonctionnalités que tous ces lecteurs PDF n'implémentent pas (encore) ? Auquel cas la « faute » est aux lecteurs PDF autres que Adobe.

Ce sont des formulaires « XFA » (XML Forms Architecture).

Un PDF contenant de tels formulaires est-il un PDF standard ? Question de point de vue : le standard PDF dit bien qu’un document PDF peut contenir un formulaire XFA et recommande aux lecteurs se voulant conformes au standard PDF d’en tenir compte (« conforming readers shall be diligent in their consideration of all content that can exist in a PDF document, including XML Forms Architecture content and Extensible Metadata Platform content »), mais il ne donne aucun détail et se contente de renvoyer à la spécification XFA, laquelle n’est pas standardisée.

Donc, oui, les lecteurs autres que Reader sont partiellement en « faute », dans le sens où ils pourraient supporter XFA (les spécifications sont publiées à défaut d’être standardisées, comme le furent les spécifications du format PDF lui-même avant leur normalisation).

Mais compte tenu du fait que les formulaires XFA sont extrêment peu supportés (seul Acrobat Reader les supporte pleinement, et encore uniquement dans ses versions « desktop » pour Windows et Mac OS X — les versions mobiles ne les supportent pas et ne les supporteront pas, c’est trop compliqué), générer des documents PDF utilisant ce genre de formulaires est quand même un gros pied de nez à l’interopérabilité. D’ailleurs, les formulaires XFA sont interdits dans la version PDF/A du standard, celle recommandée pour l’archivage électronique.

Mon impression est que les administrations générant ce genre de PDF ne se posent pas trop de questions et utilisent simplement les outils Adobe (Adobe LiveCycle), en se disant que « de toute façon c’est du PDF donc c’est standard ». Et je soupçonne les marketeux de Adobe de ne pas trop s’attarder sur le fait que ces outils produisent des documents dépendant d’extensions non standards.

un indicateur de batterie est présent en haut à droite de l'écran (cf photo ci-dessous)

Je ne sais pour le Glo et l’Aura, mais sur le Touch (offert en décembre 2011), cet indicateur de batterie n’est présent que sur l’écran que tu montres. Dès que tu sélectionnes un livre et passe en mode « lecture », il n’y a plus rien. Et comme en principe, tu ne reviens à cet écran qu’au moment de changer de livre…