I am planning to build a flutter → web + android app and have three questions:
- In the submission form theres a field:
Website or web app URL
If your app is live, please share the URL
I can stage the web site and provide that URL, but how should I approach staging the APK for the android app (so judges can test it)? Can I also provide that somewhere, maybe comma separated from the web app version of it in the field as a google drive link?
-
Allow listing emails/accounts?
I want to grant access to only judges for the length of the competition, is a mechanism to do this, like email(s) that we can clamp sign ups for? This is the easiest way to prevent abuse while the application is still under development and the more undifferentiated features like monetization/throttling are still being worked out (and less relevant to the actual use case).
-
Credits?
Similar to #2, is there any sort of credits available for Firebase hosting, GCP available for the competition?
1. Staging the APK for the Android App
According to the official rules, you are required to submit an entry form and a video demonstration of your application. While the rules don’t explicitly detail the exact method for providing an APK for judges to test, it’s reasonable to ensure the judges can access and evaluate your app.
You can stage the Android APK and provide the link within the submission form. Using a platform like Google Drive to host the APK and then sharing that link in the submission form along with your web app URL would be a pragmatic approach.
2. Allow Listing Emails/Accounts
You are almost certainly (absolutely) not going to get the email addresses of the judges. Just stage your app at some completely random path on your server, no one is going to find it.
3. Credits for Firebase Hosting, GCP
There aren’t any free credits available for any services related to this competition.
For all other details and specifics, you can refer to the official rules of the Gemini API Developer Competition.
Here are the relevant sections of the official rules you may want to review:
- Submission requirements: Section 5. HOW TO ENTER
- General conditions: Section 9. GENERAL CONDITIONS
Thanks for your response. Your solution for #2 is inadequate - That’s how you get a denial of wallet attack.
If we could assume at the very least their domain is Google.com that would be sufficient.
I mean, yes, in theory… But… if the page is not indexed and your website and server are otherwise reasonably secure the likelihood of anyone stumbling upon your sub-directory babe with a random UUID is vanishingly small—effectively zero.
But, if that’s just simply too much risk for you conceivably bear, you could always just slap some good ol’ Oauth2 on it and either,
- You could assume all judges will have an
@google.com email address and only allow those emails to authenticate and connect. Probably not a great idea.
- Leave it open for anyone to connect, but set up an alert so you can check it to see if it’s a legitimate looking source. Chances are if there was no probing behavior before the authentication attempt you’re in the clear. This allows you to ensure any legitimate judge can access it if, for instance, they have an email from a Google partner company or other affiliate.
- You could just put an API key in the query string of your submission URL and authenticate judges that way. But this runs the risk that the API key might get mangled or stripped out of your URL by whatever process they have for making these things available to judges.
All in all I honestly think you’re way overthinking this and worrying about something which simply isn’t going to happen.
This is an instance where security through obscurity is, honestly, plenty sufficient. I swear >99% of the random attempts against my home server are botnets looking for vulnerable WordPress instances—no one is looking for AI apps they can exploit. Just disallow IP addresses from problematic countries and set reasonable rate limits inside your own application sufficient enough for what you would expect from a couple of simultaneous normal users, get a notification when someone is using your app so you can reach out in real time and see what they’re up to, and you’ll be more than fine.
I suspect you’ll be vastly more likely to end up hurting your chances by introducing any friction into the system since there could be however many untold thousands of entries which need to be judged over the span of 20-days.
But, who knows, maybe Google will give you all the possible email addresses of all the judges who might possibly need to test your app.
¯\_(ツ)_/¯
1 Like
I definitely don’t want to degrade the experience. But as for me and my wallet I’d like something to clamp down for access.
In any other serious professional context (at least that I’ve been in) your security by obscurity in this case wouldn’t be acceptable. Much more do I care about my own personal wallet.
I can tell you with absolute certainty that if you put a web page online, under a completely random directory name, which isn’t indexed and is not linked to anywhere other than in a text field in a Google form, if anyone accesses it who isn’t supposed to, you have a much bigger security concern than an publicly available app—because absent Google and/or the judges being hacked the implication would be someone you don’t know has root access on your server.
If some rando discovering the URL of the open demo app you’ve put online to be judged for this contest is going to bankrupt you, you have bigger configuration concerns than the app’s availability.
I can’t sit idly by while you denigrate security through obscurity, which if properly implemented for a use case like this, is a perfectly valid security scheme.
I’ve given you 4 options to choose from, I’m not personally invested in which (if any) you choose to implement or your wallet, which you’ve weirdly mentioned three times.
You are free do whatever you want, I’m not your dad.
for #2, I decided to try something like Appcheck to mitigate issues and stay the free firebase plan + monitoring and alerting to avoid denial of wallet type attacks.