If a US company is actually based in Ireland, then it's not a US company. That's an Irish company.

Some US companies have offices in Ireland. That's to take advantage of Irish tax policy. Their headquarters are still in the US. The decisions of the company are still made in the US. They are based in the US. Those are US companies.

Okay then, that was always allowed.

EU regulators were perfectly capable of blocking any US purchase of EU companies at any time. They were perfectly happy taking US money all this time. It's ridiculous to now complain about all that money the EU earned.

Still as a American, I shrug. Europe should have been allowing, recommending, and actively promoting the creation of their own software their entire time. I think it's great that Europe is finally deciding to truly compete in technology.

The whole thing reminds me of Jerry walking out of the daycare in Rick and Morty. Yes, that was always allowed.

Europe always had the capability and opportunity to create European alternatives to US technology. There was never anything stopping them from going that route at any time. In fact, I welcome this work as an American. As a consumer of technology, I'd love to see some alternatives to the US technologies I currently use. Why Europe is approaching this as some flex on the US seems a bit ridiculous to me. This was always allowed.

Long term, there won't be many working on leading edge who deal with the USA government...

Have you seen Trumps plan to destroy research in the USA yet?

https://arstechnica.com/scienc...

That is really going to perform badly, especially if you ever update your computer. Will MS actually improve for a change due to the RAM crisis going on??? Maybe Edge will improve on RAM use over google trying to replace the OS with Chrome?

I have an M1 with only 8GB of RAM and it works surprisingly well within that limitation. I don't do serious work with it but my casual use is beyond a typical office worker; plus I have two accounts that are often active each with a browser open. I might wear out the SSD early with swap usage; guess I'll find out.

Look around. I think i've seen stuff that does Time Machine out there. I don't know how much longer apple supports network Time Machine servers... they are dropping Intel emulation soon so all your old apps die. Unless you have a windows version of the app and an emulator. No, you don't need to upgrade old software, not everything needs internet or exchanges complex data files with the outside world.

usually an American. We have our version of "Americans" within America, they live in Florida.

There is no reason to pay attention to wireless ID names or t-shirts... where are the rational adults? Simply because somebody makes a joke the brains all turn 100% off and they act like robots... except by the time robots are running things, it's likely the chatbot will not be so stupid as to over react like this.

Even a small child knows to lie about sneaking a cookie they do not openly eat the thing when they are not supposed to have it. Unless they their parents are trying to raise an orange monster who flagrantly ignores the rules.

I swear America only has an average IQ because a few of us are raising so high it makes up for 60% being dumb as shit (oh, and many high IQ people are immigrants.)

I won't say it's provably random or very strongly random especially with recent news about a new random generator claiming to be fully and completely random... I'm being vague. It's random enough that you won't have enough of a pattern in the noise to detect the user's web app because of access patterns that are so consistent that they can be detected. Are you thinking of access patterns that are not merely detecting the contention of your process's access of the device?

That is what I'm thinking about. You think contention timing is not impacted by seek times? Rust discs don't store files in the same physical location all the time, they are not always fully defragmented, the databases powering operations may append and update not just overwrite the same location.... but other tasks are also not using the same data in the same location. Fragmentation has serious noticeable performance costs because of the TIME required while SSD has almost consistent random access (not perfectly but practically close enough.) You don't know how it's going to seek on every device. The underlying FS and OS implementation are more abstracted and different for a browser than an app that runs on 1 OS with likely just 1 common FS being used. Sure back in the day when you only had 32 tracks you could maybe even hear the difference ... certainly you could between a 1 track shift verses a 30 track shift! The small amount of data on your floppy and for some programs really could end up using the same locations... and there were so few available anyway and allocation patterns were likely linear...but then heavy fragmentation could make it really slow over heavy usage too. Still could be predictable since people did only 1 thing per floppy. 1 program at a time as well... I certainly could detect patterns in the sounds...a few programs had cool hacks to make sounds with the floppy drive... but direct access was not uncommon. Here we are talking about many layers of separation and it still working because of the lack of noise in those layers. I'm just saying that I think the old storage and FS add too much variation.

I doubt this is beyond human statistical analysis; it's just not been worth exploring labor wise?? Or maybe it is because people DID try and never published a failure paper since there was nothing interesting to publish about them not finding a detectable pattern due to the noise. I would guess it didn't work with the underlying noise. I can't see why nobody thought of trying since timing side channel attacks are old and anything you can measure time on has risk. Storage is way slower than other attack vectors previously demonstrated so it should be an easy target.

The worst bugs are contextual misunderstandings. Technical help can't avoid this. It's in the same world of legal contracts and laws; tons of problems without technology, it's a human problem. Specifications issues, communication issues, understanding, lack of predictability, foresight, experience etc. add in technical issues and it gets worse but removing all tech issues the rest still remain. The more complex the tasks you need to automate makes for more problems; you can force multiply but then you free up harder problems to address in what seems to be unlimited number of problems. The risk is that we run out of problems we want to solve because we're good enough and who's motivated to figure out harder things without enough benefit. Outside of nerds who like Star Trek, continue to work when there is no longer a need to do anything.

C has evolved. but not enough. too much resistance.

