523737 - Ally.com never remembers that I've registered my computer with them

Status: RESOLVED WORKSFORME

(Core :: Networking: Cookies, defect)

Description

[u88484]

Ally.com never remembers that I've registered my computer with them.

STR:
1) Go to Ally.com or more specifically https://secure.ally.com/allyWebClient/login.do
2) Type in username, hit continue
3) Fill out information
4) Select the option to register your computer
5) Close browser
6) Repeat steps 1 and 2
7) Get presented with same screen about registering your computer

Comment 1

[Robert Longson [:longsonr]]

The website contains code to stop browsers from doing this. You need to take it up with them.

		function disableAutocomplete() {
			var formElement = (document.getElementById) ? document.getElementById("noautocomplete") : ((document.all) ? document.all["noautocomplete"] : null);
			if (formElement) {
				formElement.setAttribute("autocomplete","off");
			}
		}
		addLoadEvent(disableAutocomplete);

Comment 2

[u88484]

That is for auto completion of input fields.  I'm talking about the portion that asks if I want to register my computer with ally.com so that way I bypass the security questions each time I login.  I'm assuming this is supposed to set a cookie and it keeps getting deleted when I shutdown the browser.  I do not have any history clearing options set.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Did this work in Firefox 3.5? Can we get a regression window?

Comment 4

[u88484]

Works with 3.5.5 and 3.6b3 but does not work with trunk even after spoofing the UA.  So this is caused by something that did not land on the 1.9.2 branch.

Changing to ALL now that I'm on Windows 7 64 bit.

Comment 5

[u88484]

I was wondering why I had requested blocking if it worked in the branch and so I went back and tested.  It does work in 3.5.5 and does NOT work in 3.6b3, latest branch or the trunk nightlies.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Maybe this was caused by the localStorage changes? cc'ing Jonas ...

Kurt: you seeing this on any other site?

Comment 7

[u88484]

This is the only site that I have an issue with and I have a few banking sites that require the same type process with registering my computer.  If someone can point me to some bugs that may have caused this, I will download the before and after nightlys to find the regression window.  I don't think I'll have time for at least a week or two to randomly download builds to find the regression window.

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

cc'ing Honza Bombas as well, who made changes to localStorage in Firefox 3.6, IIRC. Honza, can you take a look at this and see if it's related to those changes?

--> Core

Comment 9

[Boris Zbarsky [:bzbarsky]]

Kurt, can you use nightlies to figure out when the problem appeared?

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

I put this in cookies because I don't know where localStorage bugs go, and until we confirm that the site is using localStorage, it would appear to be a cookie problem.

Comment 11

[u88484]

Attachment: Source code

Here is the source code for that page.

(In reply to comment #9)
> Kurt, can you use nightlies to figure out when the problem appeared?
Yes, I think it will take a week or two until I can randomly download nightlys to figure out the regression range.  If someone can get me some kidn of clue of where to start I can do it asap.

Comment 12

[Boris Zbarsky [:bzbarsky]]

That source doesn't really tell us what they're doing (esp in all those external scripts).

Binary search on nightlies since 3.6 branched should take about 7 nightly downloads, right?

Comment 13

[u88484]

I went through at least 30 builds as far back as June of 2008 and couldn't reproduce it.  I then used the profile I created for the Jan 01 build and used it with the Feb 01 build and could reproduce it each and every time. Same thing happens when I go back to june of 2008.

So I can't reproduce with a new profile using the same build but at soon as I use the profile with another build, I can reproduce it each and every time. That explains my comment in the bug yesterday where I couldn't reproduce with 3.6 and then upgraded it to the latest nigtly and then could reproduce.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Ah, so if you try a clean profile with a current nightly things work but then if you use the same profile with a 3.5 build (say) it's broken?

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Do you have any addons installed in this profile? Could you try disabling them to see if that makes a difference?

Comment 16

[Honza Bambas (:mayhemer)]

Kurt, it's not very clear on which build and which profile (what is history of that profile, i.e. what all versions of firefox you were using that profile with) you CAN reproduce the problem.

If the hypothesis with localStorage difference for 1.9.2 and newer branches is true, then it could be a bad database update that causes some bug we are not aware of or it might be a a dom quota exhaustion (you don't have space to store data).

Did you check the error console if there were not any report?

Comment 17

[u88484]

Ok, lets try putting all information in one comment now that I have more information.

The below was reproduced using a new profile on the 11/23/2009 trunk build.

STR with a new profile:
1) Go to Ally.com or more specifically 
https://secure.ally.com/allyWebClient/login.do
2) Type in username, hit continue
3) Answer secret question
4) Select the option to register your computer then hit submit
5) Type in my password, submit
6) Click log out or just close browser
7) Repeat steps 1 and 2..no secret question prompt screen, no prompt to register my computer.  I get to bypass that and just enter my password.
8) Can repeat 1-2 as many times as you wish
9) Update to the 11/24/2009 build
10) Repeat steps 1-2, now I get the secret question prompt screen and i'm asked if I'd like to register my computer.
11) Use profile with the 11/23/2009 build, continually get asked to register my computer

