La nuit derni=E8re je me suis pos=E9 une question qui m'a emp=EAch=E9e de
dormir...
NB : c'est un peu technique, mais vous devriez comprendre, sinon,
demandez moi :-)
Voici mon cas : je d=E9veloppe une application de type "client-serveur",
je souhaite placer la partie cliente en licence GPL.
La partie cliente se connecte =E0 la partie serveur en lui envoyant le
login/password (gr=E2ce =E0 une requete HTTP)
Or, le principe de la GPL est de pouvoir modifier le code source, tr=E8s
bien, pas de soucis de ce cot=E9 l=E0 pour moi, sauf si une personne
malveillante modifie le code pour que les requ=EAtes de connections se
fassent sur son propre serveur. Cela permettrai =E0 cette personne
malveillante de pouvoir disposer des login/password de mes utilisateurs.
(et donc d'acc=E9der =E0 d'autres informations : emails, etc...)
Or envers la Cnil je suis dans l'obligation de prot=E9ger les donn=E9es de
mes utilisateurs (c'est bien cela ? j'ai bien compris ?). Par
cons=E9quent, je suis oblig=E9 de mettre en suret=E9 les donn=E9es.
Donc, la licence GPL serait, dans mon cas, contradictoire avec la cnil.
- Que me conseillez vous de faire ?
- Est-ce que je suis parano : bien sur la personne malveillante serai
oblig=E9e de redistribuer le code source, et on pourrai voir sa
malveillance.. mais bon...
- Comment font les autres d=E9veloppeurs d'application client-serveur ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
SB - AXIGES
Bonjour,
Réponse "non-juridique" mais...
Pourquoi livrer dans le code source l'identifiant et le mot de passe de connexion à votre base ???
MySQL est en GPL (je crois) ce qui ne veut pas dire que qui l'utilise (ou en modifie les paramètres) peut se connecter à toutes les bases MySQL de la planète...
Non ?
Cordialement,
SB
Bonjour,
Réponse "non-juridique" mais...
Pourquoi livrer dans le code source l'identifiant et le mot de passe de
connexion à votre base ???
MySQL est en GPL (je crois) ce qui ne veut pas dire que qui l'utilise
(ou en modifie les paramètres) peut se connecter à toutes les bases
MySQL de la planète...
Pourquoi livrer dans le code source l'identifiant et le mot de passe de connexion à votre base ???
MySQL est en GPL (je crois) ce qui ne veut pas dire que qui l'utilise (ou en modifie les paramètres) peut se connecter à toutes les bases MySQL de la planète...
Non ?
Cordialement,
SB
Newsgroups
Le vendredi 10 novembre 2006 à 11:33 +0100, SB - AXIGES a écrit :
Bonjour,
Réponse "non-juridique" mais...
Pourquoi livrer dans le code source l'identifiant et le mot de passe de connexion à votre base ???
Je me suis pas bien expliqué alors...
Je ne livre pas le mot de passe de ma base de données ; en fait si un de mes utilisateur utilise l'application modifiée (de la personne malveillante) alors le login/pass seront envoyés (pour savoir si login/pass sont les bon) non pas à MON serveur mais au serveur du choix du malveillant qui aura donc "jouissance" de stocker les login/passwords de mes utilisateurs.
-- Cordialement, Mathieu
Le vendredi 10 novembre 2006 à 11:33 +0100, SB - AXIGES a écrit :
Bonjour,
Réponse "non-juridique" mais...
Pourquoi livrer dans le code source l'identifiant et le mot de passe de
connexion à votre base ???
Je me suis pas bien expliqué alors...
Je ne livre pas le mot de passe de ma base de données ; en fait si un de
mes utilisateur utilise l'application modifiée (de la personne
malveillante) alors le login/pass seront envoyés (pour savoir si
login/pass sont les bon) non pas à MON serveur mais au serveur du choix
du malveillant qui aura donc "jouissance" de stocker les login/passwords
de mes utilisateurs.
Le vendredi 10 novembre 2006 à 11:33 +0100, SB - AXIGES a écrit :
Bonjour,
Réponse "non-juridique" mais...
Pourquoi livrer dans le code source l'identifiant et le mot de passe de connexion à votre base ???
Je me suis pas bien expliqué alors...
Je ne livre pas le mot de passe de ma base de données ; en fait si un de mes utilisateur utilise l'application modifiée (de la personne malveillante) alors le login/pass seront envoyés (pour savoir si login/pass sont les bon) non pas à MON serveur mais au serveur du choix du malveillant qui aura donc "jouissance" de stocker les login/passwords de mes utilisateurs.
-- Cordialement, Mathieu
O.L.
Newsgroups a présenté l'énoncé suivant :
Bonjour,
La nuit dernière je me suis posé une question qui m'a empêchée de dormir... NB : c'est un peu technique, mais vous devriez comprendre, sinon, demandez moi :-)
Voici mon cas : je développe une application de type "client-serveur", je souhaite placer la partie cliente en licence GPL.
La partie cliente se connecte à la partie serveur en lui envoyant le login/password (grâce à une requete HTTP)
Or, le principe de la GPL est de pouvoir modifier le code source, très bien, pas de soucis de ce coté là pour moi, sauf si une personne malveillante modifie le code pour que les requêtes de connections se fassent sur son propre serveur. Cela permettrai à cette personne malveillante de pouvoir disposer des login/password de mes utilisateurs. (et donc d'accéder à d'autres informations : emails, etc...)
Or envers la Cnil je suis dans l'obligation de protéger les données de mes utilisateurs (c'est bien cela ? j'ai bien compris ?). Par conséquent, je suis obligé de mettre en sureté les données.
Donc, la licence GPL serait, dans mon cas, contradictoire avec la cnil. - Que me conseillez vous de faire ? - Est-ce que je suis parano : bien sur la personne malveillante serai obligée de redistribuer le code source, et on pourrai voir sa malveillance.. mais bon... - Comment font les autres développeurs d'application client-serveur ?
Il faut simplement que les utilisateurs finaux aient confiance dans les personnes qui distribuent des versions modifiées de ton code client ... et si elles ont confiance, mais que la personne est malveillante, AMHA tu ne peux rien faire contre. Pourquoi ne pas annoncer aux utilisateurs que la seule version principale et fiable du logiciel client est dispo sur ton site uniquement ? Comme ça elles sauront si elles le téléchargent ailleurs que c'est à leurs risques et périls. Ou alors tu modifies ton code pour rendre la partie "authentification" indépendante et indécompilable, et tu la met en dehors du code GPL.
-- Olivier Ligny Créateur web free-lance / www.cyber-tamtam.net
Newsgroups a présenté l'énoncé suivant :
Bonjour,
La nuit dernière je me suis posé une question qui m'a empêchée de
dormir...
NB : c'est un peu technique, mais vous devriez comprendre, sinon,
demandez moi :-)
Voici mon cas : je développe une application de type "client-serveur",
je souhaite placer la partie cliente en licence GPL.
La partie cliente se connecte à la partie serveur en lui envoyant le
login/password (grâce à une requete HTTP)
Or, le principe de la GPL est de pouvoir modifier le code source, très
bien, pas de soucis de ce coté là pour moi, sauf si une personne
malveillante modifie le code pour que les requêtes de connections se
fassent sur son propre serveur. Cela permettrai à cette personne
malveillante de pouvoir disposer des login/password de mes utilisateurs.
(et donc d'accéder à d'autres informations : emails, etc...)
Or envers la Cnil je suis dans l'obligation de protéger les données de
mes utilisateurs (c'est bien cela ? j'ai bien compris ?). Par
conséquent, je suis obligé de mettre en sureté les données.
Donc, la licence GPL serait, dans mon cas, contradictoire avec la cnil.
- Que me conseillez vous de faire ?
- Est-ce que je suis parano : bien sur la personne malveillante serai
obligée de redistribuer le code source, et on pourrai voir sa
malveillance.. mais bon...
- Comment font les autres développeurs d'application client-serveur ?
Il faut simplement que les utilisateurs finaux aient confiance dans les
personnes qui distribuent des versions modifiées de ton code client ...
et si elles ont confiance, mais que la personne est malveillante, AMHA
tu ne peux rien faire contre.
Pourquoi ne pas annoncer aux utilisateurs que la seule version
principale et fiable du logiciel client est dispo sur ton site
uniquement ? Comme ça elles sauront si elles le téléchargent ailleurs
que c'est à leurs risques et périls.
Ou alors tu modifies ton code pour rendre la partie "authentification"
indépendante et indécompilable, et tu la met en dehors du code GPL.
--
Olivier Ligny
Créateur web free-lance / www.cyber-tamtam.net
La nuit dernière je me suis posé une question qui m'a empêchée de dormir... NB : c'est un peu technique, mais vous devriez comprendre, sinon, demandez moi :-)
Voici mon cas : je développe une application de type "client-serveur", je souhaite placer la partie cliente en licence GPL.
La partie cliente se connecte à la partie serveur en lui envoyant le login/password (grâce à une requete HTTP)
Or, le principe de la GPL est de pouvoir modifier le code source, très bien, pas de soucis de ce coté là pour moi, sauf si une personne malveillante modifie le code pour que les requêtes de connections se fassent sur son propre serveur. Cela permettrai à cette personne malveillante de pouvoir disposer des login/password de mes utilisateurs. (et donc d'accéder à d'autres informations : emails, etc...)
Or envers la Cnil je suis dans l'obligation de protéger les données de mes utilisateurs (c'est bien cela ? j'ai bien compris ?). Par conséquent, je suis obligé de mettre en sureté les données.
Donc, la licence GPL serait, dans mon cas, contradictoire avec la cnil. - Que me conseillez vous de faire ? - Est-ce que je suis parano : bien sur la personne malveillante serai obligée de redistribuer le code source, et on pourrai voir sa malveillance.. mais bon... - Comment font les autres développeurs d'application client-serveur ?
Il faut simplement que les utilisateurs finaux aient confiance dans les personnes qui distribuent des versions modifiées de ton code client ... et si elles ont confiance, mais que la personne est malveillante, AMHA tu ne peux rien faire contre. Pourquoi ne pas annoncer aux utilisateurs que la seule version principale et fiable du logiciel client est dispo sur ton site uniquement ? Comme ça elles sauront si elles le téléchargent ailleurs que c'est à leurs risques et périls. Ou alors tu modifies ton code pour rendre la partie "authentification" indépendante et indécompilable, et tu la met en dehors du code GPL.
-- Olivier Ligny Créateur web free-lance / www.cyber-tamtam.net
Newsgroups
Le vendredi 10 novembre 2006 à 11:55 +0100, O.L. a écrit :
Il faut simplement que les utilisateurs finaux aient confiance dans les personnes qui distribuent des versions modifiées de ton code client ... et si elles ont confiance, mais que la personne est malveillante, AMHA tu ne peux rien faire contre.
ok, mais légalement, suis responsable ?
Pourquoi ne pas annoncer aux utilisateurs que la seule version principale et fiable du logiciel client est dispo sur ton site uniquement ? Comme ça elles sauront si elles le téléchargent ailleu rs que c'est à leurs risques et périls.
Oui, ça, je vais le faire dès que je proposerai le téléchargement.
Ou alors tu modifies ton code pour rendre la partie "authentification" indépendante et indécompilable, et tu la met en dehors du code GPL.
Ah !! et bien j'avais même pas pensé à cela.. Je vais voir ce que je peux faire pour sortir l'authentification du code et l'exclure de la gpl.
Le vendredi 10 novembre 2006 à 11:55 +0100, O.L. a écrit :
Il faut simplement que les utilisateurs finaux aient confiance dans les
personnes qui distribuent des versions modifiées de ton code client ...
et si elles ont confiance, mais que la personne est malveillante, AMHA
tu ne peux rien faire contre.
ok, mais légalement, suis responsable ?
Pourquoi ne pas annoncer aux utilisateurs que la seule version
principale et fiable du logiciel client est dispo sur ton site
uniquement ? Comme ça elles sauront si elles le téléchargent ailleu rs
que c'est à leurs risques et périls.
Oui, ça, je vais le faire dès que je proposerai le téléchargement.
Ou alors tu modifies ton code pour rendre la partie "authentification"
indépendante et indécompilable, et tu la met en dehors du code GPL.
Ah !! et bien j'avais même pas pensé à cela.. Je vais voir ce que je peux
faire pour sortir l'authentification du code et l'exclure de la gpl.
Le vendredi 10 novembre 2006 à 11:55 +0100, O.L. a écrit :
Il faut simplement que les utilisateurs finaux aient confiance dans les personnes qui distribuent des versions modifiées de ton code client ... et si elles ont confiance, mais que la personne est malveillante, AMHA tu ne peux rien faire contre.
ok, mais légalement, suis responsable ?
Pourquoi ne pas annoncer aux utilisateurs que la seule version principale et fiable du logiciel client est dispo sur ton site uniquement ? Comme ça elles sauront si elles le téléchargent ailleu rs que c'est à leurs risques et périls.
Oui, ça, je vais le faire dès que je proposerai le téléchargement.
Ou alors tu modifies ton code pour rendre la partie "authentification" indépendante et indécompilable, et tu la met en dehors du code GPL.
Ah !! et bien j'avais même pas pensé à cela.. Je vais voir ce que je peux faire pour sortir l'authentification du code et l'exclure de la gpl.
Dominique ROUSSEAU
Le ven, 10 nov 2006 at 10:18 GMT, Newsgroups a écrit : [... snip ...]
Or envers la Cnil je suis dans l'obligation de protéger les données de mes utilisateurs (c'est bien cela ? j'ai bien compris ?). Par conséquent, je suis obligé de mettre en sureté les données.
Donc, la licence GPL serait, dans mon cas, contradictoire avec la cnil. - Que me conseillez vous de faire ? - Est-ce que je suis parano : bien sur la personne malveillante serai obligée de redistribuer le code source, et on pourrai voir sa malveillance.. mais bon... - Comment font les autres développeurs d'application client-serveur ?
Les mots de passes des utilisateurs chargeant ton logiciel ne sont pas enregistrés dans un "fichier" (au sens CNIL) que tu gères. Tu ne détiens pas de données personelles dont tu devrais assurer la protection.
Le ven, 10 nov 2006 at 10:18 GMT, Newsgroups <newsgroups@free.fr> a écrit :
[... snip ...]
Or envers la Cnil je suis dans l'obligation de protéger les données de
mes utilisateurs (c'est bien cela ? j'ai bien compris ?). Par
conséquent, je suis obligé de mettre en sureté les données.
Donc, la licence GPL serait, dans mon cas, contradictoire avec la cnil.
- Que me conseillez vous de faire ?
- Est-ce que je suis parano : bien sur la personne malveillante serai
obligée de redistribuer le code source, et on pourrai voir sa
malveillance.. mais bon...
- Comment font les autres développeurs d'application client-serveur ?
Les mots de passes des utilisateurs chargeant ton logiciel ne sont pas
enregistrés dans un "fichier" (au sens CNIL) que tu gères.
Tu ne détiens pas de données personelles dont tu devrais assurer la
protection.
Le ven, 10 nov 2006 at 10:18 GMT, Newsgroups a écrit : [... snip ...]
Or envers la Cnil je suis dans l'obligation de protéger les données de mes utilisateurs (c'est bien cela ? j'ai bien compris ?). Par conséquent, je suis obligé de mettre en sureté les données.
Donc, la licence GPL serait, dans mon cas, contradictoire avec la cnil. - Que me conseillez vous de faire ? - Est-ce que je suis parano : bien sur la personne malveillante serai obligée de redistribuer le code source, et on pourrai voir sa malveillance.. mais bon... - Comment font les autres développeurs d'application client-serveur ?
Les mots de passes des utilisateurs chargeant ton logiciel ne sont pas enregistrés dans un "fichier" (au sens CNIL) que tu gères. Tu ne détiens pas de données personelles dont tu devrais assurer la protection.
SB - AXIGES
> Le vendredi 10 novembre 2006 à 11:33 +0100, SB - AXIGES a écrit :
Bonjour,
Réponse "non-juridique" mais...
Pourquoi livrer dans le code source l'identifiant et le mot de passe de connexion à votre base ???
Je me suis pas bien expliqué alors...
Je ne livre pas le mot de passe de ma base de données ; en fait si un de mes utilisateur utilise l'application modifiée (de la personne malveillante) alors le login/pass seront envoyés (pour savoir si login/pass sont les bon) non pas à MON serveur mais au serveur du choix du malveillant qui aura donc "jouissance" de stocker les login/passwords de mes utilisateurs.
Vu. Il ne s'agit pas que du faille sur le plan juridique (éventuellement), il s'agit carrément d'un bogue de sécurité qui, par les conséquences qu'il peut induire pour les utilisateurs (et là , avec des conséquences juridiques, certainement), doit être résolu dans votre code lui-même (effectivement par un bloc non décompilable ou un appel externe à une application "mono-propriétaire") au niveau des principes d'authentification. Ca restera sans doute le meilleur moyen de protection (sur le plan juridique et des données).
Cdlt,
SB
> Le vendredi 10 novembre 2006 à 11:33 +0100, SB - AXIGES a écrit :
Bonjour,
Réponse "non-juridique" mais...
Pourquoi livrer dans le code source l'identifiant et le mot de passe de
connexion à votre base ???
Je me suis pas bien expliqué alors...
Je ne livre pas le mot de passe de ma base de données ; en fait si un de
mes utilisateur utilise l'application modifiée (de la personne
malveillante) alors le login/pass seront envoyés (pour savoir si
login/pass sont les bon) non pas à MON serveur mais au serveur du choix
du malveillant qui aura donc "jouissance" de stocker les login/passwords
de mes utilisateurs.
Vu.
Il ne s'agit pas que du faille sur le plan juridique (éventuellement),
il s'agit carrément d'un bogue de sécurité qui, par les conséquences
qu'il peut induire pour les utilisateurs (et là , avec des conséquences
juridiques, certainement), doit être résolu dans votre code lui-même
(effectivement par un bloc non décompilable ou un appel externe à une
application "mono-propriétaire") au niveau des principes
d'authentification.
Ca restera sans doute le meilleur moyen de protection (sur le plan
juridique et des données).
> Le vendredi 10 novembre 2006 à 11:33 +0100, SB - AXIGES a écrit :
Bonjour,
Réponse "non-juridique" mais...
Pourquoi livrer dans le code source l'identifiant et le mot de passe de connexion à votre base ???
Je me suis pas bien expliqué alors...
Je ne livre pas le mot de passe de ma base de données ; en fait si un de mes utilisateur utilise l'application modifiée (de la personne malveillante) alors le login/pass seront envoyés (pour savoir si login/pass sont les bon) non pas à MON serveur mais au serveur du choix du malveillant qui aura donc "jouissance" de stocker les login/passwords de mes utilisateurs.
Vu. Il ne s'agit pas que du faille sur le plan juridique (éventuellement), il s'agit carrément d'un bogue de sécurité qui, par les conséquences qu'il peut induire pour les utilisateurs (et là , avec des conséquences juridiques, certainement), doit être résolu dans votre code lui-même (effectivement par un bloc non décompilable ou un appel externe à une application "mono-propriétaire") au niveau des principes d'authentification. Ca restera sans doute le meilleur moyen de protection (sur le plan juridique et des données).
Cdlt,
SB
Newsgroups
Le vendredi 10 novembre 2006 à 12:10 +0100, Dominique ROUSSEAU a écrit :
Les mots de passes des utilisateurs chargeant ton logiciel ne sont pas enregistrés dans un "fichier" (au sens CNIL) que tu gères. Tu ne détiens pas de données personelles dont tu devrais assurer la protection.
Mais ces mots de passe donnent accès aux emails, nom et prénom.
Le vendredi 10 novembre 2006 à 12:10 +0100, Dominique ROUSSEAU a écrit :
Les mots de passes des utilisateurs chargeant ton logiciel ne sont pas
enregistrés dans un "fichier" (au sens CNIL) que tu gères.
Tu ne détiens pas de données personelles dont tu devrais assurer la
protection.
Mais ces mots de passe donnent accès aux emails, nom et prénom.
Le vendredi 10 novembre 2006 à 12:10 +0100, Dominique ROUSSEAU a écrit :
Les mots de passes des utilisateurs chargeant ton logiciel ne sont pas enregistrés dans un "fichier" (au sens CNIL) que tu gères. Tu ne détiens pas de données personelles dont tu devrais assurer la protection.
Mais ces mots de passe donnent accès aux emails, nom et prénom.
Albert ARIBAUD
Le Fri, 10 Nov 2006 12:40:20 +0100, SB - AXIGES a écrit:
Le vendredi 10 novembre 2006 à 11:33 +0100, SB - AXIGES a écrit :
Bonjour,
Réponse "non-juridique" mais...
Pourquoi livrer dans le code source l'identifiant et le mot de passe de connexion à votre base ???
Je me suis pas bien expliqué alors...
Je ne livre pas le mot de passe de ma base de données ; en fait si un de mes utilisateur utilise l'application modifiée (de la personne malveillante) alors le login/pass seront envoyés (pour savoir si login/pass sont les bon) non pas à MON serveur mais au serveur du choix du malveillant qui aura donc "jouissance" de stocker les login/passwords de mes utilisateurs.
Vu. Il ne s'agit pas que du faille sur le plan juridique (éventuellement), il s'agit carrément d'un bogue de sécurité qui, par les conséquences qu'il peut induire pour les utilisateurs (et là , avec des conséquences juridiques, certainement), doit être résolu dans votre code lui-même (effectivement par un bloc non décompilable ou un appel externe à une application "mono-propriétaire") au niveau des principes d'authentification.
Ou bien en utilisant une méthode d'authentification solide qui ne transmette pas le login et le mot de passe sans avoir au préalable établi une connexion authentifiée (HTTPS et certificat serveur et/ou certificats client).
Bien sûr, cela n'est envisageable en pratique que si le serveur web est sur une machine dédiée et non une machine mutualisée.
Amicalement, -- Albert.
Le Fri, 10 Nov 2006 12:40:20 +0100, SB - AXIGES a écrit:
Le vendredi 10 novembre 2006 à 11:33 +0100, SB - AXIGES a écrit :
Bonjour,
Réponse "non-juridique" mais...
Pourquoi livrer dans le code source l'identifiant et le mot de passe de
connexion à votre base ???
Je me suis pas bien expliqué alors...
Je ne livre pas le mot de passe de ma base de données ; en fait si un de
mes utilisateur utilise l'application modifiée (de la personne
malveillante) alors le login/pass seront envoyés (pour savoir si
login/pass sont les bon) non pas à MON serveur mais au serveur du choix
du malveillant qui aura donc "jouissance" de stocker les login/passwords
de mes utilisateurs.
Vu.
Il ne s'agit pas que du faille sur le plan juridique (éventuellement),
il s'agit carrément d'un bogue de sécurité qui, par les conséquences
qu'il peut induire pour les utilisateurs (et là , avec des conséquences
juridiques, certainement), doit être résolu dans votre code lui-même
(effectivement par un bloc non décompilable ou un appel externe à une
application "mono-propriétaire") au niveau des principes
d'authentification.
Ou bien en utilisant une méthode d'authentification solide qui ne
transmette pas le login et le mot de passe sans avoir au préalable établi
une connexion authentifiée (HTTPS et certificat serveur et/ou certificats
client).
Bien sûr, cela n'est envisageable en pratique que si le serveur web est sur
une machine dédiée et non une machine mutualisée.
Le Fri, 10 Nov 2006 12:40:20 +0100, SB - AXIGES a écrit:
Le vendredi 10 novembre 2006 à 11:33 +0100, SB - AXIGES a écrit :
Bonjour,
Réponse "non-juridique" mais...
Pourquoi livrer dans le code source l'identifiant et le mot de passe de connexion à votre base ???
Je me suis pas bien expliqué alors...
Je ne livre pas le mot de passe de ma base de données ; en fait si un de mes utilisateur utilise l'application modifiée (de la personne malveillante) alors le login/pass seront envoyés (pour savoir si login/pass sont les bon) non pas à MON serveur mais au serveur du choix du malveillant qui aura donc "jouissance" de stocker les login/passwords de mes utilisateurs.
Vu. Il ne s'agit pas que du faille sur le plan juridique (éventuellement), il s'agit carrément d'un bogue de sécurité qui, par les conséquences qu'il peut induire pour les utilisateurs (et là , avec des conséquences juridiques, certainement), doit être résolu dans votre code lui-même (effectivement par un bloc non décompilable ou un appel externe à une application "mono-propriétaire") au niveau des principes d'authentification.
Ou bien en utilisant une méthode d'authentification solide qui ne transmette pas le login et le mot de passe sans avoir au préalable établi une connexion authentifiée (HTTPS et certificat serveur et/ou certificats client).
Bien sûr, cela n'est envisageable en pratique que si le serveur web est sur une machine dédiée et non une machine mutualisée.
Amicalement, -- Albert.
Dominique ROUSSEAU
Le ven, 10 nov 2006 at 12:13 GMT, Newsgroups a écrit :
Le vendredi 10 novembre 2006 à 12:10 +0100, Dominique ROUSSEAU a écrit :
Les mots de passes des utilisateurs chargeant ton logiciel ne sont pas enregistrés dans un "fichier" (au sens CNIL) que tu gères. Tu ne détiens pas de données personelles dont tu devrais assurer la protection.
Mais ces mots de passe donnent accès aux emails, nom et prénom.
La même problématique peut se poser pour un serveur mail (pop3, par exemple) et un client de mail. Un client de mail, va manipuler des identifiants qui permettent d'accéder à des données personelles sotckées sur le serveur de mail. L'administrateur du serveur de mail est responsable de déterminer si des identifiants corrects ont été donnés avant de laisser l'acès à la boite aux lettres. Ce que le client de mail fait (ou non) des identifiants demandés à l'utilisateur, ça n'est pas son problème.
Il faut juste instruire les utilisateurs des risques liés à l'utilisation d'un client autre que le tien, mais tu ne peux en aucun cas être tenu responsable d'une maveillance de quelqu'un qui distribuerait une version modifiée du client. L'obligation de diffusion des sources qu'inclut la GPL est d'ailleurs là pourapporter une certaine assurance à l'utilisateur qu'il peut vérifier (ou faire vérifier) que le logiciel fait bien ce qu'il annonce faire et pas autre chose.
Dom
Le ven, 10 nov 2006 at 12:13 GMT, Newsgroups <newsgroups@free.fr> a écrit :
Le vendredi 10 novembre 2006 à 12:10 +0100, Dominique ROUSSEAU a écrit :
Les mots de passes des utilisateurs chargeant ton logiciel ne sont pas
enregistrés dans un "fichier" (au sens CNIL) que tu gères.
Tu ne détiens pas de données personelles dont tu devrais assurer la
protection.
Mais ces mots de passe donnent accès aux emails, nom et prénom.
La même problématique peut se poser pour un serveur mail (pop3, par
exemple) et un client de mail.
Un client de mail, va manipuler des identifiants qui permettent
d'accéder à des données personelles sotckées sur le serveur de mail.
L'administrateur du serveur de mail est responsable de déterminer si des
identifiants corrects ont été donnés avant de laisser l'acès à la boite
aux lettres. Ce que le client de mail fait (ou non) des identifiants
demandés à l'utilisateur, ça n'est pas son problème.
Il faut juste instruire les utilisateurs des risques liés à
l'utilisation d'un client autre que le tien, mais tu ne peux en aucun
cas être tenu responsable d'une maveillance de quelqu'un qui
distribuerait une version modifiée du client.
L'obligation de diffusion des sources qu'inclut la GPL est d'ailleurs là
pourapporter une certaine assurance à l'utilisateur qu'il peut vérifier
(ou faire vérifier) que le logiciel fait bien ce qu'il annonce faire et
pas autre chose.
Le ven, 10 nov 2006 at 12:13 GMT, Newsgroups a écrit :
Le vendredi 10 novembre 2006 à 12:10 +0100, Dominique ROUSSEAU a écrit :
Les mots de passes des utilisateurs chargeant ton logiciel ne sont pas enregistrés dans un "fichier" (au sens CNIL) que tu gères. Tu ne détiens pas de données personelles dont tu devrais assurer la protection.
Mais ces mots de passe donnent accès aux emails, nom et prénom.
La même problématique peut se poser pour un serveur mail (pop3, par exemple) et un client de mail. Un client de mail, va manipuler des identifiants qui permettent d'accéder à des données personelles sotckées sur le serveur de mail. L'administrateur du serveur de mail est responsable de déterminer si des identifiants corrects ont été donnés avant de laisser l'acès à la boite aux lettres. Ce que le client de mail fait (ou non) des identifiants demandés à l'utilisateur, ça n'est pas son problème.
Il faut juste instruire les utilisateurs des risques liés à l'utilisation d'un client autre que le tien, mais tu ne peux en aucun cas être tenu responsable d'une maveillance de quelqu'un qui distribuerait une version modifiée du client. L'obligation de diffusion des sources qu'inclut la GPL est d'ailleurs là pourapporter une certaine assurance à l'utilisateur qu'il peut vérifier (ou faire vérifier) que le logiciel fait bien ce qu'il annonce faire et pas autre chose.
