sandeepkd

I try to be accurate when sharing information like this. Some things are fact and some things are opinions, I already tried to annotate the opinions as interpretation. Most of the information is first hand, I was a member of FIDO alliance in past, have been watching these discussions.

1. This can be subjective, Unfortunately Customer identity is not on the highest priority from security perspective, its all about ease of product use when it comes to customer identity. For customer identity, most account recovery methods still fall back to email or SMS even if you have 2FA configured. The real money lost with phishing is with enterprise identity, when some one poses as an employee. The recovery of these accounts can be managed. If a customer account gets hacked then the business is not really on the hook to make it even.

Usability of passwords

This is the biggest point of contention as per my interpretation. The industry did a very poor job of securing their infrastructure leading the massive leaks of password databases. Instead of fixing that goal post changed, with the by introduction of PASSWORDLESS. The passwordless works just fine for enterprise identities, not the customer identity. Even for enterprises, you cannot get rid of passwords if you get into AAL concepts (guidelines provided by NIST for authenticator assurance levels)

4. I was working on WebAuthn when the term passkey was not there, I was there when the term was introduced, I saw how every one was trying to map their existing definition/understnading with the new terminology specially the part where Apple just announced them to be syncable. Enterprise companies had to actually disable the Apple Passkeys for this reason to begin with. I found it interesting to see how Yubico changed their documentation overnight, they switched every instance of WebAuthn keyword with Passkey. It took some time to settle on how to categorize discoverable credentials (where meta information about user is on the device in addition to credential) and non-discoverable credentials (hardware keys, they are limited in space so they did not store user meta information in earlier versions). Eventually google took the lead in calling the credential where private key cannot be synched as Security key and everything else as Passkey. Resident key, syncable, synched are all different bits of the WebAuthn assertion

5. Thats an interpretation of how I read things based on the overall play going on.

Passkeys protect against phishing attacks, and you get that protection regardless of whether the credential is hardware-bound or not. That protection comes from the cryptographic binding of the credential to the domain at the time of credential creation.

The security aspect is tightly coupled with the authenticator implementation. The phishing aspect is the only default good in here, it just means that the credential is strictly tied to a particular domain, the one on which it was set, that too is highly dependent on the client (browser) doing the right thing. Additionally you have to count on the server to not get compromised as well (There is a a feature to support multiple domains).

Most importantly, when you make something this hard and complex to understand then be advised that people are going to make mistakes in implementation and leave gaps in security.

I would highly recommend using ORM's, with the caveat to know exactly when not to use them. Startups do not fall in that bucket.

1. Most of these advices are unfortunately impractical and incomplete for startups. A good Data Model is highly dependent on understanding the business requirements, data flows. Means unless you are repeating yourself in the same domain its really hard to come up with a good schema in first iteration.

2. Startups are in the mode of discovering the schema for most part

3. Deleting columns is harder than adding additional columns, no one takes that risk so everyone ends up with schema bloat

4. Once you go a little bigger you will realize that the integer based UUID are not that great of a choice. Those are separate tables which maintain those index counters and not part of your DDLs. They have their own set of issues with data merging, backups and recovery

