C'était une façon non standard de le faire (je pense que Mozilla et Internet Explorer le supportent toujours) mais déconner aux attentes des utilisateurs est une mauvaise idée.

Si l'utilisateur saisit les détails de sa carte de crédit dans un formulaire, puis laisse quelqu'un d'autre utiliser ce navigateur, cela ne vous concerne pas. :)

Nous avons effectivement utilisé l'idée de sasb pour un site. Il s'agissait d'une application Web de logiciel médical pour gérer un cabinet médical. Cependant, bon nombre de nos clients étaient des chirurgiens qui utilisaient de nombreux postes de travail différents, y compris des terminaux semi-publics. Ainsi, ils voulaient s'assurer qu'un médecin qui ne comprend pas l'implication des mots de passe enregistrés automatiquement ou qui ne fait pas attention ne puisse pas accidentellement laisser ses informations de connexion facilement accessibles. Bien sûr, c'était avant l'idée de la navigation privée qui commence à apparaître dans IE8, FF3.1, etc. Même ainsi, de nombreux médecins sont obligés d'utiliser des navigateurs à l'ancienne dans les hôpitaux avec une informatique qui ne changera pas.

Nous avons donc demandé à la page de connexion de générer des noms de champs aléatoires qui ne fonctionneraient que pour ce message. Oui, c'est moins pratique, mais c'est juste prendre l'utilisateur au-dessus de la tête de ne pas stocker les informations de connexion sur les terminaux publics.

En plus de autocomplete=off, vous pouvez également faire en sorte que les noms de vos champs de formulaire soient randomisés par le code qui génère la page, peut-être en ajoutant une chaîne spécifique à la session à la fin des noms.

Lorsque le formulaire est soumis, vous pouvez supprimer cette partie avant de les traiter côté serveur. Cela empêcherait le navigateur Web de trouver le contexte de votre champ et pourrait également aider à prévenir les attaques XSRF, car un attaquant ne serait pas en mesure de deviner les noms des champs pour une soumission de formulaire.