support

AmazingMech2418 wrote:

NitroCipher wrote:

AmazingMech2418 wrote:

AmazingMech2418 wrote:

Sheep_maker wrote:

MasterOfTheTiger wrote:

Well, kids wouldn't do bad things with Scratch extensions that require a lot of work.

It's not Scratch extensions that the ST is worried about (they encourage sharing Scratch extensions), it's browser extensions. A Scratcher could make an extension and have kids download it

AmazingMech2418 wrote:

So basically, they're worried about ajax post and PHP post.

Yes, and that's a valid thing to worry about; it could send your information (such as what you type while typing in your Scratch password) to someone else's server. If they have your CSRF token, then they can use Scratch APIs to do stuff without your password as if they were signed in to your account

So people can use ajax to hack a scratch account? That could be very dangerous. Maybe any post methods should be blocked in the extensions. I'll now test the code.

IT WORKED!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! THE BLOCKER BLOCKED A TEST EXTENSION!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

You can't just expect them to get rid of ajax and stuff. Sometimes you have to use these features in your code. (I am currently working on an userscript that adds blocks to your backpack) Extensions would have to be reviewed manually. You cant just blindly blanket features.

You can actually make the code very specific and only allow posts to scratch. It would be somewhat difficult though.

if people use remember me they don' type pass

With the advent of Scratch 3.0, I think it is imperative that this be considered. Scratch 3.0 has a lot of ways it could be customized with userscripts, as opposed to Scratch 2, and these could definitely provide a positive impact to the user experience

NitroCipher wrote:

With the advent of Scratch 3.0, I think it is imperative that this be considered. Scratch 3.0 has a lot of ways it could be customized with userscripts, as opposed to Scratch 2, and these could definitely provide a positive impact to the user experience

+1

Yes I love this! Support! I've had an idea like this for a while now, as I wanted direct access to the video buffer in JavaScript in order to have MUCH faster rendering of things without having to use Scratch's slow pen, stamps, and clones for things such as rendering polygons, or cool effects that would have been too slow or simply impossible otherwise, like per-pixel lighting, shadows, and other effects that require individual pixels to be modified. These extensions would allow for blocks that do just that!

NitroCipher wrote:

With the advent of Scratch 3.0, I think it is imperative that this be considered. Scratch 3.0 has a lot of ways it could be customized with userscripts, as opposed to Scratch 2, and these could definitely provide a positive impact to the user experience

Support.

elitheultimate wrote:

Yes I love this! Support! I've had an idea like this for a while now, as I wanted direct access to the video buffer in JavaScript in order to have MUCH faster rendering of things without having to use Scratch's slow pen, stamps, and clones for things such as rendering polygons, or cool effects that would have been too slow or simply impossible otherwise, like per-pixel lighting, shadows, and other effects that require individual pixels to be modified. These extensions would allow for blocks that do just that!

Entirely. It should be at least heavily reconsidered. But we all know that the rule was made specifically to end isOnline.

bump

MasterOfTheTiger wrote:

Entirely. It should be at least heavily reconsidered. But we all know that the rule was made specifically to end xyz.

I'm not that sure.
You could say my subconscious is protecting myself so I don't feel terrible about causing a policy that blocks coding in a coding community, but I honestly think it was not 100% aimed at it. It probably impacted the decision, yes, but I don't think we were that important for them to make such a policy.
This suggestion is pretty much rejected, so I'll use this topic for general discussion: we plan to make a new version of the online/offline extension but as a website. Won't be as cool, but if you help us make it grow, it will
Hopefully we won't cause a website policy.

World_Languages wrote:

MasterOfTheTiger wrote:

Entirely. It should be at least heavily reconsidered. But we all know that the rule was made specifically to end xyz.

I'm not that sure.
You could say my subconscious is protecting myself so I don't feel terrible about causing a policy that blocks coding in a coding community, but I honestly think it was not 100% aimed at it. It probably impacted the decision, yes, but I don't think we were that important for them to make such a policy.
This suggestion is pretty much rejected, so I'll use this topic for general discussion: we plan to make a new version of the online/offline extension but as a website. Won't be as cool, but if you help us make it grow, it will
Hopefully we won't cause a website policy.

I am simply saying that “xyz” probably was getting too intrusive for their comfort. Many people advertised it in their bios, and it was getting huge. The ST may have wondered if “xyz” would start doing other things that they wouldn't like, and would encourage others to make extensions themselves, opening it up to further abuse.

“xyz” was probably influential in their decision.

bump

I agree. I'll see if I can rally some support for this.

Support this sounds awesome! How would this work with the user extention sharing policy though?

--Explosion-- wrote:

Support this sounds awesome! How would this work with the user extention sharing policy though?

As far as I'm concerned, the extension policy is aimed at browser extensions, not Scratch extensions.

Support! Then I could use all the unknown great extensions!

(note: they are allowed, it's just against the rules to promote and advertise them on Scratch)

elitheultimate wrote:

--Explosion-- wrote:

Support this sounds awesome! How would this work with the user extention sharing policy though?

As far as I'm concerned, the extension policy is aimed at browser extensions, not Scratch extensions.

This topic is about browser extensions too.

Some time ago, Paddle2See said the Scratch Team doesn't have time to review userscripts and browser extensions. This means that they probably won't want to do that.

I like your idea that ATers could review browser extensions, but I'm not sure if the Scratch Team would agree (I hope they would).

Bump, even though the post above is a bit of a dealbreaker.

Oh, and look at me with my fancy hax that let me edit a post as a new scratcher ooooO

Would every single update for an extension have to be manually re-reviewed? That seems like the only safe way to go about this and yet it sounds like it would take forever.

I feel that it would be too hard to re-review the extension if it gets changed, as that was (i believe) one of the leading problems as to why they stopped the “submit your website to be reviewed” topic.

The Scratch Team would also be waaaaay too overworked to implement this, I suppose it wouldn't be as big as the websites topic, but it would certainly take up some time.