Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SGN Product Enhancement Suggestions

Might be a good idea to star this list early so it's in early. My wishlist

- Better AD synchronization (automated, configurable schedule, and built into MC)

- "Policy for a slider" - meaning give user the option via policy to control how fast they want to encrypt the HD. Of course if this policy is disable user cannot control that (aka today's status). Giving the users a little power will simplify the deployment of such invasive product

- Better policy stamping on the client. Today you can see "Last Received" but that's misleading as policy might not have been changed for long before that. I would rather see a hashmark or some kind of name where I could match the server policy name with the client (the date should be in the name)

:145


This thread was automatically locked due to age.
Parents

  • Thomas wrote:

    - Better policy stamping on the client. Today you can see "Last Received" but that's misleading as policy might not have been changed for long before that. I would rather see a hashmark or some kind of name where I could match the server policy name with the client (the date should be in the name)

    We hear this suggestion for the first time.


    I mulled over this for a while and while not (yet) being a SafeGuard customer I think it expresses a more general problem: "If I'm not in control then at least I want to be informed" - and a usual answer is (no offence meant, Thomas) "this is too complex to understand (for you)".

    A simple example: the ABS in your car. Of course you want to know if it works - that is, you want to be sure it will work when you need it. But how can you be sure? If it's telling you with a green light that it will - can you trust it? So the arrangement is, it will tell you with a red light in advance that it definitely wont work - otherwise assume it will. Still ...

    Or take the SAV icon: it has the white-on-red x when the update has failed. Otherwise it's telling you when it has last successfully searched for updates. I've heard from several people that this is not satisfactory: it should also tell you the last time it has received an update. Whereupon I say: and what might this tell you? It always turns out that the underlying fear is that the client is not protected from the very latest threat.

    Of course all the arguments are to a certain extent valid - nevertheless they are rationalisations. What do you, vojta, or your users want to find out? Whether the client has the correct policies applied? Or whether "something" has changed recently or not? Do you have an example where this would really be needed?

    Changing sides: vojta said "will simplify the deployment of such invasive product".  Perception and acceptance by the (end-)user are not unimportant (at least for some of us "intermediaries" - and "This is how Sophos is doing it"  is not an answer you want to give all the time). It's hard to know what exactly is needed - and even harder to explain and it might not make sense from an engineering point of view. Take the "slider": it would be a solution to an imaginary (unless two processes are "competing! for the idle cycles) problem - nevertheless it could also solve the real problem. Of course the "slider" wont help if CPU monitors still show near 100% usage ... Sometimes it's more psychology than technology

    Christian

    :645
Reply

  • Thomas wrote:

    - Better policy stamping on the client. Today you can see "Last Received" but that's misleading as policy might not have been changed for long before that. I would rather see a hashmark or some kind of name where I could match the server policy name with the client (the date should be in the name)

    We hear this suggestion for the first time.


    I mulled over this for a while and while not (yet) being a SafeGuard customer I think it expresses a more general problem: "If I'm not in control then at least I want to be informed" - and a usual answer is (no offence meant, Thomas) "this is too complex to understand (for you)".

    A simple example: the ABS in your car. Of course you want to know if it works - that is, you want to be sure it will work when you need it. But how can you be sure? If it's telling you with a green light that it will - can you trust it? So the arrangement is, it will tell you with a red light in advance that it definitely wont work - otherwise assume it will. Still ...

    Or take the SAV icon: it has the white-on-red x when the update has failed. Otherwise it's telling you when it has last successfully searched for updates. I've heard from several people that this is not satisfactory: it should also tell you the last time it has received an update. Whereupon I say: and what might this tell you? It always turns out that the underlying fear is that the client is not protected from the very latest threat.

    Of course all the arguments are to a certain extent valid - nevertheless they are rationalisations. What do you, vojta, or your users want to find out? Whether the client has the correct policies applied? Or whether "something" has changed recently or not? Do you have an example where this would really be needed?

    Changing sides: vojta said "will simplify the deployment of such invasive product".  Perception and acceptance by the (end-)user are not unimportant (at least for some of us "intermediaries" - and "This is how Sophos is doing it"  is not an answer you want to give all the time). It's hard to know what exactly is needed - and even harder to explain and it might not make sense from an engineering point of view. Take the "slider": it would be a solution to an imaginary (unless two processes are "competing! for the idle cycles) problem - nevertheless it could also solve the real problem. Of course the "slider" wont help if CPU monitors still show near 100% usage ... Sometimes it's more psychology than technology

    Christian

    :645
Children
No Data