[Arianne-bugs] [ arianne-Feature Requests-3439835 ] Don't show admin names to player in supportanswer

[SourceForge.net <no...@so...>]

Feature Requests item #3439835, was opened at 2011-11-18 02:50
Message generated for change (Comment added) made by oslsachem
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351111&aid=3439835&group_id=1111

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Katie Russell (kymara)
Assigned to: Nobody/Anonymous (nobody)
Summary: Don't show admin names to player in supportanswer

Initial Comment:
As part of our policies on personal admin involvement, we should anonymise admin names when answering support queries.

Several other high profile multiplayer games do this.

The admins still need to know who is replying to the player and so do the logs.

The anonymising function should not just pick a random string. players need to know when the same admin is replying to them on a specific query.

Also it should distinguish between different admin so the player knows when a new admin joins a discussion. 

The anonymising function should not always use the same string for a given admin or it would be quickly clear who is who. It could change daily.


----------------------------------------------------------------------

Comment By: oslsachem (oslsachem)
Date: 2011-12-07 14:09

Message:
>> For an unknown variable, I guess it doesn't need to change daily? 
You are right. I was considering the (date + unknown variable) as a whole,
which is unnecessary.

>> We could hash 
>> name + date + something in server.ini or similar?
Yes, the unknown could be persistently stored in a file.

>> Perhaps it is better to have simply the first admin who replies, is
admin1,
>> today
>> (add to an internal map with timestamp)
>> the second who replies is admin2, today
>> (add to an internal map with timestamp)

>> When an admin uses supportanswer, if they are present in the internal
map
>> and the last time they used support answer was within N hours, use the
>> anonymised name, adminN, otherwise, remove the old entry and add a new
one
>> with a new name for the admin.

This seems the ideal solution because:
- It avoids using long and difficult to remember hashes.
- It avoids building beforehand and flushing a static list of the current
admins and dealing with the disturbance of adding new admins to it.
- It takes advantage of a randomly ocurring associated event such as the
order in which the admins join the support discussion instead of using a
purposefully generated unknown.
- It uses a related event for timeout (elapsed time since the admin's last
support answer) instead of a prefixed time frame (midnight change: an admin
joining at 23:59 would time out just after one minute).

It should be noted that this map should update the respective admin's
timestamp each time she uses /supportanswer if she is already in the map. 
Moreover, this map should reuse the numbers it has issued to admins - once
these have been removed from the map.  Otherwise, the numbers issued by the
map could grow indefinitely unnecessarily.


----------------------------------------------------------------------

Comment By: Katie Russell (kymara)
Date: 2011-12-07 02:05

Message:
For an unknown variable, I guess it doesn't need to change daily? 

We could hash 
name + date + something in server.ini or similar?

Admin names are already known to players and would naturally get known on
the occasions when we do become visible. This is just for support answering
that I wanted the feature.

Perhaps it is better to have simply the first admin who replies, is admin1,
today
(add to an internal map with timestamp)
the second who replies is admin2, today
(add to an internal map with timestamp)

When an admin uses supportanswer, if they are present in the internal map
and the last time they used support answer was within N hours, use the
anonymised name, adminN, otherwise, remove the old entry and add a new one
with a new name for the admin.

----------------------------------------------------------------------

Comment By: oslsachem (oslsachem)
Date: 2011-11-22 12:31

Message:
>> As an initial attempt I tried a hash of (admin name + todays date).
[...]

I now realize that something unpredictable needs to be appended to the
object to be hashed (Cryptographic nonce). Otherwise, a user which knows an
admin's name, today's date and understands the source code may replicate
the hashing process and may check if she is talking to that particular
admin.
This means that the anonymising function should rely on an unpredictable
object in memory which is modified once daily.
Alternatively, the admins could use names which are unknown/unpredictable
to players.

----------------------------------------------------------------------

Comment By: Katie Russell (kymara)
Date: 2011-11-22 01:58

Message:
Osl, thanks for your reply!

I'd wondered about the daily change thing too. I thought about making the
switchover happen about 4am server time instead of midnight (somehow?) as
it's usually very quiet then.

Sorry, I meant to commit what I'd done so far and I haven't got round to
it: will try to tonight or tomorrow!




----------------------------------------------------------------------

Comment By: oslsachem (oslsachem)
Date: 2011-11-21 12:24

Message:
>> The anonymising function [...] could change daily.
If the support discussion happens close to the daily change, an admin could
end up with two different strings. However, setting a timeout for each
player's request for support in order to change the hashes could be much
more involved.

>> [...] any thoughts on making the hashed object a lot smaller?!
I think the minimum size could be "admin#n" with n being a number between 1
and the maximum number of authorized admins at a certain time.

A list of the currently authorized admins could be built (I don't know how
difficult this actually is) and then shuffled, and the position of each
admin in the resulting list could be her hash:

Collections.shuffle(adminsList, new Random( todaysDate))

By using today's date as the seed for the random number generator one could
expect to always get the same shuffled list in the same day because,
according to documentation : "If two instances of Random are created with
the same seed, and the same sequence of method calls is made for each, they
will generate and return identical sequences of numbers."  But I haven't
tested it.

A drawback of this approach is that if a new admin was added to the list,
the hashes of the previous admins in the list could immediately change.

----------------------------------------------------------------------

Comment By: Katie Russell (kymara)
Date: 2011-11-18 03:02

Message:
As an initial attempt I tried a hash of (admin name + todays date). That
gave an array of bytes. Then I converted the array of bytes to a BigInteger
(another option was to a hex string). I was using Marauroa's Hash class for
this.

And then I returned "admin" + biginteger instead of the admin name in the
message to the player: 
 Support ( name ) tells you:
 But it didn't replace it in the message to supporters.
This would be unique per admin per day, this means users know when distinct
admin are dealing with them, but not who they are. and it means that a
history can't be kept to eventually 'deduce' that admin238934393939490349 =
superkym etc, because it does change each day. I didn't want it a hashed on
timestamp because I'd rather they know when the same person replies.

The BigInteger is clearly way too long.

Aside from being very long it works nicely for supportanswer where the
player is online, the 'sender' is replaced in the message to the player.
Need to find a solution for the StoreMessageCommand for when the player is
offline. The admin name should perhaps still be stored as the source of the
message? Maybe when 'S' type stored messages are sent it should simply say
'support' and in those cases we likely don't need all the hashing stuff.
it's not an active conversation. would have to handle that when messages
are sent.

Any thoughts on that stored message issue and any thoughts on making the
hashed object a lot smaller?! It's not super critical that it's a perfect
hash.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351111&aid=3439835&group_id=1111