Autoblog de BohwaZ

On Debian : download the oxideqt-codecs-extra package from Ubuntu website and install it.

On Ubuntu :

sudo apt update && sudo apt install oxideqt-codecs-extra

If you happen to stumble on this error on Debian or Ubuntu:

[31:31:1029/204029:ERROR:nss_util.cc(211)] Error initializing NSS without a persistent database: NSS error code: -8023

Here is the fix: just add the following line to /etc/chromium/default:

EXTRALIB=/usr/lib/xulrunner-24.0:/usr/lib/xulrunner-1.9.1

Source: Eric De Mund on Debian Users mailing list

Si vous n'avez pas suivi l'histoire, depuis deux semaines les Panama Papers c'est une fuite de documents d'un cabinet d'avocats du Panama qui crée et administre des sociétés écran dans des paradis fiscaux. Procédé utilisé par les riches et les criminels pour blanchir de l'argent sale ou le cacher des services fiscaux. Dans les documents révélés on trouve de nombreux noms : chefs d'état, PDG, sportifs, avocats et autres membres de la caste des 1%. On constate aussi que les banques (françaises notamment) sont largement partie prenante du procédé malgré des promesses main sur le cœur que non on n'a rien à voir avec les paradis fiscaux.

Ce qu'il faut se rappeler c'est que si certains pays ou noms sont un peu épargnés par cette fuite massive (dûe probablement à un Wordpress dépassé et troué de failles de sécurité !) c'est que ce n'est qu'un seul cabinet spécialisé dans ce business, mais il y en a des milliers dans le monde ! Et ça m'étonnerait fort que ce genre de pratique ne soit pas répandu chez une large majorité des 1% les plus riches, ceux-là même qui abusent des médias pour dire qu'il y a trop d'impôts et de charges, alors qu'ils ne payent qu'une infime partie de ce qu'ils devraient payer. Et pendant ce temps-là on nous rabache que le problème c'est la fraude des chômeurs et des allocations familiales, qui ne représente absolument rien par rapport à cette fraude massive, organisée et soutenue par les plus grandes entreprises.

Mais ce n'est pas là ce dont je veux parler. Ce qui m'étonne le plus dans tous ces montages fumeux c'est que ce sont vraiment des montages douteux. Comment peut-on être multi-millionnaire et être assez bête pour confier des dizaines de millions d'euros à une entreprise créée dans un pays où on a jamais mis les pieds et dirigée par un prête-nom qui gagne probablement à peine plus qu'un SMIC français ? Enfin je sais pas vous mais moi je vois bien la faille du dirigeant prête-nom qui se barre avec l'argent de la société-écran, disparaissant à jamais. C'est un risque énorme. Et si ça arrive vous faites quoi, vous allez porter plainte que l'argent que vous blanchissez a été volé ?

Pour illustrer cette chaîne de confiance complètement stupide on peut prendre pour exemple ce qui se passe dans le reportage de Cash Investigation où un journaliste se rend chez une société suisse pour créer une société offshore. Cette dernière est enregistrée au Delaware (USA), et il reçoit ensuite une carte bancaire et un compte d'une banque néo-zélandaise. C'est déjà assez suspect comme ça, mais c'est dommage que les journalistes n'aient pas cherché un peu plus loin sur cette fameuse banque, car quand j'ai entendu le nom ça m'a rappelé quelque chose… En cherchant j'ai retrouvé un article que j'avais lu sur un journal de Nouvelle-Zélande, et c'est accablant : cette banque (Breder Suasso) n'en est pas vraiment une. Elle n'a aucun client en Nouvelle-Zélande (et les refuse), et pire n'a aucun compte en Nouvelle-Zélande. Donc le compte du journaliste en Nouvelle-Zélande est en réalité soit dans les Iles Marshall ou en Pologne, on ne sait pas vraiment (selon cet article).

Vous avez donc envoyé de l'argent dans une société basée au Delaware, avec un compte dans une entité néo-zélandaise, mais l'argent serait en réalité dans un autre pays, vous ne savez pas vraiment lequel. Pour moi ça ressemble plus à un scam à large échelle qu'à un montage offshore. Et si Breder Suasso ne vous semble pas suffisamment douteuse comme ça, apprenez que son seul actionnaire et président est résident de l'Île Maurice. L'entreprise n'a pas vraiment de locaux en NZ, un simple bureau partagé avec plusieurs entreprises. Vous sentez venir le gag ? Et oui : la banque est en réalité elle aussi une société-écran, une coquille vide qui ne sert que de façade.

