Le 22/11/2024 à 12h 07

Ce n’est pas vraiment qu’ils ne l’appliquent pas eux-même, c’est qu’ils sont justement dans le cas où ils doivent optimiser et mettre un relay.
Les petites instances d’appview n’ont pas d’intérêt à un relai et peuvent discuter avec les PDS directement. Les grosses instances d’appview écrouleraient le réseau sans relai, en bombardant les PDS en permanence.

Rien n’empêche de monter son appview et son PDS et de fédérer avec le réseau conventionnel. Ça resterait BlueSky. ’fin pour être plus exact, ça resterait ATProto, avec une instance non BS à la fois en PDS et en AppView.
Un peu comme le fait d’avoir mamot.social sur le Fediverse ne remet pas en question mastodon.social. Ça reste du Fediverse 😊

C’est à mon sens la grosse confusion. On est en train de comparer BlueSky (une instance) à ActivityPub (un protocole) quand on devrait comparer BlueSky (une instance) à mastodon.social (une instance) et ATProtocol (un protocole) à ActivityPub (un protocol).
Dire « ça ne sera plus BS » est à mon sens une erreur de compréhension et conduit à faire des erreurs de sens et de conclusion. C’est comme dire « mastodon.social est-il centralisé ». La réponse est dans la question 🤣 (Et d’ailleurs la réponse est « mastodon.social est plus centralisé que BS parce que BS a déjà pu se couper en plusieurs bouts, ce que mastodon.social est incapable de faire »).

Le vrai titre de l’article est « ATProtocol est-il décentralisé », BS n’étant qu’une instance d’AT et la question est justement de savoir s’il est possible d’en fédérer une 2nde (et la réponse est oui, avec ou sans relai)

Le 21/11/2024 à 20h 05

Petite remarque quand même, mais qui a son importance. L’usage d’un relay n’est PAS obligatoire.
Il est utilisé pour des questions de performance, mais le protocole est prévu pour fonctionner sans, et c’est officiellement dans la doc, et AT encourage officiellement à s’en passer.

https://atproto.com/guides/glossary#relay
Relays are an optimization and are not strictly necessary. An AppView could communicate directly with PDSes (in fact, this is encouraged if needed). The Relay serves to reduce the number of connections that are needed in the network.

Bluesky
Given all that, our proposed methodology here of networking through Relays instead of server-to-server isn’t prescriptive. The protocol is actually explicitly designed to work both ways.

Donc absolument aucun problème à ce qu’actuellement seul BS en fasse tourner un ou que ça ne soit à la portée que de gros moyens.

Et dire « sans relay, rien ne fonctionne » est donc faux.

Le 11/09/2024 à 00h 55

il faudra réécrire une RGPD française, pas de souci.

Et que s’appelerio « Loi n° 78-17 du 6 janvier 1978 relative à l'informatique, aux fichiers et aux libertés ». La mère du RGPD en fait… 🤷
LIL 1978 -> Directive 95 -> RGPD 2016. C’est du copié-collé ou presque entre les 3.

Le 09/09/2024 à 18h 09

J’ajouterai qu’on n’aurait pas vraiment d’autre choix que de remettre le RGPD chez nous même en cas de Frexit. Ben oui, le RGPD interdit le traitement de données dans un pays non adéquat au niveau de sa législation 🤣 C’est exactement le problème qu’il y a actuellement avec Schrems I et Schrems II et les États-Unis.
Du coup sauf à vraiment envisager de ne plus pouvoir faire de commerce avec l’intégralité des pays restants dans l’UE, ça restera difficile de ne pas remettre cette législation chez nous…

Le 05/09/2024 à 14h 07

Le RGPD étant issu directement de l’article 8 de la Convention Européenne des Droits de l’Homme, traité fondateur de l’Union Européenne et de l’EEE, je dirais que si tu envisages de conserver le RGPD malgré un Frexit, commence par remettre en cause ton Frexit tout court hein… 🤷

Le 04/09/2024 à 18h 53

Je suis co-fondateur de PURR et Guillaume n'y a strictement jamais mis le moindre orteil.

Le 04/09/2024 à 18h 13

Pôle Emploi est un vrai faux problème. Les fuites de données, en soit c'est « normal » (j'en ai même moi-même déclaré à la CNIL).
Le problème est surtout le pourquoi et l'absence de sanction quand ça commence à se reproduire un peu trop souvent et sans mesure de correction…

Le 04/09/2024 à 18h 05

