An error occurred during a connection to archive.is. Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP
SSLLabs probably has the same problem: https://www.ssllabs.com/ssltest/analyze.html?d=archive.is
"We delete [the] temporary logs [which include your full IP address to identify things like DDoS attacks and debug problems] within 24 to 48 hours."
"In the permanent logs, we don't keep personally identifiable information or IP information. After keeping [the data we do keep] for two weeks, we randomly sample a small subset for permanent storage."
And importantly:
"We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services."
Source: https://developers.google.com/speed/public-dns/privacy
Unless you think they're lying or unable to enforce this policy, this addresses most of the common privacy concerns I've heard in this context.
(I have worked for Google in the past, but I have never been involved at all with Google Public DNS or its privacy promises.)
Adhering to these promises is a separate question from changes of policy in the future, of course, and just as separate from failures in the areas of product design or ethics. Many parts of the conglomerate that calls itself Google have gotten worse in all of those areas over the last several years, though I am still a big fan of how GCP is progressing.
But none of this makes me think that they're retaining more Google Public DNS data than they claim. Given how little of that data they retain for the long haul, the risk of bad retroactive impact from a change in policy in this area is quite low. The risk is admittedly higher for other consumer services which do retain identifiable data over a long period of time.
Conversely, the risk is lower for G Suite and GCP offerings and for European residents, given the concerns and compliance obligations of business customers and the obligations imposed by the GDPR.
Obviously, no user would be able to justify buying subscriptions to every publication linked from HN.
And if there was no paywall bypass, then HN couldn't link to it and it would get no HN traffic and no discussion on HN at all.
Allowing paywall bypass means the publication gets the HN traffic and discussion it wouldn't otherwise get, and the possibility of converting some of that traffic to subscribers who wouldn't otherwise subscribe.
For what it's worth, the owners/operators clearly don't think it puts this forum at risk, as the sharing of paywall bypass links is explicitly allowed/encouraged according to the guidelines and moderator comments.
And the very fact that the publications themselves allow bypass via certain referrers (e.g., Facebook) suggests they don't have a problem with it.
The other way of looking at it is that it can boost publication revenue... by driving more traffic
The same argument has been made in defense of software piracy for over a generation.But we’re not talking about piracy here. If the publishers thought of it that way they’d block all access to archive sites.
Anyway, rather than a snarky dismissal like this, do you have a constructive suggestion for a solution that works well for everyone?
If the answer is “no paywalled sites on HN ever” please say so.
But if you have a more nuanced suggestion that would be a huge help!