Treat as same site

[jmorgannz]

Add new sync'd option 'treat_as_same_site', which allows configuration of which parts of a domain should be used to identify a site vs it's subdomains or base domains.

Update both options pages to include this, with instructions how to use it. Default to sane values which preserve previous functionality (hardcoded recognition of .co.* domains) Rewrite domain matching routine to use new configuration option using regexes.

This patch fixes an issue where countries that use second-level domains (.net.nz, .co.nz, .org.nz, .gov.nz) were misidentified with the second level domain part being used as the site name. It has sane defaults, but allows configuration so that users can customise for the particulars of their country and other websites that use a two-level base domain system.

This should be fully future proof now.

This is an adaption of my feature of the same name from masterpassword-chrome

[jmorgannz]

Note I don't have the boilerplate installed to run your tests (and have not modified or created any tests for this feature) Feel free to instruct.

I also run windows so have trouble building the icons and the scryptasm - to get by I just downloaded the latest release and ripped the files out. I guess I could try using WSL.

[ttyridal]

I'm left to wondering if we're over-engineering this (ref my comments in masterpassword-chrome). The user interface for this is rather advanced (hence the need for a longish explanatory help text)

Also it doesn't seem to work as intended in Firefox. I can't make a new line, and all the defaults end up on the same line.

about over engineering: Previously there was a tight coupling to the visited URL and what's stored in the site settings. This is no longer the case. sitename x.y.com is the same regardless of the visited site (domain/url match), and will be preferred over q.y.com when visiting x.y.com. This is based on a match on the stored _sitename not the stored url and this matching takes into account as many domain name parts/levels as possible.

The remaining problems to solve are

• The default case when visiting new sites. Ie suggesting a sitename. Maybe removing the first element (typically, www, login, etc) is a better solution? at least it's much simpler.

• When one wants to use amazon.com on all variants (.co.uk, .de etc). (does require some stored-url matching)

[jmorgannz]

(porting comment by @ttyridal over from masterpassword-chrome PR) https://github.com/ttyridal/masterpassword-chrome/pull/16#issuecomment-977691180

Hi, I haven't had the chance to look closely at your solution(more than a quick browse) I would prefer a solution that " just works" (ie no config) but the nature of this is dynamic - and keeping up to date with what every country does is out of the question.

One question that arises is to drop the whole idea. Previously there was a tight coupling to the visited URL. This is no longer the case. sitename x.y.com is the same regardless of the visited site, and will be preferred over q.y.com when visiting x.y.com The remaining problems to solve are

the default case when visiting new sites. Ie suggesting a sitename. Maybe removing the first element (typically, www, login, etc) is a better solution?

when one wants to use amazon.com on all variants (.co.uk, .de etc)

The existing solution solves all but the default sitename suggestion.

[jmorgannz]

I think the functionality of both of our solutions to managing 2LD's is actually pretty much the same - the implementation is just a bit different.

We both try to expand the 'sane defaults' of what a 2LD is so that MP 'just works' for most people by listing out a bunch of 2LD's.

There are two main differences in our implementations:

• Your one is fixed at the 2LD level; whereas this one allows any number of domain parts to be considered the 'base' part of a site - so if a user frequented sitename1.webhost.co.nz and also sitename2.webhost.co.nz, this would allow adding .webhost.co.nz to the config and it would fix the issue. (or .webhost.co.*)

• This one allows user-override of sane defaults - which as with the example above hopefully you can see could likely be fairly common in some countries like mine.

I do concede that figuring out how to operate this feature may be beyond the average user - which is why sane defaults are so important.

However, on the second point; hopefully we can agree that a list of 2LD's isn't code but configuration data.
That doesn't necessarily mean that it should be user configurable configuration - but that it could/should be treated as configuration from the code point of view and managed through the config class?
This possibly applies to other areas of the code that use lists of hard-coded things also - however sane they may be.

Once you adjust thinking to be in line with that; it isn't a far stretch to imagine an 'advanced settings (here be dragons)' area or some such, not unlike about:config in the browser - that would list internal configuration settings that are really not meant to be changed by most users - but that could be for those that understand enough to realise changing them would fix an issue for them (i.e. me!).

In that vein; an advanced config area need not concern itself with baby-proofing, and I think has some right to be a bit more verbose in it's descriptions and method of config entry.