Je suis bien hébergeur au sens LCEN de l'association, avec qui j'ai un DPA de sous-traitance, les machines étant hébergées chez moi. Qui se trouve aussi être le siège social de l'asso.
Je n'ai strictement aucun intérêt financier quelconque à la conformité RGPD, je ne fais pas de conseil payant, je n'opère aucun service d'aucune sorte, je suis salarié standard d'une boîte standard sans rapport avec le RGPD.
Et du coup, ça gagne rien. Ça me coûte même beaucoup en temps et en frais d'avocat.

Le 04/09/2024 à 17h 53

Aeriss (avec 2s) est une société bretonne de conformité RGPD sans aucun lien avec moi

Le 04/09/2024 à 17h 52

Oui

Le 18/07/2024 à 21h 09

Ayant déposé personnellement 4 plaintes contre LFI, je pense détenir au moins un des 2 partis vainqueurs 🤣

Le 07/02/2024 à 23h 21

Tu remarqueras la présence du « généralement » à la fin de ma phrase 🤣
Dans 99.9999% des cas le DPO ne pourra de toute façon comparer avec rien du tout donc pièce inutile…

Le 07/02/2024 à 17h 12

Alors pour le coup, la saisie de la CNIL n’est pas exclusif de la saisie des juridictions civiles et pénales. La triple saisie est même ce qui devrait être fait à chaque fois…

Et la procédure à la CNIL est au final aussi longue et pénible que le civil et le pénal…

Le 07/02/2024 à 17h 10

Alors la dernière boîte qui m’a dit être conforme RGPD s’est fait un poil pilorisée pour violation du RGPD en long en large et en travers 🤣.
Il y a aussi « le meilleur logiciel RGPD du marché » qui a une petite plainte de ma parte pas piquée des hannetons sur le bureau de la CNIL.

Le 07/02/2024 à 17h 08

La demande de communication d’une pièce d’identité est une non conformité RGPD généralement.
C’est la CNIL qui le dit.
Twitter

Le 06/02/2024 à 18h 56

(J’ai BlueSky aussi à la limite hein… Quitte à utiliser un truc pas conforme RGPD, autant que ça soit celui qui assume clairement ne pas l’être ? 🤣)

Le 06/02/2024 à 18h 53

Pardon, pas 573. Ça c’était le mois dernier. 799 maintenant. Pfiou, faut la suivre celle-là… 🤣

Le 06/02/2024 à 18h 50

En vrai ? Non.
AEPD, la CNIL espagnole, c’est 20% de budget (15 millions contre 20 millions de mémoire) et d’effectifs (180 contre 220) en moins pour le même volume de plaintes (~14 000/an). Par contre AEPD c’est déjà 573 condamnations, contre 40 pour la CNIL… 😑
Ce n’est pas un manque de moyen, c’est un grave manque d’organisation… et des ordres politiques de ne pas toucher au business… 😡

Le 24/05/2023 à 20h 53

Je les tanne quasiment chaque jour hein 🤣

Le 24/05/2023 à 20h 04

Ou juste pas du tout. 30 sanctions par an nous place bon dernier dans les APD européennes vu le nombre de plaintes et le budget disponible.
Les sanctions étant majoritairement non publiques, elles ne permettent pas non plus de faire avancer la conformité globale, les autres responsables de traitement n’étant pas informés de la violation/sanction et donc allant continuer à faire la même chose que l’entité sanctionnée, en attendant sa propre sanction qui ne viendra jamais.

Dans mon cas personnel, c’est aussi plus de 80 plaintes de déposées avec quasiment aucune réponse concrète de la CNIL, pour des violations notoirement identifiées, connues et déjà traitées par la CNIL.
Ça se solde le plus souvent par un simple courrier de la CNIL après 3 ans de délai et jamais aucune sanction à la clef.

Au global, un responsable de traitement a tout intérêt à violer la loi. La CNIL ne le sanctionnera quasiment jamais, le risque encouru étant ridicule et se soldera certainement plutôt par un simple courrier de rappel à la loi au bout de X années de violation, et autant de bénéfices engrangés par rapport à avoir respecter la loi.

Même les grosses sanctions de la CNIL (380.000€ à Doctissimo) sont juste astronomiquement anecdotique (0.05% du CA annuel) et ne pousserons pas les entreprises à se mettre en conformité (Doctissimo a certainement encaisser 5 à 10× le montant de la sanction entre temps).

Le 17/12/2022 à 12h 35

DavidLibeau a dit:

Alors pourquoi tu écris l’inverse sur ton blog : “Il suffit d’un seul des 3 critères [nécessité, proportionnalité, et le troisième n’est même pas mentionné] en défaut pour ne pas pouvoir se placer sous le régime de l’intérêt légitime.”. C’est faux, la nécessité c’est dans TOUS les cas. Pas que pour l’intérêt légitime. Merci d’arrêter de dire n’importe quoi sur le RGPD.

