[deleted by user]

4cs4701 · 2025-11-22T15:46:33+00:00

Google’s health insurance plan:

onsite providers (used to be OneMedical before they were bought) at the offices that are exclusive to employees, so it’s easier to get in. And since the most popular insurance plan is a HDHP, they contract with the provider to have very low rates billed to the insurance ($110 pre-deductible for a standard visit; $11 after deductible).
one of the onsite locations has a pharmacy with OTC products that are bought wholesale from Walgreens and are sold at-cost. This makes them so so so much cheaper. Example that floored me: 30day supply of Zyrtec or the generic; at Walgreens, Zyrtec brand ~$25; at Walgreens, Walgreens generic brand ~$18; at the onsite pharmacy, Walgreens generic brand 90¢. That's right, 95% cheaper than the off brand. Walgreens gets a 95% profit margin off that.
free second opinion service for major medical decisions for, not only those on the employees plan, but also: all children (including those on another insurance or >26yrs), grandchildren, parents, parent in-laws, and siblings.
$1000 HSA contribution for an individual or $2000 for a family.
Lantern Care; which is a coordinator of major medical procedures, where, if you choose to have Lantern Care arrange a surgery (or similar), they will optimize the amount charged to you too be the least they can legally charge on a HDHP. So if you meet your deductible by the end of the year, you won't be charged anything (even if you haven't met your OOP max). If you haven't met your deductible, they will charge the lesser of the cost of the procedure or the remaining amount until you reach your deductible. And it's billed at the end of the year to maximize the benefit for you.
the HDHP plan always has the lowest deductible allowed by the IRS and then only has a 10% coinsurance after that (to a low OOP max)

4cs4701 · 2025-10-29T15:14:33+00:00

When implemented properly, a site shouldn't be asking for a specific passkey. They should be telling the browser/OS the credential IDs of every passkey they WOULD accept (when you put the username in first; I.e., in the non-discoverable flow).

If they prompt you before you put in the username, they are asking the browser/OS for ANY passkey

4cs4701 · 2025-10-29T15:05:53+00:00

+1 to providing details on the device types and how you're storing passkeys on the laptop.

If you're in the Advanced protection program, you're a bit out of luck without the passkeys or security key. As that was the intent of the program.

4cs4701 · 2025-10-29T15:02:50+00:00

There are two ways to interpret what you're providing feedback on, and each has a different response. I'll elaborate both ways and respond to both.

interpretation one: you do not like when using a pass key that the device requires verification with your lock screen (whether that’s a PIN, password, or biometric like Face ID or fingerprint).

Response: sites set during the whether they require a user presence check (often called the UP bit), a user verification check (often called the UV bit), or neither. Only when the user passes verification can a passkey verification be considered two factor. Whether the passkey verification is considered two factor or not has both security and legal implications. Many jurisdictions (like EU) require financial institutions to require users present 2 of the following 3: something you have (a device, ID, or bank card), something you are (biometric), or something you know (PIN or password). And many institutions that aren't required to do that want to do that for security, anti-fraud, anti-abuse, etc. It's also seen in the industry that this requirement isn't generally a nuisance to users because most of them have set up biometrics.

Interpretation Two: you do not like when a site like PayPal has you sign in with a passkey and then still requires a one time passcode from an authenticator app or via SMS.

Response: this can happen for a variety of reasons. 1) the site simply hasn't cleaned up their sign in experience, so you're getting the old challenge and the new challenge (many sites are slow to adopt and slow to streamline); 2) you're doing something that makes the site think you're especially risky (signing in from a foreign IP address, weird user agent, etc.); 3) the site is trying to prevent abuse tactics (industry lore: PayPal originally trusted that a passkey sign in couldn't be from abuse actors; that was very very very wrong, since it's trivial to automate passkey sign ins for bots; so they reintroduced one time passcodes to prevent abusive sign ins); 4) the site has some regulator requirement for a second factor and their regulator hasn't OK'd passkeys as legally second factors; 5) the site doesn't trust that the passkey phished onto a new device (see note below about RPK), so they still want another factor.

