<form autocomplete="yes, dammit">

Dear Lazyweb, here's an answer instead of a question!

Some web sites put "autocomplete=no" in their login forms to prevent your web browser from saving your password. I find that annoying (if I've told it to save my passwords, then I'd like my passwords saved, thanks) so here's how you fix Safari so that it will treat those forms just like all the others.

    sudo sh
    cd /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/
    mv WebCore WebCore.orig
    perl -pe 's/(\000)a(utocomplete\000)/\1_\2/gsi' < WebCore.orig > WebCore

Then re-launch Safari.

This change will get blown away the next time Software Update sends down a new Safari.

Tags: , , , ,

35 Responses:

  1. zackbishop says:

    Thanks -- this is very cool indeed! I'm employed in a Mac environment now, so I'll pass this around at work.

    Thanks again.

  2. duskwuff says:

    I love the smell of binary patches in the morning.

    • strspn says:

      I do, too, and the idea behind this one is solid. I would make this change though:

      perl -pe 's/(\000autocomplet)e(\000)/\1_\2/gsi' < WebCore.orig > WebCore

      in order to avoid confusing anything which might assume sortedness. Lots of things are assumed to be sorted, and since tags aren't abbreviatable, that is just as good.

      • duskwuff says:

        As it so happens, "autocomplete" appears exactly once in a big (unsorted) table of attributes. So it doesn't really matter either way.

  3. violentbloom says:

    it'd also be nice if reset everything really blew everything away, alas it does not, but do feel free to let me know how to fix that also :)

  4. anthonybaxter says:

    Huh. I used to do something similar to turn 'blink' into 'brink' in Netscape.

  5. tithonium says:

    I use firefox on both my windows machines and my powerbook. so I wrote a greasemonkey script to reset any autocomplete tags to 'yes'.

    Really, Shouldn't /I/ be the arbiter of my own security?

    • jesus_x says:

      Normally yes, and thankfully they'r efairly easy to override, but there's some history here. Basically, it was some backroom blackmail. The big banks and such threatened to not support Moz/FF on purpose unless we all drank their Koolaid and gave them the autocomplete attribute. It soothed their lawyerbots enough, and it's still fairly easy to override. It's a case of waving the dead chicken.

      • ebel says:

        it's still fairly easy to override.

        'easy'? Sedding the binary is easy?

        • jesus_x says:

          Hard to recall exactly what I was referring to from three years ago, but most users would just swap out the binary with a prehacked one. But it's trivially easy to end run by just scanning it in another app.

    • starjewel says:

      share? (for win+firefox) :P

      • tithonium says:

        Apparently I haven't gotten around to installing it on this machine yet. I'll grab it off another machine as soon as I get a chance, and reply here with a link.

      • georgedorn says:

        Ask, and ye shall receive.

        Love greasemonkey. Absurdly simple hack, though.

    • malokai says:

      Some companies/services are required by law to force you to enter your username and password every single time. Usually this is only delegated to medical however (to prevent an unlocked workstation from being a point of attack). Banks have an interest in this because stored passwords = retrievable passwords.

      • georgedorn says:

        Obviously, don't do this at a public workstation. Obviously, don't do this on any computer that you don't lock when you stand up, if anybody else can get at the computer.

        autocomplete has nothing to do with store passwords, though.

      • jwz says:

        You're a moron.

        • malokai says:

          No, I'm a person that's had to write software to defeat any attempt to auto-store passwords.

          • jwz says:

            I don't care what you "had" to do, and I don't care what your employers' believe to be their legal obligation to prevent me from using my computer as I see fit. If you think that your employers' halfassed attempts to prevent me from storing my passwords has anything to do with security...

            you're a moron.

            • malokai says:

              *sniffle* mommy, someone on the internet called me stupid ;_;

              It's not hard. Create two random strings of text and insert them into the user's session, define one to be the username, one to be the password. Insert into form, retrieve values next request. Put autocomplete=in your scripts all you want, it's not gonna matter when the form variable names change everytime the page is loaded.


              Individuals as yourself may be intelligent enough to make their own decisions; people in general are pretty stupid though and should just not be allowed to do certain things.

              I'd go look up the parts that defined it, but you're slinging beer, not storing x-rays, and you've already made your decisions.

              • johnlu_78759 says:

                malokai, any chance you're still getting notifications on this thread? I'm in agreement with you, and if you're at all willing to discuss your methods a little bit, I would appreciate it if you pinged my e-mail.

                I work on a site that coordinates large-scale clinical research studies, and my goal is to do whatever I can--within reason--to protect the patients' privacy, regardless how the site's users have their browsers configured. I tried the dynamic-form-variable-names approach you outlined, but met with only limited success.


  6. nester says:

    Now is the season of giving.. ;)

  7. mark242 says:

    Evidence piece number one for a DMCA lawsuit? Har har.

  8. ultranurd says:

    Huh. I didn't know that was a valid attribute of the form tag. I guess I should actually look at the source from time to time to keep my HTML knowledge fresh.

  9. pawliger says:

    Never let it be sed that's not elegant and easy, but the whole source for the WebKit frameworks are also available for hackery using the instructions at http://webkit.opendarwin.org/building/checkout.html along with scripts for launching Safari using the newly built frameworks without requiring them to be installed so would keep the system clean.

    If you go the hackery route find the two implementations of elementDoesAutoComplete in WebCoreBridge.mm and WebHTMLRepresentation.m, make them always return NO, build, and use WebKitSources/WebKitTools/Scripts/run-safari to run with the newly built frameworks.

    • duskwuff says:

      For extra credit, implement an InputManager (or SIMBL plugin) to override those methods without patching or recompiling WebCore.

    • pawliger says:

      Of course, what I said was "make then always return YES" but the evil little monkeys in my head made me type the wrong thing... again.

  10. ciphergoth says:

    Of course, if this gets too popular, websites will start writing _utocomplete="no" in their login forms. Thankfully I can't see perl binary patches becoming too popular.

    Incidentally, on my system "sudo -s" starts your shell, which can be convenient. I don't know if it does the same in OS X but I'd be surprised to learn it didn't. Other neat sudo command line options: "EDITOR=gnuclient sudo -e /etc/passwd" has to be the most convenient way to edit system files in Emacs.

    • helixblue says:

      Wouldn't "sudo gnuclient /etc/passwd" work here?

      sudoedit/sudo -e is neat, in any case. :)

  11. cnoocy says:

    Does this break Google Suggest, which uses autocomplete="no" to avoid a conflict between autocomplete and its own functionality?

    • georgedorn says:

      Yeah, sorta. At least, turning autocomplete on in FF results in the browser's autocomplete box appearing over the top of the google suggest autocomplete box.

      The greasemonkey script can be made to exclude google suggest, though. The binary patch, not so much.

  12. ydna says:

    The latest security update (Security Update 2005-009 v1.0) replaces WebCore. Additionally, the fix above won't work on this version of WebCore. Turns out there's another set of strings that includes AUTOCOMPLETE which gets caught by the patch (and breaks--er keeps autocomplete working). The fix is to make it case sensitive.

    sudo perl -pi -e 's/(\000)a(utocomplete\000)/\1_\2/gs' .../WebCore