Closed Bug 1233052 Opened 8 years ago Closed 8 years ago

Switch to a new way of geolocation for client-side code

Categories

(www.mozilla.org :: Bedrock, defect)

Production
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pmac, Unassigned)

References

Details

(Whiteboard: [kb=1931906] )

We're currently using geo.mozilla.org (geodude), but that is slated for decommission some time in 2016. I'm also told that geodude is at 100% capacity, so we're at risk for slow sessions and failed lookups. Let's figure out something else. I know of a couple options at the moment:

1. Use the HTML5 geolocation api (https://developer.mozilla.org/en-US/docs/WebAPI/Using_geolocation)
2. Switch to Mozilla Location Services (https://location.services.mozilla.com/api)
3. Use the MaxMind Database we have on the server side to provide our own geo endpoint on www.m.o.

I've put the above in order of my preference. I think using the HTML5 service is best because it's transparent and asks the user's permission. It also isn't an added drain on any of our services or on bedrock itself. It would take some work over #2 as we'd probably want to add a fall-back of a country list. #2 could be an easy interim step to #1 also as long as they have the capacity. Snippets is switching to #2 now, so we'd have to talk to them about it.
List of pages for reference where we currently use geodude:

https://www.mozilla.org/firefox/37.0/whatsnew/
https://www.mozilla.org/firefox/os/devices/
https://www.mozilla.org/firefox/os/1.1/
https://www.mozilla.org/firefox/os/1.3/
https://www.mozilla.org/firefox/os/1.3t/
https://www.mozilla.org/firefox/os/2.0/
https://www.mozilla.org/firefox/android/
https://www.mozilla.org/firefox/ios/

Some of these we may be able to retire / remove the dependency entirely. For other pages we'll have to look through pmac's list of excellent suggestions to see what is most suited.
Some general thoughts on possible solutions:

1. Use the HTML5 geolocation api.

I like this as a general solution, in that it requires users to opt-in to having their location shared with the page. This is much better in terms of respecting user privacy, and does not require users to actively install content-blocking solutions in order to remain private. It would require us to rethink/rework our UI's and how/when we use this however, and we would also need to consider making the pages accessible for those without support for the native geolocation API. We would also need to use some form of reverse geocoding API, in order to turn the users lat/lon into a country code. We likely have some options here (e.g. mapbox), but there would still be some overhead/cost involved.

2.) Switch to Mozilla Location Services

This would require us to gain an API key for mozorg, and we would need to ensure they can cope with whatever traffic we send their way. There is also no guarantee that this solution won't end up being blocked by certain privacy focused extensions or addons either (same with geo.mozilla.org).

3.) Use the MaxMind Database we have on the server side to provide our own geo endpoint on www.m.o.

Using our own solution to provide an end-point means we are far less likely to have issues with content blocking or addons when we use geo location on the front-end. It does not really improve privacy from a users perspective however, unless we made a way for the user to easily opt in/out. I understand there would also likely be some significant load/maintenance costs involved in providing a service like this.
Some thoughts on solutions for individual pages:

Send-to-device widget
---------------------

The following pages use the send-to-device widget, which uses geo-location on page load to determine if the user is in the U.S. If the user is in the U.S, they can send an SMS or Email. If not, the form defaults to email only:

https://www.mozilla.org/firefox/ios/
https://www.mozilla.org/firefox/android/

We will need to find a new solution here for this widget. I don't think using HTML5 Geolocation API is really a viable solution for this UI, as it would require the user to click an extra button before filling in the form if they want to send an SMS (assuming they are in the U.S). So we likely need to use some other form of API here.

The other option not yet covered would be to not use geo-location at all here, and just show the SMS messaging for the en-US locale. It's not ideal, but still something we could consider (perhaps with an additional string e.g. "*SMS is for U.S. only").

Firefox OS pages
----------------

The Firefox OS pages in Comment 1 currently use geo-location in order to determine the users country. If a phone is available, they see a "Get a Phone" button. If not, they see a "Sign up" button for a newsletter to let them know when a phone is available in their country.

Given that we're no longer selling Firefox OS consumer phones, and the latest 2.5 page does not use geo-location (https://www.mozilla.org/firefox/os/2.5/), I wonder if we could potentially remove dependency from these pages? We could implement an alternative solution from the list above, but if no new Firefox OS phones are coming out, is there much point in people being shown a newsletter signup button? Could we just provide a drop-down list of countries to choose from, like we do on the devices page?

Other pages
-----------

I think we can probably remove geo-location from these pages altogether, unless anyone feels strongly here:

