[HS quoi que...] Firefox 40.0.3 (Kubuntu 12.04)

Lucas Levrel

20/09/2015 à 09:37

Le 20 septembre 2015, Dominique a écrit :

Apparemment, le problème ne se pose qu'avec le webmail de mon employeur
(Roundcube Webmail). Je n'ai aucun souci avec les fichier ODF ou autres
trouvés sur la toile.

Le Content-Type d'un fichier ods est : application/octet-stream

Et je ne sais pas trop ce que ça veut dire...

Il me semble que c'est le Content-Type « tout venant » pour les fichiers
binaires, typiquement utilisé quand le fichier n'est dans aucun format
connu. Du coup ça n'est pas étonnant que tu ne puisses pas sauvegarder ton
choix d'application ! La proposition de gedit n'est pas bien utile dans ce
cas...

--
LL
Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)
C'est mieux avé les accents (F. Patte)

Nicolas George

20/09/2015 à 13:04

Lucas Levrel , dans le message
, a écrit :

Le Content-Type d'un fichier ods est : application/octet-stream

Il me semble que c'est le Content-Type « tout venant » pour les fichiers
binaires, typiquement utilisé quand le fichier n'est dans aucun format
connu.

Exactement.

Yliur

20/09/2015 à 16:59

Le Sun, 20 Sep 2015 07:25:32 +0200
Dominique a écrit :

Le 18/09/2015 16:13, Yliur a écrit :

> Tu peux vérifier ça comme ça : <SNIP> une ligne du type
> "Content-Type: ...". C'est le type de fichier que le serveur a
> indiqué.

Bonjour Ylur,

Apparemment, le problème ne se pose qu'avec le webmail de mon
employeur (Roundcube Webmail). Je n'ai aucun souci avec les fichier
ODF ou autres trouvés sur la toile.

Le Content-Type d'un fichier ods est : application/octet-stream

Et je ne sais pas trop ce que ça veut dire...

J'ai placé une copie écran ici :

http://www.cjoint.com/c/EIufymZNVJX

Si ça te parle plus qu'à moi...

Merci pour le coup de main. Je te souhaite une agréable journée,

A priori c'est à l'expéditeur du courriel de remplir cette information,
donc si les messages arrivent avec des pièces jointes marquées comme
"application/octet-stream" je ne sais pas quoi y faire.

Peut-être installer LibreOffice sur la machine de l'expéditeur, pour que
le logiciel qui expédie la pièce jointe renseigne correctement ce
champ ?

Ou encore indiquer au logiciel d'expédition du courriel de ne rien
écrire dans ce champ quand il ne connaît pas le type du fichier, mais
ce n'est probablement pas possible ?

Il semblerait que deviner le type du fichier en se basant sur son
extension alors qu'un type est indiqué par le serveur web puisse être
dangereux, sans doute la raison pour laquelle Firefox ne le fait pas (ce
qui semble conforme aux recommandations de la norme http).

Pour un courrier électronique de toutes façons tu fais plus ou
moins confiance à l'expéditeur si tu ouvres la pièce jointe, donc
j'imagine que le lecteur de courriels pourrait jouer aux devinettes mais
puisque ici c'est un serveur web qui distribue la pièce jointe ça ne
peut pas marcher : le serveur web indique comme type de contenu ce qui
est écrit dans le courriel et le navigateur est plus ou moins obligé de
le croire.

Nicolas George

20/09/2015 à 17:40

Yliur , dans le message , a écrit :

A priori c'est à l'expéditeur du courriel de remplir cette information,

Oui. Bien sûr, c'est fait automatiquement.

Il n'est pas exclu que Roundcube fasse des bêtises dans l'histoire, il
faudrait regarder le mail original en détail pour vérifier.

Il semblerait que deviner le type du fichier en se basant sur son
extension alors qu'un type est indiqué par le serveur web puisse être
dangereux

Pas du tout : le type MIME et l'extension suggérée sont tous les deux à la
discrétion du serveur, faire confiance à l'un ou à l'autre est
rigoureusement équivalent.

Je pense qu'exploiter la confusion entre type MIME et extension servait
juste à contourner certains anti-virus débiles.

Quand Firefox reçoit un type MIME générique (application/octet-stream), il
devrait certainement, en plus de proposer la simple sauvegarde, proposer de
choisir un type plus utile en suggérant le bon par détection (extension et
contenu du fichier).

