Rapport final et recommandations du 4 août 2021 concernant l'application "SocialPass"

2.6.2. Droits des personnes concernées

a. Exercice du droit d'accès Le document « SocialPass — SocialScan et la protection des données »°, accessibles via l'application, les AppStores et le site web sous le titre « Protection des données », indique une adresse de contact pour les utilisateurs (info@socialpass.ch; état au 10.05.2021).

En outre, la déclaration de protection des données contient des informations sur les droits des personnes concernées (cf. ch. 6).

b. Exercice du droit à l'effacement des données L'effacement se fera de façon automatisée après la durée de conservation de 14 jours prévue par l'Ordonnance Covid-19 situation particulière.

Par contre, lorsque la fonction « Saisie manuelle » (cf. chapitre 2.4.1) est utilisée, les coordonnées des «clients réguliers » restent enregistrées sur l'appareil de l'établissement. Sur la base de la documentation soumise au PFPDT, aucune possibilité d'effacer les données des « clients réguliers » des appareils des établissements accessibles au public ne semble avoir été prévue par les exploitants de SocialPass.

Aucune information n'est disponible sur la question de savoir si une sollicitation à l'adresse des utilisateurs de supprimer l'application, et donc toutes les données personnelles détenues sur les appareils, est prévue lorsque les dispositions pertinentes fondées sur l'Ordonnance COVID-19 Situation particulière ne seront plus en vigueur.

2.7. Aspects de sécurité des données

2.7.1. Organisation de la sécurité de l'information Le PFPDT a demandé aux opérateurs de l'application, au moyen d'un questionnaire, comment les responsabilités en matière de sécurité de l'information et de protection des données sont définies, documentées et attribuées entre les deux exploitants de l'application. Dans leur réponse à ce

3 https:/Awww.socialpass.ch/mentionslegales/ questionnaire technique, les exploitants de l'application ont indiqué que la répartition des responsabilités en matière de sécurité de l'information et de protection des données n'a pas pu être fixée (ni par oral ni par écrit), notamment en raison des modifications constantes de l'application au niveau cantonal ainsi qu'en raison des développements rapides, mais que peu prévisibles de la pandémie.

2.7.2. Login avec double-authentification Sur la base des informations soumises au PFPDT, il n'est pas clair si et, le cas échéant, quels composants du système de SocialPass sont sécurisés au moyen d'une authentification à deux facteurs.