Je ne vois pas en quoi ce que je dis est en contradiction avec mon blog. La nécessité est effectivement partout, et dans le cas de l’IL, il faut en plus la légitimité et la proportionnalité.

Faux, considérant 47 du RGPD : “Le traitement de données à caractère personnel strictement nécessaire à des fins de prévention de la fraude constitue également un intérêt légitime du responsable du traitement concerné.”

Considérant 50 de EDPB 2/2019 : la fraude peut être sous IL uniquement si proportionné et nécessaire. Généralement elle ne l’est pas et enlever la lutte contre la fraude coûte moins cher pour moins de données moins de complexité moins de rétention et moins d’intrusion sur les droits, le tout sans remettre en question le service (vu qu’elle n’est de toute façon pas une obligation contractuelle parce que pas nécessaire au service, même considérant). Dans l’extrêmeme majorité des cas, la lutte contre la fraude ne passe pas le triple test de l’IL permettant de fonder le traitement sur cette base légale. Beaucoup de condamnation et de requalification en consentement à ce sujet par exemple sur le scoring bancaire pour l’obtention de prêt.

Le 15/12/2022 à 17h 44

fdorin a dit:

Autrement dit, quand tu prends le soin de minimiser les données et les traitements, l’usage de la base contractuel couvre un large panel de cas d’utilisation, sans avoir besoin de recourir au consentement.

Encore une fois : non. La minimisation des données est l’étape initiale et obligatoire du RGPD, peu importe la base légale derrière. Toute finalité non minimale pour ton business est de toute façon à rejeter et est non conforme by design.
Pour chaque finalité survivante à la minimisation, tu dois alors trouver la base légale à retenir, et les GL montrent que dans 90% des cas, tu devras les placer sous le strict régime du consentement parce que ne sera pas strictement nécessaire à la réalisation du service (et non de ton business), donc pas contrat ni intérêt légitime, ou proportionné, donc pas intérêt légitime.
Tu vas du coup devoir encore élaguer dans tes finalités pour ton business tout en maintenant celle pour ton service, ou les placer sous consentement qui généralement tue ton business (mais pas ton service).
Tout le monde confond complètement les 2 mondes. Ton business n’est pas ce dont le RGPD traite, mais exclusivement ton service.
La gestion de fraude, l’amélioration du service, le suivi de ta compta ou de tes objectifs marketing ne sont PAS plaçables sous l’intérêt légitime ou le contrat (parce que non nécessaire à la fourniture du service ou trop intrusif sur la vie privée des utilisateurs par rapport aux avantages retirées) alors qu’ils sont nécessaires à ton business.

Et c’est là que ça coince en général, parce qu’on a construit la plus grosse partie de la viabilité de nos business sur des choses qui sont aujourd’hui illicites de par le RGPD. À de très rares exceptions près, aucune entreprise ne sait conserver son activité une fois passé le crible de la minimisation et de l’affectation des finalités restantes à des bases légales recevables.
L’intersection des bases légales acceptables au point de vue business par rapport à celle légalement acceptable pour le service est proche du vide. Typiquement pour le suivi marketing de ta boîte, il est inenvisageable de placer ça autre part que contrat ou intérêt légitime (parce que tes chiffres n’ont de sens que si tu touches 80-100% de ta base client) alors que le RGPD t’impose le consentement (et que tu en toucheras maximum 20-30% du coup, personne n’ayant d’intérêt à consentir à ce suivi pour tes beaux yeux).
Et même sous consentement, en touchant seulement 30% de ta base client, tes KPI business perdent du coup tout intérêt et deviennent non nécessaires puisque plus pertinentes, ne devraient du coup plus passer le crible de la minimisation et devraient être purement et simplement supprimées, conduisant à la fermeture de ta boîte qui ne sait plus fonctionner sans.

EDPB est au dessus de la CNIL (de toutes les CNILs en fait) et est là pour gérer les cas transfrontaliers et les problèmes. Elles émets des avis sur des cas spécifiques qui ont valeur jurisprudentiel afin d’harmoniser les interprétations au niveau européen lorsqu’elle est saisie (soit par elle-même, soit par une autorité).
Son rôle est aussi de publier des lignes directrices, des recommandations et des bonnes pratiques. Mais cela reste des recommandations et non des exigences. C’est très important car cela signifie que le non respect des guides n’est pas directement sanctionnable. C’est donc très différent d’un avis contraignant.

Non. Son boulot est d’homogénéiser l’ensemble des décisions des 27 APD et aucune APD ne peut traiter un dossier sans consulter EDPB avant. Tout décision, ligne directrice, avis ou sanction d’une APD est rendue exclusivement après consultation de l’ensemble des 26 autres APD. Toutes les APD n’ont donc d’autres choix que d’appliquer strictement les lignes directrices émises par EDPB (en auto-saisie ou sur demande d’une APD). Si ce n’était pas le cas, l’obligation de cohérence serait violé.
EDPB a d’ailleurs bien rappeler la règle récemment : Twitter

