Why does RSA downplay the PINpad?

Slashdot posted to How to keep track of passwords? as Re:SecurID :

jtshaw writes:

I carry my password on my keychain... it changes every 60 seconds. Of course... there are a few more numbers that aren't on the keychain.. but remembering that is no worse then a ATM pin.

The next step in security is the SecurID "PINpad", this looks like the credit-card form SecurID product, but has twelve "buttons". The display still show random six digit numbers every sixty seconds.
Instead of typing your PIN in online, you enter it into the PINpad and then enter the newly computed combined number.

The advantage is that you never enter your PIN in the clear, the only place you ever type your PIN is once when you first create it, from then on you just enter it into the PINpad.

PAC issue in Safari on Tiger (MacOS 10.4)

The Proxy Automatic Configuration URL feature, as implemented in Safari, is broken.

Instead of one HTTP request for the PAC file at the start of a session, Safari 2.0(412) makes a HTTP request to the PAC server once for each object requested -- for each HTTP request out to the internet, a corresponding request is made for the PAC.

This leads to one host generating PAC request rates exceeding 57 GETs/second, totalling over ten thousand hits in a day from a single Tiger workstation, and hundreds of thousands of extra PAC hits per day.

For comparison, the average MS-Windows client hits the PAC URL a mere 7 times per day. As the number of Tiger installations grow, the load on the server hosting PAC grows, until critical mass is reached, the server falls over, and suddenly nobody can reach the internet because nobody can load the proxy settings.

When using a local PAC file (a file::/localhost/... URL), the network problems are avoided, but browser performance is poor, with many broken images and general slowness in loading pages.

Well-written PAC-aware browsers will retrieve a fresh copy of PAC when first launched, and then cache this copy, refreshing the contents either based on the Expires header or using an internal refresh timeout (Under MSIE, the refresh time can be set using the IEAK). Safari drops the ball.

In Mac OSX Tiger, the option to configure proxy settings is under System Preferences/Network. This menu gives the user the option to set a "PAC File URL", but no option to control how/whether this file is cached and refreshed. Also, Safari does not respect Expires headers sent by the PAC server.

For each site accessed, Safari makes a new TCP connection to the PAC URL (specifying Connection: close) and sends a HTTP/1.0 request for the URL as set in the System Preferences. If they'd at least implement keepalives (as Firefox does), the problem would be greatly reduced.

Workarounds:

Installing 10.4.1 does not resolve this issue.

As a temporary workaround, switching to Firefox eliminates this problem. Firefox will only download the PAC at the start of the session or when the user manually chooses to reload PAC.