Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Beta extension test and feature requests #47

Open
JeGr opened this issue Aug 16, 2020 · 2 comments
Open

Beta extension test and feature requests #47

JeGr opened this issue Aug 16, 2020 · 2 comments

Comments

@JeGr
Copy link

JeGr commented Aug 16, 2020

Hi all,

I thought it best to get it all together into one post for the first look into it, and perhaps later splitting out into actual bugs/features. But based on the beta extension now, I took a look and found these points along with (for me) missing features to be discussed of course :)

  1. installed the beta extension in the same browser the "normal" one was installed prior (that I disabled beforehand). New extension seems to sense my log-in in the dashboard and creates a new "Chrome 32bit" entry for an API key and seems to use it, too. So 👍 for using the API key now, but a 👎 as the newly created API key always has the same name (Chrome XYbit for example) and as API keys in the dashboard can't be renamed, it's an utter mess to install the extension on multiple PCs/laptops and actually know which key is which!
    So my recommendation: if a log-in is detected rather than auto-create an API key with a predefined name, either let the User choose a name "for its browser" itself or try to detect (if possible) the correct browser name and perhaps hostname if possible to create something like "%browser ON %hostname" so it's actually clear as to which browser on which host is using that API key.
    ➡️ Also a side note for Dashboard/App backend: Make the API keys' name editable :)

  2. New settings menu: Very good to have one!

  3. New App setting: Show simplelogin button on email input fields:
    First: great idea for quickly use of disposable addresses.
    BUT: It's a bit messy. Core feature is there and it works. Period. For everyone only working with a single domain or some default domain of yours, it's OK('ish). But as you can't select either a mailbox or domain from those configured in the backend of your account in the extension, it falls back to the very basic default settings of the backend itself. That's okay for single-user/single-domain, but for everyone with a more complex setup, it's messy. I have a "trash" domain, that would also affect set up for random "BS" addesses that I want to use. But for some things, I'd like to create a non-trash/non-random address and that button would be great for it. So if we could double/multi-use it to insert random addresses with left click or open a popup on right click where you can select to create an address like in the extension popup (sitename is suggested along with a domain popup) and after the creation of the address it's auto-inserted, that would be just great!
    So TL;DR: for intended use of random - good and working but lacking control of the mailbox (only creates addresses for default mb and domain) - but could be much more powerful later :)

So what's "missing" in the extension IMHO?
I write missing in "" because that's my feature request rather than a bug :) So the points I can see would be:

  1. App setting: Default Domain
    Select a default of either SL-domains or your own custom domains to use/show when the extension symbol is clicked and a alias suggestion is created. Especially useful when used in a family or business context as you'll have multiple browser extensions / app users, that want to create aliases for their own mailbox or with their own domain. That leads to

  2. App setting: Default Mailbox
    See 1) as it goes hand-in-hand with the default domain. I'm currently trying SL together with my wife and daughter to make them use application/service specific email/pw combinations and it's a great testing ground for a more complex business usecase. So if daughter/wifey want to create aliases they always have to switch to another domain. And have me edit the alias afterwards as one can't select another mailbox as the default one in the backend. So ATM the extension isn't of use in a multi-mailbox scenario as you have to always re-edit the alias to the right mailbox. Actually this is more important that 1) as for the domain that is already switchable via the dropdown at least.

  3. App setting: Default MB/Domain for Random addresses.
    Yes we can fall back to the backend settings from the account, but different use cases exist. I have three subdomains for myself and different usages (business etc.) where I create aliases on so depending on me using the company or personal laptop/PC it would be a great help

  4. New Alias popup: Dropdown for mailbox
    self-explanatory and essential for using SimpleLogin with multiple mailboxes. Instead of the current implementation to show the mailbox dropdown after alias creation, just move that dropdown to the normal screen as a second line so you can select the domain and mailbox before actually creating the alias. That stops the API from unnecessary getting multiple calls for the same thing. Having the dialog in the "after creation" screen as it's now is still valid - in case one wants to use 2 or more mailboxes for an alias. But most commonly, I want to set this up beforehand.

  5. New Alias popup: optional PGP switch
    self-explanatory: having it in the initial popup wouldn't clutter too much when put in the same 2nd line as the default mailbox as a small on/off toggle.
    having 4) and 5) on display in the initial popup would bring the extension ~on par with the android app 👍

  6. extend new button usage
    As described above, the "insert random mail" button would be even more useful if you could trigger the "normal" app extension popup "New Alias" by e.g. right-clicking or open a context menu to select that action.

  7. extend automatic detection of site/url
    When clicking on the extension to create a new alias, the site is checked and a recommendation for a site alias is made. So going to e.g. GitHub and clicking it, it searches and then shows "New Alias: %sitename @Domain" or - if it detects an existing alias for that site, it shows it on top with "already used on that website". I don't know how it recognizes that there already exists an alias for that site, but in a few cases or with aliases not created through the extension, that detection fails to see an existing alias.
    Also, if there are 2 aliases for the same URL/Domain, only the newest (or most recently used?) is shown, so that leads to confusion on sites that e.g. have 2 aliases for different mailboxes (personal/business account for example).
    So it would be nice if it would be further specified how the app looks for these "domain hints" or how one can manually add these so they will be found (better) as well as if more then one is present, show both/more on top for that domain.