Once you get to this point thinking through what I am saying; you can see my solution basically does exactly this.

• Takes your hard-coded list of 2LD's and moves them to a config option.
• Generalises it to run on an engine rather than an array, allowing a little more coverage of edge cases (3LD's, 4LD's, etc)

The only thing extra that need be done to complete the idea above is have a tickbox for 'show advanced options' or some such in the config UI, and hide the config by default unless the tickbox is ticked.
(or another accordion if that floats your boat)

What do you think?

[jmorgannz]

Sorry further to this - understand what you are saying as far as having resolved this issue by changing the way site matching works. Presumably you are doing the same thing I am doing in the domain matching method - attempting match against all sites then scoring based on parts matched - which would be why you no longer support multiple configuratons per site.
(I haven't digested that procedure yet)

If that's the case, then this patch only fixes up the initial domain identification for new unstored sites.
Personally I still think it's an elegant solution - but it's usefulness is limited in that you already fixed part of the issue it was trying to fix (it was designed for masterpassword-chrome)

If you want to turf it given that then fine. Up to you.
Personally I don't think the extra code hurts any. If anything perhaps we could just display: none the config elements for this feature so its the same as using a hard-coded list of 2LD's - but for someone like me I can inspect and make visible to override :)

[jmorgannz]

Actually on properly taking stock of the fact that you have effectively solved the issue I was trying to solve already; I have to concede that this patch had two things going for it for me - pride in an elegant solution, and added/fixed functionality.

The functionality has already been fixed which takes that out of the equation. The solution is no longer elegant but redundant given the former. Which leaves pride for what was an elegant but no longer elegant solution - which should not be a reason for accepting a PR!

I can see that storing the 2LD list as a config option itself could cause issues for future updates - as it may get sucked into storage and then even if the defaults are updated in future to expand coverage, they will not be used. So that's another negative of this solution that would require engineering to fix.

So the only other thing to discuss from my POV coming from masterpassword-chrome with my fix applied, is what are the drawbacks/functionality loss of shifting to the your new model.
So far as I can see they are:

1. Potentially having to manually fix up incorrectly detected domains on unstored sites - but less frequent given the new 2LD list, and if one does come up as frequent I can submit an issue or PR.

   • seems better justified than the added complexity added by my code.

2. The loss of being able the store multiple configurations for the same site with the new site storage model.

   • can you elaborate on this, as I didn't quite understand what you meant by it. with the new site model can you still store multiple accounts for the same site using the accountname@domain format, which you can then select from the dropdown?
     if so; what do you mean by multiple configurations per site?

[ttyridal]

You are writing out my thoughts :)

Having slept on this, I really really dislike the user experience part, but your implementation is a lot more generic and nicer than my very simple brute-force solution. And, the config vs code argument is a valid one. I’m not too worried about the future updates thing. As it works now nothing is saved if you don’t change the defaults.

I would be perfectly happy with your approach if we burry it in some –ignore-for-most-users- advanced settings (and a wiki entry to notify of its existence?). Possibly, We might allow the full power of raw regex as well in that case? no ui at all for the first iteration would also be an option.

It would be better to get the stored-url just right, because it does play a part for proposing the sitename on first visit (as mentioned), but also in the sitename dropdown – the presentation is split between “related” (matching on stored-url) and “others”

