revisit: search engine region

[ghost]

v107 enables region tracking (0203) again, why?

browser.region.network.url is the broader setting which needs to be blocked to prevent mozilla and firefox from knowing your region (region.current, region.home, browser.search.region, doh-rollout.home-region).
browser.region.update.enabled is a specific setting which only controls if firefox is allowed to switch region.home.

So browser.region.network.url is probably the main thing we want and not a just an additional defense-in-depth.

As firefox is now allowed to set browser.search.region we probably need to make 0204 active, too.

Originally posted by @livingentity in #1579 (comment)
Originally posted by @Thorin-Oakenpants in #1579 (comment)

[Thorin-Oakenpants]

is a specific setting which only controls if firefox is allowed to switch region.home

Which is what we wanted. It's doing it's job.

to prevent mozilla and firefox from knowing your region

why? There's nothing wrong with the Firefox app knowing the correct region.

DoH is a roll-out based on region and you are notified and can opt out. Or you can use the pref to opt of the rollout. Besides, the rollout for en-US has been done (not that everyone will stay as en-US).

search region is already set to en-US (0203)

regional locales (intl. resolvedOptions) is for the time being only properly controllable as using en-US with 0210 + 0211 but we hope we can use RFP to enforce the same locale as the primary language (so no more mixing up en-US with en-GB, en-CA, or whatnot, and to also bypass using system formatting, which can be custom), and to make sure the primary language is not messed up (e.g. en,en-US vs en-US,en and other secondary languages)

So I fail to see what the issue is.

[Thorin-Oakenpants]

search region is already set to en-US (0203)

crap, it's inactive, sorry was looking at an old user.js which happened to be open because of something else

PS: I actually set this in my overrides, always have

[Thorin-Oakenpants]

So ... what does the search engine region leak to the search engine?

[ghost]

That's the question: Do we want to make use of the region or not?

Otherwise browser.region.network.url is the current master switch for regions and we could get rid of browser.region.update.enabled instead (or make it defense-in-depth). Personally I prefer that as a cleaner solution because it needs less prefs to flip.
But in the end it's up to what one wants to achieve.

[Thorin-Oakenpants]

once again ... what does the search region leak to engines?

[ghost]

The region obviously which the search engine might or might not uses to serve region based content. That might or might not be desireable (convenience, proxy, etc.).

I don't get this. So your point is that all those region based settings have no privacy value and 0203 is merely a convenience for travellers?

Because if leaking your region to mozilla and your search engine doesn't matter, why bother maintaining several prefs (which were even redundant until now as browser.region.network.url blocked them all anyhow)?

[Thorin-Oakenpants]

So your point is that all those region based settings have no privacy value

No, they don't. The DoH one is for rollout. The regional locales is useless, we have to use en-US and prefs or wait for RFP to cover all languages. And no-one cares if Mozilla looks it up and sets it for you - they're not recording it or selling it.

So the only one I ASKED about was search. Asked twice now. What does the search region leak to engines? Answer that. AFAICT it doesn't change the search engine, it doesn't send any extra parameters to the search engine. For example, I installed Nightly on my computer, - it was an en-US install, I think it was installed via stub and I got to choose en-US. I am NOT in the USA. But my country is en

 en-au: english (australia)
  en-be: english (belize)
  en-ca: english (canada)
  en-gb: english (united kingdom)
  en-ie: english (ireland)
  en-jm: english (jamaica)
  en-nz: english (new zealand)
  en-ph: english (philippines)
  en-tt: english (trinidad and tobago)
  en-us: english (united states)
  en-za: english (south africa)
  en-zw: english (zimbabwe)

And my nightly, which does not have a user.js (well a super minimal one such as sanitizing), has set my regional stuff as en-GB (for example). And the pref matches. But my search engine is still directed to google.com, not google.co.uk

So I'm asking HOW, where, when .. who, why ... does the region leak. Until I know that then what am I supposed to do.

[Thorin-Oakenpants]

Sorry, to clarify ... I am asking because IDK. I don't read all of Firefox's code nor have time to do so. And it's hard to test with a single machine set to a similar search region (i.e the Firrefox build is en-US and my locale is en-somethingelse and my OS locale is the same en-somethingelse, and search engine changes or region checks can take time (IIRC)

Since you seemed to know what the code does, I wanted to make sure that nothing was leaked (to a search engine) or changed on the end-user (e.g. changing their search engine)

