Locking the cards

[Samuel]

Hello:

Would it be possible to lock the cards so that no one could add,
change, or alter the content of any card except the creator?

Thank you,

Samuel

[Jesse]

2009/11/13 Samuel <samuelthom...@gmail.com>

Mnemosyne is currently a single-user system, and does not keep track of the creator or anyone else for that matter.

I'm guessing you want to do this in a school environment (or something similar) and don't want the students to change the cards? If so, this is not currently possible with Mnemosyne.

--
Jesse Weaver

[Jason Axelson]

Maybe alternatively you could create one deck for each student?

[Samuel Morrison]

Thank you for the response.

 

Yes, I don't want students to change the cards. I have over 80 students per month, every month, who also leave every month. That is about 1000 separate decks.

 

Also, I don't want someone form Flashcardexchange profiting from my work.

 

Please think about it. I am not interested in putting my name on the cards. I would just like some encryption or password protection.

 

Thanks

[Gwern Branwen]

On Sat, Nov 14, 2009 at 8:27 PM, Samuel Morrison
<samuelthom...@gmail.com> wrote:
> Thank you for the response.
>
> Yes, I don't want students to change the cards. I have over 80 students per
> month, every month, who also leave every month. That is about 1000 separate
> decks.

It doesn't make a whole lot of sense to have 80 students share the
same deck. The whole point of SRS is customization and long-term
retention; how can that work if students stay 1 month and are stomping
on each other's reviews? One person, one deck. But maybe you're not
explaining your situation well.

> Also, I don't want someone form Flashcardexchange profiting from my work.

You can host the cards on the Mnemosyne website if you prefer.

> Please think about it. I am not interested in putting my name on the cards.
> I would just like some encryption or password protection.
>
> Thanks

Short of Mnemosyne as a web service, that cannot be done. Editing the
deck is the exact same thing as doing reviews. The one file
mnemosyne.mem holds the card and its metadata (like last grade,
hardness, etc.) You cannot give the user/Mnemosyne-program permission
to write/modify the mnemosyne.mem and also not give them permission to
write/modify it.

It's the same contradiction which renders DRM in general a pipe dream.
Worse, any attempt to convert Mnemosyne to do some sort of ad hoc DRM
will badly impact usability and complexify the program, where it isn't
outright harmful. (A program which can lock data against students can
lock it against you. If you've put years of effort into your SRS, the
slightest risk of data loss should make you break out into a cold
sweat.)

--
gwern

[Samuel Morrison]

It doesn't make a whole lot of sense to have 80 students share the
same deck. The whole point of SRS is customization and long-term
retention; how can that work if students stay 1 month and are stomping
on each other's reviews? One person, one deck. But maybe you're not
explaining your situation well.

 

The students do not share the exact same deck, but get their own copy of the same deck on shared computers at school

Right now students can enter and change another students deck--why? Because they are students.

I need to have control over the content. Otherwise some students can fail quizes because of missing vocabulary, or claim they failed because the class bully deleted cards.  I need to stop any malicious tampering with decks. There needs to be some kind of protection. I also do not allow any Internet connection at school during class.  

 

 

 

> Also, I don't want someone form Flashcardexchange profiting from my work.

You can host the cards on the Mnemosyne website if you prefer.

> Please think about it. I am not interested in putting my name on the cards.
> I would just like some encryption or password protection.
>
> Thanks

Short of Mnemosyne as a web service, that cannot be done. Editing the
deck is the exact same thing as doing reviews. The one file
mnemosyne.mem holds the card and its metadata (like last grade,
hardness, etc.) You cannot give the user/Mnemosyne-program permission
to write/modify the mnemosyne.mem and also not give them permission to
write/modify it.

 

 

I do not want to give them permission to modify it. They have no need to modify the deck in any way. Also, I do not use the program to collect data on their score or grades. It is a tool to use to train them  in vocabulary before in class quizes.

 

It's the same contradiction which renders DRM in general a pipe dream.
Worse, any attempt to convert Mnemosyne to do some sort of ad hoc DRM
will badly impact usability and complexify the program, where it isn't
outright harmful. (A program which can lock data against students can
lock it against you. If you've put years of effort into your SRS, the
slightest risk of data loss should make you break out into a cold
sweat.)

 

 

I have no idea what DRM is. I am not afraid the program will lock against me. I have all my vocabulary saved as word, text, and then as decks. If the decks disappear, well, I have to reload the data on each computer and for each student, but my words are not gone.

 

 

So, in layman's terms, it is impossible to protect my vocabulary from being ripped off the Internet, loaded on a computer, have some words altered, and resaved as the exact same deck?

 

Thank you

 

 

--
gwern

[Charles Cave]

It seems to be that flashcards are not the appropriate teaching medium
for your students. Flashcards are for people motivated for self-paced,
efficient learning. Are your students following a spaced repetition strategy
which is the basis of Mnemosyne, or are you looking for an assessment tool?

[Oisín]

2009/11/15 Samuel Morrison <samuelthom...@gmail.com>:

> The students do not share the exact same deck, but get their own copy of the
> same deck on shared computers at school
> Right now students can enter and change another students deck--why? Because
> they are students.
> I need to have control over the content. Otherwise some students can fail
> quizes because of missing vocabulary, or claim they failed because the class
> bully deleted cards.  I need to stop any malicious tampering with
> decks. There needs to be some kind of protection. I also do not allow any
> Internet connection at school during class.

Hi Samuel,

No offense intended, but I think the fundamental problem you need
solved is not within Mnemosyne's scope - it is in your school's
computer system where students share computers with no individual
logins or protected filespace.

