SpyShelter 15.3.0.898 now available!

Yes thanks, that’s also a good article. :slight_smile:

Like I said, it’s important that system processes can make these changes (without alerts), because you don’t want to break the system of course. But other processes should normally not modify/add certain registry keys.

Most of the time, apps will try to modify regkeys related to autostartup and scheduled tasks. But I’m not sure if it makes sense to monitor WMI/COM Objects, because I don’t know how often these keys are being used by legitimate apps.

I will start by saying that I have not subscribed to SpyShelter Pro because I don’t see the point in paying to protect 3 devices when I only own 1 (I live in Italy so I should pay yearly 44,76 € or 33,56 € with 25% discount , VAT 22% included, for me it’s too expensive) but I think that an option to enable / disable registry protection would be more appropriate.

Thanks for your feedback on registry protection.

Also, thanks @Surt also for your detailed feedback. We will consider this and think carefully about next steps. Thanks also @jasonX on the poll idea!

I have made a poll in the main thread for those who want to vote and give more feedback on removal of Registry Protection.

I just realized something about why I disabled registry protection in SS 12. I noticed that it had a bug which caused it to alert about system processes like explorer.exe trying to modify the registry.

SS 12 actually had a feature that auto-allowed trusted signers to make changes to the registry, but it was buggy. But now that I think of it, it would be nice if you allowed users to select which regkeys should be monitored. This way you could also minimize alerts.

1 Like

Very useful @RasheedHolland. I will share with our team, thanks!

Also, please note SpyShelter still does monitor the Registry. For example, drivers, service alerts, mic/cam detections, etc…

But we no longer offer SpyShelter users to modify their own specific Registry keys which it seems nobody seemed to need or use.

Due to feedback from everyone, we are considering adding a new feature to “System Integrity” that focuses on apps added to auto-start for Windows. Do you agree that would be useful?

No, you missed the point 100%.

Software can (and should) “use a lot of resources” to handle/solve involved, intricate processes.

The still-adequate 8 MB RAM retail-class PCs and laptops are falling by the wayside, 16 GB the baseline and 32, premium.

Even cheap-o CPUs rock, including the Pentium N6000 (10 nm litho!) in a $125 USD S-mode laptop I mentioned in passing.

The disk has been no-more for ages. Only benchmark software has a chance of effectively bogging down an SSD or eMMC.

The days of the Task Manager Guru discussions about “heavy” and “light” numbers under the I/O columns are long over and those who did engage in those dialogues rarely had any idea of what the metrics related to.

None of this is to say that folks who choose to or must run 10-15+ year-old systems won’t have to dial back or disable software settings.

OK I see, strange that this wasn’t mentioned before? So you guys already had a feature that allowed users to choose which regkeys should be monitored? Why would you get rid of that?

And yes, services and drivers are still monitored because that’s a separate module. But do you guys also monitor the Task Scheduler for example? In fact, can you perhaps give a list of regkeys that are monitored? I mean aren’t you already monitoring regkeys related to auto-start? :thinking:

I believe you may have missed my point. :slight_smile:

I meant that normally speaking, security tools like behavior blockers should not trigger a lot of CPU and disk activity and should also not use a lot of RAM. And that’s because they basically only need to come in action when certain behaviors/API’s are triggered.

So stuff like monitoring of process execution, network connections, service/driver loading and registry modification can all be done, without using many resources. Of course RAM usage can be high in case the GUI is a bit heavy.

1 Like