171235 - cookies not recognised at meine.deutsche-bank.de

Status: VERIFIED WORKSFORME

(Tech Evangelism Graveyard :: German, defect, P2)

Description

[Joseph Doer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20020927 Netscape/7.1 (AOL 8.0RC2)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20020927

I open this bug regarding the Comments:
     bug 165681 comment 13 
     bug 169091 comment 6

With the latest Trunk Builds incl. Build-ID 2002092704 I get an Error that the
Cookies are disabled but I enabled all Cookies and get no difference with it.
Result: I can't access the HTTPS page.

The URL is the german "Deutsche Bank"
https://banking.db24.de/mod/WebObjects/db24 or/and
https://banking.db24.de/mod/WebObjects/db24.woa
(there is also an link to an english version of the page on the upper left)

This works for the 1.0.x (latest Trunks) and 1.1 (so far I remember) lines but
not any more for the 1.2 Trunks.


Reproducible: Always

Steps to Reproduce:
Simple accessing the page with all activated cookies:
1. http://www.deutsche-bank-24.de/
2. Klick upper left link "Kunden-Login"
3. Window opens


Actual Results:  
It says that the Cookies are not activated but they are.

Expected Results:  
accept an hanle the Cookies the right way.

Comment 1

[Stephen P. Morse]

This is probably a consequence of bug 155083, but I won't know for sure unless
someone lists the actual set-cookie header showing what path attribute (if any)
was specified and what path the requesting URL was on.

Comment 2

[Stephen P. Morse]

Patch for bug 155083 has been backed out.  This site should now be working

Comment 3

[Joseph Doer]

I'm sorry, but it continues not to work for me. :(
I checked it with the latest trunk build 2002100308

Comment 4

[Stephen P. Morse]

You are correct -- this is not fixed.  It had nothing to do with the cookie path
test.  Furthermore, this is not a new bug but one that's been around for quite a
while -- it's in the N7 release.

Comment 5

[Stephen P. Morse]

Cookie logging shows that no cookies have been rejected.  The site has sent two
cookies and the browser accepted both.

0[8c2a70]: ===== ACCEPTED COOKIE =====
0[8c2a70]: request URL: https://meine.deutsche-bank.de/mod/WebObjects/dbpbc
0[8c2a70]: set-cookie: ID_STR=2814219361869; version="1"; path=/mod/WebObjects/dbpbc
0[8c2a70]: current time (gmt): Fri Oct 04 05:27:09 2002
0[8c2a70]: ----------------
0[8c2a70]: name: ID_STR
0[8c2a70]: value: 2814219361869
0[8c2a70]: host: meine.deutsche-bank.de
0[8c2a70]: path: /mod/WebObjects/dbpbc
0[8c2a70]: expires (gmt): at end of session
0[8c2a70]: is secure: false
0[8c2a70]: 
0[8c2a70]: ===== ACCEPTED COOKIE =====
0[8c2a70]: request URL: http://www.deutsche-bank.de/pbc/content/pu_txm_browser.html
0[8c2a70]: set-cookie: SecurePopup=zeigen;expires=Sun, 03 Nov 2002 05:27:14
GMT;path=/pbc
0[8c2a70]: current time (gmt): Fri Oct 04 05:27:14 2002
0[8c2a70]: ----------------
0[8c2a70]: name: SecurePopup
0[8c2a70]: value: zeigen
0[8c2a70]: host: www.deutsche-bank.de
0[8c2a70]: path: /pbc
0[8c2a70]: expires (gmt): Sun Nov 03 05:27:14 2002
0[8c2a70]: is secure: false
0[8c2a70]: 

Comment 6

[Jon Levell]

I'm not sure whether this is the same bug or completely different but Mozilla no
longer works with LloydsTSB (UK Bank) either. Login URL:
https://online.lloydstsb.co.uk/customer.ibc
Although I can log in everytime I do something it ask me for my username and
password again, as if the cookie has not been stored. I can reproduce this bug
in 1.2alpha (on linux Redhat 7.3), and the latest nightly but not with Mozilla
1.1 with the same profile. 
I understand it'll be hard to test this without a Lloyds bank account, I guess
I'll have to go through old nightlies and try and locate the build where it
stops working!...Won't get a chance to do that for a few days though.

Comment 7

[Stephen P. Morse]

Please open a separate bug report on the Lloyds problem.

Also if you can attach a cookie log for that problem it would be helpful.  That
will require your applying the patch in bug 171507.

Comment 8

[Stephen P. Morse]

Correction -- this site works fine with the N7 release.  Don't know why I
thought that it didn't yesterday.

Since this is an https site, I can't do any traffic sniffing to see where things
differ between N7 and the current trunk build.  But I did add some more cookie
logging to see exactly what the current trunk is doing.  Specifically I see the
following:

- accept cookie SecurePopup from www.deutsche-bank.de
- send SecurePopup cookie on a request to 
     www.deutsche-bank.de/pbc/images/content/pu_header_db_620.jpg
- accept cookie ID_STR from meine.deutsche-bank.de with path attribute of
     /mod/WebObjects/dbpbc
- several requests are then made to 
     meine.deutsche-bank.de/WebObjects/dbpbc.woa/...
- no cookies are sent with these requests since it does not satisfy the
     path attribute of the saved meine.deutsche-bank cookie

So is the site expecting these cookies to be sent?  If so, the error is on the
site.  But why then is it working in N7?  I don't have the answer to that and am
still investigating.

Comment 9

[Stephen P. Morse]

No, the problem is not that the site is expecting the cookie.  I tried
commenting out the path test so that the cookie will be sent to the site and it
made no difference.

Wondering if this is something other than a cookie problem.

Comment 10

[Stephen P. Morse]

Correction to correction.  I was right in comment 4 and wrong in comment 8 --
this does not work in the N7 release version.  So this bug has been around for
quite a while.

Furthermore, reporter says that he gets a message saying "cookies are not
activated on this site".  That's not the message I am seeing.  According to
babelfish, the message says:

   Safety reference If you have at present problems with the access on the 
   on-line Banking and Broking of the German bank, the safety standard of
   your Webbrowsers is probably not sufficient. Their Browser supports then
   no coding pattern, which corresponds to the requirements of this web page.
   This side requires a strong coding pattern. In order to be able to use the
   on-line Banking and Broking of the German bank, you try please the
   following:
      1. Install the newest in each case version of your Browsers, so that
         all new coding patterns are supported. The following Browserversionen
         was tested successfully with our InterNet Banking and Broking and
         makes a safe connection possible
    ...

Comment 11

[Stephen P. Morse]

OK, it's an evangelism problem.  Site is intentionally blocking us.  This can be
demonstrated by spoofing the user-agent string to say that we are N4, in which
case we do not get this bad message from the site.

To spoof the user-agent string, add the following line to your prefs.js file:

   user_pref("general.useragent.override", "Mozilla/4.75 [en] (Win95; U)");

So cookies have nothing to do with this.  Reassigning.

Comment 12

[Joseph Doer]

Well, to the N7 thing. It works for me with N7 _and_ all trunks I tested from
the 1.0.x tree. It don't works for Phoenix 0.1/0.2/later and the 1.2 trunks.

And here an URL change. Since the "Deutsche Bank 24 AG" changed her name on
01.10.2002 to "Deutsche Bank Privat- und Geschäftskunden AG" a new direct URL is
needed: https://meine.deutsche-bank.de 
To get the english version click on the upper left link in the corner "English
Version" on that page.

If I try to log in I get this:
"...We tried to place a cookie on your computer to ensure that your Transaction
Manager is closed automatically when you close your browser. This cookie helps
you make use of all security measures offered by the Transaction Manager. It
will automatically be deleted from your PC as soon as you end your session.  To
use the Transaction Manager, you must activate the acceptance of cookies in your
browser.Please set your browser to accept cookies and then click here
<https://meine.deutsche-bank.de/mod/WebObjects/dbpbc> ..."

I'll add two Screenshots of Success on N7 and Error on Mozilla1.2

Anyway I have a Mozilla Browserstring which identifies Mozilla as a fictive N7.1

Comment 13

[Joseph Doer]

Attachment: Netscape 7 Successfull access

Comment 14

[Joseph Doer]

Attachment: Mozilla 1.2 trunk Error Access

Comment 15

[Joseph Doer]

OK, I check that with the user agent string.. nope. It won't work. I tried these
both:
user_pref("general.useragent.override", "Mozilla/4.75 [en] (Win95; U)");
user_pref("general.useragent.override", "Mozilla/5.0 (Windows; U; Windows NT
5.0; de-DE; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-Yabba)");
Neither one of them had any (better) effect.

The page sets three cookies which I added as Screenshot.
My Cookiebehavior are the following (from pref.js):
user_pref("network.cookie.cookieBehavior", 0);
user_pref("network.cookie.lifetime.enabled", true);
user_pref("network.cookie.warnAboutCookies", true);

I selected to access all Cookies with a lifetime for the actual session.

Comment 16

[Joseph Doer]

Attachment: Mozilla 1.2 Cookie Nr. 1

Comment 17

[Joseph Doer]

Attachment: Mozilla 1.2 Cookie Nr. 2

Comment 18

[Joseph Doer]

Attachment: Mozilla 1.2 Cookie Nr. 3

Comment 19

[Jacek Piskozub]

Germany is Europe: West (at least according to mozilla.org)

Reassigning.

Comment 20

[Stephen P. Morse]

OK, with the new URL given in comment 12 I am able to get the cookie-error
message.  I will investigate further and reassign the bug back to myself.

And whatever made Netscape think that Germany is in West Europe instead of
Central Europe! ;-)