The correct solution is for each user to have a personal login with
their own private and protected filespace. This is the responsibility
of an operating system really; not Mnemosyne or the other applications
students use.
If you don't have control over the issue of individual accounts, then
the next best thing is to provide some kind of individual filespace,
be it through some kind of network/internet host like Dropbox, or
setting up some ssh accounts somewhere and using Reddrive or
equivalent to mount users' filespace as a virtual disk, or simply
providing each student with their own USB key (of course, they could
conveniently lose this and say someone stole it, but there's only so
much you can do... you could enforce rules on how they take care of
their keys, maybe not leaving the school with them).

Hacking some kind of protection scheme into Mnemosyne is not the
appropriate way to go IMO.

Oisín

[David A. Harding]

On Sat, Nov 14, 2009 at 11:52:08PM -0500, Samuel Morrison wrote:
> I need to stop any malicious tampering with decks.

Your system administrator can setup password-protected accounts for each
student. If you have the budget for it, you may also consider buying 80
USB mass storage sticks, one to lend to each student. Besides your
deck, you can also place a full copy of Mnemosyne on the USB stick so
that your students can run Mnemosyne from any Microsoft Windows computer.
For instructions, see the Mnemosyne Web site.

> [is it] impossible to protect my vocabulary from being ripped off the

> Internet, loaded on a computer, have some words altered, and resaved
> as the exact same deck?

Mnemosyne doesn't provide any access security and probably never will.
The security you want is provided by the computer's operating system and
the computer's own physical security.

Talk to your system administrator about password-protected accounts,
private data drives, disabling Internet access, and other access
restrictions.

Good luck,

-Dave
--
David A. Harding Website: http://dtrt.org/
1 (609) 997-0765 Email: da...@dtrt.org
Jabber/XMPP: dhar...@jabber.org

[Samuel Morrison]

 Thanks for all the responses.

All of your advice is great, if I had a network admin. I work in a government funded school. My boss would have to call some ad min in do work on the computers every month, creating all those accounts, when I could just do it myself. Not likely, not with hundreds of thousands of students in the school system. Not when it isnt a part of the curriculum. Not when vice principals don't really care.  This is red tape, and it is the reality in the school system.

USB sticks for 80 studens every month? Who pays?

 

Well, I guess it is hopeless. I thought locking a deck would be an easy request. I remember when I learned German at university in the early 90s that my teacher had a simple password protected flashcard system on each computer, before the Internet. Yes, flashcards are a great way to make sure students go through the vocabulary. It isn't just for self learners.

I don't see why this is so hard, but I guess I just don't get it.

 

Anyways, this is the last post. I will uninstall this program and try a different one.

 

Thanks for all the comments.

 

[Oisín]

2009/11/15 Samuel Morrison <samuelthom...@gmail.com>:

>>  Thanks for all the responses.
>
> All of your advice is great, if I had a network admin. I work in a
> government funded school. My boss would have to call some ad min in do work
> on the computers every month, creating all those accounts, when I could just
> do it myself. Not likely, not with hundreds of thousands of students in the
> school system. Not when it isnt a part of the curriculum. Not when vice
> principals don't really care.  This is red tape, and it is the reality in
> the school system.
> USB sticks for 80 studens every month? Who pays?
>
> Well, I guess it is hopeless. I thought locking a deck would be an easy
> request. I remember when I learned German at university in the early 90s
> that my teacher had a simple password protected flashcard system on each
> computer, before the Internet. Yes, flashcards are a great way to make sure
> students go through the vocabulary. It isn't just for self learners.
> I don't see why this is so hard, but I guess I just don't get it.

I think you're missing the point. Whatever hacked-together
password/encryption system one might add to Mnemosyne will offer
nothing useful (except perhaps privacy, but that's not really a
concern with flashcards) if students can simply delete other students'
deck files or overwrite them with garbage outside of Mnemosyne.

What could it possibly do to prevent users trashing the deck files?
The simple fact is that if the students have write access to the
filespace (which they must to use Mnemosyne anyway), then they can
delete/trash anything - it is completely outside of Mnemosyne's power
(and purpose) to prevent this. The only option is to provide them with
a secure filespace as previously mentioned, be it through cheap USB
disks or even _floppy_ disks - remember that each user's deck will
probably be miniscule in size; probably far less than 100kb.

Get one cheap USB floppy drive (literally $5-10 each on eBay including
delivery) for each shared machine and one floppy disk for each student
(you can still buy floppy disks in bulk very cheaply on eBay/etc).

>
> Anyways, this is the last post. I will uninstall this program and try a
> different one.

Since no software solution other than a proper authenticated
multi-user environment will solve your particular problem, I don't
expect other SRS programs will help, but good luck.

Oisín

[Michael Campbell]

Samuel Morrison wrote:

> I remember when I learned German at university in the early 90s
> that my teacher had a simple password protected flashcard system on each
> computer, before the Internet.

Mnemosyne is not a "flashcard" program in the classic sense - it's an
individualized SRS system that happens to use the card metaphor. The particular
implementation here requires write access to the deck itself, and while it
could have been written to use different files for the "scores" and the data, it
wasn't. C'est la vie.

Have you considered a few dollars (or euros) worth of PHYSICAL cards and a
couple hours of work with a pen/marker? Perhaps an electronic/computerized
solution is not the right one for your particular issue. Remember that
Mnemosyne and the like are simply programs that is based on an original physical
card-and-box system.

[Samuel Morrison]

 

I think you're missing the point. Whatever hacked-together
password/encryption system one might add to Mnemosyne will offer
nothing useful (except perhaps privacy, but that's not really a
concern with flashcards) if students can simply delete other students'
deck files or overwrite them with garbage outside of Mnemosyne.

What could it possibly do to prevent users trashing the deck files?
The simple fact is that if the students have write access to the
filespace (which they must to use Mnemosyne anyway), then they can
delete/trash anything - it is completely outside of Mnemosyne's power
(and purpose) to prevent this. The only option is to provide them with
a secure filespace as previously mentioned, be it through cheap USB
disks or even _floppy_ disks - remember that each user's deck will
probably be miniscule in size; probably far less than 100kb.

 

 

