[E-Lang] My financial data

Norman Hardy norm@cap-lore.com
Sun, 28 Jan 2001 16:27:19 -0800


At 3:15 AM -0500 1/28/01, Vijay Saraswat wrote:
.....
>
>Here is a news paper account I just came across.. amazingly, on
>yodlee.com:
>
>http://www.washingtonpost.com/wp-dyn/articles/A4911-2000Sep23.html
>
>So:
>
>How would one design a system (hardware, software) that could let me, a
>user, collect my financial data from various feeds on the net, pull
>together my composite financial picture...hosted on some ASP (or
>portal)site on the net (so I can connect to it from anywhere on the net,
>and from any wireless device)... but in a way that i was guaranteed that
>no one else could see that picture except me, or those who I had
>explicitly delegated the ability to?
>
>more practically, how might yahoo be able to convince me, a sceptical
>reporter (let us say), that their life history is safe with me ...
>without governmental laws etc having to be brought into play...more
>carefully, how would they have to design their system so that they could
>convince me?

Here is my vision of such a service. In the description below the 
first person, "I", is the one whose data is to be protected.

First it would run on my computer to simplify the issue of trusting 
the operator of the machine where the data is aggregated. I am the 
operator. Mutually trusted operators may sometimes be necessary and 
feasible, but they are not needed here.

I run a secure operating system, perhaps with vetted or open source 
whose code and design are both subject to wide scrutiny.

I authorize the aggregation software to fetch my data from my 
respective financial correspondents. I create a clerk for each 
correspondent. This is difficult with current interfaces that I have 
seen with such correspondents. I indeed use "HomeBanking" from BofA 
as reported in the above article. They use SSL. I specifically 
authorize the BofA clerk to access sites with a specific certificate. 
(Parsimonioulsy I merely authorize the finger print of the public key 
found within the cert.) This would require adding logic to the SSL 
code at my site. (Curiously the current BofA site uses a cert whose 
embedded domain name does not match the domain name in the URL.) My 
BofA clerk would have free run as my agent, as far as BofA is 
concerned. This might be too much and I would have to restrict it to 
certain transactions lest it add a new bogus payee and send all my 
money to Tuva. This is possible via the BofA bill paying service that 
comes, protected by the same password, with my access. This is hard 
but not impossible. If the bank software supported passwords for 
"personal secretaries" with incomplete authority over an account, 
just as banks now discriminate various singing authorities to 
accounts of large organizations, this would be much easier.

The aggregation software would run as a confined object with these 
various clerks as holes, or perhaps merely as objects passed to the 
aggregator by the security manager, which is me in the above scenario.

I see that the above description makes implicit reference to ideas 
and schemes that not all on this list will be aware of. See 
<http://cap-lore.com/CapTheory/KK/Factory.html> for confinement and 
"holes". There is a long way to go before we achieve V.J.'s 
easy-to-trust criterion. I think we first make it trust-worthy.
-- 
Norman Hardy  <http://cap-lore.com/>