g Gregg C Vanderheiden [email protected]
> On Oct 6, 2017, at 12:05 PM, Li, Cindy <[email protected]> wrote: > > Comments inline as well. > >> On Oct 6, 2017, at 11:39 AM, Gregg C Vanderheiden <[email protected] >> <mailto:[email protected]>> wrote: >> >> Comments in line >> >> g >> >> >> >>> On Oct 6, 2017, at 10:31 AM, Li, Cindy <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Thanks for the input, Greg. Please see my comments below: >>> >>>> On Oct 6, 2017, at 2:11 AM, Gregg C Vanderheiden <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>>> On Oct 5, 2017, at 3:02 PM, Li, Cindy <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Hi, Steven Githens and everyone, >>>>> >>>>> The topic might seem scary but hopefully you will think differently after >>>>> reading their use cases. >>>>> >>>>> This question was brought up at creating the new GPII data model >>>>> <https://wiki.gpii.net/w/Keys,_KeyTokens,_and_Preferences> based on >>>>> requirements from “keys and key tokens” document >>>>> <https://docs.google.com/document/d/1UoJzaEVFXEVA_CBfA5WNUHn9Y3j4JSy3tHvqeg19N1k/edit>. >>>>> What shows so far is OAuth2 authorization code and client credential >>>>> grants are not being used by any real use cases, which means we could >>>>> potentially remove their support from the universal repo to simplify the >>>>> new data model. I’m sending this email to the team to find out if this >>>>> understanding is correct, or if there are possibilities that they are >>>>> still needed in the near future. >>>>> >>>>> 1. Use case where OAuth2 authorization code grant is needed: >>>>> >>>>> One use case in the near future this grant could be used is the >>>>> deployment of PMT. The question is, which method will be used to deploy >>>>> PMT: >>>>> (1) Will it be deployed as one single centralized GPII hosted website >>>>> that runs behind GPII firewall, has direct access to GPII Cloud database, >>>>> just as a part of GPII Cloud? >>>>> (2) Or, will it be deployed and managed outside of the GPII org. It will >>>>> then access cloud data via APIs provided by GPII Cloud. Or even multiple >>>>> PMT sites could exist to access one single GPII Cloud? >>>>> >>>>> (1) doesn’t need the use of OAuth2 authorization code grant and (2) might. >>>> >>>> >>>> GV2: The only thing that should be accessing the preferences are web apps >>>> that we create (or we control — i.e. they are reviewed by us and run under >>>> our control). >>>> >>>> The PMTs are included in this. >>>> The Discovery tools are included in this >>>> The explore tools are included in this. >>>> Even PSP (aka PCP) with memory is included in this — since the PSP with >>>> memory sends the information to OUR cloud - and our cloud opens the safe >>>> and writes it. The local computer never has access and cannot see the >>>> preference sets. In fact it actually doesn’t know if our cloud writes >>>> what is sent from the local computer — or if it modifies it in some way, >>>> normalizes it in some way, before it writes it into the preference safe. >>>> >>>> The BIG security hole we have — is that web apps are rendered on the local >>>> computer - and the local computer can therefore see what is displayed >>>> there. >>> >>> Even for apps or websites that are created and controlled by us, the way >>> GPII Cloud authenticate and authorize them could be different depending on >>> how they are deployed or used. For example, the security guard for a >>> central website hosted by GPII would be different from GPII apps installed >>> on users’ machines. >> >> >> GV: The concern I have is for apps that are in the cloud. Even if you run >> the app on our secure servers, if the user is using a browser to look at >> their preference settings — the preference setting data is displayed on the >> local computer — and local computer software can see (and capture) all of >> that information. If it can’t - then local AT won’t work— so we have a >> catch-22. Don’t we? >> >> >> That is the security hole I am talking about. and I think it is structural >> / functional. I don’t see a way around it other than to never allow a >> user to view their preferences except on a ‘trusted’ computer - whatever we >> decide that is. And then it is only as secure as the ‘trust’ is good. >> Mind bender. > > Understand your concern. It’s complicated enough to use a separate topic. > >> >> >>> >>>> >>>>> >>>>> I looked into Steven Githens’ dev PMT work >>>>> <https://github.com/sgithens/gpii-devpmt/tree/GPII-2452>, at the moment >>>>> it’s reading/writing preferences from json files on the file system. I’m >>>>> not sure if its deployment has been thought about. Please chime in if >>>>> anyone has ideas. >>>>> >>>> >>>> GV2: what file system are you referring to? We are temporarily >>>> running “our cloud” on the local computer. but that should end soon. >>> >>> The file system refers to the file system provided by the operating system, >>> on developers’ computers in this case. When a tool is at the development >>> stage, we usually start by reading/writing data from our own machines >>> instead of relying on a remote cloud support. I believe Steven’s PMT work >>> will eventually connect with GPII Cloud when it’s ready. >> >> >> GV: Correct. all of the preference tools - when used by users - should be >> web apps running in our controlled and secure space. If anyone knows of >> anything that doesn’t look like it would fit this model/statement let me >> know. thx >> >> >> >>> >>>> >>>>> 2. Use case where OAuth2 client credential grant is needed: >>>>> The only use case is First Discovery Tool, which is not really in use as >>>>> far as I know. Please let me know if anyone has a real case of First >>>>> Discovery Tool running. >>>> >>>> GV2: Not sure if it matters. It will be a cloud app — running under our >>>> control. That puts it in the category that you don’t care about - yes? >>> >>> It still matters as to my first comment. >>> >> >> GV: I don’t follow. If all preference tools (including FD tools) are cloud >> tools — then they fall into your category 1 — and are the same concern or >> non-concern would apply. No? > > Although all preference tools are cloud tools that controlled by us, they > don’t necessarily fall into category 1. An example is GPII apps installed on > users’ computers. These apps use cloud APIs to read and help PCP with memory > to write to the cloud. OAuth is required to protect these APIs. (PCP is now PSP) Right. 1) My comment was - and my understanding is that the GPII local app (including its PSP) will be the only app that is running on the local computer. all of our other programs will be running in the cloud. And even that (the local GPII software) would not have any access to the preferences. It would only see “setting commands” that are sent down from the Cloud GPII - and these setting commands may reflect some of the user’s preferences or may just be MatchMaker interpretations of what the best settings are based on the user’s preferences. 2) The exception to this would be if someday we implement preferences stored on local token - in which case we would then have local software doing interpretation of preferences 3) There is an exception to the exception where the preferences would be passed as an encrypted package up to the cloud for decryption and processing. This would solve one problem but would mean that the user’s preferences would be passed to the cloud which would preserve a privacy advocate from having their preferences stored in the cloud but would not keep their preferences from ever getting to the cloud and it would not work for computers that are not connected to the internet. so if we want someday to support ‘non-internet-connected’ auto-personalization then we will at that time have to worry about exposure of the person’s preferences to the computer. When we raise this we will need to think about the security implications of this. It may be a combination of new security measures at the local software level - combined with additional consent/awareness on the part of users who want to use this. But for now — we are only implementing (1) above. And for the future — we should think/talk about (2) and (3) to see what we can/want to do there thanks Cindy > >> >> >> >> >> >> >> >> >>>>> >>>>> Once GPII Cloud stops supporting OAuth2 client credential grant, the >>>>> front end of First Discovery Tool will continue to function except at the >>>>> last step it won’t be able to create new preferences sets on GPII Cloud. >>>> >>>> GV2: I presume you mean some old FD tool - yes? >>> >>> I meant the FD tool in this demo >>> <https://build.fluidproject.org/first-discovery/demos/>. It was created 2 >>> years ago. Do you know if it’s in use somewhere? >> >> >> GV: It is not being used anywhere that I am aware of. >> Use of it is not on any APCP roadmap (though things we learned from >> it are being used and code or widgets from it will likely be used). > > This information very helpful. Thanks. >> >>> >>>> >>>>> >>>>> Steven Githens again, I remember you did some work to demo First >>>>> Discovery Tool on your machine. Do you need OAuth2 client credential >>>>> grant continue to be supported? >>>> >>>> GV2: I believe that was not a real FD tool, but just a tool to let the >>>> libraries play with some settings on their demo machines. (which were run >>>> locally so that would have written to the local machine.) but that is >>>> not the model going forward. >>> >>> Good to know it’s not writing to the cloud. >> >> GV: It currently isn’t. But its successors will run in the GPII secure >> cloud and write to the GPII secure cloud. (i.e. it’s successors will be >> GPII Preference Tools and follow all of the PT rules ) >> > I guess its successors will be other tools like PCP or PMT instead of the > same tool being hooked back up with GPII Cloud? > >> >>> >>>> >>>>> >>>>> Look forward to your input. Thanks. >>>> >>>> GV2: Does that help? >>>> >>>> (still need to discuss the security problem with web app being visible to >>>> local computer. ) >>> >>> Yes, this helps. Thanks, Greg. >>> >>> I agree the concern of web app being visible to local computer worths >>> another topic. >> >> GV: Yea — this one has me stumped. If we make it local AT accessible — >> by definition software on the local computer can access the information >> too….. >> >> >> >>> >>>> >>>> >>>>> >>>>> Cindy >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.gpii.net/mailman/listinfo/architecture >>>>> <https://lists.gpii.net/mailman/listinfo/architecture>
_______________________________________________ Architecture mailing list [email protected] https://lists.gpii.net/mailman/listinfo/architecture