What Rust needs to do is pressure C to evolve features that negate the need for Rust. AI can make the compiler smarter if you limit it's reach so it's not generating code and replacing compiling. The fact C is so stubborn that it is under real threat of becoming irrelevant and only an entrenched legacy language is a bad sign. Cobal on the other hand, has a stronger case for being relevant but it's been pushed out so it's not like rationality is what guides our industry. (I don't like Cobal, but it's purpose is for non-programming experts to code bureaucratic logic. Nobody's created an evolution in that direction outside of AI translating legalese into flawed code. Perhaps those flow chart languages of the past were correct but simply couldn't appeal to the programming nerds and they've had too much influence; I think I may have been wrong about them as I was for Cobal. It's not all for professional programmers and shouldn't be and AI is going to force us to realize this as it makes automation accessible to experts outside the CS domain.)

I think C should remain the foundation for everything but it needs to evolve developer support and stop burdening them with doing everything without help and without crutches. The underlying compiler being implemented on every chip as the boost strap for everything else is fine to continue... but they need to add more support before Rust (and it's needed unprotected code features) replaces C as the foundation; this will take at least a decade likely even with AI helping translate the C code, but could move faster. They can't just sit around like they have been doing. They are moving too slowly and now risk of big changes is a sign they weren't moving fast enough previously; it becomes bigger and more risky the longer addressing the problems are delayed.

Spinning rust is random. Allocation is not consistently done so seek times will differ wildly; caching will bring that into line with SSD except you can't control caching so that greatly limits the window of opportunity to exploit that.

The problem is high precision timing being applied to everything and what is impossible today may become possible later.

You are correct in that the larger view that running code is the problem and everything has some CS fool trying to add code to it... fonts, PDF, CSS, and I'm still expecting Unicode to add some more BS someday given how much they've overly complicated what should be a simple text encoding format.

Caching timing I'm sure works as a data source as well. Anything with high precision timing is subject to profiling and AI allows for automated deep statistical analysis that is too costly to power by human experts. The problem is access to high precision timing not imagining everything that might be too uniquely consistent... user or web apps/sites users visit. Spinning rust made this too random before SSD. Network bandwidth and latency shifts are far too random now to imagine that as a risk but maybe not forever (think of caching measurement.)

We CS people have a real problem of making everything programmable. Just can't stand being limited to data... even our FONTS are Turing complete now and a push to standardize crazy CSS features that create a threat there too. I'd not be surprised if unicode isn't at risk of having it's decoder running Doom in some convoluted form too... PDF and HTML were supposed to be an output format not another software platform. Note- I realize that had HTML not added automation it might have died off before adding scripting; it's inevitable it would add scripting because eventually some CS person will have to add it to anything they work on long enough.

I'm annoyed I didn't think of it... or that others haven't years ago. The reality is that many of us would have thought of it right after the 1st javascript timing attacks were possible long ago but we were not tasked with thinking about timing timing attack fingerprinting; it was just an interesting attack to read about back then. People who were tasked with countering the attack should have addressed ALL these issues by now - I'm upset that those people did not do their jobs! We assumed that people in those roles would be applying the knowledge of the technique more broadly... that is truly disappointing.

If I tried to solve the issue; as many of us would, we'd consider precision timing a security risk on every operation performed. The ability to do precise timing would be the 1st feature to remove and then provide exceptions such as how microphone/camera or privacy modes handle similar risks. Imagining every possible API that could be exploited at the time is inherently flawed by the tech at the time and the imagination of the engineers involved... the reason we have sandboxing etc. to cover the imperfection of our imagination of the future possibilities. SSD is a great example of tech changes that opened up new pathways previously not imagined; spinning rust has more randomized seek times outside of the cache.

Simply measuring timing of API security denials could be another fingerprint... anything you can precisely time.

Few things in life are clear when you get into the weeds of a subject. This is why real experts and professors are so hesitant and undecided while blowhards are so confident... sadly the majority of people in the USA judge leadership and competence by how confidently a person presents... maybe chatbots will change this perception if they keep up their overconfidence?

My experience is that productivity gains overall are more harmful that people realize because it's long term, usually more in-depth or complex to spot, and unpleasant which is demotivating or optimism bias blocks out the effort/consideration. It's also easy to cherry pick outside things such as going outside of the job losses into other jobs created; such as, creation of IT dept. and staff going up while other jobs disappear or change/stop growing. Sure, you can do more because it is now viable - should you choose to do so and generally that produces more gains than reducing staff. It doesn't always result in productive gains-- eventually, years later when that extra labor is ruled out as non-productive the connection is not made as staffing goes down; especially, when staffing stays the same but does not grow proportionally because it's a soft staff reduction by limiting staffing growth.

The whole mentality of today's business is to reduce jobs; capitalists never are job creators, they begrudgingly are forced to create jobs by necessity only and their goal is to eliminate top overhead costs to compete. The larger role in society of providing gainful employment is hardly even contemplated from the look of it. This is where regulations are necessary to set the rules of the game to constrain the fire that drives the engine. It'll burn everything it can and is very useful, if not necessary and will find every way to keep burning - we fear too much about burning out and not getting started again. To be safe, it has to be strongly contained and respected for it's danger not worshiped like a pagan god (which it is in the USA, for generations now as the #1 true religion -- Trump reflects the deeper "soul" of the nation, the world is seeing this.)