TrueDuality

Really not trying to be cheeky... but why? Who is the audience here? I can see maybe academics with small grants and want to do the absolute minimum spend on compute... But that is an audience you will have to fight for every cent.

This doesn't solve or provide guidance for the subtle problems in these otherwise opensource solvers... The first example requires the client to manually disambiguate equivalent variables to get a stable solution... Sure that's a pretty common problem everyone working with optimizers should be familiar with but they're also one of the hardest things to track down in a complex derived model.

The problem frequently crops up in order-deterministic systems that use time and haven't accounted for the edge case of all the vagaries related to time-keeping of this being only one.

I've worked on some extremely sensitive systems that had thousands of lines of C dedicated to handling skewing a time gap across an hour-per-second when necessary. I know that code assumed only "missing" time (jump-forwards)... Even knowing what I know as a developer now, if I was re-implementing that system from scratch and didn't have this top-of-mind, I'd bet I would miss "overlapping" or "duplicate" time entirely.

Maybe that is more of a me problem than others, but I'd bet there are some safety critical systems out there where the responsible engineers, QA, and specs all missed this as well.

Do you want to trust your company's legal commitment on the output of modern LLMs?

The article itself covers the specific reasons that has led to that exact problem and the potential solutions available in the ecosystem with their various trade-offs.

A big chunk of the problem with this kind of legislation for me is that it inherently indicates a failure to govern to me. I disagree with the premise of the solution, but even more so this is trying to legislate a specific engineering solution for our current systems rather than any form of financial, objective guidance, or have reasonably actionable and enforceable consequences.

While laws that target engineering decisions are sometimes reasonable, they are always accompanied with specific guidance from a credible academic based institution (e.g. mechanical and civil engineering use private licensing bodies and develop specific curriculum and best practices).

The only time this law will ever be enforced is punitively for other crimes against major actors who are extremely limited in number. It is unenforceable for Linux, trivial for Apple, Microsoft, and Google to add to their OS. Presumably easy to spoof, the law describes it as minimal but once again, there isn't a specification so who knows. Websites won't be liable, they're getting a sweetheart deal here.

In practice what this law does is absolve abusive platforms an from any responsibility. It adds extra meaningless work and overhead for legitimate adult platforms while opening themselves up to new potential legal challenges, and ultimately doesn't replace the responsibility its removing.

This doesn't make children safer. This doesn't make the internet safer. This kind of legislation makes it easier to abuse children online by removing responsibility from platforms that are known to be dangerous to them yet profit from their presence the most.

This is publicly publishing the account ID. There is an optional extension in RFC8659 that extends it but it isn't required by any implementer. This puts that ID into a public well known location that is easy to scrape and will be (this is exactly the kind of opsec info project like Maltego love to go lookup and pull in).

The accounturi is an optional extension. Email, and phone are also optional. This is the first challenge that publicly requires you to specify your account ID publicly. There may be implementations that require it but neither Let's Encrypt or the protocols require them.

I think this is solving a real operational pain point, definitely one that I've experienced. My biggest hesitation here is the direct exposure of the managing account identity not that I need to protect the accounts key material, I already need to do that.

While "usernames" are not generally protected to the same degree as credentials, they do matter and act as an important gate to even know about before a real attack can commence. This also provides the ability to associate random found credentials back to the sites you can now issue certificates for if they're using the same account. This is free scope expansion for any breach that occurs.

I guarantee sites like Shodan will start indexing these IDs on all domains they look at to provide those reverse lookup services.

I'm not sure the distinction matters, and attribution is inherently hard and easy to get wrong. I frequently read Country X is doing Y, less as a indicator of government action and more of a single that we can't be more specific of who within the country is performing an action but we know the behavior is occurring there.

In the case of IP address purchases, these are publicly tied to specific public and private entities and can be easily queried through the regional registries. These private entities are frequently the same kind of shell company you'll get with hiding shady financial details.

Pretty unlikely in my book. This runs OpenWRT out of the box. Given, there are still closed source binary blobs in these things, especially around WiFi 6 and frequently the customizations for the kernel isn't released, but those tend to be more expensive locations to place backdoors especially when the system is very open to inspection. These kind of devices are VERY frequently torn down by security researchers and used in WiFi shoot-outs leading to much higher potential increased detection of anything present.