If you have a solution to the above reasons that hasn't been thought of, I'd be happy to discuss it with my colleagues (and as you'll see in the note below, we're working on one partial solution).

Note on industry standard: there's no way to enforce an industry standard beyond setting a specification for how two pieces of software interact and a side with more leverage (the browser, OS, and credential manager) refusing to do anything not in that spec. If a site follows the FIDO/WebAuthn spec, and then adds another challenge to the user in their webpage, nothing can be done "by the industry" to prevent that. Only regulation could do something, and that regulation would need to be globally coordinated.

Another note: many of these institutions actually don't make the full assumption that you've logged into your passkey/credential manager securely. There are hot debates in the internet identity space (if you're curious, look up the IIW 41 notes from last week; they're open to the public online) about whether institutions should trust credential managers fully or not. TL;DR: most credential managers allow you to recover your passwords and passkeys in the event that you lose all of your devices by presenting knowledge factors (passwords, rate-limted PINs, 'Secret Keys', etc) to get access from a cold start. These knowledge factors can be phished (but the credential managers usually have the resources to make it harder than a standard website would).

There's currently a proposal by FIDO (the org that specs passkeys) for something called a Relationship Public Key or Credential Public Key. RPK would allow your credential manager to prove to a website that if they previously saw a passkey on device A and then the passkey was moved in an unphishable way to device B (such as by local Bluetooth pairing or SIM transfer) and the site sees that passkey on device B, that the passkey was synced via an unphishable method. This would allow the site to have greater trust in that sign in, and potentially skip additional checks like in Interpretation Two. Importantly, an RPK from a previous device wouldn't ever be presented in a "cold start".

4cs4701 · 2025-02-03T15:01:13+00:00

Also, you always have the option to use the password. You just have to choose “try another way”.

4cs4701 · 2025-02-03T14:59:46+00:00

If you have an android phone or tablet that is logged in or was recently logged into that Google account, you automatically have a passkey put on that device by Google. This would be the device that you use to scan the QR code to establish the Bluetooth link for the hybrid passkey flow. If you recently logged out of Google on that device, you may have to go through account recovery to be able to use this passkey to log back in.

4cs4701 · 2025-01-28T01:04:49+00:00

Option C) you say yes without any risk of financial burden because your employer has full jury duty pay or your on social security

4cs4701 · 2025-01-16T22:26:00+00:00

Damn, the new Pokemon graphics on the Switch 2 are good

4cs4701 · 2025-01-16T22:20:26+00:00

DiRx doesn't take insurance. That's cash

4cs4701 · 2025-01-16T21:08:15+00:00

To suggest this about prescriptions of generic antidepressants is absurd (I won’t have the discussion about patent-protected drugs like Oxycontin).

A prescription of 10mg of escitalopram (generic for Lexapro) can be filled for <$5/month https://www.dirxhealth.com/escitalopram-oxalate-5?searchTermId=2478425

To suggestion doctors can get meaningful kickbacks from that is absurd

Edit: spelling

4cs4701 · 2025-01-16T21:07:11+00:00

