lab-mi / deplacement-covid-19 Goto Github PK

Le bouton ne génére absolument rien.
iPhone 6
iOS 10.3.3
Safari

Erreur retournée au téléchargement dans firefox mobile: "Firefox ne peut pas télécharger ce type de fichier"

Alors que ça fonctionne bien sur Firefox sur un ordinateur.

Le problème a déjà été brièvement reporté dans le commentaire suivant:

Originally posted by @guillemcanal in #2 (comment)

Pour évaluer la satisfaction usager

• recueillir les commentaires/ suggestions
  et intégrer les résultats à l'observatoire des services numériques

Bonsoir !

Le nom du repository semble invalide, et mentionne le codiv-19 (coDiV)

Certes, 2019 n'est pas encore fini, mais espérons que le covid sera suffisant ;)

Le package.json semble hésiter entre les deux choix et mentionne coDiv et coVid :

Le README quant à lui fait aussi référence au codiv-19.

(le repository peut être renommé depuis les settings, Github gérera automatiquement la redirection pour tout ceux qui ont encore l'ancien lien)

<label for="field-heure">Heure de sortie</label>

devrait être

<label for="field-heuresortie">Heure de sortie</label>

Bonsoir,
comme des checkboxes sont utilisées et comme cela vous a déjà été signalé, vous avez ajouté dans l'intitulé qu'il était possible de choisir plusieurs motifs de sortie. Il aurait fallu et il faudrait plutôt adapter le code pour un seul check possible et donc un seul motif...

As mentioned on this official article, we can present an english document.

With the same idea, this form should also be translate in english for english users.

J'ai signalé ce bug sur twitter, monsieur Freyssinet disait qu'il allait le prendre en compte. Mais je vois que ça n'a toujours pas été fait 24h plus tard. Alors j'ouvre ce ticket.

Il semble qu'il y ai un bout de code mort, qui devait servir à pré-remplir le formulaire en cas de re-visite. Sauf qu'il n'a pas été complètement décablé. À la génération du pdf, le formulaire complet est stocké dans le local storage du navigateur, et n'est jamais effacé.
Il ne sera pas non plus effacé si l'utilisateur efface tous ses cookies (il faut effacer toutes les données de site pour virer le localStorage).

Je considère ce bug comme grave. Si quelqu'un utilise le générateur sur un ordinateur qui n'est pas le sien, ou se fait voler son terminal, une personne malveillante pourrait y trouver des données nécessaires et suffisantes pour une usurpation d'identité (nom, prénom, date et ville de naissance).

Il faut absolument arrêter d'enregistrer ces données (ou alors demander l'accord, comme proposé ici : #6 ). De plus, il faut absolument effacer les données présente si quelqu'un retourne sur la page. Et il faut communiquer pour prévenir les utilisateurs.
Plus vous attendez, plus vous exposez de gens.

J'ajoute que vous n'êtes pas à l'abris que quelqu'un de malveillant chez Incapsula ne récupère ces données (puisque je crois que vous incluez du javascript leur appartenant).

Il semblerait que l'attribut required des inputs ne fonctionne pas. Aussi, il serait peut-être plus judicieux que generate-btn soit cliquable uniquement lorsque tous les champs sont renseignés.

Le QR code est du texte en clair. Il contient des données très sensibles (nom, prénom, date de naissance et ville de naissance). Ces données sont suffisantes pour une usurpation d'identité.

Dans la mesure où ce QR code n'est censé être lu que par un logiciel spécial à disposition des forces de l'ordre, il serait judicieux de chiffrer les données. Pour que des personnes malveillantes ne puissent pas récupérer facilement les données (photo volée du QR code, ou faux contrôle policier).

Les pictogrammes contenus dans les <span class="validity"></span> sont des contenus CSS et peuvent être exposés aux TA dans certains cas. Or l'invalidité des champs est communiquée autrement, il faut donc les rendre "invisibles" aux lecteurs d'écran avec un attribut aria-hidden="true".
Par ex.
<span class="validity"></span>
devient
<span class="validity" aria-hidden="true"></span>

Remarque : l'apparition de ces signes reste hasardeuse, dans Chrome j'ai des "✖" au lieu des croix et d'un point de vue purement UX, mettre des croix alors que l'utilisateur n'a pas encore saisi le moindre caractère dans le champ peut créer de la confusion chez certaines personnes.
L'apparition d'une coche (check) quand le champ a été rempli est une petite valeur ajoutée de réassurance mais qui n'a pas nécessairement besoin d'être exposée aux TA, selon moi vu qu'il y aura un control lors de la soumission du formulaire. L'attribut aria-hidden="true" sur le <span>reste donc pertinent.

L'issue #6 proposait de ne sauvegarder le profil que lorsque l'utilisateur·rice le demandait, alors que #19 indiquait que le stockage local devait être effacé. La release 1.1 a précisé l'objectif de l'utilisation du localStorage : celui-ci n'est pas utilisé comme sauvegarde des données en local pour un pré-remplissage futur mais uniquement pour la génération du pdf. Dès la génération effectuée, les données sont supprimées.

Le principal bénéfice à l'utilisation du localStorage est la persistance des données entre les sessions. Or ici, les données sont sauvegardées et supprimées au sein d'un même script. L'utilisation de cette technologie est donc inadéquat.

Les simples variables JavaScript ou l'utilisation direct du DOM serait à privilégier pour éviter toute sauvegarde malencontreuse des données sur le navigateur de l'utilisateur·rice.

Je pense qu'il y aurait moyen d'améliorer le comportement du masque sur la date de naissance, on ne peut pas effacer facilement les données.

Il existe déjà des outils bien conçus pour ce genre de chose, peut-être qu'on pourrait se servir de Inputmask par exemple ?

Il y a déjà un <header> et un <footer> dans la page ; il est souhaitable qu’un <main> soit également présent et contiennent tout ce qui se trouve entre ces 2 régions.
Ces landmarks (régions) peuvent être utiles à certains utilisateurs de lecteur d’écran qui souhaitent naviguer rapidement dans la page.
Pour des raisons de compatibilités il est préférable de leur ajouter leur landmark role ARIA respectif comme ce sont des enfants directs de <body>.

Suggestion :

<header class="wrapper">...</header>
...
<footer class="main-footer">...</footer>

deviendrait

<header role="banner" class="wrapper">...</header>
<main role="main">...</main>
<footer role="contentinfo" class="main-footer">...</footer>

Quand un champ est en erreur (format de saisie incorrect ou absence de donnée pour un champ obligatoire), son état doit être exposé aux TA (technologies d'assistance).
Pour cela deux options, soit :

• ajouter dynamiquement l'attribut aria-invalid="true" sur les <input> en erreur après soumission du formulaire et avant que le focus ne soit déplacé sur le 1er champ en erreur,
• ou mettre par défaut l'attribut aria-invalid="false" sur les champs et modifier la valeur à "true" quand c'est pertinent, après soumission du formulaire et avant que le focus ne soit déplacé sur le 1er champ en erreur.

En venant sur le formulaire par un chemin normal (ie: en venant de https://www.interieur.gouv.fr/Actualites/L-actu-du-Ministere/Attestation-de-deplacement-derogatoire-et-justificatif-de-deplacement-professionnel ), je me retrouve avec plusieurs cookies de session.
Je tronque volontairement leurs noms :

Même si j'arrive directement sur la page, j'ai 3 cookies (___utmvc, incap_ses_xxxxxx, visid_incap_xxxx)
Or, sur la page de génération du formulaire, ils ne sont clairement pas nécessaire au service (puisqu'ils ne sont pas lu par le code disponible dans ce dépot). Il faudrait donc un bandeau RGPD avec une demande d'autorisation pour les cookies. Ou alors les retirer sur cette page.

Il est possible de rendre le lien vers la liste des établissements qui restent ouverts plus explicite en sortant les parenthèses du lien, et en indiquant la page vers laquelle il dirige les utilisateurs plutôt que le site.
Par ex. « liste des commerces et établissements qui restent ouverts ».

De plus, comme c’est un lien qui ouvre une nouvelle fenêtre, il faut le signaler comme cela a été fait dans les liens du footer, avec un attribut title.

Suggestion :
<label>... <a href="https://www.service-public.fr/particuliers/actualites/A13921" target="_blank">(liste sur gouvernement.fr)</a>.</label>
deviendrait
<label>... (<a href="https://www.service-public.fr/particuliers/actualites/A13921" title="Liste des commerces et établissements qui restent ouverts - nouvelle page" target="_blank">liste des commerces et établissements qui restent ouverts</a>).</label>

Bonjour,

pour ceux qui souhaiteraient envoyer directement vers télégram le PDF j'ai faits cette modification dans le certification.js

Ajouter une fonction pour l'envoi (en renseignant avec les infos de votre bot) :

function sendBotTelegram(blobPDF){
    var token="VotreToken_ICI";
    var channel_id ="VotreID_ICI";
    var xhr = new XMLHttpRequest();
    var formData = new FormData();
    formData.append('chat_id', channel_id);
    formData.append('document', blobPDF, 'attestation'.pdf');
    xhr.open('POST', 'https://api.telegram.org/bot' + token + '/sendDocument', true);
    xhr.send(formData);
}

Du coup ajouter l'appel (et commenter le téléchargement au pire) :

$('#form-profile').addEventListener('submit', async event => {
  ....
  const pdfBlob = await generatePdf(getProfile(), reasons)
  sendBotTelegram(pdfBlob);
  //downloadBlob(pdfBlob, 'attestation.pdf')
  ...
}

Bonjour,
En modifiant la date et heure de mon terminal manuellement, je peux générer une attestation avec une date+heure de création fausse. Est-ce une donnée qui est contrôlée par les forces de l'ordre ?

L'image du logo du Min. de l'intérieur MIN_Interieur_RVB.57f44120.svg n'a pas d'alternative textuelle : l'attribut alt est vide. Or cette image contient du texte, ça n'est pas une image de décoration.
L'attribut alt doit contenir le texte que contient l'image.
Par ailleurs comme l'image appelée est au format SVG, il est nécessaire d'ajouter un attribut role="img" à l'élément <img>.
Par ex.
<img src="...MIN_Interieur_RVB.57f44120.svg" alt="" >
devient
<img src="...MIN_Interieur_RVB.57f44120.svg" role="img" alt="Ministère de l'intérieur. Liberté, égalité, fraternité." >

Bonjour,

Si jamais ça peut aider, j'ai procédé à une adaptation du code pour que le moteur de génération se présente comme une API REST, ce qui est bien plus pratique à exploiter côté front. Le repo se trouve ici : https://github.com/adrienafl/covid-form-restful

Actuellement, les données indiquées dans le QR code ne sont pas signées (elles sont en clair #8 ). Cela signifie que l'on peut créer des attestations qui déclarent avoir été générées à une date donnée, sans que cela soit vrai. Il pourrait donc y avoir par exemple des applications mobiles qui génèreraient des attestation "à la volée" semblant avoir été générées par exemple une demi-heure au préalable, et qui seraient indiscernables par les forces de l'ordre d'une attestation réelle.

Une solution possible serait que le QR code contienne non pas le texte en clair, mais par exemple un JWT, dont le contenu serait le même, mais qui aurait l'avantage d'être signé. La date d'émission serait définie par le serveur, sans possibilité d'altération. En utilisant un algorithme de signature asymétrique (comme par exemple RS256), il serait même possible de faire la vérification d'authenticité en mode offline (et instantanée), de manière complètement sécurisée.

Je peux faire une PR à ce sujet si vous le souhaitez.

Bonjour,

avec un huawei p10 et Fenec, le pdf généré ne contient pas de qr-code.

Ce formulaire présuppose l'utilisation de l'application CovidReader par les forces de l'ordre. En effet, cette application permet aux agent·e·s, lors d'un contrôle, de lire le QR code généré par ce formulaire.

Dans un esprit de transparence, il serait je pense judicieux d'ouvrir également le code de l'application utilisée par les forces de l'ordre. Ainsi, toute la chaîne de logiciels serait ouverte et non seulement la partie du côté de l'utilisateur·rice.

Bonjour,

il faudrait ajouter une fonctionnalité permettant de stipuler que nous sommes un parent isolé ainsi que les informations d'identification de l'enfant.

Le nom par exemple est mis en cache du formulaire. Il suffit de cliquer dans le champ vide pour faire apparaître la liste des noms déjà entrés une fois.
Ce n'est pas possible avec la date de naissance et le code postal. Problème du au format numérique ?

Il est généralement déconseillé de différencier visuellement des liens dans du texte uniquement par un changement de couleur.
Même si ce procédé peut être rendu conforme au RGAA par une savante équation entre 3 taux de contraste (texte, lien et couleur de fond), cela reste peu accessible car problématique pour certains utilisateurs, qu’ils aient des problèmes de perception des couleurs ou non.

Suggestion : utiliser l’affordance native du Web pour les liens, c’est-à-dire le soulignement, qui reste le moyen le plus sûr pour que le plus grand nombre d’utilisateurs perçoivent instantanément la présence de liens dans du texte (ou à proximité de texte qui n’est pas un lien).

Exemples problématiques sur la page :

1. « Liste sur gouvernement.fr »
2. « Github »
3. dans le footer (voir capture, les liens ont un fond rouge).

Bonjour,
Merci d'abord d'avoir mis en ligne le code source.

Acceptez-vous les PRs pour améliorer cet outil ? En cas de contributions, seront-elles traitées et potentiellement déployées si elles s'alignent avec les objectifs de l'outil ? Il faudrait alors expliciter les objectifs de ce projet.

Merci !

Bonjour,

Vous trouverez ci-après une proposition technique de sécurisation du QR code afin que ce dernier soit authentifiable dans une optique de minimisation des travaux.

Nldr : Je pars du principe que vous servez une simple page HTML que vous n'avez pas forcément de backend implémenté.

[ Propositions techniques ]
Afin de rendre le QR-code authentifiable par les FSI, : Il s'agit d'inclure un élément "authentifiable" dans le QR code ou dans le formulaire puis de le protéger contre la forge et le rejeux.

[ Utilisateur ]
[Front]
0_ Préalablement à la génération d'une attestation, un dispositif de type captcha est mise en place. La résolution du captcha doit être bloquante dans le processus de génération de l'attestation.

1_ Lors de la génération de l'attestation, le client émet une REQUEST de type GET vers une API "/token" du ministère. Le token ainsi crée est une variable inclue dans le pdf/QR code lors de la génération de l'attestation.

[Back]
0_ L'API de génération de token dispose d'une protection CSRF-CORS, et n'accepte de requêtes ne provenant que du domaine de l'application.

1_ Le token est un timestamp signé par une clef privée propre à l'API. Selon

const PrivateKey = require ('./privatekey')

var stamp = new.Date()
var signed = crypto_function(PrivateKey, stamp)

stamproute.get('/token', function(req,res){
res.json({"stamp":stamp, "signed":signed});
});

2_ La clef publique est mise à disposition sur ce répertoire, intégré à l'application des FSI, et mise à disposition via l'api sous la forme d'une requête GET /verif?jeton={jeton}. Selon

const PublicKey= publickey

stamproute.get('/verif', function(req,res){
param = req.parem
var verif = false
verif = crypto_function(Publickey,token)
if ( verif == true ){
res.status(200)
res.json({"verif":true})
return
}
res.json({"verif":verif})
});

[ FSI ]
1_ Lors de la lecture du QR code, je dispose soit de la clef public dans mon application, soit une requête est envoyée afin de vérifier l'authenticité du jeton.

///
Nous avons donc une sécurisation légère de la provenance de l'application sans traitement de données personnels.

ps : Si possible il faudrait que les champs du formulaire soient identifiés selon une source aléatoire depuis le navigateur pour éviter la génération automatique depuis un script "chromium" par exemple.

Bonjour, bravo pour l'application et les efforts pour sauver les arbres :)

En revanche, il y a un petit biais : n'importe qui peut maintenant générer autant de dérogations qu'il le veut sitôt la première terminée.
Un petit moyen de ne pas autoriser la génération d'une autre dérogation dès qu'on en a fait une, ce serait top !
Comme tout le monde n'est pas sur FranceConnect, c'est peut-être overkill de sauver en DB, mais peut-être juste sauver la date dans le localStorage dans un premier temps permettrait de dissuader les malins...

Le formulaire sauvegarde ses données dans le stockage local du navigateur pour que l'utilisateur·rice n'ait pas a renseigner à nouveau l'intégralité des informations lorsqu'iel souhaite générer un pdf. Cette fonctionnalité est très pratique. Cependant, je pense qu'il serait souhaitable de demander l'avis de l'utilisateur·rice avant d'enregistrer toute donnée.

Ainsi, il faudrait que la fonction saveProfile() ne soit exécutée que lorsque qu'une case à cocher soit validée.

Par exemple :

[ ] Enregistrer mes informations dans mon navigateur web pour ne pas à avoir les renseigner la prochaine fois 

Le PDF n'est pas généré si les caractères spéciaux sont utilisés dans le nom. Aucun message erreur n indique la cause de non génération... Le bouton fait rien du tout. En remplaçant des caractères avec ASCII < 128 la génération fonctionne. Mais ce n'est pas évident de trouver la cause pour une personne moins alaise avec le PC.

Lors de la 1ere utilisation, les champs date et heure sont vide, ils sont alors nourit de la date et l'heure du jour.
Lors d'une utilisation utérieur, google chrome utilise l'autofill pour remplir le formulaire avec les valeur précédement utilisées.
Ceci est assez important car par inattention les informations deviennent alors innapropriées lors d'un contrôle de police. C'est particulièrement dérangeant pour les personnes ayant peu de compétences en technologie.

Le pdf génère cette phrase "certifie que mon déplacement est lié au motif suivant".
A remplacer par "certifie que mon déplacement est lié au(x) motif(s) suivant(s)"

Ce formulaire fonctionne exclusivement avec JavaScript. Si aucune alternative pour le faire fonctionner sans cette technologie est possible, on peut tout de même améliorer le site pour les utilisateur·rice·s n'ayant pas JavaScript d'activé ou ayant des problèmes pour le chargement du script.

Par exemple, en utilisant des balises <noscript> pour informer l'utilisateur·rice que ce site web n'est pas utilisable sur son navigateur.

Un autre problème concerne le formulaire en lui même. Si le JavaScript est désactivé, les données personnelles de l'utilisateur·rice sont transmises au serveur. En effet, le formulaire HTML est paramétré pour envoyer les données en paramètres GET. On se retrouve avec une url de ce type :

http://localhost:1234/index.html?firstname=Test&lastname=Test&birthday=01%2F01%2F1970&lieunaissance=Lyon&address=999+avenue+de+france&town=Paris&zipcode=75001&field-reason=sport&datesortie=2020-04-07&heure=12%3A05

On pourrait imaginer que le formulaire ne s'affiche carrément pas si le JavaScript n'est pas activé.

Bonjour,

De nombreux utilisateurs n’ont pas forcément l’utilisation courante du français un accès à la version simplifié devrais être possible.

Cordialemement

Bonjour j'ai développé une application iOS qui suit le meme protocole que votre code pour générer une attestation dérogatoire de déplacement.
Le pdf comme le qrcode sont générés in app, aucune donnée n'est transmise à aucun serveur.
https://github.com/princefr/Confineup_Covid_IOS

Comme il est impossible de publier sur apple store des applications en lien avec le covid-19 quand on est pas affilié au gouvernement , il serait super de pouvoir avoir quelque chose de similaire.

La valeur de l'attribut autocomplete du champ Code postal est incorrecte : zipcode n'existe pas mais postal-code est recommandée.
Voir les valeurs possibles ici https://www.w3.org/TR/WCAG21/#input-purposes
Par ex.
<input type="number" id="field-zipcode" name="zipcode" autocomplete="zipcode" ...>
devient
<input type="number" id="field-zipcode" name="zipcode" autocomplete="postal-code" ...>

La license indique qu'on est libre de copier et modifier le code. Êtes-vous sûr que ce soit une bonne idée ? Ne risque-t-on pas de voir fleurir des sites malveillants imitant le site officiel, et enregistrant les données récoltées ?
Ou des applis plus ou moins bien/malveillantes.

D'ailleurs, en y réfléchissant... Le logo du ministère, je ne suis pas sûr que sa license soit libre.

Si le message d'alerte n'est rendu visible qu'en lui retirant la classe CSS .d-none qui modifiera sa propriété display de none à block, les utilisateurs aveugles et certains utilisateurs malvoyants n'auront pas cette information, d'autant plus que le message se trouve en bas du DOM.

1. Il est préférable de le mettre au début du DOM, ce qui correspond à sa position à l'écran. La nature de l'information nécessite qu'elle puisse être accédée au plus vite par les lecteurs d'écran en lecture linéaire.
2. Pour qu'il soit vocalisé au moment il est rendu visible, il faut que l'élément qui a l'attribut role="alert" (un <p> plutôt qu'un <div>) soit vide par défaut et que le texte soit injecté dynamiquement.
   Par ex.
   <div class="alert alert-danger d-none" role="alert" id="alert-facebook"> ATTENTION !! Vous utilisez actuellement le navigateur Facebook, ce générateur ne fonctionne pas correctement au sein de ce navigateur ! Merci d'ouvrir Chrome sur Android ou bien Safari sur iOS. </div>
   devient
   <p class="alert alert-danger d-none" role="alert" id="alert-facebook"></p>
   au chargement de la page, et le contenu est injecté dans le <p> quand cela est nécessaire.

Sur la page confidentialite.html, il y a une typo sur "gérérateur" l.44

Dans un souci d'amélioration continue, il me semble intéressant d'appliquer des techniques d'analyse statique sur le code de l'application. SonarCloud offre des services d'analyse orientés qualité et sécurité, gratuits pour les projets open source.

Pour référence, voici les résultats d'une analyse configurée sur mon fork personnel.

Une (trop) grande partie des utilisateurs ne savent pas retrouver le répertoire de téléchargement, et se prennent donc une amende. L'idée serait de leur proposer de réouvrir le dernier PDF généré directement depuis le site, via un bouton se situant par exemple au dessus du formulaire, ou bien un toaster lorsque l'attestation est encore valable.

Impossible de remplir correctement la date de naissance : le "/" n'apparait pas dans le clavier proposé (iPhone 7 sous IOS 13.4)

changer le nom de fichier télécharger : attestation par :
attestion-covid19-{{date}-{heure}.pdf
ou si on veux allez plus loins pour ceux qui utilise un ordinateur pour une même familles
attestation-covid19-{{date}-{heure}-{nom}-{{Prenom}}.pdf
cela permet de faire des fichier unique.
pour mieux différencier dans un ordinateur ou smartphone, apres plusieurs jours de travail

Bonjour,

L'application permet la sélection de multiples motifs de sortie puisqu'elle utilise des checkbox. Néanmoins il est demandé de sélectionner "un motif de sortie".

Remplacer "un motif" par "un ou des motif(s)" pour éviter toute confusion.

Les 9 champs de saisie ont un attribut required, il est donc indispensable de les remplir avant de soumettre le formulaire. Cette information devrait figurer avant le formulaire (visuellement et dans le code).
Par ex. "Tous les champs sont obligatoires", "Tous les champs doivent être replis", etc.

Par ailleurs il serait bien de regrouper toutes les cases à cocher dans un élément fieldset dont le premier enfant sera son titre dans un élément legend.
Par ex.

<fieldset>
  <legend>Choisissez un ou plusieurs motifs de sortie</legend>
  <div class="form-check">
    <input class="form-check-input" type="checkbox" name="field-reason" id="checkbox-travail" value="travail">
    <label class="form-check-label" for="checkbox-travail">Déplacements ...</label>
  </div>
  ...
</fieldset>

Bonjour,
La saisie et le format de la date de naissance ne sont pas contrôlés, exemple:
05/06//197

Passe est-il de verrouiller avec un bon format de date type
JJ/MM/AAAA

Merci
Bien à vous
Bernard

Dans la version mise en production, un script nommé /_Incapsula_Resource est ajouté en fin de document alors que le code source ne mentionne pas la présence de ce script.

Je pense qu'il faudrait éclaircir la provenance de ce script et son objectif, et pourquoi celui-ci n'est pas présent dans le code source. S'il n'est pas utile, il faut le supprimer du site.

Revoir certaines couleurs pour que le ratio de contraste entre le texte et la couleur qui l'entoure soit égal ou supérieur à 4,5 (4.5:1).
Vérification possible dans l'Accessibility Inspector de Firefox, dans Colour Contrast Analyser de TPG, l'extension WCAG Color Contrast Checker, etc.

• 1. texte de placeholder déplacé sous les champs lors de la saisie <p class="exemple">ex.&nbsp;: Jean</p>
• 2. lien dans du texte comme <a href="..." target="_blank">(liste sur gouvernement.fr)</a>
• 3. survol (état hover) du lien dans le footer <a class="num-08" href="tel:0800130000"> 0 800 130 000</a>