Le 15/12/2022 à 13h 15

Oui

Le 15/12/2022 à 12h 35

fdorin a dit:

Beaucoup de si…. Mon propos, c’est juste pour dire que, contrairement à ce que tu affirmes, les bases contractuelles remplissent beaucoup de cases.

Non. Correction, les gens voudraient qu’elles cochent beaucoup de cases. Les GL sur le sujet sont très claires : ce qui est couvert par cette base légale doit être extrêmement limité (considérant 27 & 28 page 10 des GL ²⁄₂₀₁₉).
De la même manière qu’avoir un intérêt légitime pour une finalité ne veut pas automatiquement dire que tu peux te prévaloir de la base légale de l’intérêt légitime (il faut encore prouver la nécessité et la proportionnalité), une clause que tu mets dans ton contrat ne relève pas automatiquement de l’obligation contractuelle (il faut aussi prouver la stricte nécessité).

Un mauvais choix de base légal pour un traitement en particulier ne signifie pas que les bases légales autres que le consentement sont inutilisables en général.

Non, mais que si tu t’es planté de base légale au départ, tu es en non conformité. Même si tu aurais pu te placer sous une autre base pour effectuer légalement la finalité.

Là dessus, je ne suis absolument pas d’accord. Un avis de 2014 n’a pas autant d’effets juridiques alors que celui-ci a été remis à plat depuis. Il peut émettre des avis, mais pas des avis contraignants.

L’avis de 2014 a le même poids légal que celui de 2019. D’ailleurs il est cité en référence dedans (note 26 de bas de page 16) et ses idées sont reprises textuellement.
Tant que ces GL WP29 (nouvellement EDPB) pré 2016 ne sont pas abrogées par EDPB (anciennement WP29), elles ont légalement le même effet que celles émises par EDPB post 2016.

Par contre, il peut émettre des décisions contraignantes, dans le cas d’affaires en particulier, par exemple, lorsqu’il y a mésentente entre différentes autorités nationales. Ou alors j’ai mal compris son rôle.

Tu as mal compris. EDPB est comme la CNIL, un organe de droit souple. Ils ne peuvent pas légalement émettre d’avis « contraignant » au sens réglementaire (et se font sanctionner s’ils le font, comme la CNIL au Conseil d’État pour l’interdiction des cookie wall). Mais étant aussi les organes de sanction, forcément que c’est contraignant parce que les APD (via EDPB et l’article 63 du RGPD) n’iront pas à l’encontre des GL édictées et approuvées collectivement et à l’unanimité par elles.
L’absence de contrainte au sens légal du terme ne veut pas dire qu’il n’y aura pas sanction à la fin et reconnaissance de la non conformité via le non respect de ces GL. ET donc en pratique contrainte de respecter ces GL quand même, sous peine de sanction.

Le 15/12/2022 à 10h 02

fdorin a dit:

Attention quand même, l’un des documents n’est qu’un avis de 2014, soit 2 ans AVANT l’adoption du RGPD, et 4 ans avant sa mise en application !

Ce sont des avis contraignants de WP29 aka EDPB, qu’ils retranscrivent régulièrement en version moderne. L’avis de 2014 a autant d’effets juridiques que celui de 2019 donc.

Dès lors qu’on respecte le principe de minimisation de la collecte des données, c’est-à-dire collecter uniquement ce dont on a besoin, ce n’est vraiment pas un souci.

Si justement. Non seulement tu dois minimiser, mais en plus tu dois avoir la bonne base légale. Si tu as minimisé sous le régime de l’intérêt légitime ou du contrat mais qu’une APD requalifie ça en consentement parce que ni 6(1)f ni 6(1)b n’étaient possible, ton traitement n’en reste pas moins tout autant non conforme et illicite.

Mais en faisant les choses correctement, contrat, intérêt légitime et obligation légale remplissent très bien leur rôle dans beaucoup de cas.

Encore une fois non justement. Beaucoup trop de finalités sont placées sous ces bases légales alors qu’elles peuvent et ne devraient qu’exclusivement relever du strict consentement et sont donc de facto illicites.
Il faudrait que je retrouve la condamnation en question, mais un mauvais choix de base légale, ça veut possiblement dire une condamnation à devoir effacer l’intégralité des données collectées (oui, parce qu’on ne peut pas changer de base légale en court de route). Et ceci même si elles étaient minimisées. C’est TRÈS con quand c’est l’intégralité de ta base client :)

