It's not a horrible idea... the challenge there would be making that payment/refund flow totally transparent in order to build trust and be fair to the researchers.
Same experience here. I've run a successful vulnerability disclosure program for over a decade and paid out thousands of dollars in bounties for scanii.com (a malware identification API service), but recently (since the beginning of the year), we went from receiving maybe 5 per month to receiving 5 per day. These are clearly AI-generated and extremely low quality (albeit well-written). The rules of the program aren't read, and it's clearly a “point-and-click to a website" and file a report.
I'm now considering just shutting down the program since, as the OP pointed out, if you found this vulnerability using an AI tool, they are inherently public.
I haven't gone that far yet but have instituted some new rules aiming at filtering out most of the reports: 1- No AI-generated report and 2 - Reports must include a video of the exploit.
You can see our program rules here: https://docs.scanii.com/article/131-does-scanii-have-a-secur...
Sure, for a very narrow definition of _efficiency_. There's plenty to complain in terms of the JVM and Java but performance, as in units of work per dollar spent, is not one of them - JITs just have too many opportunities for optimizing generated code.
that's a very shallow analogy as the stock market has significantly stronger guardrails to curtain insider trading including fines and jail time these companies lack. But even if you were to bring prediction markets under the purview of the FTC, it would still not be a functioning regulatory scheme since the scope of prediction markets is just so much larger - you can bet on anything.
Well, assuming that by "statically linking" you mean in the c sense, that's exactly what GraalVM native image does today, it statically analyzes the JAR for reachability only compiling the methods/classes in use. This works but it's also what makes native-image difficult to use and brittle.
It's hard, and some might argue impossible, to statically analyze reachability in a dynamic language like java that allows for runtime class loading and redefinition. As it turns out, Java is much closer to javascript than C++ in terms of dynamic runtime behavior.
I think the big problem here is conceptual. The JDK folks are looking at this akin to PGO when, IMHO, they should be looking at this as an AOT cache (yes, the flag names make this even more confusing). How do those two differ, you ask?
With PGO you do a lot of deliberate work to profile your application under different conditions and feed that information back to the compiler to make better branch/inlining decisions.
With a AOT cache, you do nothing up front, and the JVM should just dump a big cache to disk every time it exits just in case it gets stared again on the same host. In this case, training runs would just be a” run you did to create the cache". With that said, the big technical challenge right ow is that building the AOT cache is expensive hence performance impacting and cannot really be done alongside a live application - but that’s where I think the focus should be, making filling the aot cache something less intensive and automatic.
Another aspect this strategy would help with is “what to do with these big AOT cache files”, if the AOT cache really starts caching every compiled method, it will become essentially another so file possibly of a size greater than the original JAR it started off with. Keeping this is in a docker image will double the size of the image slowing down deployments. Alternatively, with the aot cache concept, you just need to ensure there is some form of persistent disk cache across your hosts. The same logic also significantly helps CLIs, where I dont’ want to ship a 100MB CLI + Jlink bundle and have to add another 50MB of aot cache in it - what I do want is every time the client uses my CLI the JVM keeps improving the AOT cache.
> Impressive! What do you think it is that you do that allows you to compete with VirusTotal, and even free tools like Jotti?
Thanks and good question. We don't really compete with virus total since it's more of a research tool and, for a while, their terms explicitly prohibited commercial use (but I think that has changed). Jotti is a similar thing, more of a research tool than a high performance API you can use to build commercial products on.
> Presumably you're now using commercial AV tools, rather than Clam? Did you have to get some kind of special license from them to use it like this?
Yeah the product has expended a bunch over the years and we use multiple detection engines [2] to catch all kinds of unsafe content. But you are right, we do license a commercial AV engine to act as a backup to our own to ensure best possible detection rates. The licensing process warrants a blog post of its own since it's not what I would call easy.
Got it, in that case it helps to build a product for a community you can interact with. In my case, this was connecting with folks on Stackoverflow that were struggling with integrating malware detection into their apps... that was all the marketing I did to get the product validated - but keep in mind that was 10 years or so back.
> What did "getting it out there" consist of for you? How did you get it out there in the beginning?
For Scanii in particular, the original product was a thin wrapper around an open source AV engine, a hacked on a weekend UX, and a credit card processing integration to collect payment - the very minimal needed to find out if _anyone_ was willing to pay for this service.
With that said, what worked for me in this case is not what I would focus here since it depends on what kind of business you are trying to build. What I do believe is important is focusing on the economics of your space which, for IT, is all about productivity or, more succinctly, saving people's time - they pay you X for something that could cost them, in terms of people's time, Y to do.
So, what you want to ask yourself is whether signing up, paying and onboarding onto your product (the X in the equation above) is significantly lower than the next best alternative, either doing the same on a competitor product or building something themselves - the Y above.
For scanii, even at launch it saved people lots of time managing and operating malware detection engines which are cumbersome and hard to keep up to date. I had a feeling that would be the case when I launched but I couldn't be sure until our first customer voted with their credit card.
I built Scanii [1], an unsafe/malware content detection API/SaaS, as a way to keep my coding skills sharp as I moved into engineering leadership roles. Over the years it has grown into a lovely $35k/month business while spending $0 in marketing thanks to our amazing customers.
My advice to aspiring entrepreneurs: get it out there quick, listen to your customers and be ready to act on their feedback. Finding product/market fit is a journey even if you are selling into the most well understood vertical since it's not just about what the market expects it's about what your engineering talent/capacity can delver in a reasonable amount of time.
https://www.scanii.com a content arbitration/malware API service. It has been profitable for over 10+ years now with customers around the globe.
Building it was one of the best decisions I made in my life since it enabled me to make hard decisions at work that were not skewed by the fear of losing my job and not being able to provide for my family - I'm in engineering/product leadership.
But, do not be fooled, this also means I've had two jobs (albeit of unequal urgency) and that, obviously, equates to long work hours.
For the last 9+ years I've worked on https://scanii.com, a content identification service (think of it as the unix file command on steroids wrapped around an easy to use API). Started with a real MVP hacked on a weekend (https://web.archive.org/web/20101209005314/http://scanii.com...) after identifying the need on a day job I had a long time ago. With 0 marketing and sales it took a while to start gaining traction but I always knew that we were solving a real problem with a good and fair-priced product. Nowadays it’s big enough to be classified as a lifestyle business and that’s all right by me.