Dans son message envoyé le 09/04/2004 20:37, Julien Salort
<lists@juliensalort.org>, écrivait ...
> Par contre c'est vrai, il peut être trompé par l'icône. Mais comme il
> peut également être trompé par l'extension, je ne vois pas la différence
> sinon que l'icône est plus user-friendly.
Il est vrai, je l'admets, c'est l'icône qui séduit le plus souvent au
premier abord.
Mais, dans ce fil de discussion, lorsque l'on traite de l'apparence de
l'icône, je suis plutôt, comment dire, ennuyé car, dans le prototype en
question, on en revient sans cesse à l'icône bien connue de l'application
iTunes.
Or, cet après-midi, j'ai testé le prototype proposé en téléchargement à
<http://www.scoop.se/~blgl/virus.mp3.sit>.
Comme je le rapportais dans mon message envoyé vers ce forum hier le 9 à
17:15, l'icône du fichier virus.mp3 représente celle d'une application
générique, peu importe le mode de vue (par icônes, par liste, par colonnes).
En outre, File Buddy 7.6 me confirme qu'il s'agit d'un icône générique et
non d'un icône personnalisé. Je n'ai pas poussé jusque l'édition de l'icône
au moyen de Resorcerer 2.4.1 (OSX).
Puis-je en déduire que le prototype téléchargeable à
<http://www.scoop.se/~blgl/virus.mp3.sit> présente une lacune au niveau de
l'icône ?
Obtenez-vous un phénomène semblable ?
Je sais la remplacer facilement - comme nous savons le faire - mais, alors,
les règles du jeu sont faussées, donc, uniquement en ce qui concerne
l'apparence destinée à séduire le pigeon ...
A votre avis ...
--
________/J/e/a/n/_______________/P/r/u/d/h/o/m/m/e/________
Le difficile n'est pas d'apprendre ce qu'on ne sait pas, c'est d'apprendre
ce qu'on sait. [Jacques Salomé "Si je m'écoutais, je m'entendrais"]
In article <BC9CFE40.16F94%, Jean Prudhomme wrote:
Mais, dans ce fil de discussion, lorsque l'on traite de l'apparence de l'icône, je suis plutôt, comment dire, ennuyé car, dans le prototype en question, on en revient sans cesse à l'icône bien connue de l'application iTunes.
Or, cet après-midi, j'ai testé le prototype proposé en téléchargement à <http://www.scoop.se/~blgl/virus.mp3.sit>.
Comme je le rapportais dans mon message envoyé vers ce forum hier le 9 à 17:15, l'icône du fichier virus.mp3 représente celle d'une application générique, peu importe le mode de vue (par icônes, par liste, par colonnes).
Ce n'est pas le cas normalement. Plusieurs personnes (dont je fais partie) avait bien un icône de MP3.
En outre, File Buddy 7.6 me confirme qu'il s'agit d'un icône générique et non d'un icône personnalisé. Je n'ai pas poussé jusque l'édition de l'icône au moyen de Resorcerer 2.4.1 (OSX).
Ce n'est pas une icône personalisée (ie collé via la fenêtre d'info), mais l'icône contient l'icône (comme toute application Carbon).
Puis-je en déduire que le prototype téléchargeable à <http://www.scoop.se/~blgl/virus.mp3.sit> présente une lacune au niveau de l'icône ?
Obtenez-vous un phénomène semblable ?
Non.
Patrick -- Patrick Stadelmann
In article <BC9CFE40.16F94%jean.prudhomme@skynet.be>,
Jean Prudhomme <jean.prudhomme@skynet.be> wrote:
Mais, dans ce fil de discussion, lorsque l'on traite de l'apparence de
l'icône, je suis plutôt, comment dire, ennuyé car, dans le prototype en
question, on en revient sans cesse à l'icône bien connue de l'application
iTunes.
Or, cet après-midi, j'ai testé le prototype proposé en téléchargement à
<http://www.scoop.se/~blgl/virus.mp3.sit>.
Comme je le rapportais dans mon message envoyé vers ce forum hier le 9 à
17:15, l'icône du fichier virus.mp3 représente celle d'une application
générique, peu importe le mode de vue (par icônes, par liste, par colonnes).
Ce n'est pas le cas normalement. Plusieurs personnes (dont je fais
partie) avait bien un icône de MP3.
En outre, File Buddy 7.6 me confirme qu'il s'agit d'un icône générique et
non d'un icône personnalisé. Je n'ai pas poussé jusque l'édition de l'icône
au moyen de Resorcerer 2.4.1 (OSX).
Ce n'est pas une icône personalisée (ie collé via la fenêtre d'info),
mais l'icône contient l'icône (comme toute application Carbon).
Puis-je en déduire que le prototype téléchargeable à
<http://www.scoop.se/~blgl/virus.mp3.sit> présente une lacune au niveau de
l'icône ?
Obtenez-vous un phénomène semblable ?
Non.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <BC9CFE40.16F94%, Jean Prudhomme wrote:
Mais, dans ce fil de discussion, lorsque l'on traite de l'apparence de l'icône, je suis plutôt, comment dire, ennuyé car, dans le prototype en question, on en revient sans cesse à l'icône bien connue de l'application iTunes.
Or, cet après-midi, j'ai testé le prototype proposé en téléchargement à <http://www.scoop.se/~blgl/virus.mp3.sit>.
Comme je le rapportais dans mon message envoyé vers ce forum hier le 9 à 17:15, l'icône du fichier virus.mp3 représente celle d'une application générique, peu importe le mode de vue (par icônes, par liste, par colonnes).
Ce n'est pas le cas normalement. Plusieurs personnes (dont je fais partie) avait bien un icône de MP3.
En outre, File Buddy 7.6 me confirme qu'il s'agit d'un icône générique et non d'un icône personnalisé. Je n'ai pas poussé jusque l'édition de l'icône au moyen de Resorcerer 2.4.1 (OSX).
Ce n'est pas une icône personalisée (ie collé via la fenêtre d'info), mais l'icône contient l'icône (comme toute application Carbon).
Puis-je en déduire que le prototype téléchargeable à <http://www.scoop.se/~blgl/virus.mp3.sit> présente une lacune au niveau de l'icône ?
Obtenez-vous un phénomène semblable ?
Non.
Patrick -- Patrick Stadelmann
Jean Prudhomme
Dans son message envoyé le 10/04/2004 10:22, Patrick Stadelmann , écrivait ...
Jean Prudhomme wrote:
Mais, dans ce fil de discussion, lorsque l'on traite de l'apparence de l'icône, je suis plutôt, comment dire, ennuyé car, dans le prototype en question, on en revient sans cesse à l'icône bien connue de l'application iTunes.
Or, cet après-midi, j'ai testé le prototype proposé en téléchargement à <http://www.scoop.se/~blgl/virus.mp3.sit>.
Comme je le rapportais dans mon message envoyé vers ce forum hier le 9 à 17:15, l'icône du fichier virus.mp3 représente celle d'une application générique, peu importe le mode de vue (par icônes, par liste, par colonnes).
Ce n'est pas le cas normalement. Plusieurs personnes (dont je fais partie) avait bien un icône de MP3.
Je ne sais pas si cela peut constituer une explication mais, chez moi, c'est l'application Audion qui est associée pour jouer tous les fichier.mp3 et, évidemment, c'est l'icône d'Audion qui apparaît systématiquement lorsqu'il s'agit d'un vrai_fichier.mp3. Serait-ce un début de parade ...
Cordialement, Jean --
Dans son message envoyé le 10/04/2004 10:22, Patrick Stadelmann
<Patrick.Stadelmann@unine.ch>, écrivait ...
Jean Prudhomme <jean.prudhomme@skynet.be> wrote:
Mais, dans ce fil de discussion, lorsque l'on traite de l'apparence de
l'icône, je suis plutôt, comment dire, ennuyé car, dans le prototype en
question, on en revient sans cesse à l'icône bien connue de l'application
iTunes.
Or, cet après-midi, j'ai testé le prototype proposé en téléchargement à
<http://www.scoop.se/~blgl/virus.mp3.sit>.
Comme je le rapportais dans mon message envoyé vers ce forum hier le 9 à
17:15, l'icône du fichier virus.mp3 représente celle d'une application
générique, peu importe le mode de vue (par icônes, par liste, par colonnes).
Ce n'est pas le cas normalement. Plusieurs personnes (dont je fais
partie) avait bien un icône de MP3.
Je ne sais pas si cela peut constituer une explication mais, chez moi, c'est
l'application Audion qui est associée pour jouer tous les fichier.mp3 et,
évidemment, c'est l'icône d'Audion qui apparaît systématiquement lorsqu'il
s'agit d'un vrai_fichier.mp3. Serait-ce un début de parade ...
Dans son message envoyé le 10/04/2004 10:22, Patrick Stadelmann , écrivait ...
Jean Prudhomme wrote:
Mais, dans ce fil de discussion, lorsque l'on traite de l'apparence de l'icône, je suis plutôt, comment dire, ennuyé car, dans le prototype en question, on en revient sans cesse à l'icône bien connue de l'application iTunes.
Or, cet après-midi, j'ai testé le prototype proposé en téléchargement à <http://www.scoop.se/~blgl/virus.mp3.sit>.
Comme je le rapportais dans mon message envoyé vers ce forum hier le 9 à 17:15, l'icône du fichier virus.mp3 représente celle d'une application générique, peu importe le mode de vue (par icônes, par liste, par colonnes).
Ce n'est pas le cas normalement. Plusieurs personnes (dont je fais partie) avait bien un icône de MP3.
Je ne sais pas si cela peut constituer une explication mais, chez moi, c'est l'application Audion qui est associée pour jouer tous les fichier.mp3 et, évidemment, c'est l'icône d'Audion qui apparaît systématiquement lorsqu'il s'agit d'un vrai_fichier.mp3. Serait-ce un début de parade ...
Cordialement, Jean --
Éric Lévénez
Le 10/04/04 11:56, dans <BC9D9184.16FCE%, « Jean Prudhomme » a écrit :
Dans son message envoyé le 10/04/2004 10:22, Patrick Stadelmann , écrivait ...
Ce n'est pas le cas normalement. Plusieurs personnes (dont je fais partie) avait bien un icône de MP3.
Je ne sais pas si cela peut constituer une explication mais, chez moi, c'est l'application Audion qui est associée pour jouer tous les fichier.mp3 et, évidemment, c'est l'icône d'Audion qui apparaît systématiquement lorsqu'il s'agit d'un vrai_fichier.mp3. Serait-ce un début de parade ...
Oui un début. Si on interdit aux documents d'avoir des icônes personnifiées, l'icône du document est celle associée à l'application qui va l'ouvrir. Simple et clair. Aucune surprise.
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
Le 10/04/04 11:56, dans <BC9D9184.16FCE%jean.prudhomme@skynet.be>, « Jean
Prudhomme » <jean.prudhomme@skynet.be> a écrit :
Dans son message envoyé le 10/04/2004 10:22, Patrick Stadelmann
<Patrick.Stadelmann@unine.ch>, écrivait ...
Ce n'est pas le cas normalement. Plusieurs personnes (dont je fais
partie) avait bien un icône de MP3.
Je ne sais pas si cela peut constituer une explication mais, chez moi, c'est
l'application Audion qui est associée pour jouer tous les fichier.mp3 et,
évidemment, c'est l'icône d'Audion qui apparaît systématiquement lorsqu'il
s'agit d'un vrai_fichier.mp3. Serait-ce un début de parade ...
Oui un début. Si on interdit aux documents d'avoir des icônes personnifiées,
l'icône du document est celle associée à l'application qui va l'ouvrir.
Simple et clair. Aucune surprise.
--
Éric Lévénez -- <http://www.levenez.com>
Unix is not only an OS, it's a way of life.
Le 10/04/04 11:56, dans <BC9D9184.16FCE%, « Jean Prudhomme » a écrit :
Dans son message envoyé le 10/04/2004 10:22, Patrick Stadelmann , écrivait ...
Ce n'est pas le cas normalement. Plusieurs personnes (dont je fais partie) avait bien un icône de MP3.
Je ne sais pas si cela peut constituer une explication mais, chez moi, c'est l'application Audion qui est associée pour jouer tous les fichier.mp3 et, évidemment, c'est l'icône d'Audion qui apparaît systématiquement lorsqu'il s'agit d'un vrai_fichier.mp3. Serait-ce un début de parade ...
Oui un début. Si on interdit aux documents d'avoir des icônes personnifiées, l'icône du document est celle associée à l'application qui va l'ouvrir. Simple et clair. Aucune surprise.
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
Patrick Stadelmann
In article <BC9DAEF3.635FE%, Éric Lévénez wrote:
Oui un début. Si on interdit aux documents d'avoir des icônes personnifiées, l'icône du document est celle associée à l'application qui va l'ouvrir. Simple et clair. Aucune surprise.
Et qui te garantit que l'icône de "Lisez Moi" est bien celui d'un document TextEdit, et non pas celui d'un document "Mon Virus.app" caché dans un dossier invisible (sur une image disque par exemple).
Ca fait plus de 10 ans qu'on peut modifier les icônes par simple copier-coller sur Mac, et tout le monde vit très bien avec. Je suis sincérement désolé si c'était différent, et mieux selon toi, sur NeXT mais ici on parle d'un système d'exploitation qui s'appelle "Mac OS X" et non pas "NeXT OS X". Accepte que tout ne soit pas comme avant !
Patrick -- Patrick Stadelmann
In article <BC9DAEF3.635FE%news@levenez.com>,
Éric Lévénez <news@levenez.com> wrote:
Oui un début. Si on interdit aux documents d'avoir des icônes personnifiées,
l'icône du document est celle associée à l'application qui va l'ouvrir.
Simple et clair. Aucune surprise.
Et qui te garantit que l'icône de "Lisez Moi" est bien celui d'un
document TextEdit, et non pas celui d'un document "Mon Virus.app" caché
dans un dossier invisible (sur une image disque par exemple).
Ca fait plus de 10 ans qu'on peut modifier les icônes par simple
copier-coller sur Mac, et tout le monde vit très bien avec. Je suis
sincérement désolé si c'était différent, et mieux selon toi, sur NeXT
mais ici on parle d'un système d'exploitation qui s'appelle "Mac OS X"
et non pas "NeXT OS X". Accepte que tout ne soit pas comme avant !
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Oui un début. Si on interdit aux documents d'avoir des icônes personnifiées, l'icône du document est celle associée à l'application qui va l'ouvrir. Simple et clair. Aucune surprise.
Et qui te garantit que l'icône de "Lisez Moi" est bien celui d'un document TextEdit, et non pas celui d'un document "Mon Virus.app" caché dans un dossier invisible (sur une image disque par exemple).
Ca fait plus de 10 ans qu'on peut modifier les icônes par simple copier-coller sur Mac, et tout le monde vit très bien avec. Je suis sincérement désolé si c'était différent, et mieux selon toi, sur NeXT mais ici on parle d'un système d'exploitation qui s'appelle "Mac OS X" et non pas "NeXT OS X". Accepte que tout ne soit pas comme avant !
Patrick -- Patrick Stadelmann
Éric Lévénez
Le 10/04/04 14:56, dans , « Patrick Stadelmann » a écrit :
In article <BC9DAEF3.635FE%, Éric Lévénez wrote:
Oui un début. Si on interdit aux documents d'avoir des icônes personnifiées, l'icône du document est celle associée à l'application qui va l'ouvrir. Simple et clair. Aucune surprise.
Et qui te garantit que l'icône de "Lisez Moi" est bien celui d'un document TextEdit, et non pas celui d'un document "Mon Virus.app" caché dans un dossier invisible (sur une image disque par exemple).
Parce que cette histoire d'icône n'est qu'une partie du problème. L'autre partie est l'extension des fichiers qui doit être obligatoire et non cachée ainsi que l'abandon du type/créateur. Une fois que l'on a tout cela on a un système simple et fiable. L'utilisateur voit ainsi toutes les applications qu'il utilise et le "Mon Virus.app" ne peut redéfinir l'icône d'une autre application par défaut car c'est un choix de l'utilisateur. Pour changer l'icône "Lisez Moi", il faut que l'utilisateur change l'application par défaut à "Mon Virus.app", et cela est un acte volontaire.
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
Le 10/04/04 14:56, dans
<Patrick.Stadelmann-158F57.14561910042004@news.fu-berlin.de>, « Patrick
Stadelmann » <Patrick.Stadelmann@unine.ch> a écrit :
In article <BC9DAEF3.635FE%news@levenez.com>,
Éric Lévénez <news@levenez.com> wrote:
Oui un début. Si on interdit aux documents d'avoir des icônes personnifiées,
l'icône du document est celle associée à l'application qui va l'ouvrir.
Simple et clair. Aucune surprise.
Et qui te garantit que l'icône de "Lisez Moi" est bien celui d'un
document TextEdit, et non pas celui d'un document "Mon Virus.app" caché
dans un dossier invisible (sur une image disque par exemple).
Parce que cette histoire d'icône n'est qu'une partie du problème. L'autre
partie est l'extension des fichiers qui doit être obligatoire et non cachée
ainsi que l'abandon du type/créateur. Une fois que l'on a tout cela on a un
système simple et fiable. L'utilisateur voit ainsi toutes les applications
qu'il utilise et le "Mon Virus.app" ne peut redéfinir l'icône d'une autre
application par défaut car c'est un choix de l'utilisateur. Pour changer
l'icône "Lisez Moi", il faut que l'utilisateur change l'application par
défaut à "Mon Virus.app", et cela est un acte volontaire.
--
Éric Lévénez -- <http://www.levenez.com>
Unix is not only an OS, it's a way of life.
Le 10/04/04 14:56, dans , « Patrick Stadelmann » a écrit :
In article <BC9DAEF3.635FE%, Éric Lévénez wrote:
Oui un début. Si on interdit aux documents d'avoir des icônes personnifiées, l'icône du document est celle associée à l'application qui va l'ouvrir. Simple et clair. Aucune surprise.
Et qui te garantit que l'icône de "Lisez Moi" est bien celui d'un document TextEdit, et non pas celui d'un document "Mon Virus.app" caché dans un dossier invisible (sur une image disque par exemple).
Parce que cette histoire d'icône n'est qu'une partie du problème. L'autre partie est l'extension des fichiers qui doit être obligatoire et non cachée ainsi que l'abandon du type/créateur. Une fois que l'on a tout cela on a un système simple et fiable. L'utilisateur voit ainsi toutes les applications qu'il utilise et le "Mon Virus.app" ne peut redéfinir l'icône d'une autre application par défaut car c'est un choix de l'utilisateur. Pour changer l'icône "Lisez Moi", il faut que l'utilisateur change l'application par défaut à "Mon Virus.app", et cela est un acte volontaire.
-- Éric Lévénez -- <http://www.levenez.com> Unix is not only an OS, it's a way of life.
Patrick Stadelmann
In article <BC9DC503.6360B%, Éric Lévénez wrote:
Parce que cette histoire d'icône n'est qu'une partie du problème. L'autre partie est l'extension des fichiers qui doit être obligatoire et non cachée ainsi que l'abandon du type/créateur.
Il faudrait encore supprimer la possibilité d'associer une appli autre que celle par défaut à certains fichiers. Sinon l'image disque pourrait contenir un "Lisez Moi.pdf" (sans meta datas) reglé par l'auteur du virus pour s'ouvrir avec "Mon Virus.app".
Une fois que l'on a tout cela on a un système simple et fiable. L'utilisateur voit ainsi toutes les applications qu'il utilise et le "Mon Virus.app" ne peut redéfinir l'icône d'une autre application par défaut car c'est un choix de l'utilisateur. Pour changer l'icône "Lisez Moi", il faut que l'utilisateur change l'application par défaut à "Mon Virus.app", et cela est un acte volontaire.
Non, sauf à supprimer la possibilité évoquée ci-dessus de changer l'appli associée au cas par cas. Donc encore une fonctionnalité extrêmement utilie qui disparaitrait. Et pour quoi ? Juste pour que l'on puisse cliquer les yeux fermés sur les documents reçus ? Je trouve que ca cause trop d'inconvénient et que ce n'est pas assez ciblé sur le problème.
Patrick -- Patrick Stadelmann
In article <BC9DC503.6360B%news@levenez.com>,
Éric Lévénez <news@levenez.com> wrote:
Parce que cette histoire d'icône n'est qu'une partie du problème. L'autre
partie est l'extension des fichiers qui doit être obligatoire et non cachée
ainsi que l'abandon du type/créateur.
Il faudrait encore supprimer la possibilité d'associer une appli autre
que celle par défaut à certains fichiers. Sinon l'image disque pourrait
contenir un "Lisez Moi.pdf" (sans meta datas) reglé par l'auteur du
virus pour s'ouvrir avec "Mon Virus.app".
Une fois que l'on a tout cela on a un
système simple et fiable. L'utilisateur voit ainsi toutes les applications
qu'il utilise et le "Mon Virus.app" ne peut redéfinir l'icône d'une autre
application par défaut car c'est un choix de l'utilisateur. Pour changer
l'icône "Lisez Moi", il faut que l'utilisateur change l'application par
défaut à "Mon Virus.app", et cela est un acte volontaire.
Non, sauf à supprimer la possibilité évoquée ci-dessus de changer
l'appli associée au cas par cas. Donc encore une fonctionnalité
extrêmement utilie qui disparaitrait. Et pour quoi ? Juste pour que l'on
puisse cliquer les yeux fermés sur les documents reçus ? Je trouve que
ca cause trop d'inconvénient et que ce n'est pas assez ciblé sur le
problème.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Parce que cette histoire d'icône n'est qu'une partie du problème. L'autre partie est l'extension des fichiers qui doit être obligatoire et non cachée ainsi que l'abandon du type/créateur.
Il faudrait encore supprimer la possibilité d'associer une appli autre que celle par défaut à certains fichiers. Sinon l'image disque pourrait contenir un "Lisez Moi.pdf" (sans meta datas) reglé par l'auteur du virus pour s'ouvrir avec "Mon Virus.app".
Une fois que l'on a tout cela on a un système simple et fiable. L'utilisateur voit ainsi toutes les applications qu'il utilise et le "Mon Virus.app" ne peut redéfinir l'icône d'une autre application par défaut car c'est un choix de l'utilisateur. Pour changer l'icône "Lisez Moi", il faut que l'utilisateur change l'application par défaut à "Mon Virus.app", et cela est un acte volontaire.
Non, sauf à supprimer la possibilité évoquée ci-dessus de changer l'appli associée au cas par cas. Donc encore une fonctionnalité extrêmement utilie qui disparaitrait. Et pour quoi ? Juste pour que l'on puisse cliquer les yeux fermés sur les documents reçus ? Je trouve que ca cause trop d'inconvénient et que ce n'est pas assez ciblé sur le problème.
Patrick -- Patrick Stadelmann
ol.g+news
Éric Lévénez wrote:
Oui un début. Si on interdit aux documents d'avoir des icônes personnifiées, l'icône du document est celle associée à l'application qui va l'ouvrir. Simple et clair. Aucune surprise.
Et bien entendu, une application en .app qui aura la tronche d'un document ne relèverait pas du même problème ? D'ailleurs, j'ai déjà vu Apple utiliser un .app avec une icône de document texte pour un ReadMe (pour afficher directement une information dans la langue idoine - et ça ne me parait pas idiot du tout). C'est ce cas là qui est réellement un problème en puissance, le cas du document à l'icône changée me semble une broutille en comparaison.
Quand à supposer que la présence 'visible' de l'extension (document ou appli) suffit à résoudre le problème, ça me parait simpliste. On sait bien que la sécurité par l'obscurité ça ne marche pas. La sécurité par la lumière ne me semble valoir guère mieux :) Autant s'attaquer au noeud du problème: qu'est-ce que c'est qu'un document/une application sûre ? que doit être le comportement d'un mailer ? comment être sûr qu'un message vient bien d'un destinataire ? comment vérifier qu'un document est bien du type attendu ? etc.
Ol. -- Olivier Gutknecht
Éric Lévénez <news@levenez.com> wrote:
Oui un début. Si on interdit aux documents d'avoir des icônes personnifiées,
l'icône du document est celle associée à l'application qui va l'ouvrir.
Simple et clair. Aucune surprise.
Et bien entendu, une application en .app qui aura la tronche d'un
document ne relèverait pas du même problème ?
D'ailleurs, j'ai déjà vu Apple utiliser un .app avec une icône de
document texte pour un ReadMe (pour afficher directement une information
dans la langue idoine - et ça ne me parait pas idiot du tout).
C'est ce cas là qui est réellement un problème en puissance, le cas du
document à l'icône changée me semble une broutille en comparaison.
Quand à supposer que la présence 'visible' de l'extension (document ou
appli) suffit à résoudre le problème, ça me parait simpliste. On sait
bien que la sécurité par l'obscurité ça ne marche pas. La sécurité par
la lumière ne me semble valoir guère mieux :) Autant s'attaquer au noeud
du problème: qu'est-ce que c'est qu'un document/une application sûre ?
que doit être le comportement d'un mailer ? comment être sûr qu'un
message vient bien d'un destinataire ? comment vérifier qu'un document
est bien du type attendu ? etc.
Oui un début. Si on interdit aux documents d'avoir des icônes personnifiées, l'icône du document est celle associée à l'application qui va l'ouvrir. Simple et clair. Aucune surprise.
Et bien entendu, une application en .app qui aura la tronche d'un document ne relèverait pas du même problème ? D'ailleurs, j'ai déjà vu Apple utiliser un .app avec une icône de document texte pour un ReadMe (pour afficher directement une information dans la langue idoine - et ça ne me parait pas idiot du tout). C'est ce cas là qui est réellement un problème en puissance, le cas du document à l'icône changée me semble une broutille en comparaison.
Quand à supposer que la présence 'visible' de l'extension (document ou appli) suffit à résoudre le problème, ça me parait simpliste. On sait bien que la sécurité par l'obscurité ça ne marche pas. La sécurité par la lumière ne me semble valoir guère mieux :) Autant s'attaquer au noeud du problème: qu'est-ce que c'est qu'un document/une application sûre ? que doit être le comportement d'un mailer ? comment être sûr qu'un message vient bien d'un destinataire ? comment vérifier qu'un document est bien du type attendu ? etc.
Ol. -- Olivier Gutknecht
nobody
Olivier Gutknecht <ol.g+ wrote:
Quand à supposer que la présence 'visible' de l'extension (document ou appli) suffit à résoudre le problème, ça me parait simpliste.
Ce n'est sans doute pas suffisant, mais c'est sans doute nécessaire. Qu'on puisse immédiatement et sans ambiguïté faire la différence entre un document et une application me semble être le béa-ba. Sinon autant se ballader sur des falaises avec un bandeau sur les yeux.
-- JP
Olivier Gutknecht <ol.g+news@free.fr> wrote:
Quand à supposer que la présence 'visible' de l'extension (document ou
appli) suffit à résoudre le problème, ça me parait simpliste.
Ce n'est sans doute pas suffisant, mais c'est sans doute nécessaire.
Qu'on puisse immédiatement et sans ambiguïté faire la différence entre
un document et une application me semble être le béa-ba. Sinon autant se
ballader sur des falaises avec un bandeau sur les yeux.
Quand à supposer que la présence 'visible' de l'extension (document ou appli) suffit à résoudre le problème, ça me parait simpliste.
Ce n'est sans doute pas suffisant, mais c'est sans doute nécessaire. Qu'on puisse immédiatement et sans ambiguïté faire la différence entre un document et une application me semble être le béa-ba. Sinon autant se ballader sur des falaises avec un bandeau sur les yeux.
-- JP
Éric Lévénez
Le 10/04/04 17:25, dans <1gc1ehe.uaug5agrekgN%ol.g+, « Olivier Gutknecht » <ol.g+ a écrit :
Et bien entendu, une application en .app qui aura la tronche d'un document ne relèverait pas du même problème ?
Qui a dit cela ?
D'ailleurs, j'ai déjà vu Apple utiliser un .app avec une icône de document texte pour un ReadMe (pour afficher directement une information dans la langue idoine - et ça ne me parait pas idiot du tout).
C'est au contraire une très mauvaise idée. Apple en a eu de très mauvaises dès le début de Mac OS X sur la gestion des types/créateurs.
C'est ce cas là qui est réellement un problème en puissance, le cas du document à l'icône changée me semble une broutille en comparaison.
Si les extensions deviennent obligatoires, les utilisateurs prendront l'habitude de les regarder avant de cliquer sur tout ce qui bouge.
Quand à supposer que la présence 'visible' de l'extension (document ou appli) suffit à résoudre le problème, ça me parait simpliste.
Non, c'est simple et efficace.
On sait bien que la sécurité par l'obscurité ça ne marche pas.
On est d'accord, c'est pourquoi il est mauvais de cacher le type d'un fichier dans champ caché HFS.
La sécurité par la lumière ne me semble valoir guère mieux :)
Sur mon clavier il y a des lettres écrites, et cela me permet de savoir ce qui va se passer si j'appuie dessus. Je n'aimerai pas avoir un clavier nu.
Autant s'attaquer au noeud du problème: qu'est-ce que c'est qu'un document/une application sûre ?
Le noeud du problème est "quel est le type de ce document et est-ce que je le connais ?" Si on connaît le type (ex: .mp3, .html, .gif, .app ...) on sait si l'on peut ou non cliquer dessus. On sait qu'un .app est une application et que si on vient de la recevoir par email, il faut faire attention.
Simple (et non simpliste).
que doit être le comportement d'un mailer ?
Un mailer envoie des emails.
Les fichiers qui comportent des virus ne viennent pas que de là.
comment être sûr qu'un message vient bien d'un destinataire ?
On ne peut pas, sauf en utilisant des procédés d'authentification très lourds et en supposant que le réseau que l'on utilise n'est pas aux mains de crackers jouants avec les DNS et autres joyeusetés.
comment vérifier qu'un document est bien du type attendu ?
Un seul champ doit indiquer le type de document, sinon il peut y avoir divergence.
Actuellement quand on reçoit un fichier par email, on a le type Mime, l'extension du fichier, et sous Mac le type/créateur. Cela fait 3 fois trop de champs et donc 3 fois trop de problèmes potentiels.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 10/04/04 17:25, dans <1gc1ehe.uaug5agrekgN%ol.g+news@free.fr>, « Olivier
Gutknecht » <ol.g+news@free.fr> a écrit :
Et bien entendu, une application en .app qui aura la tronche d'un
document ne relèverait pas du même problème ?
Qui a dit cela ?
D'ailleurs, j'ai déjà vu Apple utiliser un .app avec une icône de
document texte pour un ReadMe (pour afficher directement une information
dans la langue idoine - et ça ne me parait pas idiot du tout).
C'est au contraire une très mauvaise idée. Apple en a eu de très mauvaises
dès le début de Mac OS X sur la gestion des types/créateurs.
C'est ce cas là qui est réellement un problème en puissance, le cas du
document à l'icône changée me semble une broutille en comparaison.
Si les extensions deviennent obligatoires, les utilisateurs prendront
l'habitude de les regarder avant de cliquer sur tout ce qui bouge.
Quand à supposer que la présence 'visible' de l'extension (document ou
appli) suffit à résoudre le problème, ça me parait simpliste.
Non, c'est simple et efficace.
On sait
bien que la sécurité par l'obscurité ça ne marche pas.
On est d'accord, c'est pourquoi il est mauvais de cacher le type d'un
fichier dans champ caché HFS.
La sécurité par
la lumière ne me semble valoir guère mieux :)
Sur mon clavier il y a des lettres écrites, et cela me permet de savoir ce
qui va se passer si j'appuie dessus. Je n'aimerai pas avoir un clavier nu.
Autant s'attaquer au noeud
du problème: qu'est-ce que c'est qu'un document/une application sûre ?
Le noeud du problème est "quel est le type de ce document et est-ce que je
le connais ?" Si on connaît le type (ex: .mp3, .html, .gif, .app ...) on
sait si l'on peut ou non cliquer dessus. On sait qu'un .app est une
application et que si on vient de la recevoir par email, il faut faire
attention.
Simple (et non simpliste).
que doit être le comportement d'un mailer ?
Un mailer envoie des emails.
Les fichiers qui comportent des virus ne viennent pas que de là.
comment être sûr qu'un
message vient bien d'un destinataire ?
On ne peut pas, sauf en utilisant des procédés d'authentification très
lourds et en supposant que le réseau que l'on utilise n'est pas aux mains de
crackers jouants avec les DNS et autres joyeusetés.
comment vérifier qu'un document
est bien du type attendu ?
Un seul champ doit indiquer le type de document, sinon il peut y avoir
divergence.
Actuellement quand on reçoit un fichier par email, on a le type Mime,
l'extension du fichier, et sous Mac le type/créateur. Cela fait 3 fois trop
de champs et donc 3 fois trop de problèmes potentiels.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 10/04/04 17:25, dans <1gc1ehe.uaug5agrekgN%ol.g+, « Olivier Gutknecht » <ol.g+ a écrit :
Et bien entendu, une application en .app qui aura la tronche d'un document ne relèverait pas du même problème ?
Qui a dit cela ?
D'ailleurs, j'ai déjà vu Apple utiliser un .app avec une icône de document texte pour un ReadMe (pour afficher directement une information dans la langue idoine - et ça ne me parait pas idiot du tout).
C'est au contraire une très mauvaise idée. Apple en a eu de très mauvaises dès le début de Mac OS X sur la gestion des types/créateurs.
C'est ce cas là qui est réellement un problème en puissance, le cas du document à l'icône changée me semble une broutille en comparaison.
Si les extensions deviennent obligatoires, les utilisateurs prendront l'habitude de les regarder avant de cliquer sur tout ce qui bouge.
Quand à supposer que la présence 'visible' de l'extension (document ou appli) suffit à résoudre le problème, ça me parait simpliste.
Non, c'est simple et efficace.
On sait bien que la sécurité par l'obscurité ça ne marche pas.
On est d'accord, c'est pourquoi il est mauvais de cacher le type d'un fichier dans champ caché HFS.
La sécurité par la lumière ne me semble valoir guère mieux :)
Sur mon clavier il y a des lettres écrites, et cela me permet de savoir ce qui va se passer si j'appuie dessus. Je n'aimerai pas avoir un clavier nu.
Autant s'attaquer au noeud du problème: qu'est-ce que c'est qu'un document/une application sûre ?
Le noeud du problème est "quel est le type de ce document et est-ce que je le connais ?" Si on connaît le type (ex: .mp3, .html, .gif, .app ...) on sait si l'on peut ou non cliquer dessus. On sait qu'un .app est une application et que si on vient de la recevoir par email, il faut faire attention.
Simple (et non simpliste).
que doit être le comportement d'un mailer ?
Un mailer envoie des emails.
Les fichiers qui comportent des virus ne viennent pas que de là.
comment être sûr qu'un message vient bien d'un destinataire ?
On ne peut pas, sauf en utilisant des procédés d'authentification très lourds et en supposant que le réseau que l'on utilise n'est pas aux mains de crackers jouants avec les DNS et autres joyeusetés.
comment vérifier qu'un document est bien du type attendu ?
Un seul champ doit indiquer le type de document, sinon il peut y avoir divergence.
Actuellement quand on reçoit un fichier par email, on a le type Mime, l'extension du fichier, et sous Mac le type/créateur. Cela fait 3 fois trop de champs et donc 3 fois trop de problèmes potentiels.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
listes
Éric Lévénez wrote:
On ne peut pas, sauf en utilisant des procédés d'authentification très lourds et en supposant que le réseau que l'on utilise n'est pas aux mains de crackers jouants avec les DNS et autres joyeusetés.
Morale de l'histoire, signez vos email avec un truc du genre GPG. Et n'oubliez pas de rencontrer vos contacts en personne, histoire de vous échanger vos clés publiques... Efficace (enfin je crois) mais pas super pratique...
-- Olivier Goldberg, étudiant, macmaniaque, plongeur CMAS *** Pour le courrier personnel, remplacer dans le From: listes par olivier AIM/iChat: Nept47
Éric Lévénez <news@levenez.com> wrote:
On ne peut pas, sauf en utilisant des procédés d'authentification très
lourds et en supposant que le réseau que l'on utilise n'est pas aux mains de
crackers jouants avec les DNS et autres joyeusetés.
Morale de l'histoire, signez vos email avec un truc du genre GPG. Et
n'oubliez pas de rencontrer vos contacts en personne, histoire de vous
échanger vos clés publiques...
Efficace (enfin je crois) mais pas super pratique...
--
Olivier Goldberg, étudiant, macmaniaque, plongeur CMAS ***
Pour le courrier personnel, remplacer dans le From: listes par olivier
AIM/iChat: Nept47
On ne peut pas, sauf en utilisant des procédés d'authentification très lourds et en supposant que le réseau que l'on utilise n'est pas aux mains de crackers jouants avec les DNS et autres joyeusetés.
Morale de l'histoire, signez vos email avec un truc du genre GPG. Et n'oubliez pas de rencontrer vos contacts en personne, histoire de vous échanger vos clés publiques... Efficace (enfin je crois) mais pas super pratique...
-- Olivier Goldberg, étudiant, macmaniaque, plongeur CMAS *** Pour le courrier personnel, remplacer dans le From: listes par olivier AIM/iChat: Nept47
