Parait que la configuration par defaut de Safari permet aux widgets
dashboard de s'auto downloader et s'auto installer, sans rien demander
à l'utilisateur.
non, bien sur, mais l'effet est le meme, le code du widget est chargé, et il est fonctionnel. Si il doit être nuisible, il le sera aussi bien là que dans le dashboard.
Dans ce cas, au lieu d'installer automatiquement un widget puis de le charger via une redirection "file://.../mechant.html", le site web pourrait simplement rediriger vers "http://server.com/mechant.html".
Je suppose qu'un widget dans Dashboard peut faire plus de choses qu'une page web (ou un widget) dans Safari, mais j'avoue ne pas être spécialiste ni de Dashboard, ni des stratégies de sécurité employée dans Safari.
Patrick -- Patrick Stadelmann
In article <patpro-7BA06D.12004810052005@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
non, bien sur, mais l'effet est le meme, le code du widget est chargé,
et il est fonctionnel. Si il doit être nuisible, il le sera aussi bien
là que dans le dashboard.
Dans ce cas, au lieu d'installer automatiquement un widget puis de le
charger via une redirection "file://.../mechant.html", le site web
pourrait simplement rediriger vers "http://server.com/mechant.html".
Je suppose qu'un widget dans Dashboard peut faire plus de choses qu'une
page web (ou un widget) dans Safari, mais j'avoue ne pas être
spécialiste ni de Dashboard, ni des stratégies de sécurité employée dans
Safari.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
non, bien sur, mais l'effet est le meme, le code du widget est chargé, et il est fonctionnel. Si il doit être nuisible, il le sera aussi bien là que dans le dashboard.
Dans ce cas, au lieu d'installer automatiquement un widget puis de le charger via une redirection "file://.../mechant.html", le site web pourrait simplement rediriger vers "http://server.com/mechant.html".
Je suppose qu'un widget dans Dashboard peut faire plus de choses qu'une page web (ou un widget) dans Safari, mais j'avoue ne pas être spécialiste ni de Dashboard, ni des stratégies de sécurité employée dans Safari.
Patrick -- Patrick Stadelmann
patpro ~ Patrick Proniewski
In article , Patrick Stadelmann wrote:
In article , patpro ~ Patrick Proniewski wrote:
non, bien sur, mais l'effet est le meme, le code du widget est chargé, et il est fonctionnel. Si il doit être nuisible, il le sera aussi bien là que dans le dashboard.
Dans ce cas, au lieu d'installer automatiquement un widget puis de le charger via une redirection "file://.../mechant.html", le site web pourrait simplement rediriger vers "http://server.com/mechant.html".
je n'ai pas lu la doc Dashboard encore, mais je suppose que l'exécution locale (file://) n'a pas les mêmes conséquences que via http://. Ça demande a être vérifié, et je n'ai pas de Tiger sous les yeux pour faire le test.
patpro
In article <Patrick.Stadelmann-980FE0.14514910052005@individual.net>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
In article <patpro-7BA06D.12004810052005@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
non, bien sur, mais l'effet est le meme, le code du widget est chargé,
et il est fonctionnel. Si il doit être nuisible, il le sera aussi bien
là que dans le dashboard.
Dans ce cas, au lieu d'installer automatiquement un widget puis de le
charger via une redirection "file://.../mechant.html", le site web
pourrait simplement rediriger vers "http://server.com/mechant.html".
je n'ai pas lu la doc Dashboard encore, mais je suppose que l'exécution
locale (file://) n'a pas les mêmes conséquences que via http://.
Ça demande a être vérifié, et je n'ai pas de Tiger sous les yeux pour
faire le test.
non, bien sur, mais l'effet est le meme, le code du widget est chargé, et il est fonctionnel. Si il doit être nuisible, il le sera aussi bien là que dans le dashboard.
Dans ce cas, au lieu d'installer automatiquement un widget puis de le charger via une redirection "file://.../mechant.html", le site web pourrait simplement rediriger vers "http://server.com/mechant.html".
je n'ai pas lu la doc Dashboard encore, mais je suppose que l'exécution locale (file://) n'a pas les mêmes conséquences que via http://. Ça demande a être vérifié, et je n'ai pas de Tiger sous les yeux pour faire le test.
patpro
Patrick Stadelmann
In article <4280908b$0$286$, Laurent PERON wrote:
Question subsidiaire :
Les widgets ont-ils les mêmes droit que l'utilisateur qui les lance, ou bien ont ils des droits restreints spécifiques aux widgets, qui les rendent inoffensifs ?
(Je suis quand meme supris qu'apple propose un truc pareil, qui avec la config par défaut de Tiger, peut permettre à une saleté de s'installer d'un seul clic sur une page web).
De s'installer, mais pas de s'activer sans le concours de l'utilisateur. C'est pas pire qu'avec les .zip sous Panther : si une page web malicieuse force le téléchargement d'un .dmg contenant un malware. Safari va monter l'image, ce qui techniquement revient à "installer" le malware : en effet, une application peut tout à fait être exécutée depuis un image disque montée. Ce malware pourrait de plus être déguisé en fichier MP3, cf le fameux trojan MP3 signalé par Intego.
Dans les deux cas cependant, l'utilisateur devra explicitement soit activer le widget dans Dashboard, soit ouvrir le malware.
Patrick -- Patrick Stadelmann
In article <4280908b$0$286$636a15ce@news.free.fr>,
Laurent PERON <laurent_point_peron_point_lap@free.fr> wrote:
Question subsidiaire :
Les widgets ont-ils les mêmes droit que l'utilisateur qui les lance, ou
bien ont ils des droits restreints spécifiques aux widgets, qui les
rendent inoffensifs ?
(Je suis quand meme supris qu'apple propose un truc pareil, qui avec la
config par défaut de Tiger, peut permettre à une saleté de s'installer
d'un seul clic sur une page web).
De s'installer, mais pas de s'activer sans le concours de l'utilisateur.
C'est pas pire qu'avec les .zip sous Panther : si une page web
malicieuse force le téléchargement d'un .dmg contenant un malware.
Safari va monter l'image, ce qui techniquement revient à "installer" le
malware : en effet, une application peut tout à fait être exécutée
depuis un image disque montée. Ce malware pourrait de plus être déguisé
en fichier MP3, cf le fameux trojan MP3 signalé par Intego.
Dans les deux cas cependant, l'utilisateur devra explicitement soit
activer le widget dans Dashboard, soit ouvrir le malware.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Les widgets ont-ils les mêmes droit que l'utilisateur qui les lance, ou bien ont ils des droits restreints spécifiques aux widgets, qui les rendent inoffensifs ?
(Je suis quand meme supris qu'apple propose un truc pareil, qui avec la config par défaut de Tiger, peut permettre à une saleté de s'installer d'un seul clic sur une page web).
De s'installer, mais pas de s'activer sans le concours de l'utilisateur. C'est pas pire qu'avec les .zip sous Panther : si une page web malicieuse force le téléchargement d'un .dmg contenant un malware. Safari va monter l'image, ce qui techniquement revient à "installer" le malware : en effet, une application peut tout à fait être exécutée depuis un image disque montée. Ce malware pourrait de plus être déguisé en fichier MP3, cf le fameux trojan MP3 signalé par Intego.
Dans les deux cas cependant, l'utilisateur devra explicitement soit activer le widget dans Dashboard, soit ouvrir le malware.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article , patpro ~ Patrick Proniewski wrote:
In article , Patrick Stadelmann wrote:
In article , patpro ~ Patrick Proniewski wrote:
non, bien sur, mais l'effet est le meme, le code du widget est chargé, et il est fonctionnel. Si il doit être nuisible, il le sera aussi bien là que dans le dashboard.
Dans ce cas, au lieu d'installer automatiquement un widget puis de le charger via une redirection "file://.../mechant.html", le site web pourrait simplement rediriger vers "http://server.com/mechant.html".
je n'ai pas lu la doc Dashboard encore,
On est deux.
mais je suppose que l'exécution locale (file://) n'a pas les mêmes conséquences que via http://. Ça demande a être vérifié, et je n'ai pas de Tiger sous les yeux pour faire le test.
Dans ce cas, pas de besoin de Dashboard : je force le téléchargement d'un fichier .html malicieux zippé, que Safari décompresse et laisse sur le bureau. Suffit ensuite de rediriger via "file:" pour charger le fichier.
Mieux, je met le fichier .html sur une image disque, comme cela je n'ai même pas besoin de connaître le nom du compte pour construire l'URL.
En tout cas, il semble qu'il y ait une différence entre exécuter le widget dans Dashboard et le charger dans Safari : le module d'exemple "which", qui appelle cette commande, fonctionne dans Dashboard, mais pas dans Safari.
Patrick -- Patrick Stadelmann
In article <patpro-6AD1AE.14553310052005@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
In article <Patrick.Stadelmann-980FE0.14514910052005@individual.net>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
In article <patpro-7BA06D.12004810052005@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
non, bien sur, mais l'effet est le meme, le code du widget est chargé,
et il est fonctionnel. Si il doit être nuisible, il le sera aussi bien
là que dans le dashboard.
Dans ce cas, au lieu d'installer automatiquement un widget puis de le
charger via une redirection "file://.../mechant.html", le site web
pourrait simplement rediriger vers "http://server.com/mechant.html".
je n'ai pas lu la doc Dashboard encore,
On est deux.
mais je suppose que l'exécution
locale (file://) n'a pas les mêmes conséquences que via http://.
Ça demande a être vérifié, et je n'ai pas de Tiger sous les yeux pour
faire le test.
Dans ce cas, pas de besoin de Dashboard : je force le téléchargement
d'un fichier .html malicieux zippé, que Safari décompresse et laisse sur
le bureau. Suffit ensuite de rediriger via "file:" pour charger le
fichier.
Mieux, je met le fichier .html sur une image disque, comme cela je n'ai
même pas besoin de connaître le nom du compte pour construire l'URL.
En tout cas, il semble qu'il y ait une différence entre exécuter le
widget dans Dashboard et le charger dans Safari : le module d'exemple
"which", qui appelle cette commande, fonctionne dans Dashboard, mais pas
dans Safari.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
non, bien sur, mais l'effet est le meme, le code du widget est chargé, et il est fonctionnel. Si il doit être nuisible, il le sera aussi bien là que dans le dashboard.
Dans ce cas, au lieu d'installer automatiquement un widget puis de le charger via une redirection "file://.../mechant.html", le site web pourrait simplement rediriger vers "http://server.com/mechant.html".
je n'ai pas lu la doc Dashboard encore,
On est deux.
mais je suppose que l'exécution locale (file://) n'a pas les mêmes conséquences que via http://. Ça demande a être vérifié, et je n'ai pas de Tiger sous les yeux pour faire le test.
Dans ce cas, pas de besoin de Dashboard : je force le téléchargement d'un fichier .html malicieux zippé, que Safari décompresse et laisse sur le bureau. Suffit ensuite de rediriger via "file:" pour charger le fichier.
Mieux, je met le fichier .html sur une image disque, comme cela je n'ai même pas besoin de connaître le nom du compte pour construire l'URL.
En tout cas, il semble qu'il y ait une différence entre exécuter le widget dans Dashboard et le charger dans Safari : le module d'exemple "which", qui appelle cette commande, fonctionne dans Dashboard, mais pas dans Safari.
Patrick -- Patrick Stadelmann
patpro ~ Patrick Proniewski
In article , Patrick Stadelmann wrote:
Dans ce cas, pas de besoin de Dashboard : je force le téléchargement d'un fichier .html malicieux zippé, que Safari décompresse et laisse sur le bureau. Suffit ensuite de rediriger via "file:" pour charger le fichier.
Mieux, je met le fichier .html sur une image disque, comme cela je n'ai même pas besoin de connaître le nom du compte pour construire l'URL.
file://~/Desktop/ fonctionne, en tout cas sur le Panther que j'ai sous les yeux. Donc nul besoin de connaître le nom du compte. Seule planche de salut dans ce cas, ne pas utiliser l'emplacement par défaut pour les pièces jointes.
En tout cas, il semble qu'il y ait une différence entre exécuter le widget dans Dashboard et le charger dans Safari : le module d'exemple "which", qui appelle cette commande, fonctionne dans Dashboard, mais pas dans Safari.
ok, pas eu l'occaz de tester, c'est une bonne nouvelle.
Du reste que pour l'utilisateur peu attentif, qui n'a pas eu le temps de prendre Dashboard en main, il n'est pas évident de se rendre compte que tel Widget "n'était pas là avant", par exemple. Donc à mon sens, voir les widget se charger tout seuls dans le bon dossier pour être prêt à l'emploi dans DashBoard est un soucis sérieux de sécurité.
patpro
In article <Patrick.Stadelmann-BC60A1.15491110052005@individual.net>,
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Dans ce cas, pas de besoin de Dashboard : je force le téléchargement
d'un fichier .html malicieux zippé, que Safari décompresse et laisse sur
le bureau. Suffit ensuite de rediriger via "file:" pour charger le
fichier.
Mieux, je met le fichier .html sur une image disque, comme cela je n'ai
même pas besoin de connaître le nom du compte pour construire l'URL.
file://~/Desktop/ fonctionne, en tout cas sur le Panther que j'ai sous
les yeux. Donc nul besoin de connaître le nom du compte. Seule planche
de salut dans ce cas, ne pas utiliser l'emplacement par défaut pour les
pièces jointes.
En tout cas, il semble qu'il y ait une différence entre exécuter le
widget dans Dashboard et le charger dans Safari : le module d'exemple
"which", qui appelle cette commande, fonctionne dans Dashboard, mais pas
dans Safari.
ok, pas eu l'occaz de tester, c'est une bonne nouvelle.
Du reste que pour l'utilisateur peu attentif, qui n'a pas eu le temps de
prendre Dashboard en main, il n'est pas évident de se rendre compte que
tel Widget "n'était pas là avant", par exemple.
Donc à mon sens, voir les widget se charger tout seuls dans le bon
dossier pour être prêt à l'emploi dans DashBoard est un soucis sérieux
de sécurité.
Dans ce cas, pas de besoin de Dashboard : je force le téléchargement d'un fichier .html malicieux zippé, que Safari décompresse et laisse sur le bureau. Suffit ensuite de rediriger via "file:" pour charger le fichier.
Mieux, je met le fichier .html sur une image disque, comme cela je n'ai même pas besoin de connaître le nom du compte pour construire l'URL.
file://~/Desktop/ fonctionne, en tout cas sur le Panther que j'ai sous les yeux. Donc nul besoin de connaître le nom du compte. Seule planche de salut dans ce cas, ne pas utiliser l'emplacement par défaut pour les pièces jointes.
En tout cas, il semble qu'il y ait une différence entre exécuter le widget dans Dashboard et le charger dans Safari : le module d'exemple "which", qui appelle cette commande, fonctionne dans Dashboard, mais pas dans Safari.
ok, pas eu l'occaz de tester, c'est une bonne nouvelle.
Du reste que pour l'utilisateur peu attentif, qui n'a pas eu le temps de prendre Dashboard en main, il n'est pas évident de se rendre compte que tel Widget "n'était pas là avant", par exemple. Donc à mon sens, voir les widget se charger tout seuls dans le bon dossier pour être prêt à l'emploi dans DashBoard est un soucis sérieux de sécurité.
patpro
Patrick Stadelmann
In article , patpro ~ Patrick Proniewski wrote:
file://~/Desktop/ fonctionne, en tout cas sur le Panther que j'ai sous les yeux. Donc nul besoin de connaître le nom du compte. Seule planche de salut dans ce cas, ne pas utiliser l'emplacement par défaut pour les pièces jointes.
Sous Tiger, ça me donne une erreur. Si j'essaie file://~/Library/ ça m'ouvre /Library. On dirait qu'il ignore simplement le ~.
Du reste que pour l'utilisateur peu attentif, qui n'a pas eu le temps de prendre Dashboard en main, il n'est pas évident de se rendre compte que tel Widget "n'était pas là avant", par exemple.
Tout à fait.
Donc à mon sens, voir les widget se charger tout seuls dans le bon dossier pour être prêt à l'emploi dans DashBoard est un soucis sérieux de sécurité.
Je vois deux solutions possibles. La première consiste à supprimer l'installation automatique, et à adopter le même comportement que pour les panneaux de préférences : lorsque l'on double-clique dessus, le Finder propose de l'installer. Inconvénient, on ne peut plus utiliser les widgets sans les installer.
Deuxième solution : Dashboard demande une confirmation quand on active pour le première fois un widget se trouvant dans le ~/Library/Widget. Ca pemet de conserver l'utilisation occasionnelle d'un widget sans l'installer.
Patrick -- Patrick Stadelmann
In article <patpro-A6E7BA.15570810052005@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
file://~/Desktop/ fonctionne, en tout cas sur le Panther que j'ai sous
les yeux. Donc nul besoin de connaître le nom du compte. Seule planche
de salut dans ce cas, ne pas utiliser l'emplacement par défaut pour les
pièces jointes.
Sous Tiger, ça me donne une erreur. Si j'essaie file://~/Library/ ça
m'ouvre /Library. On dirait qu'il ignore simplement le ~.
Du reste que pour l'utilisateur peu attentif, qui n'a pas eu le temps de
prendre Dashboard en main, il n'est pas évident de se rendre compte que
tel Widget "n'était pas là avant", par exemple.
Tout à fait.
Donc à mon sens, voir les widget se charger tout seuls dans le bon
dossier pour être prêt à l'emploi dans DashBoard est un soucis sérieux
de sécurité.
Je vois deux solutions possibles. La première consiste à supprimer
l'installation automatique, et à adopter le même comportement que pour
les panneaux de préférences : lorsque l'on double-clique dessus, le
Finder propose de l'installer. Inconvénient, on ne peut plus utiliser
les widgets sans les installer.
Deuxième solution : Dashboard demande une confirmation quand on active
pour le première fois un widget se trouvant dans le ~/Library/Widget.
Ca pemet de conserver l'utilisation occasionnelle d'un widget sans
l'installer.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
file://~/Desktop/ fonctionne, en tout cas sur le Panther que j'ai sous les yeux. Donc nul besoin de connaître le nom du compte. Seule planche de salut dans ce cas, ne pas utiliser l'emplacement par défaut pour les pièces jointes.
Sous Tiger, ça me donne une erreur. Si j'essaie file://~/Library/ ça m'ouvre /Library. On dirait qu'il ignore simplement le ~.
Du reste que pour l'utilisateur peu attentif, qui n'a pas eu le temps de prendre Dashboard en main, il n'est pas évident de se rendre compte que tel Widget "n'était pas là avant", par exemple.
Tout à fait.
Donc à mon sens, voir les widget se charger tout seuls dans le bon dossier pour être prêt à l'emploi dans DashBoard est un soucis sérieux de sécurité.
Je vois deux solutions possibles. La première consiste à supprimer l'installation automatique, et à adopter le même comportement que pour les panneaux de préférences : lorsque l'on double-clique dessus, le Finder propose de l'installer. Inconvénient, on ne peut plus utiliser les widgets sans les installer.
Deuxième solution : Dashboard demande une confirmation quand on active pour le première fois un widget se trouvant dans le ~/Library/Widget. Ca pemet de conserver l'utilisation occasionnelle d'un widget sans l'installer.