why do students need write access? I am making up the cards, not the students. I dont want them to touch the cards. I just want them to go through the deck that I made, and then leave the deck alone when they are done. It is simple. Am I asking for Rome?

Get one cheap USB floppy drive (literally $5-10 each on eBay including
delivery) for each shared machine and one floppy disk for each student
(you can still buy floppy disks in bulk very cheaply on eBay/etc).

I don't care about the students saving their work. I just don't want them to touch it for the next class. THey can spend a half an hour doing their vocabulary. Afterthat they are finished.

[Samuel Morrison]

On Sun, Nov 15, 2009 at 12:29 PM, Michael Campbell <michael....@unixgeek.com> wrote:

Samuel Morrison wrote:


 > I remember when I learned German at university in the early 90s
> that my teacher had a simple password protected flashcard system on each
> computer, before the Internet.

Mnemosyne is not a "flashcard" program in the classic sense - it's an
individualized SRS system that happens to use the card metaphor.  The particular
 implementation here requires write access to the deck itself, and while it
could have been written to use different files for the "scores" and the data, it
wasn't.  C'est la vie.

 

Why do students need write access? Can't I block it? Is that an option that no one else wants?

Have you considered a few dollars (or euros) worth of PHYSICAL cards and a
couple hours of work with a pen/marker?  Perhaps an electronic/computerized
solution is not the right one for your particular issue.  Remember that
Mnemosyne and the like are simply programs that is based on an original physical
card-and-box system.

 

1000 flash cards cost about $20 a pack. I have 80 new students a day, every day. That is right, every day. Students learn about 50 words a week. I see a  class twice or three times a month.

I would need  4 packs a week. $320 a month. Who pays?

I can't print out the cards at the school, either. We have a budget for how many copies we can make.

[Gwern Branwen]

On Sun, Nov 15, 2009 at 8:50 PM, Samuel Morrison
<samuelthom...@gmail.com> wrote:
>>
>> I think you're missing the point. Whatever hacked-together
>> password/encryption system one might add to Mnemosyne will offer
>> nothing useful (except perhaps privacy, but that's not really a
>> concern with flashcards) if students can simply delete other students'
>> deck files or overwrite them with garbage outside of Mnemosyne.
>>
>> What could it possibly do to prevent users trashing the deck files?
>> The simple fact is that if the students have write access to the
>> filespace (which they must to use Mnemosyne anyway), then they can
>> delete/trash anything - it is completely outside of Mnemosyne's power
>> (and purpose) to prevent this. The only option is to provide them with
>> a secure filespace as previously mentioned, be it through cheap USB
>> disks or even _floppy_ disks - remember that each user's deck will
>> probably be miniscule in size; probably far less than 100kb.
>
>
>
> why do students need write access? I am making up the cards, not the
> students. I dont want them to touch the cards. I just want them to go
> through the deck that I made, and then leave the deck alone when they are
> done. It is simple. Am I asking for Rome?

In an SRS context, you are asking to have your cake and eat it too.
There is no such thing as just going through the deck and also not
touching the cards. The former implies the latter. That's how spaced
repetition works: it remembers the last assessment and intelligently
updates the card's metadata with the next date (to present the card
on).

>> Get one cheap USB floppy drive (literally $5-10 each on eBay including
>> delivery) for each shared machine and one floppy disk for each student
>> (you can still buy floppy disks in bulk very cheaply on eBay/etc).
>>
> I don't care about the students saving their work. I just don't want them to
> touch it for the next class. THey can spend a half an hour doing their
> vocabulary. Afterthat they are finished.

I feel like there's a massive communication gap here. Do you, or do
you not, need spaced repetition? It is increasingly sounding to me
like you don't, you merely want students to review once or twice. In
that case, Mnemosyne is the wrong software for you. The whole point of
Mnemosyne is to be a SRS; otherwise, it does nothing interesting or
useful. You're obviously not technically inclined at all, so you don't
need nice TeX flashcards or the pictures or audio features.

If you don't need an SRS, then you would be much better off looking
for a dead-simple website which will offer free accounts and let
students import a set of cards from various sources. I have heard
flashcardexchange (which you've already mentioned before) does this,
but it's a simple problem and so I am sure that there must be dozens
of usable websites if you will but look.

--
gwern

[Samuel Morrison]

 

In an SRS context, you are asking to have your cake and eat it too.
There is no such thing as just going through the deck and also not
touching the cards. The former implies the latter. That's how spaced
repetition works: it remembers the last assessment and intelligently
updates the card's metadata with the next date (to present the card
on).

>> Get one cheap USB floppy drive (literally $5-10 each on eBay including
>> delivery) for each shared machine and one floppy disk for each student
>> (you can still buy floppy disks in bulk very cheaply on eBay/etc).
>>
> I don't care about the students saving their work. I just don't want them to
> touch it for the next class. THey can spend a half an hour doing their
> vocabulary. Afterthat they are finished.

I feel like there's a massive communication gap here. Do you, or do
you not, need spaced repetition? It is increasingly sounding to me
like you don't, you merely want students to review once or twice. In
that case, Mnemosyne is the wrong software for you. The whole point of
Mnemosyne is to be a SRS; otherwise, it does nothing interesting or
useful. You're obviously not technically inclined at all, so you don't
need nice TeX flashcards or the pictures or audio features.

 

I do not see a contradiction between using spaced repetition, which I want,  and preventing access to decks. You fail to explain how those two concepts naturally exclude each other by their very nature.  My failure to understand has nothing to do with being obviously not technically inclined at all, as you say.

 

Do me a favour--don't respond. I will uninstall this program and  I will switch to Anki. Problem solved. 

 

 

 

 