Comment 21

[Stephen P. Morse]

I see the problem.  There is an error on the site as to how they expect cookies
to be handled.  If we handled cookies they way they wanted, we would be open to
a cookie-stealing attack.  So this once again becomes an evangelism but not for
the reason that I gave in comment 11.

The site is setting the following cookie:

   name: ID_STR
   value: 4356913497526
   host: meine.deutsche-bank.de
   path: /mod/WebObjects/dbpbc
   expires (gmt): at end of session
   is secure: false

Then several requests are made to

   https://meine.deutsche-bank.de/WebObjects/dbpbc.woa/Contents/...

and the cookie is not sent.  That is correct behavior because the above site is
clearly not on the /mod/WebObjects/dbpbc path.  And this is not what is causing
the problem.

Then a request is made to

   https://meine.deutsche-bank.de/mod/WebObjects/dbpbc.woa/471/wo/...

Now that is not on the /mod/WebObjects/dbpbc path either, although it could be
considered to be so if a faulty path test were made.  And we were making such a
faulty path test at one time but that was corrected by the patch in bug 166218.
 If I back out that patch, the site works fine.

Comment 22

[Joseph Doer]

Comment 21 sounds very logic. I wrote an email to the administration. I hope
they'll check it out. :-)

Comment 23

[Stephen P. Morse]

