It's important to note that we're now arguing about the level of quality of something that was a "ha, ha, interesting" in a sidenote by Andrej Karpathy 10 years ago [0], and then became a "ha, ha, useful for weekend projects" in his tweet from a year ago. I'm looking forward to reading what he'll be saying in the next few years.

[0] https://karpathy.github.io/2015/05/21/rnn-effectiveness/

[1] https://x.com/karpathy/status/1886192184808149383?s=20

If AI had such obvious gains, why not accelerate that timeline to 6 months?

Take the average time to make a simple app, divide by the supposed productivity speed up, and this should be the time we see a wave of AI coded apps.

As time goes on, the only conclusion we can reach (especially looking at the data) is that the productivity gains are not substantial.

Because in the beginning of a new technology, the advantages of the technology benefit only the direct users of the technology (the programmers in this case).

However, after a while, the corporations see the benefit and will force their employees into an efficiency battle, until the benefit has shifted mostly away from the employees and towards their bosses.

After this efficiency battle, the benefits will become observable from a macro perspective.

Unnecessary drama as usual...

The one demanding it is the maintainer of keepassxc it would’ve been better to just close the issue that this is a Debian only problem and he should install it like that and just close it.

In fact not having it encourages copy and paste which reduces security.

Whats next? Strip javascript support from browsers to reduce the attack surface?

I don't get how this is even a discussion. Either he is paid by canonical to be a corporate saboteur or he is completely insane.