Franchement moi j'aurais peur de confier mon argent à des compagnies comme ça, ça n'inspire aucune confiance. Mais bon en même temps, je ne suis pas multi-millionnaire, alors je n'ai pas les même problèmes !

Autant j'aime beaucoup les namespaces, la séparation claire des fonctions et autres sucreries en PHP, autant j'ai l'impression qu'on est maintenant dans un excès inverse. Avant on avait des gros fichiers monolithiques remplis de fonctions sans rapport les unes avec les autres c'était crade. Mais maintenant on a un énorme bordel de fichiers et classes qui ne servent à rien et ne font que détruire les perfs du serveur.

Évidemment ça ne se voit pas trop sur un serveur qui ne sert qu'une seule application car le code et les fichiers restent en RAM, mais quand on est en mutualisé avec des milliers d'applis sur le même dédié, ça se ressent bien. D'abord car charger un fichier depuis le disque à un coût, et ensuite parce qu'une classe en PHP occupe pas mal d'espace mémoire, même si elle est vide (cf. notamment la conférence de Julien Pauli).

Prenons quelques exemples. En premier picoFeed de Frédéric Guillot, qui lui sert notamment pour miniflux, que j'apprécie beaucoup (même si c'est pas encore ça à mon avis). C'est un parseur de flux RSS/Atom qui se veut "simple" et "rapide" qui fait tout un tas de choses genre récupération du contenu des articles pour les flux qui ne fournissent rien, la possibilité de générer des flux, des filtres de contenu, etc. Mais ça reste un exemple quand même. Cette librairie (une fois supprimées les règles de récupération de contenu) fait 47 fichiers, dont 16 qui font moins de 200 octets. Prenons un exemple, de 125 octets, Parser/Rss92.php:

namespace PicoFeed\Parser;

/**
 * RSS 0.92 Parser.
 *
 * @author  Frederic Guillot
 */
class Rss92 extends Rss20
{
}

Et toutes ces classes sont comme ça, elles ne servent à rien à part avoir un nom différent. Pourquoi ne pas faire un if/else ou switch case pour gérer ces cas plutôt que de créer des classes vides ? C'est moche.

Et ce n'est qu'une seule lib qui ne sert qu'à faire du RSS/Atom. Imaginez une appli complète avec des dizaines de libs de la même manière. Oh évidemment on ne charge pas tous les fichiers de toutes les libs (et donc toutes les classes) à chaque requête mais bon niveau perfs ça se ressent quand même.

Je suis aussi particulièrement admiratif quand je vois une lib (ou appli etc.) avec des dizaines ou centaines de classes pour gérer des exceptions (record : 450 !). Chaque classe ne faisant qu'étendre une autre classe d'exceptions. picoFeed est un peu victime de ça, même si vu la taille de la lib ça reste correct. On va dire que je me répète à force mais : à quoi ça sert d'avoir une classe pour chaque type d'exception imaginable ? Vous avez oublié que le second paramètre du constructeur d'une exception c'est $code ? Et à quoi ça sert $code ? Et bien à passer un code d'erreur !

Ainsi dans picoFeed on a ClientException (qui étend Exception), et des classes qui l'étendent : InvalidUrlException, InvalidCertificateException, MaxRedirectException, MaxSizeException, et TimeoutException.

Pourquoi ne pas avoir une seule classe/exception et un code d'erreur différent pour chaque situation ? Ces exceptions ne servent à rien, 99% des utilisateurs de la lib ne vont pas les récupérer individuellement. De même que ça n'aurait aucun sens que MySQL rejette une classe d'exception différente à chaque erreur différente, qui irait vraiment utiliser MySQLException_ER_CANT_CREATE_TABLE par exemple ? Quasiment personne, et c'est pour ça que ça a du sens d'utiliser le code d'erreur.

Je pourrais parler aussi de UA-Parser, une lib qui permet de parser l'User-Agent du navigateur. Bon je sais que c'est devenu compliqué de parser ce bordel d'UA avec le temps, mais quand même, 27 classes pour ça ? 130 Ko de code, et ça ne comprend même pas le fichier avec les regexs utilisées pour reconnaître l'user-agent !

Bref il y aurait de quoi simplifier ici, et tendre vers plus de légèreté et cesser un peu cette expansion lyrique qui n'a pas grande utilité, vous ne pensez pas ?

