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.
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.
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.
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.