--
gwern

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "mnemosyne-proj-users" group.
To post to this group, send email to mnemosyne-...@googlegroups.com
To unsubscribe from this group, send email to mnemosyne-proj-u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mnemosyne-proj-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Oisín]

2009/11/17 Samuel Morrison <samuelthom...@gmail.com>:

>> > I don't care about the students saving their work. I just don't want
>> > them to
>> > touch it for the next class. THey can spend a half an hour doing their
>> > vocabulary. Afterthat they are finished.

...

> I do not see a contradiction between using spaced repetition, which I want,
>  and preventing access to decks. You fail to explain how those two concepts
> naturally exclude each other by their very nature.  My failure to understand
> has nothing to do with being obviously not technically inclined at all, as
> you say.

I don't understand why you don't understand this. To actually use the
spaced repetition features of Mnemosyne, or Anki, or Supermemo, or
Pauker, or ANY SRS system, you must have WRITE ACCESS to the deck. The
information about your individual progress with the cards is written
to the deck every time you GRADE a card - otherwise how can it decide
when to schedule the card for next review (i.e. "spaced" repetition).

Simply using the deck to study requires access to the deck. There is
your contradiction. If the students can't write to the deck, then
Mnemosyne can't do the ONE thing it was meant to do.

>
> Do me a favour--don't respond. I will uninstall this program and  I will
> switch to Anki. Problem solved.

Anki will NOT solve your problem, no matter how much you complain
about this 'simple' feature on the Anki mailing list.

What you want is basically a simple webpage of read-only flashcards
which students can view at any time but not change. This is very easy
to do, unless you can't admit that's what you want and keep searching
in vain for a self-contradicting solution of using SRS on non-writable
data. SRS is for INDIVIDUAL study, which is why every student would
need their own copy of the deck (ok, maybe you could split the deck
into two files; the cards which are made read-only on some HTTP server
and the schedule information for each student which is writable, but
it doesn't matter because you don't have any system to provide that
individual writable space for each student's schedule information;
once again Mnemosyne/Anki/etc would be nothing more than a displayer
of cards).

[le_sacre]

It seems to me that what Samuel wants is not wholly at odds with SRS;
it would just require a complete reinvention of how Mnemosyne is
engineered.

What Samuel has not seemed to grasp is that there are two classes of
information in the deck, and they are stored in the same file. One
class is the actual data that displays on the cards, the content. The
other is the learner's performance data for each card, including how
many times and when it's been reviewed, how difficult it is, etc. SRS
works by updating this performance data every time a card is reviewed,
to control when the card will next be scheduled.