For the OP, I looked at the repo (https://github.com/hatchet-dev/hatchet/blob/main/sql/schema/...) ,

1. seems like the schema has database functions - Thats a potential scaling issue, plus you are asking vertical only scalable component to do something which could have taken care by horizontally scalable component

2. TEXT datatype for pretty much every attribute - this is a footgun, you cant use them for indexes properly, in the absence of length checks they can be abused from client side

LLM is not hacking itself, its a PR spin if anything. LLM is an input output system, there is no more hacking than that. What gets abused or hacked is how the input is parsed, validated to guard certain information (training data). Security was not the design principal which was strongly considered in the design of LLMs.

LLM being hacked only means that you are able to get the training data out of LLMs which was supposedly being guarded by some probabilistic harness. Thats not security, its more like a prayer for security.

Works just fine, you have to get the one with NFC

I am an engineer and have some insights on the discussions and developments around it.

ITS NOT SIMPLE AT ALL

1. The idea was to provide a phishing resistant authentication method for enterprise users (companies loose quite a lot of money to phishing).

2. Majority of industry players shared the vision of a credential which is available across the platforms and browsers

3. The vision for collaboration never materialized so everyone went their own way to implement it. Examples would be google rolling out browser (Chrome) managed authentication which led to this situation where even on the same machine you have to remember which browser you used to create the Passkey credential.

4. Interestingly enough the earlier popular name was WebAuthn, Apple started calling it Passkey on fly, given Apple's popularity everyone just caved in.

5. My personal interpretation is that in some sense Apple wanted to be the default password manager on Apple devices.

6. This is when all password manager companies jumped in strongly to save their business and the protocol went into a direction where you can use your existing password manager to store the credential/Passkey as well

Personally its a mess, the phishing resistant aspect has its own benefits though. If you are using it with security in mind then my recommendation would be to use a hardware backed security key with NFC enabled. Everything else is pretty much lipstick on pig, they are worse than passwords in some sense from usage perspective.

Security exists in multiple layers. CVEs do not make a system vulnerable by default, there has to be a way to exploit them. Questions one can ask, is your system connected to internet, what does your fire wall looks like, which ports are open and why, what processes are running and why.

Most sensitive systems in the past had a concept of DMZ where one cannot reach through internet for security reasons except for very tightly controlled path. One had to go in the physical data centers for certain operations.

If you are running a script in a loop on your system which gets executes any/all commands from a third party system then you probably do not take security that seriously in the first place.

That capability alone could hack half the US.

This almost seems like believing in magic. What really has happened is you have collected all the hacking/abuse/malicious flows/code in one place. Greedy or A* algorithms have been discovered a long ago, the script is executing the flows for all possible permutations.

Something has to be insecure to be hacked in the first place.

Simplicity is relative from where I see things in a particular domain. Security does not have any direct ROI on it, the security engineers are hired way too late in the game when all the stack is almost buried in deep decisions. The concept of security engineers (how to secure) and product engineers (what to secure) has made the gap way to wide to make the security meaningful.

Based on my limited understanding what it translates to is -

Its a simple infrastructure security issue, instead of taking the responsibility for being lackluster with security they are just giving it a PR spin story.

Resembles a lot with my 8 year old who is so confident about everything

In the absence of concrete examples its hard to say what is OP trying to optimize for. Optimism is good, however at the end of the day everything is a trade off, the cost has to be paid for all decisions. A good design is all about optimizing when, where and how you push those costs.

leadership

Not sure if its just me, lately I have started feeling pretty offensive about the increased usage of the word. Its management not leadership by any means.

"leadership encourages this because from what they can tell, there is no downside"

For most people in management its easier to pick the current set of slangs/abbreviation's, general trend and go with it. Understanding the details would take time, raise questions and no one in management has time or political capital to spend on it.

as per benchmarks

That seems to be the key and its risky when the measure becomes the target itself. When you already know the benchmarks, and that drives the definition of success outcome then there is every incentive to just chase them

This is an interesting topic in itself, pretty much applies to all shared spaces. The security challenge is somewhat solvable with shared (tenant based) databases, I am more worried about the noisy neighbor problem. Its really easy to write a bad query which can drastically slow down the DB.

My guess is these AI companies are counting on the money to come from traditional SAAS style services only. This whole AI would be used to gather enough capital to rewrite most of the existing SAAS services under one umbrella, sort of super APP concept. The SAAS businesses doing the layoffs will soon realize that for this whole time they were just pouring their money into their own demise

any concrete evidences to support this theory from the past 12 months would be helpful here (where evidence > marketing fluff)

If the goal of a trademark is to get recognized then its futile given OpenAI is already popular. If the goal is to prevent others from using the term which is so generic then it does makes sense to not allow the common keywords being hijacked.

On a side note, the AI models from the company are not even open, one can go as far as banning it as inappropriate marketing (Product not matching the description).

Should a company promoting the enterprise usability of AI, itself start with building a intake process to distinguish between the noise and signal for these reports. If you cant solve your own problems with your product then how do you expect the customers to be able to use it.

So all the smart people are letting a script being executed on their machines where the execution of the script is controlled/managed by a remote machine. Wait, isnt that a definition of a malware??

In other words centralization of the power is most risky end game here

The problem with Flock is not who owns the data

The one who owns the data is the one who should be responsible to provide proper guardrails in certain cases if not all, specially like these ones. It comes down to the fine line around business, rules and regulations. The motivation of business is to make most profit with least cost and implementing regulatory mechanisms are cost. Abuses are natural to happen in the absence of guardrails and audits.

Not being able to prove is one thing, pretending it may not be the case is next level of positivity. There are definitely going to be pockets of hard working smart folks in every place, however the company as a whole would get a bad name even if few folks are indulged and the company is not doing anything about it.

Its just a normal letter containing the details on what to expect, its more of a heads-up than a shake down to me. If the billing information is not there and account still continue to use the feature then the account would be disabled or something similar. Question is, should the email have all the if-else situations, probably not feasible.

Most of the companies built with VC money in a MVP style fit in the criteria. The more I think about it, I feel at this point its more about the focus on business problem being solved than engineering (how its solved) which leads to this. The expectation around quality/completeness has degraded heavily lately and somewhere down the line this bloat is going to keep increasing the maintenance cost.

Fun part, all the folks who created this bloat would run away and find a green pasture.

People are generally really smart and resourceful. Specially the ones on the hacking side, boils down to whats available to take advantage of.

Decentralization is not really a feasible option when you have more than one actors. Either you embed the centralization from beginning with some good and verifiable contracts or a certain majority is going to hijack the platform and act as centralized controllers.

The LLMs are beautiful if anything, a lot of creative and hard work has been poured into building them. They take the natural language to the next level and all that was engineering part. It has its own usefulness subjective to areas. The business part, trying to put it as a silver bullet for everything, is trying to put a square peg in round hole is the one which is causing this polarization.

I was under impression that I understand networking and DNS resolution. It was really hard to follow, the OP did worked hard, just not sure what exact problem was being solved with the proposed solution that isnt already been solved.

My perception of real problem is that the LLMs were generic purpose tool and the focus was to improve their information retrieval and prediction. And they were fed with all this data (including private with was otherwise not available to everyone) for training purposes. The security and privacy of stored information was not really the requirement of this whole endeavor and all of sudden in the real world they are finding that this is a must requirement if they want to sell these models to enterprise companies.

And now all these security efforts to manage data privacy are akin to lipstick on a pig, they are brittle, costly, one-off. There are no boundaries inside the LLM storage, the training data is not encrypted at all in the memory across the pseudo tenants

Call me pessimistic or realistic, the code and architecture is just a reflection of the author/organization. The only way it can change/improve is if you either switch the people/organization or invest in their improvement/continuous learning.

Wondering whats the end game with this, it does not really benefits Anthropic much other than bad PR is its true