Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
abigailphoebe
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
3 ms
·
1.
▲
8% of images on Discord are scams: Blocking Mr. Beast scams
(abigail.sh)
6 points
by
abigailphoebe
4mo ago
|
1 comments
2.
▲
by
abigailphoebe
4mo ago
Hi all, I recently went viral on Twitter due to my solution for detecting and removing a very common scam on Discord, in the process of deployment I found that a little over 8% of all images sent on Discord are scams (8.3%). I wrote a blog
3.
▲
I made a research test suite for analysis of software metrics overtime
(abigail.sh)
3 points
by
abigailphoebe
7mo ago
|
1 comments
4.
▲
by
abigailphoebe
7mo ago
i made a nice little write-up in addition to my paper on analyzing historical software metrics - would appreciate some feedback as this is my first 'technical' writeup. the 4 page paper is attached at the bottom of the article alo
5.
▲
by
abigailphoebe
1y ago
i personally host my own git instance for all my important projects, i'm just forced to use github for work.
6.
▲
GitHub suspended my account for forking a work repo
(bsky.app)
8 points
by
abigailphoebe
1y ago
|
4 comments
7.
▲
by
abigailphoebe
1y ago
i'm at an ai summit for my work, we're doing a hackerthon on abusing ai agents we develop. i attempted to fork the dummy repository and was met with "You are unable to fork this repository at this time"; after this my co
8.
▲
by
abigailphoebe
1y ago
ehh, not really. assuming a reasonable ratelimit, say 100 lookups per day (maybe some exceptions if the lookup results in an account that already has you in contacts, idk) - this would significantly reduce the amount of scraping that can be
9.
▲
by
abigailphoebe
1y ago
eh, i'm not convinced. this was in the middle of a scheduled maintenance, with all requests failing at a singular point - that being a .unwrap(). there should be internal visibility into the fact a large number of requests are failing
10.
▲
by
abigailphoebe
1y ago
that's actually a very good point, fair enough, i agree. regretfully i'm not sure if such a big language change can be made; though it would be nice. here's to hoping!
11.
▲
by
abigailphoebe
1y ago
just read the pre-print paper. they claim to have achieved a rate of 7,000/s, which is roughly 25M/h i do agree that is an absurd amount, especially when paired with the lack of rate limiting as discussed in their paper. > &quo
12.
▲
by
abigailphoebe
1y ago
this is just... enumeration of phone numbers? how is this a 'security vulnerability'? an issue maybe, but it's not a vulnerability as that implies faulty code; this is a documented feature.
13.
▲
by
abigailphoebe
1y ago
you either misunderstand the rust ethos or are intentionally misrepresenting it. safe refers to memory safety. once again, if you write bad code, that’s your fault, not the languages. this is a feature of rust that was used incorrectly.
14.
▲
by
abigailphoebe
1y ago
blaming the language is not the way to approach this. if an engineer writes bad code that’s the engineers fault, not the languages. this was bad code that should have never hit production, it is not a rust language issue.
15.
▲
by
abigailphoebe
1y ago
kudos to getting this blog post out so fast, it’s well written and is appreciated. i’m a little confused on how this was initially confused for an attack though? is there no internal visibility into where 5xx’s are being thrown? i’m surpri