Password locked lists

einangrun

There should be a way to lock lists in the Scratch editor. You could create a password and from then on you and others would only be able to access the list by typing in said password.

Much like Cloud data, the feature would probably only be available to Scratchers (not New Scratchers) who have earned their status and proven that they are responsible members of the community and will hopefully not misuse the feature.

Pros:

Would allow blacklists to be created without other users being able to see the words blacklisted

Could provide a way to safely store users' passwords and usernames within a cloud-based game featuring logins

Cons:

Might allow users to purposefully hide important data from others, especially to prevent remixes in one way or another, which would be against the CG's - obviously this would be disallowed and reportable

Please tell me if this is a duplicate or has been rejected and I will close this topic

Last edited by einangrun (Sept. 19, 2017 23:43:28)

aking_

This would be a win-win-win because I count your con as a pro because keeping people from remixing the exact same thing would be incredible. Support.

Water

FancyFoxy

1. This allows for PMing, which is rejected.
2. This goes against the “Share” aspect of a project.

No support.

einangrun

FancyFoxy wrote:
1. This allows for PMing, which is rejected.

Didn't think of that, hm. We'd maybe have to figure out some way to not let multiple users access the same list? Or maybe Scratch Team members could view the contents of password locked lists and if any inappropriate activity occured such as bullying, gossiping, etc., the project would be removed and the users would receive an alert.

FancyFoxy wrote:
2. This goes against the “Share” aspect of a project.

No support.

How? I already said any usage of this feature that hid important data from others that could be used to further understand or remix the project would be reportable. It should also probably be something only available to Scratchers so responsibility would be a factor. Adding that to the main post.

Last edited by einangrun (Sept. 19, 2017 23:44:59)

FancyFoxy

einangrun wrote:
FancyFoxy wrote:
2. This goes against the “Share” aspect of a project.

No support.
How? I already said any usage of this feature that hid important data from others that could be used to further understand or remix the project would be reportable. It should also probably be something only available to Scratchers so responsibility would be a factor. Adding that to the main post.

The thing is, when you share a project, you are allowing anyone to see what you did and remix. If you hide data with a list, you are preventing them from changing certain things that they want to change in the remix.

einangrun

FancyFoxy wrote:
einangrun wrote:
FancyFoxy wrote:
2. This goes against the “Share” aspect of a project.

No support.
How? I already said any usage of this feature that hid important data from others that could be used to further understand or remix the project would be reportable. It should also probably be something only available to Scratchers so responsibility would be a factor. Adding that to the main post.
The thing is, when you share a project, you are allowing anyone to see what you did and remix. If you hide data with a list, you are preventing them from changing certain things that they want to change in the remix.

If it is used only for security purposes such as keeping peoples' usernames and passwords safe or creating non-viewable blacklists, then I see no reason that it would limit your capability to remix. Only a few things that you probably shouldn't have access to anyway would be unchangable.

Without password locked lists, there's no real way to make safe blacklists or protect someone's information, so these things among others are typically not included in projects anyway. With password locked lists, you could include these things but only you would be able to view them in order to keep them contained. Without, they're not in the project at all so people can't see or modify them. With, they're in the project but kept safe behind a lock so people can't see or modify them. Which is better?

braxbroscratcher

einangrun wrote:
FancyFoxy wrote:
einangrun wrote:
FancyFoxy wrote:
2. This goes against the “Share” aspect of a project.

No support.
How? I already said any usage of this feature that hid important data from others that could be used to further understand or remix the project would be reportable. It should also probably be something only available to Scratchers so responsibility would be a factor. Adding that to the main post.
The thing is, when you share a project, you are allowing anyone to see what you did and remix. If you hide data with a list, you are preventing them from changing certain things that they want to change in the remix.

If it is used only for security purposes such as keeping peoples' usernames and passwords safe or creating non-viewable blacklists, then I see no reason that it would limit your capability to remix. Only a few things that you probably shouldn't have access to anyway would be unchangable.

