oneplane

This is about the bank. You get a service from the bank. The bank has to make a trade-off which services they want to provide under which conditions.

Somewhere, 100 steps later, you might get to a "which OS on which hardware" aspect, but that's so far removed from normal life for the meaningful customer base that unless you want to stretch the scope of the post two orders of magnitude bigger than it is, it's not even close.

The bank makes a tradeoff, usually based on money: if they lose 5 customers because they can't use a specific app on a specific OS on a specific piece of hardware, they aren't going to care.

You can apply that to most businesses, especially the profitable ones. You shouldn't be surprised by that.

Could be general polarisation, or just that it's a "but in my case it is different" visceral response.

While people might not be moved by data, it would be interesting if some more public information on what people actually use was available. Imagine data points like unpatched/unpatchable iOS or Android devices being multiple percentages, or outdated browsers. Similarly, the effort per app/OS combination; if it costs X to support Y configuration, then it would be somewhat easier to see if it's more about the will to do anything rather than real-world problems.

> blanket restrictions on everyone's freedom

The scope is much smaller than that: restriction on what banking conveniences are provided.

> Most of us understand the desire to protect customers from fraud > At some point, the cost of preventing additional fraud, including the loss of individual choice and autonomy, exceeds the benefit > Could we aim for proportionate

I think you have answered your own question here; if a less than single percentage of retail customers use something that's not a general iOS or Android device, anything beyond that is not really worth it until regulation says otherwise.

You might be overthinking it. Most people want to use their phone for convenience, and if an app allows them to remove just one step in their banking activities, they'll probably do that.

As for the second part (separate authentication methods), sure, would be rather problematic if they require you to have a phone, but that's a completely separate and different issue.

Some of this stems from the idea that everything can be reduced to logic, so as long as we solve for all logical states, the end result will be perfect.

Of course, the second you start interacting with the real world and with humans, that doesn't really apply anymore and you have to get to 'good enough' much earlier than a generator would be able to predict.

Even if you steer a model to a very specific goal with an easy to validate end state, it will do things that within the scope and context of the goal a human would not really do. In theory if you put the context of the entirety of a human into a model, you might be able to get much closer, but we don't even have enough power generation on the planet to process that (unless someone has a secret ten orders of magnitude more efficient way of doing that).

They still have webkit builds for Windows and Linux etc, and you still don't need to buy anything special to run it. I think they also have a (mostly?) headless one, and a mini-browser which is intended to test the engine (so it doesn't have things like bookmarks or profiles or anything like that, a good fit). Similar options exist for FireFox and Chromium so it's not really a Safari/Webkit special. Usually gets used when you use a standard containerised browser testing CI step.

Either way, if someone is still manually testing their website instead of using a standard automated testing system you're probably not really in a league where this matters anyway.. and if they are, you probably have a device farm already.

Not sure where the "my thing is so important, I have to test it on a real device, but I can't pay for it" niche is.

You can assume that any company at a large scale will not want to divulge any information unless absolutely necessary. Doesn't matter if you or I think that it might not need to be secret or might not be competitive. Unless there is both an internal push, a need and a sort of proof dat the information can be released, it will never happen. You'll usually find thing that are simplified or aggregated for PR and marketing, or things that are required for legal reasons, but everything else stays internal.

I don't think so, the XNU and macOS LS architecture doesn't assume you're going to do policies based on the internal memory topology of a process. It's usually done with multiple processes and having one be very constrained doing only some very specific calls and the other not being able to do any calls at all.

You can probably get by with mprotect or mach internals, but if you're developing at that level you've probably already either implemented or dismissed that.

It's a bit of a different architecture with PAC/MIE/APRR (and to a degree AMFI) being used to prevent abuse that would require syscall filtering in the first place. While I personally don't think that's airtight, it does appear to work out well for their ecosystem.

Edit: come to think of it, region-based call filtering is never really going to be enough on its own, if you don't combine it with other techniques it's basically a rop gadget fest. Probably also why SBX went for intent rather than trying to do it based on location/origin.

Windows has virtualisation based sandboxing and NT has object-level security (albeit not often used correctly and granularly) and macOS has (among other things) SIP and a subsystem called sandbox that does exactly what it says: it sandboxes. It can sandbox in comparable namespace terms (like cgroups v1 or v2, but more in translocation style execution since it's a MAC framework) yet it also does it a much more fine-grained level depending on what you need. It is used by launchd and applications by default, some entitlements require it so if you want to do some broad kind of elevated application, you also have to have a specific sandbox profile. It's also been around for 16 years, and comes with a ton of examples if you wanted to use it yourself to constrain some process. Yes, it can do filesystem (would be pointless without it), but also does ipc, io, network, memory, fcntl, sysctl, mach ports, sys calls, processes, ui, sockets, messaging, events and all of that including context-aware filtering and compound matching for all of them. And if that's not enough there is also ESF and NEF, the latter only working on networking. You can compare those two to eBFP LSM and XDP. If you want all of this on linux, you'll need to add a lot of custom eBPF and LSM as well as always run in a hypervisor for guaranteed IOMMU usage, but you can't use bare KVM for that either, so you'll either need to never touch the privileged kernel (not even give it a console) or you need to run Xen and use XSM.

Flatpak is just a cheap container copy. Can't do anything beyond what cgroups and things like apparmor and selinux can do, and uses a runtime to do soft higher-level policy functions that translate down to the same primitives. If anything, it's a great bundler, but doesn't do anything new policy-wise.

So, can you get the macOS-level capabilities (both low-level and higher abstractions)? On Linux, yes, but they don't exist yet. On Windows: technically possible, but since that would break most GUI workflow it's not likely that anyone is going to bother, and you're going to have a hard time recompiling windows yourself to make that happen.

It usually does, in this case as well since it's SPL.

It's been extensively reported on, and any AWS user that clicks on the health dashboard would also have seen it, even if they don't consume from news outlets.

As for use it gets: plenty of use, mostly when someone needs to have their worlds close to that area (usually latency or legal reasons). There are a lot of smaller businesses that lost a lot (or maybe even everything) because their never thought they would need to create backups in a different region. Most of that wasn't really reported on but instead gets shared on various platforms like Reddit.

How is it crazy? It's perhaps not granular (the repository is the boundary, and that's that), but you can definitely restrict who can pull or push as easy as you can make rules for SSH.

Plenty of not-very-granular "enterprise" systems out there, it's not exactly unique to not always have full ACLs on the smallest of objects.

What are you even talking about. Every M1 Mac and earlier runs Linux. Even all the way back to PowerPC.

Granted, the M1 and up are not 100% covered yet (driver-wise), but they aren't EOL either. And if they were, Linux would still run anyway. Take a 20 year old Mac and you'll run Linux just fine. 10 year old Mac, Linux still runs fine. Take an M1 and it's a joy to use with Linux. Taken an M2 and it will boot and you can be pretty sure it will run very well long before it's EOL too. And even if it's EOL, it's not going to prevent you from running Linux later.

As for the PC example: definitely EOL problems there. Try getting your EDK2-based UEFI stack patched on an old computer. At some point you won't be getting certificate updates and if you either forget to install a local override or if the vendor didn't add it, you're SOL, especially on laptops where you can't disable secure boot.

Since SIP, it's MDM with DDM and you can basically leave engineers be local admins as it has no impact on the system state anymore.