On 08/10/2015 03:12 AM, Jonas Sicking wrote:
Andrew, could you simply pull this data directly from publicsuffix.org
and cache locally?
We don't need a new Web API to be created, no. I figured I'd just check
if there were pending plans for URL/URLUtils to expose this
functionality, or if it would be a slam dunk to add it.
The current driving use-case is for email autoconfig logic, and it's not
a must-have. DNS MX lookups are performed by the Mozilla-hosted ISPDB
with the full result returned. Thunderbird or FxOS email is responsible
for performing the getBaseDomain() transformation to perform a follow-on
ISPDB lookup. Lacking nsIEffectiveTLDService like Thunderbird has, FxOS
email currently does a slice(-2), which is obviously wrong, but has been
largely good enough. I just committed an entry to the ISPDB where it
now is definitely not good enough (ne.jp/ad.jp), hence my query.
FxOS email can just be lazy and also ask for the results of slice(-3)
and/or slice(-4) on top of slice(-2) and correctness can be guaranteed
because the underlying query set should only have results at one level
of domain. In the future the ISPDB host-logic could also be made to
optionally perform the normalization required. (For simplicity/security
the ISPDB server logic is dumb-as-rocks, plus Thunderbird originally
thought Necko might eventually surface MX lookups and the server lookup
was a stopgap. FxOS mail's threat model now depends on the MX lookup on
a non-hostile network since local DNS may not be trustworthy.) Or we
could try and compress-down the public suffix list and cram it into the
mail app. Or temporarily download it and discard it.
Having said that, there are use-cases where it would be useful for
anti-phishing/spoofing defenses, but in general I think that's more a
FxOS browser app issue, and it already has access to a fancier tier of
APIs that the email app does not need/want[1].
Andrew
1: Namely, the browser needs to reliably show the TLD+1 to users in the
location bar (instead of document.title) and ensure that the location
bar is forced to at least transiently become visible when changing
origins/TLD's+1. (Which would also include the transition from
browser-app-not-displayed to browser-app-display-the-url-requested.)
The browser currently is bad about this and accidental mis-clicks that
transition away from the mail app can have bad UX (high latency of app
switching and potential OOM-death of the mail app on low-powered
devices), so the mail app still throws up a modal prompt confirming the
(entire) URL to provide some protection against these things. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1082604 for more context.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