2.7.3. Identifiants de l'utilisateur Selon le chapitre [D] "8.11 - Device - Structure des données”, différents identifiants d'utilisateur sont utilisés. Outre le numéro de téléphone, il convient de mentionner explicitement l'utilisation de l'IMEI {International Mobile Equipment Entity, un numéro de série à quinze chiffres unique au monde de l'appareil) et d'un numéro d'utilisateur unique UID (Unique ID) de Google Firebase. Aucune autre donnée pseudonymisée servant à identifier de manière unique les personnes concernées n'a été mentionnée, même après des demandes explicites du PFPDT.

2.7.4. Géolocalisation

SocialPass n'utilise pas la géolocalisation.

28. Analyse de audit de Navixia SA Les composants « SocialPass » et « SocialScan » ont fait l'objet d'un test de vulnérabilité par Navixia SA, pour le compte de GastroVaud, aux dates suivantes. Cela vaut pour les systèmes d'exploitation iOS et Android.

Date Processus

18 mars 2021 Rapport, y compris Management Summary v.1.2 12 au 18 mars 2021 Test du cryptage mis en oeuvre

7 décembre 2020 Rapport, y compris Management Summary v.1.1 4 décembre 2020 Vérifications 2 et 3

16 au 18 novembre 2020 Kick-Off et test

Selon le rapport « Analyse de sécurité (recheck) Applications SocialPass & SocialScan v.1.2 » daté du 18 mars 2021, tous les éléments des applications susceptibles d'être pertinents pour la sécurité ont été examinés. Cela comprend le stockage des données, la confidentialité, la cryptographie,

l'authentification, la communication réseau et les paramètres de construction.

Pour analyser les applications mobiles, Navixia SA suit une méthodologie basée sur l'évaluation des risques OWASP. Cette approche suit un processus structuré et rend les résultats obtenus comparables entre eux. À cette fin, pour chaque élément identifié, la vulnérabilité est décrite et son degré de risque est cartographié sur la base du système normalisé CVSS (Common Vulnerability Scoring System). Les

résultats sont évalués selon les critères suivants :

= Exploitabilite : les vecteurs d'accès, la complexité de l'accès et l'authentification évaluent comment un attaquant peut accéder à une vulnérabilité et quelles conditions supplémentaires, le cas échéant, doivent être remplies pour qu'elle soit exploitée.

"Implications : Les indices de protection des données, d'intégrité du système et de disponibilité mesurent la manière dont une vulnérabilité peut avoir un impact direct sur l'infrastructure informatique une fois exploitée.

Dans le CVSS, le score total d'une vulnérabilité résulte de la combinaison d'une série d'évaluations isolées d'aspects individuels (métriques), en tenant compte des pondérations enregistrées dans la formule de calcul.

Les indices de mesure à cet effet sont indiqués ci-dessous avec les valeurs attribuées correspondantes.

Cet indice évalue le niveau d'autorisation qu'un attaquant doit avoir afin d'exploiter avec succès la

vulnérabilité. Disponibilité Haut: L'attaquant dispose de privilèges qui lui donnent accès à des rôles administratifs importants. Moyen: L'attaquant dispose de privilèges d'utilisateur de base qui peuvent affecter les paramètres et les fichiers d'un utilisateur. Faible: L'attaquant n'a pas besoin d'être authentifié.

Ici, l'évaluation est basée sur l'impact d'une vulnérabilité sur la confidentialité des données traitées.

Confidentialité

Haut: ll y a une perte totale de confidentialité et un attaquant obtient l'accès à toutes les ressources du composant affecté.

Moyen: Un attaquant peut accéder à certaines données.

Faible: Il existe un faible risque d'accès aux données au sein du composant concerné.

Cet indice décrit l'impact d'une vulnérabilité sur l'intégrité du système.

Intégrité

Haut: If en résulte une perte totale d'intégrité. Par exemple, l'attaquant peut modifier n'importe quel fichier (ou ensemble de fichiers).

Moyen: La modification de données est possible dans une mesure limitée. Cependant, la modification des données n'a pas d'impact significatif sur le composant concerné.

Faible: Il y a un faible risque de perte d'intégrité.

Le degré de danger est évalué dans le rapport de Navixia SA sur la base des éléments ci-dessus sur une échelle de 0 à 10.

« Score entre 9,0 et 10: critique

« Score entre 7,0 et 8,9: haut

* Score entre 4,0 et 6,9: moyen

* Score entre 0,1 et 3,9: faible

* Score 0: à titre d'information

Du point de vue du PFPDT, les interprétations suivantes doivent servir de référence, en fonction de l'indice d'évaluation, afin de prévenir les risques de violation de la protection des données.

Critique: Cette vulnérabilité représente un risque inacceptable. L'application ne doit pas être mise en ligne ; si elle l'est déjà, elle doit être désactivée immédiatement.

Haut: Cette vulnérabilité doit être corrigée immédiatement, éventuellement dans le cadre d'un correctif d'urgence. D'autres mesures de minimisation des risques doivent être envisagées jusqu'à ce que le correctif soit en place.

Moyen: Cette vulnérabilité doit être corrigée, même si elle entraîne des coûts supplémentaires (modérés) ou d'autres inconvénients (modérés).

Faible: Le correctif peut être inclus dans la planification des versions sur une base régulière.

Par la suite, les conclusions du document « GVD7009_Recheck_SocialPass_SocialScan_v1.2 » sont décrites.

2.8.1. Interaction avec la plateforme (6.2.6 et 6.3.6) Actuellement, le serveur ne vérifie pas les métacaractères. Le cross-site scripting (XSS) n'est souvent que le précurseur d'attaques plus graves. Actuellement, aucune vérification des données n’a lieu avant leur exécution par le serveur.

4 Les chiffres se réfèrent aux chapitres du document [A] « GVD7009_Recheck_SocialPass_SocialScan_v1.2 »

2.8.2. Qualité du code et packaging (6.3.7) Comme décrit dans le rapport d'audit, un attaquant peut modifier l'APK (paquet Android) afin qu'il contienne une ancienne version d'une bibliothèque externe sans que cela soit détecté par la signature. Toutefois, si cette ancienne bibliothèque contient des vulnérabilités, l'APK peut être installé sur un téléphone mobile, par exemple, sans briser la signature existante. Il est ainsi possible d'exploiter les failles de sécurité des anciennes bibliothèques.

En outre, les versions intégrées des bibliothèques tierces ont été examinées au cours de l'audit. Il a été constaté que toutes les bibliothèques ne sont pas de la dernière version. En fait, les bibliothèques tierces obsolètes sont souvent affectées par des failles de sécurité.

2.8.3. Descripteur (7.1) Le descripteur d'API utilisé par les applications mobiles est accessible au public. Cela permet à un attaquant de détecter toutes les méthodes disponibles. D'après le rapport, le descripteur d'API n'est plus visible dans l'environnement de test UAT (User Acceptance Test), mais peut toujours être consulté en production. Un attaquant peut en tirer des informations pour attaquer l'environnement UAT. Le problème ne peut donc être résolu que si l'information n'est pas du tout visible.

2.8.4. Mots de passe stockés en clair (7.1) Dans le cadre d’interviews, les développeurs de SocialPass ont confirmé à Navixia SA que les mots de passe ne sont plus stockés en texte clair dans la base de données. Cependant, sans accès à cette base de données, il n'a pas été possible pour Navixia de vérifier si les mots de passe sont maintenant stockés correctement (salt & hash). Dès lors, le PFPDT part du principe que les déclarations faites par les développeurs dans le rapport sont correctes et que les mots de passe ne sont plus seulement stockés en texte clair, mais qu'ils sont également sécurisés par un Medium Salting.

2.8.5. Conservation des données (8.4.1) La section 8.4.1 mentionne un problème de conservation des données dû à une faille de sécurité. Selon le rapport d'audit, cela a été rectifié depuis. Or, ce point ne pouvait plus être vérifié par Navixia SA sans accès à la base de données.

29. Analyse de l’audit d’Indusface Le PFPDT a reçu les deux documents suivants par e-mail le 11 février 2021 par le représentant légal des exploitants de SocialPass :

Rapports d’audit Android Mobile Application Audit Report of Social Scan v1.0.pdf

iOS Mobile Application Audit Report of Social Scan v1.0.pdf

Les deux rapports d'audit fournis (Indusface), se réfèrent exclusivement au composant « SocialScan », dans les versions pour Android et iOS. Ils ne contiennent aucune information sur le composant « SocialPass » ou sur des services tiers tels que « Twilio » ou les systèmes back-end sur « Azure ».

Périodes d’essai | os | Version SocialScan

Les conclusions des rapports « Android Mobile Application Audit Report of Social Scan v1.0 » et « iOS Mobile Application Audit Report of Social Scan v1.0 » diffèrent en fonction des systèmes d'exploitation Android et iOS.

2.9.1. Classification

La classification est basée sur les catégories ci-dessous.

Impact Description

A vulnerability wherein an attacker might have the ability to execute commands on the server or retrieve and modify private information.

Security issues are defined as a risk that puts the system and / or data related to the system in immediate danger.

Findings indicate a more serious security matter that should be remedied appropriately within a short amount of time.

Findings usually indicate a minor security risk that does not pose immediate or short-term danger. An observational point in the site, or detection of certain applications or web servers.

An observational point in the site, or detection of certain applications or web servers.

2.9.2. Résultats en fonction des catégories

iOS-App

Critical: 0 j - = Critical: 0

" Information: 3 "= Information: 1

2.9.3. Android et iOS Mobile

Le tableau ci-dessous reflète les résultats d'indusface [B] et [C] pour le composant « SocialScan » pour les systèmes d'exploitation Android et iOS. Les entrées marquées d'un astérisque (*) sont considérées par le PFPDT comme pertinentes pour la protection des données. Même s'ils sont considérés comme faibles dans la classification des risques, ils peuvent développer une classification des risques différente à la suite d'interactions. Ces entrées relatives à la protection des données sont analysées au chapitre

Le PFPDT utilise les notations suivantes comme critère pour atténuer le risque de violation de la

protection des données.

Cette vulnérabilité représente un risque inacceptable. L'application ne doit pas être mise en ligne ; si elle l'est déjà, elle doit être désactivée immédiatement.

Cette vulnérabilité doit être corrigée immédiatement, éventuellement dans le cadre d'un correctif d'urgence. D'autres mesures de minimisation des risques doivent être envisagées jusqu'à ce que le correctif soit en place.

Cette vulnérabilité doit être corrigée, même si cela entraîne des coûts supplémentaires (modérés) ou d'autres inconvénients (modérés).

La correction peut être incluse dans la planification des versions ultérieures sur une base régulière. |

Tableau 3: Résultats trouvés dans SocialScan

Ni Vulnérabilité

1* Blind HTML Injection High

2* Insecure Direct Object References High

3 Application Is Vulnerable To Email Flooding Attack Medium

4* Insecure Logging Of The Application (betrifft nur Android) Medium 5* Application Is Vulnerable To Improper Token Management Low

6* Application Accepts Special Character As User Input Low

7* Valid Account Can Be Brute Forced Low

8* Missing API Rate Limiting Low

9* Application Does Not Have A Strong Password Policy Low

10 Application Is Vulnerable To Reverse Engineering Low

11* Cleartexttraffic Is Set To True (betrifft nur Android) Low

12* Application Is Vulnerable To Simultaneous Login Low

13* Application's Request/Response Reveals Sensitive Information Low 14* SSL Pinning Can Be Bypassed Low 15* Insecure Data Storage In File System Low 16* Insecure Content Security Policy (Csp)/X-Frame-Options Low

17* Missing HSTS Header Low 18* Information Leakage From Clipboard Low 19* Sensitive Data Disclosure In Recent Apps Low

20 Default Web Page Found Low 21* Application Has Set Insecure Permissions Low

22 Programming Language And Version Disclosure Low

23 Application Displays Web Server Banner Low

24 Using Known Vulnerable Components Low

25 Application Works In Rooted Device Low

26 Application Runs On Older Platform Information

27 Printstacktrace() Function Is Used In The Application Information

28 setAlLowFileAccess Enabled Information

2.9.4. Conclusions de l'audit Indusface Le sous-chapitre 2.9.4 résume les différentes constatations du PFPDT comportant un risque de perte de données, de corruption de données ou de dommages aux données.

a. Blind HTML Injection [1P L'injection HTML est utilisée lorsque l'entrée dans une application n'est pas validée. Cela permet de modifier le contenu d'une page web et tous les utilisateurs qui naviguent sur cette page verront le contenu modifié. Ainsi, sur la page d'enregistrement de SocialScan, un attaquant peut injecter un HTML Payload (par exemple, une chaîne de code malveillant) dans les champs de données et réussir à l'enregistrer. L'injection HTML est exécutée avec succès dans les modèles d'email.

b. Insecure Direct Object References [2]

Les références directes à des objets non sécurisées (IDOR) constituent un problème de sécurité qui se produit lorsque le développeur de l'application utilise un pointeur pour accéder directement à un objet d'implémentation interne, mais ne fournit pas de contrôles d'accès et/ou de vérifications d'autorisation supplémentaires. Un utilisateur de SocialScan est lié à son numéro d'identification d'utilisateur par l'ID de l'organisation. L'attaquant, à son tour, se connecte à SocialScan et peut simplement modifier l'ID de l'organisation à volonté. Cela permet à l'attaquant d'avoir accès aux détails de l'utilisateur correspondant {numéro de téléphone mobile et mot de passe).

c. Insecure Logging Of The Application [4] Dans SocialScan, les données sensibles d'un point de vue technique sont enregistrées et peuvent conduire à des fuites d'informations. Dans SocialScan, les données sensibles telles que le nom de l'utilisateur et le mot de passe sont stockées sans aucune « obfuscation ».

d. Application Is Vulnerable To Improper Token Management [5] Le rapport indique que dans SocialScan, une session reste active même après la déconnexion. Cela signifie qu'une session peut être reprise et réutilisée par un autre utilisateur.

5 Les chiffres entre crochets font référence au tableau 3: Résultats trouvés dans SocialScan, ci-dessus.

e. Application Accepts Special Character As User Input [6] SocialScan accepte les caractères spéciaux (>{</ etc.). Cela peut conduire à l'exécution d'un code malveillant.

f. Valid Account Can Be Brute Forced [7] Une attaque par force brute (Brute-Force-Attack) est une méthode d'attaque banale. La théorie est que lors d’une telle attaque, un nombre infini de tentatives sont faites pour deviner un mot de passe. À un moment donné, le mot de passe correct devrait être deviné. C'est possible avec SocialScan.

g. Missing API Rate Limiting [8] Les interfaces d'application dont les limites de ressources et de quotas sont absentes ou mal impl&mentees offrent aux attaquants la possibilité de réaliser des attaques Brute-Force sur des comptes d'utilisateurs ou de provoquer un déni de service. L'exploitation de cette vulnérabilité ne nécessite

souvent même pas d'authentification ; elle requiert simplement l'envoi simultané de plusieurs requêtes.

h. Application Does Not Have A Strong Password Policy [9] SocialScan n'a pas de politique de mot de passe ou ne l'applique pas correctement. Par exemple, il est possible d'utiliser un mot de passe composé d'une seule lettre.

i Cleartexttraffic Is Set To True [11] Selon le rapport d'audit, le trafic de données sur la plateforme Android s'effectue sans cryptage de transport (SSL/TLS), c'est-à-dire en texte clair (HTTP).

J. Application Is Vulnerable To Simultaneous Login [12] Il est possible d'ouvrir plusieurs sessions avec les mêmes données d'identification. Cela augmente donc la surface d'attaque, puisqu'un attaquant peut utiliser de manière transparente des données d'identification valides en même temps que l'utilisateur légitime.

k. Application’s Request/Response Reveals Sensitive Information [13] Toutes les informations sensibles d'un point de vue technique (c'est-à-dire les données personnelles et les autres données qui pourraient potentiellement compromettre la sécurité des données, par exemple

le mot de passe) ne sont pas obscurcies à l'aide d'une technique appropriée telle que le Salting.

[A SSL Pinning Can Be Bypassed [14] Dans SocialScan, le SSL Pinning implémenté peut être contourné en insérant JavaScript au moment de l'exécution.

m. Insecure Data Storage In File System [15] Les vulnérabilités du stockage des données surviennent lorsqu'on suppose que les utilisateurs ou les logiciels malveillants n'ont pas accès au système de fichiers d'un appareil mobile et donc aux informations sensibles contenues dans la mémoire de l'appareil. II faut donc s'attendre à ce qu'un utilisateur malveillant ou un logiciel malveillant puisse avoir accès à des données sensibles dans SocialScan. Le rootage ou le jailbreak d'un appareil mobile contourne toute mesure dé protection par

cryptage.

n. Insecure Content Security Policy (Csp)/X-Frame-Options [16] L'en-tête de réponse HTTP de X-Frame-Options dans SocialScan peut être utilisé pour spécifier si un navigateur est autorisé ou non à rendre une page dans un <frame>, <iframe>, <embed>, ou <object>.

0. Missing HSTS Header [17] SocialScan n'utilise pas d'en-tête HSTS. Cela signifie que les communications non cryptées via HTTP sont autorisées.

p. Information Leakage From Clipboard [18] SocialScan permet de copier-coller a partir du presse-papiers, notamment le copier-coller de mots de passe figurant dans le presse-papiers.

q. Sensitive Data Disclosure In Recent Apps [19] Au vu du rapport, aucune précaution n'est prise pour empêcher l'utilisation de données sensibles (d'un point de vue technique) par des applications tierces (par exemple, en mettant en cache des instantanés d'applications).

r. Application Has Set Insecure Permissions [21] ll s'est avéré que SocialScan n'avait pas défini des droits d'accès, ce qui constitue une menace pour la sécurité pouvant entraîner des fuites de données dans le pire des cas.

3. Appréciation juridique et recommandations

Sur la base des faits établis ci-dessus, notifiés aux parties le 20 mai 2021, le PFPDT considère ce qui suit (chapitre 3). Il tient à relever que contrairement à ce que peuvent laisser entendre les documents soumis par les parties, le PFPDT ne fonde pas ses considérations sur l’« attestation de conformité » d'un audit externe telle que mentionnée dans le document intitulé « COVID-19 — Dispositifs d'identification de la clientèle dans les établissements de restauration, Procédure de vérification technique — 15 octobre 2020 ». En effet, une telle attestation, bien que mentionnée dans ledit document figurant au dossier, n’a pas été soumise au PFPDT au cours de la procédure d'établissement des faits.

3.1. Rôles et responsabilités

Tel que constaté dans le cadre de l'établissement des faits du 20 mai 2021, les informations quant aux rôles et responsabilités des parties impliquées dans la présente procédure sont restées contradictoires (cf. chapitre 2.1).

Sur la base de la documentation soumise au PFPDT et des informations disponibles au public, le PFPDT constate que les deux sociétés ont décidé d’unir leurs efforts et leurs ressources en vue d'atteindre un but commun (amélioration du traçage dans le cadre de la pandémie du COVID-19) et ont ainsi développé le système SocialPass sous forme d'une co-édition.

En vertu de l'art. 3 lit. i LPD on entend par maitre du fichier la personne privée (physique ou morale) qui décide du but et du contenu du fichier. Cependant, cette notion refléte une réalité ancienne, qui ne correspond plus aux besoins d’un monde digitalisé. En effet, cette notion remonte a une époque ou les fichiers étaient constitués de classeurs et de fiches. La notion est avant tout utilisée dans le but de déterminer la personne responsable du traitement. Le PFPDT partage l'opinion de certains auteurs qui proposent de renoncer a employer cette notion et proposent que la responsabilité au sens de la LPD découle des faits du traitement de données (cf. RUDIN BEAT, Kommentar zu Art. 3 DSG, N 43, in: Baeriswyl/Pärli (Hrsg.), Stämpflis Handkommentar zum DSG, 2015).

Force est de constater que les sociétés NewCom4U Sarl et SwissHelios Sarl ont développé le système SocialPass ensemble, elles ont décidé du but et du contenu du fichier ainsi que des droits d'accès à ce fichier et ce sont elles qui assurent les divers traitements des données. Elles doivent dès lors être considérées toutes les deux maîtres du fichier au sens de la LPD.

La qualité de maitre de fichier doit cependant être distinguée de celle de mandataire au sens de l'art. 10a LPD. Trois constellations différentes sont possibles en pratique : le mandant peut également être maître du fichier, le mandant et le mandataire peuvent être maîtres communs du fichier ou alors le mandataire peut être considéré maître du fichier, notamment lorsqu'il traite des données pour le compte de son client (cf. ROSENTHAL DAVID/JOHRI YVONNE, Kommentar zu Art. 10a DSG, N 19, in Rosenthal/Jöhri (Hrsg.), Handkommentar zum Datenschutzgesetz sowie weiteren, ausgewählten Bestimmungen, 2008).

Dans le cas d'espèce, les dispositions légales pertinentes octroient une certaine marge de manœuvre aux exploitants d'établissements accessibles au public. En effet, le ch. 4.3. de l'annexe 1 de l'Ordonnance COVID-19 situation particulière fixe uniquement que dans le cadre des plans de protection «les coordonnées peuvent être collectées à l'aide de systèmes de gestion des réservations ou des membres, ou encore au moyen de formulaires de contact ». Aucune disposition fédérale ne vient préciser quels systèmes de gestion doivent être privilégiés. Les deux sociétés ont donc proposé une solution numérique afin d'améliorer le traçage dans le cadre de la pandémie du COVID-19 (cf. chapitre 1.2). Ce faisant, elles ont proposé un traitement de données à leurs clients respectifs. En créant le système SocialPass, elles ont décidé du but et du contenu du fichier ainsi que des droits d'accès à ce fichier et ce sont elles qui assurent les divers traitements des données. Ainsi, il découle des constatations du PFPDT que dans le cas d'espèce, les mandataires communs que sont les sociétés NewCom4U Sari et SwissHelios Sarl doivent être considérés maître du fichier au sens de l'art. 3 lit. i LPD.

Dès lors, la question de savoir qui est le mandant, et s’il existe, le cas échéant, plusieurs mandants (les gouvernements des cantons respectifs, les restaurateurs pris individuellement, la faîtière des restaurateurs vaudois) peut rester ouverte.

Le maître du fichier est responsable de respecter le cadre iégal lors de tout traitement de données et de garantir les droits aux personnes concernées tels que consacrés dans la LPD (cf. RUDIN, Art. 3 DSG, N 49 s. et ROSENTHAL, Art. 10a DSG, N 22). Le maître du fichier est avant tout responsable de faire suite aux éventuelles demandes d’accés des personnes concernées (art. 8 LPD).

Il découle de ce qui précède que les sociétés NewCom4U Sarl et SwissHelios Sarl ont la qualité de maitre de fichier au sens de l'art. 3 lit. i LPD. Dès lors, il leur incombe de respecter les obligations légales prévues par la LPD, la LEp et l'Ordonnance COVID-19 situation particulière. En vertu de l'art. 4 al. 4 LPD la collecte de données personnelles, et en particulier les finalités du traitement desdites données, doivent être reconnaissables pour la personne concernée (principe de transparence). Le respect du principe de transparence permet en effet aux personnes d'exercer leur droit d'accès. Etant donné que les indications dans les différents documents sont contradictoires dans la mesure où certains documents mentionnent les deux sociétés tandis que d’autres ne mentionnent que l’une des deux sociétés en tant que maître du fichier, le PFPDT constate une violation du principe de transparence tel que consacré à l'art. 4 al. 4 LPD. En effet, en l’état actuel, les personnes concernées ne sont pas en mesure de déterminer avec certitude quelle personne morale traite leurs données et à qui, le cas échéant, elles devraient adresser une demande d'accès.

(1) Recommandation concernant les rôles et responsabilités :

Les sociétés NewCom4U Sarl et SwissHelios Sarl doivent uniformiser tous les documents (site web, appstores et app) afin de respecter leurs obligations légales en tant que maîtres du fichier au sens de l'art. 3 lit. i LPD.

3.2. Banque de données centralisée

3.2.1. Banque de données centralisée stricto sensu

La collecte des coordonnées des visiteurs (nom, prénom, numéro de téléphone, NPA) trouve son fondement dans l'art. 5 de l'Ordonnance COVID-19 situation particulière, qui oblige les exploitants d'établissements accessibles au public de collecter lesdites coordonnées. Cette disposition prévoit notamment que les exploitants collectent les coordonnées des visiteurs et les transmettent aux autorités cantonales sur demande, notamment aux fins d'identification et d'information des personnes qui se trouvaient dans l'établissement au même moment qu'une personne infectée et qui sont dès lors présumées infectées au sens de l’art. 33 LEp. Les coordonnées doivent impérativement être détruites

après 14 jours.

Selon le ch. 4.5. de l'annexe 1 de l'Ordonnance COVID-19 situation particulière, il incombe à Fexploitant de garantir la confidentialité des coordonnées qu'il collecte ainsi que la sécurité des données, notamment durant leur conservation. Ainsi, en vertu des diverses dispositions applicables, il a été prévu que les coordonnées collectées restent chez les exploitants respectifs. Ce n'est qu'en cas d'infection dans un établissement déterminé que les autorités cantonales doivent avoir accès aux coordonnées des visiteurs de l'établissement concerné. En d’autres termes, il a été prévu que les exploitants des établissements gardent le contrôle sur les coordonnées qu'ils ont collectées. La disposition fédérale ne prévoit pas d'accès direct à toutes les coordonnées collectées dans tous les restaurants d'un même canton.

SocialPass doit être considéré en tant que système de gestion tel que prévu au ch. 4.3. de l'annexe 1 de l'Ordonnance COVID-19 situation particulière. En effet, cette disposition fixe que « les coordonnées peuvent être collectées à l’aide de systèmes de gestion des réservations ou des membres, où encore au moyen de formulaires de contact ».

À la lumière de la LPD, les deux sociétés SwissHelios Sarl et NewCom4U Sarl doivent être considérées des tiers au sens de l’art. 10a LPD. Il découle de cette constatation que le système SocialPass ne devrait que permettre les traitements de données que le mandant serait en droit d'effectuer lui-même, c'est-à-dire que le système SocialPass, afin de tomber sous la définition du ch. 4.3. de l'annexe 1 de lOrdonnance COVID-19 situation particulière, ne devrait que permettre d'effectuer les traitements tels que prévus dans l'Ordonnance COVID-19 situation particulière.

Cela étant, il convient de distinguer deux questions différentes qu'il convient d'analyser séparément par la suite.

Dans le cadre de ce premier sous-chapitre, il convient de se pencher sur la question de savoir si le cadre légal pertinent permet la mise en place d’une base de données centralisée. Si le cadre légal fédéral permet en effet la mise en place d’une base de données centralisée, se pose alors la question de savoir si dans le cas d'espèce, des mesures appropriées ont été mises en place afin de répondre aux exigences tenant à la sécurité de données sensibles (cf. art. 7 LPD) et aux exigences légales en matière de protection des données (notamment le principe de la proportionnalité).

Le ch. 4 de l'annexe 1 de l'Ordonnance Covid-19 situation particulière qui fixe les détails de la collecte des coordonnées n'apporte pas de précisions quant aux systèmes de gestion des réservations qui peuvent être utilisés pour la collecte (cf. ch. 4.3). Le Rapport explicatif concernant l'ordonnance COVID- 19 situation particulière (y inclus grandes manifestations) du 26 mai 2021 n'apporte pas plus de

précisions quant à cette question.

Les dispositions pertinentes se contentent de fixer que de tels systèmes peuvent être utilisés et que les exploitants ou les organisateurs doivent garantir la confidentialité des coordonnées qu'ils collectent et la sécurité des données, notamment durant leur conservation (cf. ch. 4.6.).

Sur la base de ces dispositions laissant une marge de manœuvre aux exploitants dans le choix du système de gestion des réservations ou des membres, le PFPDT conclut que l'Ordonnance COVID-19 situation particulière n'exclut pas, par principe, que les exploitants d'établissements accessibles au public utilisent des systèmes de gestion des réservations qui impliquent un enregistrement des données centralisé. Toutefois, cet enregistrement centralisé ne sera conforme aux exigences légales uniquement si les principes de la protection des données sont respectés et des mesures de sécurité appropriées sont mises en place en amont (cf. ch. 4.6. Ordonnance COVID-19 situation particulière et art. 7 LPD).

Le PFPDT retient dès lors que l'enregistrement des coordonnées collectées dans une base de données centralisée telle que prévue par le système SocialPass est conforme au cadre légal à condition que :

- les principes généraux de la loi sur la protection des données selon l'art. 4 ss. LPD sont respectés ;

- des mesures de sécurité appropriées aient été mises en place en amont, conformément à l’art. 7 LPD en relation avec les art. 8 et 9 OLPD, en particulier l'art. 9 al. 1 let. g OLPD (pour une analyse des mesures de sécurité mises en place, cf. chapitre 3.7).

Dans un deuxième temps, il convient dès lors d'analyser la question de savoir si la solution d'une base de données centralisées est également conforme au cadre juridique dans sa forme concrète.

3.2.2. Divers droits d'accès à la base de donnée centralisée / fonctions de filtres

Dans le cadre de ses analyses, le PFPDT a constaté que le fonctionnement du système SocialPass impliquait l'existence d’une base de données centralisée (cf. chapitre 3.2.1) qui offre plusieurs options de recherches ciblées (p.ex. les personnes ayant accès à cette base de données peuvent rechercher

* toutes les personnes s’appelant Laure ou Christophe ayant visité n'importe quel établissement public dans le canton du Valais au long des 14 derniers jours).

Force est de constater que le droit d'accès direct à la base de données centralisée octroyé aux autorités cantonales vaudoises et valaisannes, y compris les différentes options de recherches ciblées, peut conduire à la création de profils de personnalité au sens de l'art. 3 lit. d LPD. En effet, en fonction des établissements accessibles au public visités (p.ex. une maison close) et/ou en raison des personnes rencontrées lors de ces visites (p.ex. un visiteur rencontre un avocat spécialisé en droit pénal), les données ainsi assemblées peuvent permettre d'apprécier les caractéristiques essentielles de la personnalité des personnes concernées.

Au regard des dispositions légales pertinentes du droit fédéral, ces multiples possibilités de recherches

ciblées apparaissent comme excessives, voire disproportionnées.

Le cadre légal fédéral pertinent ne prévoit ni le droit, pour les autorités cantonales, d'accéder à une base de données centralisée ni la création éventuelle de profils de personnalité. Dès lors, le système SocialPass permet un traitement de données qui va au-delà de ce qui est prévu par le cadre légal

fédéral.

Pour les traitements éventuellement possibles allant au-delà de ce que prévoit le cadre légal fédéral, un motif justificatif au sens de l'art. 13 al. 1° LPD doit pouvoir être invoqué par les maîtres du fichier (consentement, intérêt prépondérant privé ou public, base légale). Or, dans le cas d'espèce, il semble que le seul motif justificatif invocable par des maîtres du fichier qui offrent un produit qui permet de soutenir les établissements accessibles au public dans l'accomplissement d’une tâche légale en temps de pandémie, ne peut qu'être qu'une base légale.

La base légale entendue comme une norme générale et abstraite peut relever du droit cantonal ou fédéral. La base légale doit être applicable au cas d'espèce et ne pas être contraire à une autre norme (hiérarchiquement supérieure).

De plus, le traitement de données justifié sur la base de cette base légale doit apparaître proportionné (cf. WERMELINGER, Stämpflis Handkommentar, Art. 13 DSG N 15).

En l'espèce, le cadre légal fédéral ne prévoit pas l'accès direct, pour les autorités cantonales, sur une base de données centralisée. En effet, le droit fédéral applicable au cas d'espèce prévoit que les

exploitants des établissements accessibles au public maintiennent le contrôle sur les coordonnées collectées et ne les transmettent à l'autorité publique compétente uniquement en cas d’infections présumées dans leur établissement.

Toutefois, tant que l'accès direct à la base de données centralisée n'entraîne pas un traitement des données allant au-delà de celui qui serait effectué si les données étaient remises à l'autorité sanitaire sur demande, cet accès semble être justifié, compte tenu de l'intérêt public à lutter contre la pandémie

actuelle.

La question de savoir si et dans quelle mesure les réglementations cantonales peuvent justifier un accès plus étendu peut être laissée ouverte sur la base des considérations suivantes :

En effet, le PFPDT peut se prononcer sur la question de savoir si un acte cantonal constitue un motif justificatif au sens de l’art. 13 LPD pour un traitement de données effectué entre personnes privées. Dans ce cadre il lui incombe, entre autres, de déterminer si la base légale cantonale est conforme au

droit fédéral hiérarchiquement supérieur, notamment si le dispositif cantonal est conforme à la LPD.

À ce titre, il convient de distinguer la situation dans le canton de Vaud de celle dans le canton du Valais (cf. lettre du 23 avril 2021 soumise au PFPDT par Lexing Switzerland).

Dans le canton de Vaud, le Chef du Département de l’économie, de l'innovation et du sport ainsi que la Cheffe du Département de la santé et de laction sociale vaudois ont édicté la Directive du 15 septembre 2020 COVID-19 / Coronavirus. Selon l'art. 4 lit. e de cette Directive, « un dispositif d'identification de la clientèle doit être utilisé systématiquement. Ce dispositif doit être homologué par la faîtière de la branche, en concertation avec l'office du Médecin cantonal. Le dispositif d'identification doit permettre à garantir la fiabilité des données collectées aux fins d'identification des personnes présumées infectées, en particulier le nom, le prénom et le numéro de téléphone mobile. Les données sont conservées 14 jours avant destruction. Les données recueillies doivent être rendues accessibles

en tout temps aux autorités sanitaires dans un format défini par ces dernières ».

Dans le document intitulé « Covid-19 — Dispositifs d'identification de la clientèle dans les établissements de restauration — Procédure de vérification technique — 15 octobre 2020 » (dont l’auteur n'est pas identifiable), soumis au PFPDT par les représentants des parties en annexe au courrier du 23.04.2021, il a été prévu que «les dispositifs d'identification doivent répondre aux spécifications techniques suivantes : [...] — permettre l'enregistrement des données des clients et du personnel sur la base de données centralisée gérée par SwissHelios Sàrl ».

Le même document prévoit, un peu plus bas, qu’« en cas de besoin, l'OMC [office du médecin cantonal] se rend sur la base de données, entre le nom de l'établissement X à une date et une heure T et peut extraire un fichier CSV contenant la liste des clients et du personnel présents à ce moment. Pour accéder aux données, l'OMC ne doit pas avoir besoin de passer par l'exploitant de l'établissement ou par les dispositifs d'identification ». S’il est vrai que la Directive du 15 septembre 2020 est de nature générale et abstraite, force est de constater qu'elle ne fixe que dans des termes très généraux que les restaurateurs vaudois doivent utiliser un dispositif d'identification de manière systématique et que ce dispositif doit être homologué par la faîtière de la branche, en concertation avec l'office du Médecin cantonal.

Pour le reste, et notamment pour la question de savoir si les données collectées doivent être enregistrées sur une base de données centralisée accessible directement par les autorités publiques, cette disposition prévoit que les autorités sanitaires sont libres dans le choix des traitements de données mis en place. Ainsi, l'enregistrement dans une base de données centralisée ainsi que le droit d'accès direct octroyé aux autorités sanitaires a été prévu dans le document « Covid-19 — Dispositifs d'identification de la clientèle dans les établissements de restauration — Procédure de vérification technique — 15 octobre 2020 ».

Cet extrait de document, dont la nature juridique reste peu claire, ne constitue clairement pas la nature d'une norme générale et abstraite qui pourrait justifier l'accès dépassant le cadre de la législation fédérale pertinente des autorités sanitaires. Le PFPDT ne saurait donc admettre que l'accès direct sur la base de données centralisée permettant des recherches ciblées presque indéfinies octroyé au Médecin cantonal vaudois se fonde sur une base légale au sens de l'art. 13 al. 1° LPD.

En ce qui concerne un éventuel intérêt public prépondérant comme motif justificatif au sens de l'art. 13 LPD, il convient de relever que la lutte contre la pandémie est une tâche publique et non une tâche qui incombe aux personnes privées, pour quelque raison que ce soit, elle est régie par le droit public. Le fait que la base légale pertinente du Conseil fédéral ne prévoit pas d'accès direct doit également être considéré comme une indication que des droits d'accès aussi étendus n'ont pas été jugés nécessaires pour lutter contre la pandémie, et montre qu'il s'agit d'un traitement de données inutile et donc

disproportionné.

Dans le canton du Valais, l'usage du système SocialPass a été rendu obligatoire par Décision du Conseil d'Etat du 2 décembre 2020 qui se lit comme suit: « la mise en œuvre de l'application électronique de traçage SocialPass est obligatoire (à défaut une liste exhaustive de tous les clients ». Par ailleurs, les détails de la mise à disposition du système SocialPass en Valais ont été définis dans le cadre d'une convention passée entre l'Etat du Valais, représenté par le Chef de son Service de la santé publique, et la société NewCom4U Sarl, à la fin de l’année 2020. L'art. 2.1. dudit contrat oblige la société NewCom4U Särl à fournir une « base de données pour le traçage via scan ou autoscan de l'ID SocialPass ». Dans ce cadre, les SocialPass scannés dans les établissements sont stockés dans la base de données gérée par le mandataire et hébergés dans les serveurs Microsoft Azure localisés dans le canton de Zurich ». La même disposition contractuelle prévoit, un peu plus bas, que « [lle mandataire développe, d'entente et sur la base d'un cahier des charges de l'Office du médecin cantonal, et supporte la base de données consultable par le Médecin cantonal et ses collaborateurs ; le mandataire assure à

+)

cet effet le respect des exigences du Service cantonal de l'informatique pour permettre la consultation des données par le Médecin cantonal et ses collaborateurs depuis le réseau informatique de

l'administration cantonale ».

La convention conclue entre la société NewCom4U Sarl et l'Etat du Valais, représenté par le Chef de son Service de la santé publique, ne constitue pas une norme générale et abstraite pouvant justifier un traitement de données au sens de l’art. 13 al. 1° LPD. Dans ce cadre également, il n'existe donc pas de base juridique suffisante qui pourrait justifier un droit d'accès aussi étendu octroyé aux autorités

sanitaires.

Il découle de ce qui précède que l'accès direct sur la base de données centralisée sous sa forme actuelle {prévoyant des possibilités de recherches ciblées), octroyé aux autorités cantonales, dépasse le traitement de données tel que prévu et justifié par le droit fédéral actuellement en vigueur et qu'il n'est pas justifié par une base légale cantonale au sens de l’art. 13 al. 1° LPD (norme générale et abstraite) et s'avère comme disproportionne.

Les responsables de SocialPass doivent donc limiter l'accès des autorités sanitaires susmentionnées

aux données nécessaires pour une collecte légale des coordonnées.

(2) Recommandations :

La possibilité d'accès direct à la base de données centrale doit être limitée à ce qui est strictement nécessaire à la collecte légale des coordonnées, de sorte qu'elle soit proportionnée ; en particulier, la possibilité de rechercher des personnes doit être éliminée de cette manière.

Suite à l'élaboration puis à la notification du rapport et des recommandations dans leur version du 28 mai 2021, deux modifications du cadre légal tel que décrit au chapitre 3.2.2 doivent être relevées. Ces modifications mettent en évidence l'absence de base légale justifiant les possibilités de recherches ciblées telles que contestées dans la recommandation (2) de sorte qu'aucune modification de cette recommandation n'est indiquée.

D'une part, il convient de noter que lors de la visioconférence du 7 juin 2021, le PFPDT a été informé que la Directive du 15 septembre 2020 COVID-19 / Coronavirus du Chef du Département de l’économie, de l'innovation et du sport ainsi que de la Cheffe du Département de la santé et de l’action sociale vaudois a été abrogée en janvier 2021 bien que les représentants légaux de SocialPass aient justifié le traitement en invoquant cette base légale dans leur courrier du 23 avril 2021. Dès lors, les développements juridiques figurant au chapitre 3.2.2 du présent rapport ne sont plus pertinents. En d’autres termes, dans le canton de Vaud, le traitement de données tel que prévu par le système SocialPass n'est plus qu’encadre par le droit fédéral. Ainsi, en ce qui concerne un éventuel intérêt public prépondérant comme motif justificatif au sens de l'art. 13 LPD, il convient de réitérer que la lutte contre la pandémie est une tâche publique et non une tâche qui incombe aux personnes privées. Pour quelque raison que ce soit, cette tâche est régie par le droit public. Dans les cantons où une disposition cantonale fait défaut, cette tâche est exclusivement régie par le droit public fédéral. La base légale pertinente du Conseil fédéral ne prévoit pas d'accès direct à une base de données centralisée. Les droits d'accès aussi étendus que ceux prévus par le système SocialPass n'ont donc pas été jugés nécessaires pour lutter contre la pandémie et ne sont dès lors par justifiés sur la seule base légale pertinente dans le

canton de Vaud.

D'autre part, l'Ordonnance du Conseil fédéral Covid-19 situation particulière, qui encadre la collecte des coordonnées dans les établissements accessibles au public a fait l'objet d'une révision totale de sorte que la structure et la numérotation des articles ont changé.® L'art. 11 de l'Ordonnance (auparavant l'art. 5) est désormais la disposition essentielle pour la collecte des données des visiteurs. En sus des changements formels, l'obligation de collecter les coordonnées des visiteurs a été réduite : dans les restaurants, les clients doivent uniquement partager leurs coordonnées s'ils prennent place à l'intérieur. De plus, une seule personne par groupe doit communiquer ses coordonnées à l'exploitant de l'établissement. Dans les discothèques, l'obligation de collecter les coordonnées des clients a été supprimée. L'accès à ces événements est toutefois réservé aux personnes en possession d’un certificat Covid-19 (Art. 13 Ordonnance COVID-19 situation particulière). Dans les centres de sports et lors d'événements culturels, les coordonnées doivent toujours être collectées. Les changements susmentionnés sont entrés en vigueur le 26 juin 2021.

3.3. Option « saisie manuelle »

Le PFPDT constate que, d'une part, les coordonnées des clients réguliers sont enregistrées localement sur l'appareil et que, d'autre part, il est possible d'exporter ces données vers d'autres appareils au moyen d'un code QR. En outre, toutes les coordonnées des clients réguliers sont affichées sur les appareils utilisés par les établissements.

Avec la procédure choisie, la mise en œuvre de l'art. 5 LPD (exactitude des données) requiert un effort organisationnel considérable et ne permet même pas d’exclure certaines erreurs. Ainsi, les demandes

d'information, de rectification ou d’effacement ne peuvent être traitées que de manière incomplète.

En outre, l'affichage de toutes les données de contact viole le principe de proportionnalité tel que consacré à l'art. 4 al. 2 LPD (d'un point de vue temporel et quantitatif), car l'établissement peut consulter

$ Communiqué du Conseil fédéral du 23.06.2021 https://www.bag.admin.ch/bag/fr/nome/dasbag/aktuell/medienmitteilungen.msg-id-84127.htmi.

à tout moment d’avantage de données sur une personne que ce qui est nécessaire pour identifier le client. |

(3) Recommandation concernant la liste des clients réguliers SocialScan

SocialPass adapte les processus et les fonctions de collecte et de mise à disposition des coordonnées des personnes recourant plusieurs fois à l'application (par ex. les clients réguliers) de sorte que

- la collecte des coordonnées ne soit pas effectuée par le personnel de service,

- les coordonnées des clients réguliers que l'établissement a enregistrées puissent être effacées ou rectifiées à la demande de ces clients,

- la synchronisation de la liste des clients réguliers permette d'éviter des statuts de données différents au sein de la même structure, et que les données soient soumises à un cycle de vie axé sur la finalité,

- seules les coordonnées nécessaires à l'identification de la liste des clients réguliers puissent être consultées (principe de minimisation des données).

34. Transferts des numéros de téléphone aux Etats-Unis

Comme indiqué ci-dessus (ch. 2.5.2), les numéros de téléphone mobile des utilisateurs sont transmis au Service Twilio, et donc aux États-Unis d'Amérique dans le cadre du processus de vérification.

Les États-Unis tombe dans la catégorie des pays tiers ne disposant pas d'une législation adéquate au sens de l’art. 6 al. 1° LPD’. En dépit de l'absence d’une législation assurant un niveau de protection adéquat à l'étranger, l'art. 6 al. 2 LPD prévoit que des données personnelles peuvent être communiquées à l'étranger, à l’une des conditions prévues par cet alinéa. En l'espèce, aucune condition fixée à l’art. 6 al. 2 LPD n'est remplie. Le PFPDT relève avant tout que des garanties suffisantes, notamment de nature contractuelle, font défaut. Il découle de ce qui précède qu'un niveau de protection adéquat n'a pas été assuré par les responsables.

Même si l'intérêt (public) invoqué par les responsables afin de justifier la vérification des numéros semble compréhensible dans le contexte actuel, force est de constater qu'il n’est pas apparent pour quelles raisons il serait nécessaire de recourir à un service situé aux États-Unis, au lieu de mandater un service similaire ayant son siège dans un pays offrant un niveau de protection des données adéquat.

Par ailleurs, le PFPDT relève que les personnes concernées ne sont pas informées du transfert de leur numéro de téléphone aux États-Unis, ni même de l'utilisation du service Twilio. Aucune information à

7 Liste des Etats ayant une législation assurant un niveau de protection adéquat, publié sous https://www.edoeb.admin.ch/dam/edoeb/fr/dokumente/2020/staatenliste. pdf.download.pdf/20200908_Staatenliste_f.pdf propos de Twilio n'est disponible ni sur le site internet ni dans les App-Store. Ce manque d’information constitue une violation du principe de transparence (art. 4 al. 4 LPD).

(4) Recommandation concernant le service de vérification des numéros

SocialPass apporte des garanties manifestes (p.ex. au moyen d'un accord avec Twilio) pour qu'un niveau de protection adéquat soit garanti dans le cadre du transfert des numéros de téléphone des utilisateurs au service « Twilio » aux Etats-Unis ;

Alternativement, SocialPass recourt à un service alternatif qui n'implique pas un transfert vers un pays étranger dont le niveau de protection est inadéquat.

Les utilisateurs sont informés de manière transparente sur le transfert des données au service de tiers (Twilio ou autre), des modalités d'enregistrement et des possibilités de demander l'effacement des propres données.

3.5. Stockage centralisé et permanent du numéro de téléphone mobile dans le processus d'enregistrement

Le PFPDT note que, pour que le traçage des contacts fonctionne, il est entre autres nécessaire que le numéro de téléphone mobile soit saisi dans SocialPass. Les numéros sont vérifiés au moyen du service OTP américain Twilio (cf. chapitre 2.5.2).

Les numéros de téléphone sont également enregistrés de manière centralisée dans la base de donnée Azure. Rien n'a été prévu quant à leur effacement. Les utilisateurs ne sont pas informés de manière transparente ni de l'enregistrement ni de l'utilisation que Twilio fait de leur numéro. De tels traitements de données ne répondent pas aux exigences fixées dans la LPD, notamment au principe de transparence tel que consacré à l'art. 4 al. 4 LPD. En outre, sur la base de l'art. 4 al. 2 LPD, le stockage centralisé du numéro de téléphone mobile lors du processus d'enregistrement est disproportionné (du point de vue temporel) dans la mesure où ce numéro est conservé pour une durée illimitée, c'est-à-dire une durée allant au-dela de ce qui est nécessaire pour la lutte contre le COVID-19.

(5) Recommandation concernant l’enregistrement centralisé et permanent du numéro de téléphone mobile dans le processus d'enregistrement

SocialPass adapte le processus d'inscription des utilisateurs de sorte que

- l'enregistrement centralisé du numéro de téléphone mobile soit limité au strict nécessaire pour le traitement visé, notamment en ce qui concerne la durée de l'enregistrement (au plus tard lorsque la situation particulière prend fin) ;

- les utilisateurs, avant d'installer l'application, soient informés de manière transparente quant au traitement de leur numéro de téléphone mobile ;

- les utilisateurs soient informés de leurs droits et, en particulier, de la manière dont elles peuvent exercer leurs droits pour que les données en lien avec l'enregistrement du numéro de téléphone mobile soient effacées.

3.6. Microsoft Azure (base de données SQL)

Deux des trois composants (SocialPass et SocialScan) ont fait l'objet d'une évaluation externe de la sécurité. Le troisième composant (base de données centrale sur Azure) n'a pas été audité au motif que Microsoft est responsable de la sécurité. Le PFPDT relève toutefois qu’en raison de plusieurs risques être en mesure d'expliquer plus en détails pourquoi ils ont renoncé à un audit adéquat.L'application SocialPass communique avec une infrastructure centrale (backend) hébergée chez Microsoft Azure. Avec Azure, beaucoup de réglages sont prédéfinis, mais d'autres doivent être ajustés manuellement, comme les alertes et les accès utilisateurs. Pour la sécurité de la base de données Azure SQL, il est recommandé d'utiliser Azure Sentinel. Cela permet de recueillir des données sur l'ensemble des utilisateurs, des appareils, des applications et des infrastructures et de détecter et d'analyser les

menaces.

Azure Sentinel ne permet toutefois pas de configurer, par exemple, des autorisations d'accès pour une base de données SQL. Or, conformément à l'art. 7 LPD, une telle configuration est obligatoire du point de vue de la sécurité des données. SocialPass n'a pas encore confirmé au PFPDT que la configuration dans Azure est mise en œuvre conformément au WhitePaper et à la Baseline® applicables (voir cidessous). Le PFPDT constate donc que les recommandations faites par Microsoft (Azure security baseline) sur la protection de la base de données SQL dans Azure sont insuffisamment mises en œuvre

par SocialPass.

(6) Recommandation concernant la configuration et le renforcement de Microsoft Azure

SocialPass configure la plateforme Microsoft Azure de sorte que

a) les mesures de sécurité de la Baseline et du WhitePaper [I] de Microsoft soient mises en œuvre,

b) la vérification de l'efficacité et la mise en œuvre de ces mesures puissent être prouvées.

3.7. Divers aspects de sécurité des données Les responsables ont affirmé que des améliorations concernant la sécurité des données ont été mises en place, sans toutefois les concrétiser. Les recommandations suivantes dans le domaine de la sécurité

$ https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/sql-database-security-baseline (état au 21.4.2021).

des données sont donc formulées sous réserve que les vulnérabilités mises en lumière dans

l'établissement des faits du 20 mai 2021 n'ont pas été corrigées entre-temps.

3.7.1. Gestion des vulnérabilités

Le PFPDT note que les audits externes ont décelé des vulnérabilités. Celles-ci ont été évaluées du point de vue de la sécurité informatique, mais pas de la sécurité des données au sens de l'art. 7 LPD en relation avec l'art. 8 OLPD. Cet aspect a fait l’objet d'une premiere évaluation, par le PFPDT, dans la section 2.9.4 Afin de garantir la sécurité des données conformément à l'art. 7 LPD, il faudrait classer toutes les vulnérabilités (risques élevés comme faibles) de manière décroissante selon leur dangerosité du point de vue du droit de la protection des données.

(7) Recommandation concernant la gestion des vulnérabilités SocialPass adapte les applications SocialPass et SocialScan de sorte que

a) les vulnérabilités relevées dans les rapports d'audit [A] [B] et [C] soient éliminées en fonction des risques qu'elles représentent,

b) les vulnérabilités concernant la protection des données, en particulier, soient éliminées sans délai.

