How is the Firebase Remote Config rate limit counted?

Question

I am using Firebase Remote Config to store a secret key for a mobile app ( I do not want to include in client app due to security problems).

The problem is I know that fetching config from server many times in a short period of time can throw a throttling exception. In a production app there is a limit of 5 requests per hour but I do not know if this limit is count per user or globally.

This is the code I have:

//first search cached result, if present
    String key = FirebaseRemoteConfig.getInstance().getString("key");
    if(key != null && !key.isEmpty()){
        setKeyAndGoHome(key);
    }else {
        //no key present, let's fetch it from config
        FirebaseRemoteConfig.getInstance().fetch().addOnCompleteListener(new OnCompleteListener<Void>() {
            @Override
            public void onComplete(@NonNull Task<Void> task) {
                if(task.isSuccessful()){
                    FirebaseRemoteConfig.getInstance().activateFetched();
                    //key is cached 12 hours
                    String key = FirebaseRemoteConfig.getInstance().getString("key");
                    setKeyAndGoHome(key); 
                } else {
                    //this can happen due to a throttling exception
                }

            }
        });
    }

This is very important because without this key my app can not work. I need to know if throttling exception condition can be reached.

Do you know how is the limit counted?

Thanks.

Brott

Where are you getting the 5 per hour from ? This would imply FIRRemoteConfig.remoteConfig().fetch(withExpirationDuration: 720) is never throttled. – Kentigera

@RyanHeitner Its's there in the docs see this: firebase.google.com/docs/remote-config/android#caching – Magdala

Answer 1

The counts are maintained for each app instance. In other words, for each device on which your app runs. I confirmed this by repeatedly running code similar to yours on one device until the fetch status was LAST_FETCH_STATUS_THROTTLED. I then ran the same app on a different device, which fetched successfully.

When you think about the intended application for FirebaseRemoteConfig, it couldn't work if the fetches by all instances of an app were limited to a small number, like 5.

In your post you used the term "user". Note that FirebaseRemoteConfig does not require a signed-in user and does not provide any capability to deliver configuration parameters based on a specific user ID, as it does for other things such as app version, device language, or country.

Because you are considering using Remote Config "to store a secret key", you should be aware of this warning in the documentation:

Don't store confidential data in Remote Config parameter keys or parameter values. It is possible to decode any parameter keys or values stored in the Remote Config settings for your project.

Cygnus

So much thanks @qbix. I did not read that part of the documentation so I definitely won't use Remote Config to store the key. – Brott

Are there still security risks if you don't store default configs in your xml ? – Burson

@BabalolaTiwa: That is best answered by Firebase Support. – Cygnus

If you get throttled, does it return the cached result in the meantime? – Kinna

Answer 2

It is counted as 5 times per hour per device per instance of app. If you clear data the app, this limit will be reset. You can see this video by Firebase Remote Config Product Manager starting at 03:50 sec for more info on this question - https://www.youtube.com/watch?v=Vn8X-KQsb6w&t=230s

Poult

Hi there, great sharing on the video. It clears up some question but it seem to contradict some part of documentation / other videos. Specifically, do you happen to know where can I find more documentation about the service side throttling as mentioned at the bottom of the documentation here: firebase.google.com/docs/remote-config/use-config-android – Betti

I guess it will be same as FCM service limit since remote config changes are pushed like FCM messages. – Poult

If you want to maintain a more dynamic data, probably then you should use Firebase Realtime Database... – Poult