Regarding “multiple configurations per site”. This is still possible, ie having user1@site and user2@site.
What’s no longer possible is to have user1@site.com (associated with url1.com) and user1@site.com (associated with url2.com) to be different (eg different count/type/etc). Previously the sites where stored internally as {url: { sitename: { settings}}. Now it’s [ {sitename, url:[], settings…}] – and the sitename is enforced to be globally unique. (I’m still trying to settle if an array is a good idea or if I should enforce it with a dictionary, but that’s another story). This is in line with the original MasterPasswordApp/Spectre and how the .mpsites file is structured.

So yes, you can still have user1@ and user2@ selectable in the dropdown. Since they match on the url level they will also be pushed to the top of the list, followed by a separator line. finally all other stored sites will be shown. If you use one of them, the current url will be added to that site, and it will be shown “above the fold” the next time.

[ttyridal]

ok.. I stumbled across https://publicsuffix.org/ ... that's 230K bytes of config data to get this right 😬

[jmorgannz]

LOL, we swapped positions. You came around to my thoughts and I came around to yours.

Yeesh, cool that there is a public suffix list - but 230K, and is it even up to date?

Funny, I bet the browser already has a copy of this local somewhere.

Personally I think I'd accept we can't win completely and go for a more compact list like we have that covers as many core cases as possible. I don't think we can win trying to manage much more than 2LD's without the user's help giving hints for their specific country or frequented sites.

It's a pity we can't come at it from another angle and as a secondary check peek at the sites cookies - as the domain field in the cookie is already set up to define the cookie to traverse the entire site including subdomains.

So where do we go from here? I guess the other review points need to be tided up aside from the config data and visibility issue. Main one coming to mind is the error throwing vs empty url return.

[jmorgannz]

https://stackoverflow.com/questions/61745387/how-does-chrome-or-any-other-browser-use-public-suffix-list

[jmorgannz]

https://wiki.mozilla.org/Public_Suffix_List/Uses#document.domain

The document.domain attribute is used to enable pages on different hosts of a domain to access each others' DOMs. All browsers restrict the values to which the document.domain property can be set, to maintain the same origin policy.

Chrome implements of a multi-process architecture involving a singular "browser" process and multiple "renderer" processes. It uses the PSL (via document.domain) to identify pages that cannot script each other, helping to determine when to create a new renderer process.

It does not make a distinction between private domains and ICANN-delegated domains.

[jmorgannz]

https://github.com/remusao/tldts

[jmorgannz]

https://issueexplorer.com/issue/w3c/webextensions/58

Sorry for spam. So this seems to be an open issue in terms of webextensions - and quite timely too.

[jmorgannz]

The document.domain attribute is used to enable pages on different hosts of a domain to access each others' DOMs. All browsers restrict the values to which the document.domain property can be set, to maintain the same origin policy.

Chrome implements of a multi-process architecture involving a singular "browser" process and multiple "renderer" processes. It uses the PSL (via document.domain) to identify pages that cannot script each other, helping to determine when to create a new renderer process.

Tested this and it won't work.
Using brave (webkit) I browsed security.stackexchange.com, then opened up debugger and checked document domain.
Given what is said about how document.domain uses the PSL, I would expect document.domain to be stackexchange.com in this instance.
It was not. It was securty.stackexchange.com

Similarly browsing an article on worldbuilding.stackexchange.com yields document.domain == worldbuilding.stackexchange.com

StackExchange is a good test case; as it effectively uses one site with global logins to a bunch of subdomains that are basically just categorical.
So this is the opposite case to the case I have been trying to fix - which is where the 3LD is the login conext (site.co.nz) as opposted to irrelivant (security.stackexchange.com)

In this case; as I mentioned using cookies as a way to glean this info, sure enough their cookies are set to .stackexchange.com in all cases.

I guess that means that same origin policy is no good for our use - as technically since document.domain differs for these subdomains, they should be being treated as separate security contexts which cannot share data without CORS set up.
They are however sharing login cookies.

Tested in Firefox and behaviour is identical. I guess that article is just no longer accurate.

[ttyridal]

I think you answered most of the questions yourself :)

Yes, there are valid arguments against PSL. On the other hand, it is what browsers are using. And it would definitively cover more cases than a custom list you and I compile here can ever do. I think it is the best we can do today.

I did a quick implementation of PSL in branch wip_getDomainRight.

Got the list down to ~80k with very simple measures, and working on an idea that would reach ~60k. Compression Streams API would yield ~20k which I think is absolutely acceptable. Unfortunately it is very new and not supported in Firefox yet. Since I just yesterday figured out how to avoid a ~100k growth of scrypt-asm.js that's still a 40k win :)

Possibly, one could offer user configurable overrides.. but then we're back on how to present that to the user..

One thing I'm definetively holding back on is going online / making requests somehere.. I think it is a (security) feature that the extension does not communicate with the outside world.

[jmorgannz]

It's nice to pick up the terminology that has been laid out, at least; So what we are doing here is building a system to identify and exclude the public suffix of a domain name.
That leaves the rest of the domain name which is 0-n private subdomains sharing 1 private domain, being the first (right most) part before the public suffix We will then identify private domain as the site by default.
So privatesubdomains(0-n).privatedomain.publicsuffix is the format?

