This is also the rumor every time a crypto exchange is “hacked” and loses all of the stored crypto. It was never obvious if the people running the exchanges were incompetent or criminal, but I suspect it was a combination of both in many cases.
If you're set on doing some shit and know you won't be able to hide that it was done, arranging for it to be an "accident" is a pretty obvious ploy. Like, small children even do this.
But that can't demonstrate that there are no genuine accidents. Indeed, there almost certainly are, because people don't stop being incompetent just because some other people are malicious.
Much like there is 64-bit "code", there is also 32-bit "code" that can only be executed in the 32-bit (protected) mode, namely all the BCD, segment-related, push/pop-all instructions that will trigger an invalid opcode exception (#UD) when executed under long mode. In that strictest sense, "64-bit and 32-bit code can’t be mixed".
x86 has (not counting the system-management mode stuff) 4 major modes: real mode, protected mode, virtual 8086 mode, and IA-32e mode. Protected mode and IA-32e mode rely on the bits within the code segment's descriptor to figure out whether or not it is 16-bit, 32-bit, or 64-bit. (For extra fun, you can also have "wrong-size" stack segments, e.g., 32-bit code + 16-bit stack segment!)
16-bit and 32-bit code segments work almost exactly in IA-32e mode (what Intel calls "compatibility mode") as they do in protected mode; I think the only real difference is that the task management stuff doesn't work in IA-32e mode (and consequently features that rely on task management--e.g., virtual-8086 mode--don't work either). It's worth pointing out that if you're running a 64-bit kernel, then all of your 32-bit applications are running in IA-32e mode and not in protected mode. This also means that it's possible to have a 32-bit application that runs 64-bit code!
But I can run the BCD instructions, the crazy segment stuff, etc. all within a 16-bit or 32-bit code segment of a 64-bit executable. I have the programs to prove it.
Yes, but you transition between the 2 modes with far jumps, far calls or far returns, which reload the code segment.
Without passing through a far jump/call/return, you cannot alternate between instructions that are valid only in 32-bit mode and instructions that are valid only in 64-bit mode.
Normally you would have 32-bit functions embedded in a 64-bit main program, or vice-versa. Unlike normal functions, which are invoked with near calls and end in near returns, such functions would be invoked with far calls and they would end in far returns.
However, there is no need to write now such hybrid programs. The 32-bit compatibility mode exists mainly for running complete legacy programs, which have been compiled for 32-bit CPUs.
The separation is even in the URLs, all the locales are using paths, except the US, which lives under us.ovhcloud.com. All locales use a customer console hosted at ovh.com, except the US, which has it under us.ovhcloud.com.
You can't just spin up an LLC and call it a separate company. OVHCloud is still OVHCloud US' subsidiary company.
From the FAQ page I linked:
> In accordance with our Privacy Policy, OVHcloud will comply with lawful requests from public authorities. Under the CLOUD Act, that could include data stored outside of the United States. OVHcloud will consider the availability of legal mechanisms to quash or modify requests as permitted by the CLOUD Act.
I think we'll see a lot of companies moving away from public cloud providers in the future, but I don't think it'll be because of any privacy-related concerns.
It rarely makes economic sense to deploy workloads onto the public cloud unless you have critical uptime requirements or need massive elasticity.
FISA and the Stored Communications Act as modified by the CLOUD Act don't distinguish between (i) parent company overseas + US subsidiary and (ii) parent company in US + foreign subsidiary. In both instances the US asserts personal jurisdiction, extending to wherever the data is stored geographically.
The US by and large can (and does) assert authority outside of its jurisdiction, from which another country can choose to capitulate.
Most of the time countries do, because they are all swapping data on their citizens between themselves to skirt various laws.
In the case where the US really wants something, and the country won't yield, they'll fund contras or destabilize the government (if small enough to be bullied) or impose sanctions so drastic it's effectively a soft act of war.
This is all to say that, the US has nearly unlimited authority while it stands as the world's defacto superpower.
If the violent, untrustworthy, Americans choose to go to war with their former allies over some data then that's their choice. Better than just giving these warmongers everything they want.
Not entirely crazy narrative from Apple either. The "leaks" brought a massive boost to his channel. We've seen YouTubers do crazier things to get attention before. Will be interesting to see how this plays out. Wouldn't be surprised if it just gets settled out of court for an undisclosed amount though.
I would think the logic runs exactly the opposite way. Browser diversification would make not using chromium the good thing, rather than not using gecko.
AFAIK, McDonald’s does this with their mobile app (they weren’t letting me log in with my password) But the problem with their implementation was that the magic link that they send you is wrapped in a click tracker whose domain is blocked by pihole (and the likes), and I could not reach the actual auth URL to complete the login process.
A more sensible thing that should've been done is to tokenize the case ID so that you can't just guess it with a numerical range. Also important that you don't leak your key business metrics (# of support cases over time).
