My latest blog on the subject of Sandbox trend for the AntiVirus market
Melih
Melih
I enjoyed this read. There is a massive difference between simply adding a sandbox to a security suite or antivirus software, to actually INTEGRATING, utilizing a sandbox into a AV engine.
This is why programs like sandboxie are NOT for the average user, period. Because this is a on-demand sandbox where you will need to sandbox the applications run by your self. Avast Internet Security is the same deal when they added on their sandbox, It is a on-demand sandbox and the novice on the computer will have no idea what sandboxing is, or if they can actually sandbox applications.
CIS 4 currently in beta is the first and only suite to UTILIZE and INTEGRATE Sandboxing in the AV and HIPS engine! This is pure DEFAULT-DENY, automatic sandboxing to achieve max security and as less number as alerts as possible. It’s a technology no other has, COMODO should be proud to achieve this because programming this kind of thing to work as it is even in beta, would be a very challenging task but the security and benefit goes directly to end users.
So it’s good Comodo Internet Security 4 is using sandbox, and not adding it on. Keep up the good work.
Josh
Hi Guys,
I really don’t know how to post a short message about the “issue”… 
… but I will try, including the fact that there were some discussions in other threads
and I hope there will be more
Melih,
Please keep in mind that all you and your company are trying to do is highly appreciated.
We all (most of us?) do understand the intentions - they are grate & laudable.
But mistakes are mistakes.
Your blog article about SandBox is more “marketing gimmick” (using your words), than it is the way presented by others (whether those are free or commercial)
At least you can find points in there statements & discussions about what cannot be achieved and why some things should not work anyway… "because of "; what users should not expect and why; what are the dangers … and so on … and all that
Your article dose not contain neither technical details nor references to some important things mentioned that users should be aware of
Therefore I think - the creation of the SandBox and any novelties Comodo can add and offer compare to others is one thing, but the integration - is a mistake.
Josh,
Your excitement that you are expressing here and in other threads has no technical basis. Sorry but I had to say that - you are just overexcited. 
The reduction of the alerts cannot be by any means the major goal
The major goal is the Security itself, its strength and stability and all advantages that should be expected from layered security.
The sandbox could be and (excuse me - and should be) implemented as standalone module
… and all goodies that Comodo wants to add by introducing it can be implemented that way too even better.
Sure, I have to refrain from going into technicalities in this thread…
I hope you will accept my message calmly and without any hard feelings.
Well, I am just a user of the excellent free Firewall (currently) - my move will be very simple - I see troubles I change Firewall - as simple as that.
That will be a bit different with development and many(!) changes and fixes to come and the maintenance.
And for those who are not using SandBox there will be many unneeded updates reinstallations/ and other issues … we all know how it goes
I know your answer - we will solve all that - you don’t worry
Let’s hope … sincerely… I’m just convinced - all that would be much easy and less stressful if the SandBox is a standalone component which is communicating through the proper designed channels with other components of the Suite
Thanks guys
hi SiberLynx
I thank you for your feedback and really appreciate your openness.
Let me try to address some of the issues you raised:
1)Our Sandboxing usage is a patent pending technology, until patent or patent application is made public, we will keep the technical details private.
2)You state the goal should be security: Compared to traditional AV’s i believe CIS has already achieved a higher level of security, but usability was a hurdle that we had to overcome. So we found a way of killing 2 birds with one stone, by sandboxing all unknown automatically. This way, we provide security as well as usability all in one! I think this is a very clever approach.
3)In my blog i have identified the MOST important difference which is auto sandboxing. This is THE difference, I hope you can understand what the implication of this is.
I believe you are saying make sandbox standalone so that you can continue enjoying CIS and you are worried that sandboxing might introduce some issues.
I wholeheartedly agree that everytime you introduce something new, you are running the danger of having issues. But we can’t stop progress. We have to continue to innovate. I hope you can understand our situation.
As you rightly predicted, what makes us different is our ability to respond to our users when they have any issues. What you can do is to help us to make sure beta is very stable so that when you upgrade you don’t have any problems. Btw: you will have an option to use just the firewall on its own if you so wished in v4.
thank you
Melih
Thank you for reply Melih,
Sure you should not reveal secrets. Mentioning technical details was not about that
But there is an existing technology you build upon. That is a MS Patch Guard and nothing we can do about it (currently) that brings problems for x64.
For 32bit you can do differently and it is proven to be quite solid despite not 100% (as usual) but close. Nothing like that is in x64 regarding SandBoxing and its reliability
But fine, you know what you are doing.
At the same time, you are talking about integration. From what we know now that is not what you wrote : “an option to use just the firewall on its own"
If that is the option similar to “No AV” during installation… but…
I don’t want SandBox’s slider and options inside. I don’t want Firewall upgrades /reinstallations when something is changed for many reasons to come when SandBox’s functionality being fixed / patched / improved … etc.
Running unknown applications sandboxed by default? Good. Relying on Trusted vendors list / added trusted applications? signed application …etc. Fine again.
But may I ask why for example we cannot have a component that is the “Apps List handler”?
Its function(s) is just managing such list and serve any other existing or newly developed components
That could be very helpful even by its own.
We can:
check any files whether they are signed or not (as with other Tools available);
see what vendors Comodo is supplying as Trusted;
Edit that list
many other things can be done irrespectively to the use of other parts of a Suite
As a component it has its Private Properties and Methods and there are the Public ones.
Then AV / Firewall /Sandbox (standalone) or anything else, as a matter of fact, that you may develop in the future can request information and exchange information using their methods and properties with that “Global List Object”.
The list of trusted is not an entity belonging to Firewall / AV or Sandbox per se. Any of the latter components just asking: “GiveItToMe” and the “DisplayIt” method will show it.
User have changed / set something in different Components regarding the Applications : “JustSendThat” - changes are done in the global list by the global list’s methods.
Sure, that is a simplified example, but I hope you understand what I mean.
In this case I can indeed switch off anything I want completely and there is no difference in functionality of those components I am currently using, because there is no communication channels.
Needless to say, if you build everything around and based on such conceptual thing as applications known/trusted and unknown, and so on… I cannot and should not “switch off” that(!) module or object .
The integration this way is achieved, from outside, so to speak, but not by artificially integrating from “inside” as far as I can see it currently.
I honestly cannot see how such approach and running satandalone Sandbox can stand on the way of auto-sandboxing of unknown application as you pointed in #3 ?
I wholeheartedly agree that everytime you introduce something new, you are running the danger of having issues. But we can't stop progress. We have to continue to innovate. I hope you can understand our situation.I do understand the situation. You will continue to innovate. The progress is unstoppable indeed :)
…but my point was - different and more modular (object oriented) approach will dramatically decrease “dangers and issues” That is proven fact.
Well, if I am mistaken I will be just glad to know that and I’ll stand corrected, if not there is no drama – I definitely cannot not make you change your mind, but I know another firewall and another SandBox (if I need) that are working as standalones
… despite I want to use Comodo Firewall with many improvements from the existing Wish List… but that probably will never happen unfortunately because developers are too involved and don’t have time for that.
Thanks again for your time
My regards
I like it!!! ;D :-TU
That article has got my brain ticking.
I prefer ‘Alerts’ myself. But…
Scenario = Sandbox ‘enabled’ on my Mum’s PC.
Question 1:
When I go to my Mum’s house, could I take a peek in her Sandbox?
Question 2:
If I notice something in the Sandbox - which I know is Safe - could I then answer the Alert to have it physically installed and removed from the Sandbox?
Question 3:
If I notice something in the Sandbox - which I know is Malware (or just not needed in the system; like Crapware) - could I then answer the Alert to have it completely destroyed (Files & Reg’ Entries)?
EDIT:
Where I say, “could I then answer the Alert”, what I really meant was, “could I then mark the ‘unknown’ entries as Safe or Destroy”.
I saw on the ‘CIS4 Promo video’ that Sandboxed items are sent to Comodo Lab for analysis. I’m hoping this is not done automatically. It would feel like stealing. Especially for software writers.
I know you might need to be hush hush on the sandbox ATM while the patent goes through. But i really think we need coments from developers on the points SiberLynx has raised. Especially on using a modular approach to the integration of components and why comodo are not doing it this way.
On the article i think automatically sandboxing unknown is a great approach versus sandboxing browsers. Cause this then removes the annoyance of emptying the sandbox and loosing bookmark etc, It also less likely to let the user run something malicious unsandboxed.
Cheers
Shaun
I agree with the above/quoted, on another note… well done and interesting read Melih. I’m glad you gone the patent route and rightly so! Cannot wait to see Comodo take CIS to another level when CIS v4 is released, and then BB after as well as other nice additions.
:ilovecomodo:
Hi MetalShaun,
Thank you very much for expressing the interest in some of my thoughts.
I know though that most likely I have a little hope or rather no chance whatsoever to be heard regarding this “over-integrated” development that went too early too far unfortunately, and now it’s too late.
As for the automatic SandBoxing that is not only the browsers (which you definitely know) and usually users of existing standalone solutions can choose how to manage that for any given application or use automatic sandboxing etc.
That would be definitely just unacceptable. There must be an option.
“The hope it out there” (?)
But that is interesting not only from this perspective.
Have a look at Pending Files implementation, which is sitting in the Defense+
And then, there is “Submitting Suspicious files” that is sitting somewhere in Miscellaneous
Leaving aside the great deal of inconvenience in selecting feature that was not fixed (yet?) the idea and the set of functions are not bad.
Except, I don’t remember now but the option of auto-sending pending files is somehow “hidden”. It’s in one of the dialogues when submitting pending files. I haven’t used it for a long time – that’s not a main point
My question is why those identical by nature functions are spread?
What is the big difference in submitting already unknown files “caught” by Comodo and adding any file that user want to send for analysis despite that was even never used, for example?
How that ( Pending / Unknown List) may not be used and live as a separate entity whether it is necessary for AV module, Defense or Firewall and the newly introduced Sandbox?
That actually can be utilized even if we are not using any of the mentioned components or some of them.
Say Defense+ is completely disabled or I may switch off the Firewall, I am not using AV at all…
… but I can check “unknown” files/ processes with Comodo lab. Why not?
My questions are:
How conceptually the notion of “Unknown (process or file)” / “Need to be analyzed”… call it whatever you like… could be different to the different components of the security Suite?
Why that cannot be managed by the dedicated Object that is fed by respective data from outside whether it is any component (SandBox included) or a user and has an ability of sending data ( auto– or manually ) that was gathered, can be observed and manipulated?
That was just another example in addition to the (virtual) “Trusted List” object.
Cheers!
I believe personally that v4 version will be more stronger than ever with “sandboxing”. Also, as I see now many security suites don’t support sandbox at all - so this is telling me that Comodo has great strategies for users, especially when you try to even see that many paid products (I can count them on my fingers actually, but I won’t say their brands!) are still LESS effective than ComodoIS which is a free product. This is pretty shocking, so go on Comodo - you are awesome, you know why?
In my 15 years of working on PCs I didn’t see in my life ever that one company is building that STRONG security based software which is also FREE. So many thanks & respect!
“Love it!” :-TU :comodorocks:
Hi g33k,
:-TU Agree! Thanks and respect no my behalf too.
:-TD Disagree!
First, as a concept (many things were discussed here and in other threads).
Then, what do you mean by “security suites don’t support sandbox at all”
If you mean by that: “not developing” - then, yes.
But why should they when there are solutions commercial and free. Install SandBox and use it with other security.
If you mean that some incompatibilities can emerge. Where do we not having those?
That can be addressed and solved (see some examples with “SandBoxie”)
Do you have any doubts that Comodo’ SandBox will have the similar issues?
Those (some of them) are already determined for any Software virtualization implementation in x64. We will have escapees (whether those are “bad or good guys”) being able to run free outside.
And what about the hardware virtualisation? Do other security not supporting hypervisor? Well, at least that cannot be integrated (thanks for that)
Virtualization better be and it Is a separate entity.
Moreover, if free Comodo’s SandBox was implemented as a standalone (with all alleged novelties) more users could use it having their beloved security in place.
If the integration of the Comodo’s SandBox was done “from outside” those who are using components belonging to Comodo Suite could have an additional benefits - that is different and that would be definitely appreciated by those using whole Comodo Suite or just parts of it.
At the same time, those who does not want to use SandBox (irrespectively which one) are not affected at all no matter whether they are are Comodo users or not.
My regards
First, as a concept (many things were discussed here and in other threads).Then, what do you mean by “security suites don’t support sandbox at all”
If you mean by that: “not developing” - then, yes.
But why should they when there are solutions commercial and free. Install SandBox and use it with other security.
I meaned by that that many security companies didn’t accept still in their suites sandboxing based security. I don’t know why, because I am thinking personally that sandboxing can improve drastically security on OS.
Especially on 32bit based OSes, because they are more vurneable to rootkits which is I believe a great security threat today and it will be more greater security threat in the future.
If you mean that some incompatibilities can emerge. Where do we not having those? That can be addressed and solved (see some examples with "SandBoxie")
I didn’t test really v4 version, which is in heavy stage of developing. Main fact is that Comodo will have pretty stronger security suite with sandboxing technologies.
Do you have any doubts that Comodo' SandBox have the similar issues?
I answered to this question, see my previous comment.
Those (some of them) are already determined for any Software virtualization implementation in x64. We will have escapees (whether those are “bad or good guys”) being able to run free outside.
Look first. x64 arch. is more secure than 32bit arch. Reason, today you cannot find so many 64bit fully written rootkits or malware - only 32bit are presenting for now. But yes I didn’t say here that 64bit written rootkits don’t exist! They are existing, but they are very rare! Actually
Speaking about great security, I would love to see Comodo V4 64bit with Sandboxing on WinNT 64bit based OSes, this platform is hard to break with any type of malware.
But in the future we’ll see more and more rootkits and other type of malware for 64bit platform I believe in that too.
And what about the hardware virtualisation? Do other security not supporting hypervisor? Well, at least that cannot be integrated :) (thanks for that)
Indeed and I am agreeing with you.
Virtualization better be and it a separate entity.
Indeed!
Moreover, if free Comodo's SandBox was implemented as a standalone (with all alleged novelties) more users could use it having their beloved security in place.If the integration of the Comodo’s SandBox was done “from outside” those who are using components belonging to Comodo Suite could have an additional benefits - that is different and that would be definitely appreciated by those using whole Comodo Suite or just parts of it.
At the same time, those who does not want to use SandBox (irrespectively which one) are not affected at all no matter whether they are are Comodo users or not.
Then these type of users can install another security suite. But I said that today still many paid-security suites don’t have sandboxing at all! This is ridiculous really after all!
My regards
Cheers!
Hi g33k,
Thanks for detailed reply.
As for rootkits, I was actually not talking about them at all in conjunction with x64
That is a “normal” 88) malware I was talking about.
As estimated currently more than 10%(!) cannot be protected by sandboxing there;
running inside the sandbox is quite special as well and can allow escaping and running processes outside of it.
Regarding the companies not developing sandboxing and your comment about using security other than Comodo’s Suite or different components…
My point was quite opposite - I was saying that having the standalone sandbox developed by Comodo would allow others to use the whole Comodo’s Suite or just Comodo’s Sandbox if that is indeed allegedly revolutionary.
… and there were some points where we have a complete agreement … that is good too Cheers!
Even mach microkernels were meant to be modular on paper but developers had to face reality and leverage on an hybrid design.
It would be interesting to read about such technicalities hinted (but undisclosed) above but in a separate topic, even more if eventual criticism seemingly provided for constructive purposes (in few topics) would account for V4 specific integrations and dynamics and not leverage on general assumptions on modular design or conjectures on V4 (or V3) implementation.
Indeed IMHO it is unclear if some comments actually leverage on verified findings about CIS inner and less visible engine or are guesses based on the monolithic V3/V3 GUI design or on the names of services/drivers active in different installer-provided setups (AV, Firewall, whole suite).
X64 OSses are currently preinstalled (if not bought by users themselves) on many PC or laptops and it doesn’t look this is going to change.
Besides some points that implicitly stress seemingly unsurmountable patchguard drawbacks that conclusively affect end-users, it would be also interesting to read about, for a change, eventual advices meant for X64 patchguard constrained end-users (or developers) as this MS feature affect security development on X64 and it is likely to impose restrictions to all security developers carnying effects not seemingly limited to sandboxes.
Considering the number of contributions over such topics I hope the above requests would not appear just my selfishness even if it is obvious my interest about the clarifying technicalities apparently omitted in currently available comments.
... some advices about X64 patchguardWhat advices? I was not about any advices regarding the Patch Guard. I do accept that the Patch Guard exists and I do not support the ideas that are expressed in other forums about killing the Guard until the next MS update in order to built "perfect SandBox".
this MS feature affect security development on X64 and it is likely to impose restrictions to all security developers and whose effects are not seemingly limited to sandboxes.True. Who doesn't know that? But I was not questioning that. My opinion was about creating Sandbox as standalone knowing those limitations. Nothing else.
Finally, according to “the agreement” I should refrain myself from replying to you (well … sorry about that)
Therefore, I have to thank all participants. Let’s hope we’ll meet in another thread
Indeed X64 patchguard is often confirmed to impose constraints to security applications on X64 systems but it doesn’t look this prevented sandbox development for X64 by 3rd parties :-La
Though these restrictions might affect also sandboxes if was not clear from your opinion how much these restrictions would affect X64 sandboxes nor, by any chance, it was clarified if those restrictions apply to the design/purposes of V4 sandbox on X64.
A more detailed clarification about the impact of such restrictions on V4 would be greatly appreciated obviously because then there would be a way to clarify/search-for how address such implied shortcomings and the chance to confirm if any of them affect V4 during beta-testing.
There are many members in these forums and a more focused topic could provide something more valuable than generic concerns which could apply to whatsoever X64 security software.
Thanks for pointing out out you self-imposed restriction/agreement. I guess “sorry” would be a poor alternative to clarifying those undisclosed technicalities in a new topic fit for such purpose but perhaps you would be more comfortable providing hints here and there without technicalities.
I assumed there were more to some comment of yours but I guess I’ll never know anything other than your assumptions (I believed you specifically refrained from posting technicalities “in this thread”. well … sorry about that.)