It seems to me that it's by no means strictly necessary for the
content data and performance data to occupy the same file. For a
school environment you could (theoretically) lock the content data,
while having a separate file that contains the performance data for
all the students, with each student being given a password that
enables the system to update only their performance data in this file
as the cards are reviewed. There would still be the same issue of the
danger of tampering, until some form of user login is implemented on
the computer(s) (on Macs this is easy to do--don't know about PCs),
but the teacher could make regular backups of both files.

Of course, this would practically involve rewriting Mnemosyne from
scratch to achieve. But I don't think it's accurate to say SRS is in
general completely incompatible with what Samuel's requesting.

On Nov 17, 2:17 am, Oisín <denpasho...@gmail.com> wrote:
> 2009/11/17 Samuel Morrison <samuelthomasmorri...@gmail.com>:

[crgm...@yahoo.com.au]

I think this list is being somewhat unfair to the original poster.
There is a big difference between the program having write-access to
save learning/scheduling data, and the individual student having edit
access to card content. A bully might think it was funny to make
another student learn (wrongly) that schwarz = white, gelb = green,
and so on. Or a bully might open up someone's flashcard set and muck
up all the gradings. Having the files locked for editing and password-
protected would prevent that.

Sure, the bully could simply delete the file, but that seems less
tempting to me, when I try to think like a bully. Also, it is
immediately noticeble. The student with the deleted file would know
immediately that the file was gone, report it to the teacher, and the
teacher could then reload his backup copy of the victim's flashcard
set. If the teacher makes a backup of all students sets at the end of
every day, saving it to a secure location such as the teacher's USB or
teacher's secure file area, then the victim has at most lost one day's
worth of revision data - not really wasted effort anyway. That is much
better than having a few weeks go by learning that back=white. No
major IT resources would be needed. The backup procedure could be done
by a simple batch file.

So, it could be useful in some contexts to turn off editing for all
users. And the original poster is right in suggesting that this is
simple to implement.

On Nov 17, 9:17 pm, Oisín <denpasho...@gmail.com> wrote:
> 2009/11/17 Samuel Morrison <samuelthomasmorri...@gmail.com>:
>

[Gwern Branwen]

On Tue, Nov 17, 2009 at 3:37 PM, le_sacre <thoma...@gmail.com> wrote:
> It seems to me that what Samuel wants is not wholly at odds with SRS;
> it would just require a complete reinvention of how Mnemosyne is
> engineered.
>
> What Samuel has not seemed to grasp is that there are two classes of
> information in the deck, and they are stored in the same file.  One
> class is the actual data that displays on the cards, the content.  The
> other is the learner's performance data for each card, including how
> many times and when it's been reviewed, how difficult it is, etc.  SRS
> works by updating this performance data every time a card is reviewed,
> to control when the card will next be scheduled.
>
> It seems to me that it's by no means strictly necessary for the
> content data and performance data to occupy the same file.  For a
> school environment you could (theoretically) lock the content data,
> while having a separate file that contains the performance data for
> all the students, with each student being given a password that
> enables the system to update only their performance data in this file
> as the cards are reviewed.  There would still be the same issue of the
> danger of tampering, until some form of user login is implemented on
> the computer(s) (on Macs this is easy to do--don't know about PCs),
> but the teacher could make regular backups of both files.
>
> Of course, this would practically involve rewriting Mnemosyne from
> scratch to achieve.  But I don't think it's accurate to say SRS is in
> general completely incompatible with what Samuel's requesting.

That's true, you could split up the data over multiple files. (You
could also have each card be a file, or contain every card starting
with the letter 'A' and so on.)

But there's a good reason to have one file rather than many: besides
being easier to write, easier to understand, easier to backup, a
single file makes it easier to have *consistency*. (Notice that SQLite
- which Mnemosyne 2.x will use - also uses a single file model.)

If you have one file for grades and one for cards, imagine a power
failure interrupts or any failure of any kind from a platter on the
hard disk all the way up to the actual Mnemosyne running - what
happens? Do you wind up with a card-file which has fewer cards than
the grade-file specifies (perhaps you deleted or merged some)? Do you
have a grade-file assuming a card-file with different contents? With
one file, it's all or nothing. You lose all your work, or you save all
your work; but you won't wind up with a database which is corrupt,
incomplete, or contradictory. (Mnemosyne currently will add new
questions before shutdown, but everything else gets written out in one
batch to one file.)

--
gwern

[Oisín]

2009/11/17 le_sacre <thoma...@gmail.com>:

> It seems to me that what Samuel wants is not wholly at odds with SRS;
> it would just require a complete reinvention of how Mnemosyne is
> engineered.

(...)

> Of course, this would practically involve rewriting Mnemosyne from
> scratch to achieve.  But I don't think it's accurate to say SRS is in
> general completely incompatible with what Samuel's requesting.

I didn't say it was. In fact I said what you just said!

> On Nov 17, 2:17 am, Oisín <denpasho...@gmail.com> wrote:
> (ok, maybe you could split the deck
> into two files; the cards which are made read-only on some HTTP server
> and the schedule information for each student which is writable, but
> it doesn't matter because you don't have any system to provide that
> individual writable space for each student's schedule information;
> once again Mnemosyne/Anki/etc would be nothing more than a displayer
> of cards).

My point was that, without SOME form of protected filespace,
separating the (global for all students) card and (individual for each
student) scheduling information would still not work, since other
students can still trash or modify either or both files (or if they
were somehow read-only, they still wouldn't be able to update the SRS
scheduling/grading data). So local SRS systems will not work.

Online SRS systems can work around the problem by providing that
individual filespace (in fact Anki has a free web-based hosting
service which could be used for this purpose), but, as you note,
Mnemosyne is not designed for it.

[le_sacre]

On Nov 17, 12:45 pm, "crgmcc...@yahoo.com.au" <crgmcc...@yahoo.com.au>
wrote:

> There is a big difference between the program having write-access to
> save learning/scheduling data, and the individual student having edit
> access to card content.

As I just explained, this is not true for Mnemosyne. Mnemosyne was
written to have both kinds of data in the same file. Changing this
would require a massive alteration to the program's fundamental
architecture, requiring wholly new schemes for maintaining
correspondence integrity between separate files.

> So, it could be useful in some contexts to turn off editing for all
> users. And the original poster is right in suggesting that this is
> simple to implement.

No. Without the huge change to the architecture to make separate
learning data files, turning off editing would change Mnemosyne into a
completely basic flashcard program with no spaced repetition
scheduling ability (dozens of which already exist). And that change
would absolutely not be simple.

If anything about this is unclear, I think the best tactic would be to
re-read this entire thread in entirety:
http://groups.google.com/group/mnemosyne-proj-users/browse_thread/thread/892d9235fdcb5479

[Andrew Wilson]

On Tue, Nov 17, 2009 at 12:31 AM, Samuel Morrison
<samuelthom...@gmail.com> wrote:
>
> I do not see a contradiction between using spaced repetition, which I want,
>  and preventing access to decks. You fail to explain how those two concepts
> naturally exclude each other by their very nature.
>

There may be some confusion as to what "write access" means. If you
don't use an operating system that has file-based permissions, the
concept of "write access" isn't obvious. The operating system must
allow users to write to the files that contain the deck information
because Mnemosyne writes out information that is used for keeping
track of information it uses to determine how often it needs to show
certain cards using its SRS (spaced repetition system) algorithm. This
is what most people who are responding here mean by write access - the
fact that the operating system must allow you to write to the deck
files in order to save the relevant information about how well you're
doing with certain cards so it knows which ones to show more often.

From an application perspective, you might be thinking of "write
access" as the ability to add/remove/edit the contents of a "deck". I
don't think there's any way to "lock down" cards in a way that people
can't do this from Mnemosyne.


Part of the larger sense confusion here might be that Mnemosyne trusts
that users are mature enough do the right thing. The assumption of
this kind of trust lets the developers focus on making Mnemosyne a
really great flashcard program - adding that other functionality might
be possible but it takes time and doesn't really make Mnemosyne any
better of a flashcard program. The concept of locking down a deck
isn't necessary when you start with this assumption. If I don't want a
deck to change I just won't change it - I don't need any external
mechanism that prevents me from changing it and I probably wouldn't
use it if it did exist. Your particular environment seems like one in
which you can't trust the users, and I think that's where the
mis-match is.

You can, as others have suggested, try to secure the deck files
through some external method - either via per-student user accounts
with appropriate permissions, some sort of per-student storage (e.g.
USB drives), or some clever encryption scheme. It sounds like your
resources are limited such that these aren't feasible.

Mnemosyne is really great at what it does - SRS based flashcards for
memorization of lots of different types of information. It doesn't
seem like that's exactly what you're looking for, so you are right to
look elsewhere.

[Michael Campbell]

Samuel Morrison wrote:

> I do not see a contradiction between using spaced repetition, which I
> want, and preventing access to decks. You fail to explain how those two
> concepts naturally exclude each other by their very nature.

They don't in general. It's a perfectly reasonable assumption that a given
program could record a particular student's results in a different file than the
deck itself. Mnemosyne just doesn't, so "locking the deck" also effectively
"locks the scores", making the whole point of the program moot.

> Do me a favour--don't respond. I will uninstall this program and I will
> switch to Anki. Problem solved.

<shrug> Ok. Hope it works for you.

[crgm...@yahoo.com.au]

>If anything about this is unclear, I think the best tactic would be to
> re-read this entire thread in entirety:

Nothing about this thread is unclear to me, and the arrogant tone of
that comment is far from warranted. I never assumed or implied that
learning data and content had to be in separate files.

>No. Without the huge change to the architecture to make separate
>learning data files, turning off editing would change Mnemosyne into a
>completely basic flashcard program with no spaced repetition
>scheduling ability

This is an odd assumption on your part. It is the scheduling that
makes Mnemosyne an SRS system, not the user's ability to edit card
content. The original poster and I am talking about student access to
the card content within the program. I don't use mnemosyne - I have my
own SRS program - but most of these programs have some gui feature,
like a button, that initiates editing. Disabling that button is all
that is required, and this does not require a massive overhaul of the
system. The scheduling algorithm can still have its usual access to
the data, while the student has no way to change the card content. I
implemented both password protection and a teacher-lock system in my
own program the same day the original poster made his first comments,
and the programming only took me about 40 minutes. I did not overhaul
the file system, and my program still keeps both types of data in the
same file. I just added a teacher-password to the data file, and
turned off the Edit button (all and related gui features) for all
files that had such a password, until the file was unlocked by the
password holder. If there is no such password in the file, it is
treated normally with full editing access. The scheduling code was
untouched.

Mnemosyne is slightly different in that it has the data in a hackable
text format (XML, I think, but it is not important and I haven't
checked), accessible from outside the program, but it is a very simple
matter to encrypt a text file. In Java, it requires about 3 extra
lines of code while writing the datastream to file.
.
Craig.

[crgm...@yahoo.com.au]

> > I do not see a contradiction between using spaced repetition, which I want,
> >  and preventing access to decks. You fail to explain how those two concepts
> > naturally exclude each other by their very nature.
>

> There may be some confusion as to what "write access" means. ... SNIP ...

> From an application perspective, you might be thinking of "write
> access" as the ability to add/remove/edit the contents of a "deck".

Exactly. I'm pleased someone understands this, besides the original
poster. As I said, denying the *program* access and denying the
*student/user* acccess are not the same thing, which is why the
different data types do not have to be in a different file. The
control can be blocked at the level of the GUI, and the OP didn't ask
for anything more than the optional removal of the editing facility.
It was others, not him, who made assumptions that revealed their
ignorance.

> Part of the larger sense confusion here might be that Mnemosyne trusts
> that users are mature enough do the right thing.

Yes, that is true. But the extra programming involved in providing a
lockdown would not actually be that hard - an evening's work, perhaps.
I don't write python, or else I would submit a proof-of-concept
program to demonstrate. I suspect there would be less new code than
there have been lines in this thread. In Java, it took me about 40
minutes for my own program, where the access issues are exactly the
same, and the content/scheduling data are still within the same file
after I made the changes. I will probably remove the 'Lock' facility
from the default GUI, because I agree most adults won't want it, but I
will provide teachers a simple way to add it if they do want it.

The value of a lockdown might be greater than you think, in the school
setting. My own kids use my program to learn German, and they have all
at some stage added joke cards to each other's vocab files. These were
single cards that were designed to be a surprise, and they were
deleted after they had their desired effect. No harm was done, but I
thought of locking the files at one stage. I didn't because the joke
staled rapidly, they are generally well-behaved children, and I wanted
them to be able to add their own content. I can easily imagine that a
school bully would take it further. In a highly developed, tried-and-
tested curriculum, the need to add new cards might be fairly limited,
and so the value of locking the decks to remove one source of
headaches might be greater. It would have ZERO impact on the ability
of the program to perform its scheduling function.

Craig.

[Gwern Branwen]

On Wed, Nov 18, 2009 at 5:52 PM, crgm...@yahoo.com.au
<crgm...@yahoo.com.au> wrote:
>
>> > I do not see a contradiction between using spaced repetition, which I want,
>> >  and preventing access to decks. You fail to explain how those two concepts
>> > naturally exclude each other by their very nature.
>>
>> There may be some confusion as to what "write access" means. ... SNIP ...
>> From an application perspective, you might be thinking of "write
>> access" as the ability to add/remove/edit the contents of a "deck".
>
> Exactly. I'm pleased someone understands this, besides the original
> poster. As I said, denying the *program* access and denying the
> *student/user* acccess are not the same thing, which is why the
> different data types do not have to be in a different file. The
> control can be blocked at the level of the GUI, and the OP didn't ask
> for anything more than the optional removal of the editing facility.
> It was others, not him, who made assumptions that revealed their
> ignorance.

"Would it be possible to lock the cards so that no one could add,
change, or alter the content of any card except the creator?"

"I would just like some encryption or password protection."

"Otherwise some students can fail quizes because of missing
vocabulary, or claim they failed because the class bully deleted
cards. I need to stop any malicious tampering with decks."

"So, in layman's terms, it is impossible to protect my vocabulary from
being ripped off the Internet, loaded on a computer, have some words
altered, and resaved as the exact same deck?"

I suppose if one squinted really hard, one could read that as 'disable
parts of the GUI'.

But he *is* ignorant:

"I do not see a contradiction between using spaced repetition, which I
want, and preventing access to decks. You fail to explain how those
two concepts naturally exclude each other by their very nature."

After people had multiple times explained to him that the cards and
metadata are in the same file, and remembering that SRS is *defined*
as changing the intervals between repetition! Where is Mnemosyne going
to get the change in intervals from if it cannot save any data? Out of
thin air? By asking its fairy godmother?

If he only wanted Mnemosyne to not do SRS (and just display cards),
then something could be done - the deck/.mem file could be created as
usual, and then changed to be owned by root but still world-readable.
Mnemosyne would crash or something upon exiting, since it wouldn't be
able to write the recorded grades, but the actual review would still
work. If he wanted Mnemosyne to do SRS, then he needs to allow writing
and there are many solutions to that as well. But he wants SRS and
not-writing, which preclude each other.

No, this man is beyond our ability to help. Sometimes that happens;
sometimes people are idiotic or refuse to think or are arrogant or
have some other flaw. Once that is ascertained, they must be ignored
in the hope they will go away before doing any more damage (like this
whole acrimonious thread), and forgotten about unless they start
spreading their venom elsewhere.

--
gwern

[crgm...@yahoo.com.au]

Hi Gwern,

I accept some of that, and certainly don't want to argue with you. I
always read your posts with great interest, and I know you are
generally very helpful to newbies. But just reread his posts and
mentally replace 'access to the decks' with 'user access to the
decks', not programmatic access. That logically implies the GUI (even
if he had not thought the details through), because that's how the
student usually *does* have access. It does not follow, then, that the
scheduling need be hampered in any way by switching off user-initiated
content-editing. All the discussion about mnemosyne needing file
access to write scheduling data is simply tangential to his inquiry,
and I don't think he misunderstood this so much as ignored it because
it was irrelevant, or he failed to see why you all linked user-access
to cards with programmatic-access to files. I also have trouble seeing
why these need to be treated as inseparable - it never occurred to me
to implement his request by letting the user edit the deck and then
blocking the program at the write stage. *Of course* you would be
better to block the user at the GUI before any editing took place.
(This is especially true if the scheduling data and content data are
in the same file, but the GUI would still be the natural blocking
point regardless of where the data was. If nothing else, it would be
unkind to let legitimate users waste time doing editing if their
changes could not then be saved.).