La minimisation serait en fait même violée, parce que sous la base du consentement, les données n’auraient juste pas du/pu du tout être collectées (et on fait difficilement plus minimal que pas de données du tout).

Le 14/12/2022 à 22h 46

fdorin a dit:

Qu’appelles tu GL ?

GuideLines, en l’occurence
https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines-art_6-1-b-adopted_after_public_consultation_fr.pdf pour le 6(1)b « nécessaire au contrat » et https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp217_fr.pdf pour 6(1)f « intérêt légitime »

J’ai l’impression que tu parles d’expériences dans le domaine bancaire

Je parle de fraude au sens général du terme, ça inclut aussi par exemple les portiques de sécurité de la RATP qui ne peuvent pas être couverts par « nécessaire au contrat » (tu peux parfaitement les supprimer sans compromettre le service « je paie pour que tu me transportes de A à B »).
Et la RATP ne peut pas non plus le mettre sous l’intérêt légitime parce que la CNIL a dit que les pass nominatifs étaient non proportionnés à l’objectif visé.

Beaucoup de choses que tu considères comme pouvant relever du 6(1)b ou du 6(1)f ne peuvent en fait pas les utiliser (lire pages 9 et suivantes des GL ²⁄₂₀₁₉) et seul le consentement reste valide.

Après, comme tu le soulignes, il y a aussi des obligations légales. Tu cites le LCB-FT. Si tu fais ce qui est demandé au niveau de la loi, tu n’as absolument aucun souci pour légitimer ta base légale.

Certes, mais encore une fois, il faut que ça relève réellement d’une obligation légale et pas de vague truc décidés par des entités de droit privé (et il y en a plein).

Je connais beaucoup plus le domaine de la santé que le domaine bancaire. Et les bases utilisées sont soit le contrat, soit l’obligation légale, soit l’intérêt général (sauvegarde du patient). Si tu ne t’écartes pas de ce que tu dois faire (par obligation légale ou contrat), il n’y a aucune difficulté à justifier un traitement.

Tout à fait, mais dans les cas généraux, le consentement est réellement le truc qui représente 90% des cas au doigt mouillé. Et c’est bien tout le problème : personne ne veut avoir à gérer du consentement et donc plutôt que de virer le traitement, ils le font rentrer aux forceps dans contrat ou intérêt légitime…

J’ai surtout l’impression que tu imagines de nombreux traitements (ex: lutte contre la fraude bancaire) à la marge d’un traitement de base (ex: fournir un compte en banque)

Pas vraiment. EDPB a bien indiqué dans GL ²⁄₂₀₁₉ considérant 50 que la « lutte contre la fraude » (au sens large, pas que bancaire) ne pouvait pas relever du contrat mais uniquement de l’intérêt légitime. Et que l’intérêt légitime devait être nécessaire et proportionné en plus d’être légitime.

Tous tes services annexes ne peuvent par définition pas relever du contrat et devraient relever de l’intérêt légitime ou du consentement.
Dans BEAUCOUP de cas, ton intérêt légitime tombe et du coup sauf consentement, ton traitement annexe devient impossible.
Traitement annexe que toi, prestataire du service, tu considères pourtant comme une condition nécessaire à la réalisation de ton contrat et n’envisage pas du tout de faire sans. En d’autres termes, tu n’envisages pas de pouvoir rendre ton service principal sans être en non conformité RGPD à cause des finalités secondaires…
Tu as le choix entre fermer ta boîte ou être en non conformité. Je te laisse deviner ce que la plupart des gens choisissent…

Le 14/12/2022 à 17h 29

Jean_G a dit:

Et puis ici on peut l’utiliser pour un CDN car c’est un impératif pour la réalisation du contrat (= la délivrance du service de CDN).

Non, c’est justement refusé comme « nécessaire au contrat » parce que tu sais parfaitement fournir le même service sans CDN du tout (tu le fais toi-même avec ton infra en propre). C’est du coup exclusivement « intérêt légitime » mais c’est très fragile surtout fonction des CGU de ton CDN en face (cf décision CDN US et Schrems II). Et consentement impossible à appliquer en pratique. Ça veut donc dire juste devoir supprimer le CDN tout court car aucune base légale valide.

Le 14/12/2022 à 17h 27

fdorin a dit:

mais dans beaucoup de traitements, les obligations légales ou une base contractuelle sont largement exploitable.

Tu devrais relire les GL sur l’intérêt légitime et l’obligation contractuelle. Tu serais très surpris…
La lutte contre la fraude bancaire ? Ni nécessaire au contrat (tu peux rendre le service sans, c’est juste que tu prends un risque) ni intérêt légitime (les scores réalisés nécessitent des violations de vie privée non proportionnés aux risques), consentement obligatoire… 🤣 Pas obligation légale parce que ce sont des obligations (PCI-DSS) d’organismes privés (GIE-CB ou autres) et non des textes réglementaires (seul LCB-FT l’est).
Les cas réellement obligation légales, contrat ou intérêt légitimes sont BEAUCOUP plus rares que tu ne le penses en pratique.

