should an SST server be expected to be able to write to a client's stream?

We have an SST server application which exports (#export:as:) some of its objects so our client application can send those objects messages.  If our client hits a problem and happens to have one of these remote references (SstRemoteReference) on the stack, writing the walkback.log will ask that remote (server) object to printOn: to the client's stream.  This seems to be quite dangerous, putting the server itself at risk of a crash, especially during the uncertainty of whatever caused that client walkback to be written.  What do others think?

We fixed it via adding this to SstRemoteReference:

printOn: aStream

aStream nextPutAll: '<a remote reference>'

Background:

We actually had a server crash in the past where some client code passed a reference to a client object, and the server crashed trying to do something with that remote object.  I forget if it was writing to some client stream as here or not.  We never figured out what client code was doing this.  But we put in code on the server to reject any messages coming to it with remote references - except it does allow #registerCallback: to pass remote references.  That code works well - except it did catch the above walkback-writing #printOn: - which we could also allow but we are now avoiding.