J’ai eu l’acces à mon Jeedom bloqué également.
Mon domaine est chez OVH.
J’ai déclaré plusieurs fois le site comme non dangereux et j’ai contacté OVH à ce sujet et le lendemain c’était OK sans plus d’info 
Si ça peut aider quelqu’un.
2 « J'aime »
Hello
Je n’arrive pas à trouver le moyen de contacter Google domains. Les explications pour le support sont tellement alambiquées que je suis perdu dès la deuxième ligne.
Quant à Google, ils corrigent sans dire plus pourquoi qu’ils n’ont dit pourquoi ils bloquaient
Merci
ça serait très intéressant de savoir ce qu’ils ont fait…
Faut demander a gpt…
Ca devient du délire.
On est face a une black box ss info dc c’est inextricable.
1 « J'aime »
Je viens de lui poser la question ^^ pas grand intérêt
Quels sont les critère de Google pour blacklister un site internet?
Google utilise un certain nombre de critères pour évaluer la qualité et la pertinence d’un site web, ainsi que pour identifier les sites potentiellement malveillants ou nuisibles. Voici quelques-uns des critères de base que Google utilise pour blacklister un site internet :
- Contenu de faible qualité ou dupliqué : Google privilégie les sites qui offrent un contenu unique et de haute qualité. Les sites avec du contenu de faible qualité ou dupliqué peuvent être blacklister.
- Contenu malveillant : Les sites qui contiennent des logiciels malveillants, des virus, des chevaux de Troie ou d’autres formes de contenu dangereux peuvent être blacklister.
- Liens non naturels : Les sites qui ont des liens qui semblent artificiels, tels que des liens payants, des échanges de liens, ou des liens qui pointent vers des sites de spam, peuvent être considérés comme manipulatifs et donc blacklister.
- Pratiques de référencement manipulatrices : Les sites qui utilisent des pratiques de référencement trompeuses, telles que la création de pages de porte d’entrée, la dissimulation de texte ou de liens, ou la création de liens vers des sites non pertinents peuvent être blacklister.
- Contenu de spam : Les sites qui contiennent du contenu de spam, tels que des commentaires de spam, des pages avec un grand nombre de mots-clés, ou des annonces intrusives peuvent être blacklister.
Il convient de noter que Google utilise un algorithme complexe pour évaluer les sites web et peut utiliser des critères supplémentaires pour décider de blacklister un site. Pour éviter d’être blacklister, il est important de suivre les meilleures pratiques de référencement et de créer un contenu de qualité pour votre site web.
d’un coté révéler ses méthodes ne serait pas productif pour google ^^
Ca fait rever les majors…
On a aucun vrai contact aucune vraie info
Faut faire quoi se mettre a plusieurs st demander y ne action justice ?
Car bloquer un site perso ss motif ca devient lourd
De mon côté, depuis le déblocage, l’alerte revient de temps en temps au hasard de la navigation dans les menus Jeedom. Bien entendu, j’ai entièrement nettoyé le cache de mon navigateur, y compris avec CCleaner, mais ou hasard d’un click, l’avertissement revient. Je supprime la dernière heure de l’historique de navigation et c’est à nouveau ok.
Pourtant depuis l’alerte :
- J’ai changé de machine physique
- Suis passé d’une Debian 10 sur Nuc dédié à une Debian 11 en VM sur Proxmox
- Changé tous mes mots de passe
- Activé l’authentification 2FA
- Supprimé le compte admin
- Changé de mot de passe root sur Debian
Je croyais que ChatGPT ne faisait pas de fautes d’orthographe ? Alors écrire à l’infinitif un participe passé pris comme attribut… 
Je crois quon peut jouer longtemps a tt refaire tant que gogole ne dit pas sur quoi il se base pour bloquer on pisse face au vent
Et on est daccord c inadmissible de ne pas avoir de reponse de leur part
Pire je suis meme pas sur quils l’aient. Cest leur algo et pour que quelquun chez eux se penche dessus pr savoir si c normal ou pas cest comme espere voir Holla.de faire du scooter sur la lune
Moi perso j’ai plus eu de problème depuis la dernière fois, ca a duré 2 jours et plus rien. On verra si ça revient. J’ai rien fait à part leur envoyer que c’était une URL perso pour de la domotique.
Quand à utiliser les DNS de Jeedom, aux dernières nouvelles ça ne fonctionne pas avec du Docker, faut bien qu’on se démerde autrement 
Dns ça fonctionne sur docker…
Pareil de mon côté, j’ai eu l’alerte une première fois. Puis j’ai demandé un examen à google, qui m’a remis mon site comme « fiable ».
3 jours plus tard, rebelote. Je refais la même démarche. Cette fois ça a tenu 1 semaine.
Et ce soir, je reçois encore le mail de google qui me dit :« Contenu d’ingénierie social détecté sur MON_NOM_DE_DOMAINE » …
Je vais encore et encore faire des demande de whitelist, mais c’est dommage de ne pas pouvoir comprendre ce qu’il se passe.
1 « J'aime »
Bonjour,
Je suis sur le même type de configuration ausi, DIY sur un RPI, avec un certificat lets encrypt. Mais, je suis derrière un reverse proxy (j’ai installé Nginx Proxy Manager avec Docker et c’est donc lui le point d’entrée de mon réseau) ça fait peut être une différence. En tout cas je n’ai jamais eu de problème.
C’est juste lié au navigateur Google Chrome, vous avez testé Edge / Safari / Opera / autre ?
Ou bien lié aux DNS de Google et dans ce cas, possible de les changer aussi ?
Pouvez aussi tester la valeur de votre certificat, avec ce site très pointu qui donne des tas d’information que je ne comprends pas forcément tout. Mais ça cassera l’argument qui disait « on a tous un certificat lets encrypt donc c’est le même » clairement, non, un certificat lets encrypt est généré de manière unique sur chaque machine c’est très compliqué et toujours unique.
Moi mon certificat est tout vert (A) mais j’ai quand même quelques zones d’ombre, le TSL 1.3 n’est pas supporté, quelques erreurs « handshake simulation »…
sympa ton site , très instructif
Je ne suis pas sûr d’être d’accord avec cette affirmation. Bien entendu, le certificat est généré de manière unique, puisque il comporte entre autres choses la clé publique, l’URL, la date d’expiration du certificat, et les coordonnées publiques du site, qui sont des données propres à chacun. Mais il comporte aussi des données communes, le nom de l’autorité de certification et sa signature qui sont je pense communes à tous les certificats Let’s Encrypt. Je suppose que tout le reste est également commun, parce que Let’s Encrypt génère toujours son certificat de la même façon, et les quelques faiblesses - qui n’en sont pas vraiment - relevées par le site cité sont vraisemblablement communes.
D’autant que Let’s Encrypt fournit uniquement des certificats DV (domain validated), et ni des OV (organisation) ni encore moins des EV dont la sécurité est plus poussée. Tout ceci gratuité et automatisation obligent.
Quant à savoir si un certificat peut être différent selon le serveur qui l’héberge, Apache, Tomcat, 2IS ou autre, je ne me suis jamais posé la question jusqu’à aujourd’hui, mais je suis preneur de l’info si quelqu’un le sait.
Par contre sur ce point, je me pose aussi la question, car derrière un reverse proxy, ça n’est pas la page d’accueil (login) de Jeedom qui est exposée. Il faudrait relire en détail l’historique de ce post, mais il me semble que personne n’a indiqué avoir eu le problème derrière un reverse proxy. Prévenez moi si je me trompe. De même, les nombreux utilisateurs du reverse Proxy et DNS de Jeedom ne sont pas touchés.
Je rappelle que la maigre info que j’avais eue de Google, c’est : « Page trompeuse ». A moins que Google ne soit capable de remonter au delà de la page d’accueil (authentification) de Jeedom - tout est possible, c’est elle qui fait la différence entre un accès direct et un accès par reverse Proxy. C’est elle qui est exposée, alors que dans le cas d’un reverse proxy, c’est juste le serveur où il est hébergé qui est exposé.
Du coup, on en revient à Jeedom, je sais que ça ne plaît pas à Loïc mais au moins, ça serait une explication possible.
Merci de vos commentaires.
Bonsoir à tous,
Installation DIY sur Raspi et certificat Let’s encrypt, pas de reverse proxy, pas de DNS Jeedom et pas d’erreur Google (pas plus sous edge ou firefox).
Donc ce n’est a priori pas Jeedom non plus (peut être un plugin) mais si cela devait être le core j’aurais également l’erreur.
Bonne recherche
Ca n’est pas tout le monde non plus heureusement. On en entendrait parler à flot continu.
C’est obligatoirement un cumul de plusieurs critères
1 « J'aime »
Pour ma part c’est arrivé pile poil après le renouvellement de mon certificat lets encrypt. Il s’agit d’un jeedom DIY sans reverse proxy. Ce qui me paraît étrange c’est que de le site apparaît encore en trompeur sur mon téléphone Android alors que sur différents pc via chrome plus d’alerte.
Alors la encore, pas forcément, parce que c’est lié aussi aux packages installés, et leurs versions, un certificat généré il y a 6 mois ou 1 an avec une lib pas forcément à jour aura des faiblesses qui sont maintenant corrigées avec la dernière maj. D’ailleurs ça me fait dire que c’est sûrement une bonne idée de mettre à jour les libssl avant la génération / renouvellement du certificat.
Je n’ai pas activé d’option SSO (Single sign-on, identification unique) donc mon reverse-proxy ne fait que de la redirection, et l’URL expose directement la page d’authentification de Jeedom.
Il y a probablement des headers rajoutés, qui permettent à Google de deviner que Jeedom est derrière un reverse-proxy. Et encore, pas sûr, je pense qu’on peut paramétrer pour être totalement invisible, en général pour la sécurité, moins on en montre, mieux c’est.
Après, pour continuer d’alimenter le débat… 
google peut blacklister sur des critères aussi simples que le seul nom de domaine, si d’un coup il décide que ça ressemble un peu trop à un nom de marque protégé: tu achète un domaine smiley.fr et du jour au lendemain la société smile fait une réclamation à google ou juste l’algorithme devient un peu plus exhaustif et hop, blacklistage.
Bonjour,
Ceux qui ont le problème, est-ce que vous avez un fichier robots.txt à la racine, accessible de l’extérieur (https://votrejeedom.votredomaine.tld/robots.txt) ?