Slashdot Mirror
ISP Embarq Monitors User Traffic
Deli Korkmaz writes "The Washington Post reports that Sprint-Nextel spin-off Embarq, currently the US's fourth largest DSL provider, monitored Internet activity on some 26,000 customers in Kansas using deep-packet inspection technology NebuAd in order to deliver targeted advertising to users' desktops. CNet provides coverage as well. The House of Representatives Committee on Energy and Commerce is investigating whether any privacy laws were broken. Users were informed of this test and invited to opt out only via Embarq's online Privacy Policy; a mere 15 subscribers did so."
It is exactly like Phorm. They monitor your surfing habits to identify your likes and feed the info to a partner website that is displaying an ad based on your habits.
~ Ron Fitzgerald
Disclaimer: I am an Embarq employee.
It was used to better target the advertisements on MyEmbarq.com and on the DNS redirection pages for server not found. If there was any more past that, then the general work force was not aware of it. No modifying of pages or redirecting others' advertisements.
This system would only work if you used Embarq's DNS servers.
tom.gerke@embarq.com was the contact for the CEO back in March. I assume it is still legitimate...
Weird slashbug #455
That started long before Reagan.
Please be careful with the terminology.
Opt-out means that you're in and you have to opt-out to stop your membership/subscription/whatever.
Opt-in is what you want: it's your choice to subscribe/join/whatever, and if you don't, there is no membership/subscription/whatever.
For example: The do-not-call list is an opt-out scheme. Unless you take action and put your name on the list, they're allowed to call you. Most newsletters are opt-in: You only receive the newsletter if you subscribe. Spam is neither opt-in nor opt-out: You get spam without doing anything. If you try to opt-out, you get more spam.
... in my opinion, because not only do they *know* that not many people out there even read the terms of service (or Privacy policy for that matter), but on top of that they are compulsively "opting" everyone in.
To me, it looks like unilaterally changing the terms of a lease, after the fact, to allow me to go into your apartment an install cameras on every room.
I'd be switching providers right about... now.
You seem to be in favour of ISPs respecting their customer's privacy but then went on to mock an anonymous coward for opting to remain anonymous.
That doesn't make much sense to me.
Yes, you are wrong. Rogers Cable throttles encrypted traffic, but doesn't block it.
Opt-out should be replaced by opt-in, always!
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
HTTPS presents a significant load on servers. It can easily demand 3 times the hardware and support to transfer a large, busy set of servers to HTTPS for all traffic. If it *didn't* present a noticeable load, it would be fairly useful as a normal encryption channel.
It's also awkward to proxy and manage the encryption securely, because HTTPS is very careful about checking hostnames and IP addresses to avoid people forging your site. This makes it more awkard for usrs, as their browsers complain about untrusted keys or the server owners have to invest in registering keys.
IP addresses are not useful as global identifiers of services: (i) their scope of validity is limited in time (DHCP, renumbering); (ii) their scope of validity is topologically limited (NAT, anycast); (iii) they may be shared resources (NAT, multiple web servers sharing one address); (iv) a address:resource correspondence that is valid may insuficiently describe that resource's reachablitity (same service, multiple addresses).
These are not theoretical problems; this is all stuff that is in the Internet now, in sufficent quantity that they cannot be ignored (no matter whether one thinks they are "evil" or not) without breaking presently working client<>connectivity.
In modern DNS, the important RRs are SRVs and TXTs, not A RRs.
SRVs allow the resolution of a "handle" to a given service; they do not stack especially well, but they do decouple the service from the network layer address, and especially from the well-known (static) port mapping.
SRVs, like A RRs may be mutated along the way, since there is no guarantee that the address and port that the service thinks it has is a valid mapping far away, which also means that there is no guarantee that the client has the same idea as the server of what the server's address + port 2-tuple is.
TXTs can encode public key authenticators, service-access information, and so forth, which should not mutate along the path, since it is information useful to identify and use the service no matter where the service appears to be network topology wise.
A modern Wide Area Bonjour DNS zone is worth studying, particularly one that contains SASL keys (32hexdigits._apple-sasl._tcp.WAB.ZONE.NAME. TXT "f.q.d.n." is pretty commonplace, and one can look up the SRV for _apple-sasl._tcp.f.q.d.n. and the A RR for f.q.d.n. and when one connects, one does a crypto handshake using the 32hexdigits. NATs might munge the A RR and overloading closer to the server might munge the SRV RR, but that only relates to being able to initiate a connection to *something* that will either prove its identity or not).
There are a variety of approaches to encoding X.509 style information into TXT RRs too, with similar reasoning: decoupling the identity of the server from the address/port tuple resolved at the client.
Thus, while you are not "lost" with respect to the tree of auths, you are more likely to want to protect (via PK signing) the non-mutable information (service keys, TXT RRs)
A RRs and SRV RRs cannot be put "back" into the non-mutable category without breaking a substantial amount of existing connectivity. Moreover, keeping them mutable and ephemeral offers an ability to scale network connectivity in the event IPv6 fails to see wide deployment (no comment on the possibility that). The technology is also useful in the event IPv6 does see wide deployment, fully supplanting the IPv4 Internet, since renumbering, mobility, provider change, and so forth will continue to be operational problems.
An alternate approach would be to use a separate distributed identity database which one searches to find the binding between a server name (fqdn:servicename) and server credentials. This could use DNS software, it's just the servicename:identity mapping tree could benefit from having a different structure than the servicename:address mapping tree currently in the DNS.
The DNS would continue to primarily act as a distributed address database that one searches to find the binding between an FQDN and a locally useful handle (IP Address, and where SRV RRs are in use, transport layer protocol and port).
We already have several databases which find bindings between organizational identity and server name (google, for instance)...