Librenix
Headlines | Linux | Apps | Coding | BSD | Admin | News
Information for Linux System Administration 

Proposal: A Web Bug-based Micropayment Model

Up
vote
Down

The problem
The trouble with paying for web content suffers from the inherent nature of web interaction. The fundamental problems with paying for online content are these:
  • Very small payments are economically infeasible because the transaction costs for a payment are far too high with existing payment methods.
  • The Internet is a huge resource where literally millions of disconnected individuals own the content and hundreds of millions of others use that content.
  • The fast-moving and anonymous nature of surfing doesn't lend itself to creating an account at every site you deem worthy of a mere micropayment, even if small payments were economical.

The first constraint makes pay-as-you-go prohibitively expensive. The second prevents subscriptions from being a viable solution for websurfers who are likely to visit hundreds or thousands of websites in a year, and worse, don't know which websites they will be visiting tomorrow. And, of course, the third makes it too inconvenient even if transaction costs were lower and you knew which sites you were likely to go to.

Note that a single website can charge a subscription by the month or the year in order to spread the transaction cost of the payment over a large number of uses. Unfortunately, that solution only works for large websites with very specific and compelling content that are used repeatedly by mostly the same users. Obviously, subscriptions solve the problem for only a tiny fraction of websites and an even tinier fraction of web users.

Look to the dark side
What I propose is a system based on the (previously) unmitigated evil known as the web bug. A web bug1 is a tiny, typically 1 pixel by 1 pixel, stealth image embedded in a web page.

The way the web bug-based micropayment system would work is simple. The three parties to a transaction would be:

  • Participating websites
  • A micropayment clearing house
  • Participating web surfers

The roles of those three types of participants are as follows:

A web user purchases a web surfer account at the micropayment clearing house and funds it with, for example, $20. The web surfer can now log into the account from any computer and be issued a funded surfing cookie.

A website owner opens a website account with the clearing house. The website owner receives account information and instructions from the clearing house. The webmaster updates the website with code to display the web bug on the priced documents. In that code is embedded information containing that website's account number. For example, each website could be given a different URL for the image file at the clearing house's web bug server in order to identify the website associated with a request.

The web user tries to access priced content at a participating website. At that point the user is prompted to authorize micropayments to that website. The surfer authorizes the payments and surfs into the priced area of the website. There, each page contains a web bug which causes the user to fetch the invisible image from the clearing house. The web bug causes a counter to be incremented in the web surfer's account and another counter to be incremented in the website's account. The web bug could also be used to have the clearing house send a small confirmation message to the website with an IP address and a referring URL to authenticate the web surfer as a micropayment member with surfing funds available.

Since the user has a cookie from the clearing house and the web bug code identifies the website, the clearing house has all of the information necessary to move a cent -- or ten -- from the user's account into the website account. The clearing house, of course, takes a piece of the micropayment -- the house cut. It'll be a small slice, naturally, but perhaps they can make up for that in volume.

Advantages
This system would have tiny overhead for each micropayment. The web bug plus the code and cookies could be as small as a few hundred bytes, perhaps less than 1 percent of the size of the typical web page. All of the actual micropayment would be automated, lowering the overhead cost for the micropayment to a properly micro amount. My guess based only on the costs of online advertising is that payments under a cent would be viable with this method.

The clearing house gets to validate the web surfing action independently from the website. The web surfer gets to authorize payment for each website used. The website owner would be able to allow anyone with an account access to priced pages without requiring a subscription.

This micropayment model could be used to implement a 'tip jar' or a 'cover charge page' where a user simply clicks to make a donation or to gain access to other content for a flat fee. In the second case, the user clicks the 'cover' page, the micropayment is made, and a 'membership' cookie is issued that might last a day, a week, or a month, depending on the contribution level. I think the 'cover charge' method is the most viable of the options covered so far. Users might not be comfortable with surfing where each page could cost a penny. However, it may be less stressful to click a page for a flat fee, then surf without additional charges until the cookie runs out.

Ideally, a web surfer account would be configurable to cause a confirmation for either:

  • All payments, or
  • Payments above a specified threshold
For example, one might choose to not be asked for charges of one cent or less, to be asked for authorization for charges between one cent and one dollar, and to have the clearing house automatically refuse any page priced above a dollar.2

