GV: see below > On Jul 8, 2018, at 11:25 PM, Steven Githens <[email protected]> wrote: > > Hi Gregg, > > > >> On Jul 5, 2018, at 9:36 PM, Gregg C Vanderheiden <[email protected] >> <mailto:[email protected]>> wrote: >> >> that is what I suspected >> >> that will give Sergio more time to give notice as well. >> >> If I don’t hear anything else by tomorrow - I will proceed with this plan >> and start them both on the 23rd >> >> >> >> ALSO - if anyone sees any holes (including you Tyler) in what Tyler and I >> came up with - and I posted wednesday - as to a plan for going forward with >> DevOp work and deployment - please send tomorrow (Friday). >> >> If I don’t hear anything to the contrary I will move the DevOp & Deployment >> plan I sent out Wednesday from idea to plan over the weekend as well. > > For this, are you referring to the plan that was sent to the UX list last > week? [1] > > I was quite worried about this until I got to the last bullet point that said > it wasn't for NOVA.
GV: Yeah. This won’t do it all for NOVA. I should have mentioned that earlier in the plan probably. > My question is, who is this scenerio for? Internal development and testing? > Demoing? An AJC? A public library? GV: It is for the AJC’s and the public library. (Demonstrations don’t need individual accounts). > > If it is for internal testing and demoing it seems fine, but if it's for any > sort of external use, I think it's going to require quite a lot of extra > logistics such as: > - How are these unique usernames and passwords being handed out? GV: this is being written up for review and Sign off. But basically we provide the user with a unique name, probably something like User22. And an easy to type password like “Orange-chair55” > - How they being generated so people can actually type them? Random > dictionary concatenation so you get usernames and passwords like > "strawberry-asphalt-generation" or "incredible-discernment-flower". [2] GV: yes > - Since there are no identifiers, there is really no way we could reset > somebodies password if they lost it, they'd have to start from scratch. GV: we are also asking for their email - but that information is not stored on our servers - so our servers do not need to be secure. > I'm not sure how the offline email strategy below would actually work to > give someone support if they lost their information. Are the technical > details written up for that somewhere? GV: This is being documented. But yes - if we lose the key sheet we will lose access to their account. So we will have offline backup. Also, all that is being saved at this point is a small number of settings. So even if they did lose their PW and we did lose their name - it would take them a minute or two to set it back up. As soon as the secure server is set up - we will send them a note to change their password - and begin using their email (or the user22 if they like) to sign in. > > I have done some work for authenticating cloudsafe usernames and password > with the Phase II work of the PPT and as part of the preferences server, but > this approach will still need to be propagated to some other parts of the > framework, so we should plan that out carefully and inform the architecture > team about it as soon as possible. GV: Agree actually I think the plan is for the PPT to only be available after you sign in to the Account/CloudSafe — so the login should transfer from the PPT to the account signin. But check with Bern on the latest plan. this part is not finalized or signed off on yet. > While there are some concerns to work out, I think it would be helpful in > that it would force us to finish and test our cloudsafe login and management > capabilities, which would actually get us close to being a project that you > could just clone from github, fire up and run some type of reasonable > demo/impl of. Best gregg > > > Cheers, > Steve > > > > [1] > We already have a working preference server up on Amazon (AWS) that should be > able to handle traffic at the level we would see in Aug- Sept > It is not fully secured - and we will not be securing it further (since that > would majorly distract from the move to the Secure Google implementation > To avoid the security issues - we provide users with unique SignInNames and > Passwords of our own creation > this avoids having any PII like email addresses — and passwords that might > be used by them elsewhere > since all we have after that are settings for some already installed apps - > we won’t have any information that rises to PII that requires more security > than we have now on AWS > we can store a key to the SignInNames that links them to email addresses for > support and lost keys — but that key will not be online anywhere. > This will allow us to implement both the QSS and the Save functions — while > we await the secure Google that we will need for NOVA > > > >> >> >> Thanks much >> >> Gregg >> >> >> >>> On Jul 6, 2018, at 12:31 AM, Tyler Roscoe <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> The plan was for them to start at the same time to optimize onboarding, so >>> I guess they should both start on the 23rd. >>> >>> On Thu, Jul 5, 2018 at 10:29 PM, Gregg Vanderheiden GPII <[email protected] >>> <mailto:[email protected]>> wrote: >>> One can start next week. Sergio >>> One can start on 23rd when his current contract runs out Stepan >>> >>> Let me know when we should start each of them so that we can write up their >>> contracts. >>> >>> thanks >>> Gregg >>> >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] <mailto:[email protected]> >> https://lists.gpii.net/mailman/listinfo/architecture >
_______________________________________________ Architecture mailing list [email protected] https://lists.gpii.net/mailman/listinfo/architecture