1.) https://www.mozilla.org/firefox/37.0/whatsnew/

This page only uses geo location to auto-select the newsletter language. I think we can just remove this as a dependency since the page is now pretty old and likely low-traffic.

2.) https://www.mozilla.org/firefox/os/devices/

This page only uses geo-location if you come from the /firefox/partners page as a direct referrer. The page is already perfectly accessible without using geo-location, as you can select your country via a drop-down menu.
CC'ing Jen for here thoughts on above
See Also: → 1221894
Hi Alex and Pmac-

I like your recommendation to use the HTML 5 geolocation api, in particular for the privacy and transparency reasons discussed above.

I do think that we can remove geolocation from the 37 whatsnew page right now, and from the Firefox OS pages in the next 4-6 weeks, as those pages will most likely be removed from the site.

However, that brings us to the "send to device" widget.  I agree with Alex that the HTML 5 geolocation api isn't an ideal solution for the widget, due to the extra user permission opt-in.  Could we show it to en-US only, state "valid only for US phone numbers," and error-check the form to confirm a valid US phone number (+1 xxx xxxx) had been entered?  The two problems with that are 
1.  We will miss es-* users with valid US phone numbers and 
2.  We will validate Canadian phone numbers

We have the SMS country restriction so that we aren't paying high data rates outside the US to send SMS messages.

I guess I would opt for Option #2 (Mozilla Location Services) for the Send to Device widget use case.

Thought?

-Jen
Whiteboard: [kb=1931906]
I agree for the Send to Device widget, using Option #2 (Mozilla Location Services) might be the best bet.
I agree with option #2. I don't like going en-US only. We already do the phone number validation, but like you said it doesn't catch some other countries that also use the "1" country code.
I'm going to contat the MLS team using the email address at: https://location.services.mozilla.com/api and request an API key for mozorg. I'll CC both Jen and Paul to keep folks in the loop.
Hi, Hanno from the MLS team here. You can needinfo me if you have questions, instead of going through out-of-band email.

For your own use, to you have any estimate about the number of requests per second or per day that you would send to MLS? Any rough low/high estimate would help us plan.

We are currently switching over snippets to MLS, testing in non-release builds so far. The code they use is at https://github.com/mozilla/snippets-service/pull/139/files#diff-3adb3669370af06c37adc916ba7b7c3cR374 - you may be able to steal that code.

As a key you can use ec4d0c4b-b9ac-4d72-9197-289160930e14 for all stage/prod sites. The key isn't a secret, but helps us to attribute traffic and errors back to a specific user.
> For your own use, to you have any estimate about the number of requests per second or per day that you would send to MLS? Any rough low/high estimate would help us plan.

Jen, could you please provide some info on the total number of daily visits to each of these pages?

https://www.mozilla.org/firefox/android/
https://www.mozilla.org/firefox/ios/

This would likely give us a good indicator.
Flags: needinfo?(jbertsch)
I'm handling the removal of the old Firefox 37 /whatsnew page in Bug 1237960
Depends on: 1237960
Depends on: 1239863
(In reply to Alex Gibson [:agibson] from comment #10)
> > For your own use, to you have any estimate about the number of requests per second or per day that you would send to MLS? Any rough low/high estimate would help us plan.
> 
> Jen, could you please provide some info on the total number of daily visits
> to each of these pages?
> 
> https://www.mozilla.org/firefox/android/
> https://www.mozilla.org/firefox/ios/
> 
> This would likely give us a good indicator.

/ios is about 6,000 visits per day
/android is about 22,500 visits per day
Flags: needinfo?(jbertsch)
(In reply to Jennifer Bertsch [:jbertsch] from comment #12)
> (In reply to Alex Gibson [:agibson] from comment #10)
> > > For your own use, to you have any estimate about the number of requests per second or per day that you would send to MLS? Any rough low/high estimate would help us plan.
> 
> /ios is about 6,000 visits per day
> /android is about 22,500 visits per day

Thx so much!

Those numbers are well below anything we'd be worried about. We have switched over snippets traffic on Monday which is generating that much traffic in about a minute :))

So from the MLS side, feel free to switch over.
Depends on: 1242610
Filed Bug 1233052 to switch the send to device widget to use MLS.
All the dependent bugs have now been resolved and a search of the bedrock code base for "geo.mozilla.org" returns zero results: 

https://github.com/mozilla/bedrock/search?utf8=%E2%9C%93&q=%22geo.mozilla.org%22&type=Code

Closing this as resolved, thanks all!
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.