Most wanted feature ? (Community edition)

The forum is quite stagnat those day... so i'll try to start a "non-specialised" thread in wich everyone can give a shot

I start a new post because the curent feature request thread looks like a dump.
It's so rarely used that no one relly bother eply in htere and it's hard to discuss on old post concerning features.

So my first feature request would be a proper feature request subforum with some kind of unified display / voting system. While i say that, the model that come to my mind is utorrent feature request voting : http://www.niteshdw.com/utorrent/

We migth also benefit merging appdefend / regdefend general discution into GSS as most ppl that have problem or want imformation simply choose one randomly. Then we migth have another forum regarding only RD rules and maybe another on issue with AD rules.


Next to the list would be a wiki. If the community voice high enougth and show enthousiam in the project, then i will volunter to be part of the wiki team.

Some idea of the wiki:
Product description
FAQ
Instalation / configuration tip
A page to describe each of the tony RD rules
Repository of custom user submited rules
> Subsection of "moderator" approved rules
Knowlege base / known bug and fix

While i'm on the community idea, if GSS ever adopt a event-based plugin system i'd like to see an optional module to collect statistic on program usage and rule trigger. A bit like prevx1, however it'll just collect information and when you are unsure you can see what other have done.

What those post have in common ?
ZDT: Zero development time.

This basicly means that YOU improve your user experience by participating in your community. No matter if for some reason we are waiting for the devloper, the user experience continue to improve instead of just waiting for next upgrade.

The harder part is to start. Then community will generate more community and it'll go by itself (almost)

 

Re: Most wanted feature ? (Community eddition)

Hello,

The utorrent thing sounds really cool, but only logged users should be able to post on it and click yes/no, to avoid erroneous spamming from guest sources.

About the Wiki community, I really don't know, it's an innovative idea. I would like to know what Jason thinks about it

Regards,
gkweb.

 

Re: Most wanted feature ? (Community eddition)

hi gkweb thanks for the answer

about the wiki ... what do you think can go wrong ? Or is there any reason of not having a brand loud YES

 

Re: Most wanted feature ? (Community eddition)

proper request:

child-parent process control .. do not need to say more.

please @ all next posters : the only requests are
- no compares with other programs
- no issues with this build (this is no complain thread)
- no blames and trollin" posts (those will be removed appropriately)

.. (hi f3x, I hope this is what you want with this post ..) ..

I do think a wiki can be a good thing, if there is a customer base great enoug to have a decent wiki anyway .. a customer base able to give thougts and ideas, malware entries (regdefend/appdefend) with the possibility to have feedback ..

that would be awesome! but this already exists with regdefend imho .. ..(regarding the beta entries and the ones that are checked .. ) and that's why it has to get merged together IMHO Regdefend and Appdefend into one program ..