3.7.2. Mise en place d'une authentification forte

Le PFPDT constate que, sur la base des informations fournies, il n'est pas possible de savoir quels composants du système SocialPass sont sécurisés par l'authentification à deux facteurs et donc protégés contre tout accès, modification ou destruction non autorisés, si l'on se réfère à l’état actuel de la technique et à l'art. 7 LPD en relation avec l'art. 8 s. OLPD.

(8) Recommandation concernant la mise en place d’une authentification forte

SocialPass revoit l'accès à tous ses composants de sorte que ceux-ci, en fonction de l’état actuel de la technique, permettent une authentification robuste, voire y soient obligatoirement soumis si la protection des données l'exige.

3.7.3. Utilisation disproportionnée d'identifiants

Le PFPDT note que, outre le numéro de téléphone, le traitement des données dans le cadre de SocialPass englobe l'IMEI (International Mobile Equipment Identity, un numéro de série unique à quinze chiffres pour les appareils) et, dans le cas d'Android, également un UID (Unique ID) du numéro d'utilisateur provenant de Google Firebase. La saisie des données de contact en vue du traçage vise toutefois les personnes et non les appareils. Les opérateurs n'ont pas expliqué, et les informations disponibles n'indiquent pas clairement en quoi l'utilisation de ces identifiants est nécessaire.