A little more clarification.  If we backed out the patch for bug 166218, that
clearly fixes the problem with the deutchebank site.  But then we would have the
problem reported in bug 166218, and the reporter of that bug report said that
his problem did not occur on IE.  So I did some more experimenting to determine
just what sort of test IE was making.  It turns out that IE will accept a period
as the end of a path name whereas the only characters we accept as the end of
the path name are '/', ';', '#', and '?'.  So if I modify the code in
nsCookies.cpp that reads:

      if (pathLen>cookiePathLen && 
          path[cookiePathLen] != '/' && path[cookiePathLen] != '?' &&
          path[cookiePathLen] != '#' && path[cookiePathLen] != ';') {

to instead read

      if (pathLen>cookiePathLen && 
          path[cookiePathLen] != '/' && path[cookiePathLen] != '?' &&
          path[cookiePathLen] != '.' && 
          path[cookiePathLen] != '#' && path[cookiePathLen] != ';') {

then this deutchebank site works fine.

But I will argue that this is the wrong thing to do.  It simply defeats the
purpose of the path test when sending cookies.  If we allowed this, then it
means that an attacker could steal the cookies of a site on a public server by
simply getting the same account name but with a ".xxx" suffixed to it.  For
example, suppose I am running a business at mywebpage.netscape.com/acme and I
set cookies with the path of "/acme".  Now my competitor wants to see my cookies
so he opens a netscape account with the username of acme.plus, so that now his
homepage is mywebpage.netscape.com/acme.plus.  Whenever one of my acme customers
visits my competitor's site, my customer's acme cookies will come be delivered
to my competitor.

Note that the classic example given for this sort of attach usually involves
geocities.  But by showing that netscape.com has the same problem makes it hit a
little closer to home.

Reassigning to evangelism (again, but for a different reason) to get deutchebank
to fix their site.

Comment 24

[Joseph Doer]

OK, I understand the problem and absolutly agree with you.
But am I right that this problem you mention is not yet fixed/changed in the N7
nor in the M1.0 tree? Shouldn't it?

Comment 25

[Stephen P. Morse]

The patch for bug 166218 was checked in on Sept 15 2002.  So that would not be
in the N7 or 1.0 tree and deutchebank website should behave fine with those builds.

Comment 26

[Joseph Doer]

That's right. Till now both builds are working with the website of Deutsche Bank.

I got an answer from the E-Mail-Service with a lot of blabla ("yes we care
but..") which says that they can't give a timeframe on which they care about and
change it.. :(

Comment 27

[Stephen P. Morse]

*** Bug 174011 has been marked as a duplicate of this bug. ***

Comment 28

[Daniel (Leaf) Nunes]

I'm getting a similar behaviour at tmobile's website:
http://www.tmobile.com/locator.asp?referer=/plans/Default.asp
(should a separate bug be filed for evangelism for that site?)

Comment 29

[Stephen P. Morse]

Yes, please do file a separate bug.  This one is well understood and has to do
with specific error on the deutchebank site.

Comment 30

[Stephen P. Morse]

*** Bug 175961 has been marked as a duplicate of this bug. ***

Comment 31

[Stephen P. Morse]

Fixing summary so it can be found by a search.

Evangelists, this one is pretty important and we are getting dups of it.

Comment 32

[Stephen P. Morse]

*** Bug 176488 has been marked as a duplicate of this bug. ***

Comment 33

[mr_tob]

with 1.2a the deutschebank page worked fine...
with 1.2b the page shows the already posted error message.

I reported that bug to the bank, aswell.
and didn't get any answer... another reason to change the bank

Comment 34

[Joseph Doer]

Totally my opinion: _another_ reason more.. :-/

Comment 35

[Deti Fliegl]

This is what Deutsche Bank replied:
"Der von Ihnen genannte Fehler ist uns bekannt und betrifft insbesondere die
Version 1.2b von Mozilla, bei der die gesendeten Cookies nicht korrekt
verarbeitet werden. Unsere Techniker arbeiten an dem beschriebenen Fehler,
einen konkreten Zeitpunkt bis zur Wiederherstellung einer einwandfreien
Funktionsweise koennen wir Ihnen gegenwaertig jedoch nicht benennen."

English summary: We know about that problem. Our technicians are concerned with
it, but we cannot tell when it will be fixed.

Comment 36

[Joseph Doer]

Well, the correct translation should be:
"We know about the error which is only located on esp. Mozilla 1.2b (see my
Comment 22 and Comment 26) and that Mozilla is not handling the Cockies is the
right way. Our technicas are working on it but we can't give you a timeframe
until it would work again the right way."

So, now they know about a month from that their page has an error concerning the
Cockie handling. And they keep saying that the error was Mozilla who it has, not
their page... Their online banking was never the best, but their service for
their online banking is worse. So we say: "Schade!" :-(

Comment 37

[Stephen P. Morse]

*** Bug 178650 has been marked as a duplicate of this bug. ***

Comment 38

[Stephen P. Morse]

*** Bug 182393 has been marked as a duplicate of this bug. ***

Comment 39

[matteo porta]

from what i understand mozilla behaviour is correct (but the bank site doesn't 
work) while ie is wrong because of security hole (but the site works).
if someone reports to microsoft that there is this security hole then maybe 
they'll fix it. then the bank site will not work anymore with ie, just like 
mozilla. in this case i'm sure the bank programmers will fix the problem much 
faster...
in the end the site will work for both browsers :-)

Comment 40

[Thomas Ganter]

OK, you evangelists, I do not know whether this might help you, but for those
Deutsche Bank guys the problem is easily fixed. 

Since they are using WebObjects, the cookies are created using the WOCookie
class, which has a 'setPath()' method. The straightforward approach for those
trained individuals thus would be to grep for 'setPath' and correct their
arguments there. 

If they are not capable of doing so, I would be very much willing to help them. 8^)

Comment 41

[Mathieu Pillard [:mat]]

Thomas, feel free to contact them with the fix. would be better if you could do
this in german :)
(note: btw, that would need a contact, which we do not have... yet :)

Comment 42

[Thomas Ganter]

OK, 

I sent them a detailed Problem description (once more... 8^) along with an offer
for free-of-charge assistance in fixing their obvious WebObjects problem. 

BTW, I used their HTML contact form for the lack of an direct email address.
Does anyone have a contact mail address I could use to flood with additional
messages?

- Thomas

Comment 43

[Marc]

Thomas, you might want to try "[e-mail]". This is the e-mail
address from which I got some replys in 2001 when I was complaining about some
other problems with Deutsche Bank online services. But maybe this address is not
valid anymore.
Thanks alot for looking after this. I have complained about this issue in their
HTML contact form yesterday, too.

Comment 44

[Stefan Moebius]

According to this article: http://www.apple.com/de/smallbusiness/local/db24/
the responsible person is Michael C. Koch, Leiter Internet Technology &
Infrastructure. (Note the "smallbusiness" in the URL, *grin*)

However, I was unable to find this person, or even the departement using DB's
search engine. Maybe this information is outdated.

Using the default e-mail scheme, his address should be [e-mail],
maybe you could try this.

Comment 45

[Stefan Moebius]

Marc (and anyone else who got any response from them), did the mails contain any
names or names of departement that we could dig after?

Comment 46

[Marc]

The e-mails I got from Deutsche Bank had addresses "[e-mail]" (on
2001-07-17 and 2001-10-04) and an old one had
"[e-mail]" (dated 2000-01-07). The most recent one was
signed by "Ruediger Geist" who seemed to know some technical details. The one
from July 2001 was signed "Silvia Hilgartner" but this lady only told me to call
their hotline and didn't seem to have technical background.

Comment 47

[Torben]

*** Bug 182617 has been marked as a duplicate of this bug. ***

Comment 48

[Sven C. Berger]

The latest generic e-mail address is <[e-mail]>.

The address of Thomas-C Koch is probably totally outdated, better not to use it
for complaints.

Comment 49

[Thomas Ganter]

8^)