Autant j'aime beaucoup les namespaces, la séparation claire des fonctions et autres sucreries en PHP, autant j'ai l'impression qu'on est maintenant dans un excès inverse. Avant on avait des gros fichiers monolithiques remplis de fonctions sans rapport les unes avec les autres c'était crade. Mais maintenant on a un énorme bordel de fichiers et classes qui ne servent à rien et ne font que détruire les perfs du serveur.

Évidemment ça ne se voit pas trop sur un serveur qui ne sert qu'une seule application car le code et les fichiers restent en RAM, mais quand on est en mutualisé avec des milliers d'applis sur le même dédié, ça se ressent bien. D'abord car charger un fichier depuis le disque à un coût, et ensuite parce qu'une classe en PHP occupe pas mal d'espace mémoire, même si elle est vide (cf. notamment la conférence de Julien Pauli).

Prenons quelques exemples. En premier picoFeed de Frédéric Guillot, qui lui sert notamment pour miniflux, que j'apprécie beaucoup (même si c'est pas encore ça à mon avis). C'est un parseur de flux RSS/Atom qui se veut "simple" et "rapide" qui fait tout un tas de choses genre récupération du contenu des articles pour les flux qui ne fournissent rien, la possibilité de générer des flux, des filtres de contenu, etc. Mais ça reste un exemple quand même. Cette librairie (une fois supprimées les règles de récupération de contenu) fait 47 fichiers, dont 16 qui font moins de 200 octets. Prenons un exemple, de 125 octets, Parser/Rss92.php:

namespace PicoFeed\Parser;

/**
 * RSS 0.92 Parser.
 *
 * @author  Frederic Guillot
 */
class Rss92 extends Rss20
{
}

Et toutes ces classes sont comme ça, elles ne servent à rien à part avoir un nom différent. Pourquoi ne pas faire un if/else ou switch case pour gérer ces cas plutôt que de créer des classes vides ? C'est moche.

Et ce n'est qu'une seule lib qui ne sert qu'à faire du RSS/Atom. Imaginez une appli complète avec des dizaines de libs de la même manière. Oh évidemment on ne charge pas tous les fichiers de toutes les libs (et donc toutes les classes) à chaque requête mais bon niveau perfs ça se ressent quand même.

Je suis aussi particulièrement admiratif quand je vois une lib (ou appli etc.) avec des dizaines ou centaines de classes pour gérer des exceptions (record : 450 !). Chaque classe ne faisant qu'étendre une autre classe d'exceptions. picoFeed est un peu victime de ça, même si vu la taille de la lib ça reste correct. On va dire que je me répète à force mais : à quoi ça sert d'avoir une classe pour chaque type d'exception imaginable ? Vous avez oublié que le second paramètre du constructeur d'une exception c'est $code ? Et à quoi ça sert $code ? Et bien à passer un code d'erreur !

Ainsi dans picoFeed on a ClientException (qui étend Exception), et des classes qui l'étendent : InvalidUrlException, InvalidCertificateException, MaxRedirectException, MaxSizeException, et TimeoutException.

Pourquoi ne pas avoir une seule classe/exception et un code d'erreur différent pour chaque situation ? Ces exceptions ne servent à rien, 99% des utilisateurs de la lib ne vont pas les récupérer individuellement. De même que ça n'aurait aucun sens que MySQL rejette une classe d'exception différente à chaque erreur différente, qui irait vraiment utiliser MySQLException_ER_CANT_CREATE_TABLE par exemple ? Quasiment personne, et c'est pour ça que ça a du sens d'utiliser le code d'erreur.

Je pourrais parler aussi de UA-Parser, une lib qui permet de parser l'User-Agent du navigateur. Bon je sais que c'est devenu compliqué de parser ce bordel d'UA avec le temps, mais quand même, 27 classes pour ça ? 130 Ko de code, et ça ne comprend même pas le fichier avec les regexs utilisées pour reconnaître l'user-agent !

Bref il y aurait de quoi simplifier ici, et tendre vers plus de légèreté et cesser un peu cette expansion lyrique qui n'a pas grande utilité, vous ne pensez pas ?