Pour un courrier électronique de toutes façons tu fais plus ou
moins confiance à l'expéditeur si tu ouvres la pièce jointe,

À part pour certains types bien spécifiques qui devraient être dans une
catégorie à part, ça n'a pas de raison d'être le cas. Ouvrir un image, une
musique ou un texte joint n'a aucune conséquence néfaste en termes de
sécurité.

Sauf bien sûr si le logiciel utilisé pour l'ouvrir est lui-même troué.
C'était le cas des bouzins office de microsoft avec les macros.

Yliur

20/09/2015 à 18:48

Le 20 Sep 2015 15:40:07 GMT
Nicolas George <nicolas$ a écrit :

Yliur , dans le message , a écrit :
> A priori c'est à l'expéditeur du courriel de remplir cette
> information,

Oui. Bien sûr, c'est fait automatiquement.

Il n'est pas exclu que Roundcube fasse des bêtises dans l'histoire, il
faudrait regarder le mail original en détail pour vérifier.

J'utilise aussi Roundcube et m'expédier un fichier odt et le
récupérer, le tout avec Roundcube, fonctionne correctement.

> Il semblerait que deviner le type du fichier en se basant sur son
> extension alors qu'un type est indiqué par le serveur web puisse
> être dangereux

Pas du tout : le type MIME et l'extension suggérée sont tous les deux
à la discrétion du serveur, faire confiance à l'un ou à l'autre est
rigoureusement équivalent.

Je pense qu'exploiter la confusion entre type MIME et extension
servait juste à contourner certains anti-virus débiles.

Quand Firefox reçoit un type MIME générique
(application/octet-stream), il devrait certainement, en plus de
proposer la simple sauvegarde, proposer de choisir un type plus utile
en suggérant le bon par détection (extension et contenu du fichier).

Je n'ai pas vérifié, mais j'ai trouvé quelqu'un qui citait la RFC 2616
(http 1.1) :
"
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource.
"