Sound right?

Beyond that in the case where different private subdomains actually use different logins or are different sites; it is then up to the user to manually correct this, and after that the scoring system will ensure it works fine unlike the old implementation.
Example would be;

• website.com.au
• testing.website.com.au
• staging.website.com.au
  (common in business and software dev, each being a unique instance of an app and therefore having unique logins)

For efficient lookups of the data, did you look at tldts?

[ttyridal]

I think so.

All your examples will be identified as (associated with the) Website.com.au (url)

I did browse through a couple of libs. Maybe I misunderstood, but I got the impression they where quite large and/or requires some build system/module loader.

I think convenient and small is more important than efficient. We're doing one lookup when the pop-up opens. As long as it's in the ms range, we're good.

[jmorgannz]

All your examples will be identified as (associated with the) Website.com.au (url)

So what happens when I browse staging.website.com.au, having previously amended the sitename to be staging.website.com.au?
Will it show a dropdown with all website.com.au logins?

I guess I can test this myself.

As for comments re libs/efficiency - yeah again that would be my thought also. We're not engineering a kernel here lol :)

What timezone are you in, by the way?
Seems we are at opposite ends?

I'm in NZ (+13)

[jmorgannz]

All your examples will be identified as (associated with the) Website.com.au (url)

Hmm I just tested this as if codegolf.stackexchange.com and worldbuilding.stackexchange.com were independent websites.
It doesn't work. It forces recognition of the site as stackexchange.com in all cases; even if when I first visit one of the subdomains I overtype the sitename with the full domain name including subdomain.

This puts me back in the starting position that this PR was meant to fix - when you come across sites that use private subdomains that are actually different sites for purposes of login.
I thought your scoring rules would allow storage of codegolf.stackexchange.com as it's own site so long as the user manually amended the site name when first entered. However as this doesn't function the only fix is for me to use my config system for domain detection and enter a rule .stackexchange.com which would treat each subdomain of stackexchange.com as it's own site.

For a real world example of this; take for example wordpress.com - which you can host your own website on at yourwebsitename.wordpress.com - each of which is it's own website with it's own logins etc.

I guess a workaround for this would be if you allow sitename to be editable in the config screen - perhaps only if double-clicked.
It's clumsy, but that would mean I could add an entry for website1.wordpress.com which would incorrectly save as wordpress.com, but then go into the config, double click the sitename, and amend it to website1.wordpress.com.
Note if I amend the 'matching' domain field to be website1.wordpress.com, it still matches all wordpress.com subdomains.

Also, there appears to be autofill enabled on the sitename box, which wants to suggest all prevously entered sitenames.

[ttyridal]

What timezone are you in, by the way?

Norway (+1) so yeah :-D

Also, there appears to be autofill enabled on the sitename box, which wants to suggest all previously entered sitenames.

yes, that's by design. sort by score the ones that (partially) match the url, then a separator and finally every other site. Do you think it was better before? or is it the autocomplete thing that's giving you pain? I'm not sure I'm 100% satisfied with how it works myself to be honest. Maybe it's better to just filter the list and not doing suggestions/type-ahead

[ttyridal]

Hmm I just tested this as if codegolf.stackexchange.com and worldbuilding.stackexchange.com

You're right.. that's a bug in the match-url-to-sitename thing.. When I added that it was primarily to catch this case: {sitename: apple.com, url: icloud.com} now, when I visit apple.com I wanted that record to be the default shown, even if apple.com is not in the url list.

regarding wordpress.. I'm surprised they are not in the public_suffix_list. maybe worth sending in a pr there= (hmm.. if the browsers use psl to limit cross domain cookies.... 😈)

It's clumsy, but that would mean I could add an entry for website1.wordpress.com which would incorrectly save as wordpress.com, but then go into the config, double click the sitename, and amend it to website1.wordpress.com

You already can. what you are editing in the config page is the url to match the record/sitename/siteconfig to. So in the two stackexchange cases, you will get the correct default after editing. but it would still show the other one as "related" (which clearly could be considered a bug: {sitename: worldbuilding.stackexchange.com, url: worldbuilding.stackexchange.com} should definitively score low when visiting codegolf.stackexchange.com, even if it's still stachexchange.

[ttyridal]

clearly some missing tests in this area still 🙄 and maybe some contradicting goals.. I still want my apple.com/icloud.com match :)

