[Linux-bruxelles] Lot Linux-bruxelles, Vol 107, Parution 38

Mer 29 Sep 04:46:46 CEST 2021

Salut Philippe,
hello you all,

Je suis immensément navré de lire ton compte rendu ici, à l'ULB, parlant
d'un endroit où il  fut question, mais surtout réponse, du refus de l
'argument d'autorité.
Certes, il y a ~185 ans, et l'emprise de séduction des gafam était fort
embryonnaire. Il y avait juste un embrun dans l'air : le monopole de la
connaissance, du savoir et de ces moyens de transmission.

Qui des autorités académiques ou des simple end users faudrait-il,
d'après toi, essayer de sensibiliser le plus/mieux..

Bizzzkes
Fred

Bien à toi
Fred

Le 23/09/21 à 13:49, Philippe Delchambre via Linux-bruxelles a écrit :
>
> Bonjour,
>
> L’histoire se prolonge à l'ULB où toute la gestion de ses mails est
> désormais acquise à Microsoft (365). Il est aujourd'hui réclamé à
> toustes ses agent.e.s de télécharger une application tierce sur son
> GSM pour une question de "double authentification". 
>
> Je ne doute pas que Microsoft possède déjà mon numéro de GSM, mais lui
> donner revient à les autoriser de détenir une information qui relève
> de ma vie privée. En conséquence le ton monte avec le responsable de
> cette opération, car je refuse de plier. Il me répond qu'/«//à la
> suite de la cyberattaque ..., une Task Force a été chargée de procéder
> à l'ensemble des actions nécessaires destinées à sécuriser l'accès à
> l'ensemble des ressources informatiques. C'est dans le cadre des
> travaux que s'inscrit le déploiement du MFA sur l'accès à notre
> environnement Microsoft 365. J'insiste sur le mot "notre" dans la
> mesure où nous en sommes pleinement propriétaires et responsables, que
> son administration passe exclusivement pas nos propres experts, et
> qu'en aucun cas Microsoft n'y dispose du moindre accès.»/
>
> Je ne peux que m'étonner devant tant d'innocence feinte.
>
> D'autre part l'origine de la cyberattaque réside dans un mot de passe
> commun utilisé par des agents des services informatiques, et en charge
> de la maintenance du parc de PC des secrétariats. C'est bien le
> vecteur de sécurité de Microsoft que ces crapules de pirates ont
> utilisé pour crypter les données des serveurs de l'ULB.
>
> P.
>
>
>
> Le 23/09/21 à 11:37, linux-bruxelles-request at lists.bxlug.be a écrit :
>
>> Envoyez vos messages pour la liste Linux-bruxelles à
>> 	linux-bruxelles at lists.bxlug.be
>>
>> Pour vous (dés)abonner par le web, consultez
>> 	https://chahut.domainepublic.net/cgi-bin/mailman/listinfo/linux-bruxelles
>>
>>
>> ou, par email, envoyez un message avec 'help' dans le corps ou dans le
>> sujet à
>> 	linux-bruxelles-request at lists.bxlug.be
>>
>> Vous pouvez contacter l'administrateur de la liste à l'adresse
>> 	linux-bruxelles-owner at lists.bxlug.be
>>
>> Si vous répondez, n'oubliez pas de changer l'objet du message afin
>> qu'il soit plus spécifique que "Re: Contenu du digest de
>> Linux-bruxelles..."
>>
>>
>> Thèmes du jour :
>>
>>    1. Re:  Pour info : suite office et étudiants vs Google
>>       worspace (Rémi Letot)
>>    2. Fwd:  LCP Fourquet, NTFS suite et peut être fin (Fred)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Wed, 22 Sep 2021 14:51:34 +0200
>> From: Rémi Letot <hobbes at poukram.net>
>> To: linux-bruxelles at lists.bxlug.be
>> Subject: Re: [Linux-bruxelles]  Pour info : suite office et étudiants
>> 	vs Google worspace
>> Message-ID: <87zgs4soax.fsf at sphax.lybrafox.lan>
>> Content-Type: text/plain; charset=utf-8
>>
>> Bonjour Nicolas, bonjour la liste,
>>
>> le cadre contractuel devrait effectivement normalement empêcher
>> l'utilisation des données de l'utilisateur par Microsoft (ou autre),
>> au-moins dans le cas d'une utilisation professionnelle sous contrat.
>>
>> En théorie.
>>
>> En pratique, il n'en reste pas moins que l'utilisation de ces
>> plateformes, même «protégé» par un contrat, reste problématique, et ce
>> pour plusieurs raisons:
>>
>> - Microsoft tente par tous les moyens d'étendre l'emprise de ses comptes
>>   à l'ensemble de la plateforme utilisée par l'utilisateur. Par exemple,
>>   quand tu configures un compte Teams sur un pc Windows, il va te
>>   demander si tu veux utiliser ce compte sur toute la machine (et en
>>   petit te donner la possibilité de dire non). Rien que le design de cet
>>   écran n'est pas conforme avec le RGPD puisque par défaut c'est oui, et
>>   en petit difficilement visible c'est non.
>>
>> - ils sont extrêmement agressifs pour pouvoir utiliser tes données et
>>   ton comportement, même si tu leur dis non. Par exemple, à chaque
>>   grosse mise à jour de Windows (y compris la version Pro), il va te
>>   redemander (avec insistance) si tu veux bien qu'il utilise tes données
>>   pour «améliorer» ses services. Ni la démarche, ni les écrans en
>>   question, ne sont conformes avec le RGPD.
>>
>> - chrome fait à peu près la même chose: par exemple quand tu rentres sur
>>   ton compte gmail, même professionnel, c'est tout chrome qui s'y
>>   connecte sans te demander ton avis. Peut-être qu'ils n'en font
>>   rien. Mais vu leur historique, moi je n'ai pas spécialement
>>   confiance. Par exemple il y a un gros bouton «synchroniser avec
>>   google» qui apparaît sous ton nom de compte, sur lequel les gens ont
>>   tendance à pousser (le design est fait pour). Ce design n'est pas non
>>   plus conforme au RGPD.
>>
>> - un Windows sans aucun logiciel et sans utilisation transmets déjà à
>>   Microsoft une quantité de données incroyables sous couvert de
>>   «monitoring» pour améliorer le produit (l'équivalent d'un roman par
>>   jour d'après le ministère de l'intérieur Allemand). Si tu ajoutes des
>>   logiciels, notamment Office, il semble que des bouts de documents
>>   passent dans ces données. Office est un produit payant, couvert par un
>>   contrat, mais des données qui peuvent être confidentielles sont
>>   quand-même envoyées à Microsoft. Alors ils n'en font peut-être
>>   effectivement rien à priori, mais alors pourquoi les collecter ?
>>
>> Je pourrais continuer longtemps, mais je pense que le message général
>> est clair: oui normalement les contrats devraient nous protéger. Mais en
>> pratique ces sociétés enfreignent le RGPD à tours de bras, et usent de
>> tous les subterfuges possibles et imaginables pour étendre leur
>> emprise. Probablement souvent en respectant les contrats à la lettre
>> (après tout ce sont eux qui les ont écrits), mais probablement souvent
>> aussi en poussant un peu (ou beaucoup) les limites. Ils ne respectent
>> pas (encore) le RGPD, je ne vois pas pourquoi ils respecteraient plus
>> les contrats. 
>>
>>
>> Mais en plus, et ça c'est le coup de grâce pour finir: les garanties
>> contractuelles offertes ne sont pas au-dessus de la loi américaine à
>> laquelle ces éditeurs sont soumis. Le Cloud Act et le FISA sont très
>> clair: les agences de renseignement américaines ont la possibilité
>> d'avoir accès à toutes ces données, hébergées aux US ou partout
>> ailleurs. Avec très peu de contrôle (il existe des recours, mais leurs
>> conditions sont drastiques), et sans que l'utilisateur en soit averti.
>>
>> Donc contrat ou pas, ils sont soumis à cette loi, et ne peuvent
>> respecter le RGPD.
>>
>>
>> En passant, je ne le connais pas, mais l'analyse de François Bocquet est
>> étonnante dans la conversation sur la liste de l'April: même les textes
>> qu'il fournit contredisent son interprétation, sans parler le la cours
>> de justice européenne...
>>
>> A+,
>
>
> _______________________________________________
> Linux-bruxelles :
> Èchanger, partager, s'informer par mails sur toute action, proposition accordée avec: http://www.bxlug.be/?Nos-statuts
>
> ! 64 kb autorisés par mail, tout fichier inclus !
>
> Linux-bruxelles at lists.bxlug.be
> https://chahut.domainepublic.net/cgi-bin/mailman/listinfo/linux-bruxelles
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: </pipermail/linux-bruxelles/attachments/20210929/51960feb/attachment.html>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: 0x5FC3B4CF55DF67E7.asc
Type: application/pgp-keys
Taille: 644 octets
Desc: non disponible
URL: </pipermail/linux-bruxelles/attachments/20210929/51960feb/attachment.key>