Le 14/12/2022 à 15h 50

the_Grim_Reaper a dit:

Sauf si t’as une obligation légale supérieure liée à ton activité

Oui tout à fait, faut toujours regarder ton cas à toi dans tous les cas. Mais en tout cas le nécessaire au contrat ou l’intérêt légitime ne tiendrait pas sur un compte « trop » inactif.

Le 14/12/2022 à 15h 49

aurel_gogo a dit:

Tiens question à ceux qui savent.

Pour faire simple, on va dire que ma boite est une sorte d’intermédiaire technique qui permet à des PME de faire du marketing direct par SMS.

Quand un utilisateur se désabonne, on lui donne une adresse email de contact si il veut plus d’info.

Un des désabonnés m’a demandé de supprimer toutes les données qu’on a sur lui. Pas de soucis, j’ai que le téléphone, donc c’est simple…. Sauf que je lui ai dit que je ne supprimerai pas son numéro de téléphone car cela serait contraire à sa demande de désabonnement.

En gros, pour qu’un utilisateur ne reçoive plus de SMS, il me faut une “blocklist”, si je supprime son numéro, il n’est plus dans la blocklist et peut donc recevoir des SMS marketing et c’est donc en opposition avec son souhait.

Ai-je bien répondu, à votre avis ?

Oui et non. La blackliste devrait être constituée par exemple d’un hash du n° de téléphone et pas du numéro de téléphone en clair. En théorie ça reste de la pseudonymisation et donc ça reste une DCP, mais ça élimine les possibilités de détournement de finalité à partir de la base de donnée des blacklists.
Et la bonne réponse serait du coup « on a bien purgé toutes vos données, par contre, sauf opposition explicite de votre part, on conserve le hash pour notre blacklist et vous voyez, on respecte bien la minimisation de données et les mesures techniques de protection »

Le 14/12/2022 à 15h 45

fdorin a dit:

Déjà, présenter le consentement comme obligatoire avec 5 exceptions n’est pas vraiment juste. Le RGPD ne met absolument pas en avant une des bases légales pour légitimer un traitement. Il existe 6 bases légales, dont le consentement. C’est quand même très différent d’un régime à base d’exception tel que présenté dans l’article.

En fait si quand même. Les 2 autres régimes généralement utilisables (contrat et intérêt légitime) sont soumis à un régime TRÈS strict (beaucoup de choses que tu envisages sous l’un de ces 2 régimes y est généralement explicitement interdit), du coup le consentement est trop souvent la seule base légale licite.

Le 14/12/2022 à 15h 36

La CNIL conseille (aka sanctionnera sinon ) 1 à 2 ans de conservation des données d’un compte inactif. Après il faut purger.

Le 13/11/2019 à 15h 00

C’est plus compliqué que ça. Les trackers sont sur des sous-domaines délégués à Eulerian via le DNS. Eulerian arrive donc durant la résolution récursive du résolveur DNS, et est donc invisible au niveau de la résolution (non récursive) du client… Les systèmes de blocage simples sont complètement aveugles à cette étape, qui n’a lieu que dans le résolveur.

Le système de pi-hole ne fonctionne pas nativement du coup pour bloquer ce type de merde, il faut descendre encore plus bas…

Le 30/01/2018 à 11h 07

skankhunt42 a écrit :



Tu à totalement raison mais le crétin il doit manger et payer ses factures…





J’aurais bien aimé mettre 1200€ dans autre chose que des frais de justice tu vois. Genre dans de la bouffe.

Donc que tu manges c’est une chose, mais fait en sorte que ça ne soit pas au détriment de la bouffe des autres hein… Surtout ceux qui sont simple particuliers et qui ne peuvent pas compenser la perte sèche par du chiffre d’affaire supplémentaire. Ou les PME qui vont se retrouver Wanacryptées et mettre la clef sous la porte.



 





skankhunt42 a écrit :



J’ai vraiment des doutes… Ils désactivent chaque modules avant d’upgrade puis les réactive un par un ? Sachant qu’en moyenne c’est 90% de page blanche sur les modules non natifs et qu’il y à pas forcément une mise à jours de dispo ( payante ) ? Ensuite il le reconfigure / test un par un ? Pareil pour le thème ? Sachant que bien évidement la doc ne sera dispo au mieux qu’un an plus tard, sois six mois avant une nouvelle version ?



 