The same things happens when I use a new profile with the 06/01/2008 build and then use the same profile with a 06/02/2009 build.

So basically I can't reproduce this without updating to a newer build or using a profile and going back to a different build.

Comment 18

[u88484]

(In reply to comment #17)
> The same things happens when I use a new profile with the 06/01/2008 build and
> then use the same profile with a 06/02/2009 build.
should be 06/02/200_8_ build.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Does the same thing happen if you create a profile with 3.0.x and then do steps 2-6 and then update to 3.5.x?

Does clearing the site's cookies after step 10 help?  If so, what cookies are they storing?

What about spoofing the UA of the build that used to work?

Comment 20

[u88484]

(In reply to comment #19)
> Does the same thing happen if you create a profile with 3.0.x and then do steps
> 2-6 and then update to 3.5.x?
Works.  I tried using a 3.0.15 build did all the steps above, checked for update and updated to 3.5.5.  Still working correctly, I have not been asked to register my computer.

> Does clearing the site's cookies after step 10 help?  If so, what cookies are
> they storing?
I'll try that in a little while
 
> What about spoofing the UA of the build that used to work?
Spoofing the UA as in setting it to Firefox/3.0.15 since I can't reproduce this using 3.0.15?

Comment 21

[u88484]

(In reply to comment #20) 
> > Does clearing the site's cookies after step 10 help?  If so, what cookies are
> > they storing?
> I'll try that in a little while
> 
Yep, that fixes the issue.  Just to double check, I'll update to tomorrows build with this profile and do the same thing.

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This is sounding more and more like a website bug. Minusing for now, though please do renominate if data indicates otherwise.

Comment 23

[Boris Zbarsky [:bzbarsky]]

> Spoofing the UA as in setting it to Firefox/3.0.15

No, setting it to the 11/23 trunk build's UA while running the 11/24 trunk build.

> Yep, that fixes the issue.

OK.  What cookie names/values do they set?

Comment 24

[u88484]

(In reply to comment #23)
> OK.  What cookie names/values do they set?
I don't see any listing for values for any cookies.

Comment 25

[Honza Bambas (:mayhemer)]

And what about the UA spoof as bz suggests in comment 23: "setting it to the 11/23 trunk build's UA while running the 11/24 trunk build" ?

Be careful to have it exactly char by char. It seems that the site is using the UA string to check identity of your computer somehow.

Comment 26

[Boris Zbarsky [:bzbarsky]]

> I don't see any listing for values for any cookies.

If you go to Preferences > Privacy, click the "Show Cookies" option, then scroll down to the site in question (or filter for it) and click on a cookie, the "Content" value in the pane below the cookie tree is what the cookie is set to.  Or are you saying all those are the empty string for this site?

Comment 27

[u88484]

(In reply to comment #23)
> OK.  What cookie names/values do they set?

First line is the name, second is the value.  The ones that are duplicates have different paths.

BIGipServerpool.fi.consumer-live-prd.gmacrescap.com.7281
3706880778.28956.0000

TLTSID
2FWFxUe4Z8MJn8jcBe3W3Q==

BIGipServerpool.fi.consumer-live-prd-static.gmacrescap.com.8000
3706880778.16415.0000

TLTSID
2FWFxUe4Z8MJn8jcBe3W3Q==

TLTSID
2FWFxUe4Z8MJn8jcBe3W3Q==

ally_tealeaf
true

mbox
check#true#1264794590|session#1264794511743-666123#1264796390

s_pers
%20s_nr%3D1264794529734-New%7C1267386529734%3B%20s_uid%3D519984%7C1295898529735%3B

s_sess
%20s_cc%3Dtrue%3B%20s_sq%3D%3B

PMDataa15d6b39af0f1c5fda8db8888a49fad3
PMV2CvJt0PjSAHzIiYX9+kB1d77M5/6lUW5VIk+DavHuGuvVxPA854HRaxPofpNKx6MTo8VU/y7Hyuw74m6mZzYun7326d62/H3J7XgH4cw4SZW7j1DUQamUQlZUL63hZ5FuvI

JSESSIONID
0BA8B03A8D7F5B53CF8A9FA34AD5A15E

expandable
0c

subexpandable
-1c

Comment 28

[u88484]

Attachment: Cookies names and values

First build - new profile, registered with it, recorded the cookies
Second build - new profile, registered with it, recorded the cookies

Launched the first build using the profile from the second build - Asked to register again.  Opened about:config and spoofed the UA to that of the second builds.  Successfully logged in without needed to register my computer.

Diff of the cookie names/vaules: http://pastebin.mozilla.org/?diff=700316

Comment 29

[Boris Zbarsky [:bzbarsky]]

What were the actual UA strings for those builds?

Comment 30

[u88484]

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100127 Minefield/3.7a1pre

and

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100128 Minefield/3.7a1pre

Comment 31

[Boris Zbarsky [:bzbarsky]]

Hmm.  I feel like I'm solving a crypto problem.  ;)  There are several base-64-encoded binary blobs in those cookies, and at least one md5 checksum.  Checksum of what, I don't know; it's not a checksum of the UA string, which was my guess.  :(

But it certainly sounds like they're just baking the UA string into the cookie... have you tried contacting them about this?

Comment 32

[u88484]

Kurt: It saves a cookie based on the User Agent of the browser. Anytime Firefox users upgrades, the cookie no longer matches the UA and the user has to once again register the computer.

Laura: Yes. That will happen with Firefox.

Laura: Firefox is compatible with our web site but you will need to register the site every time Firefox upgrades. It has to do with the security between Firefox and Ally site.

Laura: This does not happen with Internet Explorer.

Kurt: well IE only updates every few years ;)

Kurt: ok thanks, I partially understand what your saying. Could you please pass the bug report unto the devs though?

Laura: I will but this is not something new. We do appreciate you taking the time to notify us though.

Comment 33

[Boris Zbarsky [:bzbarsky]]

Right.  Well, I'd love to hear what "the securiyt between Firefox and Ally site" is in this case... please feel free to give Laura my e-mail?

Comment 34

[u88484]

I meant to put at the top there that she was just a live chat customer support agent so I didn't expect anything technical out of the conversation.  Seems they know the issue with Firefox and Ally.com and she said she will send this bug report to their devs.  She started off sounding like she knew what she was talking about but then she started going into asking me to change my cookie settings through internet explorer's options lol...I left.

I'll write up an email tomorrow and see how that goes.

Comment 35

[u88484]

They fixed this issue at least six or seven months ago.  I haven't had an issue with the site since.

Comment 36

[Dave]

I still have this issue.. anyone else?

Comment 37

[Joshua Mitchell (Inactive)]

Issue is resolved - clearing old keywords - qa-wanted clean-up