Indépendamment du fait qu'ici on utilise un serveur web pour distribuer
une pièce jointe, qui est un cas un peu particulier, je ne suis pas sûr
que ce soit neutre d'un point de vue sécurité : le fait que le serveur
spécifie le type qu'est censé avoir un fichier peut permettre de
l'inactiver vis-à-vis du navigateur. Bien sûr il pourrait aussi
vérifier l'extension ou autre, mais je pense que c'est utile pour
mettre en place des mécanismes de sécurité dans les applications web :
si l'appli est censée fournir un fichier à télécharger, il ne peut pas
être interprété comme un script ou autre malencontreusement : l'appli
peut encadrer un peu l'envoi du fichier (quand l'appli permet de
partager des fichiers légitimement mais qu'on ne veut pas que leur
expédition fasse n'importe quoi). Pouvoir appliquer un filtre à ce
niveau peut être intéressant, même si l'appli peut tâcher de filtrer
les fichiers par extension aussi (ce qui n'est pas tellement mieux).
C'est un cas où l'origine du fichier et le propriétaire du serveur ne
sont pas les mêmes. Et ça peut même permettre de laisser passer le
fichier tel quel sans qu'il soit automatiquement ouvert par le
navigateur (cas d'un fichier html contenant du javascript par exemple).

Après effectivement si le type est application/octet-stream et que le
navigateur propose explicitement de l'ouvrir avec un autre programme
(pas d'interprétation possible de sa part), je suppose que ce n'est pas
si grave : de toutes façons s'il ne le fait pas l'utilisateur va sans
doute sauvegarder le fichier et l'ouvrir avec l'appli proposée par son
système.

Le 20 Sep 2015 15:40:07 GMT
Nicolas George <nicolas$george@salle-s.org> a écrit :

Yliur , dans le message <20150920165942.4b14db2b@free.fr>, a écrit :
> A priori c'est à l'expéditeur du courriel de remplir cette
> information,

Oui. Bien sûr, c'est fait automatiquement.

Il n'est pas exclu que Roundcube fasse des bêtises dans l'histoire, il
faudrait regarder le mail original en détail pour vérifier.

J'utilise aussi Roundcube et m'expédier un fichier odt et le
récupérer, le tout avec Roundcube, fonctionne correctement.

> Il semblerait que deviner le type du fichier en se basant sur son
> extension alors qu'un type est indiqué par le serveur web puisse
> être dangereux

Pas du tout : le type MIME et l'extension suggérée sont tous les deux
à la discrétion du serveur, faire confiance à l'un ou à l'autre est
rigoureusement équivalent.

Je pense qu'exploiter la confusion entre type MIME et extension
servait juste à contourner certains anti-virus débiles.

Quand Firefox reçoit un type MIME générique
(application/octet-stream), il devrait certainement, en plus de
proposer la simple sauvegarde, proposer de choisir un type plus utile
en suggérant le bon par détection (extension et contenu du fichier).

Je n'ai pas vérifié, mais j'ai trouvé quelqu'un qui citait la RFC 2616
(http 1.1) :
"
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource.
"

Indépendamment du fait qu'ici on utilise un serveur web pour distribuer
une pièce jointe, qui est un cas un peu particulier, je ne suis pas sûr
que ce soit neutre d'un point de vue sécurité : le fait que le serveur
spécifie le type qu'est censé avoir un fichier peut permettre de
l'inactiver vis-à-vis du navigateur. Bien sûr il pourrait aussi
vérifier l'extension ou autre, mais je pense que c'est utile pour
mettre en place des mécanismes de sécurité dans les applications web :
si l'appli est censée fournir un fichier à télécharger, il ne peut pas
être interprété comme un script ou autre malencontreusement : l'appli
peut encadrer un peu l'envoi du fichier (quand l'appli permet de
partager des fichiers légitimement mais qu'on ne veut pas que leur
expédition fasse n'importe quoi). Pouvoir appliquer un filtre à ce
niveau peut être intéressant, même si l'appli peut tâcher de filtrer
les fichiers par extension aussi (ce qui n'est pas tellement mieux).
C'est un cas où l'origine du fichier et le propriétaire du serveur ne
sont pas les mêmes. Et ça peut même permettre de laisser passer le
fichier tel quel sans qu'il soit automatiquement ouvert par le
navigateur (cas d'un fichier html contenant du javascript par exemple).

Après effectivement si le type est application/octet-stream et que le
navigateur propose explicitement de l'ouvrir avec un autre programme
(pas d'interprétation possible de sa part), je suppose que ce n'est pas
si grave : de toutes façons s'il ne le fait pas l'utilisateur va sans
doute sauvegarder le fichier et l'ouvrir avec l'appli proposée par son
système.

Vous avez filtré cet utilisateur ! Consultez son message

Le 20 Sep 2015 15:40:07 GMT
Nicolas George <nicolas$ a écrit :

Yliur , dans le message , a écrit :
> A priori c'est à l'expéditeur du courriel de remplir cette
> information,

Oui. Bien sûr, c'est fait automatiquement.

Il n'est pas exclu que Roundcube fasse des bêtises dans l'histoire, il
faudrait regarder le mail original en détail pour vérifier.

J'utilise aussi Roundcube et m'expédier un fichier odt et le
récupérer, le tout avec Roundcube, fonctionne correctement.

> Il semblerait que deviner le type du fichier en se basant sur son
> extension alors qu'un type est indiqué par le serveur web puisse
> être dangereux

Pas du tout : le type MIME et l'extension suggérée sont tous les deux
à la discrétion du serveur, faire confiance à l'un ou à l'autre est
rigoureusement équivalent.

Je pense qu'exploiter la confusion entre type MIME et extension
servait juste à contourner certains anti-virus débiles.

Quand Firefox reçoit un type MIME générique
(application/octet-stream), il devrait certainement, en plus de
proposer la simple sauvegarde, proposer de choisir un type plus utile
en suggérant le bon par détection (extension et contenu du fichier).

Je n'ai pas vérifié, mais j'ai trouvé quelqu'un qui citait la RFC 2616
(http 1.1) :
"
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource.
"

Indépendamment du fait qu'ici on utilise un serveur web pour distribuer
une pièce jointe, qui est un cas un peu particulier, je ne suis pas sûr
que ce soit neutre d'un point de vue sécurité : le fait que le serveur
spécifie le type qu'est censé avoir un fichier peut permettre de
l'inactiver vis-à-vis du navigateur. Bien sûr il pourrait aussi
vérifier l'extension ou autre, mais je pense que c'est utile pour
mettre en place des mécanismes de sécurité dans les applications web :
si l'appli est censée fournir un fichier à télécharger, il ne peut pas
être interprété comme un script ou autre malencontreusement : l'appli
peut encadrer un peu l'envoi du fichier (quand l'appli permet de
partager des fichiers légitimement mais qu'on ne veut pas que leur
expédition fasse n'importe quoi). Pouvoir appliquer un filtre à ce
niveau peut être intéressant, même si l'appli peut tâcher de filtrer
les fichiers par extension aussi (ce qui n'est pas tellement mieux).
C'est un cas où l'origine du fichier et le propriétaire du serveur ne
sont pas les mêmes. Et ça peut même permettre de laisser passer le
fichier tel quel sans qu'il soit automatiquement ouvert par le
navigateur (cas d'un fichier html contenant du javascript par exemple).

Après effectivement si le type est application/octet-stream et que le
navigateur propose explicitement de l'ouvrir avec un autre programme
(pas d'interprétation possible de sa part), je suppose que ce n'est pas
si grave : de toutes façons s'il ne le fait pas l'utilisateur va sans
doute sauvegarder le fichier et l'ouvrir avec l'appli proposée par son
système.

Nicolas George

20/09/2015 à 18:49

Yliur , dans le message , a écrit :

Je n'ai pas vérifié, mais j'ai trouvé quelqu'un qui citait la RFC 2616
(http 1.1) :

Une RFC spécifie le protocole entre un client et un serveur. Si elle se
mêlait de spécifier le comportement d'une application vis-à-vis de
l'utilisateur, elle sortirait complètement et gravement de son domaine de
compétence. Heureusement, ce n'est en général pas le cas.

Indépendamment du fait qu'ici on utilise un serveur web pour distribuer
une pièce jointe, qui est un cas un peu particulier, je ne suis pas sûr
que ce soit neutre d'un point de vue sécurité

Comme je l'ai expliqué, non, ce n'est pas vrai, car toutes ces informations
sont à la discrétion du serveur. Le client doit être robuste vis-à-vis de
toutes les indications qu'il reçoit, et si le serveur veut filtrer des
informations d'origine extérieure pour protéger des clients peu robustes,
c'est sa responsabilité de le faire efficacement.

Yliur

20/09/2015 à 19:39

Le 20 Sep 2015 16:49:04 GMT
Nicolas George <nicolas$ a écrit :

Yliur , dans le message , a écrit :
> Je n'ai pas vérifié, mais j'ai trouvé quelqu'un qui citait la RFC
> 2616 (http 1.1) :

Une RFC spécifie le protocole entre un client et un serveur. Si elle
se mêlait de spécifier le comportement d'une application vis-à-vis de
l'utilisateur, elle sortirait complètement et gravement de son
domaine de compétence. Heureusement, ce n'est en général pas le cas.

Ben là c'est le cas (bien qu'il s'agisse de recommandations et pas
d'obligations). Et le protocole n'est pas totalement indépendant du
comportement de l'un et de l'autre. Avoir un moyen d'obtenir un
comportement similaire dans différentes configurations client/serveur
fait partie de la définition de ce protocole, notamment à cause du fait
que certains contenus envoyés sont actifs dans le client et d'autres
non. Il ne s'agit pas juste du comportement vis-à-vis de l'utilisateur
mais aussi ce que le client est censé faire des données, selon leur
type (et donc de comment il reconnaît leur type).

Le protocole http n'est pas totalement indépendant des infos qui
transitent dessus, la question de savoir comment déterminer le type
d'une information reçue est délicate et traitée en partie par la RFC
(sur la première page : "A feature of HTTP is the typing and
negotiation of data representation, allowing systems to be built
independently of the data being transferred.").

> Indépendamment du fait qu'ici on utilise un serveur web pour
> distribuer une pièce jointe, qui est un cas un peu particulier, je
> ne suis pas sûr que ce soit neutre d'un point de vue sécurité

Comme je l'ai expliqué, non, ce n'est pas vrai, car toutes ces
informations sont à la discrétion du serveur. Le client doit être
robuste vis-à-vis de toutes les indications qu'il reçoit,

Le client est *fait* pour exécuter des contenus actifs (les scripts
notamment), potentiellement dangereux.

et si le
serveur veut filtrer des informations d'origine extérieure pour
protéger des clients peu robustes, c'est sa responsabilité de le
faire efficacement.

Par exemple il peut indiquer au client que quelque chose ne doit pas
être considéré comme un contenu actif interprétable directement, quoi
qu'il y ait dans son nom ou son contenu...

Le 20 Sep 2015 16:49:04 GMT
Nicolas George <nicolas$george@salle-s.org> a écrit :

Yliur , dans le message <20150920184844.76e55af4@free.fr>, a écrit :
> Je n'ai pas vérifié, mais j'ai trouvé quelqu'un qui citait la RFC
> 2616 (http 1.1) :

Une RFC spécifie le protocole entre un client et un serveur. Si elle
se mêlait de spécifier le comportement d'une application vis-à-vis de
l'utilisateur, elle sortirait complètement et gravement de son
domaine de compétence. Heureusement, ce n'est en général pas le cas.

Ben là c'est le cas (bien qu'il s'agisse de recommandations et pas
d'obligations). Et le protocole n'est pas totalement indépendant du
comportement de l'un et de l'autre. Avoir un moyen d'obtenir un
comportement similaire dans différentes configurations client/serveur
fait partie de la définition de ce protocole, notamment à cause du fait
que certains contenus envoyés sont actifs dans le client et d'autres
non. Il ne s'agit pas juste du comportement vis-à-vis de l'utilisateur
mais aussi ce que le client est censé faire des données, selon leur
type (et donc de comment il reconnaît leur type).

Le protocole http n'est pas totalement indépendant des infos qui
transitent dessus, la question de savoir comment déterminer le type
d'une information reçue est délicate et traitée en partie par la RFC
(sur la première page : "A feature of HTTP is the typing and
negotiation of data representation, allowing systems to be built
independently of the data being transferred.").

> Indépendamment du fait qu'ici on utilise un serveur web pour
> distribuer une pièce jointe, qui est un cas un peu particulier, je
> ne suis pas sûr que ce soit neutre d'un point de vue sécurité

Comme je l'ai expliqué, non, ce n'est pas vrai, car toutes ces
informations sont à la discrétion du serveur. Le client doit être
robuste vis-à-vis de toutes les indications qu'il reçoit,

Le client est *fait* pour exécuter des contenus actifs (les scripts
notamment), potentiellement dangereux.

et si le
serveur veut filtrer des informations d'origine extérieure pour
protéger des clients peu robustes, c'est sa responsabilité de le
faire efficacement.

Par exemple il peut indiquer au client que quelque chose ne doit pas
être considéré comme un contenu actif interprétable directement, quoi
qu'il y ait dans son nom ou son contenu...

Vous avez filtré cet utilisateur ! Consultez son message

Le 20 Sep 2015 16:49:04 GMT
Nicolas George <nicolas$ a écrit :

Yliur , dans le message , a écrit :
> Je n'ai pas vérifié, mais j'ai trouvé quelqu'un qui citait la RFC
> 2616 (http 1.1) :

Une RFC spécifie le protocole entre un client et un serveur. Si elle
se mêlait de spécifier le comportement d'une application vis-à-vis de
l'utilisateur, elle sortirait complètement et gravement de son
domaine de compétence. Heureusement, ce n'est en général pas le cas.

Ben là c'est le cas (bien qu'il s'agisse de recommandations et pas
d'obligations). Et le protocole n'est pas totalement indépendant du
comportement de l'un et de l'autre. Avoir un moyen d'obtenir un
comportement similaire dans différentes configurations client/serveur
fait partie de la définition de ce protocole, notamment à cause du fait
que certains contenus envoyés sont actifs dans le client et d'autres
non. Il ne s'agit pas juste du comportement vis-à-vis de l'utilisateur
mais aussi ce que le client est censé faire des données, selon leur
type (et donc de comment il reconnaît leur type).

Le protocole http n'est pas totalement indépendant des infos qui
transitent dessus, la question de savoir comment déterminer le type
d'une information reçue est délicate et traitée en partie par la RFC
(sur la première page : "A feature of HTTP is the typing and
negotiation of data representation, allowing systems to be built
independently of the data being transferred.").

> Indépendamment du fait qu'ici on utilise un serveur web pour
> distribuer une pièce jointe, qui est un cas un peu particulier, je
> ne suis pas sûr que ce soit neutre d'un point de vue sécurité

Comme je l'ai expliqué, non, ce n'est pas vrai, car toutes ces
informations sont à la discrétion du serveur. Le client doit être
robuste vis-à-vis de toutes les indications qu'il reçoit,

Le client est *fait* pour exécuter des contenus actifs (les scripts
notamment), potentiellement dangereux.

et si le
serveur veut filtrer des informations d'origine extérieure pour
protéger des clients peu robustes, c'est sa responsabilité de le
faire efficacement.

Par exemple il peut indiquer au client que quelque chose ne doit pas
être considéré comme un contenu actif interprétable directement, quoi
qu'il y ait dans son nom ou son contenu...

Nicolas George

20/09/2015 à 19:45

Yliur , dans le message , a écrit :

Le protocole http n'est pas totalement indépendant des infos qui
transitent dessus, la question de savoir comment déterminer le type
d'une information reçue est délicate et traitée en partie par la RFC

Le protocole définit comment le client obtient l'information « ce contenu
est de tel type », mais pas ce que le client fait de cette information
ensuite du point de vue de l'interaction avec l'utilisateur. Tout au plus,
les rédacteurs du protocole peuvent (et même doivent) expliquer, dans les
parties non normatives, quel est le genre de comportement attendu qui a
présidé à la conception du protocole.

Le client est *fait* pour exécuter des contenus actifs (les scripts
notamment), potentiellement dangereux.

Si les scripts sont dangereux, il y a déjà un problème.

Par exemple il peut indiquer au client que quelque chose ne doit pas
être considéré comme un contenu actif interprétable directement, quoi
qu'il y ait dans son nom ou son contenu...

Et ce que j'essaie de te faire comprendre, c'est que s'il cherche à faire
ça, il doit le faire efficacement. Mais tout ceci est oiseux : réfléchis
bien à qui contrôle quoi et quelles sont les implications et tu verras que
toute cette partie de la discussion est absolument hors sujet.

Yliur

20/09/2015 à 20:42

Le 20 Sep 2015 17:45:13 GMT
Nicolas George <nicolas$ a écrit :

Yliur , dans le message , a écrit :
> Le protocole http n'est pas totalement indépendant des infos qui
> transitent dessus, la question de savoir comment déterminer le type
> d'une information reçue est délicate et traitée en partie par la RFC

Le protocole définit comment le client obtient l'information « ce
contenu est de tel type », mais pas ce que le client fait de cette
information ensuite du point de vue de l'interaction avec
l'utilisateur. Tout au plus, les rédacteurs du protocole peuvent (et
même doivent) expliquer, dans les parties non normatives, quel est le
genre de comportement attendu qui a présidé à la conception du
protocole.

> Le client est *fait* pour exécuter des contenus actifs (les scripts
> notamment), potentiellement dangereux.

Si les scripts sont dangereux, il y a déjà un problème.

> Par exemple il peut indiquer au client que quelque chose ne doit pas
> être considéré comme un contenu actif interprétable directement,
> quoi qu'il y ait dans son nom ou son contenu...

Et ce que j'essaie de te faire comprendre, c'est que s'il cherche à
faire ça, il doit le faire efficacement. Mais tout ceci est oiseux :
réfléchis bien à qui contrôle quoi et quelles sont les implications
et tu verras que toute cette partie de la discussion est absolument
hors sujet.

Et faire des phrases générales ne résout rien du tout... En fait je ne
pense pas que tu comprennes le problème. D'ailleurs tu ne lis pas
vraiment ce que j'écris, tu t'acharnes sur les questions d'interaction
avec l'utilisateur sans les distinguer du reste.

Nicolas George

20/09/2015 à 20:46

Yliur , dans le message , a écrit :

Et faire des phrases générales ne résout rien du tout... En fait je ne
pense pas que tu comprennes le problème. D'ailleurs tu ne lis pas
vraiment ce que j'écris

Alors essaie d'être plus précis : explique qui tu veux protéger, de quoi et
comment. Tu te rendras compte que ça ne colle pas.

[HS quoi que...] Firefox 40.0.3 (Kubuntu 12.04)

10 réponses

Veuillez sélectionner un problème