[jmorgannz]

clearly some missing tests in this area still 🙄 and maybe some contradicting goals.. I still want my apple.com/icloud.com match :)

Sure. That's a good feature that I also use. Same goes for gmail.com and google.com

Perhaps I should do a PR for some test cases that cover issues I have. They can then be turned into issues to work on individually.

[jmorgannz]

You already can. what you are editing in the config page is the url to match the record/sitename/siteconfig to. So in the two stackexchange cases, you will get the correct default after editing.

The sitename field on the config page is readonly for me. It's just a td, not an input.
I can only modify the (matching) entry box (domain?), but the sitename is forced to what the original entry box from the popup had in it - which detects stackexchange.com on codegolf.stackexchange.com and if I override it it just changes it back. So I have no way to get my own data into the sitename field.
Is this the bug you were talking about?
(EDIT: Oh I see the problem. The combobox doesn't accept entry on blur. It seems to need the enter key to be hit to accept the input or it just resets)

Ok so two issues here:

• Bug? stopping popup sitename from being changed without hitting enter (not obvious)
• Feature: Being able to edit the sitename field from the config screen.

I guess this PR is starting to branch off a bit. I should submit these things as individual issues/features.

but it would still show the other one as "related" (which clearly could be considered a bug: {sitename: worldbuilding.stackexchange.com, url: worldbuilding.stackexchange.com} should definitively score low when visiting codegolf.stackexchange.com, even if it's still stachexchange.

Not so worried about that. Bug or undocumented feature? :)

[jmorgannz]

yes, that's by design. sort by score the ones that (partially) match the url, then a separator and finally every other site. Do you think it was better before? or is it the autocomplete thing that's giving you pain? I'm not sure I'm 100% satisfied with how it works myself to be honest. Maybe it's better to just filter the list and not doing suggestions/type-ahead

Oh ok it's the mpcombobox I'm seeing. I thought it was the browser doing it's own autofill thing.
No autocomplete is not giving any issues.

I think the mpcombo is fine. I now also understand what you meant about requiring the promise chain to continue even with unmatched domains (url='') so that you can select from your sites. Yes this is a great feature, means I don't have to keep browsing to a site just to get it's password to use in another app (like battle.net, etc)

I think the idea of 'free lookup' mode is a good one - but I feel like it confuses things trying to make the same UI have two functions - one being creation of entries for the current site (or recall if already in place), and another being free-lookup of any site's password.

There is some simplicity of cognitive load that one knows that when they click the MP icon, what they get is directly related to the site they are viewing. Making it able to look up unrelated sites kind of breaks an unwritten rule in my head that instantly adds cognitive overhead - if you get what I mean.

I have shown family how to use your plugin and it took some work to get them to understand that it was not a general password lookup app that they typed the sitename into manually each time to get a password - but was meant to be automatic based on the site you are on. (if they do do what I said, they end up with all these random unrelated sites attached to whatever domain they happened to be on when they used the plugin this way)

So adding a mode where what they are supposed to do to look up a random unrelated site is do it that way kind of makes it even harder for a novice to 'get it'

Perhaps a better UI idiom for this would be a dedicated 'free lookup' mode to disassociate the two modes of UI operation.

Of course; I am just pontificating at this point. You know what they say about opinions. They are like aholes - everyone has one!

The reality is what you have done works fine aside from the teething bugs.
I feel like the popup could look a bit nicer as it's not obvious to me it's a popup initially. Perhaps it should be a little taller so you fully understand it's a scrollable combobox.
I like how it used to have a button rather than just pop up on it's own. It was clearer what was happening.

Maybe I am just expecting it to operate like the old version - if I give it some time maybe the new idiom is better.
If you combine accurate site detection with default usernames, it may not even be necessary to store site data in 90% of cases as the defaults will produce the correct password generation.
Although - if that happened, then the mpcombobox would be empty except for the currently detected site and the few sites where a user has altered the configuration by setting a non-default username or other password generation parameters, triggering a store - which turns the whole thing into a big circular argument... ulp!

I dunno. I'm waffling at this point.

[ttyridal]

Bug? stopping popup sitename from being changed without hitting enter (not obvious)

bug, no bug. hard to say. It will work it hitting enter or tab. cancel the edit on Escape. now, if you click outside, is it ack or cancel? in most situations on the web, it's ack. so -> bug.

Don't remember why I wanted to disallow changing the sitename from config. It was problematic somehow with the old storage format, but I can't see why it couldn't be allowed now.

free lookup mode

An alternative is to show all sitenames only on about:blank etc pages.. and some "see all" button in the other case?

I like how it used to have a button rather than just pop up on it's own

The button is there. if you have more sitenames for the same url (to give a clue about just that)

it may not even be necessary to store site data in 90% of cases

That's mostly how I use it and why I implemented the default login-name like I did. :) When trying it, I liked yours better, as it was somewhat "less intrusive".. It also fails when one have to increment the counter.

Not sure I understood how you've explained your family to use it. I tried to keep the default behaviour the same as before (but failed?)

[jmorgannz]

An alternative is to show all sitenames only on about:blank etc pages.. and some "see all" button in the other case?

That seems more clear at a UX level to me.

Not sure I understood how you've explained your family to use it. I tried to keep the default behaviour the same as before (but failed?)

For the less technically inclined (read: luddites), the idiom they are familiar with is an 'app'.
The idea of a browser addon is somewhat more complex - it involves the idea of an app that is 'context sensitive' - that is, the way it works changes depending on where you use it (which domain in this case)
Whilst this idiom is obvious to us; to the less technically inclined it is something that has to be learned and can be quite difficult to initially get their head around.
Their first instinct is to attempt to use the addon like it's an APP with no context sensitivity.
They can actually succeed in this via brute force in that they learn that the steps to get a password are as follows:

1. go to whatever browser window is currently present - any
2. ignore the sitename, delete it out and write in the sitename they want the password for - often not even a domain. Eg 'email' or 'facebook'
3. copy the password out for use somewhere

The result of this is that 'email', or 'facebook' is assocated with whatever random domain they are on, and it is unlikely to even recall automatically in the future.
This means they learn that they must type in the sitename by hand each time.
It also means stored sites get polluted with junk.

So educating them away from this behaviour can be a bit of a task. It takes them energy to get their head around the way the popup associates to the website they are on. It can be done but it takes some gymnastics.

So given that; all of which applies to the old masterpassword-chrome; now imagine trying to teach the users the same thing, except it has been made even easier for them to use the plugin the 'wrong' way by providiing a lookup mechanism for sites that don't relate to the current domain.
You can imagine it just being too hard to understand why they should try to understand how to use the context-aware features of the plugin when it's so easy to use it the 'wrong' way (the context-less way)

This can lead to them not understanding why sites they want to select are not in their stored sites - the reason being that they never actually fill in their details for that site on the actual domain because they just don't get that it works that way.

[jmorgannz]

regarding wordpress.. I'm surprised they are not in the public_suffix_list. maybe worth sending in a pr there= (hmm.. if the browsers use psl to limit cross domain cookies.... 😈)

I meant to reply to this at the time but forgot.
Wordpress would not belong in the public suffix list as it is not public, It's a private domain.
The difference is it's also a prefix in that it's subdomains are all owned by different owners. PSL can't help here. :(

[ttyridal]

Wordpress would not belong in the public suffix list as it is not public, It's a private domain

How is it different to blogspot or various dynamic dns sites (eg dyndns) - that are on the list? I think it just shows a limitation of PSL. It's a community based effort after all.

I see.. so I'm about to make the extension too limit-less and non-tech-user-friendly 😮 can't have any of that 🤣🤣

Interesting part is that it is kind of the use-case I'm after. Quick lookup for using outside the browser (some native-app appstore thing etc). It would have been great if it could do both. Be a "generic" password lookup app - with context sensitiveness, so the first option is the one you most likely want.

But you are also correct about the significant drawback: stored sites gets polluted. I have tried to squeeze an idea out of my head for a heuristic to decide if we're changing the sitename purposefully, or just doing a lookup (and thus should not save the url). without luck so far.

The only alternative I can come up with is a save button.. And that's so 1999 :) It could work if you mostly use the context feature: eg when visiting gmail.com and changing it to google.com, ask: "do you often use your google.com account on gmail.com?" or something.. ugh.. definitively not as a popup...

Using about:blank as a mode switch for this lookup-mode is perhaps the best choice. And it will not add url to the stored site. I actually have about:blank as my default page so it would work pretty great. I guess many (most?) have google.com, their email, facebook (shrug) or some corporate homepage though.

Leads me to another, kind of related, issue. To save or not to save the default suggested site (so an export will contain all sites you've used the extension on). I know several users make and revert a change, just to get it saved. Part of the reason why I liked your default login name solution better... It forces an interaction and gives us a hint that this site is worth saving.

[jmorgannz]

How is it different to blogspot or various dynamic dns sites (eg dyndns) - that are on the list? I think it just shows a limitation of PSL. It's a community based effort after all.

Fair point.

I see.. so I'm about to make the extension too limit-less and non-tech-user-friendly 😮 can't have any of that 🤣🤣

Hah. Hope you don't take any of my comments the wrong way. It's your baby! Only sharing my experience with a couple of users.
If it requires users to 'unlearn' using the plugin the way that is intuitive for them, and learn doing it another 'correct' way as decreed by a propeller-hat, then maybe that is justification for doing exactly what you have done. Don't fight the current, enable it.

Interesting part is that it is kind of the use-case I'm after. Quick lookup for using outside the browser (some native-app appstore thing etc). It would have been great if it could do both. Be a "generic" password lookup app - with context sensitiveness, so the first option is the one you most likely want.

Yep as I replied above.
And yes that is a great feature. I have felt like coding up a quick dotnet systray app so many times, but then not reached peak motivation. So instead I just browse to the site I want the password for to get the password. So whos doing it the backward way then. The 'luddite' users, or me!
I'd def use the free lookup.

But you are also correct about the significant drawback: stored sites gets polluted. I have tried to squeeze an idea out of my head for a heuristic to decide if we're changing the sitename purposefully, or just doing a lookup (and thus should not save the url). without luck so far.

Yeah tough.

The only alternative I can come up with is a save button.. And that's so 1999 :) It could work if you mostly use the context feature: eg when visiting gmail.com and changing it to google.com, ask: "do you often use your google.com account on gmail.com?" or something.. ugh.. definitively not as a popup...

Yeah I was just writing that above then read the next paragraph. HAH.

Using about:blank as a mode switch for this lookup-mode is perhaps the best choice. And it will not add url to the stored site. I actually have about:blank as my default page so it would work pretty great. I guess many (most?) have google.com, their email, facebook (shrug) or some corporate homepage though.

By definition the only URL's available in this mode would be stored, right - unless a user manually typed one in.
If they did; wouldn't that be a pretty good hint to save it?
The difference is the matching domain should not be about:blank - perhaps it should be identical to the sitename?

Leads me to another, kind of related, issue. To save or not to save the default suggested site (so an export will contain all sites you've used the extension on). I know several users make and revert a change, just to get it saved. Part of the reason why I liked your default login name solution better... It forces an interaction and gives us a hint that this site is worth saving.

Yeah I'd lean toward no (not saving default generated sites) - but this multimode operation creates some use cases that create extra challenges.
There is no issue if a site is not stored when one browses to it, you can still autofill and predict the correct password. So with just that model there is no issue generating the data on the fly. Stored sites only then really exists to store non-generatable data such as the MPW config parameters.
It breaks when your use case is free lookup - which now requires all sites you use to be stored to provide a lookup list.

The only ideas I can come up with off the top of my head here are:

• Differentiate between 'lookup sites' and 'stored sites'
  • For example, record a separate history of sites (just domains?) that have ever had the popup opened on them. Use that list union'd with stored sites to provide a free lookup list, with the 'history' sites generating data using defaults when selected.
  • Somehow use browser history to glean a list of domains for the same purpose?

But again here we are starting to flesh out engineering an entire other system and the scope of this discussion thread trails off :)

Not that I find that a problem at all - happy to bounce ideas around - just I am a fan of biting off things in little chunks and refining.

This one; design of the free-lookup mode, and the use cases/systems which support it, I think is worthy of it's own feature/issue and may generate multiple PR's (or internal commits) to interate over?