I'm not sure it's our duty to prevent phishing attacks, which depend on user errors rather than software weakness. You're trying to make the point that projects shouldn't be able to find out the username, and I agree, but your example would really be just as nasty if it didn't check the name typed in by the user before recording it.

No because

then why did you disable JS in the first place?

Because it is our duty to fix software weaknesses!

No,you disabled JS because

So, about a week ago, we had our first serious malware attack using users' ability to write JavaScript code in the Snap*!* environment to present users with a fake version of the snap.berkeley.edu web site, with the goal both of collecting passwords and of potentially infecting users' computers.

We've known all along that the JS Function block was a security hole, but our users are generally well behaved and we're not a bank or anything, so I'm pretty sure this was the first real attack (as opposed to benign practical jokes).

starting with pranks all the way to serious fraud and phishing

But you can keep your password safe if you don't connect to the Internet while running this!

Yes, it's true that that attack included a serious mockup of the Snap! front page in an effort to collect passwords, among many other problems.

But your version, still trapped in the Snap! sandbox, can't really mimic a web page. So, again, I don't feel responsible for preventing anyone running a project that has the string "password" anywhere in it.

But this discussion does make me a little less eager to provide a DOM library the way App Inventor and Catrobat do.

Oh yes it only works for new people

So then students wrote programs saying printf("Pass");printf("word: ");

I made something like it. Failed on the password part:/ Snap! 6.9.0 Build Your Own Blocks