@myleshorton I think this change to the condition for displaying the alert defeats the whole purpose of the alert.  The point is that if a user doesn't have a fallback already, and we can't read a fallback config, there's no point to that user running Lantern, so we want to show them the alert.  This new logic only shows an alert if the user doesn't have a URL config file.  That misses the case where the user has a url config file, but we can't actually fetch an updated S3 configuration for some reason (e.g. network flakiness).  As it stands, your change will appear to fix the reported problem of the alert dialog being shown, but it doesn't actually address the root cause, which is that we can sometimes have trouble fetchinging the S3 configuration.  What I think is actually needed to fix the bug is to tweak the existing logic to only display the alert if we couldn't fetch an S3 configuration AND we don't already know about fallbacks from fetching it a previous time.  If we don't already persist known fallbacks across runs of Lantern, we should do that too so that even if the first S3 config fetch after starting Lantern fails, as long as we learned about a fallback in a previous run, we can continue to operate.  I think we should also improve the text of the error message, since what we couldn't find isn't just a "configuration", we specifically were unable to determine a fallback for the user.  Making this text clearer would reduce confusion on both the user's and our parts if and when this happens again.