Excellent job!
How did you approach the licensing matter, as in order to customise Windows installation media and in order to be compliant with licensing terms one needs to solve (and pay for) this non-trivial puzzle if it can be solved in the first place: https://download.microsoft.com/download/3/d/4/3d42bdc2-6725-... ?
I guess Microsoft has to make money somehow, but it's not funny. And the worst thing is that you somehow have to magically know this.
I really wish that OIDC / Oauth(orization) would be less confusing from user experience and security perspective.
What I have in mind - I'd say only very small population understand that OIDC / Oauth(orization) is about granting access to a service to access your data. Meaning once you have approved service (lets say Dropbox), now Dropbox can access your data on your google account (this of course depends what exactly dropbox asked and if you clicked on "approve", but most people do click as they want to login to Dropbox via their Google account).
SAML is better, as it can be defined at Google side what data is being sent to DropBox when Single Sign On happens and DropBox cannot access your google data as it sees fit.
SAML ain't perfect either because there's no practical way to "sign me out everywhere"
Interesting. For example how would one find a "new" Tool or Deftones? Current algorithms probably don't "pick up" not-yet-so-popular things. For example Shelton San (I found out about them via word-of-mouth), although I'm frequent user of Spotify.
This means that classical promotion channels are still necessary, as otherwise things get lost in noise.
That's the thing - authentication capability is basically sideeffect of Oauth/OIDC.
SAAS x can request whatever they want via OIDC and then user can either accept it or decline it. This is protocol, not google specific matter. Ask ordinary user how they understand what is being asked from them when they are trying "to log in" via OIDC/Oauth.
With SAML it's the other way around - administrator chooses what is being sent to SAAS x, user does not need to decide anything nor do they get hard to understand prompts.
Would be great if chromeos flex would start supporting organisation provided wifi credentials - currently only device generated keys are an option, meaning one has no idea whatsoever if keys generated are actually good enough or are just looking random while generated might be generated predictably. No idea, as it's a black box. Allow organisations to generate keys off device and allow these to be uploaded to the device, and then we can start considering it.
The other problem is that other vendors do not provide chromeos versions of their tools. Looking at you Fortinet and your vpn.
When has the switch been toggled though and how can I know in each implementation?
1. Is it when I pushed the toggle, regardless of when animation finishes?
2. Is it when the animation finishes
This is necessary when flipping many toggles on one page and it needs to be done many times over. In case there's no animation, it simple and clear. In case there's animation you need the know is it case 1 or 2. If it's case 2 it will additionally slow you down as you now need to wait until all animations lengths * number of switches toggled has finished.
Looked very promising, but there are some hard blockers:
1. It's not shipping yet, meaning there are no trustworthy reviews.
2. It will be shipped to USA only.
3. It needs apple device for (full) control.