Forum général.général URL avec référent, RGPD, et ZRR

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
7
12
avr.
2023

Question de béotien : depuis que l'Ensicaen qui héberge le laboratoire où je travaille a délocalisé son informatique au pays merveilleux de la vie privée, du secret industriel, et des Gafa, quand des collègues envoient des liens, ils sont systématiquement assaisonnés de ce qui ressemble fort à un référent.
Par exemple au lieu de :

https://ent.normandie-univ.fr/filex/get?k=[CODE DE FICHIER]

on reçoit des trucs qui ressemblent à :

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fent.normandie-univ.fr%2Ffilex%2Fget%3Fk%[CODE_DE_FICHIER]&data=05%7C01%7C[NOM_DE L'EXPEDITEUR]%40[NOM_D'INSTITUTION]%7Cafc3bb9b02184966b30d08db3b39ba6a%7C430c3e75ff03445fb3f4ae2809a0b10b%7C0%7C0%7C638168891357137744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=E751J3l69sUzVG%2B6AClusFLZEA%2FnFppW2HEfWhyaIlQ%3D&reserved=0 

Cette pratique me paraît quelque peu douteuse ? D'une part ne s'agit-il pas de collecter des données à caractère personnel ? Et même d'en diffuser, l'URL contenant désormais le nom de l'expéditeur initial ?
Et d'autre part, ces pratiques de collecte ne contreviennent-elles pas au principe des ZRR ? Même si en pratique le passage à ce régime ne se traduit guère que par la sous-traitance de l'informatique aux Gafa, et des étiquettes collées dans les couloirs menaçant des pires avanies quiconque oserait transiter en ces lieux sans y être dûment autorisé.

