Live data from Hacker News

Things I learned after getting users

basementcommunity.bearblog.dev

21–30 of 155 posts

Re: Things I learned after getting users

#21
post #4

> when the site first got a surge of users from hacker news, there was one poster in particular who came to the site, registered a bunch of offensive, racist usernames and proceeded to post and create threads that were just full of dumb slurs. this was definitely a learning experience because i had to act quickly, so i tried a bunch of different methods to get rid of him. it's sad that people like this exist in the w…

Mental illness

Re: Things I learned after getting users

#22
post #2

Man, on the abuse front—it’s amazing the lengths that people will go through to put spam on the web. There are apparently canned solutions for pushing stuff to any Mediawiki site, although I found that a really stupid captcha¹ was enough to bring that down almost to zero, but early on with rejectionwiki, I had the same sort of chronic abuser things happening that are described in the article. ⸻ 1. Basically a set of…

> Who wrote Hamlet?

Sir Francis Bacon :smirk:

Re: Things I learned after getting users

#23
post #4

> when the site first got a surge of users from hacker news, there was one poster in particular who came to the site, registered a bunch of offensive, racist usernames and proceeded to post and create threads that were just full of dumb slurs. this was definitely a learning experience because i had to act quickly, so i tried a bunch of different methods to get rid of him. it's sad that people like this exist in the w…

Richard Bartle, has this way of dividing up the way what he calls "players" but it works for any social media[1]. One of them is the "killer" with a sub-type of "griefer" which are those whose "... vague aim is to get a big, bad reputation". So, from that perspective, they actually do get something out of it.

[1]https://en.wikipedia.org/wiki/Bartle_taxonomy_of_player_type...

Re: Things I learned after getting users

#24

Are you paying for Sentry? What type of monitoring does it provide? I'm working on a project I'd like to add some monitoring so I'm on the lookout for a good solution. Looking for something free though until there's a need to have better insight than I can get without paying for it

My team got really far using something called GlitchTip. It's compatible with the Sentry SDKs, but really cheap, so it felt like there were minimal consequences to switch if we ever had the need to. We only switched to Sentry cause our company was acquired and they already had a Sentry subscription going.

Hadn't heard of GlitchTip, but will look into it. Thanks!

Re: Things I learned after getting users

#25
post #2

Man, on the abuse front—it’s amazing the lengths that people will go through to put spam on the web. There are apparently canned solutions for pushing stuff to any Mediawiki site, although I found that a really stupid captcha¹ was enough to bring that down almost to zero, but early on with rejectionwiki, I had the same sort of chronic abuser things happening that are described in the article. ⸻ 1. Basically a set of…

> that any writer (for whom the site is targeted) should be able to answer

hey now, not all writers who discuss things in English are necessarily familiar with the anglo literary tradition

(it's probably a higher overlap than average, and shouldn't be too hard for them to search, but be careful throwing the assumption around)

Re: Things I learned after getting users

#26
post #4

> when the site first got a surge of users from hacker news, there was one poster in particular who came to the site, registered a bunch of offensive, racist usernames and proceeded to post and create threads that were just full of dumb slurs. this was definitely a learning experience because i had to act quickly, so i tried a bunch of different methods to get rid of him. it's sad that people like this exist in the w…

Alcohol.

Re: Things I learned after getting users

#27
post #4

> when the site first got a surge of users from hacker news, there was one poster in particular who came to the site, registered a bunch of offensive, racist usernames and proceeded to post and create threads that were just full of dumb slurs. this was definitely a learning experience because i had to act quickly, so i tried a bunch of different methods to get rid of him. it's sad that people like this exist in the w…

The thing that really surprised me was that even when he implemented IP blocking, the user used a VPN to continue abusing the site. That's a step beyond "casual" trolling that someone might do to test a site's security (not that this is justifiable behavior) and enters the territory of targeted harassment.

Re: Things I learned after getting users

#28

> some users have suggested pretty smart features that i've since implemented, like this back-to-top button to quickly get back to the top of the page To me all position:fixed elements (headers, footers, this back-to-top button, etc) feel like a kind of annoying dirt on the screen. Their absence is a big part of why I love the web 1.0 aesthetic.

My god yes. There is literally a key on a full keyboard dedicated to this function (Home), smaller keyboards have a chord for it (like Fn-Up), and "mobile" touchscreen UI has a global mechanism for this (on iOS: touching the status bar)... to plop down a position:fixed button on top of the content to make it even easier to access this feature that is already extremely easy to access is just gratuitous.

Re: Things I learned after getting users

#29
Yes, there are numerous automated and human-powered nuisance traffic streams.

1. CMS sites are constant maintenance, as most are an endless supply of issues. However, some have content caching to reduce the SQL workload.

2. Delayed registration with CAPTCHA and a brief explanation of why you are there. Quiet banning IP filter applied to list to boot pending users who enter emails that bonce or fail to authenticate.

3. Firewall blacklist areas of the world where you don't do business (better yet, whitelist the ISPs in the regions you do business), blacklist proxy/tor/spam IP ranges, add port tripwires, and setup rate limited traffic per IP (see slow loris mitigation methods if you are not using nginx).

4. add peer site content blocker for forum spammers/bots i.e. share exploit probes preemptively with the rest of the net.

5. add email filter for mention of bitcoin/BTC, and black-hole the entire IP block if in an irrelevant region.

6. lookup same-origin enforcement for your web-server, add Subresource Integrity Hash to your core, and re-scale/watermark/scrub all media to protect users from themselves.

7. fail2ban rules for common site security scanners, known exploit attempts, and common email scams.

You owe nonpaying users nothing, so the collateral cost of blanket bans is $0 in hostile regions. Remote traffic monitoring is also recommended if you have a game engine running.

On day 2 we can look at how BTC tumblers/launderers fund most of these issues, and whether it is OK to also preemptively blanket-ban most cloud/hosting providers (costs under 7% of your users in most cases). Remember, adversaries will often pretend to be from wherever they wish to inflict harm, and time does not have an associated cost in the 3rd world.

Have a gloriously wonderful day =)

Re: Things I learned after getting users

#30
"this is mostly because i relied on a SQL ORM which in short is a tool that makes writing SQL easier to pick up and faster to develop. the biggest downside is that it might execute 50 queries to your database to get a list of information, when it probably only needs 1, which will cause slowdown."

I appreciate this honesty. Listen to this old man's advise: learn SQL properly. It's not that hard. Focus on it for a few weeks intensely and you've mastered it for life. Then just write SQL directly.

I've had weekends ruined troubleshooting my "highly productive ORM layer" that nuked a production database. Whilst functionally speaking my ORM code was in no way incorrect. I'm talking differences of a thousand fold in query load depending on how one expresses the ORM calls.

You can then become proficient in trying to reason and predict about what your ORM calls do in the actual database, but when you're several joins deep, this becomes near impossible. At which point you become the ORM, and might as well just write SQL.

Post reply on HN