I think a sensible architecture would involve many pools of wallets with different availability. So the majority of funds can probably be completely offline, with only occasional transfers to/from various offline vaults. The there could be different groups of different levels of online funds that are ideally physically separated (individual teams and employees can only access a subset of the wallets).
Yeah, because the six number chunk is near the limit of recall. Don't remember CVE-2026 since the year and CVE can be reconstructed from time memory. You know it came up this year. Remember that vuln 111-497 (as two chunks) came out this year, and remembering two short chunks is easier.
I don’t know why you’d want to remember the number, but this one seems easy if you know some memory techniques.
> Remember that vuln 111-497 (as two chunks)
Good first step. Remember it’s two sets of three numbers. The first set is all ones, meaning the first three numbers are 1, then the fourth number is 4, then you add five for the next one (9), then you have to remember to subtract two (7)¹.
May sound silly, but I bet some of you have already memorised it from that alone. Being a slightly convoluted by still logical set-by-step helps with recollection.
¹ Lot of different ways to go about that, like remembering that the first set was three of one so “two was left out”.
What if they never fix it? Is there at least a deadline where the researcher's are ungagged? What if the exploit is being used in the wild, can the researcher warn people then?
This is the only way. Auto mode is really just yolo mode with more LLM tokens billed. It may catch some weird shit but it isn't a reliable sandbox. Just lock up the LLM and let it run.
Are you sure? When they announced it they said they will update quotas to account for it. Which just means that the next adjustment will effectively null it out.
The docs all say there is a time and billing cost:
It's the only way if you want 100% security but often a compromise between security and usability is preferred.
I'm actually working on multi harness auto mode. It's already done for Pi and I'm currently working on copilot cli port (where it is needed the most by the fa r of autopilot in copilot being so atrocious).
The correct way for auto approve to work is similar to what claude code does (a deterministic algorithm where a separate model reads what the user says and adds rules based on what the user enables).
I couldn't believe such a thing that works well doesn't exist, but it doesn't. You either have to do borderline yolo or you cannot leave a model working overnight and not find it got stuck on some silyness after an hour.
Not only revenue but enterprise users are valuable market share. Think of things like Slack calling which last I checked don't work in Firefox unless you spoof the user-agent. More enterprise users will force better Firefox support in a huge variety of websites which will benefit all Firefox users.
I don't mind 64-day certificates. However they recommended renew at 2/3 validity remaining means that I can no longer take a month off without needing to be prepared to debug a certificate re-issuance problem. Not a problem for companies with 24/7 oncall or even at most a week of the whole company off at a time. But for individuals this is pretty annoying.
Sure, re-issuance usually works. But when you only do it every 42 days it does break from time-to-time without you noticing.
I would love if we still renew with 30d remaining. I really don't care if they reduce certificate lifetime to 31 days as long as I am allowed to renew daily. But lowering the gap between expiry and when you are allowed to renew is very annoying.
Be ready because their plan is to reduce the lifetime to 7d as soon as possible for their evil masterplan to strip us off reasonable control about our websites.
Now that they have a dominant position they do Google style and Google influenced move.
You are at their will fit whatever retarded dictatorial decision they want.
Given this is a free service, what's the endgame of this "evil plan"? I don't know much about SSL and such so I assumed lowering this lifetime has some safety benefit
With a longer lifetime there are validity checks. If the life is lower than the maximum time to cache a validity check then they are unnecessary, every renewal is like its own validity check.
"Let's encrypt" was the excuse to impose "https" as mandatory and web browser and so. So let's say you have a home device, https is also mandatory to not have to go through countless warning hops.
But they said: it is ok now, because you can get a certificate for free with let's encrypt.
So suppose, you have a local device not connected to internet or your own private network server/services, with 3 month validity, it was short but you were able to generate the certificate in some way, manually, and deploy it manually also.
You could also easily manual renew and deploy the certificates.
Now, with a very short period, especially the 7 days that is their end goal, your devices needs to be constantly connected to internet, constantly receiving "things" from LE that are automatically downloaded and "installed". And it becomes impossible, to manually manage the certificate renewal, so you are force to let automatic scripts/agent do that work.
And most probably also let the script/agent auto-update itself because of "breaking changes" like it happened with certbot.
And all of that being, with a short lifetime, you are now constantly at will of Let's Encrypt, and in the end the US state and government where all of this is located. You depend of the https for a lot of things, now at the US gov will you can be cut off, eventually be monitored or be targeted, in a very short timeframe of "days" instead of months.
You can also more easily have your certificates impersonated in a hard to catch way as certificates will be constantly renewed.
And even in a non evil plot, if anything happens to let's encrypt, down time or anything, you could have your service broken with dead certificate in a so short time that you would not even have the time to look for a solution. Today you have at least months to figure out.
There are many flows that don't work. You can only have a single person working at the file at a time. You need a mutex (which email is in this case). However imagine that you send back a file, then realize that you missed something. You can add more changes and send it again, but if the other party has started working already now they have no reasonable way to merge in the new changes.
Also is there anything that actually guarantees that the tracked changes were the only changes made? I haven't seen this but it seems like a serious flaw in the process.
Also what if you get an intern to do some of the work, then you want to review the changes between version:$lastyousaw and version:$current. IIUC the mail with tracked changes only allows you to view one "patch" at a time.
To argue for this workflow: the mutex is soft (social) which is a good thing, sometimes ppl do not reply on time and you need to move forward. For having new ideas/paragraphs after sending out, you either inform the colleague to hold it until your done, or you send a paragraph and ask him to merge it.
The mail allows you to see all patches, sometimes 'clean slate' is done by accepting all changes. While this sounds like a problem in theory, in practise its not.
I agree that things can be better somehow, but it is really difficult to see any solution which is at least 10% better. The current workflow also has the advantages:
- data is as safe as your filesystem and email system together
- Word file is generally not considered a vendor lock-in
- everybody understands the workflow
- nobody can block the workflow (like not checking in again with sharepoint)
reply