yes, most company settings don't run untrusted code, and OpenBSD is mostly used for servers not employee devices
but that doesn't mean LPEs aren't quite relevant, because they matter for pretty much everyone if combined with other vulnerabilities, like RCE, supply chain attack etc.
and while RCE are becoming less common, supply chain attacks have been increasingly more common
makes me wonder if there is potential for a more "main stream"/by default friendly version of this, where the key during suspend is encrypted using the TPM even if the TPM isn't a possible unlock from cold boot (i.e. no TMP encrypted volume key in the LECS headers/meta only temporary in memory during suspend)
or the alternative (for more convenient usage) for single user systems auto login on boot + use disc password for doas/sudo?
I mean gov id app really doesn't matter (for now) you can just use you id card which is credit card sized. (For now has things might change wrt. age verification.)
But banking apps are a problem.
It's not even about the main online banking (you can use a web portal) or storing a EC digitally in you phone (convenient but really unneeded).
The problem is dump, misguided 2FA apps. E.g. credit card 2FA which already mostly required Android/iOS to work or even online banking login 2FA, transaction 2FA etc. with same requirement.
Currently for the later I can still use other methods but for a huge amount of Banks where I live you can't use a credit card (reliably) without Android or iOS as "carrier" for an 2FA app.
EU AI Act got hijacked by huge corpo with last minute changed with moved it from "could probably work" to "catastrophe".
Even at 2 December 2027 it might be intentionally not enforced at all due to that for a while, through I think the goal is currently to amend it until then.
> that LLMs will be excluded from being used in high-risk AI use cases
no, it won't I can guarantee you this. At best they will get additional restrictions over time, as things go wrong. Anyone who could make this happen has way too much interest to not make it happen. (Most/All? EU country legal systems are overloaded to a point of not working correctly anymore, and have been before AI generated law suites and other AI nonsense started. I won't go into detail but many believe AI assistance (for certain tasks, always with a human doing any final decisions) is the only way to get out of this mess).
> standards are published yet
or exist,
like seriously this isn't a case of there being non public WIP standards which will pin all the nitty bitty details down, but cases of state agencies (and in last instance judges) having to decide if a specific standard (or implementation) is sufficient or not.
but also to some degree it shouldn't be tightly coupled to tech standards as there are often many ways to implement the things the law requires and accepting only one is undesirable (and likely wouldn't legally hold up). But having tech standards which are a "guaranteed to be enough if you comply with" (but not the only valid way) would have been preferable, bringing us to the next point
> have absolutely no idea how they will ensure compliance
nor do they know, the original non big corpo hijacked version had exceptions for most companies affected now. So it would only have affected a handful of huge companies, which have many of the things required already in place, in some form or another. Most likely this would have played out as this companies presenting how their measurements are "sufficient" and the agencies then evaluating it and potentially requiring some changes, going back and force over a longer duration leading to documented cases of rough technical standards about "what is sufficient" they then can pass to other organizations in the future. But now the law affects not just a handful of companies but like thousands, if not tens of thousands. Many not stuffed in a way where such a process could work, or even do the necessary documentation to show "compliance"...
So from a practicability POV, if enforced starting 2027, it currently excludes close to _any_ (meaningful) use of AI, down to a trivial linear regression or similar. Including any "old school ML/AI" any Bank uses for risk assessment.
Banking stopping running in December and there not being any (meaningfull) AI startups or adoption at all is not something anyone (in power in any state organ) wants to see, so guess how much it will be enforced ;)
And as mentioned the chance of AI as technology being excluded "in general" is close to none. Maybe specific usages could be excluded (and/or are already excluded) but thats it.
Oh and as a bonus a malicious reading of f+g remove any proper privacy protections for any AI usage in high risk context, where it is often most relevant... (a more sane reading allow it, with ... tricks).
also not fully sure, but AFIK there are limits to how far you can wave this right, in context of things like TOS, simple opt-in fields on forms etc.
Like YT would have loved to make you opt out of it (and probably has it in their TOS) but there where multiple cases of courts forcing them to handle it properly in the past as far as I remember.
My _guess_ is that at least if you don't sign a proper contract you can always force a human reevaluation. But also only that (so only semi useful). Also even with a proper contract it's unclear if it would be possible in this specific case due to the contract being fundamentally one-side/unfair and semi-forced on you if it where wide spread on the market for the specific job you are trying to get.
- having a right you can't wave
- which is very similar to something being forbidden
- but different to having a right you fully or partially can wave
Furthermore to some degree you are only "subject to a decision based on ..." if the decision has an effects affecting you.
In practice wrt. Article 22 this means companies can make a "decision solely based on automated processing[..]" iff they give you a (realistic) chance to object to it in which case they will do a human review of the decision where a human confirms/changes this decision based on reviewing the involved information.
There is a lot of gray area what a "chance to object" means and when a human review makes an decision no longer "solely based on automated processing" (a human just saying AI was right clearly doesn't count, but a human constructing a case why they would have decided the same way based on the why the AI did the decision can count, iff it's reasonable to assume a human might have come to the decision had it only been reviews by an human).
Or in other words GDRP Article 22, just "soso" meaningful in context of hiring.
Like if the AI did a mistake they have to reevaluate it, but as long as there are other similarly qualified competitor (they did hire/are in process of hiring) it quite easy to come up with a reason why they are a better choice for them. Or go through the motions of you being in round 2,3 of hiring and then find an excuse to not hire you.
And this + the tendency for AI to "prefer" AI produced code + some other AI biased is why *this is most likely highly illegal to use in the EU due to violating anti discrimination laws in multiple ways.
To be clear:
- randomly filtering "too many" resumes is pretty much allowed (I think)
- but must be actual random independent of the resume (and can be in multiple layers, i.e. random filter > pre-select > random filter > select)
- this isn't the case for AI as the random aspect isn't done as the random aspect is not independent of the actual resume evaluation
- in general you can't make sure the AI doesn't apply systematic biases, and there is high indication that it does do so
- for humans you can train them and order them to ignore their biases, this won't work reliable either _but now you delegated the responsibility of illegal biases to the hiring personal violating the order_. But for AI usage you are responsibility no matter what you tell it. Lastly you can technically "show/proof" a specific used AI is highly biased in a specific contexts, which for human employees is technical possible but practical not really practical. So this moves "specific mostly deniable" cases, into "systematic proven bias" teritory. Or in other word legal risk goes from "limited/no issue" to "people can systematically f-you over if they know you use AI for hiring".
and this should include musics and similar in games (excluding stuff like sessional content)
if you sell a game you should have to have bought a license to use the music (and similar) in the game permanently (for given game sold, new sold revision can change what they contain but only if there isn't deceptive advertisement and it's very clearly labeled that it's a different revision/the content changed!).
except it very well might look quite like that. I happen to know such a case and I don't know that many people IRL.
Video Gaming became widely available roughly in the 90th in many of the places the steam machine is expected to mainly sell to (US/EU/CA/AU/UK/some other places, a lot of special cases).
And most people who grew up with video games don't stop gaming. This means that Steam customers and gaming in general is not _at all_ anymore a hobby where most people fall under a small handful of stereotypes.
In turn statements along the line of yours are really quite meaningless and misleading. Steam has stopped being "just for nerds" or anything like that a long time ago.
And sure, things are probably different if you limit yourself to people active on steam forums, that place has a very different bias and using it as basis can lead to huge misconceptions about how people who "use" steam generally live.
Lastly let's also take a moment to consider who this steam machine is advertised to:
- no children, doing so is a regulatory pain
- not young adults, in current times 1k is just too much for someone currently trying to see if they can move out of their parent's place
- so more adults with a stable job/income, which grew up with gaming or at least do game a lot (so mainly age group ~20-35)
- also excluding the kind of people which would anyway go for a 3+k gaming system even if prices where more normal (like a lot of tech enthusiasts with money, "pc masterace" gamers, etc.)
and if you consider that potential customer base the chance for a randomly sampled home (of the target customer audience) to look somewhat like that(1) just went up quite a bit.
And exactly this is also the group for which the clip is, because a major part of the clips "message" is something on the line of a vague combination of "It's a product for everyone"/"Not just for nerds"/"Not just for tech enthusiasts"/"No special tech knowledge needed to play". I.e. "hey person who might live in an apartment without any nerdy stuff, it's also for you, you don't need special tech skills or anything like that". And this is kinda the only group where such a clip might make a difference in weather or not they buy, most other customer groups either won't buy anyway or will make a decision based on spec and reviews...
So IMHO this is a very well chosen clip setting.
Funnily the room does contain a lot of the kind of "not perfectly fitting furniture" you find a lot IRL due to a combination of people not finding fits and replacing/adding furniture over time with slightly changes in taste. I wonder if that was intentional or if the studio provider just didn't care or hat issues finding the right sets of things them self.
---
(1): As in: It has no "nerdy" things, or tech enthusiasts things. And is "just" a "normal/boring" adult apartment taken a clip of shortly after it was cleaned.
and you might also end up with 100 people with punk hair stiles, or firefighters or whatever
Games are so wide spread through all parts of society and Steam is the largest platform for them, sampling 100 people is fully non representive.
Whatever stereotype of two people on a couch you pick, there are not just thousands but more like many 100,000ths to millions of people not matching the stereotype at all. I mean think about it steam has daily active user numbers in the multiple tens of millions.
My best guess is, the people on the photos are related to whoever created the photos in some arbitrary way. It's a pretty common practice for startups when you need photos like that and have no need for "professional actors/models". Like employees of you or who ever you might have hired to do the photos, or some of their friends etc. You still need to singn a simple contract but it's much less time intensive, complicated and annoying to do compared to trying to hire models (of any kind including such made to look like "gamer stereotypes") .
IMHO there isn't a realistic "typical gamer stereotype" anymore
sure you can pick any of the past stereotypes and will find people like that, even many, but it's not "most" or even "a slim majority"
Games, and with that Steam, have spread through all of society and Steam is the most wide spread platform for it.
So whatever anecdotal data you have based on your local environments selection bias is probably not "overall representative", just a slice of one of the many many different kinds of people playing games bought from steam.
> I don't understand how Codex can blunder so badly.
because they trust the AI too much (and seem to be fin with acting knowingly negligent)
the problem is
- AI tends to produces very convincing looking code, even if fully wrong
- AI does mistakes of kinds no human would do, at least no human who is also able to write convincing looking code
- code reviews are hard, a lot of devs, including senior devs, put a lot of implicit trust into the co-worker behaving "sane and non malicious". But AIs behave sometimes not so sane and in a way (wrt. trying to be convincing). In the worst case in ways which if it where a human you might consider to be them trying malicious sabotage the product
Like a "dump" example from work:
- AI randomly removes a HTML element id while doing other changes in jsx/react
- the PR has a lot of changes, the id removal line looks innocent, like some on the fly cleanup
- human reviewers have the bad tendency to often not look too much at deleted lines, only if they need reference to how a new line was before (but it's only a deleted line and no new line)
- you don't expect humans to randomly without reason delete important properties of components when changing other things
- you maybe would still have found it, but it's a emergency fix for a production issue
- it happens to miss integration tests, but happens to still matter a lot for one specific important for complicated reasons not properly tested flow (similar people tend to not test logging too much, at best the presence of needed info but hardly ever the absence of noise)
racial slurs are an impossible problem you can only approximate based on non trivial linguistic analysis. Regexes can't handle that without you accidentally messing up badly including, discriminating against minorities in a potentially illegal way, especially when it comes to names.
I mean sometimes you can put a cultural context on something, e.g. the life chat of a US streamer you can use wort filters based on what is a slur in the US. But the streaming platform as a whole probably should be far more careful then using naive (and likely wrong/discriminating) regexes.
Because what is a slur is often highly context dependent in many often not so obvious ways. And people do intentional misspellings etc. all the time so a lot of "definitely not slur words" become de-facto slurs if (and only if) use in specific ways.
E.g. "Niger" as in "Republik Niger" also known as "Jamhuriyar Nijar" (see Wikipedia) is a country in Afrika, but also in the US a subtle misspelling of a very bad slur...
E.g. Nonce is a cryptography term is most of the world (number only used once), except in the UK where it's a pretty offensive slur (through not a racial one).
Like it basically jail broke the "no security vul guard rails" not in any clever way but just by fixing them, producing exploit code just by writing test cases making sure it's fixed. So you just need to look at the code & tests as a human to get vulnerabilities and exploits(components).
What makes this so beautiful IMHO is that it's a trivial jail break, but also a close to unfixable. At least not without making the model close to useless for normal development (it refuses to fix bugs/write code) or making it a major liability (it silently pretends it didn't see bugs and silently avoids fixing it, which for a human would count as intentional sabotage and might involve criminal liability).
32bit WASM doesn't have a strict 4GiB limit (if the runtime and OS it runs on is 64bit, which is normally the case)
the thing is in WASM "memory" is more or less a resizable ArrayBuffer
and while each has an effective 4GiB limit wasm does allow passing more then one such buffer to any specific wasm "execution/thread"(1) you can then reference them in load/store instructions to load/store from other "memories" then the default one
As general purpose languages tend to not model that this isn't that easy to take advantage of but it is still useful for all kind of "tricks", like (non exhaustive):
- working around 4GiB size limit
- persistent memory between otherwise clean restarts and/or software updates (like what you can get from systemds file descriptor store and other means)
- easier handling of pre-populated memory (think large perfect hashmaps, trie, or similar)
- memory isolation, WASM memory can be shared, but for security and fault tolerance reasons it is often preferable if different workers have their own memory array as well as an additional shared memory array.
- This also allows stuff like security proxies where A->B have a shared memory IPC mechanism and B->C have that too, but A->C can directly communicate at all. Not that relevant in the browser and more for server side WASM usage.
- and more
Anyway IMHO the main point for WASM64 is more the convenience benefits then the 32bit memory limitations. Like porting is easier, most software is 64bit today. Like it's what people are used to. There are a lot of ways where overflows can happen with 32bit but are practically impossible for 64bit. E.g. overflowing 0u64 with +=1 at 6e9 ops/s takes decades, but for 0u32 it's <1s. Stuff like that means you need far more sanity&safety checks in 32bit and it's easier to mess up edge cases.
or they increasingly copy what a lot of their training data does, discussion for discussion sake and arguments for the sake of winning them instead of productive outcomes.
That the AIs where trained on what humans wrote on the internet forms is increasingly sowing as they incresingly mirror all the bad things which are so common on such forums, like:
- non stop, non productive discussions
- gaslighting
- valuing "winning the argument" over correctness
- ignoring of context/ignoring the actual questions/instructions etc.
- bad faith argumentation methods
- etc.
the problem is in a forum you can just decide to ignore "most users", but LLMs tend to copy "most users" more then "a few high quality answers" and you have only one per model type more or less...
> beside-the-point semantic nits all over the place.
This is also a problem with Copilot Reviews on GitHub.
We have them enabled (but opt in) and they have, multiple times, spotted quite useful things.
Sure often the thing they spot is just half right, like it spots the place where a problem is but not quite the relevant problem but by reading it (and taking it serious) you then notice the actual problem.
This involved finding a bunch of nasty race conditions.
And many ways where doc and code was out of sync which could have caused pretty bad outcomes further down the line.
But the problem is it is too obsessed with finding 2-4 but not more things, leading to two issue:
1. even if there are 10 non overlapping issues it often will tell them to you bit by bit over 2-3 runs after you fix the previous issues. This is very annoying/high friction.
2. once there isn't much to find anymore it comes up with increasingly more annoying nit picks not one cares. Thinks like minor unclearness in formulation no one would get wrong, spell correcting non-doc comments for things like `foos => foo's` and similar etc. All indeed wrong, but also all things where fixing them adds 0 business value. Obsessing that for an aliased function name where, both names are equally good, one specific name must be used and naturally always the name you didn't use even if this is the most widely used name in the code base. And similar non-bussiness value nonsens. Worse it will starting classifying such minor non business value issues as "high" and hallucinate reasons why supposedly minor style issues will lead to very bad runtime error or other nonsense.
This has me very split about the feature, on one hand is has proven quite useful, on the other hand it can very annoying, high friction and pushes people to wast time on non-business value nit pick (which are fine to fix if you anyway touch to code but not fine if you don't and sometimes it's just wrong).
Ironically with how it work it is more like a bad unreliable and inconsistent employees which is sometimes good at spotting things others overlook. That just isn't what you want from an automated code review :/, but also is to useful to fully ignore :(.
> Canadian government directly liquidated their property and put them into camps.
While the mechanism was different that was what _effectively_ happened to US Japanese people, too. The taxes part is more like a separate mechanism of discrimination against anyone "new" which "happened" to overlap with this (and tbh. I have no idea to which degree this overlap was intentional or just "tolerated").
--
But if I have to guess why someone down voted the comment (not me) ti might be because it feels a bit like trying to downplaying how bad and against the values the US claimed it stood for, this was. And doing so by pointing at some random other country and saying "they also did bad things so we aren't that bad" which is a really bad argument.
Just because others also have done bad things doesn't mean anything is less bad, or more reasonable or more excusable.
I mean a lot of countries did some pretty bad things in the past, especially the past 200 years.
When I post about stuff like that it's isn't about saying "hey they are bad". It's more because I think people from countries should be aware about all the bad stuff their country did/was done in their country. So that they can learn from this.
But sadly most countries try to bury most mistake, atrocities, large scale crimes etc. in history or at least exclude them from anything thought proactively, e.g. in school. And the only way to know about them is to go looking for them by yourself in your free time. Which doesn't work well even if you care as it's hard to learn what you don't know you don't know.
Like as a random example the tulsa race massacre should be required teaching in middle school with focus on the dynamics which lead to a mob of people including people in governing positions to thinking it is okay to try to lynch a whole district (more or less, simplified).
Or e.g. in Canada there is the genocide of indigenous people (which by now might be through about in school, not sure).
Or in Germany the genocide against Jews (which is thought a lot in middle school as required teaching material).
Or the crimes Japan committed against China in WW2 and before (which they still bury very deeply AFIK).
Or a pretty long list of atrocities in China science 1900.
The important part here isn't teaching "that" it happened, but "why/how" it happened, so that if stuff goes in the same bad direction again people realize it and (hopefully) stop it.
If we don't learn from the past I really don't know how humans as a species expect to not accidentally collectively press Alt+F4, given the increasingly higher stacks/larger powers involved.
and implicitly force them to sell the land they own for less then it's worth, which in combination with setting up very messed up tax related laws in some states (1) which highly benefit you if you bought land longer in the past effectively "killed" a budding, wealthy, land owning Asian community and made sure it can't really regrow in that form.
(1): I think it was mainly California, but don't remember full
yes, most company settings don't run untrusted code, and OpenBSD is mostly used for servers not employee devices
but that doesn't mean LPEs aren't quite relevant, because they matter for pretty much everyone if combined with other vulnerabilities, like RCE, supply chain attack etc.
and while RCE are becoming less common, supply chain attacks have been increasingly more common