I think it's just because supply-chain attacks are not common enough / their attack surfaces not large enough to be worth the dev time... yet...
Sneak in a malicious browser extension that breaks the permissions sandbox, and you have hundreds of thousands to millions of users as an attack surface.
Make a malicious VSCode/IDE extension and maybe you hit some hundreds or thousands of devs, a couple of smaller companies, and probably can get on some infosec blogs...
Operating systems are different though, since their whole purpose is to host _other_ applications.
FWIW, MacOS isn't any better or worse for security than any other desktop OS tbh....
I mean, MacOS just had it's "UAC" rollout not that long ago... and not sure about you, but I've encountered many times where someone had to hang up a Zoom or browser call because they updated the app or OS, and had to re-grant screenshare permissions or something. So, not that different. (Pre-"UAC" versions of MacOS didn't do any sandboxing when it came to user files / device access)
Browser extensions also have a relatively robust permissions-based system.
If they wanted to, one would guess that browser-ish local apps based on stuff like Electron/node-webkit could probably figure out some way to limit extension permissions more granularly.
> If I break my house key I can know exactly where the broken parts are but I still can't unlock my front door.
This actually isn't true (it's exactly why digital 2FA is different!) If you break a physical key (already much less likely) you can still read the bitting (~ password) off of it. Bring the broken pieces to a competent locksmith and they can originate a new key for you. 2FA doesn't let you do this (intentionally, it's not a bad thing but it does mean recovery is harder).
> recovery keys any decent website makes you save or print out are for
Right, and almost all of the services that I still have on TOTP 2FA are not decently implemented... and do not have the concept of recovery keys (they are actually a somewhat recent inclusion in the setup process)! Sites that are modern enough to have made recovery codes usually also support HW tokens which I would've used instead.
See, this where the metaphor breaks down. At no point was the phone "lost". The 2fa tokens are perfectly safe yet there's no way to get to them... even though you still "have" the things, you can't prove you have it.
Which is why having 2FA _solely_ on a phone (like OP implies) is a bad idea. It's a fragile device that can easily render you unable to prove yoh still have it.
> I DO have to remember some passcodes which I otherwise never use but that's not too hard.
Right, but you're giving up a lot of security to do this, since it implies with these rare passcodes someone else could also bootstrap your logins.
With HW tokens, you don't have to worry about recovery passcodes being leaked/hacked (the recommended procedure today is to print out the recovery codes and destroy digital copies).
My point here is to note that "phones" are not a good 2nd factor, unfortunately, because they're not that durable and are kind of targets of theft. So moving to solely rely on phone sounds like a bad idea.
In my case, this was not the end of the world since I use a Yubikey for Google rather than TOTP, so at least my core email services (which represent a huge identity provider) were fine.
(This is also the reason why I could afford to wait to get parts and fix the phone rather than get into some panic mode of having all my digital accounts in a state where I might get locked out at any point.)
I do something similar but with other mobile/gacha game characters since those names are always in abundance. I also try to do some kind of correlation with the fictional settings too (groups of devices will correspond to meaningful in-domain names)
For non-mobile devices like workstations or servers, I also tend to directly give FQDN, like (name).(location).(my-personal-domain.tld)
The problem with cloud-sync-based managers like the iCloud Keychain is bootstrapping. Since you need to be able to log in to the services themselves to provision access to the passwords.
This makes travelling a bit risky, since it's not that hard to lose/break/have your devices stolen during a random trip. This makes it immensely hard to recover, since you cannot just hop onto a public terminal and authenticate (which might involve entering 2FA codes etc that you cannot get anymore).
This is why physical tokens are still quite useful. They're rather unattractive to thieves, don't require its own Internet connection to work, and they're relatively small and cheap so you can get a bunch them to stuff in various places increasing your chances of having one still available to you.
I had the misfortune of getting into a cycling accident which broke my phone display (completely lost display output and touch input), and it meant I lost access to all my OTP 2FAs for a couple of days (which is actually kind of scary).
I was able to fix it myself by getting parts and going through an ifixit guide (right to repair anyone? ;-), after which I promptly exported my 2FA seeds to (1) a backup phone (2) KeePass, which apparently supports them, who knew... and (3) a QR code on a printed piece of paper.
My guess of what will happen is if a service sets `rk=required` and you are on a platform that doesn't want to (or can't) enable/support it, the process would always fail and you wouldn't even be able to register. Which seems like a shoot-yourself-in-the-foot kind of move if the goal is to onboard users and get more business...
I wonder if there could be a middle-ground software solution here?
E.g. A piece of software (like a passkey manager or keychain service) that transparently simulates a resident key store by using an encrypted database that resolves services to credential IDs which are then forwarded and unlocked by a non-resident hardware key. One could then conceivably still sync the database around (using whatever services or method you want), and even if the encryption of the database were somehow broken, it wouldn't be the end of the world, as the actual signing is still done by the hardware key.
(Disclaimer: I don't know enough about the actual protocols to judge if the above is actually technically feasible, but would be curious if it is)
> makes it hard to figure out how users use a website
Isn't that the whole point? A user with the no tracking filters turned on in uBO is intentionally trying to opt out. I don't have much sympathy for site owners unless they also offer a first party opt-out option (which I've never seen so far even given the cookie banners). Site owners are no more entitled to track than a site user is to block even first party trackers. (Also wouldn't a site owner be able to use server logs anyways?)
As for defaults, I think when it comes to the point that someone is installing uBO specifically, they're usually sophiscated enough to configure filters. Most of the people I know (even those in tech) don't use any form of adblock or tracking blocking. (I don't know how they can manage to always be vigilant and avoid all the dark patterns, but to each their own.)
To be fair, housing and rental markets in some places are kind of pre-ruined. There have been plenty of (and doubtless will be plenty more) scammy landlords for short-term rentals.
AirBnB really just provided a modern online interface with some customer service stuff that papered over the bad stuff for a while. But like with actual bad construction, you can't hide the stuff forever so sooner or later the magic disappears.
To be fair, the last two are more from a bad design choice by *nix in general to base everything on passing around unstructured text and hoping each tool's ad-hoc schema won't change.
> The Coca-Cola Company sought ways to increase the five cent price, even approaching the U.S. Treasury Department in 1953 to ask that they mint a 7.5 cent coin. [https://en.wikipedia.org/wiki/Fixed_price_of_Coca-Cola_from_...]