now this is separate from being open for discussion if someone has some good arguments (which aren't "you break something which isn't supported and only nich used") and some claim he isn't open for arguments

and tbh. if someone exposes users to actual relevant security risk(1) because the change adds a bit of in depth security(2) and then implicitly denounces them for "wanting crap" this raises a lot of red flags IMHO.

(1): Copy pasting passwords is a very bad idea, the problem is phsishing attacks with "look alike" domains. You password manager won't fill them out, your copy past is prone to falling for it. In addition there are other smaller issues related to clip board safety and similar (hence why KC clears the clipboard after a short time).

(2): Removing unneeded functionality which could have vulnerabilities. Except we speak about code from the same source which if not enabled/setup does pretty much nothing (It might still pull in some dependencies, tho.)

but yes very unnecessary drama

It depends on the threat model you have in mind. If you are a nation state that is hosting data in a US cloud, and you want to protect yourself from the NSA, I would say this is a realistic attack vector.

Happy to revisit this in 20 years and see if this attack is found in the wild and is representative. (I notice it has been about 20 years since cold boot / evil maid was published and we still haven't seen or heard of it being used in the wild (though the world has kind of moved onto soldered ram for portable devices).

* They went to great lengths to provide a logo, a fancy website and domain, etc. to publicise the issue, so they should at least give the correct impression on severity.

    It requires only brief one-time physical access, which is realistic in cloud environments, considering, for instance:

    * Rogue cloud employees;
    * Datacenter technicians or cleaning personnel;
    * Coercive local law enforcement agencies;
    * Supply chain tampering during shipping or manufacturing of the memory modules.

Consider also "Room 641A" [1]: the NSA has asked big companies to install special hardware on their premises for wiretapping. This work is at least proof that a similar request could be made to intercept confidential compute environments.

[1] https://en.wikipedia.org/wiki/Room_641A

Ah yes, so I bet all these companies that are or were going to use confidential cloud compute aren't going to now, or kick up a fuss with their cloud vendor. I'm sure all these cloud companies are going to send vulnerability disclosures to all confidential cloud compute customers that their data could potentially be compromised by this attack.

First we should be careful in what I said; I never said physical access is unrealistic and certainly didn't say this attack is not viable*. What I am saying is that this is not a concern outside a negligible amount of the population. They never will be affected as we have seen with the case of Cold Boot, and all the other infeasible fear mongering attacks. But sure, add it to your vulnerability scanner or whatever when you detect SGX/etc.

But why should this not be a concern for an end user that may have their data going through cloud compute or a direct customer? It comes down to a few factors: scale, insider threats and/or collusion, or straight up cloud providers selling backdoored products.

Let's go in reverse. Selling backdoored products is an instant way to lose goodwill, reputation, lose your customer base, with little to no upshot if you succeed in the long term. I don't see Amazon, Oracle, or whoever stooping this low. A company with no or low reputation will not even make a shortlist for CCC (confidential cloud compute).

Next is insider threats. Large cloud providers have physical security locked down pretty tight. Very few in an organisation know where the actual datacentres are. Cull that list by 50% for those that can gain physical access. Now you need to have justification for why you need access to the physical machine (does the system have failed hardware or bad RAM) that you need to target **. And so on and so forth. Then there is physical monitoring of capturing a recording of you performing the act and the huge deterrent of not losing your cushy job and being sentenced to prison.

Next collusion: so we consider a state actor/intelligence community compelling a cloud provider to do this (but it could be anyone such as an online criminal group or a next door neighbour). This is too much hassle and headache in which they would try to get more straightforward access. But the UK for example, after exhausting all other ways of getting access data to a target, could supply a TCN to a cloud provider to deploy these interposers for a target, they would still need to get root access to the system. Reality is this would be put in the too hard basket; they would probably find easier and more reliable ways to get the data they seek (which is more specific than random page accesses).

Finally I think the most important issue here is scale. There's a few things I think about when I think of scale: first is the populous that should generally be worried (which I stated earlier is a negligible amount). There's the customers of CCC. Then there's the end users that actually use CCC. There's also the number of how many interposers can be deployed surreptitiously. At the moment, very few services use CCC, the biggest is Apple PCC and WhatsApp private processing for AI. Apple is not vulnerable for a few reasons. Meta does use SEV-SNP, and I'm sure they'd find this attack intriguing as a technically curiousity, but won't change anything they do as they're likely to have tight physical controls and separate that with the personnel that have root access to the machines. But outside of these few applications which are unlikely to be targetted, there's nascent use of CCC, so there's negligible chance the general public will be even exposed to the possibility of this attack.

I've ignored the supply chain attack scenario which will be clear as you read what follows.

A few glaring issues with this attack:

1. You need root on the system. I have a cursory understanding of the threat model here in that the OS/hypervisor is considered hostile to SGX, but if you're trying to get access to data and you control the OS/hypervisor, why not just subvert the system at that level rather than go through this trouble?

2. You need precise control of memory allocation to alias memory. Again, this goes back to my previous point, why would you go to all this trouble when you have front door access.

(Note I eventually did read the paper, but my commentary based on the website itself was still a good indicator that this affects virtually noone.)

* The paper talks about feasibility of the attack when they actually mean how viable it is.

** You can't simply reap the rewards of targeting a random machine, you need root access for this to work. Also the datacentre technicians at these cloud companies usually don't have the information apriori of which customer maps to which physical server.

Credit/debit cards with chips (EMV) are another proof of existence that hardware-based protection can exist.

> It is not evident that there even is a way to implement the kind of guarantees confidential computing is trying to offer using hardware-based protection only.

Not in the absolute, but in the more than $10 mil required to break it (atomic microscopes to extract keys from CPU gates, ...), and that to break a single specific device, not the whole class.

And the key would not allow you to jailbrake another Xbox.

So at most you might be able to make a PC look like an Xbox, but a PC is more expensive to start with.

So unclear exactly what you have accomplished.

You must be joking, are you still not using a password manager at all?

When you create the username+password combo you either do it yourself, then put in the password manager the domain, or you use whatever the password manager infers at the registration page, then that's basically it, for most sites. Then 1% of the websites insist to use signin.example.com for login and signup.example.com for signup, so you add both domains to your password manager, or example.com.

Now whenever you login, you either see a list of accounts (means you're on the right domain) or you don't (which means the domain isn't correct). And before people whine about "autofill doesn't always work", it doesn't matter, the list should (also) show up from the extension modal/popup, so even if autofill doesn't work for that website, you'd be protected, since the list of accounts are empty for wrong domains.

It's really easy, and migrating to a password manager just sucks the first couple of days, every day after that you'd be happy you finally did it.

Or applied to the programming example, the statements:

    1. Server.accept
    2. Client.connect
    3. File.write  # write to completely unrelated file