[cap-talk] Capability accounting

[Norman Hardy]

On Jun 25, 2006, at 5:15 PM, Sandro Magi wrote:

> Norman Hardy wrote:
>> I agree with all your points. Agents for some situations are easy
>> however.
>> I can instruct an agent in my browser to pay up to 1 cent for any
>> link that I explicitly click on but 10 cents for any NY Times page I
>> select.
>> Other demands by web servers will require my explicit attention.
>
> I think the problem, is that metered resources like water and
> electricity have:
>
> 1. sufficiently course-grained controls, power switches and  
> faucets, so
> the user can mentally track/estimate how much these resources were
> actually used (should he so choose).
>
> 2. sufficiently stable, or at least slowly-varying, prices (so there's
> no shocking "surprise" after the fact).
>
> 3. sufficient confidence in the metering equipment (such that they  
> would
> rarely dispute the results).
>
> Software is clearly lacking in #3, but since we're dealing with  
> "ideal",
> capability-based software, we'll assume this is handled to our
> satisfaction. :-)
>
> #2 is problematic, as 10c links on one site could 20c links, or $100
> links elsewhere. This price variability must be explicitly  
> programmed or
> configured each time, should you decide for "metered" user  
> interaction.
> Managing all this information strikes me as quite a burden, though I'm
> open to suggestions.

In my NY Times example the agent in my browser responds to payment
solicitations from the web site that arrive before the content arrives.
Upon a solicitation for $100 it merely declines and gives you an
error like one of the many error outcomes that http requires may now  
produce.
There is no disputed payment because there is no payment!
It is like the fraud of putting a magazine on a newsstand with a  
sticker price of
$100. You are protected from this fraud by not proffering the $100.
It the author wants and deserves $100, use a credit card, not DSR.
The only variability suffered in this case by the user or his agent  
agent
is that some sites ask for more than the limit established by the user
some months ago.
>
> #1 is a real problem with today's software. AJAX architectures
> (potentially) don't fit into the web model you presented. If the  
> browser
> is loading data incrementally or dynamically, or in such a fashion  
> that
> the user is not aware of the background data transfers, he can be
> charged in ways he's not aware of. This interaction is sufficiently
> complicated that I can't see it being automated via agents with any
> degree of confidence.

> But perhaps I've misunderstood your user interaction model.

I had not spelled it out clearly. A browser (user) agent would
impose the preset limit of payments once per user interaction.
The total payments resulting in multiple internal AJAX transactions
would so limited.

> Sandro
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk