Hi Gregg,


> On Jul 5, 2018, at 9:36 PM, Gregg C Vanderheiden <[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.  My question is, who is this scenerio for?  Internal 
development and testing?  Demoing? An AJC? A public library?

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?
- 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]
- 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.  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?

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.  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.


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]
> https://lists.gpii.net/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[email protected]
https://lists.gpii.net/mailman/listinfo/architecture

Reply via email to