Perhaps I missed something already there (but hope not :)) but those are the things that popped up over the weekend in short-testing it with the family :)

Of course open to discussion!

Best regards,
\jens

@nguyenkims
Copy link
Contributor

@JeGr wow, thanks a lot for the thorough feedbacks! For the first section, I think 1) can be fixed by choosing a different name for the Api key when beta extension is used. Would be a piece of cake for @ngxson 👍

For 3), I totally understand that the one-click alias creation is quite basic compared to the rich options in the alias popup. We can't do much for the new SimpleLogin icon as it's not ideal to add new elements to another website UI. We'll try to tweak the right-click menu to see what we can do there. Maybe add an menu for each domain. These features are always less powerful to the alias popup though.

For the new features ideas, I'll take a deeper look and create items on our open roadmap to address them 👍.

@JeGr
Copy link
Author

JeGr commented Aug 17, 2020

Thanks for getting back!

If anything makes no sense to you don't understand why, just ask - perhaps I overlooked something myself. Learned in all those years that one still only has two eyes and if those are tired, things may slip ;)

Besides that always glad to test things out. As said, I'm currently using our daughter as a field tester by "encouraging" her to switch to service-based mail addresses (like @her.sub.domain.tld) to get her user/pass pairs even further apart in case one service goes bad and has a data breach so both user (mostly email) and password are "disposable" (password because of pwmgr that generates a new one) and can't be used on other sites successfully. I'm also switching a few service credentials out the same way, so we have some overlapping services and generate enough aliases and things to really test things out ;)
That's also why feature 7) popped up, as we both created an alias for the same service on different domains and at first I got her alias proposed, then after creating mine, I got mine (and she, too). That brought us to "how does it even select it and which one wins"?
That also triggered feature 1 & 2 as well as the test of the beta extension, because she couldn't create aliases with her mailbox preselected and I ended up changing it in the dashboard. But that way we could test the "catch all -> mailbox" feature and up until now it works great for her (switched her subdomain to catch all and defaulted it to her mailbox so she doesn't need to use the extension). That also showed "automagically" created aliases for services won't show up on the extension's radar to "hey you already have an alias here". I suspect some backend code or the default comment (Used on www.xyz.tld) is the trigger for the extension to "see" existing aliases and show it up?

So yes, we're pretty busy putting SL though the paces and making use of those nifty forwards that so far working great! Thanks for that! It really makes teaching about net-sec and using PW managers & strong passwords in combination with service-style emails a whole lot easier! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants