To be honest—I don't know myself how the validation protocols are named, so I don't know what the steps proposed in that thread actually do. It just sounds as if they turned off checking the validity of a certificate.
If that's what they do, though, bookmarks will not protect you against an attack. They will only protect you against the URL spoofing I mentioned later in the posting above.
This is what an attack might look like: The attackers hack the DNS server that is responsible for the bank's domain. They replace the bank's DNS records by their own. From that point on, the hostname
www.bankxy.com will resolve to an IP address that points to the attackers' servers instead of to the servers of the bank. If you now enter that hostname in your browser (or click on the bookmark), and you ISP's DNS doesn't give you a cached result, but has to fetch the IP address from the domain's DNS server, your browser will show the attackers' site, not the bank's. The attackers have copied the complete banking interface of the bank and can collect PINs and TANs. Another way would be if your ISP's DNS server is hacked so it will give you only "cached" results for
www.bankxy.com that have been inserted by the attackers. Or, if they gained root access to your computer, they could insert a line for
www.bankxy.com in the file /etc/hosts—the system will not fetch the IP from a DNS server, then, but use the entry in /etc/hosts.
Now, if everything is configured as it should be, the following happens when an SSL session is started: The server sends its SSL cerificate to the browser, and the browser checks back if the certificate is correctly signed by the issuer of the certificate (like VeriSign). This is what you might turn off with the steps from the thread. If an attack is going on, you will normally be presented a warning by your browser and can take the appropriate steps. You won't see any difference with that checking turned off, though.
So, as you see above, it is _very_ difficult to launch such an attack. The money that could be earned might make this effort worthwhile in the case of a bank, though. Additionally, if you use HBCI (at least in Germany that's a standard where banking security isn't done via PIN/TAN, but with a smartcard and a reader attached to the computer) or your bank has a good TAN system (that randomly chooses a _numbered_ TAN you have to enter instead using one TAN after the other as they appear on the list), there couldn't be much harm done. The attackers could get you PIN and look into your account, but the could not send money anywhere else, as they can't know what the next TAN that's asked for will be, or, in the case of HBCI, wouldn't be able to get any information at all. And, another point is: It would probably be a better idea for the attackers not to use SSL at all—who will check if the little lock is present in his browser before entering sensitive data? So, maybe these settings wouldn't make any difference at all as SSL isn't used, ayway. Maybe.
Thus, that risk isn't _that_ great. But still a one I wouldn't take.