Ils vont péter les rotules de la boîte de presta qui s’occupe du Wordpress jusqu’à ce que ça retombe en marche oui. Et te résilie ton contrat si tu ne fais pas ce qu’il faut pour préserver l’intégrité du réseau Internet malgré leur relance. Une boîte éthique qui fait correctement son boulot quoi.

Et oui, ils ont des gens à temps plein qui passent leur vie à passer sur des milliers de Wordpress et à les configurer aux petits oignons, à les tester un par un, à thuner les caches quand ça merde, à désinfecter les Wordpress quand ils se font powner (oui, parce que même à jour, ça reste l’infection ces trucs…).

Le 29/01/2018 à 23h 33

skankhunt42 a écrit :



Du coup la sécurité n’est pas la non plus… 

   Tu prends de l’infogérance et du coup c’est ton presta qui s’occupe de faire les majs de sécu et le reste. Cfhttps://www.planet-work.com/ par exemple, qui gère ton Prestashop ou Wordpress de A à Z, y compris niveau sécu et maintenance. Mais forcément, c’est pas le même tarif que ton truc à 600€ complètement bâclé…          


           

skankhunt42 a écrit :



L’hébergeur possède un minimum de protection, si un truc louche est détecté sur le réseau le serveur est déconnecté en moins de 10 minutes et tu reçois un email d’abuse. Après j’ai rajouté un FW + RKhunter donc c’est quand même protégé un minium.

   Tu peux aller expliquer ça à l’OCLCTIC s’il te plaît ? Leur dire de me rendre les serveurs qu’ils m’ont saisi, puisqu’il est a priori impossible que j’ai été la cible d’une attaque de la part d’un très grand industriel français qui a refusé de faire ses mises-à-jour de sécurité et que son hébergeur lui aurait couper le réseau le cas échéant quand l’ensemble de son parc info a été infecté par un ransomware ? Ça m’a un peu coûter 1200€ juste en frais de justice si tu veux. Et je suis un simple particulier.         


   Parce qu’un crétin comme toi leur a vendu des daubes pas maintenues (du genre du Windows XP ou du Samba 1) pour économiser 2 francs 6 sous…     

Et FW + RKHunter, ça te protège TOI d’une attaque externe, mais c’est juste totalement inutile si tu tournes avec un Wordpress de 10 ans de retard ou un PHP antédiluvien… Ce sont les autres que tu vas toi-même attaquer à coup de spam, de DDoS ou plus vicieux, de relai pour un C&C d’un ransomware ou l’hébergement de contenu pédo-pornographique…

Le 28/01/2018 à 21h 48

skankhunt42 a écrit :



Si l’ont part du principe qu’il faut être tout le temps à jours pour la sécurité alors un commerçant devra repayer tous les an et demi pour repartir “from scratch”, sachant qu’un site met parfois plusieurs mois pour être développé… A ce tarif c’est limite une équipe dédié en permanence et tous le monde ne peut pas ce l’offrir.



 

Si tu n’as pas les moyens de te payer un kiné complet, tu ne vas pas pour autant chez le charlatan du coin 3× moins cher mais qui risque plus de te niquer complètement ton dos qu’autre chose…

C’est pareil en info : si tu n’as PAS les moyens de mettre correctement un site en ligne (maj de sécu, veille technique, maintenance…), tu ne mets PAS un site en ligne.



Ton site qui te rapporte 600€ mais livré sans maintenance ni mise-à-jour de sécurité, il me coûte peut-être à moi 100€/mois parce que ton super client va venir faire du DDoS chez moi, ou m’envoyer du spam, ou servir de plate-forme de relai de Wanacry, ou que sais-je encore.

Le 26/01/2018 à 15h 09

Erwannys a écrit :



Si tu souhaites t’améliorer et un peu automatiser la génération du site statique tu élabores un framework XML/XSL, toujours avec Notepad++ ou Brackets.





Ça existe déjà hein :P



https://middlemanapp.com/

https://jekyllrb.com/

https://gohugo.io/

https://blog.getpelican.com/



Mais forcément, tout le monde ne jure que par la « simplicité » de Wordpress, qui n’est simple que si on oublie de mentionner le coût et la complexité de la maintenance…

Le 26/01/2018 à 14h 58

Erwannys a écrit :



L’histoire de l’informatique est un éternel recommencement fait de médiocrité. 





Je connais bien, j’ai démissionné de mon ancien poste justement parce que je ne supportais plus la médiocrité ambiante…https://blog.imirhil.fr/2016/07/21/no-more-ssii.html

Le 26/01/2018 à 14h 51

aeris22 a écrit :



