Scratch

Are you using v1.2.1 of scratch?  I thought that the security issues had been fixed in that release.  If you are still using v1.1, try switching to v1.2.1

Microsoft security is some of the worst designed in the industry.  It should not be *possible* for an application program to defeat security so accidentally, but the Scratch team has tried in v1.2.1 to add the "security" that Microsoft is missing.

Microsoft relies on hiding drives for security, then allows application programs to see the hidden drives.  That's not security, that's just obscurity.  asking every software developer in the world to provide security because they can't be bothered to do it right is just laziness (or incompetence) on Microsoft's part.

Thanks Jens for your reply.
As already stated we have tried modifying the scratch.ini file with very little success.
We don't rely on 'obscurity' we are just following a standard Microsoft protocol for a locked down network, which is required by many secondary schools etc.

Gonna pop in here.  I was involved with the previous drive problem and not really had much time to play with Scratch until recently but have given up again until the next version where more admin customisation is apparently coming
The problem is that Scratch doesn't follow it's own security, never mind Microsoft.  I have hidden all drives except the users document drive and a shared work area.  As soon as Scratch is started & save or open pressed the user is directed to the C: drive (supposedly hidden by scratch) which they can navigate.  I tried installing Scratch to a public drive so that it didn't matter that users could look around and they can still get at C: drive by clicking the Documents drive.  This takes the user to the Documents and Settings folder on the hard drive.  Now considering this isn't even used by our users this is a very strange redirection.  All our network settings have been changed to direct the user to their Work drive so why this Documents button does this we do not know.
  This isn't a chance to bash MS, but a chance to help develop Scratch as we do really want to use it.  As Noser has said every other application we have seems to follow standards and only show the correct drives, even littel apps we create ourselves.  The last time we had this problem was with 16 bit apps or those that tried to create their own file interface.  The latter is why Scratch falls down, it is using its own file interface.  Security is still intact (users can't write to areas they don't have access to) but they are let wander in random areas & can write to areas by accident that have to be left open to allow normal running (Documents and Settings for example).
  As for the obscurity, it isn't a good security mechanism but it does help stop random wandering or accidental saving in random areas.  This is what we are trying to stop in a school.  You can not imagine how many hours are wasted by students losing their work in their own areas let alone on random drives if they could.
  Now I haven't used Linux or OSX in a networked environment so can't compare to what happens in the same circumstances (if someone knows it would be nice to hear, actual experience not it shoulds) but do they really manage to hide drives from scratch that aren't needed?

When you're discussing security, let's not forget that Scratch is probably a lot more secure than any other software you might be using precisely *because* it has its own file system interface, which - unlike the standard windows file dialog - doesn't allow users to delete anything or even change the standard file name extensions to anything other than *.sb or *.sprite or graphics/audio.

Plus, the Scratch 'language' itself has no file access command blocks whatsoever, and is plain unable to control any periphery settings (it can't even change the screen resolution or access a printer), and cannot produce any standalone executables, thus making it in fact impossible to do any harm to any computer / network.

You can actually damage to your system much more by just writing a plain old DOS batch file in the windows notepad.

Even if you do manage to 'break into' the Squeak IDE there's a lot that's disabled there, for example Squeak's 'Foreign Function Interface (FFI)' has been completely taken out. So I really cannot follow some of the security concerns brought up recently, although I have to agree that it would certainly be nice if the scratch.ini settings did work correctly, which doesn't seem to be the case.

Thanks for the replies. 
@kevin_karplus: As I said, I don't want this to be an OS comparison but just so you know, if I set a user or group of users to not be able to read a folder on our network there is no way they can get to it either.  The problem here is areas that are needed for writing to but the user has no need to see or go to.  Places like the Program Files area where apps are installed.  A user has to have read and write permissions for the app to run but we don't really want them wandering in there saving stuff. Using any other application on the network student users are limited to areas we want them able to see but they do have 'access' to other areas purely because they need to for day to day running.

@Jens:  I think it has been blown up slightly as a security issue.  That users can access areas that to all intents and purposes they have had hidden for them sounds security related but they do have access to them so nothing is really being broken.  It is just the standard Windows file dialogues that are being avoided so an extra layer of rules.  You are correct that in fact it is slightly better than if this was possible in a windows file box as nothing can be done to files (renaming, deletion, copying, moving etc) but in a school, as I have said, all things are interesting so being able to explore will lead to  some finding hidey holes that files can be stashed, folders that exes could possibly be run from etc.  It also allows students to have a higher possibilty of losing work.  As I have said before, if there is an option of a sensible place to save a file or a non sensical one a high proportion will pick the non sensical one and an even higher proportion will forget they have done that and a another proportion will deny they saved elsewhere and that it must be the system it always eats their work, it hates them, eveyone is out to get them, ARGGGHHHHHH.  Or something along those lines.  This is what we are trying to avoid.

thanks again.

Last edited by PriorySchool (2008-01-16 04:57:21)

Hi, PriorySchool.

I just read through this thread again, especially your posting, which clarified the issue of where the "desktop" and "documents" shortcuts go. It sounds as though they do go to the correct places (i.e. subfolders of the "Documents and Settings" folder) but that those places are not used in your setting. And, what's more, those places might actually be on a drive that you don't want users to see at all.

So it sounds like the problems for PriorySchool and others stem from a combination of  two things:

  1. Once you are in a particular folder, the Scratch file dialog allows you to navigate up the folder hierarchy from that folder, ultimately allowing exploration of the entire drive (except hidden files and folders).

  2. Scratch lets the user get to folders from which this navigation process can be started such as:
    a. the Scratch media and sample projects folders
    b. shortcuts to the user's desktop and documents (normally unused in your network).

Does this description accurately capture the problems people are seeing (anyone can chime in here, not just PriorySchool)? Are there any additional issues?

I have no experience with school networks. If the user's desktop and documents folders are not used, where do users save their documents? Is there some way of automatically computing a path to the folder where they should be saving their Scratch projects?

  -- John

Last edited by johnm (2008-01-16 09:47:22)