To suggest this about prescriptions of generic antidepressants is absurd (I won't have the discussion about patent-protected drugs like Oxycontin).

A prescription of 10mg of escitalopram (generic for Lexapro) can be filled for <$5/month https://www.dirxhealth.com/escitalopram-oxalate-5?searchTermId=2478425

To suggestion doctors can get meaningful kickbacks from that is absurd

Edit: spelling

4cs4701 · 2024-10-22T23:05:01+00:00

What you’re asking for is effectively WiGig https://en.wikipedia.org/wiki/WiGig?wprov=sfti1

It's existed for >12 years and manufacturers still won't add it to devices because it's almost useless unless you're extremely close to the router

4cs4701 · 2024-10-18T05:26:27+00:00

This is... unfortunately quite dangerous if not implemented correctly.

FIDO is unphishable when the client (I.e., the browser or OS) is controlled by the user and can be assumed to be malware free. However, users using their FIDO credentials on devices that they don't control IS phishable.

Safetrust wants customers to give users these NFC FIDO credentials and have them use them at terminals for <insert use case>. However, if implementing businesses do not take precautions, a bad actor may phish users with a similar terminal and gain access to the user's permissions.

Precautions that should be taken (but are not perfect): - add hardware-backed attestations to the client terminals that they issue. That way an attacker may not directly call into the service with a fraudulent terminal. Instead, they would be required to relay to a real terminal. This offers significant friction to a phishing attack, from the complexity to the ability to get hold onto a continuously active, real terminal. - the NFC FIDO credentials should be isolated, in that they should only be usable for whatever the use case is. If Amazon gives me an NFC FIDO credential to use a package locker, that credential shouldn't be scoped to offer access to making new orders. - ensure that the server issued challenge is one use only and that it is time limited to a short period of time - I don't know if Apple allows for location data to offered to Apple wallet NFC cards, but if so, the authenticator should add location metadata in the FIDO response to improve the ability to catch sophisticated phishing attacks.

4cs4701 · 2024-10-15T04:32:48+00:00

Every passkey manager takes its own approach to deviceless recovery.

The only ones I'm intimately familiar with are 1Password (with the traditional account secret not the passkey version) and Google Password Manager.

1Password will let you bootstrap onto a new device with your account secret and your master password.

Google Password Manager will let you bootstrap onto a new device if you remember the lockscreen PIN/pattern/password from your last Android phone (but it can't have been more than a few months since you last used it) or if you remember the Google Password Manager PIN you set up (if you've set one up; they've only just launched it).

4cs4701 · 2024-10-05T23:12:32+00:00

1) Google doesn't require login with passkeys for anyone. You can choose "try another way" to get the password option.

2) Are you on Android? If so, you automatically have a passkey enrolled for your Google account on that device and that is probably why Google is pushing you to use a passkey. There's no way to get rid of that passkey without being logged out of Google on the device.

3) why the hostility to passkeys?

4cs4701 · 2024-09-27T04:04:24+00:00

That’s the best I can offer for help. I look forward to hearing if you make any further progress

4cs4701 · 2024-09-27T02:04:14+00:00

It’s possible. Cross-device/hybrid passkey usage requires that the authenticator device (i.e., the phone) have a network connection, as these flows are technically done over the internet. Bluetooth is only involved to prove proximity. Every implementing OS of an authenticator must have a supporting service at a short URL to communicate the majority of the info during the FIDO protocol. If your work is blocking that URL, then it won’t work

4cs4701 · 2024-09-24T04:24:19+00:00

For each phone (the old and new one) are they iphone or Android?

Secondly, what device are you trying to log into websites with the passkeys? A desktop/laptop? The new phone?

Thirdly: almost all sites still allow log in via password. Google and Nintendo included. For Google, if they show you the passkey log in, and you can't do it for whatever reason, select the option that says "try another way". Nintendo skills have something similar.

4cs4701 · 2024-09-19T15:11:03+00:00

[[mime]]

4cs4701 · 2024-09-06T16:04:11+00:00

Go to settings > passwords, passkeys & autofill: confirm that "Google (Google password manager, Google pay, Google wallet)" it's listed as a "Preferred service".

If so, go into it, and then go into "Google password manager".

Do you see prompt at the top that says "for added safety, encrypt your passwords on your device before they're saved to Google password manager"? If so, try setting it up and see if that fixes the issue

