Random Thoughts – Randosity!

Stupid Security Measures: autocomplete=off – How To Turn Off or Disable

Posted in banking, security, technologies by commorancy on April 16, 2012

While I’m all for some browser related security, this one feature is completely asinine because it’s so unpredictable, uncontrollable and stupidly implemented. This is the complete opposite anyone should expect from a quality user experience. Let’s explore.

What is auto-completion?

Most browsers today will automatically fill forms and password fields from locally saved browser login and password information (usually the field is yellow when automatically filled). This is called autofill or autocompletion. While I admit that storing passwords inside a browser is not the smartest of ideas, specifically if it happens to be connected to your bank account. With that said, it is my choice. Let me emphasize this again loudly. Saving passwords IS MY CHOICE! Sorry for yelling, but some people just don’t listen or get this… hello Chrome, Firefox and IE, you guys (especially Chrome) need to take notes here.

So what’s this autocomplete=off business?

As a result of autocompletion, the browser creators have decided to give web site creators the ability to disable this mechanism from within their own web pages. So, when they create forms, they can add the tag “autocomplete=off” to the form which prevents the browser from storing (or offering to store) passwords or other sensitive information. This is fine if the browser would give the user the choice still. It doesn’t.

I’m fine with browsers trying to prevent stupid behavior from users, but always provide an override. Never implement features like this, however, at the expense of a frustrating and inconsistent browser experience. This is exactly what autocomplete=off does. Why? The browser doesn’t give the user control over this web page mechanism nor does it even warn of it. If the site sets this flag on their form, the browser won’t offer to store anything dealing with this form. That’s fine IF I can disable this behavior in the browser. I can’t. As I so loudly said above, this is MY choice. Make this a preference. If I want to store logins and passwords for any site on the Internet, it’s my choice. This is not Chrome’s choice or Wells Fargo’s choice or any other site’s choice. If you offer to store and save passwords, you need to let me do it under all conditions or don’t offer to do it at all. Don’t selectively do it based on some random flag that’s set without any warning to the user.

Inconsistent Browser Experience

When autocomplete=off is set on a form, there is no warning to the user that this value is set. The browser just doesn’t save the password. You have no idea why, you don’t know what’s going on. You expect the browser to offer to save and it doesn’t. This just makes the browser look broken. And, frankly, it is. If the browser can’t warn that autocomplete=off is set by the site through changing the color of the bar, flashing, an icon or some other warning mechanism (like the lock when https is in use) the user experience has been compromised and the browser is broken. This affects not only Chrome, but IE, Safari and Firefox. Yes, and this is extremely bad browser behavior. It’s also taking a step back in time before web 2.0 when the browser experience became more positive than negative. We’re heading back into negative territory here.

Browser Developers Hear Me

Not warning the user that the experience is about to change substantially is not wanted behavior. For auto-completion, we already have mechanisms to shut it off entirely. We have mechanisms to exclude sites from saving credentials. Why do we need to change the browser experience just to satisfy Wells Fargo or some other site? I’m all for letting these sites set this flag, but just like overriding bad certificates at https sites, users should be able to override autocomplete=off. There is no need to break the browser experience because you want to allow sites stop saving of passwords. No, again, hear me, it’s MY CHOICE. It’s not your choice as a developer. It’s not Wells Fargo’s choice. It’s not PayPal’s choice. It’s MY CHOICE. If I want to save passwords into my browser, allow me t0 always override this setting.

Hacks Galore

Yes, there are browser hacks available as browser extensions (Chrome or Firefox) to disable autocomplete=off on forms on sites. While these hacks work, they require updating, can break on browser updates and can be generally problematic under some conditions. No, this is an issue that firmly needs to be addressed in the core browser, not through clever browser add-on hacks. Let the sites set autocomplete=off, that’s fine. But, warn me that it’s turned on and let me override it. I shouldn’t need a hack to fix a bug in the browser.

Always Warn of Browser Experience Changes

Why am I going down on this issue so hard? Because this is a completely crappy implementation of this feature. Why? Because it breaks the user’s browsing experience without any warning. If this the page is attempting to prevent me from saving credentials, then this information should be marked clearly in the browser somewhere. Perhaps by adding a special icon to the address bar indicating that credential saving is not allowed on this site. Then, when I click that small icon, I should be able to override this behavior immediately. Again, this is my choice to store or not store passwords to the browser. There should never be any defacto security mechanisms which cannot be overridden by a user control. Never!

