HN user

tjhorner

29 karma

[ my public key: https://keybase.io/tjhorner; my proof: https://keybase.io/tjhorner/sigs/b-dI-M2R4QDpuYOqOnOlqJogwuFTDGEiwpGYrTHWMKw ]

Posts2
Comments13
View on HN

The post raises several points that I wholeheartedly agree with, but the framing is poor and honestly kind of elitist (or just short-sighted). Maybe to the point that I think much of it might just be bait, lol. For example:

Ask a twenty-two-year-old to connect to a remote server via SSH. Ask them to explain what DNS is at a conceptual level. Ask them to tell you the difference between their router’s public IP and the local IP of their laptop. Ask them to open a terminal and list the contents of a directory. These are not advanced topics. Twenty years ago these were things you learned in the first week of any serious engagement with computers.

What? Computers were everywhere in all kinds of domains by 2006, but you can bet that your average accountant of the time would most likely not be able to SSH into a server (nor should they need to...) I guess it really depends on what the author qualifies as a "serious engagement with computers."

It obviously depends on local laws, but it's very commonly illegal to sell prepared food without a license/permit. You might not get caught selling food on FB Marketplace, but that doesn't make it any less allowed.

I agree with the author regarding Apple's walled-garden app distribution, but the analogy just doesn't work here.

I'm interested in how the poison data was generated and why it's "practically endless". It looks like bits of code, structured data, and prose, but with small modifications that make it subtly incorrect. Usually off-by-a-few numbers, e.g. I got the text of GPL-3.0 with a copyright date of 2738.

Anubis doesn't target crawlers which run JS (or those which use a headless browser, etc.) It's meant to block the low-effort crawlers that tend to make up large swaths of spam traffic. One can argue about the efficacy of this approach, but those higher-effort crawlers are out of scope for the project.

I don't think that's the threat model here. The concern is regarding potentially sensitive information being sent to a third-party system without being able to audit which information is actually sent or what is done with it.

So, for example, if your local `.env` is inadvertently sent to Cursor and it's persisted on their end (which you can't verify one way or the other), an attacker targeting Cursor's infrastructure could potentially compromise it.

The forks aren't actually automatically taken down in most cases. The claimant must list every individual fork in the claim. Which I love, because it's kind of petty but still following the DMCA to the letter.

Here is an example[1] of the form claimants must fill out.

Each fork is a distinct repository and must be identified separately if you believe it is infringing and wish to have it taken down

[1] https://github.com/github/dmca/blob/master/2024/05/2024-05-3...

Telegram stores the messages you send/receive unencrypted on their servers.

They don't. From the Telegram FAQ:

"Cloud chats are stored encrypted in the Telegram Cloud, and the keys needed to decipher this data are kept in other data centers in different jurisdictions. This way, local intruders or engineers can't access this data, and several court orders from different jurisdictions are required to force us to give up anything. Thanks to this structure, we can ensure that no single government or block of like-minded countries can intrude on people's privacy and freedom of expression."[1]

1: http://telegra.ph/Telegram-Security-FAQ