Suggestion: Make robots addresses distinguishable

[GoogleCodeExporter]

I think it is important to make robots to be easily distinguishable from human 
wave participants. It seems to me that the easiest way would be to add a 
certain tag to the robot address on the registration. 
For example, if robot wants to register a name "nicebotty" at wiab domain 
"example.com" then it's full address on this domain will be 
nicebotty@robot.example.com and not nicebotty@example.com as it is now.

Original issue reported on code.google.com by vega113 on 26 Nov 2010 at 9:40

[GoogleCodeExporter]

I don't agree that this is desirable or feasible in the manner suggested.

I'm aware of two main motivations for distinguishing robots. The first is in 
order to prevent abuse, prevent robots entering feedback loops, and for other 
security-related reasons. As has been pointed out before, it's not reasonable 
to add robot-detection mechanisms deep in the protocols (such as embedded in 
addresses) because in federated contexts it's impossible to know that other 
servers are playing by the same rules. This would be somewhat like trusting 
mail servers not to send spam (except from nicebotty@spam.example.com). 
Protection against abuse needs to be done elsewhere.

The second motivation is for user experience, to set the right expectations for 
a user who is collaborating with a robot. This is a good motivation and we 
should do something about it, but again I disagree that it should be built in 
low in the protocols (like embedded in an address). Wave hosts may have very 
legitimate reasons to automate some interactions (e.g. talking to a customer 
service entity) without necessarily exposing that they are automated. Building 
something into the address makes it deeply immutable, so a service could not 
evolve from one provided by a human to one fully or partially automated. 
Embedding it in the address again requires that federated servers play by the 
same rules, which is impossible to enforce.

For this second case, I think wave providers could provide "best effort" 
distinction of robots, at least of those hosted on the same service, based on 
higher level profile information. Somewhere up in the account system where a 
user's real name is stored there could be a robot flag and wave systems may 
choose to expose this to the user. If/when we have federated account data then 
a server could also fetch this from other hosts, but again on an untrusted 
"best effort" basis.

Original comment by ano...@google.com on 26 Nov 2010 at 5:09

[GoogleCodeExporter]

I think the difference in opinions arises from differences in evaluating the 
potential harm (abuse) that malicious robots can cause. 
Regarding the comparison with email spam - imho it doesn't really apply to the 
situation with waves, since spam email cannot harm your existing emails, while 
malicious robot can harm your existing waves.
Regarding feasibility - while it is impossible to enforce the policy over all 
federating servers, still - servers that would follow such policy will be 
considered more secure. It also would gives an option to block all users from 
insecure domains.

I agree that profile based approach is the best way to solve this issue. 
However, from what I understand, it might take a lot of time until it would be 
implemented, while the need to protect from malicious robots is urgent.
I think that the inability to protect waves from malicious robots can in effect 
prevent any company to adopt it in commercial applications. 

Original comment by vega113 on 26 Nov 2010 at 6:26

[GoogleCodeExporter]

I think there's another reason for making robot addresses distinguishable. 
Let's imagine situation where 10 wiab servers federate with each other. There's 
1 robot hosted on some other server - foo@somewhere.com on 
http://foo.somewhere.com. Now some user wants to use this robot, so he 
registers this robot as foo@example1.com. (or maybe the robot creator registers 
it). Now, other users on the same domain - exampple1.com don't know about the 
relation of foo@somewhere.com and foo@example1.com. So they may reregister the 
robot again and again as foo..._@example1.com and also on other wiab domains 
foo...@example..._.com. In other words same robot will be known under many 
names in many wiab domains - creating confusion. 
I think the solution can be like this: 
1) Robot names should be distinguishable, so robots do not compete with users 
for  usernames
2)implement "robot usernames" lookup - so user can lookup robot alias on the 
wiab domain by the robot's real address, i.e. looking by "foo.somewhere.com" 
will result in foo@robot.example1.com

Original comment by vega113 on 20 Dec 2010 at 6:25