PS : pour ceux/celles qui demandent une alternative à picoFeed je ne peux que conseiller ma propre solution (modestie oblige ;-) ), FeedParser, issu du Framework KD2 (qui n'est pas un vrai framework structurant mais un ensemble de libs pratiques, légères et utiles, utilisables indépendamment les unes des autres). La stratégie de parsing est complètement différente : FeedParser n'utilise pas DOMDocument ou SimpleXML pour parser un document car les sites génèrent souvent du XML invalide. De ce fait FeedParser fait du parsing/lexing directement sur le flux, même s'il est invalide. Et ça marche ! Dans mes tests j'ai 100% de succès (aucun flux n'est illisible) sur plus de 20.000 flux, dont 15% de flux invalides. Et évidemment une seule classe, 17 Ko de code, contre pas loin de 400 Ko pour picoFeed par exemple.

Fotoo Hosting est (toujours) un script permettant de créer un service d'hébergement d'images auto-hébergé (comme imgur par exemple), gérant les albums, mais aussi et surtout le redimensionnement en javascript des images avant envoi, ce qui est très pratique pour envoyer des photos depuis une connexion lente, du coup au lieu d'envoyer des fichiers de 5 Mo ou plus on n'envoie qu'environ 400 Ko par image.

Cette nouvelle version 2.1.0 ajoute des options pour l'administration : stockage des adresses IP des uploaders (avec effacement automatique après la période légale de conservation), possibilité de bannir des IPs (ou des masques ou des ranges même, supporte IPv6), et la suppression de plusieurs images ou albums en même temps.

Toutes les infos ici : Fotoo Hosting

Et bien sûr toujours la démo : i.kd2.org

Suite à la demande populaire (comprendre quelques mails par an) je remet en ligne le site de WikiKubbe avec l'installeur à télécharger. Ce script de wiki en PHP4 est sorti en 2003 ou 2002, donc pas loin d'une douzaine d'années, et la dernière mise à jour date de 2006. De manière assez surprenante ça marche toujours chez Free.fr, et ça pourrait sûrement marcher sur PHP 5 ou PHP 7 avec quelques corrections (notamment les ereg_*), mais on verra ça un autre jour. En tout cas je suis étonné que certains l'utilisent encore.

Si vous avez développé des patchs ou autres modifs pour WikiKubbe (je sais qu'il y en a qui tournent sur PHP 5 notamment) n'hésitez pas à me contacter et envoyer vos modifs ou scripts et j'intégrerais ça au WikiKubbe "officiel".

Donc le site au passage : http://dev.kd2.org/wikikubbe/

Voilà mon compte lautre.net a été détruit hier.

J'étais membre depuis 2000 ou 2001 je ne sais plus trop, je n'ai pas accès à mes mails datant d'avant 2002 de toutes façons. Ça fait donc quasiment quinze ans que j'étais membre de cet hébergeur auto-géré auquel j'ai participé à la hauteur de mes capacités, notamment en créant annuaire.lautre.net, en aidant les gens sur le forum d'aide et autres trucs du quotidien. Bon en réalité j'ai surtout participé à saturer le premier serveur de lautre.net à cause du succès imprévu de Journal Intime.com (qui continue, toujours quelques millions de visiteurs chaque mois).

On a combattu ensemble les lois qui s'attaquaient à la vie privée, au statut des hébergeurs, et par dessus tout on a démontré qu'un hébergeur web de masse, pas cher, indépendant, associatif et libre est une réalité possible. Et ce malgré les difficultés inhérentes à ce genre de projet. Aujourd'hui je ne suis plus d'accord avec les dernières décisions prises ainsi que le fonctionnement global de l'association qui ne correspond plus à ce que j'attend d'un projet auto-géré et collectif, c'est pour cela que je part, car de plus je n'ai plus grand chose à apporter au projet, et je ne veux pas me retrouver à critiquer ce qui est fait sans pouvoir proposer de m'investir pour changer tout ça.

Malgré tout je me souviendrais avec beaucoup d'émotion de tout ce que nous avons fait, et des personnes rencontrées. Alors un grand merci à tout le monde, et plus particulièrement aux roots, passés, présents et futurs, notamment Benjamin, Olive, Rémi, Cédric, daffy, etc. Mais aussi en particulier un grand merci à Camille et Chantal qui m'ont hébergé ou payé le billet de train pour aller rencontrer les autres membres à Paris alors que j'avais à peine 15 ans ! Merci à toutes et tous, et à bientôt sur le grand internet !

Voilà mon compte lautre.net a été détruit hier.

J'étais membre depuis 2000 ou 2001 je ne sais plus trop, je n'ai pas accès à mes mails datant d'avant 2002 de toutes façons. Ça fait donc quasiment quinze ans que j'étais membre de cet hébergeur auto-géré auquel j'ai participé à la hauteur de mes capacités, notamment en créant annuaire.lautre.net, en aidant les gens sur le forum d'aide et autres trucs du quotidien. Bon en réalité j'ai surtout participé à saturer le premier serveur de lautre.net à cause du succès imprévu de Journal Intime.com (qui continue, toujours quelques millions de visiteurs chaque mois).

On a combattu ensemble les lois qui s'attaquaient à la vie privée, au statut des hébergeurs, et par dessus tout on a démontré qu'un hébergeur web de masse, pas cher, indépendant, associatif et libre est une réalité possible. Et ce malgré les difficultés inhérentes à ce genre de projet. Aujourd'hui je ne suis plus d'accord avec les dernières décisions prises ainsi que le fonctionnement global de l'association qui ne correspond plus à ce que j'attends d'un projet auto-géré et collectif, c'est pour cela que je pars, car de plus je n'ai plus grand chose à apporter au projet, et je ne veux pas me retrouver à critiquer ce qui est fait sans pouvoir proposer de m'investir pour changer tout ça.

Malgré tout je me souviendrai avec beaucoup d'émotion de tout ce que nous avons fait, et des personnes rencontrées. Alors un grand merci à tout le monde, et plus particulièrement aux roots, passés, présents et futurs, notamment Benjamin, Olive, Rémi, Cédric, daffy, etc. Mais aussi en particulier un grand merci à Camille et Chantal qui m'ont hébergé ou payé le billet de train pour aller rencontrer les autres membres à Paris alors que j'avais à peine 15 ans ! Merci à toutes et tous, et à bientôt sur le grand internet !

You are ordering something online, like a new TV, on an online store, or maybe you are ordering an airplane ticket on Air New Zealand. You complete your order, then comes the time to pay. You can't find your credit card which must be in your tuesday pants, which are buried under two weeks worth of dirty clothes in a corner of your bedroom. Or you don't want to pay the credit card surcharge charged by Air NZ. So on the payment webpage you spot this intriguing payment option: Internet Bank Payment.

This looks like a safe thing, practical and all, when you click on help, Air NZ assures you that this is a legit thing, and "you can use to safely pay for your flights directly from your bank account". Seems nice, why not try it. You don't know what this "POLi" thing is, but if it says it's safe, why not? It even tells you that "at no time are your personal banking login details disclosed to Air New Zealand or POLi". Sounds great. Let's do it!

First you have to chose your bank in a dropdown menu, fill a captcha code. If there is a captcha it must be secure. You click next and a nice popup show in the page, asking you... your online banking credentials. Oh. Wait. Didn't I read on every email and letter ever sent by my bank that I should never disclose my online banking credentials to anyone?

OK. This is where you should be stopping and never entering your banking details in that form and never trust POLi Payments. And you will see why.

So, what is POLi Payments? It is a private company, a subsidiary of Australia Post, that provides a "payment solution" for merchants so that Australian and New Zealanders customers can pay an order via their own bank account. You must think that this is a very serious business, and that they should have agreements with all the australian and NZ banks, and that they must be using some kind of banking API or back-end to make transactions.

Well, you are wrong. POLi Payments don't have agreements with the banks. They don't use a secure API or anything like that.

Do you remember the scam and phishing websites your bank tells you about? That you should be careful of not entering your banking details on any website other than the one of your bank? Well they work by doing something simple: they build a fake website asking your credentials, then they collect them, store them and use them to connect to your banks website and do fraudulent transactions.

And what does POLi exactly? They ask for your banking credentials, they collect them and use them to connect to your banks website and do a "legitimate" transaction, in fact they just do a wire transfer. Yup, pretty similar stuff.

The only difference is that POLi is supposed to be a legitimate business, and they tell you that it's really secure. OK, then would you write down on a paper your banking login and password to give to the cashier at the supermarket so that he could make a transfer to the supermarket account to pay for your groceries? Yes, probably not. Even if he assured you that he would destroy the paper after the transfer, you couldn't see him destroy it. This seems a bit unsafe no? Well, it's the same thing that POLi is doing. Yes. They are in fact doing a man-in-the-middle attack on your bank website, there is no other word for it.

Remember when the Air NZ website said: "at no time are your personal banking login details disclosed to Air New Zealand or POLi"? Well, obviously when you are entering your banking login details on the POLi pop-up, you are disclosing them! Even if they claim that they claim that they "do not capture or store usernames or passwords" (POLi Security overview), your login and password is transmitted to the POLi servers, stored in memory and transmitted to your banks website. Because POLi is in fact only a sophisticated "proxy" that navigates on the website of your bank with their servers.

This so-called "payment solution" is definitely misleading and a major security risk should you disclose your banking credentials to them. And I bet they get a number of credentials and transactions done as they seem to be doing everything to tell that they are really safe and secure and they are in fact just a proxy server, like Opera Mini. Which is true, but this is not really reassuring. And one of the many problems of POLi is the fact that they are using an iframe embedded in the merchant website. This means that even though you are disclosing your banking credentials on the POLi website, the fact that it is inside the merchants website means that the merchants website could access your banking credentials when you are entering them in the POLi frame, or even it could maybe exploit a security flaw in POLi proxy service and do other actions or transactions on your online banking using the POLi proxy server. And did you think about other resources used on the merchants website? Like for example a script for analytics, or an external javascript library sideloaded from another website, or ads. They all may access your banking credentials through the POLi frame as well.

The fact that the embedded frame displays a Comodo logo and a padlock is even more misleading, as it suggests that the frame is served over HTTPS, which you have no way of knowing for sure.

And it doesn't stop here, as POLi is using the access to your online banking to collect informations on your bank account, including past transactions or account balances, as it is written in their privacy policy:

We may also collect your financial information including bank account balances, bank account payment limits, a record of your previous banking transactions and information about your internet banking sessions.

Worse, their terms and conditions are deliberately wrong:

Your account access information such as usernames and passwords are not captured or stored by POLi™ or by our website.

And it is repeated on the FAQ of Air New Zealand:

During the course of your payment, Air New Zealand and POLi never have access to your internet banking identifier or password

This is blatantly false, as you can see when you check the requests made from the POLi frame, your login and password are in fact sent to the POLi server:

IMAGE

Not only their service is a terribly bad idea to begin with, but their own terms and conditions don't reflect the reality of what their service is actually doing.

So there is a lot of problems with POLi and in my opinion no one should use it. Why?

• You should never enter your banking login or password on any other site that the one of your bank. NEVER.
• You would have to trust POLi that they don't keep your credentials.
• POLi is not a bank, not a secure payment solution, and doesn't have to comply to any security guidelines or external audit. So you can't really trust their servers to be secure and not compromised.
• POLi doesn't have agreements with the banks and most banks advise against using it.
• The merchant has potential access to your banking credentials. And even if the merchant website was safe, merchants websites are not immune to XSS attacks, and what about their advertisers, analytics or dozens of othen external resources? There is no way to analyze and check that everything in the chain is and will stay secure.
• POLi collect details about your banking transaction history and account balance. This should stay private.
• It potentially breaches your bank terms and conditions.

So: don't use POLi. Ever. And I'm not the only one saying it. No, really.

And merchants shouldn't use it either as it just shows how bad they are at understanding the safety of their customers. If they accepted to use POLi as a payment option, you should really be worried as how they store and process other private informations. In the case of AirNZ I am really worried as they seem to process credit card numbers themselves. I do not want to know how they store them!

If you are not convinced check out what the banks are thinking below. I don't know why the POLi servers are not blocked by the banks, but it is clear that they don't like this idea:

• KiwiBank (NZ): We advise against using POLiPayments as it invalidates our internet banking guarantee & is not secure. and Providing your details through a third party is against terms and conditions and we very much advise against it
• Commonwealth (AU): The Commonwealth Bank does not have any working agreement with POLi Payments. The Bank urges customers making online payments to do so via the Bank’s own NetBank site, which guarantees the customer’s security.
• ASB (NZ): we recommend that you do not use the POLi payment service due to the security risks involved and Using POLi or Account2Account’s payment system requires users to input their username and password to a third party which breaches ASB FastNet Classic’s Terms and Conditions.
• Westpac (AU): POLI is not supported by the bank. If making online pymts, should do so via bank's own site which guarantees customer's security
• ANZ: ANZ reminds customers not to enter your ANZ Internet Banking log on information when using non-ANZ sites.
• BNZ: Providing log in details to a third party presents serious security risks and contradicts both the New Zealand Code of Banking Practice and our terms and conditions.
• Bank Australia: Unfortunately POLi payments don’t meet our security standards.
• Bank of Queensland: We take your Internet Banking security very seriously and, for this reason, we do not support the use of 3rd party applications such as POLi. While it may seem that you are in complete control of the Internet Banking session whilst using POLi, we cannot guarantee the security of your logon credentials unless you access Internet Banking via the BOQ website.

The fact that an idea like POLi is allowed to legally exist is a major problem. How can you seriously educate people to never give out their banking details if you allow this kind of "service"?