said by funchords:Sounds good, Nirmal & Jason. I'm doubtful but a Denver trial sounds like a way to find out for sure. I think the problem will be with user behavior, but maybe I'm jaded by my friend who turns off his AV everytime he tries to install software or play games because he believes it gets in the way.
My recommendation will be to make a panel out of people who were in a state to get the notice and learn:
1. Did they notice it and how long did it take?
2. Did they respond to it and when, how?
3. Did any applications fail to work?
It's important that you don't rely on Customer Support complaints. My expectation is that these folks won't call.
We have to compare these answers against the reality that these bots are not only harming the network but scamming folks. (I do know you guys intercept that junk from compromised hosts and assume you still will.)
This is a technicality in your FAQ above: How is DPI not involved in getting the proxy inserted in the flow? How are you getting HTTP traffic to pass through a proxy without DPI? (I did read Jason's 6A but I don't understand how DiffServ does anything with TCP port 80, that doesn't sound like DiffServ, that sounds like packet inspection, perhaps what some call Shallow Packet Inspection, but then you need DPI to do some forgery and redirection, right?.) If it turns out that it is technically DPI that makes this work, I think it's probably something okay since the alternative is a 100% walled-garden block and this clearly is a network management activity.
We definitely did do a focus group study to understand user behavior and the feedback was positive. The system worked as expected when we tested it with the group as well as during our internal beta testing. The technical trial will provide further insight into how users behave and react to the notice. If we do get customer calls we are ready to help them as needed via our Customer Security Assurance team. So it will be a learning process.