Some minutes ago, I got called by Deutsche Bank through my telephone at work. I
once more stressed the point that the problem is not on our side but on theirs,
and that I know how to fix it. 

Right this very second while writing here, my Notes popped up and I was CC-ed
when the person I talked with forwarded all communication to someone whose
capacity I can only guess as being in charge of creating a task force: "[...] Do
you see a possibility to install a task force [willing to approach the problem.
...]" (my translation)

I'll keep you updated. 

- Thomas

Comment 50

[Alexander Skwar]

I just called the Deutsche Bank, and the lady from the DB told me, that the
problem is known and being worked on.  She couldn't give me any timeframe about
when the problem will be fixed.

Comment 51

[Felix Miata]

*** Bug 183149 has been marked as a duplicate of this bug. ***

Comment 52

[Marc]

Deutsche Bank added this to their browser info today (or yesterday):
"Wichtiger Hinweis: Bitte benutzen Sie Mozilla Version 1.1! Auf Grund eines
geänderten Cookie-Handlings ist die Nutzung des db OnlineBanking mit Mozilla 1.2
zur Zeit nicht möglich."
In English: "Important notice: Please use Mozilla version 1.1! Due to different
cookie handling it's not possible to use db Online Banking with Mozilla 1.2 at
this point."
They seem to be aware that it's their problem, otherwise they would most likely
say that it's a bug in Mozilla 1.2. Let's hope that they really work on it.

