If this is supposed to be used in production as open source, then I am a little surprised that it's under AGPL 3.0, especially given there's no mention of commercial version.
I wonder if JS could benefit from a system similar to Rust editions (https://doc.rust-lang.org/edition-guide/introduction.html). Requiring assertion like "This code was written in 2021, no MooTools here" seems like a reasonable ask to access new features in the standard library.
I know it may sound similar to what X-UA-Compatible did, but that was really horribly implemented and vendor specific...
It just never really worked well for me in a multi-monitor setup with two screens and a docking station... Now, Windows itself is quite terrible with this and often moves windows between screens for no reason. For example, when primary screen takes a second longer to come back from sleep, all windows float to secondary one, at least that is what I guess is happening.
Now, with ConEmu, that also caused some rendering defects and I would have to hide/show window and sometimes reopen tabs to get it to work again. If I understand correctly, ConEmu does some sort of off screen rendering hack with conhost and then just synchronizes the bitmap to where its real window is. Though I may be completely wrong and that is not how it really works. But these issues have never occurred with WT.
Otherwise, I had nothing to complain about with ConEmu, especially its UAC handling is awesome. Unless we could have proper sudo on Windows, of course. That would be even better UX :)
Had been literally doing this first as a "poor man's" quake mode since moving away from ConEmu - pretty soon realised it was just enough for me. So I'd rather they find an elegant solution to UAC elevation.
I understand that. Problem is that I can "steal" other dev's app client_id and use in my app. So it seems impossible to use such client_id for auditing/evidence. With a web client I cannot do that since I don't own the domain, so I can be proven to be a party in some transaction
Yeah, thinking about the same. But then I saw the OP mentioned somewhere in the comments below that he's only thinking about server to server scenario (2LO/client credentials), so its those comments above discussing fake login UIs confused me that it was about 3-legged flow.
I completely agree with everything you said and know a bit about OIDC too, but since I'm far from mobile/3rd party apps development, there is one thing I don't understand: client credentials (confidential client) in case of mobile app installed from the marketplace. How is it done?
You'd need dynamic client registration, right? I know there's a spec for that and I think I understand the mechanics. That would let you identify the client but not sure you can ever identify app developer with it (if needed for audit purposes). Or am I missing something, maybe?