> > it's the difference between a $200m raise with a bunch of untested API endpoints and a $10m raise with them.
> I'm tired of companies with API endpoints that leak data like a sieve. This is why companies need some skin in the privacy game.
There is a world of difference between “untested” and “insecure” API endpoints. What seems to have been cut in the example isn’t a permissions model, but some form of automated integration testing.
I’ve seen horribly insecure APIs with 100% code coverage, and I’ve personally burned myself on untested API endpoints where the privacy implementation was _too_ restrictive for what my customers were trying to do.
I've worked with Firebase Hosting for around three years, using Firebase Functions instead of Cloud Run, but in your particular example, you can configure your Firebase Hosting to rewrite requests against your Cloud Run instances as documented in https://firebase.google.com/docs/hosting/full-config#rewrite....
This doesn't require handling an OPTIONS request for every endpoint, which I agree could be fairly simple, but Firebase Hosting configuration could very well be less invasive than this change in the rest of the codebase.
Meta might not be legally able to buy “the next big thing” in international markets. Neither the EU nor the US are particularly “friendly” to them right now, and pretty much anything Meta does in the social media category is going to run up against anti-trust regulation.
Instagram was probably the last time Facebook could have gotten away with that sort of thing in the North American and European markets. I’m being cautious to only include those markets because I’m not familiar with the regulatory environment elsewhere.
> No deadlocks, races, etc to worry about because lock graph concurrency is complicated.
I’ve spent the last two and a half years mainly programming in single-threaded NodeJS environments with a focus on heavy same-task concurrency, and I’ve still run into deadlocks and races, despite the lack of OS threads involved.
However, your point that context switching is expensive, and is why thread-per-core architectures are so common, still holds.
> Even simpler: do not upload copyrighted materials to Dropbox, Google Drive, etc.
As the article illustrates, it’s not actually that simple. Cloud services that terminate accounts (and probably instantly delete everything, to comply with GDPR, CCPA, etc.) for perceived copyright infringements will always and necessarily suffer from a false positive rate.
We’ll likely never truly learn what this false positive rate is, but that it will always exist is reason enough to give pause to the thought that services should “just terminate their account” if they think it’s infringing on intellectual property laws.
The only good answer here is an unqualified “Use a local backup”. The terms of use for non-business cloud storage absolve the providers of all responsibility for data loss, even when they have incorrectly taken punitive action against you.
I only have experience with GCP’s Cloud Functions, but in that environment, “serverless” is only cheaper than virtual servers if your load can’t saturate the lowest end VM GCP has to offer.
Once you have enough load to justify going “unserverless” the prices drop to approximately 1/4 that of Cloud Functions for the same burst performance, and that’s before playing billing games like long-term commitments or using preemptible instances.
What’s truly scalable about “serverless compute” versus VMs is the line item on your bill. Sure, “they manage the auto-scaling” but for the per-unit price you rapidly hit a point where you might as well set up a Kubernetes load balancer and eat the setup costs. The pricing model only works out in your favor if you _don’t_ have load.
It would not surprise me to learn that the same is true of AWS prices.
> The people running the company were playing with fire and they must either be too junior themselves to understand that, or they were just knowingly doing so and hoping to get whatever product MVP they had planned as quickly as possible with the minimum amount of expenses possible.
Knowingly playing with fire like this is a sign of a lack of maturity, both on the founders part and the investor’s part. Anyone experienced in the business of building software would have known that:
1. It takes time
2. Time takes funding
3. It’s probably not going to work the first time you try an end-to-end test
Mature founders would have found mature investors to give them both the funding and the time to stabilize the software. They would not have attempted to make their investor demo the first big end-to-end test, and even if they did put off testing they would have communicated that to the investors, who should have understood the state of their investment only six ~months~ weeks in.
I think the comments here taking the religious references at face value are missing the point.
> This document was [...] created for the purpose of filling in a box on "supplier registration" forms submitted to the SQLite developers by some clients.
> [The developers of SQLite] have pledged to govern their interactions [...] in accordance with the "instruments of good works" from chapter 4 of The Rule of St. Benedict [...] This code of ethics has proven its mettle in thousands of diverse communities for over 1,500 years, and has served as a baseline for many civil law codes since the time of Charlemagne.
> The Rule of Saint Benedict (Latin: Regula Sancti Benedicti) is a book of precepts written [...] for monks living communally under the authority of an abbot.
The explicit purpose of the document is further clarified in the third paragraph.
> This document continues to be used for its original purpose - providing a reference to fill in the "code of conduct" box on supplier registration forms.
As of 8:06:07 AM PDT, all of my Firebase projects in us-central1 are back up.
We saw a complete silencing of our highly used Cloud Functions between 7:15 AM PDT and 7:38 AM PDT, but had reports from our users as early as 7:10 AM PDT.
My favorite part about https://status.cloud.google.com/incident/zall/20005 is that 7:49 AM PDT's update acknowledges that customers can't create support requests. Not like they'd do anything. Every time we've gone to GCP support, we've been unhappy with excessive back-and-forth, non-responsiveness on the part of the responsible parties, and generally extremely long durations between "we are completely down" and "everything would be fine had you not hacked around our incompetence three days ago".
Maybe this is a "grass is greener" sort of thing but I can't imagine AWS is this unreliable. This is the third major GCP outage we've had this year, and last time (not even three weeks ago!) it was three hours long.
Heads up on the Microsoft Graph API: it only works for certain styles of Microsoft Office customer. In particular, you can only authenticate against it with Azure AD, which completely chokes out the home market.
> First, that their app is a better mobile experience. And I'd agree, actually, but I understand why someone would disagree. From their perspective it's an easy download and it's native app and it's way better.
It’s been two years since I last used the native iOS Reddit client, even though I think the responsive web version is embarrassingly bad, because of one reason alone: battery life.
I doubled my screen-on battery life by abandoning the native client.
Maybe in the two year interval they found a way to not be battery vampires but I’m not particularly in the mood to give them the benefit of the doubt.
Keep in mind that just about two literal years ago, the mobile experience was pretty much exactly the same as it is today, if not worse.
I imagine I’m not alone in this perspective: the “smooth, slick, native” app is worse than the stuttering, crashing, mobile web version. Period. Because I value my battery life.
I recently left the US Federal “Cyber” space, which involves practically everything that enterprises claim they want with respect to “security”. I also work for a company looking to get into the enterprise space, so have some experience on the side of spinning up these practices.
> After meeting with our first client's security team it's clear that we don't have any of the procedures in place that these clients are used to vendors having with regard security and oversight.
As mentioned in other answers, your potential customers will often give you an absolutely brutal questionnaire about this in the early exploration phase. Something that may surprise you though is that many “requirements” can actually be waived or reduced in scope, especially if the individuals investigating your product have some clout within the organization.
Be attentive to the actual needs of these customers, not the “hard requirements” of the paperwork, but make sure that as part of the legal paperwork all of your “we won’t have this ever, we don’t have this yet, we have this in x capacity” answers are all in writing. You might be surprised how many of these “requirements” don’t actually matter once these answers are written down.
Note that I mentioned “we don’t have this yet” as a valid answer. Some of the requirements presented might actually be things you know you need to implement, but don’t have the capacity to do so immediately. In my experience, customers appreciate your honesty about these sorts of requirements and can temporarily waive them with the understanding that they will be made available at a later date. Be sure that you mean what you say here: saying “we’ll have this at some point” can eventually become a point of contention if you don’t ever actually implement these features.
> While our app and infrastructure has been built with common-sense security and best practises, we haven't put in place things like vulnerability scanning, anti-malware, patch management procedures etc.
I have no idea what your tech stack looks like, but if you use cloud services at any level, you should look into how your cloud providers fare against the provided requirements.
Other answers have mentioned NIST SP 800-53 as a potential starting point for security requirements. This set of standards includes the concept of “inherited controls,” where the security requirements can be fulfilled by your upstream service providers without any additional effort on your part. This same concept also applies to the private enterprise space.
As an example, if you use a “serverless” architecture from a major cloud provider, you can automatically assume compliance with “anti-malware,” host-level vulnerability scanning, and patch management requirements. If you host your source on Github, you can legitimately claim Github’s built-in dependency vulnerability alerting as source-level vulnerability scanning.
If you happen to be running your own infrastructure here, your employer should seriously consider a migration to managed services wherever it makes sense to do so. Technical compliance with security requirements is a huge operational overhead. There’s a reason the US Federal Government has given up on in-house hosting and is now buying cloud services from Amazon and Microsoft.
> 3. Documenting procedures
At a tactical level, in order to close a sale or get your security validation, you’ll want to take the approach of “document first, implement eventually.” The best technical implementation of security controls in a NIST SP 800-53 scenario will utterly fail validation without adequate documentation, but you could skip actual implementation entirely and still squeak through an assessment with no more than an answer of “we promise to follow our own documentation.” counter-response.
Sure, you’ll eventually need to implement the documented procedures and follow the documented policy. This is going to sound extremely cynical, but so long as the fault of non-implementation can be externalized from the rest of the organization, the end customers will be happy enough to keep paying you. This is why documentation is so much more important than implementation: end customers and vendor organizations get to state that they already went through their due diligence by writing everything down, and point fingers at individuals when things aren’t following the documentation.
Forgive my ignorance, but how does the trade deficit in favor of China necessarily entitle China to acquire ownership of US companies? The best explanation I could think of is that China is using the liquid capital obtained by US trade to turn around and purchase ownership stakes in US companies the same way pretty much anyone within the US would, which means there’s no special arrangement outside of China having money to spend and the US being in need of investments.
If my hypothetical explanation is correct then the implicit goal of “fixing the deficit” ends up reading as ultimately somehow ensuring China has less money, and just that China has less money, when I think that the legitimate national security concerns around the trade deficit would be better addressed by some actual investment oversight.
But, again, maybe there’s something about the deficit entitling China to stakes in US companies that I’m not seeing.
Though their timing is incorrect. We noticed this at 9:26 AM EST and their posting says it "started" at 10:11 AM EST.