What doesn't get talked about in these articles is the increasing impact to small business in the US.
I run a small business (scanii.com) and I've noticed over the past year an increasing number of customers leaving us to European competitors, customers that have been happy with us for years, using our European region, but now have concerns over US foreign policy and are giving preferred treatment to EU suppliers. When I asked they said, I'm paraphrasing here, "happy with the product but management wants EU supplier".
What this means in practical terms is that, if the tide doesn't change, US entrepreneurs will have a potential buyer population that is roughly cut in half if they can only sell to US buyers. This will have a cascading negative effect in the number of startups that succeed - impossible to quantify at this point.
Large corps can skirt around this issue by establishing an EU entity and trying to buy goodwill that way but that's not an option easily available to small businesses.
To be fair, it was always obvious to anyone with half a brain that "European region" from a US provider was fake-EU.
The problem is that PARIOT act, CLOUD act and everything else has gone from being a paper tiger to real and present danger. No longer a theoretical risk.
So even people willing to previously turn a blind eye to the crystal clear risks can no longer do so.
It is also no longer possible to trust those tasked with implementing it not to bow to political pressures.
A long time ago now, Microsoft (Azure) put up a fight when the US came calling for some data hosted in their "EU (Ireland) region". I think there is zero chance of them putting up a fight today if Donny boy picked up the phone to Satya .
And that's before we get to the example of a Texas court ordering Verisign to cut off the .com domain from a Dutch company.[1]
Sadly I have limited sympathy for a country that having witnessed Donny's first term thought "you know what, we'll have more of that" and voted accordingly.
Sovereignty has gone from being a theoretical concern that a lot of cloud (esp. AWS) advocates poo-poohed to something that is a very real concern in the minds of many. It's not just US foreign policy either. It's even within Europe--to say nothing of things related to China.
It'll be longer than that. If during that 2.5 years more and more companies move away from US companies, why do you think they would just abandon the non-US company to move back to a US company? The non-US company would have to be sooooo bad for that to happen. Also, there's no guarantee that the next US administration will be the opposite of the current, and even if it is there's no guarantee the one after that won't flip back.
No, that’s the new status quo. Even if democrats get in power next time:
1) it’s fairly unlikely that they give up on more powers voluntarily (exactly how much of the patriot act and the post-9/11 rules were given up by Obama and Biden?)
2) there is always the possibility of a future switch to another populist nutcase (or hell, any nutcase really). We are not going to trust American voters to be sensible anymore. We’ll need a couple of sane administrations and long-term polling data for that.
That would not be a big problem. But the next Republican president may be even worse than Trump. Trump is just the symptom of a deeper corruption problem.
That things will fix themselves when Trump is not in the White House anymore is a dangerous misconception.
US-made... Cloud products? Like there's anything US-specific or unique about Taiwan made/China assembled computers the instant it's sold by a US corporation?
Since they are cloud products and not bare metal servers, yes, you are paying for the specific features of AWS, Google Cloud, Azure, etc that are lacking outside of US companies.
I disagree, that's a price point concern not a market accessibility one. I strongly prefer to be able to sell to another 400M people than not have the option to do so.
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...
What if... on the vulnerability report rules page there's an image of some text saying something like "your report must include the text: turtle123". Reports without that text get automatically deleted.
Sure - modern AI can figure that out, but I bet in a vast majority of cases they won't.
Reminds me of someone (well known in their field) who charged $0.05 for using their “contact me” page. A trivial amount for someone who genuinely wanted to contact them, but just high enough to prevent any kind of scaled abuse
If I've stumbled across what I think is a security issue in your systems, there is zero chance that I'm going to get out my credit card and pay you for the privilege of responsibly disclosing it to you. Especially if it's the vulnerability is in the site hosting the contact form.
I don’t participate in bounties at all unless I believe there is a moral obligation or I’m set to make thousands of dollars. In each case, $0.05 is fine.
For a typical commercial entity? $0.05 is not a deterrent; the companies legal team is and has been for a decade.
In most cases I'd think it's more of a deterrent for commercial entities, because spending money create complexity. Most employees are not in a position to just directly spend their organisation's money, so that $0.05 will often mean needing to get approval, purchase orders, deciding which cost centre it comes from, needing an invoice, etc, etc.
Very few people are going to invest that much effort when they're trying to do the company that they're reporting to a favour.
I know some professors who have started doing something similar to combat students using AI for their work. Even going as far as to hide the "your report must include XYZ obscure word 3x" prompt instructions in small invisible text. It's gotten pretty bad, with some students turning in papers with the original ChatGPT prompt LEFT IN THE TURNED IN ASSIGNMENT.
Have you considered requiring a small payment for vulnerability disclosure? Refund it on payout. This should be very effective at deterring spammers. It also sucks for real reports, but beats shutting down the program entirely.
Those are 2 big "ifs". The incentives are completely misaligned and the platforms work for the companies. They would now have an even bigger incentive to stonewall and close valid issues than they did before.
They already like blurring the lines by rejecting reports that have clear reproduction scripts, videos, demonstrable (but not critical) impact. They'll close it as "not a bug" but then also forbid disclosure and stonewall mediation requests. Reports are supposed to be kept private until the issue is fixed but the system gets abused to cover up issues long after they've been fixed.
In some cases I strongly suspect it's to evade liability for financial damages that their customers might've suffered. Platform mediation always takes their side and if you want to do what's right, you will get banned.
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.
Making, payment/refund setup is more complicated than „set and forget”.
First question: Do you keep money for shit reports?
Well no, you have to pay it back like credit card validation. There is no pain for posting shit report just inconvenience. There is no legal way where you can keep the money.
Because you are not providing any service not selling anything. There is no real way as a company to withhold someone’s money and that it goes through accounting.
I am not an accountant so ask some accountants why not.
To participate in the bug bounty program, you must pay ACME Inc. $1 (one U.S. dollar) per submission. This payment is non-refundable as it covers our triage costs and bounty payment processing fees. You may submit a vulnerability without paying, but you will not be eligible for receiving any bounty payments under this program.
If your disclosure otherwise meets all of the guidelines of the program, but is not eligible for a bounty, we may, in our sole discretion, award you a bounty of $1.
There is a history of companies and organisations threatening legal action against security researchers when they report vulnerabilities in their systems or products.
Sometimes even when the testing has been completely offline - I know people who have downloaded some software, carried out testing against a local copy of it, and then faced legal threats when they tried to report serious security vulnerabilities to the vendor.
It's one of the reasons that some researchers don't bother trying to talk to the vendors and just go straight to full disclosure, or if they do report to vendors they do so anonymously. But if you have to pay, that's creating a link back to yourself which makes the latter much harder.
When you report a vulnerability in a product that means you hacked the product. Hacking is illegal. If it's something that runs on your own computer you might get away but if it runs on a server then it's 100% a felony.
But do you know how many people are doing things that are even dumber right this very minute? I don't know either, but I'm sure it's larger than either of us would like to admit.
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.
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.
It would be nice to be able to trigger AOT somehow, e.g. as part of a Docker build, or as part of an app startup as you say. Then the software deployment can decide what to do.
> I’m not asking if the tooling currently exists, I’m curious if there’s something inherent in .class files that would prevent static linking.
It's not so much a problem with the .class files, instead it's a problem with reflection.
I can write `var foo = Class.forName("foo.bar.Baz")` which will cause the current class loader to look up and initialize the `foo.bar.Baz` class if it's available. I can then reflectively initialize an instance of that class by calling `foo.newInstance()`
Java has a ton of really neat meta-programming capabilities (and those will increase with the new ClassFile api). Unfortunately, those make static compilation and dead code elimination particularly hard. Tools that allow for static compilation (like graal) basically push the dev to declare upfront which classes will be accessed via reflection.
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.
In the Java sense, if you properly utilize JPMS, JLink can cut dead modules and reduce your image size drastically. This obviously of course like you said depends on how "open" your runtime model is. If you're not dynamically loading jars it works really well.
Native Image does exactly that already, but producing an AOT-compiled-and-linked native executable is not the goal, it's just a means to some goal. The real question is what is it that you want to optimise? Is it startup/warmup time? Is it the size of the binary? Peak performance? Developer productivity? Program functionality? Ops capabilities?
AOT compilation certainly doesn't give you the best outcome for all of these concerns (regardless of the language).
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.
> 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.
> 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 guess more of what I'm asking is, how did you launch? The biggest problem I have is getting word out about my product, which always ends up killing them.
I'm a developer by trade, so marketing and the like isn't my forte. Did you use ProductHunt? Indiehackers? Reddit? Twitter? Word of mouth?
Thanks for the reply btw, very helpful info. I've been iterating on something in my free time that fills a very small budgeting niche. I'm going to wrap it up with a website this weekend and see if I can gain any traction. At the very least, I know that if I had found the product I've built for $1.99 a month or something, I would have just paid the money. Hoping that others feel the same.
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.
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.
Not impressed, particularly with the basic-auth description. Basic auth is purely a well understood vehicle for sending a tuple (aka the credentials) for authenticating a HTTP request, most of the concerns highlighted are with regards to how the credentials are acquired and potentially reused across requests - that has nothing to do with the HTTP protocol.
For example, my API product scanii.com has used basic auth for 7+ years and I firmly believe it strikes the right balance between security and easy of use. Besides fairly complex key/secret tuples for server side usage, we also provide one-time auth tokens for when you want to make API calls directly from a web browser (or another insecure device).
Author here. The doc does acknowledge basic auth as a valid approach for server side usage, but the language was a bit too pessimistic about basic auth.
I just modified it to say the following
If you use HTTPS, then basic authentication is a good choice for server side only applications. It is the easiest to get started, and is well supported by clients and server frameworks.
Basic auth is only OK if you don't have :80 open. Clients will send the creds over the clear to :80. It doesn't matter if you reply with a 400, the creds are already compromised at that point.
As a rule, HTTP basic auth is inappropriate without SSL, even for intranet apps. An office could easily have an insecure Wifi point, and someone sitting outside running Wireshark.
Also important to note that even on secure Wi-Fi with WPA2, if the attacker knew the password to the network they can just as easily sniff such plaintext ocontent.
It prevents delegation, though, which is an important use case for some APIs. As in "I want this third-party service to read my calendar from another server, but I don't want it to hijack my account, and I want to be able to revoke its access later on."
That's an implementation detail of how the credentials are created, managed, interpreted by the server, and their use reported on to the user, none of which is specific to the credentials transport or encoding, which is all basic auth is. The thing to be aware of is how different HTTP clients, specifically user-interactive browsers, use (apply and remember) the credentials.
If you reinterpret Basic auth as "send a token that's not the user's password in the Authorization header", you're just doing OAuth 2 but writing "Basic" instead of "Bearer".
We migrated scanii.com from Amazon Simple Payments to Stripe subscriptions (after the whole FPS debacle) and haven't looked back, it's truly the best way to process payments right now. If I could buy Stripe stock I would.
I run a small business (scanii.com) and I've noticed over the past year an increasing number of customers leaving us to European competitors, customers that have been happy with us for years, using our European region, but now have concerns over US foreign policy and are giving preferred treatment to EU suppliers. When I asked they said, I'm paraphrasing here, "happy with the product but management wants EU supplier".
What this means in practical terms is that, if the tide doesn't change, US entrepreneurs will have a potential buyer population that is roughly cut in half if they can only sell to US buyers. This will have a cascading negative effect in the number of startups that succeed - impossible to quantify at this point.
Large corps can skirt around this issue by establishing an EU entity and trying to buy goodwill that way but that's not an option easily available to small businesses.
I fear rough waters ahead.