Par conséquent, il est inutile, et par ce fait, disproportionne du point de vue de l'art. 4 al. 2 LPD, d’utiliser des identifiants spécifiques aux appareils et aux applications à cette fin. Les numéros de téléphone peuvent très bien être vérifiés sans que ces identifiants soient utilisés.

(9) Recommandation concernant le traitement des identifiants d’appareils

SocialPass renonce au traitement des identifiants qui ne sont pas nécessaires à la lumière de la finalité poursuivie, notamment IMEI, Firebase-ID et Unique ID provenant de Google Firebase.

3.7.4. Organisation et documentation relatives à la sécurité des données

Les responsables de SocialPass n'ayant pas soumis de documentation relative a la sécurité des données, dans le cadre de la présente procédure, portant sur les responsabilités en la matière, le PFPDT part du principe qu'une telle documentation fait défaut.

Le PFPDT constate en outre qu'il n'existe pas de règlement de traitement au sens de l'art. 11 OLPD incluant une stratégie de sécurité (notamment celle des données) pour SocialPass et SocialScan. Un tel règlement sert à mettre en œuvre et à documenter la stratégie de sécurité et décrit les mesures techniques et organisationnelles mises en œuvre au sens de l'art. 7 LPD.

En vertu de l’art. 11a al. 5 lit a LPD, les responsables de la base de données ne sont pas soumis à l'obligation de déclaration d’un fichier, s'il est assumé que les données sont traitées par une personne privée en vertu d’une obligation légale. Par contre, l'art. 11 OLPD prévoit l'obligation d'élaborer un règlement de traitement pour les fichiers automatisés, y compris pour les maîtres de fichiers déliés de l'obligation de déclaration à condition que cette exception soit basée sur la lettre a de l'art. 11a al. 5 LPD.

