HN user

arnarbi

1,541 karma

Icelandic. SWE @ Google. Security, authentication, authorization. Work on WebAuthn, FIDO & passkeys.

[ my public key: https://keybase.io/arnar; my proof: https://keybase.io/arnar/sigs/lf4Zbpd04PZPXu_eZyGhPVoef2BuJ0p5VUuzV8ZXD4I ]

Posts0
Comments472
View on HN
No posts found.

I think it’s a little different.

The restaurant fee isn’t a fee for something “extra”, it’s just a blanket extra charge on everything.

It’d be like the airline sold you a ticket for $500, but as you step off the plane at the destination they say “actually it was $550”, because it said so in the fine print.

Restaurant owners interviewed in the media here in SF are directly quoted saying they can’t do that because “customers would notice”, or think “oh that’s expensive, I can’t eat out twice a week”.

These are arguments for including the fees that make the customer __still pay the same higher price__, implying that the whole point is that they won’t notice. And reporters don’t seem to even register the absurdity of those remarks or question them in any way.

https://www.sfgate.com/food/article/sf-restaurants-junk-fees...

https://www.kqed.org/news/11992412/californias-junk-fee-ban-...

Scorched Earth was also my first hacking target. Found out that your cash balance and weapons inventory was all stored in a mysterious .ini file and you could just edit it.

Best "friendmaker" hobby I know is sailing.

It's in general a very newcomer friendly hobby, which is both important as a newcomer yourself as well as for meeting new people once you are into it. It's naturally collaborative so you have to communicate, not very intense so there's a good amount of chill time, and in the cases where small-talk doesn't turn up interesting topics you can always talk about sailing itself.

Back in college (~2008) we implemented this with a 7 foot tall back-projected screen and a couple of Wii remotes after seeing Johnny Lee’s video. The nice thing with that screen was that you could stand so close to it you couldn’t really see the edges.

We had as many people come test as we could, and we found that 90% of them didn’t get a sense of depth, likely because it lacked stereo-vision cues. It only worked for folks with some form of monocular vision, incl myself, who were used to relying primarily on other cues like parallax.

why they don't have TLS try and always create a client certificate per endpoint to proactively register on the server side

That is effectively what Token Binding does. That was unfortunately difficult to deploy because the auth stack can be far removed from TLS termination, providing consistency on the client side to avoid frequent sign outs was very difficult, and (benign) client side TLS proxies are a fairly common thing.

Some more on this in the explainer: https://github.com/w3c/webappsec-dbsc#what-makes-device-boun...

Services can certainly make this safer by providing means to get more restricted credentials, so that users can deputize semi-trusted delegates, such as agents vulnerable to injection.

The important point being made in this discussion is that this is already a common thing with OAuth, but mostly unheard of with web sessions and cookies.

This is a very good point, and one the DBSC team thinks about a lot.

In the short term it's about economics: Infostealer malware today scales really well because it can a) exfiltrate cookies quickly and clean it self up, mostly evading any client based detection, and b) sit on large stashes of long-lived cookies and carefully "cash them in" in ways that evade server side detections.

A short-lived cookie forces different behavior for b, which we think will make it more detectable server side, and binding in general will force malware to act more locally, which will make it (far) more detectable locally.

In the long term, DBSC also is designed so that the session management and key registration is somewhat decoupled from that short-term cookie business. If and when we can sign more often (perhaps every request), I believe the DBSC API will still be useful for websites to manage the session key and lifetime.

There are many sailing schools around SF, but one that stands out is https://www.cal-sailing.org/ - as it's by far the least expensive and low-commitment option to get on the water, and they have dinghies in which you'll learn very fast (but also get wet). Instructors are regular volunteer club members and mileage may vary, so make sure to go out with a few different ones.

Another good way to get started is to find crewing opportunities for casual racing on https://www.latitude38.com/crew-list-home/. Many skippers will take no-experience folks out for fun. (It may take a couple of attempts to find a skipper/crew you enjoy hanging out with)

Garfield is certainly (meant to be) real, but I've never seen a strip that confirms that Jon can actually hear Garfield's thoughts. I think that's why Garfield minus Garfield works so well.

You used to be required to adopt an Icelandic forename - not surname. You still kept your original name (if you wanted) and it was up to you which one you used on practice.

But as sibling comment says, that’s been dropped.

For surnames, anyone (including Icelanders) is allowed to use a family name if they have a claim to one, which is defined as having a parent or a grandparent carrying that name as a surname. So foreigners with family names can pass those to their children if they like and skip the patronym.

Is that really price discrimination?

“Enthusiasts” might have legitimate reasons for preferring hardcover (durability, aesthetics, etc) and are willingly and knowingly paying extra for that.

How much it cost to manufacture is mostly irrelevant.

A Tour of WebAuthn 2 years ago

“They” in this case included me and this was a deliberate fix for poor UX many years ago. We definitely thought about it and we used to blink only the key that had a credential from the allow list, because like you we thought that made the most sense. But people got routinely stuck because they just tapped a different key out of habit and nothing happened. There was no way for the browser to tell them “not that key”. Best case the reports would say the key was dead because it didn’t blink.

We changed it to blink all keys, so that if you tap the wrong one, the browser can at least tell you something sensible and get you unstuck. This wasn’t a hypothetical shot in the dark, but something we tested and actually worked well for real users.

I don’t disagree that WebAuthn has grown well beyond anything we could call good spec design. But it’s worth remembering that there’s /a lot/ of context behind it, and that the average user doesn’t behave anything like an average HN reader.

hoping the other keys with timeout before the use actually have to use them

Both Chrome and Android will cancel requests to all other keys. If your keys are locking up until a timeout it’s more likely the key itself is buggy.

Moon 2 years ago

I have the same fantasy. I think it’s appealing because I imagine they’d be able to appreciate all the amazing things behind it more than most people, dead or alive.

Stained glass won’t (I think) shift any frequencies. It will attenuate different frequencies differently, but it won’t make up new ones.

So when the signal frequency changes, you’ll still see that change, but the light might get brighter or dimmer at the same time due to the stained glass. But you don’t care about the brightness to begin with.

What am I missing?

The tree blowing in the wind will introduce its own amplitude (brightness) fluctuations. It will be hard for you to tell which amplitude changes are signal from the source and which are noise from the tree.

Edit: Looks like you answered yourself while I typed that, where you added:

Couldn't this be dealt with if you know the details of the tree's dimming ability?

If the tree is moving, and you’re far enough away to resolve individual leaves (which is not unreasonable) then its “dimming ability” is constantly changing.

Others have answered correctly (it was an arbitrary choice), but fwiw I always found it helpful to think of current as the direction of the “holes” where electrons can be.

Like bubbles rising in water, the holes “travel” opposite the potential that’s pulling the surrounding electrons the other way.

In one of our iterations, we did indeed have a mandatory rule that each set of caveats added by a holder was terminated by a “sign off” caveat. But in the end we concluded that if that mattered in the actual enforcement, then one wasn’t really doing things “the capability way” and then that principal probably needed some stronger authentication than merely having held the unattenuated macaroon.

But that’s theoretical thinking and the real world is indeed more shades of gray.

See you in Madrid!

None of these changes are necessarily authenticated - I don't know that it specifically was the user agent that shared the token with the service or added the read-only restriction, at least with the core tech.

Macaroons are very much grounded in capability thinking, where it is a “feature” that principals such as the user agent in your case don’t need to have representable identities. So there’s nobody to authenticate, except the fact that it was a holder of the previous macaroons tag, which means they had the authority it represented.

In other words, not needing something like a PKI is somewhat the point of it all.

If you have the need to authenticate the intermediate principals, eg because they have pre-existing identities already, then the capability model in general may just be a distraction. They could just sign their desired attentuations with their own identity key.