This is a submission for Weekend Challenge: Generosity Edition
Target categories: Best Use of Snowflake + Best Use of Solana.
What it is. An acco...
For further actions, you may consider blocking this person and/or reporting abuse
The 18 out of 108 on disaster attachment is the number that stuck with me. The intro is about people registering LA fire domains, and that's the exact pattern the detector is weakest on - so how much of the real problem does this catch today? Not a gotcha, I'm genuinely asking whether the prefix thing is fixable or whether whole-name embeddings just can't do it.
Honestly, of the thing in the intro? None of it. Someone registering lafirerelieffund.com during a fire never files for 501(c)(3), so they're not in the Business Master File and this never sees them. That's the scope gap and it's the weakest part of the project. What it does catch is a registered entity impersonating another registered entity, which is real but much narrower.
On whether the prefix thing is fixable, I don't think it is with whole-name embeddings. Illinois Coalition For Immigrant And Refugee Rights becomes Illinois Coalition For Fire Recovery: it keeps the part a donor's eye lands on and replaces the part the embedding weights. Cosine over the full string has no concept of a prefix being load-bearing.
And it isn't a threshold problem, which is the bit I found genuinely annoying. When I re-picked the cut-off on the other three techniques and held this one out, recall on it went down, to 12.6%. So tuning honestly makes it worse, not better.
Two things I'd try and haven't built: score the first N tokens as their own comparison and require both to agree, or skip the embedding for this case entirely and run a disaster-keyword predicate against a live registration feed. If you've seen anyone do the first one properly I'd take the link
Here We Go again in another Weekend Dev Challenge we pull of this amazing final product Using Snowflake and on Solana Chain Hope This time will get a Gem in our Blog.
Most annoying build yet, and it's the privacy layer that did it. The thing we shipped last time as a "platform limitation" turned out to be two statements I'd written that were never in the language. Found that out on the last day, which is why The Wall exists again and why it now measures its own defeat instead of just claiming a guarantee.
Favourite bit is still the one that made us look worst: the chain caught our own bridge minting 79 disbursements twice while ORACLE.MINT_QUEUE reported a clean run. Wrote it up instead of quietly fixing it, because a receipt you can't check against something you don't control isn't a receipt.
Next one we're doing the affiliate pre-pass first. PEO Sisterhood alone is 5,995 pairs and it's been mocking me all week.
Wait, you shipped a privacy budget you say yourself doesn't stop the attack it exists for? If 330 trials breaks it and BUDGET_LIMIT => 300 allows 3,000, why not just drop the limit to 30 before publishing and say it holds?
Because 30 makes the sentence true and the tool useless, and I'd rather ship the tension than hide it.
The budget doesn't know who's asking. At 0.1 an aggregate, a limit of 30 is 300 queries total before the window refreshes, and that's for everyone, not per person. The landscape on that tab has 1,328 distinct questions in it. So an analyst doing legitimate work runs out before they've asked a quarter of what's there, and the attacker is spending from the same pot at the same rate. There is no value that stops one and not the other. That's the actual finding, and it's more interesting than a number I could have quietly changed.
The other reason I left it alone: my arithmetic is worst case for the defender. It assumes every repeat draws fresh independent noise. A deployment that returns a cached answer to an identical query raises the attack cost a lot without touching the epsilon accounting, and that's probably the better fix than squeezing the limit. I didn't build caching so I didn't get to claim it.
And honestly, I could have set it to 30 and nobody would have run 660 queries to check. The only reason you get to ask this is that I published the number that makes me look bad.
If you've seen a DP deployment do per-query caching properly I'd like to read how they key the cache, because that's the part I couldn't find a clean answer to.
The comparison between meaning and spelling is a useful way to look at impersonation problems. Measuring both signals in Snowflake could make it easier to identify cases where names look similar but their actual meaning or identity context is different.
Really appreciate this. I’m happy the meaning-vs-spelling approach made sense, and your point about the generosity link arriving too late is spot on. I’ll rework the intro to state the donor benefit and product definition earlier, streamline the opening for judges, and clarify the Snowflake vs Solana roles. This gives me a clear plan for the final edits.
Its actually insane!
Haha
😎
yo
hey @jess @heyitsjem @ben hope you guys will read this once, i know thats way too big but due too soo much amount of data i cant make that small !