Having worked in compliance engineering I have also reported through the IC3 portal, and spoken with lawyers and analysts who register with FinCEN (which, to be clear, is maybe just a step beyond "My Uncle works at Nintendo...") and I have heard that those reports do get reviewed and often acted on, but yes, you will typically never hear back from them. (FinCEN has its own reporting structure, but we also submitted certain reports through the IC3 portal as well.)
Honestly, the "acted upon" part needs to be highlighted in tangible ways, otherwise people will be suspicious that nothing ever happens to our reports, leading to fewer reports being submitted.
During the IC3 reporting process I was asked to submit the name of people behind the scam, if known. I knew one of them because the scammer asked for a wire transfer to a named account at a bank in Oregon. Probably a mule.
Does anyone at the FBI or other agencies actually do anything with this information, such as contacting the bank in question or correlating it with other investigations? That's what I would expect if law enforcement were serious about enforcing the laws on the books. But there is no indication that anything happened, other than a confirmation number being spit out on a web page that my report had been received. That's why I made the "black hole" comment earlier.
If the IC3 portal highlighted specific cases or stats ("thanks to reports submitted to IC3, n investigations were initiated/suspects charged/convictions secured") that would really help convince ordinary victims that the government is taking tangible steps to fight this scourge of small-scale scams and frauds that affect millions of people every year.
There are strict rules about not talking about open investigations because of so-called "Tipping-off" rules. It can carry some pretty serious penalties - jail time, fines. I agree it would be nice if the FBI itself made some announcements about these sorts of things, and they might do that in aggregate, but if you're a bank or fintech employee and you're in communication with the FBI you absolutely cannot say anything about it. Even confirming that an investigation existed could be penalized.
> Even confirming that an investigation existed could be penalized.
I didn't know that. But that is another point that could be highlighted on the IC3 homepage or confirmation, along with aggregated data about enforcement actions resulting from submissions from ordinary victims.
My assumption is that they at least have an intern read them, but only act on reports likely to lead to major cases, for some value of "major" that includes cases where terrorism, large sums of money, or Important People are involved, or more generally cases that could lead to seriously good/bad PR if pursued/ignored.
De minimis non curat FBI.
They may also flag certain cases to be passed to other relevant authorities like FinCEN, the Secret Service, the Postal Inspection Service, various military investigative services, or even the intelligence community (assuming NSA doesn't already intercept the mailbox which would be a very reasonable thing to do).
"Acted upon" in these sorts of bulk data contexts typically means "charge them for an extra count when we pick them up for something else".
It's like the internet crimes version of putting the serial number of stolen property in a police report. They ain't looking for it, but they'll tack the charge when they inventory a crackhouse bust and that number pops up stolen.
They aren't dedicating serious resources to speculatively looking at the reports and trying to assess patterns like some TV cop looking at a series of dead hookers and saying "aha we have a serial killer on the loose".
Same. I lost a lot of photos this way. I've recently moved over to Immich + Borg backup with a 3-2-1 backup between a local synology NAS and BorgBase. Painful lesson, but at least now I feel much more confident. I've even built some end-to-end monitoring with Grafana.
Thanks... hence, 3-2-1 backups with offsite :) appreciate it though. Will definitely be rolling my own NAS in the future, I just needed something easy at the time.
I've recently started hosting my own forgejo instance. It works so well! Free tailscale for connectivity. I expose mine over fly.io proxy, also free, but not to be done without caution.
Correct. Not sure about a sql archive, but the kiwix ZIM archive of the top 1M English articles including (downsized but not minimized) images is 43GiB: https://download.kiwix.org/zim/wikipedia/
And the entire English wikipedia with no images is, interestingly, also 43GiB.
It goes a lot further than plan mode though, in fact I would say the key difference of mikado refactors from waterfall refactors is that you don’t do all the planning up front with mikado. If anything you try to do as little planning as possible.
I’ve been using a form of the Mikado Method based on a specific ordering of git commits (by message prefix) along with some pre commit hook scripts, governed by a document: https://docs.eblu.me/how-to/agent-change-process
I have this configured to feed in to an agent for large changes. It’s been working pretty well, still not perfect though… the tricky part is that it is very tempting (and maybe even sometimes correct) to not fully reset between mikado “iterations”, but then you wind up with a messy state transfer. The advantage so far has been that it’s easy to make progress while ditching a session context “poisoned” by some failure.
I recently orchestrated this, although in my case I've chosen to use 1password's cloud based store as my primary secret store, so I'm accepting some exposure right off the bat that you might not be comfortable with.
Basically, I have a borg backup job which runs every day, in a 3-2-1 replication strategy with the backups being sent both to a locally encrypted NAS (backups themselves have an additional layer of encryption via borg) as well as off-site with BorgBase. Those backups scoop up an export of 1password that I have a reminder to kick off manually about once a month via this script: https://github.com/eblume/blumeops/blob/main/mise-tasks/op-b...
The password that decrypts the key (along with the password that decrypts the backup) is stored on a piece of paper in a fireproof safe in my house. I've got a reminder to practice the entire DR process every six months, although I've only done it once so far as this is all pretty new.
Thanks, it's also available via my 1password cloud account, so it'd have to be a joint fire at my home and the 1password data center (and my phone, for that matter). Pretty bad day I feel.
Unrelated note: this was the first time I've linked to my static generated docs for this project and it was really fun watching the grafana dash of my fly.io nginx proxy pick up all the scraping traffic. Thanks for warming my cache :) I work with this tech all the time at my day job but this is the first time I've hosted something from my home, it's genuinely made my afternoon to see it light up.
reply