Re: US banks that can send PGP/MIME e-mail
On 2013-02-23, Jerry je...@seibercom.net wrote: Well, each to his/her own I suppose; however, I would not approve of the file being sent to my PC regardless. There is always the possibility of the email being intercepted and exploited or my PC being compromised. There is a security element to this, but it actually works the other way around. SSL is considerably *less* secure than an openPGP message. Here's why: * CAs: SSL requires you to trust a certificate authority (and to date CAs have already been exploited). * MitM: There are also a number of MitM techniques that work on HTTPS connections. One attack that comes to mind involves establishing a non-SSL connection to the customer. They get no pop-up about a bad cert because there's no cert involved. The attacker even uses an icon of a padlock for the site, so if the customer is careful enough to look for the padlock, but not careful enough to look where the browser puts it, they will be fooled. Alternatively, an attacker can simply use an untrusted cert knowing that many people will just click through their browsers popup warning anyway because they cannot be bothered. * Phishing: There are many tricks that bait customers into logging into a rogue site that masquerades as their banks, ultimately creating a compromising interaction would be avoided if the statement were properly delivered. * storage: When a customer downloads their PDF statement over https, the PDF is unencrypted and it remains in that state, vulnerable to anyone who penetrates their home pc. Securing the storage requires additional effort on the part of the customer (generally unlikely). OTOH, if PGP is used, the statement is encrypted in storage by default. A customer would have to proactively decrypt the attachment with intent to archive it in the clear in order to achieve the same vulnerability as the status quo. If I want confidential information delivered to my PC, that should be my business. If an institution wanted to offer that option, and thereby being issued a released of responsibility, I have no objections to it. You would not need any such release of liability. All natural people banking in the US are free of liability per regulation E. (I say natural people, because businesses do not get reg. E protection). Although banks bear the liability for poor security choices, they generally do not care. They just need a facade that complies with the poor standards and comforts the relatively street-unwise shareholders. IOW, they only need to *appear* secure, they don't actually care to *be* secure. Hence why they don't bother with PGP. If banks had a genuine interest in security, they would at a bare minimum be PGP clear-signing their e-mail notices to customers. It would impose no technical changes on their customers, but customers keen to detect phishing could do so, and the bank could then honestly say that they've taken an effective step toward mitigating phishing attacks. Dumb user tools could then be created that makes it possible for everyone to detect phishing attacks, not just those who are keen. I do not consider the clicking on of a secure link and downloading the document to be an inconvenience, but rather a security feature, Requiring a periodic human interaction is obviously less convenient for the human. And as I pointed out, it simultaneously less secure. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
Figuring out how to install an app is not the problem. Figuring out how to *use OpenPGP* is the problem. The app is not the same as the amount of specialized knowledge required to use the app successfully. The installation problem takes care of the other. Hushmail users need not know any more than yahoo users when opening an account. A HM user may not even be aware that PGP is in play, or what PGP is. OpenPGP has a learning curve like the Matterhorn. This is a long-known and long-lamented fact. If you can fix that, then maybe things will change. As things stand, though, I doubt they will change. It's been fixed. Check out countermail.com, or hushmail.com. take the bait. Such an app could embed an email client that does everything the advanced users would do, and hide everything possible. Such an app could even hide the email address, and hide the fact that email is used at all, if they wanted. Then why bother at all with email and OpenPGP? For the /other/ users. They're not good at it. On the contrary, many of them are phenomenally good at it. Operations Research is part of the business school in most universities, and the OR geeks tend to be astonishingly good at what they do -- which is maximize efficiencies and cut inefficiencies. I'm not sure why you put so much stock into the MBA. An MBA merely makes someone into a good bullshitter, so their idea, however flawed, is better marketed to upper management. In the end, the result is better marketing spin, not better ideas. And worse, better ideas end up losing out to better marketed ideas. When one MBA is pitted against another, the decision makers ignore it anyway, and vote with their gut and use whatever data supports the decision they've already made -- not the other way around. It's a sham. I understand that many geeks like to look down our noses at people in the B-schools, but really, that's a shallow prejudice that we as a community need to get over. There are some alarmingly sharp people over there. It's really not a good time to attempt to prop these guys up, when every economy in the world is suffering acutely from their colossal and aggregate incompetence. A bank forward-thinking enough to cater to nerds with ssh for transactions and openpgp for statements would spend the least amount on security I'm going to have to ask to see the business study you're using to back this up. Do you need a business study to prove that a helicopter costs more to maintain than a bicycle? The contrast is so sharp, one would be a fool to even consider funding such a study. I won't waste any time trying to track down the proof that you're asking for. But I will say that ssh and textual interfaces are decades more mature than javascript, Adobe Flash, Flash cookies, and all the other dodgy shit you find on bank sites (and casino sites alike). And the difference in complexity is staggering -- complexity being directly proportional to defects, which in turn are directly proportional to security vulnerabilites. Moreover, an SSH server wouldn't drag the bank into the vicious pattern of chasing the shiny.. e.g. there would not be a need to work on improving the smoothness of animations that must glide accross the screen. New web frills are emerging on a rapid and ongoing basis - highly unstable. This means the cost of securing it is an ongoing cost. This recurring cost is needed just to keep up with the new bugs that are being introduced -- a cost that comes on top of the normal cost of intrusion detection and incident response. This is your prejudice, nothing more. I know studies have already proven the relationship between complexity and bugs - although I don't recall where the research was done, it's not just my imagination. And the relationship between bugs and vulnerabilities is security 101. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
On 3/2/13 11:06 AM, Anonymous wrote: The installation problem takes care of the other. Hushmail users need not know any more than yahoo users when opening an account. A HM user may not even be aware that PGP is in play, or what PGP is. At this point I'm giving up on this conversation. It's pretty clear to me that the thread is going nowhere. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
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
Re: US banks that can send PGP/MIME e-mail
Figuring out how to install an app is not the problem. Figuring out how to *use OpenPGP* is the problem. The app is not the same as the amount of specialized knowledge required to use the app successfully. The installation problem takes care of the other. Hushmail users need not know any more than yahoo users when opening an account. A HM user may not even be aware that PGP is in play, or what PGP is. OpenPGP has a learning curve like the Matterhorn. This is a long-known and long-lamented fact. If you can fix that, then maybe things will change. As things stand, though, I doubt they will change. It's been fixed. Check out countermail.com, or hushmail.com. take the bait. Such an app could embed an email client that does everything the advanced users would do, and hide everything possible. Such an app could even hide the email address, and hide the fact that email is used at all, if they wanted. Then why bother at all with email and OpenPGP? For the /other/ users. They're not good at it. On the contrary, many of them are phenomenally good at it. Operations Research is part of the business school in most universities, and the OR geeks tend to be astonishingly good at what they do -- which is maximize efficiencies and cut inefficiencies. I'm not sure why you put so much stock into the MBA. An MBA merely makes someone into a good bullshitter, so their idea, however flawed, is better marketed to upper management. In the end, the result is better marketing spin, not better ideas. And worse, better ideas end up losing out to better marketed ideas. When one MBA is pitted against another, the decision makers ignore it anyway, and vote with their gut and use whatever data supports the decision they've already made -- not the other way around. It's a sham. I understand that many geeks like to look down our noses at people in the B-schools, but really, that's a shallow prejudice that we as a community need to get over. There are some alarmingly sharp people over there. It's really not a good time to attempt to prop these guys up, when every economy in the world is suffering acutely from their colossal and aggregate incompetence. A bank forward-thinking enough to cater to nerds with ssh for transactions and openpgp for statements would spend the least amount on security I'm going to have to ask to see the business study you're using to back this up. Do you need a business study to prove that a helicopter costs more to maintain than a bicycle? The contrast is so sharp, one would be a fool to even consider funding such a study. I won't waste any time trying to track down the proof that you're asking for. But I will say that ssh and textual interfaces are decades more mature than javascript, Adobe Flash, Flash cookies, and all the other dodgy shit you find on bank sites (and casino sites alike). And the difference in complexity is staggering -- complexity being directly proportional to defects, which in turn are directly proportional to security vulnerabilites. Moreover, an SSH server wouldn't drag the bank into the vicious pattern of chasing the shiny.. e.g. there would not be a need to work on improving the smoothness of animations that must glide accross the screen. New web frills are emerging on a rapid and ongoing basis - highly unstable. This means the cost of securing it is an ongoing cost. This recurring cost is needed just to keep up with the new bugs that are being introduced -- a cost that comes on top of the normal cost of intrusion detection and incident response. This is your prejudice, nothing more. I know studies have already proven the relationship between complexity and bugs - although I don't recall where the research was done, it's not just my imagination. And the relationship between bugs and vulnerabilities is security 101. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
On Sat, 2 Mar 2013, Anonymous wrote: . . . It's really not a good time to attempt to prop these guys up, when every economy in the world is suffering acutely from their colossal and aggregate incompetence. Not to mention the situations where available intelligence was used to do various cheats. The level of skill is one necessary aspect to evaluate, the uses of whatever skill level may exist is another and separable aspect. (And then there are the cases where people with public reputations for great intelligence in the financial industry have later been found to be anyhow mainly bold cheats.) A bank forward-thinking enough to cater to nerds with ssh for transactions and openpgp for statements would spend the least amount on security . . . Moreover, an SSH server wouldn't drag the bank into the vicious pattern of chasing the shiny.. e.g. there would not be a need to work on improving the smoothness of animations that must glide accross the screen. I wonder if banks offer secure communication services to premium cutomers these day, eg high-wealth customers of regular or private banks. I am surprised that is not a market niche being pursued AFAIK, in which spending directly on developing usable and private processes could be distinctive in the market. The individuals in that category whom I have known enough to have some little awareness of their attitudes about financial communications security have seemed not to have such services available from their banks. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
On 02/25/2013 05:10 PM, Anonymous wrote: Ing in Netherlands distributes software (windows, mac, and linux versions) - so apparently it's easy enough for enough average joe's to figure out how to install an app. Figuring out how to install an app is not the problem. Figuring out how to *use OpenPGP* is the problem. The app is not the same as the amount of specialized knowledge required to use the app successfully. OpenPGP has a learning curve like the Matterhorn. This is a long-known and long-lamented fact. If you can fix that, then maybe things will change. As things stand, though, I doubt they will change. take the bait. Such an app could embed an email client that does everything the advanced users would do, and hide everything possible. Such an app could even hide the email address, and hide the fact that email is used at all, if they wanted. Then why bother at all with email and OpenPGP? They're not good at it. On the contrary, many of them are phenomenally good at it. Operations Research is part of the business school in most universities, and the OR geeks tend to be astonishingly good at what they do -- which is maximize efficiencies and cut inefficiencies. (ObDisclosure: I'm a contributor to COIN-OR, the Computational Infrastructure for Operations Research, and have assisted with a couple of papers in the field. I have been deeply, thoroughly impressed by virtually everyone I've met in OR.) Moreover, the nerds among them are a very different variety of nerd than that which would understand or appreciate the needs of a comp sci/math/software nerds. OR nerds -- who are the B-schoolers who focus most heavily on efficiencies -- are serious math and CS nerds. Look up George Danzig sometime. http://en.wikipedia.org/wiki/George_Dantzig I understand that many geeks like to look down our noses at people in the B-schools, but really, that's a shallow prejudice that we as a community need to get over. There are some alarmingly sharp people over there. A bank forward-thinking enough to cater to nerds with ssh for transactions and openpgp for statements would spend the least amount on security I'm going to have to ask to see the business study you're using to back this up. This is your prejudice, nothing more. It's just as credible to claim that a bank probably wouldn't want to cater to seriously tech-savvy people because of the risk of bad apples. If 0.01% of your customers have the capability to defraud your bank, that's a much different situation from 1% having that same capability. It affects the business logic considerably. They might wind up spending the *most*. The average American has ~14 bank/credit card accounts. I shit you not. So it's not just one account they must go pickup their statement from. You could not make a convincing claim that only 0.01% of Americans would appreciate their statements *delivered* automatically. Which is why I didn't make that claim. I said that probably 1% (and my suspicion is 0.1%) of all users would want OpenPGP to be used to secure delivery. For example, I'm in the ranks of people who don't care. I genuinely don't. I want some sensible technology to be used, but I have zero interest in specifying which technology should be used. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
On Mon, Feb 25, 2013 at 05:10:01PM -0500, Anonymous wrote: [snip] In the states, the trend of banks offering proprietary apps for smartphones is snowballing. Banks what users to take their software so bad they're offering free miles and contests to get customers to take the bait. Such an app could embed an email client that does everything the advanced users would do, and hide everything possible. Such an app could even hide the email address, and hide the fact that email is used at all, if they wanted. Heh, exactly why I won't take those app.s. [snip] Security doesn't directly generate revenue -- at best it indirectly facilitates it, but that's difficult to quantify and plug into a spreadsheet. That means security gets viewed as an overhead expense: something to be minimized at all costs. The cost of securing their webserver and all the flashy shit that they compulsively upgrade on a regular basis cannot be cheap. A bank forward-thinking enough to cater to nerds with ssh for transactions and openpgp for statements would spend the least amount on security, and simultaneously achieve a more secure infrastructure than the other banks who try to keep up with the latest web animation tricks, and all the holes that this emerging junkware continues to open. I imagine that there is another class of security at work here which, at some point, is still cheaper: buy insurance and just pay off the affected customers when something occasionally goes wrong. I can't point to any evidence, but it would seem to be the way that businesspeople think about security. Remember, from their viewpoint, they are securing *their business*, not ours. [snip] OpenPGP users account for probably less than a thousandth of all computer users. 99.9% of all banking users have no real desire to see OpenPGP used for their statement delivery. The average American has ~14 bank/credit card accounts. I shit you not. So it's not just one account they must go pickup their statement from. You could not make a convincing claim that only 0.01% of Americans would appreciate their statements *delivered* automatically. Careful: would like their statements delivered automatically vs. have a desire to see OpenPGP used for statement delivery. Many customers cannot cope with the manual effort of downloading all their statements, so they simply don't. They see their balance and send a payment, and let the statements rot online, and ultimately get archived and cleaned off the server. That sounds like human nature, but I would be interested to see measurements if there are any. Others resort to giving all their bank usernames and passwords to a 3rd party whome they must trust, which downloads the statements for them, and then offers yet another pickup service (yes, these users must still login to a website, but at least it's 1 site and not 14). As above. We also have to consider the question of what the banks' lawyers will let them do, once they pick their jaws up off the floor. This is probably the origin of the closed, private email system locked away inside each bank's site. That is, perhaps, where one should work on acceptance of suitable encryption and signing. (Suitable including what will actually be used more or less correctly by a sufficient percentage of customers.) -- Mark H. Wood, Lead System Programmer mw...@iupui.edu There's an app for that: your browser pgp46KI_sS9xN.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
Well, there is a way to find out whether it works. Those who care deeply about this should get together, raise some capital, and open NerdBank(tm) where they can do business their way, and see how it goes. There's plenty of room right now for people who want to reimagine the retail banking business, so long as they still keep depositors' money safe and deal it out as ordered. I'm actually more interested in the local bank as portal to certificate services. Actually going physically to the issuer and presenting, face-to-face, identifying documents that might actually be slightly difficult to steal or forge, is not something that most people can realistically do with the current crop of CAs. Long-distance relationships in the security realm make trust difficult, in both directions. None of this has a great deal to do with OpenPGP or GnuPG as such. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu There's an app for that: your browser pgpwLUbtzQ2b8.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
Why does the business case work in Germany? It doesn't. It works for one particular bank. It doesn't work for Germany as a whole. 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? A business case can be viable if there are *zero* implementations, substantiated purely by analysis. And having just one working case goes as far as testing and proving that it works. Different banks have different clienteles and different incentives for how they deal with their clientele. My point exactly. One bank may offer a free t-shirt to get customers, while another may offer more security and more convience in statement delivery. Just because one bank can survive on the t-shirt promo doesn't make the GPG feature unviable. And as soon as a customer is on the phone with tech support for two hours trying to get GnuPG to work on their system, that's about $100 the bank has now spent trying to retain this customer. That's a lot. You're making several errors in that one statement. 1) First of all, you're assuming that the feature is officially supported. A bank need not support anything, officially. 2) You're assuming that official support implies unlimited resources must be allocated to every call. Nothing the bank does includes unlimited support. If they choose to give any support at all, they can pick and choose the extent to which they offer support. And indeed, this is what happens. Try just getting basic browser support if you're running Debian and Iceweasel, when it fails to handle all the javascript and flash that many banks (foolishly) use. You'll exhaust the tech support in no time, and will never be given the opportunity to talk to the engineers. And if you could, they aren't going to fix what's broken on their server to make the service work for you. 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. 4) A bank can (and does) limit the configuration for which they will support, officially. E.g. they might say they only support the latest MS Explorer. Or they might say they only officially support PGP statements to customers who have hushmail accounts (so the dummies can get fool-proof service that needs no technical support) - while unofficially giving the nerds a means to submit their public keys. The only way to make the user profitable in such a case is to raise service fees, in which case that bank will hemorrhage business to their competitors. IB has figured out that this is not true. Their VIP customers pay through the nose for their premium service, but they're the only game in town, so nothing threatens their market share. If I were a banker and I had a choice between SSL-secured HTTPS that 99% of my internet banking customers would approve of, which requires no special training or experience on their part, which requires no additional special training on the part of my tech support staff, or adding OpenPGP-secured statement delivery that would appeal to 1% of my userbase and each one of those users would have tech support costs orders of magnitude greater than the users as a whole, the presence of that 1% would require expensive training and retraining on the part of my tech support staff... Then you would choose to be a dime-a-dozen bank, and compete with tens of thousands of banks for 1/1th of 99% of the market, which is obviously not as profitable as taking the other 1% in whole. Honestly, if I was advising a consumer bank about this, I'd tell them to avoid OpenPGP. I don't see the business case for it. And until you can show me either (a) radical improvements in ease-of-use, Partner with hushmail. (b) radical reductions in technical support costs, Don't offer unlimited support. (c) explosive demand from the users, The demand need not be explosive if you're the only one (or one of very few) supplying the demand. you really can't show me the business case for it, either. You've failed to make a convincing case for why a business case already proven to work in Germany would fail in the US. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
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. Declaring that something works in Germany has a strong implication of it working throughout *the whole of* Germany. 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. 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. 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. 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. This does not change the fact that people will still seek technical support, and that technical support costs money. 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. 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. To give you an idea of how the accounting is done, though, labor costs are the least of the concern. Another major concern is, What if the customer gets so frustrated with the problem that the customer stops doing business with us? If 1% of tech support calls result in losing a customer, and the average lost customer would've resulted in $10,000 of profit over the course of that customer's relationship with the business, then the amortized cost of a tech support call just jumped to $100... right there... based on nothing more than the cost of the customer's frustration. You cannot measure the cost of a tech support call solely by the cost of the labor involved. The labor involved is insignificant: it's so minute it's practically considered accounting error. The real costs come elsewhere, and they accrue the instant the tech support call is placed. Then you would choose to be a dime-a-dozen bank, and compete with tens of thousands of banks for 1/1th of 99% of the market, which is obviously not as profitable as taking the other 1% in whole. This assumes the 0.1% that uses OpenPGP provides per-customer revenue comparable to that of the 99.9%. This is probably not true: you're talking about such a small selection of users that their profile will probably be quite idiosyncratic compared to the community at large. Honestly, if I was advising a consumer bank about this, I'd tell them to avoid OpenPGP. I don't see the business case for it. And until you can show me either (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] [1] http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/ (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). You can reduce the price of offering technical support or reduce the rate at which technical support is needed. Capping support will do nothing to mitigate the problem, because labor costs -- the thing you're proposing to cap -- are not the problem. 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,
Re: US banks that can send PGP/MIME e-mail
OpenPGP, no, because there's no business case for them to do so. OpenPGP users represent a phenomenally small fraction of their userbase (probably 1%) and would account for a large fraction of their tech support questions. You seem to imply that Americans are less capable or less interested in PGP-protected mail. The German bank 1822 Direkt sends PGP encrypted bank statements to their customers. Someone mentioned another German bank that does this. Why does the business case work in Germany? Interactivebrokers (which is essentially a worldwide bank) offers PGP encrypted statement as a delivery option. But sadly, IB is elitest, in the sense that only their high value high-roller VIP customers can tick the PGP box (perhaps this supports your point). There is also a bank in Japan, South Africa, and on in the US which supports a passworded PDF option. It's obviously less secure than PGP if they are using the RC4 algorithm, but certainly indicates that some people like true delivery.. just as one might prefer to have their pizza delivered. Anyway, I don't accept the idea that the business case is lacking. In an industry that is willing to pay upwards of $150 to entice new customers into opening an account, a bank could easily gain majority market share of all self-respecting nerds in the country at a fraction of that cost. I call it a missed opportunity. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
On 02/24/2013 08:21 AM, Anonymous wrote: You seem to imply that Americans are less capable or less interested in PGP-protected mail. Oh, please. This is pure projection. The German bank 1822 Direkt sends PGP encrypted bank statements to their customers. Someone mentioned another German bank that does this. Why does the business case work in Germany? It doesn't. It works for one particular bank. It doesn't work for Germany as a whole. Different banks have different clienteles and different incentives for how they deal with their clientele. Anyway, I don't accept the idea that the business case is lacking. In an industry that is willing to pay upwards of $150 to entice new customers into opening an account, a bank could easily gain majority market share of all self-respecting nerds in the country at a fraction of that cost. I call it a missed opportunity. And as soon as a customer is on the phone with tech support for two hours trying to get GnuPG to work on their system, that's about $100 the bank has now spent trying to retain this customer. That's a lot. The only way to make the user profitable in such a case is to raise service fees, in which case that bank will hemorrhage business to their competitors. If I were a banker and I had a choice between SSL-secured HTTPS that 99% of my internet banking customers would approve of, which requires no special training or experience on their part, which requires no additional special training on the part of my tech support staff, or adding OpenPGP-secured statement delivery that would appeal to 1% of my userbase and each one of those users would have tech support costs orders of magnitude greater than the users as a whole, the presence of that 1% would require expensive training and retraining on the part of my tech support staff... Honestly, if I was advising a consumer bank about this, I'd tell them to avoid OpenPGP. I don't see the business case for it. And until you can show me either (a) radical improvements in ease-of-use, (b) radical reductions in technical support costs, or (c) explosive demand from the users, you really can't show me the business case for it, either. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
On Sun, 24 Feb 2013, Robert J. Hansen r...@sixdemonbag.org wrote: On 02/24/2013 08:21 AM, Anonymous wrote: You seem to imply that Americans are less capable or less interested in PGP-protected mail. Oh, please. This is pure projection. The German bank 1822 Direkt sends PGP encrypted bank statements to their customers. Someone mentioned another German bank that does this. Why does the business case work in Germany? It doesn't. It works for one particular bank. It doesn't work for Germany as a whole. Different banks have different clienteles and different incentives for how they deal with their clientele. Anyway, I don't accept the idea that the business case is lacking. In an industry that is willing to pay upwards of $150 to entice new customers into opening an account, a bank could easily gain majority market share of all self-respecting nerds in the country at a fraction of that cost. I call it a missed opportunity. And as soon as a customer is on the phone with tech support for two hours trying to get GnuPG to work on their system, that's about $100 the bank has now spent trying to retain this customer. That's a lot. The only way to make the user profitable in such a case is to raise service fees, in which case that bank will hemorrhage business to their competitors. Ship a device. If I were a banker and I had a choice between SSL-secured HTTPS that 99% of my internet banking customers would approve of, which requires no special training or experience on their part, which requires no additional special training on the part of my tech support staff, or adding OpenPGP-secured statement delivery that would appeal to 1% of my userbase and each one of those users would have tech support costs orders of magnitude greater than the users as a whole, the presence of that 1% would require expensive training and retraining on the part of my tech support staff... Honestly, if I was advising a consumer bank about this, I'd tell them to avoid OpenPGP. I don't see the business case for it. And until you can show me either (a) radical improvements in ease-of-use, (b) radical reductions in technical support costs, or (c) explosive demand from the users, you really can't show me the business case for it, either. Your argument seems to show that, in order to get more people using encrypted email, we should use part of the system you think is superior, namely the browser with whatever crypto stack your banks use. If such a superior system for easy delivery of well encrypted stuff exists I would like to learn about it. ad a: Yes, of course, Gnupg is today for many people very difficult to set up. Why is the browser plus crypto system easier to use? oo--JS. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
On 02/24/2013 03:27 PM, Jay Sulzberger wrote: Ship a device. Meaning what, exactly? At first blush you seem to be trading one problem for another: people don't know how to use GnuPG, so ship a device and now they don't know how to use the device. Your argument seems to show that, in order to get more people using encrypted email, we should use part of the system you think is superior... Cheaper, not superior. To a first approximation, MBAs and bean-counters divide a business's operations into revenue and overhead. They'll go to great lengths to maximize revenue, and they'll go to great lengths to minimize expenses. Security doesn't directly generate revenue -- at best it indirectly facilitates it, but that's difficult to quantify and plug into a spreadsheet. That means security gets viewed as an overhead expense: something to be minimized at all costs. People keep on thinking in terms of wouldn't it be nice if, but that's not how business thinks. Business thinks in terms of, what will maximize revenue and minimize overhead? OpenPGP users account for probably less than a thousandth of all computer users. 99.9% of all banking users have no real desire to see OpenPGP used for their statement delivery. If the 0.1% of customers who want OpenPGP produce so much revenue for a bank that they cannot be ignored, and are willing to leave their current bank for one that will provide OpenPGP, then we can expect to see banks deploying OpenPGP-based solutions. But until then, no. This is not a technological problem. It's a business problem. To think otherwise is to commit serious category error. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
On Friday 22 February 2013 19:24:44 Anonymous Remailer wrote: Have any consumer banks in the US figured out how to use PGP, so monthly statements can be trully *delivered*? The only bank I know that is able to receive pgp encrypted emails is the German netbank. But they don't sent out pgp encrypted emails to their customers. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
On Fri, 22 Feb 2013 20:55:57 -0500 Robert J. Hansen articulated: On 02/22/2013 01:24 PM, Anonymous Remailer (austria) wrote: Have any consumer banks in the US figured out how to use PGP, so monthly statements can be truly *delivered*? OpenPGP, no, because there's no business case for them to do so. OpenPGP users represent a phenomenally small fraction of their userbase (probably 1%) and would account for a large fraction of their tech support questions. S/MIME, yes, some banks have discovered the benefit. However that's still mostly a business-to-bank thing as opposed to consumer-to-bank, since S/MIME is a technology that's not exactly ready for consumers. I find your statement regarding S/MIME erroneous; however, we can just agree to disagree on that matter. Neither one of us will ever win the argument. My bank and credit card company, sends me a monthly link to a secure URL that affords me the opportunity to view my statements. I also have the option of downloading in PDF, CSV or MS Excel format my statement. I have never received a plain email statement detailing my banking records. Unless I am seriously misreading this thread, I am not sure what advantage either PGP or S/MIME would afford. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 m...@jama.is wrote: On Friday 22 February 2013 19:24:44 Anonymous Remailer wrote: Have any consumer banks in the US figured out how to use PGP, so monthly statements can be trully *delivered*? The only bank I know that is able to receive pgp encrypted emails is the German netbank. But they don't sent out pgp encrypted emails to their customers. There is a nordic bank that generates s/mime certificates for its customers. Because everybody has to have a registered address (at least in Norway) they send a password to that address. You have to present the certificate to login on the web. - -- Andy Ruddock - andy.rudd...@rainydayz.org (GPG Key ID 0xB0324245) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJRKLfEAAoJECqtbbewMkJFy7MQAKF5ShSJmWu6rsuNWDBP9m+E qh+Xq5HFtkha8b7UK4+9mvNqNu2QGzXMufoxmRpiWDiWiKdPaZDVi22qh2BFcSam zLu+tlnDb8qdQeEeXDa58/0idxw/Et/VBINLLHubOERAezz9BIlrBM3XU6kRPRtF kQ0kqoFmzXYhq4gTL2RMf570M4GSS2CfTbWqup1+ArbiSeOdTb9GIbDebwMW6IrV nebwDWc8NiV3I2SkiWGhBROvMAtA2YcIuSEBcsdUNPZFftTzcvxC/wym6+SCQgRc AIibz5SLVaLZsnIbC/H62XGufz/bDINim03pnvTinEbgtqkUQLyxGs7RUZp/FVVC cs12/hmCkT350RSgk44yooFQ7Kx843d11KSofBIvMwLWSRue0qw+h0aGiOBV7WHa XaIEvJz83jVoH378WDcf8BffFdO+DtFoAob9VdJJoHarXPTw8kPHRqR2HL6Bcsfd MZ4VA7IoJz3xpW6XhrFL9z05Lnqno6bB9mDjcQtXMR1su0rDgGD1nCf4HSaVY9Lw u/RNcCzT7qHR1/dhKBzCUIaPyBquD7ml6SPLh791SJ1ZTs3yVf3AmTX/d6NEbAuo L/tpg/7EHdbUWz9Tu7IVQJ6XqdVi56Z9455C7MHQoIGpxMnUp7ftTFAII11vgyEh gu1OsmAvHsWkpGdHi1xQ =7KPs -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerry wrote: On Fri, 22 Feb 2013 20:55:57 -0500 Robert J. Hansen articulated: On 02/22/2013 01:24 PM, Anonymous Remailer (austria) wrote: Have any consumer banks in the US figured out how to use PGP, so monthly statements can be truly *delivered*? [snip] My bank and credit card company, sends me a monthly link to a secure URL that affords me the opportunity to view my statements. I also have the option of downloading in PDF, CSV or MS Excel format my statement. I have never received a plain email statement detailing my banking records. Unless I am seriously misreading this thread, I am not sure what advantage either PGP or S/MIME would afford. The point being that you get a link. If the banks used PGP or S/MIME then they could actually send you your statements. - -- Andy Ruddock - andy.rudd...@rainydayz.org (GPG Key ID 0xB0324245) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJRKNK+AAoJECqtbbewMkJFFhgQAJg0hLk8qlULy1Q6PklWVLjh f/ZAdoYnt3ywDdbY3muX7KduSfhjVEUJJnm4oM0v6ivMqul7HT+6cB4/6ML/rtR1 Hf073dVMi8VhEWcMxxm6KS/9vORVpE2zUHhfR/FCkkJLy4cVIwTou0pljwPhsOud dVj5gaynQpjMSUSNF9WfxL3LEB2l29j5iLWWS5LChnJzpstkKAkW/tlnuEf/K5Ns aKmP4TsJJDeh/nCbbry68j3eY2gVT2V4JVLdfpwf0NnHa4uD6hikh+a6Hn09MTe8 lpBi/jXv0fs8ApXq9VAqmzs5tJ0bwNV9b5TBdUaEupx4fRAhhnIxjL5S4cw4payo FwyKDoepzMj5a+q+6szDKn5D/FP5Wi+lat7TwfNxxMw4HqOHn2Jau2y8846WFNlL e8xiPneRTkI5OlannjFVEV7BFlHTFw2XhrpjZMU0ceBpvoHyEx1nm3hHdOPjFkpd h/WY7cUZJudGAgTwuY68M6ACRKWYNZ0THk1S4hvB4IoRIW1mGtnGW9Zh3SLZ03OS TIfCvXLkD4XrQ9OfdFMVVWMj1mpQ9M/GFDKJ4Kg6OzX6tJVxu7liVD09lRD1nQRO MXXuME8eZr0sqFWxNpE79PyEoUfN3qujfGMtcEAXuAh6T6YF9AWR/hteVkfIHswX tqYz9lqObnl9GFdc5Kms =3Lqg -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
On Sat, 23 Feb 2013 14:31:26 + Andy Ruddock articulated: Jerry wrote: On Fri, 22 Feb 2013 20:55:57 -0500 Robert J. Hansen articulated: On 02/22/2013 01:24 PM, Anonymous Remailer (austria) wrote: Have any consumer banks in the US figured out how to use PGP, so monthly statements can be truly *delivered*? [snip] My bank and credit card company, sends me a monthly link to a secure URL that affords me the opportunity to view my statements. I also have the option of downloading in PDF, CSV or MS Excel format my statement. I have never received a plain email statement detailing my banking records. Unless I am seriously misreading this thread, I am not sure what advantage either PGP or S/MIME would afford. The point being that you get a link. If the banks used PGP or S/MIME then they could actually send you your statements. Well, each to his/her own I suppose; however, I would not approve of the file being sent to my PC regardless. There is always the possibility of the email being intercepted and exploited or my PC being compromised. If I want confidential information delivered to my PC, that should be my business. If an institution wanted to offer that option, and thereby being issued a released of responsibility, I have no objections to it. I do not consider the clicking on of a secure link and downloading the document to be an inconvenience, but rather a security feature, especially when the documents(s) can be downloaded in several formats. I realize that not everyone will agree with me. Que Sera, Sera -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
US banks that can send PGP/MIME e-mail
Have any consumer banks in the US figured out how to use PGP, so monthly statements can be trully *delivered*? (as opposed to getting a plaintext message troubling clients to login via some GUI and point-click-point-click-point-click) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: US banks that can send PGP/MIME e-mail
On 02/22/2013 01:24 PM, Anonymous Remailer (austria) wrote: Have any consumer banks in the US figured out how to use PGP, so monthly statements can be truly *delivered*? OpenPGP, no, because there's no business case for them to do so. OpenPGP users represent a phenomenally small fraction of their userbase (probably 1%) and would account for a large fraction of their tech support questions. S/MIME, yes, some banks have discovered the benefit. However that's still mostly a business-to-bank thing as opposed to consumer-to-bank, since S/MIME is a technology that's not exactly ready for consumers. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
