Je voudrais refuser archive.is
d'avoir accès à mon site Web. (Je ne veux pas que ce site Web cache le mien sans mon consentement).
Savez-vous si c'est possible?
Je voudrais refuser archive.is
d'avoir accès à mon site Web. (Je ne veux pas que ce site Web cache le mien sans mon consentement).
Savez-vous si c'est possible?
Réponses:
D'accord. C'est un nouveau (pour moi au moins) et assez intéressant jusqu'à présent. Je ne vais pas entrer dans les mauvaises herbes à ce sujet.
Quand j'ai écrit cela, je travaillais sur peu ou pas de sommeil. J'ai raté quelques choses que @unor a aimablement souligné et je dois donc tempérer ma réponse et donner du crédit là où le crédit est dû. Merci @unor!
Archive.is est enregistré auprès de Denis Petrov qui utilise un compte d'hébergeur Google sur l'adresse IP 104.196.7.222 [AS15169 GOOGLE - Google Inc.] selon Domain Tools bien que je l'ai sur 46.17.100.191 [AS57043 HOSTKEY-AS HOSTKEY BV]. Il est probable que la société d'accueil a récemment changé.
Archive.today appartient également à Denis Petrov et est similaire à Archive.is sinon identique. Aux fins de cette réponse, je vais m'adresser à Archive.is et vous pouvez supposer qu'elle s'applique à Archive.today. Archive.today existe sur une autre adresse IP 78.108.190.21 [AS62160 GM-AS Oui Networks Unlimited Ltd]. Veuillez comprendre que Denis Petrov possède 70 domaines. Sans creuser plus profondément, il est possible que d'autres sites soient préoccupants. Je fournirai un code de blocage pour les trois adresses IP.
Archive.is est dirigé par l'utilisateur. Il est supposé que vous archivez votre propre page. Autre que ce scénario, Archive.is peut être considéré comme un site de spam de scraper de contenu.
Archive.is marche sur une ligne dangereuse. Il utilise le contenu d'autres sites via le grattage d'une seule page. En fin de compte, le potentiel de recherche du contenu d'origine est au moins dilué et potentiellement complètement usurpé. Pire encore, le site d'origine n'est pas cité comme l'auteur du contenu. Archive.is utilise une balise canonique, mais c'est vers son propre site / page.
Exemple: <link rel="canonical" href="http://archive.is/Eo267"/>
Ceci couplé avec le manque de contrôle sur qui soumet un site et s'ils ont le droit sur le site, le manque d'informations claires sur le retrait et le mécanisme de contact quelque peu flou et potentiellement faible, Archive.is a le potentiel pour de vrais difficulté.
Vous pouvez trouver plus d'informations sur l'adresse IP ici: https://www.robtex.com/#!dns=archive.is
Utilisation de Cisco Firewall.
access-list block-78-108-190-21-32 deny ip 78.108.190.21 0.0.0.0 any
permit ip any any
** Remarque: vous pouvez remplacer le [nom acl fourni] par le nom ACL de votre choix.
Utilisation de Nginx.
Modifiez nginx.conf et insérez include blockips.conf; s'il n'existe pas. Modifiez blockips.conf et ajoutez ce qui suit:
deny 78.108.190.21/32;
Utilisation du pare-feu IPTables Linux. ** Remarque: à utiliser avec prudence.
/sbin/iptables -A INPUT -s 78.108.190.21/32 -j DROP
Utilisation de Microsoft IIS Web Server
<rule name="abort ip address block 78.108.190.21/32" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{REMOTE_ADDR}" pattern="^78\.108\.190\.21$" />
</conditions>
<action type="AbortRequest" />
</rule>
Utilisation d'Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^78\.108\.190\.21$ [NC]
RewriteRule .* - [F,L]
Utilisation de Cisco Firewall.
access-list block-46-17-100-191-32 deny ip 46.17.100.191 0.0.0.0 any
permit ip any any
** Remarque: vous pouvez remplacer le [nom acl fourni] par le nom ACL de votre choix.
Utilisation de Nginx.
Modifiez nginx.conf et insérez include blockips.conf; s'il n'existe pas. Modifiez blockips.conf et ajoutez ce qui suit:
deny 46.17.100.191/32;
Utilisation du pare-feu IPTables Linux. ** Remarque: à utiliser avec prudence.
/sbin/iptables -A INPUT -s 46.17.100.191/32 -j DROP
Utilisation de Microsoft IIS Web Server
<rule name="abort ip address block 46.17.100.191/32" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{REMOTE_ADDR}" pattern="^46\.17\.100\.191$" />
</conditions>
<action type="AbortRequest" />
</rule>
Utilisation d'Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^46\.17\.100\.191$ [NC]
RewriteRule .* - [F,L]
Utilisation de Cisco Firewall.
access-list block-104-196-7-222-32 deny ip 104.196.7.222 0.0.0.0 any
permit ip any any
** Remarque: vous pouvez remplacer le [nom acl fourni] par le nom ACL de votre choix.
Utilisation de Nginx.
Modifiez nginx.conf et insérez include blockips.conf; s'il n'existe pas. Modifiez blockips.conf et ajoutez ce qui suit:
deny 104.196.7.222/32;
Utilisation du pare-feu IPTables Linux. ** Remarque: à utiliser avec prudence.
/sbin/iptables -A INPUT -s 104.196.7.222/32 -j DROP
Utilisation de Microsoft IIS Web Server
<rule name="abort ip address block 104.196.7.222/32" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{REMOTE_ADDR}" pattern="^104\.196\.7\.222$" />
</conditions>
<action type="AbortRequest" />
</rule>
Utilisation d'Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^104\.196\.7\.222$ [NC]
RewriteRule .* - [F,L]
Vous devrez peut-être bloquer plusieurs adresses IP à partir de n'importe quel ensemble de codes. Ce n'est pas clair.
archive.org loses copyright lawsuit
ne semble pas avoir publié d'articles pertinents sur les décisions.
robots.txt
Archive.is n'utilise pas un bot qui explore les pages de manière autonome (par exemple, en suivant des hyperliens), donc robots.txt
ne s'applique pas, car c'est toujours un utilisateur qui donne la commande pour archiver une certaine page.
Pour la même raison, des services comme Feedfetcher de Google ( pourquoi Feedfetcher n'obéit pas à mon fichier robots.txt? ) Et le Validator du W3C ( détails ) n'obéissent pas robots.txt
.
Voir la FAQ archive.is: Pourquoi archive.is n'obéit pas à robots.txt?
meta
- robots
/X-Robots-Tag
Je ne sais pas si archive.is devrait (idéalement) respecter la valeur noindex
ou noarchive
dans meta
- robots
/ X-Robots-Tag
, ou si ces technologies s'appliquent également aux robots autonomes uniquement. Mais comme archive.is ne le documente pas, ils ne semblent pas le supporter actuellement.
(FWIW, chaque page archivée semble en avoir un <meta name="robots" content="index,noarchive"/>
.)
User-Agent
archive.is ne documente pas qu'un certain User-Agent
est utilisé (ils ne s'identifient probablement pas, pour obtenir les pages comme si elles étaient consultées par un navigateur habituel), vous ne pouvez donc pas l'utiliser pour bloquer leur accès au niveau du serveur .
Donc, ni robots.txt
ni meta
- robots
/ ne X-Robots-Tag
fonctionnent ici, et vous ne pouvez pas les bloquer via leur User-Agent
, vous devez bloquer les accès à partir des adresses IP archive.is. Voir la réponse de closetnoc sur le blocage IP , mais notez que cela pourrait bloquer plus que prévu, et vous pourriez ne jamais attraper toutes leurs adresses IP (et / ou rester à jour).
Chaque version archivée est liée à un formulaire dans lequel vous pouvez signaler d'éventuels abus (ajouter /abuse
), par exemple, avec les raisons "Problème SEO" ou "Copyright". Mais je ne sais pas si ni comment ils traitent ces cas.
Pour bloquer les pratiques de vol dégoûtantes de archive.is (ignorer robots.txt, remplacer le lien canonique, faux agent utilisateur, aucun moyen d'effectuer une suppression à l'échelle du site), je veux ajouter ce qui suit aux solutions ci-dessus.
Pour trouver leurs adresses IP, soumettez-leur une URL qui est sous votre contrôle afin que vous puissiez surveiller les journaux de votre serveur Web pour voir qui y a accédé cette URL. L'URL n'a même pas besoin d'exister tant que le serveur Web reçoit la demande. (Il est donc préférable d'utiliser une page / URL vide non existante.) Par exemple, utilisez une URL comme: http://example.com/fuck-you-archive.is
Vérifiez ensuite vos journaux pour voir qui a accédé à l'URL. Vous pouvez utiliser grep pour le vérifier:
grep "fuck-you-archive.is" web-server-log.txt
Une fois que vous avez l'adresse IP, vous pouvez la bloquer en utilisant les solutions des autres réponses. Et puis répétez le processus à nouveau pour trouver d'autres adresses IP qu'ils utilisent. Vous devez spécifier une URL différente, pour leur faire effectuer une nouvelle requête HTTP, par exemple, changez simplement http://example.com/fuck-you-archive.is en http://example.com/fuck-you- archive.is?2 etc.
Dans le cas où vous ne souhaitez pas exposer votre site Web du tout lorsque vous essayez de trouver leurs adresses IP, vous pouvez utiliser ce site Web de demande HTTP pratique: https://requestb.in Les étapes à effectuer sont les suivantes: créer un RequestBin> soumettre le "BinURL" à Archive.is avec "? SomeRandomNumber" ajouté au BinURL> utiliser le "? inspect" de RequestBin pour surveiller la demande entrante d'Archive.is et voir leur adresse IP dans le "Cf-Connecting-Ip" "En-tête HTTP. (Assurez-vous que vous ne soumettez pas l'URL "? Inspect" à Archive.is.) Ensuite, répétez pour trouver d'autres adresses IP en remplaçant "? SomeRandomNumber" par un autre numéro.
Notez qu'avec les tables IP, vous pouvez bloquer en utilisant
/sbin/iptables -A INPUT -s 78.108.190.21 -j DROP
mais souvent la chaîne «INPUT» est définie sur une stratégie «DROP» avec acceptation du trafic HTTP. Dans ce cas, vous devrez peut-être utiliser une opération de pré-ajout (insertion) au lieu d'une opération d'ajout, sinon elle n'est pas bloquée du tout:
/sbin/iptables -I INPUT -s 78.108.190.21 -j DROP
Cependant, ils ont beaucoup d'adresses IP, il peut donc être plus facile de bloquer des plages IP complètes. Vous pouvez le faire facilement avec IPTables (sans avoir besoin de spécifier des sous-masques) en utilisant:
iptables -I INPUT -m iprange --src-range 46.166.139.110-46.166.139.180 -j DROP
Cette plage (46.166.139.110-46.166.139.180) leur appartient en grande partie, car j'ai vu plusieurs adresses entre 46.166.139.110 et 46.166.139.173.
Ils utilisent actuellement NFOrce comme hébergeur. Voir https://www.nforce.com/abuse pour savoir comment déposer une plainte concernant Archive.is. Mentionnez: 1) l'url de votre page Web que archive.is a volé, 2) mentionnez l'url sur archive.is qui contient le contenu volé et 3) mentionnez les adresses IP qu'ils ont utilisées.
Vous pouvez également vous plaindre auprès de Cloudflare, leur CDN, qui met en cache leurs pages et images volées pour des raisons de performances. https://www.cloudflare.com/abuse/
Comme nous pouvons le voir, archive.is utilise DNS anycasting.
Si vous utilisez différents serveurs de noms (par exemple sur https://www.lifewire.com/free-and-public-dns-servers-2626062 ), vous obtenez actuellement (2018-09-10) différentes adresses IP pour "archive.is" ( creuser @NAMESERVER archive.is A)
104.27.170.40
104.27.171.40
154.59.112.68
185.219.42.148
46.105.75.102
46.17.42.43
46.182.19.43
46.45.185.30
80.211.3.180
81.7.17.119
91.121.82.32
91.219.236.183
94.16.117.236
J'ai utilisé abuse-contacts.abusix.org ( https://www.abusix.com/contactdb ) pour obtenir les contacts d'abus pour ces adresses IP:
abuse@as42926.net
abuse@cloudflare.com
abuse@cogentco.com
abuse@isppro.de
abuse@nbiserv.de
abuse@netcup.de
abuse@ovh.net
abuse@serverastra.com
abuse@staff.aruba.it
abuseto@adminvps.ru
noc@baxet.ru
Comme Cloudflare l'a signalé, archive.is abuse de ses "services" en utilisant un enregistrement DNS A qui n'a aucune fonctionnalité!
Pensez également à contacter les registraires sur www.isnic.is, le registre de domaine islandais. isnic au point isnic est
L'Islande a une loi sur le droit d'auteur et le registre la reconnaît. Le registre existe depuis la fin des années 80 et n'est pas sous l'ICANN.