US banks that can send PGP/MIME e-mail

[Anonymous Remailer (austria)]

>On 02/25/2013 03:20 PM, Anonymous Remailer (austria) wrote:
>> Where does this idea that a business case must be recognized by all
>> suppliers for an entire industry in a whole country before it "works"?

>No one, but your statement seemed to be a severe overgeneralization.

You're the one that said the whole of Germany must implement X in
order for idea X to have a business case.  It's nonsense.

>Declaring that something works "in Germany" has a strong implication
>of it working throughout *the whole of* Germany.

Certainly not.  And nor does it matter.

It makes no difference what proportion of Germany the business case is
implemented.. but the fact that it works /in/ Germany is somewhat
useful to recognize, because every country has consumers with a
different mindset, and businesses are regulated under different rules
with respect to other regions.

I disclosed the fact that the bank was German because you would have
(perhaps rightly) asked to know which bank proves that sending openpgp
statements to ordinary customers is a workable business case anyway.
And it's useful to know where to contrast the rules culture in which
the model works.  But to claim that it must be implemented in the
whole of a country in order to have a viable business case if flawed.

> If your intent was instead to say, "Why does it work for these
>specific banks?", then I have no objection to that and I think it's a
>very reasonable question.

Sure, and indeed I identified the particular bank for which the model
is shown to work.

>> A business case can be viable if there are *zero* implementations,

>Like perpetual motion machines, business cases are judged by how well
>they work in the real world.

That's flawed, because every idea is unproven, and unimplemented in
the beginning.  If you must witness it working before you build it,
you can never see it working because it won't be built until you build
it.  If you need someone else to implement something first, so you can
see it to believe it, then your position still fails because before
that other person implemented and proved a viable idea, it was viable,
just viable and unimplemented.

And where do you get the idea that perpetual motion machines work in
theory?  It doesn't only fail to be demonstrated in the "real world",
it also fails on paper too.  So we know it fails before we try to
build one, just as we might have known that the printing press had a
viable business case before actually building one.

I suspect you're one of these people who believes that the market is
perfectly efficient -- and so efficient that all good ideas are in
play, and every new product or service that does not exist must not be
commercially viable until the very day it's rolled out.  But I see
opportunities missed far too frequently to accept this line of
reasoning.  

>>   1) First of all, you're assuming that the feature is
>>      officially supported.  A bank need not support anything,
>>      officially.

>The discussion is about banks that *send statements via encrypted
>email*.  If the bank is doing this then it's officially supporting it.

Nonsense.  We're talking about a privately owned business in a country
with freedom of enterprise.  They control their resources and
services.  They can decide what they support officially, and what they
support unofficially, and what they fail to support whatsoever.  

I have a bank who serves my old linux-based browser, and
*incidentally* the browser happens to work with that bank.  But the
bank certainly does not support my browser officially.  The browser
does not meet the constraints on what they're willing to support.  I
even signed an agreement acknowledging that I will not get support for
products that do not meet the constraints.  It's incidental that the
browser works.

They may not even support my browser unofficially.  E.g. if I call
them with a problem, they may refuse to so much as /attempt/ to
resolve the problem.  And rightly so.  It's their choice to do so.

The bank need not support openpgp.  They can implement an in-house
closed pgp implementation if they want, and it need not conform to the
openpgp standard, if they so choose.  Yet there may be incidental
cases where openpgp clients can open their statements.

>>   2) You're assuming that official support implies unlimited resources
>>      must be allocated to every call.
>No, I'm not.  At some point any business will declare a customer to be
>too much trouble for the amount of profit made from that person and will
>seek to alter or terminate the business relationship.

If you stand by this statement, then your original claim is
unsupported.  That is, a bank need not spend more money supporting
users individually.

>And if the bank is officially supporting sending customers bank
>statements via encrypted email, then yes, the bank does need to offer
>technical support or else the bank will soon be losing customers.

All banks lose customers.  A mission to retain every single one of
them would be a recipe for disaster.  There's a limited value on
retention.

>>   3) An hour of tech support costs the bank about $5-10 for the cheap
>>      labor they've outsourced it to India.  Perhaps another $10 if the
>>      Indian call center has operators who have been trained to lose
>>      their accent and sound American.
>Having seen the balance sheets for tech support costs for a couple of
>Fortune 50 firms, I can tell you that you're off by an order of
>magnitude.  Unfortunately, I'm bound by nondisclosure agreements and
>can't really say more than that.  $100 for an hourlong session is in the
>right ballpark for the firms I have firsthand experience with.

If the market can bear that kind of flat cost, then what difference
does it make whether a customer calls over a javascript problem,
navigation problem, or otherwise?  If the contract is written as you
say, then the 1 hour pgp call that costs as much as one of the many
website problem calls is money well spent.  The /website down/ variety
of calls alone overshadows the pgp calls that make a majority of
website calls moot.  IOW, delivered statements means fewer website
calls due to reduced need for the web - the website being a service
that has less continuity.

>>>  (a) radical improvements in ease-of-use,
>> Partner with hushmail.
>So your "solution" involves telling customers, "we will support your
>request to use OpenPGP for sending encrypted bank statements, but
>only if you agree to use Hushmail for a mail provider, even though
>they have a track record of turning cleartext copies of email over to
>legal authorities"? [1]

No, this is not "my solution".  It's an answer to your claim that
ease-of-use is necessarily a show stopper.  I merely demonstrated that
ease of use is not a show stopper -- should some bank seek clients
that need something foolproof.

Off the cuff, "my solution" would probably not start off by targeting
the segment of the market that would need a "PGP for dummies" option.

>[1] http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/

That's a classic story that hushmail opponents love to flash around.
But it's quite inappropriate here.  US law enforcement can trivially
ask the bank for someones records - often without a warrant and
certainly without getting a Canadian courts blessing.  Banks comply
without hesitation.

In fact, all US mainstream banks have paid lobbyists to push CISPA so
that they can cut the court out entirely and share all data.  If a
client needs to hide their US banking records from the law, Hushmail
is the last place they need to worry about.  It's as if you left your
car door wide open, and you're concerned about the strength of the
lock on the other door.

>>> (b) radical reductions in technical support costs,
>> Don't offer unlimited support.
>You seem to think the problem is unlimited support.  It's not.  The
>problem is the instant *any* support is offered it's a minimum $100
>charge (under the model I presented above, where each call has a 1%
>chance of terminating a business relationship that would've been worth
>$10,000 over its lifetime).

The bank can choose whether that 100 dollar invoice is worth the
future relationship.  And if they determine that the answer is "no",
by denying support they would be offering that particular client
nothing less than the next bank, who doesn't even offer an unsupported
PGP statement.

>> The demand need not be "explosive" if you're the only one (or one of
>> very few) supplying the demand.
>Nobody ever made a fortune by catering to a small and stagnant market.
>OpenPGP adoption has, on the whole, badly stagnated.  (Email itself is
>also stagnating, which is far worse.)

This is because in the past 10 years low-tech dummies have flooded
into the realm of online services on an astronical scale, saturating
the market with naive consumers.  The effect of that is not going to
continue as a trend going forward, IMO.

>> You've failed to make a convincing case for why a business case
>> already proven to work in Germany would fail in the US.
>A business case which has already shown itself to work *for one
>bank*.

I only need one bank.

>You simply don't have the data to make any argument one way or
>another.

I don't need it.  I'm not starting a bank.  Recall that I simply asked
if any US banks were doing what the German bank and IB were already
doing.  Before knowing that some FIs were already doing this, you
claimed it would not happen b/c the business case would not work, but
failed to substantiate.  

So the original question still stands.