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.
Thanks -- this is very cool indeed! I'm employed in a Mac environment now, so I'll pass this around at work.
Thanks again.
I love the smell of binary patches in the morning.
I do, too, and the idea behind this one is solid. I would make this change though:
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.
As it so happens, "autocomplete" appears exactly once in a big (unsorted) table of attributes. So it doesn't really matter either way.
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 :)
Huh. I used to do something similar to turn 'blink' into 'brink' in Netscape.
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?
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.
'easy'? Sedding the binary is easy?
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.
share? (for win+firefox) :P
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.
Ask, and ye shall receive.
Love greasemonkey. Absurdly simple hack, though.
That's even cleaner than the one I had. Guess I /won't/ post mine. ::)
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.
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.
meh, I misunderstood the point of the tag.
You're a moron.
No, I'm a person that's had to write software to defeat any attempt to auto-store passwords.
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.
*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.
*shrugs*.
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.
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.
Thanks,
John
Now is the season of giving.. ;)
Evidence piece number one for a DMCA lawsuit? Har har.
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.
Who said it was valid?
It's an IE specific thing that Moz was badgered into supporting by the banks. See above.
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.
For extra credit, implement an InputManager (or SIMBL plugin) to override those methods without patching or recompiling WebCore.
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.
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.
Wouldn't "sudo gnuclient /etc/passwd" work here?
sudoedit/sudo -e is neat, in any case. :)
Does this break Google Suggest, which uses autocomplete="no" to avoid a conflict between autocomplete and its own functionality?
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.
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.