> I really can't think of anything that comes close in terms of [...] developer experience.
Of all the languages that I have to touch professionally, C# feels by far the most opaque and unusable.
Documentation tends to be somewhere between nonexistant and useless, and MSDN's navigation feels like it was designed by a sadist. (My gold standard would be Rustdoc or Scala 2.13 era Scaladoc, but even Javadoc has been.. fine for basically forever.) For third-party libraries it tends to be even more dire and inconsistent.
The Roslyn language server crashes all the time, and when it does work.. it doesn't do anything useful? Like cross-project "go-to-definition" takes me to either a list of members or a decompiled listing of source code, even when I have the actual source code right there! (I know there's this thing called "SourceLink" which is.. supposed to solve this? I think? But I've never seen it actually use it in practice.)
Even finding where something comes from is ~impossible without the language server, because `using` statements don't mention.. what they're even importing. (Assuming that you have them at all. Because this is also the company that thought project-scoped imports were a good idea!)
And then there's the dependency injection, where I guess someone thought it would be cute if every library just had an opaque extension method on the god object, that didn't tell you anything about what it actually did. So good luck finding where the actual implementation of anything is.
You can back up a debunking with receipts or reputation. Ideally, both.
You and anotherlogin448 have neither, but also show incredible aggression towards anyone pointing that out.
Your confidence might actually be warranted, but there's no reason for any one of us to take you on your word, and neither of you have given anything else.
"Made for sharing", but suggests depending on 1Password?
It also seems.. irresponsible to claim that @sensitive values "will be always be redacted in CLI output", when the whole point of something like Varlock is to configure some external application that it doesn't control.
And what does "AI-friendly" mean here anyway... beyond, I suppose, varlock being AI slop itself.[0]
It's worse, as someone who does try to privide release notes I'm often cut off by the max length of the field. And even then, Play only shows you the notes for the latest version of the app.
You're always locked in, so you need to make sure that you can adapt it as needed. Either because you already own it (homegrown) or because you're prepared to take ownership if needed (FOSS done right).
For commercial software (or FOSS-as-appliance) then you're stuck going along wherever your vendor wants to take you.
Of course, this doesn't count the time wasted troubleshooting why your $9/mo piece of garbage doesn't work, or finding out that it never even tried to deliver on its promises. Or the time spent replacing it when you decide to 3x the price out of the blue. Or maybe you just decided to sunset it out of the blue because you got bored?
> Maybe it is different where you live but the standalone hardware key I mention is standalone: You open the website, enter your national id, find your token generator, enter pin code for hardware token, read your token, type it into the bank web site, and enter your password ib a different field.
That sounds completely different. "BankID På Kort" is basically the same experience as using an OpenPGP smartcard: it prompts you to insert the card, enter your PIN, and everything else is handled in the background.
Many banks here (and at least Nordea used the CC for this) also support manual challenge/response auth like you describe, but this is unrelated to BankID and seems to generally be considered deprecated.
> And the thing you describe seems to be very very different and I'm confident there's only one BankID product in the Nordic countries, so either it is implemented in a very different way with your bank or we aren't talking about the same thing.
From what I can tell, Swedish and Norwegian BankID are completely separate. NorBankID seems to be operated by Vipps[0] (a consortium of norwegian banks) and have existed since 2004, while SweBankID is owned by Finansiell ID-Teknik[1] (a consortium of swedish banks) since 2002.
They also don't share the logo, or seem to have any ties between their websites.
> Around here hardware tokens were supported before mobile BankID was even a thing. They are still available everywhere I log in.
Each bank generally had their own hardware tokens since before BankID (and still do).
Government services usually also support Telia's NetID (which is similar to BankID På Kort, but at least seems to provide a Linux driver).
However, BankID is also starting to become popular for services that would otherwise have been fine with plain old username/password authentication, rather than implementing U2F or TOTP. These services usually don't put a lot of thought into their implementation, and don't tend to implement alternative auth methods. Older services will support username/password for existing users, but expect it to be considered deprecated. Examples of this category would be Hallon (mobile network), Hemfrid (home cleaning service), or Kivra (crappy email without the federation).
> As for why I care, I find that BankID is a good idea, reasonably implemented, so I don't think it is OK to trash it
> You're - literally - on "Hacker News" complaining about the lack of a product. You were given one that you could easily fix to suit your aforementioned needs/demands and was a principal complaint against BankId but, instead, you want BankId to write the Linux app for you because... ...profits? This makes no sense; especially, when you would already have a hefty baseline of code to work with.
That's like saying jailbreaking makes iOS respect the consumer. It's a temporary hack that makes it tolerable to use... for a few days until the next mandatory update comes out and breaks everything again.
You won't get lasting improvement without changing the mindset of the powers that be.
> Does not automatically doesn't - implicitly - mean that it's disallowed. You seem to be confusing the two concepts, here.
You're saying service developers can put in the work to support both desktop and mobile BankID. I'm saying most of them are lazy and don't bother. Those two statements are not incompatible.
> We're - literally - talking about the API being the same because you made it a point that it was different. Either it matters or it doesn't. Pick one.
Similar and compatible are very different things.
Then again, this whole subdiscussion is irrelevant anyway, because desktop BankID is still crap for the same reasons as Mobile BankID.
> O.k.? We're still in the swamplands of those are problems created by the app developers and not BankId, correct..? I'm not sure I'm following how the app designers' decisions are the fault of BankId...
If BankID had spent more than two seconds designing their API boundaries then the app developers wouldn't have had to care about supporting both in the first place.
> I don't think it's unreasonable for services to want to know who they're dealing with. In real life, if someone else shows my ID at postnord, they have to show their own ID too.
BankID could have designed their API such that "person performing the action" and "subject the action applies to" are different fields.
But even that is unnecesary. Who actually requested the action only concerns the subject, not the third party carrying it out. BankID could simply log "Delegate A requested entity B to perform action C on behalf of subject D" and show it to D, while keeping B completely in the dark.
> There was[0]. Maybe you can revive it, since it is a pain-point?
No. This is a problem that was intentionally caused by Finansiell ID-teknik, and I'm not going to get into cat-and-mouse game to fix their for-profit product.
> Having read the BankId specs, they're "different" APIs in only in how the session is initiated. You're still challenged to enter the PIN for the certificate, which prompts the response to the authentication request. In other words, BankId and Mobile Bank Id are presenting the same exact set of data back to the session initiator.
They're different in that a service that takes Mobile BankID does not automatically support the desktop version, or vice versa. Whether the API is similar after that doesn't matter.
> I have, as of yet, to run into anything that would not take BankId or Mobile Bank Id.
Off the top of my head, Swish and Hemfrid only accept Mobile BankID, with no alternate authentication options. Swedbank accepts Mobile BankID or their custom OTP hardware token, but not desktop BankID.
> You can install it on your PC or Mac if you want.
1. Same problem. There is still no Linux client, for example.
2. It's a different API. Most services specifically require Mobile BankID these days. Desktop (regular) BankID won't work there.
3. Many applications are only useful on the go, such as Swish.
> Access delegation not being part of BankID itself is a feature not a deficiency, it would undermine the concept of secure digital ID if someone else could digitally impersonate you with it.
Different kinds of services have different security requirements. If multiple people live together then it makes sense that any of them should be able to send requests to their cleaning service.
There is also already a clear precedent to allow delegation of access that require strong authentication IRL. For example, PostNord allows you to retrieve someone else's mail as long as you provide ID for both yourself and the recipient. You can issue a Fullmakt which authorizes someone to take legally binding actions on your behalf. Hell, you can even vote by delegate.[0]
Why should those rights not extend into the digital world?
> Instead, services can choose whether they let you allow someone to log in for you.
And they don't, because they are lazy and think BankID has magically solved all of their authentication woes.
It's coupled to your phone's OS, so as it becomes even more mandatory you're stuck carrying around an iOS or Android device, even if your primary phone is something like a Librem 5.
It also doesn't support anyway to delegate access, either to people ("my partner should have access to this bank account") or computers ("I want to back up my incoming govt. messages automatically").
But yes, it'd also be nice to have something closer to dockerTools.streamLayeredImage.