Your business shouldn't care if the user is running a server or just a client. You should be charging based on transit alone. Sure servers use more outbound transit and clients use more inbound transit. But you're free to price inbound and outbound traffic differently if they have different costs. The Internet wasn't built around the idea that some machines would have some special attribute that allowed them to serve traffic and everyone else was just a client. Any attempt to apply that to the Internet will ultimately fail. ISPs have been able to get away with this thinking because most of the popular protocols were client/server. Welcome to the 21st century. There are legitimate reasons to operate distributed services. For instance it makes sense to have voice chat applications that don't use a central server.

As far as P2P for YouTube. I don't think you know what you're talking about. The only thing I can find about P2P with YouTube is some Singapore company that tried to enable that and Google didn't like it. Given that Google is pushing for browser standards that don't require Flash at all you'd think they'd also be pushing for these standards to include P2P components. But as far as I can tell they aren't doing that either. Flash does support a P2P feature called RTMFP (Real Time Media Flow Protocol) which is primarily made for collaboration applications. As far as I can tell Google isn't using this even for things like Google Hangouts. If you have some proof otherwise I'd sure like to see the source.

Where did I give the impression that content providers aren't paying for bandwidth?

The way this should be working is that end users and content providers buy bandwidth from their ISPs and then the ISPs negotiate contracts over how to peer. If peering arrangements are titled towards one side or the other then maybe one side will end up paying for the peering. However, in many cases the peerage is mutually beneficial and they simply share the costs in supporting the peerage.

Hosted for free? No. Your user is paying you for the transit in both directions.

If your users aren't aware of how much bandwidth they are using perhaps you as an ISP should so something to educate them.

Quite frankly, if ISPs want to limit bandwidth usage then they should be required to show the bandwidth usage that has been used and should be required to provide exact limits as to what customers are provided. This shouldn't be any different than how cell phone companies have to show minutes used.

Instead they've been getting away with marketing burst speeds and creating the appearance of unlimited bandwidth usage (when in reality most of the big ones will start threatening to turn you off if you're using too much).

You keep brining up Google. What service does Google have that turns a users system into a server in order to access the service?

In my particular case I know exactly how much bandwidth I'm using. I actually have Cacti graphs. The only major thing that I can think of that I use that turns my system into a server without being obvious is the downloader for some game updates that uses bittorrent. As an ISP I'd think you'd be thrilled because these clients typically prefer to talk to IPs that are in the same blocks and often save a lot of transit across your peers.

I can't fathom what you mean by content providers wasting bandwidth.

I pay for a pipe, I expect to be able to send and receive packets to whomever I want. It's up to me as the user to decide if I'm wasting bandwidth. If I don't want to pay as much and save money then I should consider how to use less bandwidth.

The problem is that ISPs have been getting away with overprovisioning, underdelivering on bandwidth promises and pocketing the massive profits. If you can't make money with people using the bandwidth you sold them then perhaps you should price your product accordingly. If you're selling burst speeds and not explaining to customers your limits then it's your own fault.

There's two basic responses to this.

1) If there are competitors but their service isn't as good by switching you're helping put more resources in the hands of those competitors. Yes you might have to make some compromises in the short term but if enough other people do the same the competitor will be able to spend the money to provide the same service that Verizon is.

2) You may be able to gain herd immunity. Other areas do have competition. The areas with viable competition typically have it because they are very profitable. If people leave a carrier in areas where they are very profitable but the people without alternatives stay it hurts their profit margins. The misbehaving carrier is left with low profit of possibly even customers they lose money serving.

Seems like there's a simple solution. Verizon's only choice is to try and degrade service for sites that don't pay. If all sites refuse to pay then customers will complain about the degraded service and possibly choose other ISPs. Customers that want to prevent this sort of behavior can simply refuse to visit or given business to sites that do work these sorts of deals. Thus discouraging both sides from doing this. Vote with your wallets people.

Those aren't iPhone model numbers. Those are Export Commodity Classification Control Numbers, which is how the government refers to categories of products. See http://www.bis.doc.gov/encryption/nlr.htm The poster above you is saying that the iPhone falls into a category that does not require an export license. However, not all encryption technology falls into that category.

Microsoft has included AutoUpdate in Office for years. Every few months when they put out an update it pops up and downloads it for me. You can get to it by going to the Help menu and choosing Check for Updates in any Office Application if for some reason you want to run it manually. Maybe they could do a better job, but I think your statement that there is no easy way to notify users is fundamentally false.

There's just an option in the Security menu to turn it on. Recall the documentation saying it takes 3 hours to turn it on. You also have to have a pin setup to unlock the phone. I haven't tried it myself.

Galaxy Nexus has full device encryption now since it's been added to ICS. Unless telcos or OEMs remove it should be available in future ICS phones.

I know this because Apple has announced as much. Look at any of the multiple tech news sites putting up comparisons of the services.

http://www.pcmag.com/article2/0,2817,2386491,00.asp

There was a better one on one of the other sites that I can't seem to find.

Finally, there are indeed people already using iCloud as you can see evidence of here:

http://www.macrumors.com/2011/06/20/if-you-use-all-your-icloud-storage-apple-sends-you-this-email/

Pretty sure you can listen (maybe someone can confirm). I know there is no Linux upload client which makes your comment a fair point.

I don't think Google and Amazon missed the boat here at all. I'd say that Apple missed the boat.

Google and Amazon's services allow streaming. Apple's doesn't. Apple's service is just a sync. A sync that avoids the upload and requires the download.

I can't access my music collection from my work computer without downloading it there. In fact my music collection becomes only available on iPhones/iPods and through iTunes. Amazon will end up being almost entirely platform neutral because they have no dog in the platform game. Google will likely try to support the IOS platform, assuming Apple lets them. I'll admit Google's support will probably lag behind the Android support and not be as good for IOS.

How much you wanna bet me that Apple never puts anything out for Android or any other mobile platform?

Apple's entire strategy here is to extend their lock in while fixing one of the annoyances of multi-device usage with iTunes. If they succeed we all lose.

For some reason your username sounds familiar. Wonder why?

There is a simple explanation why major sites are not supporting RFC 5746. A lot of these sites are probably sitting behind F5 hardware. The SSL is probably implemented just on the F5. F5 hasn't implemented the RFC in any version of their software yet.

http://support.f5.com/kb/en-us/solutions/public/10000/700/sol10737.html

Smaller sites of course are probably just a single http server running Apache. They or their hosting provide update their OpenSSL and Apache httpd versions. So the smaller sites get fixed. Major sites do not.

It'd be interesting to determine how many of these sites on his list are behind F5 hardware. I'm guessing that other load balancing vendors have similar problems, but F5 is the 800 lb gorilla.

The Opera article: http://my.opera.com/securitygroup/blog/2011/05/19/renego-popular-unpatched-and-vulnerable-sites seems to make a mention of this by saying that a major vendor will release an RFC implementation in June. But they don't say who this is and I'm not sure if they're talking about F5 or not.