HN user

wsces

181 karma
Posts6
Comments7
View on HN

The watch needs to be unlocked either with a PIN code or can be set to unlock on close proximity to iPhone which unlocks via Face ID (or Touch ID, or a passcode). Once it is in an authenticated state it remains unlocked while it is attached to a wrist. I’m not totally clear how it detects when it separates from a wrist (probably a light sensor, heart rate sensor or some heuristic derived from the both - but it’s pretty instantaneous and reliable). “Privileged” actions like payments or escalation prompts still require a double click of the watch’s physical button to confirm, but in this authenticated state it is possible to use the watch to unlock Mac or iPhone based on proximity alone.

It has no concept of “who” you are, only that it got positively authenticated while on a wrist by proximity to your iPhone unlock or a manual correct PIN entry and hasn’t separated from that wrist since.

No, a VPN would only change the source IP of your request which the author specifically states isn't how this system works: the browser uses its host OS' Location Services to self report its location based on GPS or Wi-Fi AP locations.

That said, I hope the service doesn't implicitly trust data sent by untrusted clients like web browsers, otherwise someone could just use something like this to send it a false location: https://chromewebstore.google.com/detail/spoof-geolocation/i...

Isn't this roughly what mDL (and broader future W3C Digital Credentials spec) offers albeit with the issuing agency of the ID (e.g. state DMV) acting as the credential issuer rather than a bank? A relying party make a claim for a coarse age limit 'is user over N years old'? With the user's consent, the application receives an attestation back from their wallet, with a chain of trust back to the issuer (without the issuer's intervention or knowledge).

The user's credential is bound to the device and protected by their biometrics (Face ID/Touch ID), and the consent screen feels very similar to using a Passkey (gaining in mainstream popularity) or Apple Pay (pretty mainstream at this point).

- https://www.w3.org/TR/digital-credentials/

- Apple's implementation - https://developer.apple.com/wallet/get-started-with-verify-w... (and moving to the browser in iOS 26 https://support.apple.com/en-gb/guide/apple-business-connect...)

The challenge here is adoption and availability of digital credentials. It appears State Department is allowing iOS 26 to issue digital credential representations of US passports also. Japan are also providing their national ID card in this way. Given some US states' online age verification laws (and whatever it is the UK are trying to do at the moment), seems like a great incentive for those governments to provide robust digital ID infrastructure.

The guidance does state ‘should’ rather than ‘must’ - I have amended my comment to make it clear that it’s a recommendation (alongside lots of other recommendations in the same guidance document)

Enforcement and policing of this is presently unclear (and will likely be delegated to local environmental health and licensing authorities, from what I’ve read - so may be inconsistent across the country).

I suppose if an outbreak is linked to a venue that hasn’t implemented the recommendations it will (at best) reflect badly, and at worst attract attention from the local authority in the same way as if other recommended public health measures were not implemented.

https://www.foodandwine.com/news/uk-pubs-reopen-register-dri...

UK pubs will reopen on Saturday but government issued guidance recommends that venues require customers to leave contact details in case of a localised Corona outbreak. We designed a simple service to collect the bare minimum data to comply with both the registration guidance and GDPR.

Customers just send a four digit SMS locator to a number (or an email to a special mailbox) and we log either the sender's phone number or email address against the venue and the time of entry. We reply to the message with a confirmation that can be shown to security/service staff. All data is encrypted on the back end and retention periods are enforced. Data export is controlled (and similarly encrypted) in the event that a venue is required to provide by the public health authority.

This approach means data is accurate (non-trivial to forge sender headers) and low friction for the customers. Not asking for personal details to be input makes for a less invasive check in experience for the customer, whilst maintaining compliance for the venue.