Impressive! Feels really responsive. I feel the controls are a little unusual though: WASD corresponds to actual map orientation rather than to where the character is facing. I find it confusing when playing together with a mouse, where I would expect I can hold W to move forward while using the mouse to control the character's orientation and direction.
The initial implementation actually used that approach - but I got some complaints from people saying it felt weird and I changed it. That was a long time ago during prototyping though - might change it back and see how it feels now (or just add an option). Thanks for the feedback.
You made a good point, esp. if your passkey vault is comprosed, e.g. Apple iCloud's credentials are leaked. signCount, incremented or not, would not help here in informing you of your hacked iCloud account – that would be dependent on iCloud's service itself for detecting and informing you of your compromised account.
I would still like to see big tech passkey providers implement signCount for the following 2 reasons:
1. It helps to push relying parties to implement signCount verification. Right now most relying parties do not implement it as many providers are returning `0` for `signCount`.
2. This would be an odd one, it helps against detecting leaked private keys of passkeys, if a malicious attacker, internal or external, manages to obtain the private key.
I'm a bit confused: how does signCount ever bring security in a shared-passkey scenario?
The only way I can see it be useful is if you have exactly one instance of the passkey (e.g. a security key), because if `signCount` got incremented without the security key being aware of it, then you have a problem.
Same reason how signCount is useful in a non-shared passkey. Yubikeys are not supposed to be cloneable afaik, but this helps to detect if somehow it got done.
> Same reason how signCount is useful in a non-shared passkey.
Again: unless I am missing something, signCount is useless with a shared passkey. If your laptop expects signCount to be "2" and sees "5", it will just believe that your smartphone was used in the meantime. The counter doesn't say "it was used illegally", does it?
> Also, why not.
"Because it's useless" sounds like a good reason to me. Unless you explain why it is not useless, that is.
signCount would need to be synchronised as well as the passkey by whatever method you elect to use. If your synchronisation method has been persistently compromised you're hosed, but if the passkey is cloned as a one off, the server would continue to increment signCount everytime either copy is used, while the passkey in your possession would only increment when used by you ie. half as often.
You'd run into trouble if the sync service can't tally multiple device uses in quick succession, which is the likely reason for the article - if I use my synced passkey on three separate devices in a few minutes, all three copies would have the same signCount, but it would be lower than the server's signCount. Either you'd have to prompt the user everytime this happens or record and sync a lot more information about every passkey use and let the sync service count them.
Say the user has two devices and hence two copies of the same passkey, let's call them A and B. They have a shared signCount.
Say an attacker manages to make a copy C of A. They have the signCount as part of it, right? So they can immediately connect to the server. The server will increment signCount and sync it with A and B, but C is already in and C knows that the signCount is probably lastSignCount+1.
The only way I could imagine signCount to be useful is if somehow the server synchronises it between A and B in a way that C - who got access for a while - cannot access. It would mean that C has access until A or B connects, and after that the next time C connects, it will be out of sync. This does not sound super useful, and it assumes that C cannot access the sync process even though it has unlimited access to the passkey (until A or B is used).
What am I missing? To me signCount doesn't bring anything here...
If C uses it without the knowledge of the original owner (A or B). With proper signCount check, C would have to increment it at its end; A or B would not have known.
When A logs in with an unincremented signCount. A and the relying party are now aware of a potential cloned authenticator and disable the compromised passkey.
I'm sorry but it seems far-fetched to me. For signCount to be useful with shared passkeys, the attacker who managed to copy the passkey and get full access until the true owner logs in again would have to not synchronise the signCount (which they can totally do because they have full access), and it would "only" let the true owner know that the passkey is compromised.
It seems strictly worse than just sending an email saying "your passkey was used from <IP-based geolocation>, wasn't it you?".
Loved the site and the companion book. Borrowed it at my local library and kept renewing it. Taught me CSS, coming out of hacking CSS with all the weird tricks at that time, and made me realize that you _can_ make beautiful semantic websites without the crazy hacks.
There's nothing inherent to those sites that warrant SPAs. Things that do warrant SPA are full blown apps like Gmail, Figma, Google Maps,... or if you're building a desktop-like dashboard like Synology NAS's.
Why is it not as fun? It's just a different kind of game. There are plenty of tactical shooter or sniper games that go through a lot of effort to model the ballistics (like the Sniper and Sniper Elite series), as well as pretty much every tank and naval game. The Battlefields weren't as fast-paced as UT, but they made great use of ballistics for everything from sniper rifles to RPGs... added more skill to the game.
Even Unreal Tournament itself had some basic ballistic guns, like for the alt fire of the flak cannon and biorifle.
Indeed it did, although the flak cannon brings another set of issues as the preceding article talks about (basically it combines two very different types of weapons system).
And agree, different types of game need different mechanics. Battlefield games were a very different experience; I think the simple mechanics work in UT.
Surprised that Claude (the app, not model) not only has done well for so long, but has somewhat consistently clinched the top spot in coding, all without a feature that is considered somewhat of a basic feature for most consumer-facing AI apps.
How much % it’s significant compared to say openai or google? Because if I’m paying 20$ I want other things too not just coding. And if the moat for coding compared to other vendors is not significant, it doesn’t make any difference tbh
Fair point. I wouldn't say it's by a lot because I am getting quite good results with ChatGPT's models too. A part of it could also just be confirmation bias too.
No, the BLE identities of these tags are currently practically indistinguishable from original tags, and could be made completely identical if necessary. In fact, changing the device's MAC address is part of the specification. What they could block, is the method used by these projects to fetch encrypted location reports. However, the original OpenHaystack project (this one) needs to run on macOS and lets the system handle account authentication, so it's unlikely to get blocked any time soon.
Yes, because they get a commission for every device registered on the network.
In the join process, there is a key that is shared only for developers who paid the fee - which is why it's not really trivial to create an AirTag clone without dumping the Apple AirTag flash
RSS was a key protocol in syndication a widely free and open web before the domination of big tech/social media. We now have new internet generation that has never known RSS, relying largely on "the algorithm" of the big tech in content syndication.
Thank you for your effort in advocating RSS support. I hope RSS makes a major come back especially with the recent events.
Very clear pitch at https://pagecord.com. The video explains it all in a few seconds. Clear distinction from being yet another minimalist blogigng platform or static site.
A 1-time fixed cost will not deter spam, it only encourages more spamming to lower the averaged per-spam cost. Email spamming requires some system set up, that's a 1-time fixed cost above $10/year but it does not stop spam.
It’s one time fixed cost per stream of messages, with some out of band mechanism to throttle posting per-stream. I’m not sure I agree with the original articles choice of throttling mechanism (binding to the universal Bitcoin clock), but the concept still makes sense: in order to scale up production of spam, you still need to buy additional domains, otherwise you’re limited to one post every n-minutes, and domain registration slow enough for block lists to keep up.
