Thanks Steve Can you put a copy of the writeup (of the rules and restrictions for what is captured) into the root of the Onboarding folder?
thanks gregg ——————————— Professor, University of Maryland, College Park Director , Trace R&D Center, UMD Co-Founder Raising the Floor. http://raisingthefloor.org <http://raisingthefloor.org/> And the Global Public Inclusive Infrastructure (GPII) http://GPII.net <http://gpii.net/> > On Mar 26, 2020, at 12:20 PM, Steven Githens <[email protected] > <mailto:[email protected]>> wrote: > > Hi all, > > Short version: > > I’ve put up another personal beta build of the Morphic Capture Tool if anyone > would like to try it. As always this is an in-progress build so don’t use it > on your primary productive windows instance. > > The download and basic instructions are here: > > https://github.com/sgithens/gpii-app/releases/tag/2019-03-24 > <https://github.com/sgithens/gpii-app/releases/tag/2019-03-24> > > As part of refinements for operating remotely, and running on users home > machines, we’ve added the ability to log in with a key on screen 4 if you’re > not keyed in to Morphic already. > > https://user-images.githubusercontent.com/361700/77585767-4800f100-6ea2-11ea-8187-3b3f7c37bc78.png > > <https://user-images.githubusercontent.com/361700/77585767-4800f100-6ea2-11ea-8187-3b3f7c37bc78.png> > > If you don’t have access to a key on our cloud and would like one to test > with, you can email me. ( sgithens AT raisingthefloor.org > <http://raisingthefloor.org/> ) Additionally you can report any comments and > bugs to me ( or on list if it’s general architectural engineering thinking ), > or open a jira and assign it to me. > > More detail: > > As noted above this build adds the ability to key in with an input box and > button, which is an important first step I believe to moving forward with > logging in either via key or username/password from Morphic itself. Until now > we’ve either relied on custom deployment userfolder provisioning, USB sticks, > the task tray dev menu, etc. As part of our move towards completely remote > protocols for both case studies and general users, this is suddenly very > important. (Imagine trying to test wit the capture tool, and fumbling around > with the user over screen sharing plugging USB drives in and out). > > In the instructions you’ll see that only a limited number of settings can > actually be saved to the cloud at the moment, lest you’ll get an error. > After running the capture tool, you’ll see that there are indeed, far far > more settings and solutions captured than we can currently save. A short and > incomplete refresher on why this is. > > Probably one of the most complex and challenging aspects of the GPII has > always been dealing with the interfaces and sometimes odd quirks of the > installed and built-in AT available on computers, and the way they interface > with each other in sometimes very surprising ways. Honestly, tracking and > testing these interactions is much more work than actually writing the > solution entry for them. Because of this, and our desire for AT interactions > to not foul up public machines and users machines, the settings that are > currently allowed for saving in the public cloud have been very thoroughly > testing for unexpected and detrimental combinations of usage, making sure > they are safe for machines. In addition to putting machines in odd states, > solutions also need to thoroughly vetted for other issues, such as something > I like to call SettingsInjections Vulnerabilities, similar in vein to XSS or > SQL injections. If an AT product allows free text settings, and these are > used in some portion of the application, there could be serious security > implications. This is another reason that the settings we currently allow > saving all have strong validation, the text fields are enumerated types, etc > etc. > > Via our Client Credential System, we have the opportunity to allow > configurations for some users that allow saving more AT if and when the need > arises, but for our general public users, the current set remains small, and > while it will expand over time, requires very careful vetting. > > For the Capture Tool Case Studies and testing we will have a special client > credential available to capture all these AT, but the payloads will need to > be reviewed before and if they are used for key-in. > > Enjoy! To the Max! > Steve (Hens) > > > _______________________________________________ > Architecture mailing list > [email protected] <mailto:[email protected]> > https://lists.gpii.net/mailman/listinfo/architecture > <https://lists.gpii.net/mailman/listinfo/architecture> gregg ——————————— Professor, University of Maryland, College Park Director , Trace R&D Center, UMD gregg ——————————— Professor, University of Maryland, College Park Director , Trace R&D Center, UMD Co-Founder Raising the Floor. http://raisingthefloor.org And the Global Public Inclusive Infrastructure (GPII) http://GPII.net
_______________________________________________ Architecture mailing list [email protected] https://lists.gpii.net/mailman/listinfo/architecture
