4 ms·
I see too many problems with this idea. (1) App makers that transmit data already pay for their web services' bandwidth. So they are basically getting double c
by jkeel 15y ago
I see too many problems with this idea.
(1) App makers that transmit data already pay for their web services' bandwidth. So they are basically getting double charged for the same data.
(2) If app makers transmit data to other open services (Twitter API, Facebook API, YouTube API, etc.) then does the app maker pay for the subscriber's data use or does the API provider? Looks like a lot of room for confusion.
(3) It shields the true cost of the subscriber's usage in much the same way I see company paid health care shielding employees from the true cost of health care. I would imagine this would result in AT&T raising their fees more and more against the app makers without subscriber's being aware and taking the blame on any increase in the cost of the app on the app maker rather than AT&T.
- wmf 15y agoGiven metered pricing, it's not really double-charging. Today the server pays for the packets to travel half way and the customer pays for them to travel the rest of the way. If the app pays for both halves then (in theory) the total charge is the same; it's just being paid by a different party. I doubt that AT&T would charge an app the same ridiculous overage fees they charge customers, though. Regardless, the market distortion caused by the cost-shifting is real and problematic.
- runako 15y ago> If the app pays for both halves then (in theory) the total charge is the same It sounds like you're assuming the carrier (AT&T) would stop charging the consumer for the bandwidth as well. As in AT&T would offer a data plan without a data fee. I'd wage that AT&T's gambit is to get paid twice for the same carriage, and not what you have in mind.
- wmf 15y ago"A feature that we're hoping to have out sometime next year is the equivalent of 800 numbers that would say, if you take this app, this app will come without any network usage."