(10)Recommandation concernant la documentation relative à la sécurité des données :

Les responsables de SocialPass se dotent d'un règlement de traitement portant notamment sur la sécurité des données et proposant une stratégie de sécurité documentée qui

a) comprenne des mesures organisationnelles et techniques relatives à la sécurité des données qui soient en phase avec l'état actuel de la technique,

b) attribue de manière claire et documentée les tâches qu’elle prévoit aux différents acteurs,

c) soit régulièrement contrôlée quant à l'efficacité de sa mise en œuvre.

4. Prises de position des parties

4.1. Remarques préliminaires relatives au droit d’être entendu

Ni l'art. 29 LPD ni Part. 34 OLPD ne contiennent des règles spécifiques quant aux divers délais à respecter dans le cadre d’une procédure d'établissement des faits. La pratique du PFPDT en tant qu’autorité fédérale indépendante consiste à garantir un délai de réponse raisonnable aux parties afin que ces dernières puissent exercer leur droit d’être entendu. Si le PFPDT est tenu de garantir le droit d'être entendu aux parties impliquées dans une procédure d'établissement des faits, les parties ellesmêmes ont un devoir de collaboration consacré à l'art. 34 LPD.

Lorsque le PFPDT fixe les différents délais au cours de la procédure d'établissement des faits, il procède toujours aussi à une pesée des intérêts. D'une part, il prend en compte le besoin pour les parties d'avoir le temps de préparer leurs soumissions. D'autre part, il estime que les parties ont un devoir de collaborer et qu'il leur appartient de lui transmettre toute information utile au bon déroulement de la procédure, p.ex. lorsque certains éléments de faits subissent un changement en cours de procédure. Enfin, étant donné qu’une procédure d'établissement des faits n’est qu’engagée en cas d’« erreur de système », c'est-à-dire lorsqu'un traitement risque de porter atteinte à la personnalité d'une multitude de personnes, l'intérêt du public à être informé le plus tôt possible de cette erreur de système est pris en compte dans la pesée des intérêts.