I think it is more of a miscommunication than anything else. And sure,
he got annoyed, which is somewhat understandable given that he was
basically called an idiot.

To some extent, I could not help posting in his defence because the
list was getting increasingly agitated in its claims that the feature
was way beyond the scope of mnemosyne, was inconsistent with the aims
of SRS, and required major restructuring - which all seemed somewhat
silly when I had already implemented it in another context, with very
little effort, and the extra lines of code required were about the
same length as this post. And I still don't think it would take more
than an evening of programming to add it to mnemosyne. After all, we
are simply talking about removing the editing features for some users.
Adding encryption should not be much extra work, though I am not
familiar with python and maybe it is much harder in that language.

As for worrying that people will rip off his decks, that is a whole
separate issue. I have no real interest in preventing people from
exchanging decks. It would be possible to encrypt the files, sure, but
the dedicated rip-off artist could always write the cards down as they
appeared. I'd be interested in knowing what the decks contained that
they were considered such hot property. Or maybe his points about
ripping material off the internet still related to the bully's
capacity to sneak in cards like 'to sit = scheißen'. Now we'll never
know.

Of course, if his bullies are also geniuses, then they could always
write their own plug-in to undo whatever protection is created. That
seems a little unlikely, though. The ability to delete the files is a
separate problem, not fixable by any change to mnemosyne, though it
would be possible to give the files cryptic names so the bully had no
idea what he was deleting. And it would be easy enough for the
teacher, at the end of every lesson, to back up all user files with a
one-line batch program.

