indec

My opinion is that "female-friendly fields" is (or should be) "software engineering". Thus "lets see them set up a special fund or something for female-friendly fields" reduces to the current state of the program.

Well, generally following the redirects is actually somewhat redundant. The idea of GSB is that URLs that lead to bad things would all be identified and added to the database.

Customising attacks for a given site specifically adds complexity and cost to the attack, which is really the aim for all of this sort of work. Everything you can do to drive up the cost of the attack makes you a less inviting target.

It would be a mistake to think that usb4ugc (or tools like it) would protect everyone all the time. It's never a replacement for vigilance and education on the user-side, just a useful extra line of defense.

We follow them on the server side and check the final URL we get to against the GSB database. We don't modify the user-generated content.

We "unroll" redirects as much as possible so that we can check the URL at the end.

The privacy risk for GSB in general is that you are sharing URLs with a (trusted) third party. That's most acute with the REST API, but most implementations (including gsb4ugc) cache a local copy of the lookup tables and so don't actually send URLs to Google. There is still a very occasional need to send a link to Google for validation, but in the server-side case the only context Google has for the request is the IP address of the server, which minimizes privacy risks as much as possible.

Is there a good way to deal with the case of sigma = 0 (i.e. all posts have the same number of votes)?

Was there particular value in the YC Y U NO coverage? Seems like coverage for coverage's sake. Networking value, perhaps?