La présente procédure porte sur une application numérique proposée par deux entreprises privées dans toute la Suisse pour lutter contre la pandémie actuelle. Cette application traite des données personnelles et affecte tout particulièrement la population des cantons de Vaud et Valais, notamment en raison des exigences des autorités sanitaires de ces deux cantons. Dans ce contexte, le PFPDT s'est efforcé de faire aboutir la procédure d'établissement des faits en temps utile. Toutefois, cette procédure s’est avérée exceptionnellement longue et compliquée. Lors de la fixation des délais de réponse et de l'évaluation des nombreuses demandes de prolongation de délais reçues (cf. chapitre 1.4), le PFPDT a donc, entre autres, dû tenir compte du fait que, la deuxième vague de la pandémie s'est calmée au début de l'été 2021. Cette évolution épidémiologique a eu pour conséquence que les restaurants ont pu rouvrir à ce moment-là. Ainsi, une reprise de l'utilisation de l'application SocialPass était imminente. Le PFPDT a donc estimé que la sensibilisation de la population aux risques du traitement de données était urgente.

4.2. Prise de position des parties relative aux faits &tablis le 20 mai 2021

Dans le cadre de la présente procédure, notamment au vu de la réouverture des terrasses des restaurants le 19 avril 2021, le PFPDT a remis des recommandations provisoires aux parties le 7 avril 2021. Le 23 avril 2021, les parties ont refusé ces recommandations par courrier de Lexing Switzerland.