Reopening

[Thorin-Oakenpants]

When you setup a new profile, you are assigned a region. The search engine will only change after a continuous period (current 2 weeks) - from whatever build you installed - e.g. on my portables they are en-US, on my installed ones I forget how it went, from stubs for sure. The region is grabbed from IDK, you IP and maybe from your regional locale of the OS.

IDK what exactly happens when a search engine changes: my nightly (no prefs/user.js to affect this) is locale/region en-WHATEVER (not en-US) but my search engine has never changed and stays using com (google search) - but that may just be because I'm en and all en users are .com

What is the criteria for a search engine to change? Is it the regional deals Mozilla have done, e.g. google in the USA and (previously) yandex in Russia? Or does it, or can it, actually change the end target - e.g google.com -> google.de ?

This is super low priority and I'll likely never bother getting to ti, so if anyone wants to find out, help yourself

[Thorin-Oakenpants]

Or does it, or can it, actually change the end target

Ahh, OK, so the pref change triggers the engine change straight away - that makes it easy to test

https://bugzilla.mozilla.org/show_bug.cgi?id=1800662#c3

With the GB to RU switch, the issue is that we're switching from Amazon.co.uk to Amazon.com

Honestly, I do not think this is such a big deal. When you install the app, you will have a default search engine, which you can change (either install one, or whatever). If you use a built in search engine, it's going to be the one that ships with that language (I guess) and if you add one yourself it won't change

So if you are in RU but have a GB search engine (because you are en-GB on your locale), you will stick out. You should be using .com anyway. Behind a VPN? Who cares.

Annoying if you travel overseas for more than two weeks, but correct if you move countries. I am so over this.

@fxbrit should we set the search region (which I think just makes non .com users stick out, e.g. for google at least) or ignore it. I honestly don't care about DEFAULT search engines getting changed

[fxbrit]

I looked some stuff up, to be clear none of this is a privacy or security thing but it's just for future reference if ever needed.

The region is grabbed from IDK, you IP and maybe from your regional locale of the OS.

https://searchfox.org/mozilla-central/source/testing/profiles/common/user.js#28-30

so it uses a "geoip lookup" aka your IP as you rightfully guessed.

What is the criteria for a search engine to change?

https://searchfox.org/mozilla-central/source/services/settings/dumps/main/search-config.json

this is the static dump but it can be updated via remote settings.

---

IMO this is a non-issue and we should leave it alone. most users will change their search engine (at leas the default one) and for the scope of this project the other ones do not matter; trying to match the IP with the search engine location makes little sense: we have no clue of the IP a priori, firefox is geoguessing so that could actually be a good thing as it would match the IP with the region and most importantly I would assume users trust the search engine they set as their default. if they don't then it's their interest to protect the IP.

[Thorin-Oakenpants]

There are valid and good reasons to have the correct region (DoH rollout, how credit cards and addresses etc work and the rollout for that, etc). So that's not an issue. This was about search engines changing on people (after two continuous weeks) which is not likely for most users

But from OP

browser.region.update.enabled is a specific setting which only controls if firefox is allowed to switch region.home

We should remove 0203 entirely so everything works as expected. Maybe even remove 0204

@fxbrit - are you on board to remove both?

---

if they don't then it's their interest to protect the IP

Indeed. And a VPN should "rotate" (sorry, need more coffee for the right term - am knee deep in font whackness)

trying to match the IP with the search engine location makes little sense

Indeed. You've chosen to use that search engine, and you already send them data about your IP (VPN ranges or not) and a bunch of search terms

[fxbrit]

yup, I think we can remove both. do you want to document them for the use cause you mentioned i.e. I travel abroad I don't want my region to change every 2 weeks as a result?

rotate

sounds super right actually 😄

[Thorin-Oakenpants]

if I remove them both, how can I document it?

I travel abroad I don't want my region to change every 2 weeks as a result?

not everyone is a globe trotting superstar like you (also two weeks continuous) - and the search engine being used (e.g. google) doesn't change, only the tld (e.g. .com -> .de) and even then only possibly (depends on the list I guess)

[fxbrit]

oops I forgot we don't have the issue with the out of scope prefs anymore.

I should check what my region has been set to here in Turks and Caicos..

[Thorin-Oakenpants]

72b8ded