Any slider "equivalent" in 2014 WSA?

For us WSA "veterans", are there any equivalent settings in the 2014 product to tweak security levels like we could in the previous product(s) using the slider controls?

Certainly not a priority, but inquiring minds want to know...

 

There's some tweaking but not like before and there are some new features like "Webroot Infrared" and the New Web Shield with BrightCloud with search Annotations now on HTTPS which is being rolled out slowly and it's awesome no little window at the top left but a large one in the middle and to get out you press the back button or another link no more closing the windows. https://www.wilderssecurity.com/showpost.php?p=2290537&postcount=164

Daniel

 

None I'm afraid.

 

I don't see those checkmarks next to my search results. Is this something that is going to be rolled out to us eventually?

 

Please see here https://www.wilderssecurity.com/showpost.php?p=2291210&postcount=160 and https://www.wilderssecurity.com/showpost.php?p=2291227&postcount=161

 

Cheers!

 

Yes you will get it as it is being rolled out slowly and when you see IE, FF or Chrome ask to install the Web filtering extension then you will have it!

Daniel

 

Speaking about browser extentions.

A question for Joe the magician.

I am not a fan of browser plugins or extentions. And I have always wondered why not more vendors use other ways than an browser extention or plugin for some features so the whole product will work with wich ever browser the user want/chose to use. And incorporates this function into the program instead. Or is that not possible, like with the new web filtering?

Just something I am trying to better understand and figure out since I don't see browser extentions or plugins in AV products as an advantage over having everything incorporated. Thank you

 

It's all about what has access to what. Browser Extensions are meant to be able to access things and affect things in the browser in a controlled manner that remains consistent regardless of patches and other things.

The best way to liken it:
You have an iPod and want to plug it in to get music out the bottom 30-pin port into a dock. Browser plug-in is like using the 30-pin port. Any other way is like opening the case of the iPod and trying to connect wires to the circuit board directly or do a scan of some kind to make it work. Obviously the port is made to work for that purpose, but connecting wires directly to the guts may break things and might not work on the next version of the iPod.

 

Well I have seen cases, where the plugin in an AV wich serves a purpose stopped working when a new browser version was released, because it became incompatible with the new browser. And then the vendor would need to update the plugin to make it work with the new version. This is just one example.

But my main point was that the whole product should work, regardless of wich browser the user/s use. And they rarely do because the extentions/plugins that some vendors use are only compatible with a few selected browsers.

I see your point, but that comparison was a bit extreme IMO. It's like you say that the browser extention is the only way, or any other way I would need open up my PC case to make the web filtering work. Or did I read it wrong?

 

More like "The browser plugin is the 'proper' way, otherwise the programmers need to 'open up the browser' so to speak to make the functionality work. Then each version of the browser, with or without patches, etc, can break the part they opened up to get to the guts of."

 

We surely disagree here that plugins is the proper or best way of doing things, and I don't think we understand each other to 100% in this question. I will wait to see what Joe has to say about it. Instead of starting a debate.


An example, Ad block plus is a browser plugin that you can use to block ads but it doesn't work in all browser.
And Ad Muncher is a program that also block ads, but it does it without the use of browser plugins since it work at network level (last I heard) so it is able to block ads in what ever browser you use.

I don't use any of them it's only an example.

And this part I have not heard about before "open up to get to the guts", please can explain more.

 

The browser plugin system exposes certain internal workings of the browser in a structured way. The plugin system allows plugins to work fully within the domain of the browser, feeds them information, and takes results and modifies browser actions based on the plugin requests.

Without using the plugins to get into the browser, certain parts are locked away unless you go directly into the low level functions of the browser, or in other terms, the guts.

For example, Ad Muncher works based on the network, that is correct. It says "I see a request to this IP, so I will block it." It cannot, however, see HOW the request is occurring, nor can it see requests in, for example, SSL channels. So if a javascript that comes across an HTTPS connection on the exact same IP as the main page demands that the ad be loaded otherwise it hides the whole page, Ad Muncher will fail miserably. It cannot see the Javascript inside the secure stream and so it can either blindly block the advert from the IP, resulting in a dead page, or it can allow the ad and allow the page to work. It cannot block the javascript that does this itself because it has no way of knowing whether a given HTTPS request is for that Javascript or for the normal parts of the page.

In order to see what is going on inside the browser window with a Plugin, the plugin registers "On pre-load start", so when the browser starts to load the page, before it starts it sends the signal to the plugin along with the details of what it intends to load. This happens even with secure connections (which is why plugins are critical to protect properly). The plugin says "Oh, no, don't load that, and I see the code section that tries to load it, so I will hide that element."

In order to see the same thing without a plugin, the program needs to open and constantly pay attention to memory locations inside the browser, or load a DLL to try to hook functions in the browser itself that may not remain constant even across minor patches. When it sees the memory location change or the hooked function is called, the process that hooked or watched needs to make a decision and take action.

To make a different comparison:
The program doing it via plugins is like a robot plugging headphones into your phone. Yes, sometimes phones have different "plug systems", like the difference between browsers, but when you use the plug they offer, you know the microphone will pick up your voice and the speaker will make sound.

The program doing it via other methods is like the robot being given a bunch of bare wires and having to connect it to the phone somehow to make the microphone and speaker work. Since it doesn't have a pre-formed plug, it has to find a way to connect the bare wires directly to the electronic components of the phone that handles the audio. That's where the idea of the program ("robot") having to open up the guts of the system and poke at them comes from.

Programming as a Plugin:
Here's headphones with a plug. Make it so the user can listen to music.

Programming without using plugins:
Here's headphones with three bare wires hanging off it. Do the same thing.

 

The new web filtering uses browser addons to give the best possible experience when blocking websites. This is an issue we've had for many years, in that, when a website is blocked, it either doesn't render properly or isn't in the front of the window, etc. The only solution is to work within the browser.

However, for an additional layer of security in the event that a browser addon is incompatible, is disabled, etc. we're going to be pushing out an additional layer of protection which runs in kernelmode. This will duplicate the core functionality of the browser plugins so it will work in unsupported browsers as well as supported ones, but we prefer the addon based approach as it allows for more customization of the end content and better interaction with the browser itself.

 

Nice, thanks for mentioning that. That's really useful info to know for everyone using other browsers than the officialy supported ones.

Yeah I know what you mean, I saw that a couple of times when I tested an early verion of WSA.

 

Yes I know that it doesn't work well over secure connections, yet. But I put a high value on that I can chose what browser I want to use, over that a few ads slip by the few cases when I go into a website under a secure connection. And I would be forced to use a supported browser to even get it to work on http connections if it would use plugins.

I don't know if it is possible, but if a plugin is the only way to solve https issue.
Why not make a plugin for 3-4 supported browser, wich will work under https connection. But also use the current way at network level so it will work in all browser except that it wont work as good under https connection. That way it will work great in all browsers 99% of the time, except while under https in an unsupported browser where the plugin won't work.

Meaning that if I would start to use it, it would work great in my unsupported browser, except when I would use an https connection. And those that use one of the 4-5 supported browser it will work in both cases.

Yeah like that wasn't obvious.

A plugin may be essential if you want the ad block function to work under both http and https.

But the plugin is not essential if you want it to work in all browsers under a normal http connection. Like it does today.

Or i'm I wrong here too I just want to get this sorted out