On the contrary, this thread seems to have a large number of users who can't handle criticism of Wikipedia without responding with unfounded assumptions and insinuations about the critic
In high school I knew a kid who would go around looting loose change from unlocked cars. He'd pull the driver side door open like it was his car, hop in, loot the center console, then hop out like nothing happened. He wouldn't take valuables (as far as I knew), just change, so maybe a few bucks per car.
His rationale? "Nobody will cry over a few missing quarters and they are free to lock their doors anyway."
The reason it's not stealing is because the cost to the serve content is tiny (spare change) and the sites don't stop you from viewing it with ad-blocker (unlocked doors).
That's true, but the same may already be true of your browser's cookie file. I believe Chrome on MacOS and Windows (unsure about Linux) now does use OS features to prevent it being read from other executables, but Firefox doesn't (yet)
But protecting specific directories is just whack-a-mole. The real fix is to properly sandbox code - an access whitelist rather than endlessly updating a patchy blacklist
One could easily allow or restrict visibility of almost anything to any program. There were/are some definite usability concerns with how it is done today (the OS was not designed to be friendly, but to try new things) and those could easily be solved. The core of this existed in the Plan9 kernel and the Plan9 kernel is small enough to be understood by one person.
I’m kinda angry that other operating systems don’t do this today. How much malware would be stopped in its tracks and made impotent if every program launched was inherently and natively walled off from everything else by default?
I think this normalises running untrustworthy, abusive proprietary software, because they can at least be somewhat contained. The only reason I have apps like Facebook on my android phone is that I have sufficient trust in GrapheneOSs permissions.
Then, apps like syncthing become crippled as filesystem virtualisation and restrictions prevent access and modification of files regardless of my consent.
Not disagreeing with the need for isolation though, I just think it should be designed carefully in a zero-sacrifice way (of use control/pragmatic software freedom)
> But protecting specific directories is just whack-a-mole. The real fix is to properly sandbox code - an access whitelist rather than blacklist
I believe Wayland (don't quote me on this because I know exactly zero technical details) as opposed to x is a big step in this direction. Correct me if I am wrong but I believe this effort alone has been ongoing for a decade. A proper sandbox will take longer and risks being coopted by corporate drones trying to take away our right to use our computers as we see fit.
Wayland is a significant improvement in one specific area (and it's not this one).
All programs in X were trusted and had access to the same drawing space. This meant that one program could see what another one was drawing. Effectively this meant that any compromised program could see your whole screen if you were using X.
Wayland has a different architecture where programs only have access to the resources to draw their own stuff, and then a separate compositor joins all the results together.
Wayland does nothing about the REST of the application permission model - ability to access files, send network requests etc. For that you need more sandboxing e.g. Flatpak, Containers, VMs
In Wayland you have these xdg-portals that broker access to the filesystem, microphone, webcam, etc. I am not knowledgeable about the security model though.
Portals are used to integrate applications to the host if they're being run inside a sandboxed environment.
They are hooks that latch on the common GUI application library calls for things such as "open file dialogs" such that exeptions to the sandbox are implicitly added as-you-go.
They cannot prevent for example direct filesystem access if the application has permission to open() stuff, like if they're not running in a sandbox, or if said sandbox have a "can see and modify entire filesystem" exception (very common on your average flatpak app, btw).
portals are used by wayland, but you can also use them without wayland.
E.g. under X you can use bubblewrap or firejail to restrict access to the web or whatever for some program, but still give that program access to for example an xdg portal that lets you "open url in web browser" (except the locked-down program can't for example see the result of downloading that web page)
I believe Quartz is the go-to solution for this. It's not part of Spring but it offers a similar annotation-driven interface, but with distributed locking via a database
Absolutely! But Quartz is also quite heavy. If all you need is to ensure scheduled jobs run in a clustered environment there are more “lighweight” options
> This was the very first time I heard anyone even suggest that storing data in Postgres was a concern in terms of reliability
You seem to be reading "reliability" as "durability", when I believe the parent post meant "availability" in this context
> Do you actually have any concrete scenario in mind? Because anyone can make any system "considerably degrading", even Redis
And even Postgres. It can also happen due to seemingly random events like unusual load or network issues. What do you find outlandish about the scenario of a database server being unavailable/degraded and the cache service not being?
Presumably there's no legal reason why the ISPs couldn't write to all their customers giving "notice of upcoming partial internet service outage, due to the actions of La Liga". It would be factually true
Of course, LL could still give them hell in court even on false grounds (and maybe even win anyway, given the case detailed in the root comment). And in any case there's simply no commercial reason why they would stick their neck out in the first place
I think most of this are being done in the moment, without advanced warning. Plus, some ISPs carry soccer in their TV offerings so they’re probably not benefiting from speaking out. At least, my ISP does replace the blocked website with a notice explicitly stating that this is the result of a judicial ruling in favor of LaLiga
I suppose in theory you could have a device which doesn't have the storage or bandwidth to record/transmit full audio, but does some heuristics on the device and then transmits a small payload of flags. But in any case I wouldn't want to stay anywhere with an unaccountable black box ready to unfalsifiably charge me
The other commenter is absolutely right that partyers in AirBnBs cause nuisances for local residents, but the owners will have to find another way to sort that out or close up shop
If anything I'm worried that corporate security people will hear of "attacks" like this and blindly add "must use attestation with passkeys" to their checklists, and desktop computing will end up in the same state as mobile, where you have to have an unmodified OS install from one of a handful of authorized fiefdoms to log into your bank. It's a long way off, due to the amount of old laptops with no TPM about, but a plausible future
Edit: I may be misunderstanding the scope of attestation in a FIDO/Webauthn context. Is it a legitimate concern that it would lock out other OSes, or would you simply need a hardware key (or perhaps a TPM), but could run what you want above it?
> add "must use attestation with passkeys" to their checklists
We already do. Mostly from the compliance side: I can't call passkeys "phishing-resistant" unless I can lock them down into unexportable passkey providers only. Some more details from a previous comment of mine:
From a corporate compliance perspective, I need to ensure that employee keys are stored in a FIPS-compliant TPM and unexportable. Key loss is not an issue because we have, ya know, an IT department. The only way I can ensure this happens is by whitelisting AAGUIDs and enforcing attestation.
With these factors I can also get out of the MFA hellhole (because I can prove that whitelisted vendor X already performs MFA on-device without me having to manage it: for example, WHFB requires something you have (keys in your TPM) and either something you are (face scan / fingerprint) or something you know (PIN), without me having to store/verify any of those factors or otherwise manage them). Same goes for passkeys stored in MS Authenticator on iOS/Android.
>I can't call passkeys "phishing-resistant" unless I can lock them down into unexportable passkey providers only
I don't think this is accurate. As far as I know, no credential managers (except for maybe KeePassX) allow export of passkeys, and will instead only allow for secure transfer via the new Credential Exchange Protocol.
> secure transfer via the new Credential Exchange Protocol
If it's "transferable", it's not phishing-resistant (ie it's possible for a user to get bamboozled into transferring their keys to a bad actor), right? Regardless of mechanism.
You might've missed the "FIPS" part as well. This requirement effectively means the keys (or the keys to decrypt the keys) must be stored in a tamper-resistant hardware crypto device (read: your TPM) and basically no credential managers (apart from the first-party ones we have whitelisted) use the TPM for storing your keys.
> It's a long way off, due to the amount of old laptops with no TPM about, but a plausible future
TPMs can't create hardware-attested passkeys, at least they couldn't do that with the TPM 2.0 spec.
And you can just use a USB hardware token to get attested keys. Or you can use WebAuthn over Bluetooth to your phone, essentially using your phone's secure enclave (or its equivalent) as the key source.
Being able to require attested passkeys is a _good_ thing.
Except it means backing up or moving your credentials is somewhere between a pain and infeasible, and you're requiring people to go buy another device for little to no real security benefit. Every browser already generates strong random passwords that are tied to specific sites. They've done so for many years. Passkey attestation in a non-managed-org context is trying to solve a problem that's way past the point of diminishing returns while making things more fragile for users. You also can't really do attestation without having a blessed set of vendors (otherwise a software implementation could do it), so lockin is required.
> Except it means backing up or moving your credentials is somewhere between a pain and infeasible
That's the point.
> and you're requiring people to go buy another device for little to no real security benefit.
No. The benefit is clearly there: hardware-originated keys can not be stolen under any normal circumstances. Meanwhile, synced passkeys are just fancy login/password pairs, so they can be exfiltrated by an attacker. E.g. by scanning the RAM of the passkey manager.
Of course, the operating system can try to add additional barriers, but the underlying keys must at some point be in clear text form.
Right, that makes such a system unusable for normal people, so it is not a good thing to force it upon them. The benefit is not clearly there because anything that can manipulate local memory can also just use the key directly, or if there's some kind of physical button press required, wait for the user to log in and then do whatever they want with the session cookie or alter page contents or do anything else it wants. If the token doesn't display what it's authorizing (e.g. a yubikey), you could also watch for any usage, block that request to the device, and instead auth against their bank. If you need multiple button presses (e.g. they need to press again to confirm a transfer), say there was an error and ask them to try again.
Normal people are however not concerned with these Mission Impossible scenarios, and random passwords are good enough while being easy to use without an IT department to fix when it goes wrong. A password manager (which every browser has built in) already associates passwords to domains for phishing resistance. Users already should never need to enter a password manually unless the site did something stupid to try to block the password manager from working.
> Right, that makes such a system unusable for normal people, so it is not a good thing to force it upon them.
Whut? Passkeys work perfectly fine for "normal people".
> The benefit is not clearly there because anything that can manipulate local memory can also just use the key directly
Correct. But it does require fairly high level of system access. Hardware-bound keys also allow full hardware-attested authentication.
> Normal people are however not concerned with these Mission Impossible scenarios, and random passwords are good enough while being easy to use without an IT department to fix when it goes wrong.
If you're using truly random passwords, then you're using a password manager. And if you're using a password manager, then why not just use passkeys?
All the popular password managers support them: BitWarden, 1Pass, iCloud Keychain, even LastPass.
Passkeys don't offer anything above random passwords, and hardware attested passkeys obviously cannot work with a software password manager, which is the point.
Also like I keep saying, every browser already has a password manager. You don't need an external one. Notably though, Firefox's password manager doesn't support software passkeys, so they are completely unusable for me, for example. I'm certainly not going to sign up for some SaaS so I can use a worse version of passwords.
> synced passkeys are just fancy login/password pairs, so they can be exfiltrated by an attacker. E.g. by scanning the RAM of the passkey manager.
That’s an overly reductionist view.
Lots of password compromises still happen due to credential reuse across services, server-side compromises paired with brute-force-able passwords, and phishing/MITM attacks, and software-based WebAuthN credentials prevent all of these.
The spec tells websites to please not do validation on specific hardware. You can do a light form of remote attestation, but you'll have to convince the user to use passkeys only and not some kind of username+password backup, which is still a tough sell.
If you want remote attestation, Safari already has it, but I'm not sure if their attempt at standardising is going anywhere. It's been a while since the draft got updated or mentioned anywhere.
> If you want remote attestation, Safari already has it
No, Safari/Apple gave up on remote attestation when they introduced passkeys, except for MDM devices where the MDM profile can allow attestation for RP domains on an opt-in basis.
>except for MDM devices where the MDM profile can allow attestation for RP domains on an opt-in basis.
And even then, the attestation you get in that scenario is just an attestation that the passkey was created on a managed device. It is not a hardware/device attestation.
If this "attack" convinces security people of anything that just thinking through the FIDO/WebAuthN specs and threat model didn't already, I'd be concerned about the general quality of their work.
It is still almost always unwanted garbage though, which is why the specification says please don't.
We know from the Web PKI how this goes. People who have no idea what they're doing copy-paste a "good" list in 2025, but in 2035 the fact a third of vendors on that "good" list are now known villains and another third went bankrupt doesn't change the problem that stuff on the list works and everything else doesn't, because it was mindlessly copy-pasted
Narrowly, the vendor attestation could make sense if you're BigBank and you bought every employee (or maybe every customer, I wish) a FooCo security key, you can require FooCo security keys. If you're big enough you could have FooCo make you a custom model (maybe with your company logo) and attest every key is the custom model. I expect Yubico would sell you that product, if you were willing to commit to the volume. You get assurance of the exact hardware properties, and you retain the option to shop around by updating your software to trust different attestation. IMO not worth standardizing, but people really wanted this and better it exists but isn't used than it doesn't exist so they walk away.
reply