Proposition de suppression de cette règle.
Les navigateurs incluent désormais des règles noopener/noreferrer implicitement :
- https://html.spec.whatwg.org/multipage/links.html#following-hyperlinks (specs)
- https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#browser_compatibility (compatibilité)
Discuté côté WordPress dans ce ticket public : https://core.trac.wordpress.org/ticket/53843
Clairement, comme le disaient Grégoire et Boris - si je n'étais pas clair - le cas que j'ai mentionné est un "cas à la con", voué à disparaitre.
Les navigateurs poussent à limiter ça, les recos aussi, les outils le mentionnent déjà comme pour Mozilla Observatory... je suis tout à fait pour l'ajout de cette BP.
Le libellé "Les liens externes qui ouvrent une nouvelle fenêtre ne partagent pas d'information de contexte" me convient, je suis favorable à son ajout en BP.
OK, je demande d'autres avis sur Slack, histoire d'être sûr à 100% qu'on ne fait pas de bêtise, et en attendant elle reste en candidate.
Réaliste : oui, ça se fait très bien et on a la possibilité de passer par l'URL les infos en paramètre.
Utile tout le temps : oui, puisque utile aux utilisateurs.
Valable pendant 5 ans : la non-transmission de données personnelles, sera là encore dans 5ans.
Je n'ai jamais vu de cas où le retour de paiement passait par le contexte de page passé en JS (ne serait-ce que parce que ça se ferait côté client, ça serait trop facile à falsifier).
Il s'agit en général d'un fonctionnement avec URLs de callback, donc ça n'a rien à voir.
Mais bien sûr le fait que je ne l'ai pas vu ne veut pas dire que ça n'existe pas : tu avais un exemple précis en tête ?
Pardon, on a besoin d'être certain ou presque que :
C'est réaliste, utile tout le temps et valable pendant les 5 prochaines années. Nous ne manquons pas de bonnes pratiques. Si on est pas sûr, il est beaucoup moins grave de l'avoir en recommandation que d'avoir une bonne pratique bancale. Pour l'instant, j'ai Grégoire qui la pousse à fond et c'est tout, donc j'attends d'être sûr à 100%.
Avec Firefox qui va probablement forcer avec sont "first isolation" ça va devenir de plus en plus complexe, en effet. Ça reste, néanmoins, une bonne pratique qu'il faudrait mettre en place, mais libre aux créateurs de site de ne pas le mettre en place…
Tu peux avoir des cas dans du paiement où tu dois ouvrir un truc et attendre un retour depuis un autre onglet, mais c'est pas forcément une bonne idée car les navigateurs mettent un paquet de freins à ce genre de pratique ^^
Si détaillé dans la fiche, concernant le contexte "initial", ça me semble pas mal
{Les liens externes qui ouvrent une nouvelle fenêtre ne partagent pas d'informations de contexte}
1. Les deux, pour moi ça va de paire, je met l'un et l'autre ensemble (sans réelle distinction sur les liens externe)
2. Je parle des liens vers des domaines externes, ça doit pas se rencontrer beaucoup sur des webapp ou des sites, je vois très mal des appli/site faire du multi-domaine pour leur usages, la question c'est de ne pas filer d'infos (contexte d'exécution, referrer…) à un domaine externe, c'est le cœur de la proposition ici. Si un lien vers un autre domaine est mis en place, il ne devrait pas partager d'infos sur la source, qu'il y ai des liens vers des ressources externes, c'est la base du web, il me semble pas avoir dis quoique ce soit à son encontre (ni dans la citation tronquée, ni dans le message initial)
@Grégoire : 1/ est-ce que ton commentaire concerne le Referrer ou le Opener ? 2/ "ça doit être très très limité les webapp qui changent de domaine sur des liens" Je ne vois pas d'où te viens cette idée, à quoi tu penses. Les liens hypertextes me semblent au contraire très majoritaires, et au cœur du Web. Ou alors tu mets une définition derrière "webapp" que je n'ai pas, mais qui, du coup, n'est pas universelle.
Par « lien externe » faut comprendre "vers un autre domaine", dans ce cas, ça doit être très très limité les webapp qui changent de domaine (complètement, pas juste de sous-domaine) sur des liens. Je manque aussi de recul, mais ça me parait quand même assez énorme.
C'est l'intérêt de la discussion, justement. Typiquement, limiter l'utilisation du `opener`, c'est brider l'usage de l'API `window.opener` https://developer.mozilla.org/en-US/docs/Web/API/Window/opener. Autant sur des landing pages, ça me semble pertinenant, autant j'imagine qu'il doit bien y avoir quelques cas limites de web-app où c'est pertinent… je manque de recul sur ce sujet, n'en ayant jamais croisé, mais ça me gêne de faire une croix sur une API qui a sûrement été développé pour une certaine raison.
Et pourquoi ne pas lier les deux ? Voire peut-être {Les liens externes ouvrant une nouvelle fenêtre ne partagent pas leur contexte} (on pourrait avoir le même type pour les liens n'ouvrant pas de nouvelle fenêtre, mais étant externes (déjà discuté au dessus))
La formulation laisse à penser que seules des informations pourraient circuler, et cela colle assez bien à noreferrer, mais pour le cas de noopener, c'est le contexte lui-même qui est passé. Concrètement, la nouvelle page ouverte (par exemple, dans un nouvel onglet) peut dégrader l'expérience de navigation sur la page source (plus d'infos : https://blog.dareboost.com/fr/2017/03/target-blank-rel-noopener-securite-performance/).
Je pense donc que la formulation est bonne mais ne s'applique qu'au referrer (et que côté implémentation, on a le rel="noreferrer" mais aussi le header HTTP referrer-policy), et qu'une autre reco devrait entrer en discussion : "les liens s'ouvrant dans des nouvelles fenêtres ne partagent pas leur contexte d'exécution".
On tombe dans la gestion des liens externes (changement de domaine), sans target. Il faudrait mettre sensiblement le même code pour la réalisation (cf. début de discussion et exemple Google/MDN)
Quid des liens qui s'ouvrent dans une nouvelle fenêtre non via target="_blank" mais via JS ?
{Les liens externes ouvrant une nouvelle fenêtre ne partagent pas d'information sur leur contexte initial} et c'est en effet si utilisation de "target" (cf. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#target deux sources valent mieux qu'une)
Nous avons besoin de nous appuyer au moins sur un standard du métier. Dans ce cas, Google visant les liens en target _blank. Mais oui pour les liens externes, {Les liens externes qui ouvrent une nouvelle fenêtre ne partagent pas d'information sur leur contexte initial} ?
Dans l'exemple c'est un "target =_blank", mais cela s'applique à tous liens.
De plus la reformulation n'indique pas que ce sont des liens externes, en interne ça ne pose pas de problème.
Si je comprend bien, le noopener / referrer est utile pour les liens en target _blank (et c'est de la sécurité)
Dans ce cas, le libellé de la proposition de bonne pratique serait plutôt :
{Les liens qui ouvrent une nouvelle fenêtre ne partagent pas d'information sur leur contexte initial}
Qu'en dites-vous ?
Oui, c'est exactement le rôle de ça, qui est d'ailleurs préconisé par Google lui-même (https://developers.google.com/web/tools/lighthouse/audits/noopener), partant de là… de plus les résultats de recherche Google sont déjà en noopener+noreferrer (donc l'information ne parvient pas au site), et on parle des liens externes, donc ne pas donner d'infos à d'autres sites, de quel expérience utilisateur parle-t-on quant il s'agit d'offrir à d'autres sites des informations sur les utilisateurs de nos sites ? Quels sont les arguments de "la communauté du référencement" ? (la curiosité m'habite à ce sujet)
Vous voulez dire que côté valeur ajoutée utilisateur, le fait que les liens externes soit en no referrer va éviter le traçage?
Moi, je ne me sens pas en mesure de défendre ce choix devant la communauté du référencement qui va m'arguer - à juste titre- que ces infos leur permettent d'améliorer l'expérience utilisateur ;)
Allez, hop, on reformule, on cherche :p
Définir "lien externe", mais un lien sortant du site est un lien externe (qu'il soit vers un sous-domaine ou un domaine différent). Systématiquement ? Je dirais "oui", lien externe → site externe, et "valeur ajoutée" : éviter de faire fuiter des infos d'un site à un autre (sur un historique de navigation, une provenance, une recherche…)
Intéressant. Deux questions : est-ce quelque chose à mettre systématiquement pour tous les liens, et quelle est la valeur ajoutée pour l"utilisateur final ?
Voir : rel="noreferrer" pour les liens.
Permet de prévenir la fuite d'informations d'un domaine à un autre
