My principle for https://phish.report (a tool for semi-automating the reporting of phishing sites) is: do as much statically or server side rendered as possible.
Deployment: Docker Compose. It's great to just set a DOCKER_HOST environment variable and I can deploy to any server with Docker installed.
Backend: a Go service. Could be any language really but that's what I know. Just takes requests, does some business logic and returns HTML templates.
Frontend: I'm not a frontend dev so I try to avoid it as much as possible. For UI, I use Bulma (a pretty comprehensive bunch of CSS components), with a tiny sprinkling of vanilla JS for small client-side animations (e.g. burger menu toggles).
For any user action that hits the backend, I use https://htmx.org/ and just return a small HTML snippet as the API response. No point using client-side JS for that (no latency gains and makes the tech stack less homogenous).
Similar: https://ja3er.com/ which is formed by taking a bunch of (stable) attributes from your TLS handshake, appending them into a string, and hashing it.
They've also done the correlation with User Agent and it's surprisingly accurate.
I report a lot of phishing sites but it gets very annoying very quickly.
As well as reporting to SafeBrowsing, etc. for each site you also need to look up the domain registrar and hosting provider (via WHOIS) and email them.
Rather than do this manually every time, I wrote a small CLI to automate the lookups and even open pre-templated emails: https://github.com/bradleyjkemp/abwhose
I'm now redoing this as a web app so that I can do the entire reporting process without leaving the browser: https://phish.report
Kinda fun trying to "speedrun" the process down to as few clicks as possible. And I'm pretty pleased with how fast I've gotten the process.
Now I'm looking to add some more account/user features e.g. a history of sites you've submitted.
Perhaps some stats on how many times you've been the first to report a given site.
As part of my job, I report a lot of phishing sites. This gets very annoying very quickly.
As well as reporting to SafeBrowsing, etc. for each site you also need to look up the domain registrar and hosting provider (via WHOIS) and email them.
Rather than do this manually every time, I wrote a small CLI to automate the lookups and even open pre-templated emails: https://github.com/bradleyjkemp/abwhose
I'm now redoing this as a web app so that I can do the entire reporting process without leaving the browser: https://phish.report
Kinda fun trying to "speedrun" the process down to as few clicks as possible.
Neat! I really like the crowdsourcing element where you can easily comment on the gist to make the author aware.
Would something like https://github.com/Yelp/detect-secrets be interesting to include?
Either as a filtering step to weed out false positives or to find even more secrets (i.e. that aren't near "password" or "secret")
That's a good idea! I think the biggest issue right now is the regex. It's super naive and just matches against anything containing the word "secret" or "password" which like you said results in a lot of false positives.
Indeed, on fast connections the request to Plausible gets cancelled before it can be completed. I've updated my code to use that `setTimeout` trick.
`navigator.sendBeacon` support would be amazing! I really like how simple Plausible has been to set up (having never really used analytics before) so removing even more pitfalls/hurdles would be cool
Does your company let you share your calendar privately via an iCal URL?
That's the only method of adding your calendar to QueryCal at the moment anyway but is also more likely to work with corporate restrictions (i.e. because it isn't an OAuth app that needs to be approved)
OAuth + calendar plugins are definitely on the roadmap though because it's a much nicer UX than having to dig around in calendar sharing menus
It was just a placeholder button I'm afraid :/ I've removed the buttons now to avoid confusion.
I'm planning to have a little SQL client on the homepage you can use to query against demo data (maybe the public holidays calendars from Google?) but I didn't get around to it yet.
It's a bit of a fun challenge locking it down: purposely putting unauthenticated SQLi on your homepage isn't usually recommended!
You'll never get 100% of people remembering that advice 100% of the time. So how do you mitigate the situation when they forget?