Closed Bug 57537 Opened 24 years ago Closed 23 years ago

Can't log into WellsFargo (browser sniffing)

Categories

(Tech Evangelism Graveyard :: English US, defect, P3)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: pierre, Assigned: arun)

References

(
URL
)

Details

(Keywords: ecommerce, Whiteboard: [BANK][USERAGENT][DENY][PROPRIETARY-DOM]) 

- Go to http://www.wellsfargo.com
- Click "Sign On" (in the top right corner)
==> You get a page saying " YOU MUST UPGRADE YOUR BROWSER"

Their list of approved browsers is:
http://www.wellsfargo.com/per/services/browser/chart/


Assigned to ekrock because that can't be fixed without some serious talking with 
them (and testing on their side too, I guess).
Same problem with 2000-10-20-09 trunk on Linux. According to their list of
supported browsers, they simply don't support mozilla. Platform->All, OS->All.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
*** Bug 57904 has been marked as a duplicate of this bug. ***
As I indicated in Bug 57904, it happens with other sites as well.  I gave
another example in that bug.  Mozilla should be capable of telling a site it is
ns4 since it is the future version of ns.  Perhaps an enhancement to be able to
give a specified site a specified browser string.

> Mozilla should be capable of telling a site it is ns4 since it is the future
> version of ns.

No. This would be a disastrous mistake because it would mislead client sniffing
code into delivering/executing code that is Nav4-specific. Even in pages that
had been upgraded to support the W3C DOM, a misleading UA string would cause
JavaScript code in web pages to think it was running on Nav4 and then try to
execute Nav4-only code forks with things like document.layers[], leading to
errors. Server-side sniffers would similarly dish out pages optimized for Nav4
rather than pages optimized for W3C standards supported in Gecko. You can go
here to read more about client DOM differences and the implications for client
sniffing:
http://sites.netscape.net/ekrock/standards.html
http://developer.netscape.com/viewsource/krock_v5.html
http://developer.netscape.com/docs/examples/javascript/browser_type.html

> Perhaps an enhancement to be able to give a specified site a specified
> browser string.

No, this would be an administrative albatross and a fatally doomed approach.
Suppose we tweaked the product to spoof Wells Fargo and then they upgraded their
content--then what?

The simple, correct solution to this problem is for web sites to update their
accepted UA lists to include Mozilla/N6.

Isn't this a DUP of another bug in which this was already reported?

--> Blake for evangelism.
Assignee: ekrock → blakeross
It would not be so "disasterous" to send a browser string that tells the site
moz is ns4 even if it doesn't support every littke ns4 feature.  The worst that
would happen is it wouldn't work and the user can't use moz/ns6.  There is a
chance it will work for some sites which would at least give moz/ns6 a fighting
chance.

I think it is a fatal mistake for moz/ns6 not to support ALL web sites supported
by ns4.  At least mozilla should have a "ns4 mode" which could be enabled on a
per-site basis if there are some ns4 features that are not compatible with
standards.  In this mode, moz/ns6 would tell the site it is ns4 and then support
all the extentions, behavior, etc supported by ns4.

I think you under-estimate how many sites require ns4 and the huge undertaking
to get all these sites to support pure moz/ns6.

If my suggestions are not implemented, we will be stuck with ns4 for a very long
time and moz/ns6 will rot on the shelves.

In any case, it is obvious now that moz/ns6 is not ready for prime time, since
implementing all ns4 features with a "ns4 mode" is probably not a small task.

Unless I see something positive in this bug, I will erase mozilla from my system
and give up.  There are just too many web sites (most banks, I bet and possibly
many other web sites conducting serious business) that require ns4, making
moz/ns6 useless.

What?  Your logic is nonsensicle here.

>The worst that would happen is it wouldn't work and the user can't use moz/ns6.

Hmm.  Not being able to use the browser doesn't seem too good to me.  How about 
you?
Exactly my point.  That's why I stressed moz/ns6 must be able to support all ns4
functionality or it is useless (by default or with a setting on a per-site
basis).  That is what my second paragraph is all about.
Some sites will work now with mozilla just fooling the site to believing it is
ns4 because some (if not most) probably only care if you are running IE or ns in
order to use MS specific features or not (like ActiveX controls, VB scripts,
etc).

Moz should not present itself as Nav4, no browser ever did that.  IE5 doesn't say 
"I'm IE4", IE4 doesn't say "I'm IE3" and IE3 doesn't say "I'm Netscape 1.0".  
There wouldn't have been any progress on the Web in the past 7 years.

These sites will upgrade their code.  They knew when they wrote it that it would 
become obsolete.