A lot of this these "backdoor" style hypothesis' still need a motive justification for the cost. Who would they be targeting? What is the potential value of the backdoor?

Given the visibility and complex locations required for the firmware, this would be an expensive backdoor to put in place for any amount of time. The attack is completely untargeted, at best you may be able to say tech enthusiasts that travel. You probably can't count on executive targeting, this device requires a separate battery pack as well as per-site configuration as opposed to pairing to their iPhone and not carrying all that extra stuff.

What are the chances of an expensive, high-visibility backdoor showing up in a dirt cheap product line for a high-risk untargeted attack? Pretty low in my book but your threat model may vary.

I love the inherent wonder and joy in this post around the original images.

Now THAT is great news

This is a false equivalency I'm surprised no one else has brought up. An archive of a site preserves attribution inherently, the scraping and training are not.

Yeah you're 100% right that it's optional. It's usually only required to allow company data such as email, slack, file sharing etc on your personal device. If you're on-call it is VERY rare for an employee to win a fight on making the company provide a dedicated device for that purpose (which can inherently make it a condition of your job but that's an exception).

Most employees tend to not care about the why and are happy to just do it making "you" (the one bucking the trend) the oddball. The one not being the team player. It's not legally required, and you won't be fired for it, but its strongly socially encouraged and that makes it mandatory for anyone not willing to put up that fight.

Having a device enrolled in an MDM package does not make it a corporate device. Many corporations require personal devices be managed to support remote wiping. If I install a productivity or developer tool on my personal phone or laptop for personal non-corporate use I would get mistaken as a corporate user by this process.

If you want to collect this information you should be clear about it and know and understand your edge cases before you start attempting enforcement actions based on it if that is the intent.

In general in my experience, personal tools are a VERY hard market to sell into for corporate environments (I took a peek at what the software on OPs site requires a commercial license to use). I would bet most if not all of what you're catching here is unauthorized installs in a corporate environment and you're more likely to loose interested users than sell more commercial licenses.

I haven't decided my opinion on this specific license, ones like it, or specifically around rights of training models on content... I think there is a legitimate argument this could apply in regards to making copies and making derivative works of source code and content when it comes to training models. It's still an open question legally as far as I know whether the weights of models are potentially a derivative work and production by models potentially a distribution of the original content. I'm not a lawyer here but it definitely seems like one of the open gray areas.

Another commenter mentioned that this is needed for consistently ordering events, to which I'd add:

The consistent ordering of events is important when you're working with more than one system. An un-synchronized clock can handle this fine with a single system, it only matters when you're trying to reconcile events with another system.

This is also a scale problem, when you receive one event per-second a granularity of 1 second may very well be sufficient. If you need to deterministically order 10^9 events across systems consistently you'll want better than nanosecond level precision if you're relying on timestamps for that ordering.

That is also what I came here to find out. Would love to hear from the creators of the project how it compares and contrasts to Talos. We've been running Talos for a few bare-metal and air-gapped cluster deployments with pretty good success but do have some pain-points.

The irony for me is that it's already slow because of the lack of native 64-bit math. I don't care about the memory space available nearly as much.

You don't necessarily need on-package RAM for this. I'm not sure I'd build a project around this, but 16MiB of RAM would hardly be BOM killer.

I write primarily as a means to collect my thoughts and outcomes around projects. I keep analytics on my site not to optimize for any particular audience but because it feels validating and that I'm contributing in another form.

I still see high traffic on a post explaining oddities in some of Route53's unintuitive behaviors and hope I'm making someone's day a little better in giving them a solution.

That drives me to write more.

LXC far predates docker regardless of size or impact. It's not disingenuous if you were literally the foundation docker was able to package into a shiny accessible tool.

Remember that under the last reign of the current present, information services were removed from Title II regulation. Biden did vote to restore the net neutrality status last year but that was challenged in court and never went into effect. It was ultimately overturned in January and we're left without net neutrality protections.

How many of the makers of these trash SEO sites are going to voluntarily identify their content as AI generated?

The references I'd direct you to are NIST 800-53r5 controls CM-3 (Configuration Change Control) and CM-4 (Impact Analyses) along with their enhancements, require that configuration changes go through documented approval, security impact analysis, and testing before implementation. A certificate change is unfortunately consider a configuration change to the services.

Each change needs a documented approval trail. While you can get pre-approval for automated rotations as a class of changes, many auditors interpret the controls conservatively and want to see individual change tickets for each cert rotation, even routine ones.

Speaking as someone who has worked in tightly regulated environment, certificates are kind of a nasty problem and there are a couple of requirements that are in conflict for going to full automation of certificates.

- Rotation of all certificates and authentication material must be renewed at regular intervals (no conflict here, this is the goal)

- All infrastructure changes need to have the commands executed and contents of files inspected and approved in writing by the change control board before being applied to the environment

That explicit approval of any changes being made within the environment go against these being automated in any way shape or form. These boards usually meet monthly or ad-hoc for time-sensitive security updates and usually have very long lists of changes to review causing the agenda to constantly overflow to the next meeting.

You could probably still make it work as a priority standing agenda idea but its going to still involve manual process and review every month. I wouldn't want to manually rotate and approve certificates every month and many of these requirements have been signed into law (at least in the US).

Starting to see another round of modernization initiatives so maybe in the next few years something could be done...

Almost every one of those benefits _doesn't_ require anything else. You need one more API endpoint to exchange refresh tokens for bearer token (over a simple static API key) and you get those benefits.

The quick rundown of refresh token I'm referring to is:

1. Generate your initial refresh token for the user just like you would a random API key. You really don't need to use a JWT, but you could.

2. The client sends the refresh token to an authentication endpoint. This endpoint validates the token, expires the refresh token and any prior bearer tokens issued to it. The client gets back a new refresh token and a bearer token with an expiration window (lets call it five minutes).

3. The client uses the bearer token for all requests to your API until it expires

4. If the client wants to continue using the API, go back to step 2.

The benefits of that minimal version:

Client restriction and user behavior steering. With the bearer tokens expiring quickly, and refresh tokens being one-time use it is infeasible to share a single credential between multiple clients. With easy provisioning, this will get users to generate one credential per client.

Breach containment and blast radius reduction. If your bearer tokens leak (logs being a surprisingly high source for these), they automatically expire when left in backups or deep in the objects of your git repo. If a bearer token is compromised, it's only valid for your expiration window. If a refresh token is compromised and used, the legitimate client will be knocked offline increasing the likelihood of detection. This property also allows you to know if a leaked refresh token was used at all before it was revoked.

Audit and monitoring opportunities. Every refresh creates a logging checkpoint where you can track usage patterns, detect anomalies, and enforce policy changes. This gives you natural rate limiting and abuse detection points.

Most security frameworks (SOC 2, ISO 27001, etc.) prefer time-limited credentials as a basic security control.

Add an expiration time to refresh tokens to naturally clean up access from broken or no longer used clients. Example: Daily backup script. Refresh token's expiration window is 90 days. The backups would have to not run for 90 days before the token was an issue. If it was still needed the effort is low, just provision a new API key. After 90 days of failure you either already needed to perform maintenance on your backup system or you moved to something else without revoking the access keys.

That is a very specific form of refresh token but not the only model. You can just easily have your "API key" be that refresh token. You submit it to an authentication endpoint, get back a new refresh token and a bearer token, and invalidate the previous bearer token if it was still valid. The bearer token will naturally expire and if you're still using it, just use the refresh immediately, if its days or weeks later you can use it then.

There doesn't need to be any OIDC or third party involved to get all the benefits of them. The keys can't be used by multiple simultaneous clients, they naturally expire and rotate over time, and you can easily audit their use (primarily due to the last two principles).

There are other options that allow long-lived access with naturally rotating keys without OAuth and only a tiny amount of complexity increase that can be managed by a bash script. The refresh token/bearer token combo is pretty powerful and has MUCH stronger security properties than a bare API key.