Without password locked lists, there's no real way to make safe blacklists or protect someone's information, so these things among others are typically not included in projects anyway. With password locked lists, you could include these things but only you would be able to view them in order to keep them contained. Without, they're not in the project at all so people can't see or modify them. With, they're in the project but kept safe behind a lock so people can't see or modify them. Which is better?

For blacklists, honestly they should just add a

<[...] is filtered?>

block.

Also, encode the data and store it as a bunch of meaningless characters (Such as ASCII art characters)

Charles12310

FancyFoxy wrote:
1. This allows for PMing, which is rejected.
2. This goes against the “Share” aspect of a project.

No support.

1. Only the creator can see the block. No one else.
2. I agree.

However, I do see it useful for keeping secret information only the user that made the info could see to prevent hacks in the project, and to hide blacklists.

Semi-Support

Charles12310

Charles12310 wrote:
FancyFoxy wrote:
1. This allows for PMing, which is rejected.
2. This goes against the “Share” aspect of a project.

No support.
1. Only the creator can see the block. No one else.
2. I agree.

However, I do see it useful for keeping secret information only the user that made the info could see to prevent hacks in the project, and to hide blacklists.

Semi-Support

Simulation:

einangrun

Charles12310 wrote:
1. Only the creator can see the block. No one else.

Not necessarily, if a friend or family member was told what the password was, it would allow for PMing, which is something we'd have to find a way around.

Your simulation is not exactly what I was planning for, but I suppose that would work. I was thinking more like a password input instead of an OK button, because the owner, too, would not be able to access the list until he or she inputs the password again. Much like logging into your account, except without the username.

Also I hate you for that last line in your signature

Charles12310

einangrun wrote:
Charles12310 wrote:
1. Only the creator can see the block. No one else.

Not necessarily, if a friend or family member was told what the password was, it would allow for PMing, which is something we'd have to find a way around.

Your simulation is not exactly what I was planning for, but I suppose that would work. I was thinking more like a password input instead of an OK button, because the owner, too, would not be able to access the list until he or she inputs the password again. Much like logging into your account, except without the username.

Also I hate you for that last line in your signature

1. There would be no cause of PM if nobody was able to access the locked lists in any ways, I thought you were suggesting it without a password, but I can't be sure.
2. I assume that might be an idea.
3. LOL.

einangrun

bring up my post
pump up the jam
etc.

Charles12310

Charles12310 wrote:
einangrun wrote:
Charles12310 wrote:
1. Only the creator can see the block. No one else.

Not necessarily, if a friend or family member was told what the password was, it would allow for PMing, which is something we'd have to find a way around.

Your simulation is not exactly what I was planning for, but I suppose that would work. I was thinking more like a password input instead of an OK button, because the owner, too, would not be able to access the list until he or she inputs the password again. Much like logging into your account, except without the username.

Also I hate you for that last line in your signature
1. There would be no cause of PM if nobody was able to access the locked lists in any ways, I thought you were suggesting it without a password, but I can't be sure.
2. I assume that might be an idea.
3. LOL.

einangrun

Something like that, yes! More feedback would be great, it's still a developing idea and we'd have to find a fix for possible PM'ing - maybe you're right and it would be better if they were just locked and only the owner had access.

Warriorbuilds3

Hmmmmm…
It seems people are having some heated debates. Although, it would be cool to have this and it would be SO MUCH EASIER TO MAKE A PASSWORD SAVER, it seems like people could try using this to spread inappropriate content. I mean, one of you guys said that only the creator could edit the list right? That means that people could put lots of bad words in the list for everyone to see. And since I'm assuming that it remembers everything that's put in it, that means that the only way people could get rid of it is to report it. But by then they could have already been exposed to it.
But, then again, what do I know?
I'm having trouble deciding whether or not I should support this.

braxbroscratcher

Warriorbuilds3 wrote:
Hmmmmm…
It seems people are having some heated debates. Although, it would be cool to have this and it would be SO MUCH EASIER TO MAKE A PASSWORD SAVER, it seems like people could try using this to spread inappropriate content. I mean, one of you guys said that only the creator could edit the list right? That means that people could put lots of bad words in the list for everyone to see. And since I'm assuming that it remembers everything that's put in it, that means that the only way people could get rid of it is to report it. But by then they could have already been exposed to it.
But, then again, what do I know?
I'm having trouble deciding whether or not I should support this.