You are nit picking.  OK then, mozilla should say it is ns6 and it should
support everything ns4 did.  Most (if not all) sites only care that the browser
is ns and >= 4 and they (correctly) expect ns6 to work.
If mozilla doesn't do that, then I cannot use mozilla for any serious work.
If ns6 does this and moz doesn't, then they will be different browsers and
mozilla is useless.

With all due respect, I think you are basing your position on misinformed 
ideas.  Mozilla will not and will never deliberately disguise itself as 
Netscape 6, because Mozilla is an open-source browser, whereas Netscape is a 
vendor based off Mozilla source code.  Mozilla is Mozilla, not Netscape, and to 
say otherwise would be to undo years of struggling to get that point across to 
the public.

We already have a quirks mode to help ease the transition between the current, 
non-standard and largely propietary state of the web and the strict, standard 
web that Gecko will hopefully someday bring about.  The point, as Pierre says, 
is that if we are so lenient in parsing that we accept and support everything, 
there will be no incentive for webmasters to update their sites to W3C specs.  
Considering standards are at the heart of Mozilla and its parsing and layout 
engines, I don't quite think this is `nit-picking' as you put it.

You say that `If ns6 does this and moz doesn't, then they will be different 
browsers and mozilla is useless.'  That's great!  Mozilla and Netscape ARE 
different browsers.  They might look similar now, but Mozilla will continue to 
be driven by the open-source community, while Netscape will continue to be 
diverge as necessary to comply with Netscape's interests as a company.  I fail 
to understand your point that `mozilla is useless' if it isn't Netscape, but 
since you provide no explanation or anything to back that up, I won't bother 
responding to it.

In reality, if every browser complied to the standards to the extent that 
Mozilla 1.0 and Netscape 6.0 will, these Javascript browser-sniffing hacks 
would no longer be necessary, because everyone would support the same thing.  
That is, of course, in an ideal world.  Someone needs to take a risk and let 
themselves fail these browser-sniffing hacks in the name of standards.  That's 
what we're doing.

I am sorry you feel that Mozilla cannot be used your serious work unless it 
identifies itself as Netscape.  Feel free to use Internet Explorer, the browser 
which, after NS 6.0 and MZ 1.0 are on the market, will basically be the browser 
still forcing the JavaScript-sniffing hacks which are causing you problems.
Status: NEW → ASSIGNED
(Of course, the Javascript-sniffing hacks will probably be around for awhile 
for backwards compatibility.  But the point remains.)
and this is still a problem with Netscape6 [candidate] bits: 1000.30.09/8-n6
commercial branch bits.
59593 is a simple dup of this bug, bug owners should
decide which to keep.

*** Bug 59593 has been marked as a duplicate of this bug. ***
mcaffe: I marked the new bug as a dup of this one because this one has 
more comments.
-> evangelism@telocity.com for my evangelism bugs.

removing the now-depreciated evangelism-related keywords.

setting platform to All.
Assignee: blakeross → evangelism
Status: ASSIGNED → NEW
*** Bug 52643 has been marked as a duplicate of this bug. ***
This if from wellsfargo.com's faq:

Q: How soon can I use a new browser to bank online?

A: Under normal circumstances, Wells Fargo will support the final version of a
new browser approximately two weeks after the final release date

So how is it that Netscape 6.0 which has been out for a couple months now isn't
supported?
The problem here is wellsfargo doesn't want to support Netscape 6/Mozilla
because they don't like that the password manager can not be turned off. They
don't believe that is secure enough for them.
Depends on: 63961
*** Bug 66842 has been marked as a duplicate of this bug. ***
Just  tried to log in and got this wonderful message:

Attention Netscape 6.0 users: At this time we do not support Netscape 6.0
because it does not meet our strict security guidelines. We are working hard to
change this situation and hope to support it soon. Until a solution is found we
suggest using an earlier version of Netscape or Internet Explorer.

Are they really working hard on this?  Has anyone recieved any communication
from them trying to resolve the problem?

re: jelwell's comment on the wallet/password manager... IE has the same thing
right?  They just let you turn it off?  To me "Never remember passwords for this
site" seems like an acceptable policy.  Especially when you consider that most
people's pins for the online banking were set on the phone and are completely
numeric.  

