Comment by ps2026

Comment by ps2026 5 hours ago

4 replies

The Plausible does count raw statistics without "tracking" specific users. That is just used for general website analytics. The first-party functional cookie that I am using (very similar to the auth login cookie) is used to prevent duplicate anonymous votes. Neither of these track the user and both are for on-site only. The functional cookie works much better than the fingerprint (actually less invasive too), but isn't full proof. You can switch browsers, go to incognito mode in some browsers, etc.. to bypass it, but it works for most casual users. Since it isn't election level polling, I figured it is fine. I do have an in memory rate limit to prevent excessive voting spam.

1e1a 5 hours ago

Are you rate limiting at the subnet/prefix level for IPv6?

  • ps2026 4 hours ago

    Actually no, I'm rate limiting per individual IP address right now. Good catch... I should probably normalize IPv6 to /64. I was originally thinking about not blocking universities or large groups that share IPs, but I guess that is more of an IPv4 NAT concern. Thanks for pointing it out! I didn't really think about a user rotating through IPs. I didn't add the rate limiting on voting until I removed the fingerprint, so that is for sure a valid concern.

    • 1e1a 4 hours ago

      It could make sense to lightly rate limit at /48 in addition to /64 (this is generally the largest subnet size given out by ISPs), otherwise it will be easy for people to multiply your /64 rate limit by 65536.

      • ps2026 4 hours ago

        Hey thanks for the recommendation. That makes sense. Layered rate limiting at both /64 and /48 with different thresholds. Appreciate the explanation, and I'll be adding this to the list! This is my first time dealing with a public facing app where this type of rate limiting is needed.