--- Forwarded Message from Bob Majors <[log in to unmask]> ---

>User-Agent: Microsoft-Entourage/10.1.1.2418
>Date: Tue, 18 Feb 2003 15:17:27 -0800
>Subject: Re: #7035.4 Securing MP3 in language labs (1)
>From: Bob Majors <[log in to unmask]>
>To: Language Learning and Technology International Information    Forum   <[log in to unmask]>
>In-Reply-To: <[log in to unmask]>

------------------
> I am not sure but I think the problem originally articulated had to do with
> a Divace (Tandberg) lab (that is, one in which students are supposed to use
> Divace and nothing else to play the media) where the media is on a shared
> server, not on the Web. That is, it is material that is essentially being
> delivered in a face-to-face classroom situation, and should not be copied
> or copiable.
> 
> I would say it might be easiest to make sure that the files are too large
> to be easily copied. If the student computers have CD burners, this would
> not help, but if the students don't have easy access to a copying device
> for large files they can't copy them.
> 
> Judy Shoaf

Thanks for the reference to the original post.  We also faced/face this
issue with Sony language lab software, and it is an issue for any system
relying on non-streamed and/or non-encrypted files.  For an application to
play a file, it has to have a computer (typically a server) name and file
path(name).  If a program could do this as a (Windows) service, then
permissions could perhaps be separated out from the context of the user.  I
looked briefly into this, and it might be possible, but I didn't have the
time and possibly not the skill needed to pull it off.  Currently, the
application (Soloist in our case) uses the permissions of the user (this is
how most apps work in Windows I think), therefore the audio files are
Readable by the student.  If they are readable, then they can be copied to a
USB device plugged into the computer, moved by FTP or Windows to another
server, etc., and large files pose no problem to the student.  There are
measures that can be taken, such as no restricting access to hardware and
programs (via Windows Group Policy, restricting access to just computers
that are controlled by your Group Policy settings, (password protected) BIOS
settings, etc.) -- one would have to look very carefully to make sure there
are no loopholes.  I also looked at creating the minimal audio file
permissions needed for an app to play a file, such as Read and Traverse (but
no List), but never came up with a perfect solution.  I think that some more
generalized solutions might lie in one or more of the following:
applications running as services, with separate permissions from the user
and possibly also some sort of shortcuts/ reference files to separate what
the user sees when browsing for a file to play vs. its actual location;
streaming audio (although streaming may not work for every situation);
possibly publishers not being concerned; and/or encryption.  Encryption may
be the cleanest solution, although for wide-spread, feasible use by language
learning facilities, I don't think we're there yet.

Bob Majors
Langauge Learning Center
University of Washington