I'm going to have to think about that for a bit, it's a tricky enough situation you sketch that there shouldn't be some kind of exception for it.
First thing to come to mind is maybe an electronic way of securing permission from the 'endpoint' of the traffic, since they benefit from not having their hardware and their connection abused as well.
The key is 'with the consent of the customer', and I think that such instances should be the exception rather than the rule.
So if there is no specific reason why a certain customers packets are inspected and it is done without their knowledge and consent it should be illegal.
Also, it may very well be possible to correlate enough transport layer data to figure out which packets are part of an attack and which are legit, but that might be computationally very expensive to do.
well, I'm actually /really interested/ in what people think about this. I mean, laws aside, privacy policies[1] are pretty important to some people. But the thing is, by looking at (and sometimes mucking with) your traffic, I can provide you a better service. So it's important for me to know where the line is for different people.
I think you've already nailed it, the 'better service' is the key element in that sentence. If the endpoint finds their services degraded to give other people better service then I think most people would balk. If it is to give them better service they'll be fine with it. Whether or not they read the privacy policy is another matter, I think I must be the only person that actually reads those things.
as for privacy policies, what I'd really like is to use a privacy policy published by a trusted body such as the EFF.
In my perfect world, the EFF would publish several, modeled after the 'creative commons' licenses; each policy would grant different levels or different kinds of privacy, and the meaning of the policy would be fairly well understood by all parties just by stating the name of the policy.
edit: I don't mean /legally mandating/ these privacy policies... I'm suggesting something like the system in place for managing copyright (or,uh, left) - the idea would be that if there are standard policies, you won't have to read each policy all the way through for every service.
Something totally independent of both business and government run as a non-profit that reviews the various privacy policies, notices changes (by spidering them periodically) and alerts users to those changes and their consequences?
You could also issue a 'badge' or a widget that you could include on your privacy policy page that gets served up from the reviewing institution.
Even ignoring the cost in lawyer time to draw up and review the policies, knowing that a policy is 'reviewed by X' tells the user less than "ISP Y uses standard policy Z"
Also, just like there are different creative commons licenses that grant different rights, it's reasonable to have different privacy policies that grant different rights... and if you need a particular right, it's much easier to go "Oh, isp X uses policy Y which gives me what I want" than to go reading the custom policy that each ISP drew up.
Ah ok, sorry, I see what you're saying now, just in an ISP context, I thought you meant privacy policies as a whole. Apologies.
In that case it makes perfect sense. I thought about all privacy policies and because there are so many different products out there it would be very hard to have a limited set of policies. But for the ISP subset that could definitely be done.
Well, the infrastructure provider market is what I know and care about... but I don't think the privacy needs of, say, facebook users and twitter users are all that different. they could probably use the same privacy policy with no changes.
by looking at (and sometimes mucking with) your traffic, I can provide you a better service.
That's admirable, but I notice you're a hosting provider. I've never heard of a broadband ISP that wants to use IDS or DPI to provide better service; they only seem to talk about providing worse service.
Perhaps making such things opt-in would work; if the customer believes that it really benefits them, they won't mind opting in.
well, the IDS would be primarily to protect the rest of the internet by noticing when your box becomes a zombie (and decrease costs associated with handling abuse.)
Unless you are one of those people who expects me to leave your box online after it has become compromised and is spewing abuse, the ids, assuming I use it how I say I'm using it to just detect compromised hosts, and assuming I'm careful about false positives, won't hurt you.
Mucking with the traffic is /much/ more difficult to do without damaging the service. However, there are many cases where if you muck with the traffic you can allow high latency high bandwidth bulk transfers without messing up your low-latency traffic as much as it would otherwise... e.g. it's possible, with traffic shaping to maintain better customer experiences while overselling your pipe.
this positive is realized by the customer through lower prices in markets with competition. obviously, the home broadband market is not one of those markets, so I don't know how much difference it'd make there.
If you notice, I'm a provider in the server space, where there is a lot of competition.
As one of your customers, I wouldn't mind you looking at my traffic, assuming that you notified me of it afterward and that you didn't store anything that could be used to establish patterns that could be traced to me individually or the actual data I was sending (it is liable to include, among other things, passwords).
However I would expect you to get a notification before you started to murk around with my traffic, since it is liable to interfere with my use of the services that I have paid for.
first, please, please don't send passwords unencrypted. I'm not the only one who can look at your traffic. Spoofing a route in bgp is, to my understanding, not a difficult thing to do, which means that really, anyone on the net with a sufficiently well-connected BGP box can sniff your traffic.
but yeah... would just giving you access to all the information I had about your traffic be sufficient notification? That seems like the best way to handle it to me, I mean, if I've got a IDS all setup, it's no more work for me to let you see the results, and especially on incoming traffic, that has value to you.
>However I would expect you to get a notification before you started to murk around with my traffic, since it is liable to interfere with my use of the services that I have paid for.
Yeah. mucking about with people's traffic is tricky, and /certainly/ deserves a notification. Right now, the only time I do it is when you go over your transfer limits; in that case I use tc to bump you down to something that can't hurt me, and obviously, I tell you.
If I /wanted/ to provide a bulk transfer service, rather than limiting the overage accounts to 1mbps or less each, I'd take accounts that are in overage and let them have as much bandwidth as they want, just making that bandwidth a lower priority than the bandwidth of my paying customers.
Now, my experience with that kind of traffic shaping is that it's never perfect, you always interfere at least a little with the high priority traffic; or at least that's been the case every time I've tried doing that, so I don't. But, I've heard of others doing it with varying degrees of success; it's one of those things that can possibly make a cheaper service better if you allow the provider to muck with your packets.
It is true that I shouldn't send passwords unencrypted, but the passwords I send are not those I am concerned some government agency gets their hands on, nor are they useful for industrial espionage.
I am simply trying to avoid having the passwords ending up in some log file somewhere where a second-rate cracker can get access to them and spam my webpages. Honestly if you have the power to fix the Border gateway protocol, chances are that you are not interested in spamming my redmine installation.
I'm going to have to think about that for a bit, it's a tricky enough situation you sketch that there shouldn't be some kind of exception for it.
First thing to come to mind is maybe an electronic way of securing permission from the 'endpoint' of the traffic, since they benefit from not having their hardware and their connection abused as well.
The key is 'with the consent of the customer', and I think that such instances should be the exception rather than the rule.
So if there is no specific reason why a certain customers packets are inspected and it is done without their knowledge and consent it should be illegal.
Also, it may very well be possible to correlate enough transport layer data to figure out which packets are part of an attack and which are legit, but that might be computationally very expensive to do.