Closed RichJeanes closed 4 years ago
But then how would you list sites that are in more than one country?
What about some sort of filter. You could choose what country you were in, and country specific services would show up. If a website only has 2FA in specific countries, the page would display the status of that site per country. You would still see sites that are in all countries.
Then there could be a way to say either a website has 2FA in all countries except some or it has 2FA in only certain countries and you wouldn't have to add the site to each page.
@jamcat22 how would that filter work considering we are stuck with static hosting? it would have to be fully client-side.
If a site operates independent of location, then it would be on the main page. If it operates in only specific countries, then it would be listed only in those countries. Why would a site be limited to only being listed under a single country?
I like that idea, too. Couldn't that be handled with Javascript?
@RichJeanes for example smaller financial institutions operate in a single country or geo region... I guess all the data could be cooked into a json file(s?) that then would be processed client-side. But I imagine that's not a small task to undertake.
Why couldn't we build that statically? I'm not really skilled with Jekyll at all so I have no idea if this is possible, so I'm just throwing ideas out there, but: Add a new tag for sites (eg. 'reg:' for region) and use standard country codes as comma separated tags (or some other delimiter). When Jekyll parses the file, create a new collapsible div (or whatever) for each country code found and place the site into the category corresponding to the file it is in within each country div that it is tagged for. These country divs are then listed on a separate page just for region-specific sites. When a user is looking for a service that is region-based, they go to this page and find their country.
Example:
- name: English & French Bank
url: https://eandfbank.co.uk
img: eandf.png
tfa: Yes
phone: Yes
sms: Yes
reg: UK,FR
I would recommend the use of ISO 3166-1 alpha-2.
That way each country could still have categories; we wouldn't have to clutter up the directories with a bunch of files for each country, we could have a directory just for the region specific files since they're on a separate page than the rest, or just have a separate file for each category in _data just for region-specific sites, or something; we wouldn't be confusing users by listing them with all the other sites and making users look for flags or tags; no complicated client-side coding.
I dunno. Like I said: I don't know Jekyll, I'm just throwing ideas out there.
Somewhat similar to what I was suggesting almost a year ago in https://github.com/jdavis/twofactorauth/issues/241#issuecomment-43392292 :wink:
Hmm... I didn't really consider that one company would have TFA in one country and not another... I guess under my scheme they would have to have separate entries in the files? Eg Citi Global vs Citi Austrailia? Wow this gets messy quick... Talk about a can of worms in Pandora's box.
Like remember Ovh had tfa in US but only in some countries in EU? Or even look at our notes for paypal: tfa in US and Canada, but sms only in US. Similar with Ebay and Apple. So we can have duplicate entries per country/region(could become a huge mess to maintain) or have a central entry and tags for available/unavailable per country/region.
I vote central entry (which is what I was trying to explain above). :smile: By that I mean we have one entry for a website, then manage region specific stuff within that entry instead of making hundreds of entries for one website.
And I vote region specific. It irritates me that many sites on the list only support TFA for certain countries even tho they serve a bigger audience. Like PayPal for example, how would we manage that? I mean, if we want 2fa.org to make a difference we should be able to pressure companies like that even tho they might support tfa in 1 country.
@Carlgo11 cough #1026 cough
Yes but Paypal is just an example on the top of my head. There's more sites like that listed here
I know. Just saying. :D eBay is next...
Added a bug bounty
Fancy dancy, @Carlgo11 ;)
What if we use flags (or flag globes or something) instead of check marks for services that are only offered in specific countries. So if PayPal has software TFA in the US and Canada, but SMS in the US only, the software column would have American and Canadian flags, but SMS would have US only. Mapping icons from the Yaml would use a check mark if "Yes" or a flag if a country code. Ex. (For example's sake, we'll say the have global hardware support)
- name: Ebay
url: https://ebay.com
img: ebay.png
tfa: Yes
sms: US
software: US,CA
hardware: Yes
Does the icon set that we use have flags?
What about situation where something not available in specific country?
Couldn't we just do -
in front of the country then? It must be pretty easy to code.
@mxxcon If a service isn't available in a country, then it doesn't get a flag for that country. Like in my example, CA
is not listed under SMS. Or am I misunderstanding your question?
@RichJeanes yeah but what about Yes
shows up for all, US, CA
shows up for North America while -US, -CA
shows up for all countries BUT North America.
Or is that not needed?
If we know that a site is explicitly region-specific(such as local/regional banks or gov't sites), then we add it with a country code tag.
If we add a site with just yes
flag, we assume it's global. However, if later somebody reports that this site is not available in their country, then we can easily change yes
into -country
or !country
.
Sounds good. So should we make a new branch for this?
Is this feasible with jekyll?
Will this scheme scale? There are ~196 countries in the world and a company like Google is surely in almost all of them--so we'd show ~196 flags for Google? Do people want to search visually for their flag?
@smholloway We won't be showing all flags by default. Only countries that are explicitly listed.
software: yes
means available globally.
software: usa, can
means available only in US and Canada.
software: -usa
means available globally, except US.
I love it!
And I guess for completeness sake, if we are going to implement this, we should support software: -usa, can
just in case we'll ever come across such situation.
Why not use the top-level domain shortenings? Like us
for usa, se
for Sweden, no
for norway, ie
for ireland, etc.
Not every country might have .TLD to use. I think ISO 3166-1 alpha-3 standard is a better choice.
Or ISO 3166-1 alpha-2? That would make it the same as the .TLD for most countries.
Personally I'd prefer alpha-3 since its names are a bit more logical, but at the same time it seems like it's easier to find icon flags named after alpha-2 such as https://github.com/googlei18n/region-flags or http://www.famfamfam.com/lab/icons/flags/
I just feel like alpha-2 is more widely spread as .TLD often(if not always) use the same letters.
What about flagging sites that are only available in certain countries, like banks or utilities? Do we want to address that at the same time?
@RichJeanes Wouldn't this address it by explicitly setting flags? And if tfa is not available there, it doesn't matter if a site serves only a specific region.
No but it wouldn't have to be displayed for regions where it doesn't apply. Also, we've seen a few banks that use different types of TFA in different regions.
What about an optional region:
tag?
I was thinking about page resources so that instead of potentially having three or four of the same flag in a row for a site, we could put a single instance of the flag next to the name. Whether or not that would actually have an impact on loading resources, I don't know, but it may make a region filtering system easier (or at least more efficient). That way, if a site was listed as only available in one or two specific countries, the filter could just use that region
tag and not have to scan over multiple columns with redundant data. It may not seem like that big of a deal, but the site is starting to get rather large and is only going to get larger and more cumbersome with the backlog of region specific (or labelled "international" because 'MURICA) sites that will get added.
My point is that labelling whole sites as region specific as opposed to just their TFA services could prove to afford fairly significant performance improvements at scale.Consider how long link validation takes already.
We may also want to look into providing the ability to list multiple doc links to allow linking to instructions in multiple languages. Just a thought. That can be split off into another thread if it merits serious discussion.
Would people from other countries prefer a page dedicated to services available in their country? For example, https://twofactorauth.org/sweden (or use the two digit country code as in https://twofactorauth.org/se) could show the services in Sweden.
I like how Sweden is the example country now :smile: GO SWEDEN!
@smholloway Would it be for sites that are available only in Sweden or Sweden and other countries? Would such a page be generated from existing yml or new ones?
In the system I was envisioning each country would have a page with services (un)available in that country; any regional differences would move into a country-specific page rather than trying to present all the data on one page. Instead of having something like region: us, se
or software: -us
there would be a new yml file for each country. I think we could get it done with a single yaml file per country so we don't have to worry about how to classify services. The layout would be something like this:
├── _data
│ ├── backup.yml
│ ├── banking.yml
│ ├── ...
│ └── regional
│ ├── ad.yml
│ ├── ae.yml
│ ├── ...
│ ├── zw.yml
:/ My worry with this kind of layout would be remembering to update the same site in multiple countries.
Why not create full fork and alternative domain for regional services? I do not want to flood the main page local services.
Local forks is a good idea. This allows you to better promote the initiative. This allows you to connect regional Domain, which would be better to fall into the ear. This whole initiative is designed to promote 2FA, and so this point should be important to us,
It also gives the opportunity to join local social networking sites. This provides better publicity in the local environment.
One site makes it impossible to obtain patronage. In Poland, The Ministry of Digital Affairs is very active. I see a chance to get the support of the central government agencies, but will not want to get involved, if it will be a global site. Obtaining patronage adds seriousness of the action. Companies will feel more obliged to improve their security. However, these are just my thoughts and dreams. There are no concrete plans.
Fixed in v3.0
So we've been trying to figure out how to handle "international" pages, right? Well a thought just struck me. What if we separated out region-specific sites? Anyone anywhere (for the most part) can use Google or Facebook, but (for example) the Utilities category that I started to put together only lists services for the States. What if we had a separate page from the main (similar to how we have a Providers page) for region-specific services? Instead of overall categories, the page would be separated into regions (countries?) and would only have a single list each. Or list all of the regions on the page and make them collapsible (or separate pages, something, I dunno, I'm not much of a UI guy) with all of the categories under each one. I've realized that being and American working on a project started by an American and working with mostly Americans (plus a few others :wink:), a lot of sites already listed are very American-centric (look at Banking for Pete's sake). I figure this would let us take a more globally-focused stance in site design and content. Input?