633868 - Regression: chipTAN flicker code broken

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[will69]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110213 Firefox/4.0b12pre

Several major German banks (like Sparkasse and Postbank) are migrating their customers from the PIN/iTAN system to the new chipTAN system. This system involves a hardware TAN generator used to authenticate transactions. The device is held against a flicker code on screen and receives the transaction data via five optical sensors. See http://www.kobil.com/fileadmin/Documents_2009/Video/DEMO_CHIP_TAN.swf for a demonstration.

This works very well with Firefox 3.6.13 (both Windows and Linux).
It works much worse with Firefox 4 on Windows (several tries necessary).
It fails completely with Firefox 4 on Linux.

Reproducible: Always

Steps to Reproduce:
1. Disable Flash
2. Visit https://bankingportal.sskduesseldorf.de/portal/portal/StartenIPSTANDARD
3. Click "Demokonto Online-Banking" on the left hand side
4. Click "chipTAN testen" in the middle
5. Login with demo account (id and password given on top)
6. Click "Überweisung" in the middle
7. Click "Empfängerdaten" on the left hand side
8. Click the Euro symbol on the "Tina Test" account
9. Enter an amount and click the "Weiter" button below
10. The flicker code is displayed
11. If you have a device available: Try to read the code
12. If not, observe the flickering of the leftmost bar
Actual Results:  
The display update is erratic, the leftmost bar flickers much more slowly in Firefox 4. The code is not recognized by the device on Linux (openSUSE 11.3). The code is only recognized by the device after an extended period of time on Windows XP. The problem can be reproduced on different hardware.

Expected Results:  
The display update is so fast that the leftmost bar almost seems gray. The code is recognized by the device immediately.

There are two workarounds:

1. Install and enable a Flash plugin
2. Circumvent the flicker code by manual data entry on the device keyboard

Method 1 will be used reluctantly by security-aware customers.
Method 2 is cumbersome and error-prone.

Comment 1

[Matthias Versen [:Matti]]

>11. If you have a device available: Try to read the code
My device reports "transmission successful" with Seamonkey trunk on win7 with or without flash but it often retries the transmission one time without.

The difference is difficult to see on win7. It's not possible for me to find a regression range with such a small difference.

Reporter: Would you help to find the regression range ?
You have to download multiple nightly builds and test them.

Comment 2

[will69]

Regression range:

GOOD: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091231 Minefield/3.7a1pre

FAIL: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20100101 Minefield/3.7a1pre

Comment 3

[Matthias Versen [:Matti]]

I need the build revision from both builds that you can see in about:buildconfig
An example is "Built from http://hg.mozilla.org/mozilla-central/rev/26421a3b68f3"

The date is interesting, i hope it's not some stupid UA sniffing

Comment 4

[will69]

Build revisions:

GOOD: http://hg.mozilla.org/mozilla-central/rev/6d56925adfd5
FAIL: http://hg.mozilla.org/mozilla-central/rev/cb5a303025fe

Comment 5

[will69]

If JavaScript is disabled, the flicker code is displayed as an animated GIF.
This works, but is not really practical, because it also kills the UI for
zooming the graphic to the right size and would require a plugin like NoScript.

The leftmost bar of the flicker code is a clock signal, btw. See also:
http://6xq.net/html/00/20.html (German)

Thus it may be important that the five bars reach their desired display state
simultaneously.

Comment 6

[Matthias Versen [:Matti]]

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6d56925adfd5&tochange=cb5a303025fe

Boris: I hate it to steal your time but can you help here ?

Comment 7

[Boris Zbarsky [:bzbarsky]]

What flicker frequency does this thing expect to get?

will69, thanks for the detailed steps to reproduce.  Unfortunately, visually the flicker looks about the same to me on trunk and on branch and I don't have a device to test.  But if you're willing to experiment a bit....  what happens if you set the "layout.frame_rate.precise" preference to true in about:config?

