1Password on Mastodon

[Enhancement] Treatment of Special Domain Names

I was able to produce "newtab", [empty string], [arbitrary string], "1Passwords Chrome Extension ID (khgocmkkpikpnmmkgmdnfckapcdkgfaf)", and ugly [IDN/ACE prefixed domain names]. While everything is safely encoded (and that is the most important point here), I wonder whether a few of the aforementioned cases need some special treatment (e.g., by displaying a replacement string instead).

1Password Version: Not Provided
Extension Version: 0.7.5
OS Version: xUbuntu 16.04 - Chrome 59
Sync Type: 1Password for Families


  • AGAlumBAGAlumB
    1Password Alumni
    edited June 2017

    @m33x: Thanks for bringing this up! We need to tread carefully with IDNs and let the browser handle this since they can be used in phishing attacks. What exactly are you proposing?

  • m33xm33x
    Community Member

    I totally agree, leaving IDNs aside, I would implement a whitelist for all/some of the other mentioned cases and e.g. disable the message "Autofill for" with "" instead etc.

  • beyerbeyer

    Team Member

    @m33x: We will certainly take a look at this. I'm not confident if a whitelist is the best approach as we display any domain as reported by Chrome. For example, if you copy and paste chrome://version/ into Chrome the browser extension displays version (similar to your newtab example). Furthermore, you can create a Login item with a website of chrome://version/ on your 1Password account which would then display as a fillable item.

    Personally, I think providing a little more feedback to the user when a Login item for a particular domain isn't found might be the best way to handle this. Thanks for the feedback, we will keep this under advisement as we tweak the design.

    Andrew Beyer (Ann Arbor, MI)
    Lifeline @ AgileBits

  • pazusteppazustep
    Community Member

    Another negative for special treatment is that other Blink-based browsers might do things just a little different. For example, this is what I see on Vivaldi's New Tab page:

  • dtearedteare Agile Founder

    Team Member

    Thanks for the reports everyone. To be honest I wasn't really sure what to do here and was leaving it be until I have better visibility.

    The more I think about it the more I believe that we should only show the fill category for tabs that have a https://, http://, or file:// protocol. We'd simply hit the fill category for all of these other "special" tabs.

    I think I'll go ahead and make this change in the next release.

  • dtearedteare Agile Founder

    Team Member

    I've updated things so you'll no longer see the fill actions for special pages like chrome://newtab. This change will be available in 0.7.7 which will likely be published later today.

This discussion has been closed.