Closed Bug 1112330 Opened 10 years ago Closed 8 years ago

Setup domain for captive portal detection

Categories

(Cloud Services :: Web Site - Deprecated, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: valentin, Unassigned)

References

Details

Bug 1048131 is currently tracking the implementation of a captive detection service for Firefox Desktop, that would provide reliable signals on whether the user has internet connectivity. We require a page similar to http://detectportal.firefox.com/, but maybe hosted on a mozilla.org domain, that would scale for hundreds of millions of users. In the meeting we discussed whether the addons.mozilla.org would be appropriate, considering that we already use it. However, it seems that it probably can't handle the load, and also traffic to it is logged for metrics purposes. I think that something similar to detectportal.services.mozilla.com, or even detectportal.addons.mozilla.org would be acceptable for this task, provided that there's no logging of requests (it would be pointless anyway), and that the system will scale.
Patrick, any thoughts on the domain and requirements?
Flags: needinfo?(mcmanus)
so I think anything in mozilla.org meets the requirement that someone who controls that delegation already gets a daily trackable (though we don't!) query.. I would just gate the portal detection code on whether or not the addons check is disabled or not. (I assume that's preffable?)
Flags: needinfo?(mcmanus)
Hi Benson, We are starting work on a captive portal UI. That means that as soon as the UI lands in Nightly, we might be getting millions of requests per day to our captive portal page. After it hits release, we are looking at more than a billion requests per day. We need to be sure that our end point can handle all these requests, and that no logging of requests occurs on the server. Also, as Patrick mentioned in comment 2, something under mozilla.org would be preferable.
Flags: needinfo?(bwong)
- we can make subdomains under: mozilla.org, mozilla.com, services.mozilla.com or firefox.com - how are you calculating millions/billions of requests/day? - is it static or dynamic content?
Flags: needinfo?(bwong)
(In reply to Benson Wong [:mostlygeek] from comment #4) > - we can make subdomains under: mozilla.org, mozilla.com, > services.mozilla.com or firefox.com It's up to Patrick which domain we want. > - how are you calculating millions/billions of requests/day? For release, a conservative estimate of 200 mil users x 5 requests/day = 1 billion req/day > - is it static or dynamic content? Static, of a very small size. The response should only contain "success\n".
(In reply to Valentin Gosu [:valentin] from comment #5) > It's up to Patrick which domain we want. > maybe ask bsmedberg to get it aligned with any other automatic activity.
(In reply to Patrick McManus [:mcmanus] from comment #6) > > It's up to Patrick which domain we want. > maybe ask bsmedberg to get it aligned with any other automatic activity. Hi Benjamin, Do you have some input on what subdomain would be most appropriate for the captive portal endpoint? According to comment 4, we have a number of possibilities.
Flags: needinfo?(benjamin)
Typically we use *.mozilla.org endpoints so that's what I would recommend, all else being equal. I don't think it matters from a data/privacy perspective.
Flags: needinfo?(benjamin)
Blocks: 1363651
This is live at http://detectportal.mozilla.org. It's managed by Cloudops. Closing this old bug.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
(In reply to Benson Wong [:mostlygeek] from comment #9) > This is live at http://detectportal.mozilla.org. It's managed by Cloudops. > Closing this old bug. I think the domain is still http://detectportal.firefox.com - right?
yes. Sorry my mistake.
You need to log in before you can comment on or make changes to this bug.