Cheers,

Craig.

On Nov 19, 10:52 am, Gwern Branwen <gwe...@gmail.com> wrote:
> On Wed, Nov 18, 2009 at 5:52 PM, crgmcc...@yahoo.com.au

[Peter Bienstman]

Hmm, time to chime in here :-)

The best way to implement what the original poster wants would be to write a
web server around Mnemosyne which does not have the option to edit cards.
Unfortunately, I don't have time to work on this anytime soon, as my priority
is getting 2.0 out of the door.

As for the rest of this thread, let's keep in mind that we are all human
beings, we are all fallible, and that email is one of the worst media to have
an argument.

So, I suggest we all cut each other some slack, take a few deep breaths, and
move on :-)

Cheers,

Peter

[Oisín]

2009/11/19 crgm...@yahoo.com.au <crgm...@yahoo.com.au>:

> All the discussion about mnemosyne needing file
> access to write scheduling data is simply tangential to his inquiry,
> and I don't think he misunderstood this so much as ignored it because
> it was irrelevant, or he failed to see why you all linked user-access
> to cards with programmatic-access to files. I also have trouble seeing
> why these need to be treated as inseparable - it never occurred to me
> to implement his request by letting the user edit the deck and then
> blocking the program at the write stage. *Of course* you would be
> better to block the user at the GUI before any editing took place.
> (This is especially true if the scheduling data and content data are
> in the same file, but the GUI would still be the natural blocking
> point regardless of where the data was. If nothing else, it would be
> unkind to let legitimate users waste time doing editing if their
> changes could not then be saved.).

Fair point; even a trivial password-based edit-locking feature might
be enough to discourage casual vandalism of other students' decks.
Then you could add another password for each student to allow them to
grade the cards (i.e. so student A can't simply load student B's deck,
and click "learn ahead of schedule", repeatedly marking everything a 5
to ruin the scheduling), aside from the teacher's edit-permissions
password.

I guess I got bogged down in the fact that this is a 'security through
obscurity solution' - i.e. a very thin layer of protection since one
can do anything they like to the deck file in the operating system -
delete, copy, overwrite with garbage, etc,. and the OP didn't seem to
understand that (or as you say, may have just ignored that
consideration because he saw it as irrelevant). But at least an
optional password protection in the GUI might be enough to discourage
trivial, casual messing (where the students aren't interested or
destructive enough to bother finding the deck file outside of
Mnemosyne and wiping it) and solve most of the OP's particular
problem. Just like speed bumps can't completely prevent speeding, only
make it enough of a nuisance that most drivers passing them will slow
down.