Comment 53

[Thomas Ganter]

Of course they know that there is a problem, and since they can read, they know what the 
reason is. At least, this is a public forum, and we never got tired including a link to this 
thread. 

As for my current inquiries, no further comments from Deutsche Bank as of COB today. 

Hm, perhaps I will wait another day and then call my personal private banking advisor 
again that his internal escalation was fruitless. 

- Thomas

Comment 54

[Stephen P. Morse]

*** Bug 183549 has been marked as a duplicate of this bug. ***

Comment 55

[Felix Miata]

*** Bug 183886 has been marked as a duplicate of this bug. ***

Comment 56

[Thomas Lehmann]

A quick search with google results in one netscape document specifying cookies.
http://wp.netscape.com/newsref/std/cookie_spec.html
Under "Specification | path=PATH" the following is stated:
"/foo" would match "/foobar" and "/foo/bar.html"
This is contrary to the statments mentionend above.
Maybe this document is outdated, but I couldn't find any current specification.
Is there any?

Comment 57

[Stephen P. Morse]

That spec is hopelessly out of date and blatantly wrong.  The spec you want is
RFC2109.  Do a search on that.

Comment 58

[Thomas Ganter]

Hi everybody. 

After I was in some contact with Deutsche Bank, here is what I think is the
status:  