View priviledges would be passlocked too…

_nix

A few things about this idea..

First off, do these lists act the same as cloud variables? – That is, is the actual data stored in the list the same on every computer, and, when it's changed (by any user with the password to that variable), does every computer see that it's changed?

You say that only people with the password can access the list. But then.. is it that different from a text file stored on a shared file server (like Google Drive's permission-required files)?

Maybe that sounds silly, but.. if only people with the password can view or edit the list's contents, then normal users would need to have that password to run the project at all, too. You might make a script like this:

define add clever message
ask [What's your clever message?] and wait
add (username) to [locked list v]
add (answer) to [locked list v]

define show clever message
set [parse v] to [1]
repeat (10)
  if <(item (parse) of [locked list v]) = (username)> then
    say (join [Your clever message: ] (item ((parse) + (1)) of [locked list v]) for (2) secs
    stop [this script v]
  end
  change [parse v] by (1)
end

Can you guess the problem with it?

What if you click on “see inside” and drag out a “item (1) of (locked list)” block. The result would be.. well, whatever item is first in the list? If that's how your idea works, then it's clear that anybody could access any of the data in a locked list, just by dragging out the blocks needed to do so. Sure, they might not be able to click on the “show this list” checkbox, but they could still view the contents of it. So that wouldn't be secure for storing a list of passwords or secret messages!

jromagnoli

einangrun wrote:
FancyFoxy wrote:
einangrun wrote:
FancyFoxy wrote:
2. This goes against the “Share” aspect of a project.

No support.
How? I already said any usage of this feature that hid important data from others that could be used to further understand or remix the project would be reportable. It should also probably be something only available to Scratchers so responsibility would be a factor. Adding that to the main post.
The thing is, when you share a project, you are allowing anyone to see what you did and remix. If you hide data with a list, you are preventing them from changing certain things that they want to change in the remix.

If it is used only for security purposes such as keeping peoples' usernames and passwords safe or creating non-viewable blacklists, then I see no reason that it would limit your capability to remix. Only a few things that you probably shouldn't have access to anyway would be unchangable.

Without password locked lists, there's no real way to make safe blacklists or protect someone's information, so these things among others are typically not included in projects anyway. With password locked lists, you could include these things but only you would be able to view them in order to keep them contained. Without, they're not in the project at all so people can't see or modify them. With, they're in the project but kept safe behind a lock so people can't see or modify them. Which is better?

Keeping passwords safe is easy. Just encrypt them and hide the code for the encryption. As for blacklists, they don't block out everything, so its easier to make a whitelist.

_nix

(Did you know, though – if you want to make a blacklist, the (literally!) best solution is to use a “hash” formula? Basically it's a piece of code which takes one piece of text and turns it into another piece of text, which looks like garble, and is impossible to be converted back into the original piece of text? So, you store that garble-text inside the project – and not the original bad words – and then you make your program run the hash on the inputted text, and if the text's garble-text-version is the same as the badword-garble-text, then the user inputed the bad word, and you can stop the message from being sent or such.)

_nix

jromagnoli wrote:
Keeping passwords safe is easy. Just encrypt them and hide the code for the encryption.

How would that work? And are you confusing encryption with a hash? Hashes are when you literally cannot convert the resulting text back into the original text. With encryption, it's technically possible to convert the resulting text back into the original text. (Since you don't want people to see other peoples' passwords, that's why it's so important to use a hash instead of a plain old encryption function when you're dealing with passwords.)

Also, why would you hide the code for the encryption? The whole point of encryption (and hashes) is that the resulting string is garble, and that you can't easily (or at all, in the case of hashes) get the original string, even if you have the encryption code. (As long as you're using secure encryption code. If you're using insecure, or really fast, encryption code, then it's easy enough for bad people to hack it and get the original text.)

Discuss Scratch