Si tu vends du Wordpress ou du Dotclear, tu DOIS vendre le support, la maintenance et les mises-à-jour de sécurité, sinon t’es juste en train de prendre ton client pour un con et tu es en train de mettre en péril MES serveurs, parce que les Wordpress que TU déploies se retrouveront dans 6 mois dans un botnet de DDoS ou d’envoi de spam qui viendront impacter MES services.





Wordpress CORE, c’est 47 vulnérabilités sur 2017 :https://www.cvedetails.com/vulnerability-list/vendor_id-2337/product_id-4096/yea…

Soit minimum une mise-à-jour par semaine.

Je ne te parle pas des plugins en plus, ou si tu as customisé le cœur…



Si tu utilises JetPack en plugin, tu as déjà 2 mises-à-jour critique

depuis début janvier :

https://www.cvedetails.com/product/21637/Automattic-Jetpack.html?vendor_id=11700



PHP, ça a été 43 vulnérabilités aussi :https://www.cvedetails.com/vulnerability-list/vendor_id-74/product_id-128/year-2…

Donc idem, 1 maj par semaine aussi.

Le 26/01/2018 à 14h 40

skankhunt42 a écrit :



La semaine j’ai un site à faire pour une amie je lui propose donc 1500€ au lieu de 600€ ? Elle refusera.





Si tu veux vendre des trucs quick&dirty à pas cher, tu vends du truc quick&dirty à pas cher.

Un site statique en middleman ou jekyll ou hugo ou pelican ou whatever, ça coûte 600€ et ça ne nécessite ni maintenance ni mise à jour de sécurité. Mais oui, elle fera bien moins de chose qu’avec un DotClear ou un Wordpress.

Si tu vends du Wordpress ou du Dotclear, tu DOIS vendre le support, la maintenance et les mises-à-jour de sécurité, sinon t’es juste en train de prendre ton client pour un con et tu es en train de mettre en péril MES serveurs, parce que les Wordpress que TU déploies se retrouveront dans 6 mois dans un botnet de DDoS ou d’envoi de spam qui viendront impacter MES services.

Le 26/01/2018 à 14h 07

skankhunt42 a écrit :



A un moment donné tu à besoin de manger

donc tu travaille et le client à besoin d’un site à pas trop cher alors

il ce tourne vers toi. Si tu lui explique direct que tous les 5 ans il

va falloir repasser à la caisse pour une histoire de compatibilité /

sécurité il ira voir ailleurs…





Et c’est comme ça qu’on se retrouve avec des boîtes infectées par Wanacry et autres saloperies, parce que certains prestataires préfèrent taire les coûts cachés de sécurité et de mise-à-jour juste pour remporter les marchés…

Le 26/01/2018 à 12h 34

Ce n’est pas très compliqué à faire « juste pour du test ».

C’est plus embétant pour un contexte de production.

On attend la communauté pour nous filer un coup de main à supporter des architectures qu’on ne supporte pas officiellement :)

Le 26/01/2018 à 12h 10

Cozy est multi-utilisateur depuis la version 3 justement.

C’est même ce problème qui a fait qu’on a du tout recoder en v3 pour autoriser à scaller par rapport à la v2 où il fallait une stack complète par utilisateur.

Le 26/01/2018 à 12h 06

Imbattable au niveau de la compatibilité, mais au niveau de la sécurité ?

Si PHP5 a été déprécié, ce n’est pas pour rien… Cette version souffre de GRAVES problèmes de sécurité puisque n’est plus supportée officiellement par l’équipe PHP. Donc plus de correctif de sécurité depuis plusieurs années déjà…



Idem pour ta version 0.8 de EasyPHP, juste t’as un trou de sécurité juste monstrueux sur ta machine quoi…

Le 25/01/2018 à 14h 05

Tu vas sur quelle URL pour tomber là-dessus ?

Le 25/01/2018 à 13h 49

Elle arrive, elle arrive :)

Le 28/07/2017 à 18h 58

Je proteste ! Je vais poursuivre la CIA pour contrefaçon !

Le 11/07/2017 à 09h 45

hellmut a écrit :



sinon j’ai maté la conf d’Aeris qui est intéressante bien qu’un peu technique.

surtout on voit pas du tout les slides, ce qui ne facilite pas les choses.



Les slides sont dispos en ligne à côté de la vidéo hein :P

Le 29/05/2017 à 14h 44

Ben ils se sont juste fait un peu powned leur réseau parce qu’ils n’ont appliqué aucune des préconisations minimales de sécurisation d’un réseau ? " />

Le 19/05/2017 à 00h 35

C’est pour éviter le syndrôme « clef à molette » que je fais aussi très gaffe avec des systèmes 2FA ou autres.

Même en me cassant les genoux, si je n’ai pas accès à ce dont j’ai besoin, je ne suis pas en mesure de donner les infos nécessaires au déchiffrement :)