Slashdot Mirror


Macropayments: ISPs pay Content Providers for Access

EssJay writes: "A norwegian newssite (digitoday.no) has a story (norwegian) about a swedish company's filter-system which enable content-delivery sites to differentiate between different ISP's. This means that the ISP has to pay a fee to the site in order to enable the site's content to the ISP's users. Another story (also norwegian) discusses the implications of this. They report that the swedish company (Tric AB) will "act as a third party between ISP's and content-suppliers with the intent to let the content-suppliers get a share of the access-income. It will act as a clearinghouse where the income from the ISP's is distributed to different content-suppliers in relation to size and traffic". According to a swedish newssite (Ekonomi24.se), Tric has already gathered the largest content-suppliers in Sweden and they are already in discussions with the large ISP and telecoms in Sweden (Telia, Tele2 etc.) which are positive to this. The background for this initiative is the problem of financing the content on the Internet. So far it's all been advertising and subsidising from other parts of the companies, now it will be the up to the ISP and telecom-companies to share the income with other actors. This would also be the death of smaller ISP's that feed off the free structure of the net, given that this model is applied to the entire net. And not to forget the new business created: clearinghouses. We were just waiting for another level of complicity." Either your ISP pays a fee to the content provider (raising your access fees, of course), or the provider blocks access to itself from all of your ISP's users and you have to deal with their complaints. We'll probably see this in the U.S. soon, as the next stage in the media consolidation.

2 of 140 comments (clear)

  1. Re:I don't get it. by Jason+Earl · · Score: 5

    It'll never happen. People think that Linux has a chicken and egg problem getting access to commercial applications. Any system that charges ISPs for access to content has a much larger problem. They have to sign up content providers that have content that a significant amount of an ISPs customers are willing to pay for, and then they have to convince that content provider that it is a better idea to sign up with their service (and pay the requisite commission) than to simply charge the end user themselves.

    Fat chance of that happening.

    Especially since many of the content providers already are access providers. AOL/Time Warner stands out as the best example. They are already using their "special" content as a hook to lure customers. Many of the other "large" ISPs have the same business model. One of their hooks is special proprietary information or tools. There is literally no chance that they are going to pay dues so that their subscribers can view their competitors for-pay sites, as they would rather have their customers see their own commercial sites. And without AOL's customers, and the customers from the non-complying normal ISPs the service will be severely limited in its market.

    The fact of the matter is that once a product becomes a commodity, putting it back in the proprietary bag is nearly impossible. I am surprised this particular company isn't trying to charge for air and sunshine while they are at it.

    Currently ISPs are running on razor thing margins. They aren't going to pay access fees for their users. Web companies are going to have to find a way to charge their customers directly, or they are going to have to find a way to show advertisers that their advertisements actually work. Micropayments isn't going to work, and macropayments are even less likely to work.

  2. I built something like this years ago... by General_Corto · · Score: 5

    Back in the day (just before the AOL takeover), I was a contract employee for CompuServe Germany ('hi' to Robert Stabl, my boss!). CompuServe, at that time at least, was pushing a technology called RPA (Remote Passphrase Authentication) as a way to prove a user's identity to a third party website, without that third party needing to know anything about the user's passphrase (reasonably well designed too).

    CompuServe GmbH also used this RPA technology to control micropayments to some of its more interesting (to some) content. The example that comes to mind was a site called Recht Online, which was a pay-per-view listing of all court judgements in Germany (I believe). However, there were many other areas of content which CompuServe wanted to sell, and not just to their own subscribers.

    My job was to create an ISP authenticating proxy. The idea was that if you, as a user from ISP 'blinkenlichten,' wanted to view some pay-per-view CompuServe content, then you could as long as your ISP had a service agreement with CompuServe. It was the ISP's problem to figure out who viewed what, and how to pass the cost on to their customers.

    Perhaps the most magical thing of that whole time was going onsite to a couple of ISPs (one in Frankfurt, the other in Dusseldorf), and seeing the highly sceptical sysadmins' jaws drop when I started happily connecting to expensive CompuServe content through their IP range.

    Ironic part of the story: CompuServe lost the source code.