Sur le principe, je ne suis pas fan de ce genre de blocages par défaut, avec le risque de surblocages et la difficulté de passer outre pour l'utilisateur de base.
Pour le https, certes l'erreur dans le navigateur n'est pas claire, mais d'un autre côté le but est atteint si l'utilisateur s'arrête là.
Mais il ne faudrait pas que ça banalise les erreurs de certificats, ça pourrait être à double tranchant.
Quand le blocage ne concernera pas le domaine du site visité, mais uniquement domaine utilisé pour des images ou des scripts, l'utilisateur ne sera pas vraiment averti (le site va mal d'afficher ou mal fonctionner).
Le serveur pourrait retourner une image d'avertissement quand on lui demande une image, mais pour les scripts à part un alert("Attention, le site que vous visitez charge des scripts venant d'un site de phishing") pas très élégant je ne vois pas.
Mais l'implémentation côté Belgique ne me semble pas géniale : la page d'avertissement n'est qu'à la racine du site, quel que soit le Host utilisé
Du coup si l'utilisateur essaye de charger
http://site.bloque/test, il va se retrouver avec une page d'erreur 404.
De même avec
http://sitebloque.com/fr/donnees-personelles, il tombera sur la politique de données personnelles du CCB, etc...
Ils devraient afficher la page d'erreur pour n'importe quelle URL, sauf quand le champ Host vaut baps.ccb.belgium.be, et utiliser des URL absolues pour les liens sur la page (
http://baps.ccb.belgium.be/fr/belgian-anti-phishing-shield, ...).
Je note que
http://52.149.77.208/fr/donnees-personelles est assez générique, et ne dit pas ce qu'il advient des données des utilisateurs ayant été redirigés sur cette IP (une visite involontaire donc).
Certes c'est limité au http (sauf si l'utilisateur met une exception), mais le serveur reçoit :
- l'IP de l'utilisateur
- l'ensemble de l'URL d'origine
- les cookies associés au nom de domaine d'origine