See bug 63961 for an update on this.  The necessary modification was recently 
made to the password manager and that was the crux of that bug report.  The crux 
of this bug report is that Wells Fargo is still rejecting the browser (in spite 
of the fact that it now has the modification they wanted) and that has to be 
addressed as an evangelism issue.
Adding Arun Ranganathan, who is handling Wells Fargo on the Evangelism side.
Status: NEW → ASSIGNED
I've assigned this one to me: I've got correspondence going with Wells Fargo and
in general have this one under control.  Updates soon to follow.
Assignee: evangelism → aruner
Status: ASSIGNED → NEW
Note that there are two issues here.  One of them is the sniffing of the
user-agent string.  The other is the wallet/password manager issue.  The
user-agent string affair seems to have been taken care of.  The latter issue
remains.
The good news: The bank in question approves of an IE like feature to suppress
Password Manager.  This looks like this:
<INPUT TYPE="PASSWORD" AUTOCOMPLETE="OFF">
The 'AUTOCOMPLETE' attribute goes with either the FORM element or any element
contained within the FORM element like the INPUT element.  Password Manager was
the chief bugaboo -- certain banks did not like the implications of using it in
a shared environment.  So, morse landed code that now works with
AUTOCOMPLETE="OFF" -- a feature that matches what online banking institutions
are used to in terms of suppressing autocompletion.  
The bad news: This fix has made it into the latest Moz' builds, but older Moz'
based browsers such as N6 still have this problem.
The chief consolation: There are workaround for N6 and older Moz' browsers
(before Morse landed his code) that suppress Password Manager.  Though these are
hacks, they've been suggested, and we await the response.
Status: NEW → ASSIGNED
Banks can detect different versions of Mozilla and Mozilla-based product by sniffing the Gecko date token.

If the bank in question used one-time pad authentication like Finnish banks, this would be a non-issue.
I'm hoping to have this resolved by the 0.9.2 time frame, if not sooner.  I'm in
correspondence with folks at Wells Fargo, and I'm hoping that this will be taken
care of.
http://www.wellsfargo.com/dhtml_menu.js doesn't properly detect Mozilla/uses layers.
Whiteboard: [BANK][USERAGENT][DENY][PROPRIETARY-DOM]
OK, get this:
Using 0615 Mozilla build, you can get into Wells Fargo.  No problems. Using the
commercial build, Netscape 6.1 PR1, you can NOT get into online banking at Wells
Fargo.  Here's the rub:
Netscape 6.1 b identifies itself to the world as follows --
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1) Gecko/20010607 Netscape6/6.1b1 
Wells Fargo detects Netscape 6.1 beta as "Netscape 0.9.2".  Some highly
erroneous user-agent sniffing at work.
Keywords: ecommerce
*** Bug 92031 has been marked as a duplicate of this bug. ***
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
I can log into Wellsie fine with ns6.1/w2k at this url:
https://banking.wellsfargo.com/
Someone please test with the following:

nscp comm nightly: mac/linux/win
nscp 6.1: mac/linux/win
mozilla nightly: mac/linux/win

I want ot make sure that this works on all of the above before we close 
this out.

Zach
WFM Win32 trunk 2001081003 on Win32 (in other words "Mozilla nightly: win")
Please test with http://www.wellsfargo.com, not with 'banking.wellsfargo'.  Going 
directly to 'banking.wellsfargo' bypasses the browser sniffing code.  Users don't 
do that.

The above WFM was tested from www.wellsfargo.com all the way to my account
history. Everything worked fine.
Linux Mozilla 2001080921 (nightly):
1. load www.wellsfargo.com
2. click on "Wells Fargo Online|Sign On"
3. type in ssn and password
4. click account summary

works for me.
I just tried with Mozilla 2001091203.  Went to wellsfargo.com clicked on Online
banking.  I entered my username and password and it came back with an error:
"Your browser is set to refuse cookies. In order to sign on, you will need to
reset the option in your browser to accept cookies. Then, refresh your screen,
re-enter your SSN and password and select a button to begin banking."

I checked and double checked the cookies setting in Preferences and it is set to
"Enable all Cookies"
Arun's latest symptoms are probably being caused by bug 99286.  Get a later 
build and try that again.
Oops, I meant ejohnson, not arun, in my comment above.
Arun wrote yesterday:
----
Many of you bank with Wells Fargo.  The good news is they've updated 
their site, and they even validate their CSS :-) .  Can anyone spot the 
workaround using CSS to thwart the form fill problem? :-)
You can bank with Wells Fargo without going through any "back door" 
mechanism.  I'm considering us unblocked from Wells Fargo.  If there's 
any further weirdness with Wells Fargo, send mail to me and I'll worry 
some more...  They made fairly large use of proprietary DOM so there 
may be left-overs.
----

Marking FIXED.  Reopen if anything strange happens.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Bug 102888 is another Wellsfargo.com bug. Dupe of this bug?
mass-reassign of all bank bugs to the banks component. You may filter 
for this change by searching for the string 'ilovetriagebecauseitisfun'
Component: US General → US Banks
QA Contact: zach → bclary
Verified
2002030208/WinXP
Status: RESOLVED → VERIFIED
Added to the mozilla financial shames page,
http://blue-labs.org/financial-shames.php
SPAM: New Components
Component: US Banks → English US
*** Bug 290647 has been marked as a duplicate of this bug. ***
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.