the decision which was made was having a digital ID wallet, that this needs hardware attestation (or something comparable) is somewhat of a direct consequence of existing laws/regulations regarding making IDs forgery safe
it also is a phone only application
the huge huge majority of phones runs Googled Android/iOS, so you support them
if there where a relevant 3rd party competition it would (most likely) supported it, too
going back to the "the president .. shut down .." argument: The US can shut down >90% of all smart phones used in the EU. I don't think the US being able to shut down something which in the end is fundamentally just a minor convenience feature is making much of a difference here.
But I also think that whole identity wallet (the regulations behind it) is approaching things from the wrong direction, carrying a credit card sized ID with you isn't really a problem or very inconvenient. So instead of having the whole attestation nonsense it would be more practical to simply not have attestation and in turn allow the digital ID only for usage where the damage it can cause is quite limited. Especially given that device attestation systems have a long history of being circumvented...
As a side note this whole app is distinct from the "use you ID with through your phone/NFC with applications" thing many EU countries have, through that solutions also tend to have attestation issues in most cases. But again most relevant use-case of it can be done just fine, without the security level attestation tries to provide, if approached pragmatically.
Have you seen our President? Minor conveniences are what trigger him into launching full blown DOJ investigations, wars, and economic disaster. If he realizes he can just "turn off" the EU, oh, he will threaten that on Truth Social tonight in a rant about how they should make a deal or else.
An open threat like that would be the best case scenario, as it would (hopefully) cause a reaction in EU countries trying to get rid of this yoke. Instead usually it happens through backroom dealings, or just the services being a nuisance to competitors while being helpful to friendly companies, and thus the target country is drained of its resources and economic independence, slow enough to not provoke retaliation.
With the exception of the current US administration, hostile countries and corporations try to appear non-hostile when possible.
Friendly advice: please don't capitalize random common nouns like the president does. It's a marker of one's affinity toward precision (among other things).
It’s not a proper noun, and this is HN: pedantry is par. “The president of Xyz” capitalizes the X in Xyz(pn) but not the P in president(n). However, the P in President(pn) is capitalized when it’s a Title suffixed to a Name - but that varies per country by what they title their president-equivalent locally and isn’t always translated, while the concept-slash-role label of ‘president’ in English generally does not (and is often used interchangeably, albeit somewhat wrongly, for ‘monarch’ and other such single-person executive-leader roles). (That we use the same spelling for both title and concept is annoying, as usual :)
The President, within this context, identifies a single entity. As such, it is a proper noun.
Analogy: there are many continents. But if we're discussing Brexit, the Continent is a proper noun. I don't think it's incorrect to not capitalise. But it's certainly gramatically okay, and not in the same bucket as The Nutters who capitalise Random words it Looks like Legalese.
...this isn't a counterargument. I can similarly assert you're justing making stuff up, which isn't untrue, either way, since we're talking about language, a wholly made-up enterprise.
What's your contention that the President, within the context of the American presidency, does not refer to a single entity? Is this a preference? Or something you actually believe is incorrect?
I have an internal convention to not capitalise LLMs when talking about them as if they were people; so claude is not capitalised, and the internal LLM-based service agent we're building, rex, is not capitalised.
I realise this breaks the capitalisation of proper nouns; claude is a name and therefore a proper noun and therefore should be capitalised. But I like that there's a signal in here that the thing I'm talking about is not a person and so we don't capitalise the name (I realise that cities or companies or other things that we capitalise are also not people).
Digression, but then so was the entire discussion on capitalisation.
Countries, companies, religions; hell, planets and galaxies–none of these are sapient. Yet we capitalise them.
I'll go out into the deep end for a second with a hypothesis: I think we capitalise because it makes printed text easier to scan. The words you need to spend more time on are capitalised because they aren't ones you can just roll through. This is also why the nutter affect of capitalising random words is so distracting–it drives attention to non-standard words that are, with minimum thought, being used perfectly standardly.
I completely agree with your hypothesis. And the ridiculous effect that Trump's random capitalisation has, both of making his text (even) harder to read, and of giving the impression that he doesn't actually know how to write English.
My additional hypothesis is that capitalisation accords respect, something along the lines of "this is a thing apart, something with a name, so we capitalise it". Not capitalising an actual human's name would seem disrespectful to me.
If you’re not, and I say this in good faith, take your own advice around your tone. Making assumptions about other people, and then doubling down when they correct you, comes across as a kind of horrible I doubt you truly are.
1.) No. It's another helpful tell. (And what do you mean 'anymore'?)
2.) I'm comfortable with varied comma stylization.
3.) My personal usage of the em-dash hasn't changed in a few decades and I don't see it doing so just because a bunch of folks only just recently learned it exists.
> having a digital ID wallet, that this needs hardware attestation (or something comparable) is somewhat of a direct consequence of existing laws/regulations regarding making IDs forgery safe
How do you figure? Isn't just having the digital ID be signed by a key belonging to the issuer good enough for that?
I think they are saying the signed ID can be copied to another device. Unless such ID needs to have acces to some TPM that can be trusted, which likely requires then specific trusted hardware and software
If something is actually important, don't put it on a computer. Don't let a computer be in the critical path of anything that actually matters. It's really quite simple. Even before "AI" this technology was not reliable enough for serious, important things--systems that need to be maintainable in adverse conditions (battle damage, etc), systems where failure is not an option (proving your identity, proving your children are yours, ...). If you care about your car, truck, tractor, or dozer being maintainable and reliable, don't get one with a computer in it. Until we can figure out how to make these things reliable and maintainable they're not to be trusted.
Gaming consoles typically have hardware attestation (as in verified software on verified hardware, sealed), and it has been broken many times in the past.
not just fiber, e.g. Netflix requires "only" (reliable) ~15Mb/s for a 4k stream, that means most people in most countries feel little difference between ~25 Mb/s and 1Gb/s in their "every day" usage. Sure it's a huge difference if you download a 80GiB AAA game, or preload a 4k movie. But in my experience (which definitely doesn't apply to all countries) a lot of non tech affine people don't do that that often an if they do it (e.g. movies before travel) they tend to do it over the night so it still works out just fine with not so fast internet.
So for a lot of people paying for more then 25-50Mb/s (pro person) makes only sense if it isn't too costly. Hence I rarely see people going for more then 250-500 Mb/s even iff 1Gb/s is available and they have money. And for non-gamers with little money, I mostly see them with ~50Mb/s (or paying for 50Mb/s but getting much less due to old wires :( ).
(Also IMHO The more important things compared to 1Gb/s is how much of the bought bandwidth is reliably available at all times _with good latency_...)
and people on very limited bandwidth and/or speed don't watch Netflix (or do so at most at 1080p) and if they watch netflix they are fine with clogging up their internet as it isn't some random backround download hindering what they want to do but what they are actively doing
and some fall under "micro optimizations I wouldn't be sure rust even wants",
and given how far the current async is away from it's old MVP state,
it's more like outright dishonest then overly dramatic
like the kind of click bait which is saying the author does cares neither about respecting the reader nor cares about honest communication, which for someone wanting to do open source contributions is kinda ... not so clever
through in general I agree rust should have more HIR/MIR optimizations, at least in release mode. E.g. its very common that a async function is not pub and in all places directly awaited (or other wise can be proven to only be called once), in that case neither `Returned` nor `Panicked` is needed, as it can't be called again after either. Similar `Unresumed` is not needed either as you can directly call the code up to the first await (and with such a transform their points about "inlining" and "asyncfns without await still having a state machine" would also "just go away"TM, at least in some places.). Similar the whole `.map_or(a,b)` family of functions is IMHO a anti-pattern, introducing more function with unclear operator ordering and removal of the signaling `unwrap_` and no benefits outside of minimal shortening a `.map(b).unwrap_or(a)` and some micro opt. is ... not productive on a already complicated language. Instead guaranteed optimizations for the kind of patterns a `.map(b).unwrap_or(a)` inline to would be much better.
most unsafe language to rust transpilations produce not just pretty terrible rust code but also use unsafe everywhere
which is needed, as making things safe often requires refactoring not localized to a single function/code block and doing that while transpiling isn't the best idea. In general I would recommencement a non LLM based transpilation (if possible) and then use an LLM to do bit by bit as localized as possible bottom up refactoring to get ride of unsafe code potentially at some runtime performance cost, followed by another top down refactoring to make thing nice and fast. And human supervision to spot parts where paradigms clash so hard that you have to do some larger changes already during the bottom up step.
anyways that means segfaults likely would stay segfaults in the initial transpilled version
zig can do some things wrt. compiler time compute which sits somewhere in between rust const expr and proc macro usage. This isn't something rust (or most languages) have. So even if we are generous and interpret line by line as expression by expression this isn't fully doable
but also telling a LLM to do a line-by-line translation and giving it a file _is guaranteed to never truly be a line-by-line translation_ due to how LLMs work. But thats fine you don't tell it to do line-by-line to actually make it work line by line but to try to "convince" it to not do any of the things which are the opposite (like moving things largely around, completely rewriting components based on it "guessing" what it is supposed to do etc.). Or in other words it makes the result more likely to be behavior (incl. logic bug) compatible even through it doesn't do line-by-line. And that then allow you to fuzz the behavior for discrepancies in the initial step before doing any larger refactoring which may include bug fixes.
Through tbh. I would prefer if any zip -> terrible rust part where done with a deterministic, reproducible, debug-able program instead of a LLM. The LLM then can be used to support incremental refactoring. But the initial "bad" transpilation is so much code that using an LLM there seems like an horror story, wrt. subtle hallucinations and similarr.
> So ciphers have to almost perfectly mix information.
yesn't
most modern stream ciphers basically use XOR for encryption with one time use keys per chunk (like. AES-CTR, AES-GCM, AEGIS, ChaCha20, etc.)
no mixing of bites is needed there just high entropy uniformly distributed one time use keys being generated per block, i.e. you need a "good enough" PRNG
practically the easiest way to get them is by doing something similar to a hash on the state(key, nonce, index) in some form. Which is likely done by mixing up information, hence the yes in yesn't.
but any PRNG with sufficient properties would do, and there probably are some which use some clever math which you probably wouldn't describe as "mix information".
It's just "shuffling bits" + "bad one way function" is often "sufficient" secure and faster then alternatives.
And historical many ciphers (e.g. AES block cipher) come from a time where we didn't yet had grate frameworks/know-how about how to assess security properties and write cryptography. Hence why they did all kinds of ways of mixing information and chaining which sometimes is quite.. arbitrary.
It might be easy to assume AES stuck around as it's "just grate" but that is plain wrong. It stuck around because it spread everywhere (including standards/requirements) before we knew how to best do things and due to that then ended up with hardware acceleration support on most chips. But no one would create it that way anymore (it is prone to side channel attacks if you don't have HW accl. xor use bitslicing trickery which makes it slow). But due to everything having AES hw acceleration it became a very fast building block. Hence why most modern cipher still use (part of) it and even some hashes and other algorithms use it... It's another example of how a "good enough" and wide spread technology often wins, not the best.
Mmm. It's true that stream cyphers do not need to mix information (of the plaintext) and block cyphers do. I'm not sure I fully agree with your comment, but I'm also not quite sure what you intend to say and it's late at night here. I'd suggest that anyone reading the above make sure they fully understand the different security properties of stream cyphers Vs block cyphers, before dismissing the latter.
Another big reason is that we use familiar terms, models to describe things. Often leading to very different things, being described in much less different ways. Also the simplified models often used for high level/very abstract explanations have the tendency that extrapolations you do based on them often end up wrong, in a subtle but fundamental way(* 1).
E.g. graphs, matrices, linear algebra systems, digital photos (and much more) can be all perfectly transformed into each other, or in other ways this are all different ways to look at the same data. (This is also not just hypothetical * 2)
As a side effect saying things are similar "because they are just matrix algorithms" is meaningless, because most things are "just a matrix algorithm". (It's also meaningful for the same reason, as it means you can transform many problems into such with well understood solutions.)
And the high level abstraction of "encoder -> state -> decoder" structure is another of such "too generic/meaningless" things. As state can be anything and encoding is just "process input to generate state" and decoder is just "generate output from state" wen can model most algorithms with that. Like the identity function is now `encode(input): state=input; decode(state): output=state` (and indeed as long as state is large enough wrt. the input (or unbound) you can train encode decoder network to do exactly that, as meaningless as that seems.
Similar you can treat everything as everything you have in cryptography itself: All of hash, PRNG, stream cipher can be easily(kinda, * 3) build from another and like most algorithms in existence they can be formulated to "consume data and then produce output", i.e. as encoder decoder pattern ;)
So IMHO it's mostly an combination of observer bias due to how we like to model things (in a very high level POV). And a construction bias from that and what computer can compute well (in a slightly less high level POV when looking at somewhat "arbitrary choices").
I know some of the examples here might sound a bit ridiculous, but it's some of the most important insights in CS:
- a lot of algorithms can be transformed (or modeled as) a lot of other algorithms, take advantage of it
- just because something looks alike, it neither means it is alike nor that it being alike has any deeper meaning (e.g. two graphs might look alike, but only for the subset of sample data you happen to use to plot them)
---
(* 1): Anything related to quantum physics seems be especially bad affected by it.
(* 2): you navigation system might navigate by mapping a navigation graph to a matrix and then compute on the matrix, where steps involved might treat it as a linear algebra system solved using some fast approximation.
(* 3): At least some of the conversion directions are easy. Some are a bit less intuitive. Also this assumes you either have perfect properties on the used building block or don't have to estimate how the imperfect properties map to properties of the created construct... Oh and naturally you can use some simple operations in the transformation (add, xor) as long as they are used in a straight forward way. E.g. PRNG(seed, offset) = HASH(encode(seed, offset)), with encode being a bijektive pairing function (e.g. `bytes_128bit_le(seed)+bytes_64bit_le(offset)`). E.g. for encryption you chunk, xor every chunk with a single time used key and generate the key using HASH(encode(key, nonce, chunk_idx)), or PRNG(encode(key, nonce), chunk_idx). That is how AES-CTR/AES-GCM does encryption. It (roughly) uses XOR(AES(key, encode(nonce, offset)), chunk). (Yes AES is more used like a hash then a block cipher in most modern AES ciphers...)
her reason wasn't some my tech shouldn't be bad people high moral ground but that she felt she can't do here work on here previous job anymore and the next job happened to be in Singapore, and the reasoning in order was also
- reduced funding / many projects getting side lined
- US moving away from decarbonization
- immigration policies discrimination against Chinese born people (even if they have left Chinese citizenship behind/are US citizens)
- and here not wanting to be put in a position where she is pressured to work directly on batteries for weapon systems like drones (!= general use systems being used in a military context)
so she chose Singapore because someone in Singapore presented here with a good job offer where she doesn't have to worry about this things
i.e. this isn't about the US being "evil" and Singapore being better, but about the US no longer being as good a place for civilian use battery production scientist
nor will anyone else, the point isn't about weather generic use batteries will be used for military usage, or that someone who licence the technology builds military focused versions
the point is they themselves didn't want to _explicitly_ design components for specific forms of military usage
and they no longer feel safe to not be pressured by the US to do so
but that isn't even the main reason for moving mentioned in the article which are (in order they appear in): reduced funding, moving away from electrification, immigration policies and then the previous point
-----
as a side note your comment did sound a bit like you think Singapore is China, in the unlikely case you did idk. mix it up with Honkon: it isn't China in any form it was
because it wasn't made
the decision which was made was having a digital ID wallet, that this needs hardware attestation (or something comparable) is somewhat of a direct consequence of existing laws/regulations regarding making IDs forgery safe
it also is a phone only application
the huge huge majority of phones runs Googled Android/iOS, so you support them
if there where a relevant 3rd party competition it would (most likely) supported it, too
going back to the "the president .. shut down .." argument: The US can shut down >90% of all smart phones used in the EU. I don't think the US being able to shut down something which in the end is fundamentally just a minor convenience feature is making much of a difference here.
But I also think that whole identity wallet (the regulations behind it) is approaching things from the wrong direction, carrying a credit card sized ID with you isn't really a problem or very inconvenient. So instead of having the whole attestation nonsense it would be more practical to simply not have attestation and in turn allow the digital ID only for usage where the damage it can cause is quite limited. Especially given that device attestation systems have a long history of being circumvented...
As a side note this whole app is distinct from the "use you ID with through your phone/NFC with applications" thing many EU countries have, through that solutions also tend to have attestation issues in most cases. But again most relevant use-case of it can be done just fine, without the security level attestation tries to provide, if approached pragmatically.
reply