Par lettre du 20 mai 2021, le PFPDT a ensuite communiqué aux parties les faits tels qu’établis au chapitre 2 afin qu'elles puissent prendre position. Au vu de la réouverture de l'intérieur des restaurants le 31 mai 2021, le PFPDT a estimé qu'un délai de réponse d'une semaine était approprié au regard des circonstances particulières de la présente affaire. Les parties ont décidé de laisser expirer le délai de réponse fixé au 27 mai 2021, notamment après que le PFPDT ait rejeté et leur demande de prolongation de délai d'au moins 30 jours et la demande de récusation des collaborateurs en charge du dossier soumise par Lexing Switzerland.

4.3. Prise de position des parties relative au rapport final et aux recommandations du 28 mai 2021

Par courrier du 28 mai 2021, le PFPDT a informé les parties de la fin de la présente procédure d'établissement des faits, leur a remis le présent rapport et les recommandations y relative dans leur version du 28 mai 2021 et les a invitées à lui faire savoir dans un délai de 30 jours, conformément à l'art. 29 al. 4 PFPDT, si elles acceptaient ou rejetaient les recommandations.

Par courrier du 14 juin 2021 au PFPDT, Lexing Switzerland a notifié la fin de son mandat dans la présente procédure. Cette fin de mandat a conduit le PFPDT à accorder une prolongation du délai de 30 jours jusqu'au 16 juillet 2021, notamment à la suite d'une demande des parties désormais agissant pour leur propre compte. Après que les parties aient révoqué la demande de récusation du personnel du PFPDT, deux visioconférences constructives ont eu lieu entre elles et le PFPDT le 7 et le 24 juin 2021, auxquelles ont également participé les autorités de santé et de protection des données ainsi que les associations de la gastronomie des cantons de Vaud et Valais. Sur la base des échanges qui ont eu lieu dans le cadre de ces deux visioconférences, les exploitants de SocialPass ont soumis, le 9 juillet 2021, une prise de position par rapport aux recommandations émises par le PFPDT dans son rapport notifié le 28 mai 2021. Le présent chapitre traite en détail des réponses reçues.

4.3.1. Recommandation (1) concernant les rôles et les responsabilités

La recommandation (1) formulée ci-dessus au chapitre 3.1 et reprise ci-dessous est la suivante:

(1) Recommandation rôles et responsabilités

Les sociétés NewCom4U Sarl et SwissHelios Sarl doivent uniformiser tous les documents (site web, appstores et app) afin de respecter leurs obligations légales en tant que maîtres du fichier au sens de l’art. 3 lit. i LPD.

Les exploitants de SocialPass confirment avoir donné suite à cette recommandation, toutefois sans apporter de précisions (l'affirmation correspondante est limitée à « fait »). En tout état de cause, le PFPDT prend note que les parties acceptent la recommandation (1) concernant les rôles et les responsabilités.

Le PFPDT constate en plus que, notamment dans la déclaration de confidentialité publiée sur le site web de SocialPass, seule l'entreprise NewCom4U Sarl est mentionnée comme maître du fichier. Toutefois, cela ne correspond pas à I appréciation du PFPDT (cf. chapitre 3.1) selon laquelle les deux sociétés doivent être considérées conjointement comme maîtres du fichier. La responsabilité commune doit être rendue transparente, c'est-à-dire que les deux maîtres du fichier doivent figurer de manière

cohérente dans la documentation.

La recommandation (1) concernant les rôles et responsabilités n'a donc pas encore été complètement mise en œuvre à l'heure actuelle.

4.3.2. Recommandation (2) concernant la base de données centrale La recommandation (2) formulée ci-dessus au chapitre 3.2 et reprise ci-dessous est la suivante :

(2) Recommandation

La possibilité d'accès direct à la base de données centrale doit être limitée à ce qui est strictement nécessaire à la collecte légale des coordonnées, de sorte qu'elle soit proportionnée ; en particulier, la possibilité de rechercher des personnes doit être éliminée de cette manière.

Les exploitants de SocialPass confirment avoir donné suite à cette recommandation centrale, toutefois sans apporter de précisions (l'affirmation correspondante est limitée a « fait »). En tout état de cause, le PFPDT prend note que les parties acceptent la recommandation (2) concernant l'accès direct à la base de données centrale et la possibilité de rechercher des personnes.

4.3.3. Recommandation (3) concernant la liste des clients réguliers SocialScan La recommandation (3) formulée ci-dessus au chapitre 3.3 et reprise ci-dessous est la suivante :

(3) Recommandation concernant la liste des clients réguliers SocialScan

SocialPass adapte les processus et les fonctions de collecte et de mise à disposition des coordonnées des personnes recourant plusieurs fois à l'application (par ex. les clients réguliers) de sorte que

- la collecte des coordonnées ne soit pas effectuée par le personnel de service,

- les coordonnées des clients réguliers que l'établissement a enregistrées puissent être effacées ou rectifiées à la demande de ces clients,

- la synchronisation de la liste des clients réguliers permette d'éviter des statuts de données différents au sein de la même structure, et que les données soient soumises à un cycle de vie axé sur la finalité,

- seules les coordonnées nécessairés à l'identification de la liste des clients réguliers puissent être consultées (principe de minimisation des données).

A propos de cette recommandation, la prise de position des exploitants de SocialPass se lit comme suit:

« Ces informations ne sont disponibles que sur les appareils SOCIALSCAN des restaurants et pas dans la base centrale.

a) Cette recommandation n'est pas praticable dans la perspective d'une personne âgée qui veut donner ses informations dans l'application. C'est donc au personnel que revient la tâche de saisir ces informations.

b) Cette n'existe pas pour l'instant et nous prévoyions de l'implémenter dans une prochaine phase de développement.

c) Le processus de synchronisation est basé sur la finalité car il permet une collecte de données conforme.

d) Seules les informations minimales sont recueillies actuellement ».

Le PFPDT déduit de cette réponse que les exploitants acceptent partiellement les recommandations (3) concernant la liste des clients réguliers SocialScan. Il prend acte des remarques quant à la praticabilité de la mise en œuvre des recommandations et décidera de la suite à donner à cette réponse dans le cadre d'éventuelles contrôles de suivi.

4.3.4. Recommandation (4) concernant le service de vérification des numéros La recommandation (4) formulée ci-dessus au chapitre 3.4 et reprise ci-dessous est la suivante :

(4) Recommandation concernant le service de vérification des numéros