Deutsche Bank recognises the problem, and supposedly knows how to fix it (or
even has it fixed already in their internal systems - dunno). 

Unfortunately, following the 'never change a running system' paradigm and due to
the overhead that would be caused by releasing a new software version to the
production system, it is very unlikely that the fix will find its way onto the
live system anytime soon. 

There simply currently is no business case for all the effort going through
thousands of test cases and stuff. 

Eventually, some future release should include the fix. 

Again, this is my impression from the statements I learned. Unless someone can
think of a 'cool' way to increase the business value for them of fixing it (call
for a donation maybe?), I guess we will have to live with it, which means that I
will not be using Deutsche Bank Internet Banking until it is fixed. 

- Thomas

Comment 59

[Stefan Moebius]

I filed bug #186015 for a related issue at netbank.de.

Maybe we should contact Apple to make them issue a 'security advisory' for their
customers. I guess that would increase the 'business value' ;-)
Or maybe this even is a bug in WebObjects?

Comment 60

[Andreas Lorenz]

Isn't it possible to include an option into the current and new mozilla releases
to use the old cookie handling? Currently I have to chosse between using Mozilla
1.1 and being able to access online banking, or using a new mozilla release.

Since the mozilla project is more flexible than the folks at Deutsche Bank, I
think that this is the more reasonable solution for now.

Comment 61

[Boris Glawe]

!!! It works for me with mozilla 1.3a !!!! It has not worked with this version
before... so something has changed.. sometimes it still does not work... but if
I try to login twice or three times, it works... !!!? strange server... but
better it refuses access than granting access due to a wrong browser version :-)

Comment 62

[Christian Assig]

I just logged in succesfully with Mozilla 1.2.1 on first try.
But when I clicked on a link after the login, the navigation part of the
frameset was gone. Pretty annoying, but at least the login works again (for me).

Comment 63

[Joseph Doer]

Hurra! It seams to be fixed right now by Dt. Bank. :)
It works for me on Mozilla 1.3b (latest Trunk), too.
I think this Bug is close to get closed... only a few days to be shure. :)

Comment 64

[Brant Gurganus]

RESOLVED WORKSFORME 2002121408 per recent comments.

If problems continue to be gone after a few days, please leave a comment or if
you have access, verify this issue is resolved yourself.

Comment 65

[Stefan Moebius]

WFM as well. 

The ID_STR cookie now has path=/mod/WebObjects/dbpbc.woa

Comment 66

[Frank]

Works for me too using mozilla 1.2.1 - 20021130.

Comment 67

[Frank]

The hints for browser security (and version-support/problems) which are linked
from the login-site have been changed. I don't remember the old text exactly,
but it was something like "use mozilla 1.0[.x]".
The new text is (my translation):
"The following browser versions were successfully tested with our
internetbanking and brokerage and support secure connections: Mozilla (from
Version 1.x)"

Comment 68

[Oliver Schoett]

Now works for me with Mozilla 1.2.1 on Windows XP SP1 and Debian GNU/Linux 2.2
(previously, I had to go back to Mozilla 1.1).

Comment 69

[Peter Schäfer]

WFM, too.
Build ID: 2002111808, Debian GNU/Linux 3.0
I think this can be considered closed.

Good work, guys!

Comment 70

[Brant Gurganus]

VERIFIED WORKSFORME 2002121408

Comment 71

[Frank]

Used today again; extensivly this time. I did transactions, created, changed and
used templates and changed standing orders.
Everything worked fine.
Win2K, Mozilla 1.2.1 Build 20021130

*goodby bug 171235*

Comment 72

[Kai Lahmann (is there, where MNG is)]

move...

Comment 73

[Intermittent Failures Robot]

1 failures in 3323 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 1

Platform and build breakdown:

• linux1804-64-tsan-qr: 1
  • opt: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=171235&startday=2022-03-28&endday=2022-04-03&tree=all