I’ll preface with IANACL, but you seem to be making a moral argument yourself about A), that it is not reasonable.
You have, I assume, a licensed copy of Harry Potter. That license restricts you from doing certain activities, like making (distributing? Lets go with distributing) derived works. Your models are derived works. Thus when you distribute your models, you’re violating the licence terms you “agreed” to when you acquired your copy of Harry Potter.
This is no judgement by me about whether that’s reasonable or not, just my understanding of the mechanics.
Rather than a moral argument, I think they're more just disagreeing that the spirit behind copyright law is being violated in that case. So while yes, there may be a rule in there that you may have agreed to, they disagree that such a rule is within the spirit of the law, and may reckon that it should not be a part of it even if it presently is. Like they explicitly mention how they're reflecting on the idea behind it all, rather than producing a legal analysis.
Or at least that's how I read it. I'm sure GP will clarify shortly.
More precisely, the reasoning hinges on the assertion that "Your models are derived works." which I doubt is so cut and dry. There are many processes that take external information as input. That alone clearly can't be sufficient to established that something is unambiguously a derived work.
I read a copyrighted book, it is lossy encoded into the weights of my brain. Am I a derivative work now? No. If that book inspires me to write another book in its genre, it will also not be a derivative work unless it adheres too closely to the original book.
In this scenario I personally have no physical, audio, or otherwise legitimately purchased copies of any Potters, Harry. I have entered into no direct licence agreement. If it makes things simpler, ignore the "format shifting" aside.
Nitpick: Can a license restrict you? I thought it only gave you additional rights, should you choose to accept it, but can't take away rights you have (e.g. the ability to make parodies from it). The restriction comes from IP laws themselves.
Metabase’s free version supports Google login and no others — it works okay, but any further login federation requires stepping up to the enterprise version (at least for self-hosted).
“Nightmare” is too strong, but it looks from the simple example that generators are managed by jumping between coroutines, and one of the coroutines is the renderer? (Sorry, I’m on my phone and probably not conveying my point very well)
I’d be interested in seeing this hooked up to Xstate.
100% this. Phishing is incredibly common, really difficult for even sophisticated users to detect when done well, and the best password manager isn't going to help you. A security key will all but guarantee that this isn't an issue and is a pretty good UX too.
Correct me if I'm wrong, but password managers can prevent quite a lot of phishing, because autofill can automatically check the domain.
It would be abundantly obvious to me if I were going to put my paypal password into anything but paypal, for instance, because I wouldn't even have the option. I'd have to copy/paste if I wanted to, which would up my suspicion level to the extreme.
(this is not to downplay security keys though, I think they're very important)
That's what people say but even security experts have fallen for phishing attacks. And since the autofill is not 100% reliable, it's not that unusual to go into the password store and manually get the password out of there.
It's really quite unusual. I'm not sure what password managers these security experts are using, but there's no way it works like mine (bitwarden). I've never had it fail to recognize the domain, which is good because that seems like really obvious functionality.
I have had it fail to autofill due to site implementation, and the couple of times it happened I was extremely on my guard and triple-checked everything before proceeding.
I think that's the important part of this, the manager has to be reliable enough that the bypass mechanism stands out _a lot_, and the user has to be aware.
Sure it can handle logins to both "theircompany.com" and "service.theircompany.com", assuming the cert is set up correctly. It probably isn't going to figure out that those are related to "theircompany-service.net". This would arguably be a failure in domain setup, but I've certainly seen similar setups before.
Sure, but that's something the user sets up, so it still contradicts GP's contention that the user never needs to think about this. The only thing a password manager can (validly) do automatically is look at subject name and subject alt names. (I don't know that all of them even do this.) Even that's assuming that certs are set up correctly...
> since the autofill is not 100% reliable, it's not that unusual to go into the password store and manually get the password out of there.
I imagine you can extract passwords out of security keys in some form without being on the correct domain, too.
Do domain check fails that regularly? I'm sure enterprise configuration policies would provide functionality to prevent password extraction should you be inclined to enable it.
No, the whole point of U2F/FIDO is that phishing sites can't extract a usable credential from the key because everything is tied to the origin requesting the authentication.
WebAuthn doesn't have "passwords" it does public key crypto. So phishingsite.example gets a public key signed response saying "Yup, burner wants to sign into phishingsite.example" and the whole point of cryptographic signatures is that nobody can make it say mybank.example instead of phishingsite.example without invalidating the signature. So it's useless for breaking into your bank account.
There's no UI. Even if you are 100% convinced this is really your bank, you desperately want to sign in, you keep tapping that button, trying again, it can't help the bad guys. There is no "Yes I'm really sure this is my bank" option that destroys your security.
Password managers have to be compatible with the reality of how passwords are used/ abused by site owners. When my preferred electricity supplier was bought by Shell (as part of an exercise in greenwashing the huge fossil fuel company) they rebranded and all their URLs changed overnight. My passwords still worked - but on these new URLs. This looks _exactly_ like a phishing attack, except for the huge advertising spend on a cynical rebranding exercise.
If you sell a password manager that fails in this scenario you're getting customer feedback saying this product doesn't work, fix it. How can you fix it? Add an override, destroy the security value of the product.
But WebAuthn comes out of the box enforcing this rule that the FQDN can't change. When Shell buys the electricity company and says "All your sites need to change" if they used WebAuthn the developer says "I tried that and it breaks login for all customers". "Tell them to override it, put up a banner saying so". "There is no override"... "OK, put the old site back". Done. Users saved from security lapses caused by corporate rebranding.
The WebAuthn people put a bunch of effort into thinking about evil things that can go wrong and defending against them. Having a clean slate to start from helped enormously.
So... Nothing apart from some convoluted anecdote?
If currently there's no password manager in existence that doesn't let you override the plaintext password extraction / override feature, there's nothing to stop one being made. You could probably hook it in with a system level service which cryptographically signs them, too.
What are peoples thoughts on using TLS client certificates for authentication?
Given we're talking about APIs, we avoid many of the UX problems, but it feels like taking on a different set of problems than just using a bearer token. It does provide baked in solutions for things like revocation and expiry though.
I'm not that familiar with TLS client certificates so I'm not qualified to say, but if you consider other developers as your users, then the UX problem remains.
Web developers in general are more familiar with other forms of authentication so unless you have a strong reason for picking TLS client certificates I would suggest picking something else.
In other words: I would be more likely to try out an API if it was based on Basic Authentication. ;-)
Client certificates don't work in http2. If you use due diligence and store them in secure hardware then they could be a lot more secure than bearer tokens (cannot be exported) but I guess most people would just store a PKCS#12 file on disk and that'd make them as secure as a bearer token.
On the other hand some companies use them even for browser clients for passwordless authentication.
It's a pain in the arse for everyone involved. Adding another management layer to the stack isn't my idea of maintainability, and I'm inclined to agree with you on your point that it introduces a new set of problems.
TLS client certs are nice if everyone knows what they're doing, but in a lot of orgs that just isn't the case.
Here in Australia we get a mix of US and British kids shows (on ABC Kids, have no idea what is shown on commercial channels), and its trivially easy to pick the US ones because they are dripping in morals, lessons, and such (and are also terrible).
I've started describing it to people as: British shows are designed to entertain first, and perhaps kids can learn something, whereas the US approach is THOU SHALT MAKE SURE CHILDREN UNDERSTAND RIGHT AND WRONG!.
Don't forget the importance of nutrition and exercise! There's also some law that these shows have to have a symbol on the screen somewhere that says "E/I", for "educational/informative" I think. In case you couldn't figure it out on your own!
You have, I assume, a licensed copy of Harry Potter. That license restricts you from doing certain activities, like making (distributing? Lets go with distributing) derived works. Your models are derived works. Thus when you distribute your models, you’re violating the licence terms you “agreed” to when you acquired your copy of Harry Potter.
This is no judgement by me about whether that’s reasonable or not, just my understanding of the mechanics.