SocialPass apporte des garanties manifestes (p.ex. au moyen d'un accord avec Twilio) pour qu'un niveau de protection adéquat soit garanti dans le cadre du transfert des numéros de téléphone des utilisateurs au service « Twilio » aux Etats-Unis ;

Alternativement, SocialPass recourt à un service alternatif qui n'implique pas un transfert vers un pays étranger dont le niveau de protection est inadéquat.

Les utilisateurs sont informés de manière transparente sur le transfert des données au service de tiers (Twilio ou autre), des modalités d'enregistrement et des possibilités de demander l'effacement des propres données.

À propos de cette recommandation, les exploitants de SocialPass ont soumis au PFPDT la prise de position suivante : « Twilio a établie des mesures de protection de données qui étaient approuvé par la Communauté Européenne. Binding Corporate Rules et https:/Avww.twilio.com/gdpr

Nous considérons que cela suffise comme garantie manifeste du niveau de protection de données.

Twilio ne dispose seulement d'un numéro de téléphone qui n'est pas associé à un nom. Donc personne ne pourrait dire je suis xy veuillez effacer mon numéro tel. Le nom xy n'est pas dans la base de données, seulement un no. de tel. sans identifiant »

Les exploitants n'expliquent pas dans quelle mesure les mesures présentées répondent aux exigences du PFPDT en matière de garanties suffisantes au sens de la LPD®. Les exploitants ne se prononcent

pas non plus sur l'aspect de la reconnaissabilité du traitement.

Le PFPDT déduit de cette réponse que les exploitants n'acceptent pas les recommandations (4) concernant le service de vérification des numéros. Il décidera de la suite à donner à cette réponse dans le cadre d'éventuelles contrôles de suivi.

4.3.5. Recommandation (5) concernant l'enregistrement centralisé et permanent du numéro de téléphone mobile dans le processus d'enregistrement

La recommandation (5) formulée ci-dessus au chapitre 3.5 et reprise ci-dessous est la suivante :

(5) Recommandation concernant lenregistrement centralisé et permanent du numéro de téléphone mobile dans le processus d'enregistrement

SocialPass adapte le processus d'inscription des utilisateurs de sorte que

- l'enregistrement centralisé du numéro de téléphone mobile soit limité au strict nécessaire pour le traitement visé, notamment en ce qui concerne la durée de l'enregistrement (au plus tard lorsque la situation particulière prend fin),

- les utilisateurs, avant d'installer l'application, soient informés de manière transparente quant au traitement de leur numéro de téléphone mobile,

- les utilisateurs soient informés de leurs droits et, en particulier, de la manière dont elles peuvent exercer leurs droits pour que les données en lien avec l'enregistrement du numéro de téléphone mobile soient effacées.

À propos de cette recommandation, la prise de position des exploitants de SocialPass se lit comme suit:

« L'enregistrement centralisé du numéro de téléphone est limité comme recommandé. Les utilisateurs sont informés par la publication en httos:/Avww.socialpass.ch/mentionslegales/ »

8 Cf. https:/Awww.edoeb.admin.ch/edoeb/fr/home/protection-des-donnees/handel-und-wirtschaft/uebermittlung-ins-ausland.html

Le PFPDT prend note que les parties acceptent la recommandation (5) concernant l'enregistrement

centralisé et permanent du numéro de téléphone mobile dans le processus d'enregistrement.

Cependant, le PFPDT constate que la déclaration de confidentialité mentionnée ne porte que sur l'utilisation des données collectées pour le traçage des contacts. Or, la recommandation susmentionnée fait référence au stockage du numéro de téléphone au cours du processus d'enregistrement.

En raison de ce manque de clarté, le PFPDT estime que cette recommandation n'a pas été suivie de mesures concrètes et il en déduit que la recommandation n'a pas encore été mise en place

complètement à l'heure actuelle.

4.3.6. Recommandation (6) concernant la configuration et le renforcement de Microsoft Azure La recommandation (6) formulée ci-dessus au chapitre 3.6 et reprise ci-dessous est la suivante :

(6) Recommandation concernant la configuration et le renforcement de Microsoft Azure

SocialPass configure la plateforme Microsoft Azure de sorte que

a) les mesures de sécurité de la Baseline et du WhitePaper [I] de Microsoft soient mises en œuvre, |

b) la vérification de l'efficacité et la mise en œuvre de ces mesures puissent être prouvées.

La réponse des exploitants de SocialPass à cette recommandation se lit comme suit:

« En cours d'implémentation. Disponible d'ici la fin du mois d'août. »

Le PFPDT prend note que les parties acceptent la recommandation (6) concernant la configuration et le renforcement de Microsoft Azure et attend les preuves correspondantes dès que la mise en œuvre de cette recommandation aura eu lieu.

4.3.7. Recommandation (7) concernant la gestion des vulnérabilités La recommandation (7) formulée ci-dessus au chapitre 3.7.1 et reprise ci-dessous est la suivante :

(7) Recommandation concernant la gestion des vulnérabilités SocialPass adapte les applications SocialPass et SocialScan de sorte que

a) les vulnérabilités relevées dans les rapports d'audit [A] [B] et [C] soient éliminées en fonction des risques qu'elles représentent,

b) les vulnérabilités concernant la protection des données, en particulier, Soient éliminées sans délai.

Les exploitants de SocialPass confirment avoir donné suite à cette recommandation, toutefois sans apporter de précisions (l'affirmation correspondante est limitée à « fait »). En tout état de cause, le PFPDT prend note que les parties acceptent la recommandation (7) concernant la gestion des

vulnérabilités.

4.3.8. Recommandation (8) concernant la mise en place d'une authentification forte La recommandation (8) formulée ci-dessus au chapitre 3.7.2 et reprise ci-dessous est la suivante :

(8) Recommandation concernant la mise en place d’une authentification forte

SocialPass revoit l'accès à tous ses composants de sorte que ceux-ci, en fonction de l'état actuel de la technique, permettent une authentification robuste, voire y soient obligatoirement soumis si la protection des données l'exige.

Les exploitants de SocialPass confirment avoir donné suite à cette recommandation, toutefois sans apporter de précisions (l'affirmation correspondante est limitée à « fait »). En tout état de cause, le PFPDT prend note que les parties acceptent la recommandation (8) concernant la mise en place d’une authentification forte.

4.3.9. Recommandation (9) concernant le traitement des identifiants d'appareils La recommandation (9) formulée ci-dessus au chapitre 3.7.3 et reprise ci-dessous est la suivante :

(9) Recommandation concernant le traitement des identifiants d’appareils

SocialPass renonce au traitement des identifiants qui ne sont pas nécessaires à la lumière de la finalité poursuivie, notamment IMEI, Firebase-ID et Unique ID provenant de Google Firebase.

La prise de position par rapport à cette recommandation se lit comme suit:

« Nous utilisons un identifiant qui ne correspond pas à IMEI ou FIREBASE-ID mais qui est unique et généré par l'application SocialPass ».

Le PFPDT conclut de cette réponse que les exploitants de SocialPass acceptent la recommandation

(9) concernant le traitement des identifiants d'appareils.

4.3.10. Recommandation (10) concernant la documentation relative à la sécurité des données La recommandation (10) formulée ci-dessus au chapitre 3.7.4 et reprise ci-dessous est la suivante :

(10) Recommandation concernant la documentation relative à la sécurité des données :

Les responsables de SocialPass se dotent d’un règlement de traitement portant notamment sur la sécurité des données et proposant une stratégie de sécurité documentée qui

a) comprenne des mesures organisationnelies et techniques relatives à la sécurité des données qui soient en phase avec l'état actuel de la technique,

b) attribue de manière claire et documentée les tâches qu'elle prévoit aux différents acteurs,

c) soit régulièrement contrôlée quant à l'efficacité de sa mise en œuvre.

La prise de position par rapport à cette recommandation se lit comme suit :

« a) Nous allons nous doter d’un organigramme avec des fonctions dédiées à la sécurité des données. Il sera constitué d'un organe de direction qui veillera à l'application des normes en vigueur concernant la protection des données.

b) Nous allons déléguer les tâches de documentation des processus et de l'exécution de ces processus auprès d'une compagnie externe.

c) Nous allons nous doter d'un organe de vérification de l'exécution et de la maintenance des processus décrit au point b ».

Le PFPDT conclut de cette réponse que les exploitants de SocialPass acceptent cette recommandation. II attend les preuves correspondantes dès que la mise en œuvre de cette recommandation aura eu lieu.

5. Conclusion

Depuis le début de la procédure d'établissement des faits, qui s'est avérée exceptionnellement longue et compliquée, des ajustements importants ont été effectués par les responsables de SocialPass. En particulier, les exploitants de SocialPass ont affirmé avoir mis en œuvre la recommandation (2) concernant l'accès direct à la base de données centrale. Dès lors, le PFPDT suppose que les utilisateurs de SocialPass ne sont plus exposés à un accès potentiellement excessif sur leurs coordonnées de la part des autorités sanitaires (via une recherche ciblée des personnes dans la base de données centrale). De plus, les exploitants ont confirmé au PFPDT que les faiblesses techniques — en particulier celles relevées dans les recommandations (6) à (10) — ont été corrigées. Les risques d’une atteinte au droit de la personnalité des personnes concernées liés à l'utilisation de l'application SocialPass ont donc considérablement été réduits au cours de la procédure. Dans le cadre d'un éventuel suivi du contrôle, le PFPDT reviendra sur les diverses implémentations des recommandations prévues et de manière ponctuelle sur d'autres aspects mentionnés dans le présent rapport.

Au vu de la sensibilité des données personnelles traitées et des réactions de la société civile, le contrôle du système SocialPass quant au respect des exigences de protection des données s'est avéré nécessaire et efficace. Les constatations faites et recommandations émises par le PFPDT pourront servir de marche à suivre pour d’autres exploitants privés, qui souhaiteraient développer des systèmes de gestion de réservations dans le cadre de la lutte contre la pandémie du Covid-19.

6. Suite de la procédure

La manière dont ces recommandations sont mises en œuvre en pratique relève de la seule responsabilité des exploitants de SocialPass qui sont affligés sur leurs déclarations et affirmations (art. 34 LPD). Dans le cadre de la poursuite de la coopération entre les exploitants de SocialPass et le PFPDT, notamment dans le cadre d'éventuels contrôles ultérieurs, le PFPDT se réserve le droit de contrôler le respect du cadre légal par les exploitants de SocialPass.

Dans la mesure où lesdites sociétés refusent ou ne suivent pas les recommandations, le PFPDT peut porter l'affaire devant le Tribunal administratif fédéral pour décision (art. 29 al. 4 LPD).

7. Publication de la recommandation en vertu de l'art. 30 al. 2 LPD

Pour les raisons susmentionnées, il existe un intérêt fondamental à sensibiliser le public en temps utile par rapport aux risques potentiels pour la sphère privée et le droit à l’'autodétermination, qui émanent des applications numériques développées pour lutter contre la pandémie actuelle. Vu que la procédure d'établissement des faits s'est avérée exceptionnellement longue et compliquée, le 31 mai 2021 - jour de la réouverture des terrasses des restaurants — le PFPDT a donc informé le public quant aux aspects principaux de la procédure d'établissement des faits clôturée le 28 mai 2021, y compris par rapport aux recommandations principales : SocialPass: limitation des possibilités de recherche requise (admin.ch).

La publication du rapport intégral dans sa version du 4 août 2021 n'aura lieu que sous réserve que du point de vue des sociétés SwissHelios Sarl et NewCom4U Sarl aucune donnée confidentielle qui pourrait révéler des secrets d'affaire ou influencer la capacité concurrentielle ne figure dans le rapport.

Les sociétés SwissHelios Sarl et NewCom4U Sarl sont priées de vérifier que le rapport de contrôle ne contienne pas de telles informations confidentielles et de confirmer cet état de fait par écrit au PFPDT dans un délai de 10 jours.

Le Préposé fédéral à la protection des données et à la transparence

Berne, le 4 août 2021 Adrian Lobsiger