3 ms·
https://archive.is/8J1qB https://archive.is/8J1qB Since Internet Archive chucked it in memory hole.
by hnaccy 7y ago
https://archive.is/8J1qB https://archive.is/8J1qB
Since Internet Archive chucked it in memory hole.
- Thorrez 7y agoThe Internet Archive is working for me: https://web.archive.org/web/20200108170304/https://www.teenvogue.com/story/how-facebook-is-helping-ensure-the-integrity-of-the-2020-election https://web.archive.org/web/20200108170304/https://www.teenv...
- deleted 7y ago[deleted]
- mirimir 7y agoPlease see my post in the other thread about how TFA images fared on the Internet Archiv. https://news.ycombinator.com/item?id=21998463 https://news.ycombinator.com/item?id=21998463
- throwaway365924 7y agoIt was not working earlier, returning a 404. I guess we will never know why.
- snek 7y agoArchive.is blocks cloudflare dns from resolving it's site. I'd recommend finding something else.
- throwaway365924 7y agoThat website is IP-blocked in many countries.
- mirimir 7y agoYes, for a while. But I wonder how that happened. Assuming that the timestamps in the archive.org timeline are UTC: 2020-01-08 17:03:04 UTC capture with content 2020-01-08 18:02:12 UTC capture with "Uh-Oh ..." 2020-01-08 18:10:22 UTC capture with "Uh-Oh ..." 2020-01-08 18:10:25 UTC capture with "Uh-Oh ..." 2020-01-08 18:11:28 UTC capture with "Uh-Oh ..." 2020-01-08 ~22:40 UTC 17:03:04 capture present 2020-01-08 ~23:40 UTC 17:03:04 capture missing 2020-01-09 ~02:40 UTC 17:03:04 capture present As I understand it, archive.org will take down captures if robots.txt is changed to exclude them. But that can't be the explanation here, because that robots.txt edit would necessarily have occurred after ~22:40 UTC. And that would arguably have taken down all of the earlier captures. So arguably this must have been a manual intervention. And again, no blame. It's just metadata.