If the user chooses to do something stupid, that’s the user’s choice. No, it’s not a bank’s, chrome’s or any other company’s responsibility to ensure the safety of user data. It’s entirely the user’s responsibility and those choices should be completely left up to the user to decide, for better or worse.

[Update] Safari is now warning when autocomplete=off is set on a page. Safari now tells you that the site you are visiting doesn’t allow saving of passwords. Bravo to at least Apple for getting this one right.

I have also found that Firefox with the Greasemonkey plugin and this Greasemonkey script works best for completely disabling all pieces of autocomplete=off.  While the above plugins do at least allow saving passwords, the plugins don’t always allow autocomplete to work.  This means that if you want to see your credentials autopopulate into the fields on page load, you may have to use Greasemonkey instead. I have found that the Greasemonkey solution is the most complete at disabling autocomplete=off.  The reason this works is that Greasemonkey actually removes this autocomplete=off pieces from the page before Firefox renders it. The other plugins just tweak the browser to ignore the setting for password saving, but it still exists in the page source and, thus, the pieces that manage the autocomplete parts are left unhandled.  So, these pieces still don’t populate the fields.

37 Responses

Subscribe to comments with RSS.

  1. Manuel said, on May 14, 2014 at 10:18 pm

    Nowdays Chrome is totally ignoring this parameter, but there are a few situations where this is AGAINST “UX”. For example, in my site, after a user accepts saving his credentials in the browser and a second user tries to create a new account, the username and password fields are automatically filled. For the god sake, this is a registration form and there should not be pre-filled passwords!

    I have no way to control this besides introducing a JS hack (bad idea) or assigning a different name for my PASSWORD field.

    All stories have two sides, in this case I totally disagree that their solution to all this controversy is just ignoring the autocomplete. There should be a balance I guess.

    • commorancy said, on May 15, 2014 at 2:37 am

      Hi Manuel,

      Actually, Chrome still abides by this parameter when available. You need to load an extension to make it ignore it for password saving. But, the extension is not as good as Firefox’s Greasemonkey plugin which strips the text out of the page before it’s handed over to the browser to render. It’s as if it never existed in Firefox. However, the best Chrome does is allow saving the passwords, but it doesn’t allow autofill without additional extensions.

      As for remembering autofill (when the page is allowed), if you’re talking about using your same browser instance on your system with two or more different people, then that’s not really possible using the same OS login. Chrome is a single user browser under a single OS login. Autofill and password save assume it’s only one user. If you want to use multiple users with Chrome, they will each need to have separate operating system accounts (either Mac OS X or Windows). Once you do this, then each user will have their own home directory and chrome preference area. They will also not share passwords or filled form data. So, you can avoid the problem of forms being autofilled by forcing people to use their own logins and passwords when using your system.

    • Julian Peña said, on May 27, 2014 at 8:00 am

      I Agree.
      The argument here is “It’s MY CHOICE”.
      From the point of view of the developer is also MY CHOICE.

      • commorancy said, on May 30, 2014 at 4:10 am

        From the user, it’s ‘my choice’. From the developer, it’s the choice of the user who’s using your app. The point of a software developer isn’t to dictate what the user does. The software developer job is to engineer software that does what the user wants. A lot of software engineers get into incorrect mode of thinking that attempts to dictate how the user uses the software. No, the software should be what the user wants to use, not what the developer has forced upon them to use. This is why so many software packages fail to gain traction and eventually fade away. Users want software that makes their lives easier, not harder.

  2. Lars Trebing said, on February 25, 2014 at 6:43 pm

    Lo and behold, Safari 7.0.2 (included with OS X 10.9.2) finally ignores this autocomplete=off nonsense! I am delighted!

  3. Haywood Jablome said, on October 27, 2013 at 10:54 am

    You are correct. Anything that unnecessarily inhibits usability is poor design.

  4. Gregg said, on October 4, 2013 at 6:29 pm

    Another chapter of security theater… I never knew about this but did notice the behavior change a some time back and it bugged me. The point of the web is the users are empowered. Yes dumb people may hurt themselves with power. Hopefully they learn from it, else I installed the FF extension – and the bank sites offer to save my password. Gotta love the source. Thanks for the FF link!

  5. Roel Spilker said, on September 18, 2013 at 7:33 am

    I agree to a lot of things mentioned here:
    – It should be the choice of the users
    – Users will store the password somewhere else or reuse passwords

    But recently, we get a lot of heat from our customers that use automated pentest tools to find vulnerabilities. The security tools they use say that we must add “autocomplete=off” to our password field. I personally don’t agree. Is there any research that you know of that proves (or at least suggests) that adding “autocomplete=off” is more secure than not adding the autocomplete attribute? Or possibly even proves or suggests it is less secure?

    • commorancy said, on September 18, 2013 at 11:26 am

      autocomplete=off is a suggestion, nothing more. It was created as a concession between the website creators and the browser creators. By ‘concession’, I mean that both indirectly colluded to create this more or less useless parameter to control the fact that browser creators have chosen to implement an insecure password storage mechanism.

      If the browser creators (i.e., Chromium, Safari, Firefox, etc), would actually take this feature back to the drawing board and write a safe password storage mechanism, autocomplete=off would not be necessary. That this parameter exists is a testament to browser creators’ unwillingness to make a secure password storage vault within the browser.

      Why is autocomplete=off a suggestion? Because there are plugins that negate its usage. That even one browser plugin exists says that users want to be able to control when and how their passwords are stored. And, rightly so. For pentesting, the agencies demand it because it’s a ‘best practice’, not because it’s actually useful. Worse, autocomplete=off is trying to control user behavior via a server side setting. It has nothing to do with site security and everything to do with keeping the user from his own folly.

      So, the questions that remain. Is it more secure to use it? That’s debatable. For the users who don’t use a plugin to disable the suggestion, perhaps. For users who have a plugin installed, no. Does it really do anything to protect your web site directly? No. Again, the parameter is there to suggest to the browser not to store password or form data for a specific site. It is a indirect security mechanism that you have no idea if it is really doing what it is supposed to do.

      Oh, and one other thought I’ll leave. Browsers are constantly updated, changed and revised. The autocomplete=off suggestion remains valid as long as browser creators choose to honor it. If the next release of Chromium, for example, chooses to no longer enforce autocomplete=off, then the use of this entire suggestion will become pointless. I can also pretty well guarantee you that if one browser stops supporting it, all others will follow in kind. Something to keep in mind.

  6. method3000 said, on July 9, 2013 at 9:52 pm

    You’re definitely right about this. I see a lot of people here not getting the basic point, which is that if a server doesn’t have control over something it doesn’t have the right to force the client to do what it couldn’t do. All it can do is ask politely. For example, somebody could develop a ‘no-save’ attribute for the html element, but it would be evil if the browser listened to that and wouldn’t let you save a copy of the page to your desktop. It’s not about security or developer convenience, it’s about the proper division of powers between client and server applications. It makes me unreasonably mad every time I think about it.

  7. CW said, on July 5, 2013 at 11:06 am

    Meh… It’s a security risk. I don’t care how smart you think you are – you’re the reason it exists. Not only should you NOT be given the option to override the attribute, the behavior shouldn’t exist in the first place. It should be handled on an OS level, not in the browser.

    You’re an account hack just waiting to happen…

    • commorancy said, on July 5, 2013 at 12:03 pm

      Everything’s a security risk. Simply turning on your computer is a security risk. Ignoring even that simplest of arguments, we’re discussing this feature specifically. And specifically, this feature cannot exist in the OS. Why? Because there are too many different OSes and too many different security techniques to handle how data is stored in the OS. Browsers would have to become twice as complex to deal with all of the methods to store this data at the OS level. Typically, however, in Windows we’re talking about storing things in the registry which clearly has next to nothing in the way of security. Further, it cannot exist in the OS because all browsers since the early to mid 2000s live in a walled garden. That is, they cannot get access to OS level information easily or quickly without jumping through many hoops. That, in and of itself, pretty much eliminates your argument about where this data should live.

      If you want thorough security, the data should live in your brain alone. However, we all know that remembering every single password all of the time is not possible. Therefore, it has to be put somewhere that can help us remember it. Unfortunately, that usually ends up being a password vault of some kind. That the browsers have not produced a password vault that’s secure is a browser problem. Sure, you can get 1Pass or other better password vaults, but these typically cost money and aren’t fully compatible with every browser or every device.

      Let’s understand the security risk of autocomplete=on. If you can’t store the password in the browser, then it’s likely the user will store the password somewhere else, probably in a plain text file on the file system named something like ‘passwords.txt’. Or worse, store it somewhere on their screen with a ‘post-it’ note application. The reality is, having autocomplete=on doesn’t solve the security problem, it just shoves the problem elsewhere. Placing it into the browser password store is both convenient and the reason it’s there. That the browsers have chosen to make this password store insecure is a problem with the browser developers. The browser developers could most assuredly do a better job to secure the password store, including requiring a separate password to add to, pull from and decrypt the passwords stored in it. Have they added these enhancements? No.

      You argue that autocomplete=on exists because of ‘me’ or people ‘like me’. Not true. It exists because browser developers have not done their due diligence to secure the browser password store properly. If the browser password stores were actually secure, this feature wouldn’t even be necessary.

      As for being a ‘hack just waiting to happen’, that depends on what you do with your machine and the sites you choose to visit. If you’re constantly downloading and installing randomware and browsing to random sites and clicking on spam links in email, getting hacked is likely to happen with or without a password cache in the browser. Most malware today installs keystroke loggers in among whatever other trojans they also install. It’s far easier to get your passwords with a simple key logger than digging through your browser password cache, even though it is easy enough to take that info too. The reality is, hackers don’t just want to download your browser’s password cache, they want full access to your machine so they can ‘pnwn’ it, dig through your files, look for credit card numbers and the finally hack your accounts.

  8. SuperC142 said, on April 8, 2013 at 8:36 pm

    “This website recommends you do not save your password as doing so may present a security risk. Would you like to save your password anyway, against the advice of the website’s creators?”

    How hard is that?

    • commorancy said, on April 9, 2013 at 9:30 am

      I definitely agree that it’s very simple to place a warning message on the site. It’s also relatively easy to make an icon visible on the browser when a feature is active. Either way, there’s an easy fix here to make this whole deal a much more friendly experience. Definitely need something better that’s for sure.

  9. Michael said, on April 4, 2013 at 7:13 am

    I’m a Web Developer, and at the moment I am creating a site with a form that has to give some informations through “hidden fields” to the server. It is essential for the website to work that the hidden fields are not autofilled. I was very happy to hear about the autocomplete=off feature, but I experienced it’s not working in the newest version of Chrome.I made many websites that won’t work as long as Chrome prefills HIDDEN input fields, and I am very happy to go through them all and try to fix this issue… So next time better think about the other side before you write something like that…

    • commorancy said, on April 4, 2013 at 7:28 am

      Hi Michael,

      From a user perspective, the browser needs to notify the user that this setting is active. It’s fine if sites want to use autocomplete=off on their site. It’s also fine if I want to override the setting. But, as a browser user, the browser should display and inform to the user that the site has chosen not to allow passwords to be saved. Basically, you experienced exactly what I described, which is that the browsers are broken when it comes to displaying information about this feature. As a developer, you of all people should appreciate when the browser informs you that your setting is working.

      What I mean by this is that when this setting is active on a web site, the browser does not inform the user that this setting is active with an icon or by any other means. Instead, when you attempt to enter a user and password, nothing happens and the browser does not prompt to save. Granted, Chrome’s credential storage system is hit-or-miss anyway. That is, sometimes it works to store credentials and sometimes it doesn’t even if the site isn’t using autocomplete=off. This makes Chrome generally broken for user password storage.

      However, when autocomplete=off is set, Chrome tells you nothing and offers to save nothing. It just appears broken… and it is. As a developer, you should appreciate that each browser needs to be much more informative to the user when this setting is enabled. Like the lock in the URL bar when using HTTPS, browsers should display an icon showing that autocomplete=off is active on the site. This way, there is no confusion over what the browser is doing (or not doing). As a developer, you should really complain to the browser developers that their browsers are broken when (not) informing users and developers when this feature is in use.

      Thanks for your comment.

    • commorancy said, on April 4, 2013 at 7:34 am

      BTW, I would highly recommend that you only use the release channel of Chrome when testing against the web site you are building. If you are using the beta, dev or any other non-stable channels, there’s no guarantee that any specific features you might be attempting to use aren’t broken. I’ve found that the non-release channels are generally unstable and mostly unsuitable for everyday use. So, you should make sure you have the main release channel installed on your system for testing. Good luck.

  10. rcamicandi said, on January 13, 2013 at 7:25 pm

    Thank you, thank you, thank you for this enlightening post. It saved me from further hours of searching to make autocomplete work “properly.” It is these maddening types of “O” behavior – obdurate, obstinate, obstreperous –
    from the overlords that deservedly earn them user hostility. Back off Big Brother this is NOT your call.

  11. JX said, on December 18, 2012 at 8:25 pm

    This issue ticks me off as well. I am not even using the browser’s auto-complete function. I am using an encrypted password manager to auto-fill the user and password spaces. Thus the “browser security” argument is not a big issue for me. When this functionality (to auto-complete) is shut down, you cannot even do a cut and paste into the password field — only manual typing works. I THINK the reason that some sites implement this feature (which I hate) is due to bots that roam the web trying captured user / pw combos on a variety of sites to see if they can gain access. By not allowing any cut and paste into a particular field, it forces manual typing (from what I understand), thus helping to limit some level of hacking into those sites. While I understand this, I find my most financially critical sites don’t employ this methodology – they use a third required input field, register your computer with a cookie, employ other security measures, etc. What I find is that It’s the smaller, far less critical sites that implement this stupid feature. Which in turn usually encourages me to put in a far easier password, because I don’t want to have to type in some complicated string of letters and numbers which I always use on sites that allow for auto-complete. In the end, I think this only backfires on the companies utilize this silly feature.

    • Lars Trebing said, on February 26, 2013 at 1:47 pm

      I have never observed what you mention here (browsers not allowing to paste password in autocomplete-disabled forms)—maybe it’s some special “feature” of the browser that you are using?

      In any case, this certainly wouldn’t keep any bot programmer from doing their work, either by writing a bot that is based on a different browser, or by making it “type” the password instead of pasting it, or by simply writing a standalone bot that doesn’t rely on any browser at all. (In most cases this type of bot is by far the easiest to write.)

      • Lars Trebing said, on February 26, 2013 at 2:04 pm

        I am fully aware of what you’re saying here (in fact, I was already fully aware of it even before reading this somewhat repetitive blog post). But please do look at the comment that I was answering with my comment and you’ll see that the person writing that one actually does claim autocomplete=”off” to disable the well-known copy and paste mechanism.

      • commorancy said, on February 26, 2013 at 2:13 pm

        Hi Lars,

        I thought your comment was a top-level comment as that’s the way WordPress initially presented it to me in my browser. Only after I loaded the comments page a few times did it show that it was threaded to another author’s comment. I find this frustrating about WordPress.com’s hosted site when trying to put context to comments. It doesn’t always show exactly how comments are threaded until later and it definitely doesn’t show threading in the moderation area.

        After seeing your comment in relation to the original comment thread, it makes a lot more sense than when I read it in context to the original article. Sorry for any confusion over my comment.

        Thanks.

  12. Marc said, on December 3, 2012 at 12:38 pm

    Does anyone know a good hack for IE to disable autocomplete=”off” i.e. to set it to on for all web pages?

    • commorancy said, on December 19, 2012 at 12:19 pm

      Hi Marc,

      I’ve looked for plugins to disable this in IE, but I have been unsuccessful at finding one. If I do find one, I’ll post up a link. In the meantime, I’d suggest using Firefox or Chrome.

      Thanks.

  13. Jochem said, on November 29, 2012 at 12:30 pm

    I mostly agree, but I envisage one situation where using autocomplete=off actually makes an application better … namely in the context of password reset forms … I don’t find it helpful to have those auto-filled. In the real world applications (often of the backoffice/intranet variety) some user is tasked with application administration, tasks include (re)setting people’s passwords in such as case you would like to show password inputs without the autofill behaviour.

    The issue of whether people should be tasked with changing other peoples passwords is another discussion! but in the real world it happens (and clients do request such functionality be built into their apps … even if you don’t agree you cannot always convince them it’s a bad idea)

    • commorancy said, on December 3, 2012 at 1:11 am

      The fundamental issue is that anything that can be set in a page should be allowed to be overridden by the user. This is the most basic fundamental right that we should be afforded as users. Unfortunately, that may also break potentially useful use cases. As a web programmer, as long as you understand that the user can and will potentially override anything you try to enforce, then those users may have problems. However, if a situation arises in the browser where the user is overriding a setting set by the web developer, then that information should be imparted to the user with a bubble or popup explaining that things on the page could break with the override. As long as the user is told this on page load, they can make the choice to let it override or disable the override for that page load.

      Again, it should not be the web developer’s choice that breaks the user’s experience. The user experience should always be controlled and managed by the browser. If the experience is broken by something a web developer can set on a page, then the browser is fundamentally broken. Perhaps I should write a guide on this subject?

  14. sa said, on November 22, 2012 at 7:59 am

    I strongly agree with the post. This browser behaviour is very boring.

  15. Uncle Bob said, on October 27, 2012 at 12:10 am

    Hallelujah, Brother! I’m in total agreement with you, at least now that I understand the cause of the problem. This thing bit me in the backside when I created a login at this rinkydink little site run by the school that my kids attend. It took me about half an hour to scope out why FF wouldn’t offer to store my login credentials. I’m willing to waste a little more time overriding these moron’s overreaching security policy.

    You mentioned in “Hacks Galore” that there were browser add-ons to address this issue. If you know one that works with Firefox, would you please share it. Thanks.

    • commorancy said, on October 27, 2012 at 12:27 am

      Thanks for your comment, Bob. Yes, there are Firefox addons. I’ve just installed and tested Remember Passwords 1.0.2 and it does work on Paypal’s site (which has autocomplete=off defined).

      Sorry for any confusion if you saw an earlier reply containing Autocomplete Manager. This extension doesn’t work with Firefox 16. So, I’ve tested the one above and it does work with Paypal.

      Thanks.

    • commorancy said, on October 28, 2012 at 1:57 am

      Hi Bob,

      I’ve just added the link to the Firefox add-on into the article. Thank for asking to have this information added.

      • Uncle Bob said, on October 28, 2012 at 2:29 pm

        Many thanks!

        Pls feel free to remove this note to cut down on the comment clutter…

  16. lepht said, on September 14, 2012 at 5:19 am

    > It’s not your choice as a developer. It’s not Wells Fargo’s choice. It’s not PayPal’s choice. It’s MY CHOICE. If I want to save passwords into my browser, allow me t0 always override this setting.

    Amen, brother. A big regression in the web browsing experience over the last year, IMO.

  17. Steve said, on September 10, 2012 at 5:39 pm

    Maybe if browsers had an automated way to accept a signed, notarized waiver of liability so that a bank etc wouldn’t be on the hook if your account was compromised because you stored your password in your browser.

    • commorancy said, on September 11, 2012 at 11:06 am

      Yes, that would be great wouldn’t it? Except that the most likely way that your password would be lost or stolen wouldn’t be because it’s saved in your browser. It’s much more likely that your password will be stolen because your system has become infected with a keystroke logger via an email phishing attack that installed spyware, a virus or a trojan. Alternatively, it’s about equally likely that a user will click a phishing link in a convincing email scam that looks like their bank’s emails leading them to a login page that, again, looks like their bank’s login page. This leads the victim to ‘login’ and give the scam artists their login and password credentials. These scenarios are far more likely than losing the password from the browser password storage area.

      In other words, protecting your computer from attacks is fundamentally a lot more important than worrying about having stored the password in the browser. Because, once your computer is infected, they won’t be looking at your password cache in the browser. No, they’ll be logging your keystrokes to gather your credit card numbers, account numbers, addresses, social security, birth dates and any other identifying information so they can steal your identity. Worrying about revealing your login and password details through the browser is much less likely than having the computer becoming infected or falling victim to a phishing attack.

      With a notebook that can be easily misplaced, lost or stolen, then storing passwords is not a good idea for the same reason as a shared computer. I wouldn’t place sensitive passwords in a notebook’s browser unless the whole hard drive was encrypted to protect from loss or theft. If it’s a desktop and never leaves your house, then it’s not so much a problem as long as you safeguard against attacks. Although, it might be a good idea to encrypt the drive here too.

      The only case where storing passwords isn’t recommended is if it’s a shared computer. However, if it is a shared computer, then you shouldn’t be saving any passwords on it, as your computermates will likely dig through your login and password credentials. If at all possible, get your own computer that only you have access to.

      If someone loses their password to a phishing scam, that doesn’t make Wells Fargo any more liable than the browser storing the password. In the end, if you’ve lost your money through any kind of attack, Wells Fargo is likely to be partly liable anyway, so the argument is a bit weak.

      Note, the fact that any bank sends emails out that can be spoofed by would-be phishing artists likely sets that bank up with a far more liability than worrying whether their password is being stored in the browser.

  18. Brian Sitz said, on May 24, 2012 at 11:55 pm

    aww, it was at the very top, I looked everywhere but didn’t see it. Sorry, usually see things signed and dated at the bottom.

  19. Brian Sitz said, on May 24, 2012 at 11:54 pm

    Is there a way to understand when you post things? Because without a date, it’s hard to understand if it’s still valid. Otherwise, insanely great post.

    • commorancy said, on May 25, 2012 at 4:28 am

      Actually, I’m glad you asked this question. While I know you found the answer, it’s good to let others know. There are two ways to see the date of a post. In this theme, it’s in the black bar at the top of each post. The second place is in the URL bar as part of the permalink. I try to keep my posts relevant and up-to-date so they are applicable for quite a while. I also remove posts that are no longer applicable.

      Thanks and I am glad this was helpful.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 537 other followers

%d bloggers like this: