I think it depends on the project. I think most of us could eye ball a blog directory pretty quickly and get more or less the same idea. However, give it a gnarly bit of legacy code in a language you haven't used for a while, and indeed, 11c is pretty cheap.
A human getting paid 1 cent per second ($36.00 per hour) is 75k/yr (cost to business is ~2x that).
So if Claude manages to save 11 seconds of human time for 11 cents, that would be a good deal.
Tax section 174 makes the employee costs amortised, so spending on Claude as an expense to save employee costs is more valuable than first appearances.
> You can either sync passkeys to an online account and across multiple devices, or use multiple passkeys stored in multiple physical authenticators.
But all of that has to be set up in advance, right? What happens if I really only have a single passkey, associated with my phone, and then lose the phone?
The upcoming W3C Web Authentication Level 3 defines a "backup capable" authenticator, which means that it goes beyond a single piece of hardware. Indicating "backups enabled" means that the user has a recovery process, such as if they store the passkeys in their iPhone and then lose/upgrade the model - they can just sign into iCloud on the new device.
Not all authenticators are going to have backups enabled (even ones which are backup capable), so these are really meant as hints so that a website (a la Relying Party in the spec) can guide the user to a proper experience. For instance, if you use a hardware security key fob, they may recommend you keep your password and SMS enabled as options, so you can get in even if you lose it.
> For instance, if you use a hardware security key fob, they may recommend you keep your password and SMS enabled as options, so you can get in even if you lose it.
But if you have this and the old authentication methods, doesn't that greatly reduce the security gains of this? I mean, the old methods still exist, so what you've done is increase the attack surface.
It can be used on both Android and iOS. Desktop machines can display a QR code which you scan with your device. Passkeys are backed up to the cloud using E2E encryption. If you get locked out of that device, you can do the same thing as when you lose your password.
> do the same thing as when you lose your password.
If this is a Google Service, then that means begging, pleading, threatening, crying like a baby, then finally posting a rant on HN to get the service unlocked.
Google is fairly infamous for making it near impossible to recover lost account access, or appeal bans.
I have an account that I’m never getting back. I made an error, when setting it up, that resulted in me losing the password (I saved the wrong one, in 1Password). It’s been a few years, but I remember trying everything to get it back, and was stymied at every turn.
Eventually, I gave up. The reason I registered the account, was because it was the name of one of my corporations, and I didn’t want fraudsters registering it.
Mission accomplished. Ain’t no one using that account.
In principle it can be synced between any is, it just depends on the cloud/implementation. Eg. 1Password is currently adding Passkey support, that would probably work on any device they have browser plugins and the private key material is stored and synced through 1Password vaults.
I suspect that one screen comic or a 20 second video could explain it. Instead they give us a wall of text that even technical people can't understand.
Very possibly just that it is an ID that is no longer on the App Store - in Flappy’s case because the developer was frustrated with the demands being placed on him by all of the app’s global users (it was a sad story at the time). But a security provider wouldn’t be wrong to assume that the majority of times an app is removed from the App Store it is because it was found by Apple to violate policy in some way - and why introduce the liability of having a whitelist for things like Flappy Bird?
You can be annoyed all you want, but the process is insane. The only options available to me are my two university emails. One of the email domains simply no longer exists. I actually took the time today to call my old university, and they were kind enough to temporarily turn on my old university email address for the other email tied to my Facebook account. Facebook won't send the code to the email after I correctly login. It reports an error. (I verified that the email is working.) There's no way to report the error anywhere. The only way you can report an error to Facebook is to be logged into Facebook. There's another login screen that allows you to reset your password. I did so there since that actually worked by sending an email code. After I do that, it takes me back to the "browser verification" screen. Now, the email I verified has disappeared from that list! The only one left is the email that is tied to a domain that no longer exists. It is impossible to get an email at that address. It's ridiculous.
TLDR: I actually recovered my old university email address, and Facebook refuses to send a code to that email and has now removed it as an option.
The SDK Runtime sounds like a major step in the right direction (separating advertising SDKs into its own process with distinct permissions, separate from a hosting app and with no app-to-app communication).
Also the ability to custom audiences from apps (in the fledge article) and control topics both sound good.
These things dont appear to have any current plans to be required, but in the future I hope they do.
If you’re familiar with the mobile advertising landscape, on device identifiers are either OS-provided and deterministic or are computed through a “signature” or “fingerprint” based on unique signals the app has access to.
This move is one where either of those will be removed/made universal so there is no way to identify uniquely, one user from another when they perform actions outside your app or for many scenarios within it as well (such as clicking on an ad that takes them to the app)
Lots of advertising companies (predominantly Facebook) have made an industry standard out of selling ads based on THEIR interpretations of users actions across apps and time leading to a conversion. For example, a 7day “click through conversion” means , if your ad is shown to a user through Facebook on any of their apps or partner apps with the Facebook ad network sdk, and a subsequent conversion occurs in the next 7 day window, that user is counted as 100% credit to Facebook.
Is this logical? Nope.
Advertisers pay for the nice looking metrics they can stick in a PowerPoint and be done with it.
Now, Facebook can’t use their “eye of Sauron” to put out numbers such as these and need to compete with companies such as google and Pinterest and Reddit and snap for where users are looking for things, not just “snipe” the attribution at the last minute when they know the user is about to pull the trigger and buy.
Looks like they are trying to create a distinct set of APIs for third-party advertising (and I think everything else) SDK libraries. Those libraries are submitted to Google independently from the app. The apps now have to declare they are using library X version Y and Google will deploy that library to the end user's device when the app installs.
