Pirate Library Mirror: Preserving 7TB of books (that are not in Libgen)

If the user requests the page from Internet Archive, Common Crawl or even Google Cache, how does the ISP know what the user requested. (NB. Neither IA nor Google Cache require sending SNI,^1 so the ISP may only see IP addresses).

With IA, the IP address alone does not reveal which IA site or page the user is requesting. There is more to IA than only Wayback Machine.

With Common Crawl, the user can send the Cloudfront domain name instead of a commoncrawl.org domain. Are all ISPs going to know that this is Common Crawl. Even if they expend the effort to learn, what benefit is achieved.

With Google Cache, the IP address alone does not reveal which Google site the user is accessing. Needless to say, there are many, many domains using these IP addresses.

There is nothing that requires any web user to retrieve web pages from a given host. The page may be mirrored at a number of hosts. Some of those hosts might offer HTTPS, support TLS1.3 and not require plaintext SNI/offer encrypted ClientHello.

Even assuming an ISP can determine what domain name a customer is sending in a Host header or ClientHello packet, it would still be necessary to subpoena the archive/CDN/cache to figure out precisely what pages were being requested.

1. The same party is controlling all the server certificates. IA controls the certificates for all IA domains, Amazon (issues and) controls all the certificates for Cloudfront customers and Google controls all the certificates for Google domains. Perhaps there are web users commenting on HN who believe that ingress/egress traffic for site saved/hosted/cached at an archive/CDN/cache is somehow private as against the company running the archive/CDN/cache in a meaningful way. I am not one of them.

As for the question of an ISP modifying the contents of web pages, this is an issue that could be addressed contractually in a subscriber agreement. It stands to reason that if this was a serious issue and not merely a hypothetical one raised by nerds debating the merits of TLS then it would be addressed in such agreements.

As for the "injection of advertising" issue as a argument in favour of the way TLS^2 is being administered on the web, IMO this is a bit silly since (a) it is trivial to filter such advertising (e.g., Javascript in the examples I saw) out out of the page and/or block it from running/connecting/loading and (b) the amount of "tech" company-mediated advertising that web users endure in spite of using TLS is enormous. More likely than being seen as a threat to web users, the injection of advertising by ISPs was seen as a threat to the advertising revenue of "tech" companies. The later are responsible for facilitating the injection of advertising (by their customers, not their competitors, i.e., ISPs), not preventing it.

2. By "TLS administration" I do not mean encryption as a concept nor certificates as a concept. I mean TLS administration measures designed to support "tech" companies first and web users second, if at all. A system where the questions of "threat model" and "trust" are both decided by "tech" companies not users.

That being said, 10 downloads/day feels a bit restrictive to me. I'd get if it was 100, or 50, heck, maybe even 20. I mean, I don't appreciate that it's not mirrorable in the first place, but maybe they cannot afford it, I don't know... But 10 feels less than somebody researching a new topic might need to access in a day, even if he won't read them all immediately.

…That being said as well, it has some really nice UI. I wish somebody did it for Libgen.