Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sterility Not Working As Expected #100

Closed
bigjosh opened this issue Sep 8, 2020 · 8 comments
Closed

Sterility Not Working As Expected #100

bigjosh opened this issue Sep 8, 2020 · 8 comments

Comments

@bigjosh
Copy link
Owner

bigjosh commented Sep 8, 2020

REPORTED BY @jbobrow:

Looks like I didn’t think to thoroughly test the way sterility was implemented, as I just thought to test how it is working in a number of different scenarios and realized there are some very likely problematic ones.

The desired behavior is that the Blink that is sterile can never transmit its code to another Blink (unless it is of course flashed w/ a developer publish tool). Consider the Blank running "sterile blank sketch” in the following scenario of how the Blinks currently behave, but not the desired behavior:

I have a 6-pack of Blanks, I break them out to play, they animate, look pretty and can be put to sleep. The don’t really do anything else, but they are ready to accept another game to play. I pull our ZenFlow and load it up. It transmits to all of my Blanks and then all of my Blanks are playing ZenFlow. At this point, I pick up one of my Blanks and I hold it down for 3 seconds while alone. This Blanks is running ZenFlow, since it recently learned ZenFlow, and so the Blank enters program mode. This Blank is now ready to teach other Blinks the code it knows, so I attach it and it loads onto all other Blinks and Blanks alike. This code that was shared is the “sterile blank sketch.” At this point I have a lot of Blinks and Blanks that don’t have the ability to enter program mode, so I am stuck. I have to take out a battery to return or find another Blink to program with and get out of this situation.

The desired behavior is the following: A blank that is running ZenFlow when held for 3 seconds should not enter Program mode. It should simply bypass that and go to sleep. Alternatively, if that is not possible, it should enter program mode and immediately cancel it, so there is no chance of propagation of the sterile code. Under no circumstance should someone be able to seed a sterile sketch to other Blinks.

@bigjosh
Copy link
Owner Author

bigjosh commented Sep 9, 2020

@jbobrow So if you alone-long-long-press a blink with sterile built-in game then it would reload the built-in game to be that active game and then go to sleep (it would do this regardless of whether the active game is sterile or not). Good?

@jbobrow
Copy link
Contributor

jbobrow commented Sep 9, 2020 via email

@bigjosh
Copy link
Owner Author

bigjosh commented Sep 10, 2020

Should just go to sleep.

Then how would you get a sterile that has a different game loaded back to the built-in one?

@jbobrow
Copy link
Contributor

jbobrow commented Sep 10, 2020

No need for a Blank to return to its demo sketch. The two ways that you can get back to that state are the following:

  1. Fail a game transmission (i.e. stop midway and then cancel out of it)
  2. Pull the battery and replace.

The goal is for Blanks to play a supporting role unless a developer has updated them to be something else.

@bigjosh
Copy link
Owner Author

bigjosh commented Sep 10, 2020

So "sterility" is a property of a physical tile that makes it so that tile never sends a game as a result of a button press?

If so, then I think the workflow to make a sterile tile would be to program it normally and then do an extra step to neuter it. This would probably be something like running an AVRdude command.

Does that sound right?

@jbobrow
Copy link
Contributor

jbobrow commented Sep 10, 2020

Sterility should not be a permanent aspect of the hardware. It should be a property of the application that it has stored in local memory. This sterility should be recognized while running an application downloaded from another Blink so that it remains sterile. Sterility is only overwritten if the FW is flashed via ISP.

@jbobrow
Copy link
Contributor

jbobrow commented Sep 11, 2020

Putting this one on ice while we user test. There are in fact 2 different features that could be arrived at from this description.

  1. The ability for a game to lock and unlock the ability to enter program mode. This can surely be handy for some fringe games, but not sure we want to promote this kind of behavior since it effectively disrupts the model of the OS for Blinks.

  2. The option of having Blanks ship with the understanding that the sketch on a Blank is not designed to be spread to other Blinks. This is highly contested for good reasons, but is worth testing as I've seen and heard general audiences appreciate the idea the Blanks don't teach games and Blinks with label art do. Will leave this here as a reminder to come back to this idea if/when it feels more relevant.

For the time being, we'll keep one model consistent across Blinks.

bigjosh added a commit that referenced this issue Sep 14, 2020
Closes #100.  More info there.
@bigjosh
Copy link
Owner Author

bigjosh commented Sep 14, 2020

Closing until we can work out how to do this well.

@bigjosh bigjosh closed this as completed Sep 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants