When connecting to on-line banking sites, browsers such as the latest firefox-8.x can show some of the attributes of the SSL [secure sockets layer] certificate, which the bank's server sends to the browser to provide a public encryption key plus some level of trust that the key is actually being provided by the intended bank. After connecting to the bank's secure web site with a firefox-8.x browser, and before logging in, a user has a chance to examine the SSL certificate by clicking on the colored area to the left of the bank's URL. Then click "More Information", and then "View Certificate". (Other browsers may have other methods to examine this certificate.) Some on-line banking users check this certificate before logging in for every new on-line banking session, as a precaution that they are really communicating with the intended bank or its on-line server provider. Information that is provided includes the number of bits that the session's encryption algorithm's key will use, the date of issue and expiration of the certificate, its serial number, and so-called "fingerprints" of the certificate. Fingerprints are a kind of digest of all the data in the certificate, provide some degree of confidence that the certificate has not been altered, and are often shown as a string of hexadecimal digits (0-9,A,B,C,D,E,F). Firefox-8.x shows both the MD5 (message digest #5) and SHA1 (secure hash algorithm #1) fingerprints. By monitoring the attributes of the SSL certificates used by various on-line banks across many on-line sessions with those banks, one can detect some possibly interesting differences in the way different on-line banks handle their SSL certificates. E.g. Ally Bank declares up-front in the first informational window that Ally owns the web site. AmEx uses a third party web site provider, and it is this provider that is shown as the web site owner. Chase does not declare ownership of the web site in the preliminary info window, but the later certificate info windows show that JPMorgan is the holder of the certificate. AmEx and Chase use 128 bit session encryption keys, while Ally uses a 256 bit key. AmEx and Ally each use the same unique certificate from session to session (as shown by each of their unchanging SHA1 fingerprints), while Chase appears to have tens of different active SSL certificates that are dynamically allocated to different sessions, each with a different SHA1 fingerprint. Periodically, old SSL certificates will expire and new ones will be issued to the banks by the trusted certificate authorities, of which there are several. Questions that could be discussed related to these on-line banking SSL certificate issues include:  Is it more trustworthy for a bank to operate its own on-line banking as an in-house operation, or to farm it out to specialist third party on-line banking organizations?  Is it easier to trust an on-line bank that consistently uses the same familiar SSL certificate, or is there greater safety in a bank using multiple certificates that change from session to session?  Would it be a good idea for all on-line banks to declare their explicit ownership of their web sites within the SSL certificate info that users can quickly check before logging on?