Collaborative Annotation in IF Games?
Curt Siffert
Here's something I'd like to see. In another life
I could do it myself since I'm *ok* at java (I did figure
out how to make ZPlet Save/Restore once upon a time), but
maybe someone else has more z-machine knowledge.
You're playing a zcode game. But in addition to the
the regular window and input, there is a second window
with annotations that show up. Say you reach the mailbox -
some annotations come up, left by multiple people:
"Try taking the mailbox out of the ground!"
"There's a bug if you try opening it twice."
Then you open it and take out the leaflet, and different
annotations come up.
"Part of the text was lifted from the necronomicon!"
"Weird stuff happens if you BURN IT..."
I just wonder if it's possible - if the terp could know when
state changes and then use that state information as a network
lookup to request new annotations from a web service somewhere.
You could leave annotations, you could MST3k games, you could
leave spoilers or walkthroughs, you could moderate other
annotations or categorize them, etc.
It'd be really good for beta-testing, too. Just release your
game and then go to the website to read the comments that were
left behind.
Anyone want to do it?
Curt
tarage
It would be more economical to start out on a Web platform and then
Z-code it rather than the reverse. Here's what I'm thinking.
Put the Z-code interpreter on a server somewhere in PERL or PHP. It
listens for incoming POST or GET form requests (which would be the user
submitting a command). Then it posts the response in a new HTML.
Because the in/out is text, speeds will be ok even over dialup. If you
had the page split into frames, say, then the comments would be posted
once, when you first entered the room (this saves too many requests on
the server), and the HTML that the server would update would be the rest
of the page.
Actually I'm surprised no-one has done a Z-code -> PERL yet, because
PERL is EXCELLENT at handling strings and parsing in general.
I'm not the most-qualified PERL guy on the planet, but if I had the
time, that's how I'd do it.
~Mike
Dennis G Jerz
> Here's something I'd like to see. In another life
> I could do it myself since I'm *ok* at java (I did figure
> out how to make ZPlet Save/Restore once upon a time), but
> maybe someone else has more z-machine knowledge.
ZPlet is now on sourceforge as an open-source project. Any chance you
could dust off your save/restore code and contribute it?
Curt Siffert
Well maybe - it was a pretty silly fix, though. I don't remember the
specifics but it involved using the developer tools to create a fake
certificate that was not ok'd by verisign or anything, and the asking
everyone to accept it in their browser. It was like a four-line
addition. But I was actually able to save/restore in IE and Netscape
for a while, that was cool.
I think a real fix would involve some developer with a verisign cert
they'd be willing to hook up to an open-source project... I haven't done
that before so I don't know if that's feasible.
Curt
Alex Watson
when Curt Siffert kindly supplied me with the following text for them to
eat...
><> Well maybe - it was a pretty silly fix, though. I don't remember the
><> specifics but it involved using the developer tools to create a fake
><> certificate that was not ok'd by verisign or anything, and the asking
><> everyone to accept it in their browser. It was like a four-line
><> addition. But I was actually able to save/restore in IE and Netscape
><> for a while, that was cool.
><>
><> I think a real fix would involve some developer with a verisign cert
><> they'd be willing to hook up to an open-source project... I haven't done
><> that before so I don't know if that's feasible.
I'd thought there was something in the Java SDK that allowed you to sign
the certificate as yourself, but then the end user had to click some
'yes' to let it work... Or maybe I'm going mad.
Matthew Russotto
Curt Siffert <sif...@museworldSPAMSUCKS.com> wrote:
>I think a real fix would involve some developer with a verisign cert
>they'd be willing to hook up to an open-source project... I haven't done
>that before so I don't know if that's feasible.
Once you've signed it, it's closed; you can't change it. The signing
has to be done by the person who puts together the class file.
I've got a general bad feeling about code signing in general (gives too
much of a handle for a would-be autocrat to use). And about "trusted
party" code signing in particular... aside from the fact that they
charge more, what makes a cert by Joe Schmoe that you don't know and
signed by Verisign any better than one self-signed by Schmoe?
--
Matthew T. Russotto mrus...@speakeasy.net
=====
Every time you buy a CD, a programmer is kicked in the teeth.
Every time you buy or rent a DVD, a programmer is kicked where it counts.
Every time they kick a programmer, 1000 users are kicked too, and harder.
A proposed US law called the CBDTPA would ban the PC as we know it.
This is not a joke, not an exaggeration. This is real.
http://www.cryptome.org/broadbandits.htm
Curt Siffert
save/restore. Otherwise java security won't even let anyone do it at
all short of opening up your browser security to insane points. Matt's
name is connected enough to ZPLet that maybe if he self-signed a
certificate people would feel comfy accepting it and having save/restore
in zplet.
Curt
Curt Siffert
save/restore. Otherwise java security won't even let anyone do it at
all short of opening up your browser security to insane points. Matt's
name is connected enough to ZPLet that maybe if he self-signed a
certificate people would feel comfy accepting it and having save/restore
in zplet.
Curt
Curt Siffert
Sorry, I didn't entirely grok your first paragraph when I replied the
first time.
So any open-source java program requiring extra permissions would
require someone to build and sign a binary before thoes extra features
could be used...?
The open-source school of thought is that the many-eyeballs provides
competent security, as a closed-source but "reputable" (in verisign's
eyes) certificated effort does.
Anyway for there to be an open-certificate? "This certificate is
registered to the open-source effort zplet; if you trust that this
software really is zplet, came from zplet's development environment, and
that zplet's code is not trojan'd, click here..." then maybe it could be
automatically built in.
Curt
Curt Siffert
There *was* a perl zcode library named R... R.... Rezrov. Looks like
the last time its webpage
(http://www.users.voicenet.com/~mikeedmo/rezrov/) was updated was two
years ago.
I don't mind the web-based stuff like ifiction but it breaks the
game-playing experience up too much, IMO. *But*, it would be a cool web
app.
The part that would be tricky is exactly how to index the annotations
against the game state, though - I'm not sure how much control is
feasible. For instance, my game state if I have 12 inv items and I
*ignored* a napkin back in room two might be different than someone else
who has the same 12 inv items but picked up and dropped the napkin -
would we not see the same annotations? After a point it suggests to me
that it might not be possible without actually getting into the guts of
the game's code itself.
I haven't written a zcode game before so I'm talking out of my butt.
Anyone else want to weigh in on if this is possible structurally?
Curt
tarage
>
> There *was* a perl zcode library named R... R.... Rezrov. Looks like
> the last time its webpage
> (http://www.users.voicenet.com/~mikeedmo/rezrov/) was updated was two
> years ago.
Ah! Very kewl! The things you learn reading newsgroups! I'll have to go
scope that out.
> I don't mind the web-based stuff like ifiction but it breaks the
> game-playing experience up too much, IMO. *But*, it would be a cool web
> app.
I'd be interested in comparing the latency. Right now I'm playing Curses
on my IIGS so there's some latency there. I bet a 56k to a fast server
would feel about the same, but that's just a hypothesis.
> The part that would be tricky is exactly how to index the annotations
> against the game state, though - I'm not sure how much control is
> feasible. For instance, my game state if I have 12 inv items and I
> *ignored* a napkin back in room two might be different than someone else
I was thinking of doing annotations based on the room itself, not taking
into account anything the player was holding or had done. In this aspect
it would function as the original Zork and Adventure did, which allowed
people to leave comments in rooms. Full circle...
~Mike
Fredrik Ramsberg
> I've got a general bad feeling about code signing in general (gives too
> much of a handle for a would-be autocrat to use). And about "trusted
> party" code signing in particular... aside from the fact that they
> charge more, what makes a cert by Joe Schmoe that you don't know and
> signed by Verisign any better than one self-signed by Schmoe?
You know who to sue when the app has formatted your harddrive. I'd rather run
an app signed by Joe Schmoe than an app signed by Gator Corporation calling
themsevles Joe Schmoe.
/Fredrik
Matthew Russotto
Curt Siffert <sif...@museworldSPAMSUCKS.com> wrote:
>
>So any open-source java program requiring extra permissions would
>require someone to build and sign a binary before thoes extra features
>could be used...?
Yep.
>The open-source school of thought is that the many-eyeballs provides
>competent security, as a closed-source but "reputable" (in verisign's
>eyes) certificated effort does.
Right. But what you're trusting is the binary. Not a big deal if you
build it yourself -- then you have the open-source measure of trust. With a
Java applet, you're trusting that the site owner didn't put malicious
code in. So either the site owner has to use a pre-made binary signed
by someone else, or he has to sign it himself. In the latter case,
there's no real benefit provided by the certificate; you're back to
trusting the site owner.
Curt Siffert
So what am I forgetting about the binary, does it *have* to be signed in
a way that hooks it in to the host it is hosted on? If not, assuming
the save/restore code is put in the sourceforge version of ZPlet, are
you willing to have a signed-by-you always-current binary build of the
applet available to download from sourceforge, for others to install?
Could be nice way around all this. All you'd be guaranteeing is that
the build is a reflection of what is in the open source as of that
version. ZPlet fans would trust Matthew Russotto's name I gather.
Curt
Matthew Russotto
Curt Siffert <sif...@museworldSPAMSUCKS.com> wrote:
>
>So what am I forgetting about the binary, does it *have* to be signed in
>a way that hooks it in to the host it is hosted on? If not, assuming
>the save/restore code is put in the sourceforge version of ZPlet, are
>you willing to have a signed-by-you always-current binary build of the
>applet available to download from sourceforge, for others to install?
>Could be nice way around all this. All you'd be guaranteeing is that
>the build is a reflection of what is in the open source as of that
>version. ZPlet fans would trust Matthew Russotto's name I gather.
Two problems with this
1) I still have objections to code signing in general, so I'm not going
to do it.
2) Anyone can create a "Matthew Russotto" certificate.
Dennis G. Jerz
news:uen9ip2...@corp.supernews.com...
> In article <3CEB4FCA...@museworldSPAMSUCKS.com>,
> Curt Siffert <sif...@museworldSPAMSUCKS.com> wrote:
> >
> >ZPlet fans would trust Matthew Russotto's name I gather.
>
> Two problems with this
>
> 1) I still have objections to code signing in general, so I'm not going
> to do it.
>
> 2) Anyone can create a "Matthew Russotto" certificate.
>
How about the Frobozz Magic Certificate Company?
--
Dennis
Curt Siffert
You're saying that even though you personally can sign a codebase and
put it on sourceforge for people to download, it would be entirely
indistinguishable from someone who downloaded the codebase, put in
malicious code, and signed it themselves by just saying their name was
yours?
Why does it work normally, because verisign or whoever has a
key-encrypted method of checking the validity of these certificates over
the network?
If that's all true, I guess I understand why there really isn't a
solution to this. That sucks. It might work if sourceforge allowed you
to register your signature/certificate with them so they could vouch for
the validity, but I don't know if there are actually any free
certificate-verification services for free software.
The other option is for a coalition of Frobozz Developers to spend the
$100/year to make a certificate from Thawte that verifies the code is
built from the open-source base.
If that all happened would you still have objections to code signing?
Isn't that like saying you have objections in general to Save/Restore in
ZPLet? If so, maybe we should all just go home. :-)
Curt
Matthew Russotto
Curt Siffert <sif...@museworldSPAMSUCKS.com> wrote:
>
>You're saying that even though you personally can sign a codebase and
>put it on sourceforge for people to download, it would be entirely
>indistinguishable from someone who downloaded the codebase, put in
>malicious code, and signed it themselves by just saying their name was
>yours?
Yep. Not entirely indistinguishable, because they could still check the
code against the original copy. But they could do that without a
signature too -- most people won't, though.
>Why does it work normally, because verisign or whoever has a
>key-encrypted method of checking the validity of these certificates over
>the network?
It works normally because Verisign supposedly verifies the identity of
whoever applies to them for a certificate.
>If that all happened would you still have objections to code signing?
>Isn't that like saying you have objections in general to Save/Restore in
>ZPLet? If so, maybe we should all just go home. :-)
I don't have objections to Save/Restore. I object to code signing. If
a user wants save/restore, he's got choices
1) Use a browser which allows save/restore. Microsoft IE can in fact do
this. Put the site into "restricted sites", set the security level on
"resticted sites" to low, set the custom Java permissions on that
site's security level to wide-open. This is vicious abuse of a Microsoft
product of course.
2) Download the game file and run locally
3) Convince site operator to sign the code.
Daniel Barkalow
> In article <3CEB4FCA...@museworldSPAMSUCKS.com>,
> Curt Siffert <sif...@museworldSPAMSUCKS.com> wrote:
> >
> >So what am I forgetting about the binary, does it *have* to be signed in
> >a way that hooks it in to the host it is hosted on? If not, assuming
> >the save/restore code is put in the sourceforge version of ZPlet, are
> >you willing to have a signed-by-you always-current binary build of the
> >applet available to download from sourceforge, for others to install?
> >Could be nice way around all this. All you'd be guaranteeing is that
> >the build is a reflection of what is in the open source as of that
> >version. ZPlet fans would trust Matthew Russotto's name I gather.
>
> Two problems with this
>
> 1) I still have objections to code signing in general, so I'm not going
> to do it.
>
> 2) Anyone can create a "Matthew Russotto" certificate.
A certificate is as good as whoever tells you about it. If you create a
certificate, post its fingerprint, say intelligent things about IF, and
don't say that someone forged your post about the certificate, people can
be fairly certain that the certificate is really yours and not a
forgery. Using an applet signed with such a certificate is no different
from using an unsigned application that you uploaded to the if-archive
and posted about. If you put the certificate fingerprint with the source,
the certificate is no less trustworthy than the source, and anyone who
wanted to and was able to modify the binaries and replce the certificate
in that arrangement could modify the source instead, and attack more
people with no more chance of detection.
-Iabervon
*This .sig unintentionally changed*
L. Ross Raszewski
<sif...@museworldSPAMSUCKS.com> wrote:
>
>You're saying that even though you personally can sign a codebase and
>put it on sourceforge for people to download, it would be entirely
>indistinguishable from someone who downloaded the codebase, put in
>malicious code, and signed it themselves by just saying their name was
>yours?
>
Yes.
Well, sort of.
In theory, you check the signature by making sure that it's signed
using the public key of the actual author.
This assumes that you have some outside way of knowing what the publci
key of the author is. In general practice, though, you don't; you're
given the signature, and the public key of the signer.
Great. I can check that there is a valid signature on this. But that
doesn't prove that the signature actually belongs to anyone in
particular.
In a real-world metaphor, supposing I want to purchase some
perscription medication without a perscription. I simply write out a
perscription, and sign it: Dr. Bob Smith.
It's a valid signature; it meets all the requirements of being a
signature. However, since my pharmacist doesn't know Dr. Bob Smith
from Adam, he won't relize that the perfectly valid signature I've
given him is *not actually the signature of the real Dr. Bob Smith*.
Now, if there was some public registry of signatures, the problem
would be solved: the pharmacist could look up Dr. Bob Smith in the
registry, and see that the signature I've given him is not actually
that of Dr. Bob.
But this would be a serious PITA, given that you'd need to keep the
signature of everyone in the world, and everyone who needs to check
signatures would have to have a copy.
>Why does it work normally, because verisign or whoever has a
>key-encrypted method of checking the validity of these certificates over
>the network?
Here's the basic concept:
I haven't met you before, so I can't be sure the signature you're
giving me is legitimate (That is, I can check if it's valid, because
that's how signaturews work. But I have no way of knowing that the
signature is that of the person you claim it to be of; a digital
signature can be linked to a public key, the key of the signer. But if
I haven't met you before, how do I know that the public key you show
me is actually your own; I could say "Hello. I am Microsoft. Here is
my public key. You can use this to check that this code, VIRUS.EXE, is
indeed a microsoft product.").
A certificate is like an old-fashioned 'letter of introduction'; it's
basically a document, signed by someone you *do* know, which links a
document to an identity.
In this model, I could say "Hello, I am microsoft. Here is a
certificate signed by verisign. You can use this to check that this
code, VIRUS.EXE, is indeed a microsoft product."
You would examine the certificate, which says something like this:
We at Verisign have verified that the public key X belongs to the
Microsoft Corporation
You can verify that the certificate is legitimate -- everyone knows
Verisign's public key, and therefore you know that the public key X
really does belong to Microsoft. So when you check the signature on
virus.exe, and find that it is indeed signed by the owner of public
key X, you have verisign's word that virus.exe really is a microsoft
product.
(In terms of my analogy, I'd be expected, along with the prescription,
to present a document signed by, say, a notary public, showing the
actual signature of Dr. Bob, and saying something like "We have
verified that the signature on this page belongs to an actual doctor
who is duly authorised to prescribe medications")
A mallicious person could not forge the 'real' microsoft signature,
nor could he forge a certificate claiming that the signature he's used
is that of microsoft.
The whole system works, and it works very well, so long as you can
assume that the certifying authority issues only legitimate
certificates -- that is, that in order to get a certificate from
verisign, you must present your public key and some sufficient proof
of identity (in other words, I can't just call up verisign and say
"I'm microsoft. I need a certificate.").
Unfortunately, thisi s sort of where it all breaks down. I probably
can't get a certificate in the name of microsoft, but I can easily get
one in the name of 'microsooft', and hope you don't notice.
Mark J. Tilford
> In article <3CEB4FCA...@museworldSPAMSUCKS.com>,
> Curt Siffert <sif...@museworldSPAMSUCKS.com> wrote:
>>
>>So what am I forgetting about the binary, does it *have* to be signed in
>>a way that hooks it in to the host it is hosted on? If not, assuming
>>the save/restore code is put in the sourceforge version of ZPlet, are
>>you willing to have a signed-by-you always-current binary build of the
>>applet available to download from sourceforge, for others to install?
>>Could be nice way around all this. All you'd be guaranteeing is that
>>the build is a reflection of what is in the open source as of that
>>version. ZPlet fans would trust Matthew Russotto's name I gather.
>
> Two problems with this
>
> 1) I still have objections to code signing in general, so I'm not going
> to do it.
>
> 2) Anyone can create a "Matthew Russotto" certificate.
>
How about allowing in-memory saves?
That is, you have N save slots, and any data saved can be restored during that
session, but is lost when the JVM closes.
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu
David A. Cornelson
> In article <3CE9927D...@museworldSPAMSUCKS.com>,
> Curt Siffert <sif...@museworldSPAMSUCKS.com> wrote:
> >
> Right. But what you're trusting is the binary. Not a big deal if you
Well, I have Flash installed among other 'signed' apps and I appreciate the
functionality that comes with them. I personally would love to see TADS,
Inform, Glulx, and Hugo interpreters that had legitimate certificates,
installed permanently as a 'player', and allowed for actions such as
save/restore. I would pay a shareware fee for this to help the programmer
recoup the certificate expense.
Another option, although still requiring a signed certificate, would be to
have the save/restore connect to a repository somehow on a server.
For instance, I already have a few games playable with Jetty and ZPlet on
IFLibrary.Com at http://www.iflibrary.com/default.aspx?PageId=Play.
In the very near future, I will have all of the files from the if-archive
'hooked' into the IFLibrary. This allows me to identify Z5 and GAM files
playable with Jetty and ZPLet. I won't even have to write specific code
since my xml templates will display this ability for any game with the
proper file extension (if the game breaks somehow, I'll have a way to tag
files that don't run properly).
So I would like to offer the user the ability to play a game 'in the
IFLibrary', even though the applet gets downloaded to their browser, and
allow save/restore to communicate with my server and place these files in a
server controlled area. If a user were logged in and clicked on a particular
game, I could potentially list their currently saved games in the web page.
By clicking on one of them, they could start up the applet with the restored
game automagically.
So now the user has an experience of playing IF, in a browser, with
save/restore ability, and they don't have to manage anything. It's all done
for them via the website. They can save, close the browser, and come back
later to keep playing.
In fact, Verisign is expensive. There are less expensive legitmate
certificate sellers out there. If the Jetty or ZPlet maintainers helped me
implement this functionality, I would offer to pay for the certificate.
Jarb