Oisín

[crgm...@yahoo.com.au]

Hi Oisin,

Bearing in mind that Peter suggested we move on, I will just add one
more comment, to clarify my original post, if I may. I don't think any
of us are arguing at this point.

My own solution did, in fact, have a second student password, as well
as the teacher password. The teacher password allows editing and
opening a stiudent deck. The student password simply allows opening
the deck to use it for normal revision, complete with grading, but not
content editing. If the deck lacks either of these passwords, the
corresponding password-checking phase is skipped, and all editing
permissions are normal.

The protection would indeed be quite thin, as the file could be
accessed outside the SRS program, but if the file were encryped, the
bully could not tamper with it without destroying it. Most decryption
algorithms fail catastrophically if a single character is altered. A
catastrophic failure would be the functional equivalent of deleting
the file. This is still better than having grades and content altered
on the sly. The bully would not get much satisfaction from seeing the
teacher reload his copy of the student's file - he would succeed in
annoying the teacher, but the amusement value would be fairly minimal,
compared to letting the victim soldier on with a deranged deck.

I think this could be of value in some situations, and I think it was
a reasonable enough feature request.

Cheers,

Craig.

[Oisín]

2009/11/19 crgm...@yahoo.com.au <crgm...@yahoo.com.au>:

Indeed, and since the bully's actions would be restricted to either
leaving things alone or completely destroying the deck the impact
would both be quickly obvious (resulting in a restored backup,
hopefully) and there would be no excuse of "oh I was just having a bit
of fun", so there would be nothing to gain by doing it.

> I think this could be of value in some situations, and I think it was
> a reasonable enough feature request.

Agreed, I didn't mean to shoot it down before, just hadn't thought
about it in these terms and felt that the OP might have been asking
for something impossible (full protection of the file). It's certainly
worth adding as an optional feature for exactly this kind of classroom
situation.

> Cheers,
>
> Craig.
>
> --

>
> You received this message because you are subscribed to the Google Groups "mnemosyne-proj-users" group.

> To post to this group, send email to mnemosyne-...@googlegroups.com.
> To unsubscribe from this group, send email to mnemosyne-proj-u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mnemosyne-proj-users?hl=.
>
>
>

[crgm...@yahoo.com.au]

Hey Oisin,

I think we are all on the same page now...

Just out of curiosity, I did a little google and found this:

http://www.cleanersoft.com/hidefolder/free_hide_folder.htm

It seems to work quite well. You can get into the hidden folder from
the DOS command line, but it doesn't list with the DOS command 'dir',
so you would have to guess the folder name correctly to get in and do
any damage. It doesn't appear in Windows Explorer or in the Java file
chooser - both must rely on the same directory-listing part of the
operating system. Don't know about python etc, but someone here might
be kind enough to check. Programmatic access to the folder is
unimpaired. All that the teacher would need to do is enter both a
password and a secret sub-folder name, and the SRS program would need
to avoid listing the full pathname in the title bar and elsewhere.

Seems to be a workable low-budget solution, beyond the reach of your
average school bully, though I am sure tech-savvy people could bust
it. The file-hider is freeware with a nag screen.

Cheers,

Craig.

[Francisco Fiuza Jr]

My suggestion to implement it:

- Add a flag on the config.py file to say if it's possible to add/edit cards
- The GUI will check for this flag and enable or disable the add/edit button
- write protect the config.py file.

Is it hard to implement?

Maybe a plug in could check for the flag instead of the core system.

Cheers,

Craig.

[Peter Bienstman]

> My suggestion to implement it:
>
> - Add a flag on the config.py file to say if it's possible to add/edit
> cards - The GUI will check for this flag and enable or disable the
> add/edit button - write protect the config.py file.
>
> Is it hard to implement?

No, but it's also very easy to circumvent :-)

Peter

[Francisco Fiuza Jr]

Well, but I guess this first layer of security will do the job!

[Peter Bienstman]

I'd rather not put a feature which is inherently crippled in the main
distribution, so I'll leave this to a plugin writer to provide a plugin which
will turn off the edit options :-)

Cheers,

Peter

> Well, but I guess this first layer of security will do the job!
>
> On Sun, Nov 22, 2009 at 5:38 AM, Peter Bienstman
>
> <Peter.B...@ugent.be>wrote:
> > > My suggestion to implement it:
> > >
> > > - Add a flag on the config.py file to say if it's possible to add/edit
> > > cards - The GUI will check for this flag and enable or disable the
> > > add/edit button - write protect the config.py file.
> > >
> > > Is it hard to implement?
> >
> > No, but it's also very easy to circumvent :-)
> >
> > Peter
> >
> > --
> >
> > You received this message because you are subscribed to the Google Groups
> > "mnemosyne-proj-users" group.
> > To post to this group, send email to
> > mnemosyne-...@googlegroups.com .
> > To unsubscribe from this group, send email to

> > mnemosyne-proj-u...@googlegroups.com<mnemosyne-proj-users%2B
> >unsub...@googlegroups.com> .

> > For more options, visit this group at
> > http://groups.google.com/group/mnemosyne-proj-users?hl=.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "mnemosyne-proj-users" group. To post to this group, send email to
> mnemosyne-...@googlegroups.com. To unsubscribe from this group,
> send email to mnemosyne-proj-u...@googlegroups.com. For more
> options, visit this group at
> http://groups.google.com/group/mnemosyne-proj-users?hl=.
>

------------------------------------------------
Peter Bienstman
Ghent University, Dept. of Information Technology
Sint-Pietersnieuwstraat 41, B-9000 Gent, Belgium
tel: +32 9 264 34 46, fax: +32 9 264 35 93
WWW: http://photonics.intec.UGent.be
email: Peter.B...@UGent.be
------------------------------------------------