Avoir du code injecté par un tiers est un risque (javascript, macros, applet Java, etc.).
Avoir du code injecté par un tiers dans le code d'un tiers est un plus grand risque (site qui utilise le javascript d'un autre site, etc.).
Avoir du code injecté par un tiers dans le code d'un tiers par un tiers est un encore plus grand risque (pub injectée dans une régie de pub injectée dans un site, etc.).
Etc.
La solution est simple : il suffirait de n'avoir que du code sans bug (du coup l'isolation et la sécurité seraient parfaites, et on pourrait continuer à faire des trucs assez bizarres quand on y réfléchit un peu). À noter que le code sans bug résout aussi pas mal d'autres problèmes en informatique.
Même avec zéro bug dans le code, la pub (comme tout code injecté) reste un problème de sécurité. Un code avec une isolation parfaite n'empêchera pas l'utilisateur de cliquer sur une pub trompeuse, et donc de déclencher une action volontaire et risquée.
Effectivement ça ne traite que ce qui relève du code. Après il faudrait des humains sans faille (probablement asociaux, autarciques, sans dépendance ni confiance dans rien ni personne, et de fait inhumains…).
L'ironie t'échappe visiblement. La discussion initiale est sur le fait d'accepter n'importe quel code depuis l'extérieur. Et oui un bloqueur de trucs inutiles et non demandés est une bonne idée.
En effet elle m'avait échappé. La thèse de l'article peut paraître triviale en ce qu'elle est, comme tu le soulignes, une illustration particulière d'un problème plus général, mais à trop généraliser on perd de vue justement certains cas particuliers qui méritent qu'on s'y intéressent malgré tout. Après je conçois que ça puisse être diversement intéressant pour des publics différents.
# extraits
Posté par pas_pey . Évalué à 8 (+7/-0).
[^] # Re: extraits
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+3/-1).
Avoir du code injecté par un tiers est un risque (javascript, macros, applet Java, etc.).
Avoir du code injecté par un tiers dans le code d'un tiers est un plus grand risque (site qui utilise le javascript d'un autre site, etc.).
Avoir du code injecté par un tiers dans le code d'un tiers par un tiers est un encore plus grand risque (pub injectée dans une régie de pub injectée dans un site, etc.).
Etc.
La solution est simple : il suffirait de n'avoir que du code sans bug (du coup l'isolation et la sécurité seraient parfaites, et on pourrait continuer à faire des trucs assez bizarres quand on y réfléchit un peu). À noter que le code sans bug résout aussi pas mal d'autres problèmes en informatique.
[^] # Re: extraits
Posté par Christophe . Évalué à 9 (+7/-0).
Même avec zéro bug dans le code, la pub (comme tout code injecté) reste un problème de sécurité. Un code avec une isolation parfaite n'empêchera pas l'utilisateur de cliquer sur une pub trompeuse, et donc de déclencher une action volontaire et risquée.
[^] # Re: extraits
Posté par Benoît Sibaud (site web personnel) . Évalué à 2 (+2/-3).
Effectivement ça ne traite que ce qui relève du code. Après il faudrait des humains sans faille (probablement asociaux, autarciques, sans dépendance ni confiance dans rien ni personne, et de fait inhumains…).
[^] # Re: extraits
Posté par pas_pey . Évalué à 2 (+1/-0).
Bref, rien ne sera jamais parfait, donc inutile d'essayer d'améliorer les choses ?
[^] # Re: extraits
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+3/-0).
L'ironie t'échappe visiblement. La discussion initiale est sur le fait d'accepter n'importe quel code depuis l'extérieur. Et oui un bloqueur de trucs inutiles et non demandés est une bonne idée.
[^] # Re: extraits
Posté par pas_pey . Évalué à 2 (+1/-0).
En effet elle m'avait échappé. La thèse de l'article peut paraître triviale en ce qu'elle est, comme tu le soulignes, une illustration particulière d'un problème plus général, mais à trop généraliser on perd de vue justement certains cas particuliers qui méritent qu'on s'y intéressent malgré tout. Après je conçois que ça puisse être diversement intéressant pour des publics différents.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.