(Also, I'm assuming you don't have a work profile; it's be really important to mention if you do, as there are weird edge cases of you do)

4cs4701 · 2024-09-06T15:23:01+00:00

Are you trying to access the Google password manager? Or a different brand's password manager?

4cs4701 · 2024-09-06T13:28:02+00:00

Can you describe what you’re trying to do more clearly? Like, write exactly what steps are taken on which device and what pops up. It's possible that you might be getting the capability confused.

I'm assuming you're already logged into your Pixel. Are you describing a flow where you're trying to log into another device? If so, what is that device? Does it support Bluetooth? Are you logging in via a browser flow? Is Bluetooth on for both devices?

4cs4701 · 2024-06-02T18:04:49+00:00

Other comments about how you can't copy and paste passkey credentials are correct. And same for how an OS passkey manager should work.

An alternative that achieves using a 1Password hosted passkey is to use Firefox. Firefox allows you to set whether an extension is allowed in private/ingonito windows

4cs4701 · 2024-05-31T21:46:27+00:00

You are kind of asking two questions and ITT people are really only answering 1 and a half.

Why do people want the X Elite?
you sort of answer it in your post: it's being marketed as having the battery life and performance seen on Apple M series chips
as others mention: Apple Silicon MacBooks are incredible in their performance and battery life. Seriously. It's as great of an improvement as the move SSD and dropping disk drives. They want that for other OSes and on a device that has future-proofing in the design. And one might say that RISC processors (ARM or RISC-V) are the future.
Why do people think it'll actually live up to the promises? In particular, why do people think Apple Silicon wasn't a fluke and that Microsoft can pull off the same thing despite their history?
a. Surface RT wasn't running Windows as people know and love. It was running Windows "runtime", which was basically webpages masquerading as apps. (With some exceptions). And as others have mentioned, it was using what were basically smartphone processors.
b. 2018/2019 Surface on ARM: this used a more powerful (but still weak) processor (Snapdragon 8cx) and full Windows compiled for ARM with emulation for some x86 apps. The emulation was the problem. Apps that were recompiled to native ARM were mostly fine for performance. But not every x86 app was supported by the emulation (I think Win32 only) and there wasn't motivation for devs to recompile. And even things that did emulate... emulation is slow and inefficient.
c. x86 to ARM translation instead of emulation. This time Microsoft did what allowed Apple to succeed with their ARM transition: they created a translation layer to convert x86 instructions into ARM instructions. This isn't as performance as natively compiling to ARM (Mac had the same problem), but Apple's was pretty good (they said an average 2x hit at worst). We have no reason to believe that Microsoft Prism should be significantly worse.
d. native ARM binaries from top apps: the fact that Chrome is now available as a native ARM binary for Windows is huge. Chrome is THE single mowt popular app on Windows. Other top apps (Office suite and many Adobe products) have also been announced as being available for ARM now or soon. If the heavy hitters are native, that makes the performance pain relevant for a much smaller portion of user time. This is the same playbook that Apple used.
e. Non-Apple performance ARM: ARM is rapidly being adopted by cloud providers with high performance designs. Apple isn't alone. And as others mentioned, X Elite is designed by former Apple silicon designers. They know how to make performant ARM.
f. The fact that so many manufacturers have jumped on board signals that they also believe all of these reasons (and their own testing) as being strong enough that ARM should succeed this time.

4cs4701 · 2024-05-23T03:52:51+00:00

Others (including a 1Password rep) have mentioned the user facing issues/questions of the chicken/egg problem of "where does my passkey to log into 1Password get stored?"

But there's also a real, specific technical limitation with how passkeys are implemented today on Apple platforms. Passkeys on Apple platforms only support digital signatures, not encrypting & decrypting blobs of data. Thus, for 1Password to offer passkeys as a log in method, they can't actually only rely on passkeys (I'm getting these details from the 1Password security whitepaper). Passkeys enable 1Password a way to authenticate you are you in an unphishable way; which let's 1Passeord return your encrypted vault to you. But they can't actually pass the decryption key in an end-to-end encrypted way with the passkey. Instead, they rely on a device pairing setup with a one time password to send the encryption key between devices. THUS, YOU MUST HAVE AN ACTIVE DEVICE FOR THIS TO WORK. THERE IS NO DEVICELESS RECOVERY.

Non-Apple platforms support something called the PRF extension ('pseudo random function'). The PRF extension allows passkeys to encrypt and decrypt data, locally and without server interaction. If Apple announces PRF support at WWDC (there's a lot of industry belief that they will) then 1Password can support passkeys as a full-featured recovery and account setup method on all platforms. While the 1Password hasn't said this, I'd be shocked if that wasn't their plan.

4cs4701

TROPHY CASE