Disadvantages
This might not be possible with static websites. I haven't thought about ways of getting around the dynamic requirement of verifying that a surfer has a funded account on-the-fly.

The system would either require a flat fee per page or a new authorization page to be acknowleged by the surfer if a page on a single website had a price different from the last acknowleged one. I think that would be necessary in order to overcome any uncertainty about how much a surfer was spending. (Note that this doesn't apply to the 'cover charge page' fee method.)

The Chicken-and-egg problem. Without surfers using the system, websites won't create accounts. Without enough websites with accounts, people won't open and fund surfing accounts. In practice, it may be possible to get around this problem. A few websites with very compelling content and currently surviving on a subscription model, might form, along with their users, the initial body of content and population of micropaying surfers. More likely, however, those sites won't change what already works. Instead, marginal websites -- those almost compelling enough to survive on a subscription model -- just might form a large enough group collectively to jumpstart this system.

Obviously, an exact protocol would have to be worked out. The core of this proposal is the simply the idea of using a web bug carrying some encoded data for third-party verification and accounting -- an extremely low-cost method of accruing many tiny transactions across multiple websites into a single charge. That charge would have normal transaction costs and might only happen once per month per account.

-Ray Yeargin


Footnotes
(1) In this system the term 'web bug' is a slight misnomer since the use of the hidden tracking image would be well known to all participants. Of couse, there isn't an actual requirement that the web bug be hidden -- it might be best for the web bug to be a small logo for the micropayment system and visible on all priced (or cover charge) pages. That is, the practical matter of identifying all priced pages explicitly might override any aesthetic desire to use a hidden image.

(2) If a visible web bug is used, it might display an admission price, a price per page, or even an accumulated price for the current session.

mail this link | score:7815 | -Ray, January 13, 2003 (Updated: March 19, 2009)
More Sysadmin articles...

Large Canvas Abstract Art Prints

admin headlines

Testing the Digital Ocean $5 Cloud Servers with an MMORPG

USB Redirection hack on Two Node Controller+Compute Neutron GRE+OVS Fedora 20 Cluster

Setup Dashboard and VNC console on Two Node Controller+Compute Neutron GRE+OVS+Gluster Fedora 20 Cluster

Using ngx_pagespeed With nginx On Debian Jessie/testing

Running ownCloud 5.0 On Nginx (LEMP) On Debian Wheezy

Step By Step Ubuntu 13.04 (Raring Ringtail) LAMP Server Setup

Running ProcessWire on Nginx (Debian 7 / Ubuntu 13.04)

Tutorial: Running CS-Cart on Nginx on Debian 7/Ubuntu 13.04

Setup a chroot environment on Ubuntu with debootstrap

Tutorial: Fedora 19 Samba server with tdbsam

Setup Nginx + php-FPM + apc + MariaDB on Debian: The perfect LEMP server

Tutorial: Install Lighttpd, PHP5, PHP-FPM, MySQL on Fedora 19

Setting up KeePass for Centos 6

Tutorial: Install Nginx, PHP5, PHP-FPM, MySQL on Fedora 19

Network Attached Storage (NAS) distributions

VirtualBox Headless Administration

Pentesting, digital forensics, and hacking distributions

Install and use OpenVZ on Ubuntu 13.04

Tutorial: Installing Lighttpd, PHP5, PHP-FPM, MySQL on Debian 7

Virtual Users/Domains with Postfix/Courier/MySQL/SquirrelMail (Debian 7)

Tutorial: Headless VirtualBox 4.2 and phpvirtualbox on Ubuntu 12.04

Tutorial: Install Nginx, PHP5, MySQL on Ubuntu 13.04

Tutorial: Installing Apache2, PHP5, MySQL on Ubuntu 13.04

Installing The Galera-Iworx Cluster

Add WiKID Two-Factor Authentication to OpenVPN Community On Ubuntu 13.04

High Performance Linux Router with LMS Web Panel and Radius Server

Multiarch: Use 32bit Packages on 64bit Debian 7

Tutorial: Use PHP 4.4.9 (FastCGI) with Apache (Debian 7)

Back up Route53 To S3

Using OpenVZ on Debian 7 (AMD64)

 

Firefox sidebar

Site map

Site info

News feed

Features

Login
(to post)

Search

 
Articles are owned by their authors.   © 2000-2012 Ray Yeargin