|WikiProject Computer Security / Computing|
I don't think this should be merged either. A honeypot wants attackers to come to it. A honeyclient goes and finds the attackers! They're two completely different paradigms.
I dont think this page should be merged with general honeypots. When one talks about honeypots, they usually mean server honeypots. Client honeypots are quite different. A merged page would be quite large.
I do, however, would support merging this page with the page Honeymonkey. Honeymonkey is a specific implementation of client honeypots and it would make sense to merge them into one page.
I don't think so, because Honeymonkey is a variant of a farm of honeyclients from microsoft. It would be the same to mix lemonade into the article CocaCola. And honeyclients are a sort of security software/device not a specific implementation/application. They are getting more and more important.
I dont follow. Honeymonkey is a specific implementation of a client honeypot. This page describes the general concept of client honeypots as well as lists specific implementations, which honeymonkey is.
I'm against the merging of Client Honeypot/Honeyclient with either Honeymonkey or Honeypot. Honeypot is a global concept, and is first associated with server honeypot. Client honeypot is a derivation of the original concept with a major difference (inverted paradigm). Honeymonkey is a particular implementation.
It's similar (for me) to automobile>electric car>Tesla Rodster, and each concept is mentioned in its neighbor's articles (yet there are 3 articles). —Preceding unsigned comment added by Aptarus (talk • contribs) 16:39, 9 March 2009 (UTC)
I would recommend to rename this article to Honeyclient(Security Device) in contrast to Honeyclient(Software). I am doing this because when we call this Client Honeypots than the logical naming for normal Honeypots should be Server Honeypots, this isn't the case and Honeypot is well known over years, also Honeyclient is well known as a Security Device?!
I am concerned of naming this honeyclient as the term is too much in line with a specific implementation and would make it difficult to differentiate between the general concept and the specific implementation. I think "client honeypot" nicely captures what we are dealing without this danger. I also think that the term "server honeypot" is a term that one starts seeing more and more due to the recent introduction of client honeypots and if one wants to be more accurate then he will talk about server honeypots and not just honeypots. That said, I wonder whether we should create a page on honeypots, which just describe the general concept applicable to both client and server honeypots and then move the traditional server honeypot stuff to a page named "server honeypots".
Then we should rename it to Client honeypot but Client honeypot / honeyclient (section) is a confusing name.
I agree to renaming it to client honeypot.