therefore if RD could look a little more like REGMON, the Regentries (Traces) could be added here on the forum and could be blocked with Regdefend (that's the community I would like to see) but therefor some internal stuff has to be changed, and some stuff has to be added .. and this has been told before ..

best wishes and IMHO this is the best RD/AD thread in a long time ...

Infinity

 

Re: Most wanted feature ? (Community eddition)

hi Infinity
by reading your post it looks like you have put your moderator hat
So i enroll you in the wiki team ... (btw you dont have any choice )

@
indeed child - parent process control is something needed.
@

another one in that idea is to have an option to allow a program to modify itself
this is very common with commercial packer (armadillo) and it's not cause a file is packed that we absolutely want it to be able to modify any program.



@
that would be awesome! but this already exists with regdefend imho .. ..(regarding the beta entries and the ones that are checked .. ) and that's why it has to get merged together IMHO Regdefend and Appdefend into one program ..
\@

I have some problem understanding your post.
I talked about forum merge ... not really program merge.
I another topic however i highligted that there are possible gains of better integration between modules.

I do not have all your experience with SSM however i feel that even in such *all in one* integrated security system the registry section is quite independant from the process section. So the only gain/loose of having separate buyable module is a matter of GUI/marketting/licensing.

I beleive many like the current modular buying approach. I would have myself hesitated if i had to buy to whole thing in one shot.

@
therefore if RD could look a little more like REGMON, the Regentries (Traces) could be added here on the forum and could be blocked with Regdefend (that's the community I would like to see) but therefor some internal stuff has to be changed, and some stuff has to be added .. and this has been told before ..
@

Once in a long time ago gss used to have this feature enabled.
I guess some "more recent" feature conflicted with it and it have been removed. Or jason tougth that there are plenty of other tools that does the job better.

One tool for each task alwais is a good mentality

 

Re: Most wanted feature ? (Community eddition)

You can sort of emulate the capturing process from the old RegDefend by having an ALLOW rule which logs everything. This is why I removed the capturing segment since it was sort of useless with the new update.

In regards to parent->child controls, I do not like the conventional way of handling this, which some other products have done. One reason is due to the slowness, the other is the complicated mess the GUI has to become to support those sorts of features. I am looking into alternative ways to handle child relationships, maybe flags which allow some things to occur which are common, etc.

Packers modifying "themselves" (which is really another process in the case of armadillo) might be something I will allow by default. I can see little way to misuse a process modifying another process with the same name since theoritically it should be the same code running. I will have to do a few more tests since I have seen one possible misuse most programs do not recognize which XP allows.

I'll look into the WIKI stuff, it sounds like a good idea and GSS could probably link out to it also.

 

Re: Most wanted feature ? (Community eddition)

@ Jason, thanks for the reply.

Yet this can lead to lost-in-crowd situation where you mix those log with all other log. Plus it's very bad for log-archiving. Moreover having a dedicated section to folow the registry of a process X and all child process X.X X.Y X.Z is a first step in the direction of "undoing" a malware action, a feature i would really like in gss. It can also undo bad user action where some program can get corrupted when you block it's registry write.


Jason i agree with you, i do not see the complete usage of child-parent relationship. However i'd like to see precision in the rule like:

Allow modify/kill alwais
Allow modify/kill himself
Allow modify/kill child
Allow modify/kill parent

So it's not a particular ProcessOneName > ProcessTwoName relationship,
more like a context dependant relationship.

Or in that kind of idea, maybe in addition to .default ruleset you can have a .unsafe ruleset. Then you can launch a program with unsafe flag by rigth-cliking on it or using a command line tool. The unsafe flag will propagate to all his child. Kinda a mix of defencewall and traditional hips. If you do so you can also have a .install ruleset that does the same thing with another flag and other set of permission (generally more open than default).

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

About packer modifying "themself".
If i remember i've encountered firewall leaktest that modified themself to fool a firewall.
this is what i vaguely remember however i do not have the possibility to test it now.
I'll give more information whe i'm back at home.

http://www.firewallleaktester.com/leaktest13.htm

 

Re: Most wanted feature ? (Community eddition)

I am just thinking to erroneous data that can be sent purposefully by malicious people, hence the need to have wiki moderators to analyse the proposal, and then to acknowledge it or reject it.

Besides that it's a really good idea, I hope you will give birth to this project

Regards,
gkweb.

 

Re: Most wanted feature ? (Community eddition)

I don't personally feel one can really "go wrong" by having wiki's at certain sites but I will agree as discussed in our Wiki for Wilders? thread....that regardless of which Wilders forum this might be considered for....whether it be a dedicated product support forum or a non-dedicated forum....the non-need far outweighs the need IMHO.

 

A wiki have the advantage of organising information by similar topic.
A forum is organised by timeframe, information get lost, pll ask same question 10x time.

I see the wiki more part of the product website than part of the interaction forum.The wiki is just like an instruction manual with endless possibility as the weith of maintening it is distribued across the comunity. The more the community need a wiki, the more this wiki will develop. The more the wiki will develop the more we'll need a kiki I think this is the reasoning to answear your non-need outweigth the need. No one currently absolutely need the wiki as it's easier to ask information on the forum. However, as mentioned, forum is organised by date and it's very easy to loose information or to not make the effort of searching.

BTW your link currently point to nowhere
( this is a problem with both forum and wiki )

 

Sure it does....try it again

 

Someone is cheating

Yes I do undestand that you cannot replace a such a whole thing as a forum by a wiki. Especially if it have so many different topic. Microsoft knowlege base would be a better way to represent hte whole forum than a wiki.

However when you do a wiki for application specific need ( you'll notice that i even enumerated a number of possible thread structure ) then it's another situation.

-------------------------------------------
BTW that "lips scealed" smilies is not very self descriptive until someone actually search the meaning in the post-reply forum. IMO it look like someone who is going to throw, yet without the eye / frown expression. (However i know it's hard to express eye expression in two pixel radius black circle)

 

DOnt need another feature. Just need it to work with Punkbuster.

 

that's a complain .. and you'll get 2 min points from now on ..

wiki was nice till it lasted .. nowadays all posts/beautiful threads and whatever are poisoned with untrue 'facts' and to much bla bla bla

therefore I do think that *when* having a wiki on this subject .. a subject that has many 'undocumented area's on whatever basis .. It would be a must to have a moderator, someone to control what's gettin posted, the relativeness and on facts .. otherwise it would become a joke and that's not the intention imho .. (at least, finaly .. I presume it would have the same effect as this forum .. latest news with wiki updaters and whatever .. lots and lots of work .. !!! ..)

just my two cents but if there is one thing here at WSF, that's goodwi!!

so maybe .. who knows