Merci d'avance pour vos réponses éclairées.

  • # En principe...

    Posté par  . Évalué à 4.

    Tout dépend ce que tu fais transiter dans l'url d'un lien.

    Heureusement, personne ne met jamais d'information personnelle dans l'URL. Et on a jamais vu personne dire qu'un fichier derrière un uuid, c'était trop difficile à retrouver donc pas besoin d'offrir plus de protection.

    Juste au cas où… sarcasme

    En tout logique, ce genre de lien ne devrait pas être consulté par l'application, juste vérifié avec une base de données de trucs déjà connus. Mais… difficile de savoir ce qu'ils en font vraiment.

    Je te rejoins donc sur ce point, il devient dangereux dans un contexte professionnel de s'échanger des liens. Enfin, certains diront que de toute façon, la messagerie entraîne des I.A. qu'on pourra questionner au besoin sur le contenu des conversations, donc le liens..

    Je pense qu'envoyer un lien vers une page forgée estampillé "information privée secret confidentiel absolu" et qui enregistre les accès devrait pouvoir éclairer quant à leur discrétion.

    Petite pensée extra en attendant que le café fasse effet… en faisant ça ne deviennent ils pas "éditeur" du contenu ? Ne sont ils donc pas responsables du contenu qui transite par leurs canaux à même titre que pour des pages web ?

    • [^] # Re: En principe...

      Posté par  (site web personnel) . Évalué à 3.

      « Heureusement, personne ne met jamais d'information personnelle dans l'URL. Et on a jamais vu personne dire qu'un fichier derrière un uuid, c'était trop difficile à retrouver donc pas besoin d'offrir plus de protection. »

      De ce point de vue là, rien ne change entre le fichier mis à disposition directement ou via Référent. Bon autant dire que les options mot de passe et chiffrement sont en pratique largement négligées. Le sarcasme est effectivement de mise.

      Mais est-il légitime qu'un fournisseur de logiciel de courriel se permette de modifier les liens pour faire passer des informations par ses propres serveurs ? Le lien généré par l'application de transfert de fichier est toujours le premier, les collègues le copie-colle dans leur courriels et hop, il devient le second. Déloyal non ? Une sorte de Man in the middle ?

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # safelink

    Posté par  (site web personnel) . Évalué à 2.

    C'est que ton admin O365 à activé Safelink pour le parcours des liens recu afin de detecter d'eventuel fishing, on parle pas de boite perso la.

    • [^] # Re: safelink

      Posté par  (site web personnel) . Évalué à 5.

      Oui, que le dispositif soit nommé safe-link, est assez explicite. La question porte sur les informations collectées, et sur la légalité de la chose. Est-ce comme la vidéo protection, totalement bénin et dé-corrélé de toute forme de surveillance ?

      L'espionnage, c'est avant tout la collecte d'information sur les personnes, leurs habitudes, leurs relations…. Du moins c'est ce qu'on apprend (ou apprenait) dans le premier entretient de sécurité pour obtenir une habilitation confidentielle ou secret défense. D'où ma question sur la légalité de la chose. Si une collecte d'information outrepassait allègrement ce qui est permis dans un contexte personnel, il ne semblerait pas incohérent de considérer qu'elle est encore plus évidemment proscrite dans un contexte professionnel, en particulier soumis à des restrictions de confidentialité. Non ?

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

      • [^] # Re: safelink

        Posté par  (site web personnel) . Évalué à 3.

        Ton admin lors de l'activation de safe links à accepté une CLUF, faut lui demander ;)

        • [^] # Re: safelink

          Posté par  (site web personnel) . Évalué à 2.

          Pas le genre à lire ça.

          « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

          • [^] # Re: safelink

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            Je plussois Sylvain …et il se trouve que ce genre de chose ne doit pas reposer sur les épaules des admins mais que les RSSI + DPO + services juridiques doivent lire et discuter ces clauses/conditions/etc. ensemble avant application par les opérationnels !

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

            • [^] # Re: safelink

              Posté par  (site web personnel) . Évalué à 4.

              Surtout que le pauvre admin, dans une structure de recherche publique comme celle là, avec 36 tutelles, sites, équipes, etc, et autant d’exigences diverses et variées, a certainement bien d’autres chats à fouetter que les petits caractères gris clairs sur fond beige qui expliquent qu’en cliquant ok vous cédez les âmes de tous les gens qui passeront à moins de cinq mètres des machines impliquées et de leurs descendants (ceux des gens, pas des machines :-).

              « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: safelink

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Détecter du fishing est une chose ; trafiquer et pister les liens une autre. Doit-on faire les secondes au nom de la première ?
      Au passage, mis à part le marketing, est-ce que ça marche vraiment ? Parce-que j'en vois des liens d'hameçonnage qui passent quand même.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: safelink

        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 14 avril 2023 à 08:33.

        je doute aussi de l'utilité. Mon avis est que ça complique la possibilité de savoir si le lien est légitime avant de cliquer dessus tellement l'URL est imbitable. Si le site lié est vraiment néfaste alors autant enlever le lien voire supprimer l'e-mail plutôt que d'afficher un lien comme ça.

        Un LUG en Lorraine : https://enunclic-cappel.fr

  • # emetteur ou recepteur ?

    Posté par  . Évalué à 4.

    en gros, est-ce ton server emetteur qui modifie le lien avec safelink avant de le transmettre au destintaire ? (auquel cas, c'est bien ton admin qu'il faut voir)

    ou bien est-ce le serveur receveur, qui analyse l'email, scan le lien et les pieces jointes, et modifies le lien dans l'email pour dire qu'il a été scanné ?
    auquel cas tu ne peux rien faire, ce n'est pas toi qui est en cause.

    • [^] # Re: emetteur ou recepteur ?

      Posté par  (site web personnel) . Évalué à 2.

      Ne disposant pas d'un compte sous l'OS incriminé, délicat de tester véritablement le processus.
      Le serveur receveur n'est pas incriminé : les liens en provenance d'autres sources ne sont aucunement affectés, même en faisant un tour par le serveur du labo (puis fwd).
      Tout ce que je peux affirmer c'est qu'aucun des expéditeurs ne semble s'en rendre compte, alors que ces liens sont parfaitement visibles à la réception sous Linux (même différence en clair que dans l'entrée de forum). Ça se passe comme si sur leur GUI s'affichait le lien à envoyer au lieu et place du lien effectivement fourni. Peut-être la substitution est-elle directement opérée par le client de messagerie expéditeur ?

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

      • [^] # Re: emetteur ou recepteur ?

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        Les expéditeurs peuvent s'en rendre compte, mais le commun des mortels ne prête pas attention aux détails et cette plateforme en joue …de la même façon que les messages de fishing.
        En gros, un lien-cliquable reconnu doit donner si on était en markdown l'équivalent de [lien-affiché](lien-cliquable) où lien-affiché = lien-cliquable ; mais ici le lien affiché est le vrai lien envoyé et le lien cliquable est le lien modifié… En tout cas dans le client lourd Outlook.
        Toujours dans le client lourd, quand on passe la souris sur le lien, on a une pop-up qui affiche une première ligne indiquant URL d'origine : lien-affiché et une seconde ligne en gras indiquant de faire contrôle-clic pour suivre le lien. Quand on passe la souris sur le lien, le lien modifié est est affiché dans la barre d'état (chose que les usagers regardent rarement.) Enfin, quand on suit le lien (clic avec ou sans contrôle), on voit bien que c'est l'adresse modifiée qui est chargée dans la barre d'adresse puis il y a une redirection (chose que les usagers ne remarquent que en ayant l'habitude de scruter la barre d'adresse… et sous réserve que le navigateur soit aussi transparent : je n'utilise pas Edge donc on sait jamais)
        Bref, des méthodes mafieuses qui n'aident pas à lutter contre les vilains …pour les usagers.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: emetteur ou recepteur ?

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Quelques réponses/pistes pour le cas me concernant (donc sans vouloir généraliser) :
      \ \ Contexte) Je suis dans une entreprise qui utilise la messagerie µ$ O365.
      \ \ Réceptions) Quand j'envoie un message de mes adresses privées (mon domaine personnel et la messagerie de Ggl) vers le boulot, la plupart (voir notes d'exceptions) des liens arrivent retouchés… Idem pour les messages professionnels provenant aussi bien des collègues (même domaine de messagerie) que de l'extérieur.
      \ \ \ \ Exception1) La réécriture s'applique aux liens de type "http" et "https" (je n'en ai pas testé d'autres de schémas connus), mais pas les "mailto"
      \ \ \ \ Exception2) La réécriture s'applique aux courriels, pas aux rendez-vous/réunions
      \ \ \ \ Exception3) Il y a quelques (rares) courriels formatés en HTML dont les liens ne sont pas réécrits… Le dernier exemple que j'ai en tête est un message de SNCF-Connect que je me suis envoyé au travail (je devais me déplacer avec l'ordi pro et non l'ordi perso)
      \ \ Envois) Tous les messages envoyés depuis ma messagerie professionnelle voient les liens qu'ils contiennent qui sont substitués (avec les mêmes deux premières exceptions.) Les messages ne sont bien entendus pas modifiés en local (je vois les liens comme je les ai saisi et le clic dessus ou la copie donne bien la même adresse) mais avant d'être délivré…

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.