Usually government mandating something is concerning cause it seems to favor the government for its existence. However with EU commission its actually interesting combination, its representing multiple individual governments at once which somehow works good for the citizens.
Overall this is a common sense solution. The challenge is that a significant industry makes money by collecting and selling data. It makes it harder for businesses who depend on it, they are going to get creative and will eventually come up with some dark pattern to circumvent it.
This is more of a way to create a unauthorized toll tax on highway. There is a problem indeed, however if the proposed direction by cloud flare is to solve it or benefit out of it is a debatable topic.
I get a mixed feeling about all this. Cloudflare is unilaterally making all these decisions which impact the whole internet traffic flow. Taking the lead is one thing, however decisions like this should have the direct involvement of Internet Engineering Task Force (IETF) to account for all stakeholders, otherwise we run into the situation of a fragmented internet
Ideally yes, the TLS termination does not need to happen for caching purposes. Challenge is that in practice every business wants to be sticky and try to provide more functionalities which do require TLS termination. Most people either trust CDN's or they do not understand MitM so it does not concerns them. Plus they are getting certificate management and DDOS prevention capabilities.
I think a lot of these kind of posts are standalone assessment of your problems, understanding and solutions. Its debatable to term something as lack of expertise if one is trying to work with default settings of a tool and expecting a certain performance. Everyone is doing a continuous learning with the failures.
1. What I find interesting is that the experiment seems to be using a DB server with 96 cores, 384 GB RAM (https://github.com/dbos-inc/dbos-postgres-benchmark/blob/mai...). This is very critical part of any such experiment, it should have been called out. The database is vertically scalable and that too has its limits
2. Who is making connection, and from where has its own impact on performance and overall latency
3. 60k may seem big number, however in real world the things which bring the systems down are the bursts of traffic, not the regular traffic.
Personally I would never start with such a big server unless I am a big business. Its > 100K cost for one production DB cluster if I include read replicas and cross region redundancy
I think the timeline is critical here and should be highlighted. Self hosting email server was something that worked out just fine in the past (used to host until 2014), however things have changed a lot with the scale of abuse. its not worth it unless you are doing it as a business. Sending a email from your home IP to big email providers with reliability is next to impossible. Even if we discount the spam management,
1. IP reputation is a big deal, its not just about not being on some blocklist, call it a cartel at this point, its about being on the allow list for other mail providers
> you have proven that you're able to serve random file from a webserver, so the grant is to allow you to serve them via TLS connection.
Its digression from the original topic, still, it goes way far than that, these certificates are signed by a CA that the client devices trusts by the virtue of root certificates installed on the device. If I can some how obtain the SSL/TLS certificate for google then thats a very big deal.
On a different note, adding a file on webserver is one of the ACME methods (HTTP-01) to get a SSL/TLS certificate so it is indeed considered as possession method in real world already
In the absence of actual details its hard to say what was considered for making this decision. If I have to take a wild guess then being able to demonstrate the control on the webserver hosting the content could have been one way to prove ownership over the domain.
It can be called social engineering, however one can also put it in category of account recovery by verifying content control on the domain.
The part where it gets hairy is if your credit card was associated with the account, thats probably a recipe for disaster?
Almost every API caller has to add the logic for retries based on the response codes, centralizing it with the gateway optimizes the repetitive code across the clients.
Trip breaker patterns are good for resource usage on both sides (client and server) when you know things are not working. In addition to that it also saves on cost for the clients if every call is billed irrespective of success or failure.
It works great for static credentials. As a product I think about adding couple more things that might be helpful here (Btw I am not the client for this, I just happen to know them as practical problems)
1. Support for OAuth Client credentials - Gateway does the OAuth dance to get the access token, this is quite practical and even useful in case of regular services running across clusters and sharing the same clientId-secretId
2. Support for request retries on certain failures and short circuiting in other cases
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
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.
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.
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.
Overall this is a common sense solution. The challenge is that a significant industry makes money by collecting and selling data. It makes it harder for businesses who depend on it, they are going to get creative and will eventually come up with some dark pattern to circumvent it.