It looks like the page is toggling style.visibility from hidden to visible on the images in question to create the flicker; it should all be happening at once (off the refresh driver), so the simultaneous display issue raised in comment 5 should not be a problem.

Comment 8

[will69]

Boris, thanks for taking the time to investigate this issue.

Publically available FinTS documents do not specify the physical characteristics of the data transmission. However, the animated GIF that you get as a fallback (when JavaScript is off) uses a frame delay of 0.12s (i.e. 8.33fps) and repeats after 75 frames. The preferred method (toggling visibility) seems to be much faster, though. The clock signal would allow for such variations in frequency.

I have tried different combinations of "layout.frame_rate.precise" and "layout.frame_rate". This had an impact on visual appearance, but it didn't help to recognize the flicker code.

There's one important aspect I initially overlooked, though: Firefox 4b12 + Xorg 1.8.0 use 100% CPU for the flicker code, with Xorg getting most of it. This is even worse on a faster machine: 98% Xorg, 2% Firefox. Minimizing or covering the browser window is sufficient to decrease the load.

Sorry for not seeing this right away.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> i.e. 8.33fps

Well, refresh driver can _definitely_ handle that.

> This had an impact on visual appearance, but it didn't help to recognize the
> flicker code.

This is when I start really wishing your device had diagnostics that told me what it's thinking.... ;)

> Firefox 4b12 + Xorg 1.8.0 use 100% CPU for the flicker code

Interesting.  I wonder whether X is failing to keep up with updates here for some reason.  But the regression range certainly looks like refresh driver.

What values did you try for "layout.frame_rate", by the way?  If they try to drive the flicker at a higher frequency than our refresh driver goes I can see us skipping frames, but then again so does your 60Hz LCD if they try to go at more than 60Hz...

Comment 10

[Boris Zbarsky [:bzbarsky]]

OK, looks like the relevant script is https://bankingportal.sskduessledorf.de/js/flicker91.js.

This script tries to drive the flicker at 100Hz by default (opttanDefaultDelay is in ms), which is faster than monitors actually update.  So this will drop frames.  With refresh drive it might possibly drop more frames than before...  maybe.

Put another way, I have no idea why this ever worked.  ;)

And yes, that first bar is a clock signal, looks like, based on reading that source.

Comment 11

[Boris Zbarsky [:bzbarsky]]

One other thing worth testing.  You can change the delay used by running:

  javascript:document.cookie="opttan_data=width=253#delay=500";void(0)

in your url bar; replace the "500" with whatever delay you want.  I would guess that any delay more than about 20 should work pretty reliably with the default refresh driver settings, but it would be good to have confirmation...

Comment 12

[Boris Zbarsky [:bzbarsky]]

Oh, for comment 11 you need to do that on the page the flicker code is shown on, and then reload the page for it to take effect.

I should also note that if they used mozRequestAnimationFrame here this would all Just Work...  :(

Comment 13

[will69]

Works like a charm! Thanks a lot, Boris!

The following bookmarklet can be used to set the frame rate to 30fps:

javascript:document.cookie="opttan_data=width=253#delay=33";void(0)

Note that you have to use in-app navigation, or your session is terminated. So, this bookmarklet can be used just before calling up the flicker page. A value of 20 would mean 50fps and works, too, but stresses the CPU too much. (That much you cannot even enter the generated transaction number.)

Comment 14

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

So, this doesn't sound like a blocker to me based on comment 10 and comment 11 - it actually sounds like an INVALID. Renominate if I missed something.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I think we should strongly consider evangelizing the site to fix their default timeout or to expose a user control to change the flicker rate....  Again, I don't understand how this could have worked before.

roc, thoughts?

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If this is only failing for Linux users then I think it's not worth trying to work around (which sounds incredibly painful). We should evangelize the site(s).

Comment 17

[will69]

Finanz Informatik has changed the delay value to 20ms (50fps) in flicker91.js. This fixes the problem for all German Sparkasse online banking sites.