Timeline for Google App Engine [app]s - We are all on the same quota!
Current License: CC BY-SA 2.5
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 31, 2010 at 14:46 | comment | added | Nick Johnson | @systempuntoout In an ideal world with unlimited IPs and no cloud solutions with shared egress, I'd agree. As it is, the world isn't ideal, and anything that limits on IP either needs to special case large heterogenous sources of egress traffic, or implement keys/access tokens. | |
| Oct 31, 2010 at 14:45 | comment | added | Nick Johnson | @Steffen That's correct - distinguishing on IP plus AppId is the right way to limit per 'user' for App Engine sources. | |
| Oct 30, 2010 at 16:20 | comment | added | systempuntoout | @Steffen I disagree that IP+AppId is an appropriate solution also with this statement. API should be coded without custom permission (in this case the google range of IPs.); handling specific cases with custom IF is a terrible idea. The custom workaround, although temporary, is far more generic and usable (also outside GAE). | |
| Oct 28, 2010 at 17:28 | comment | added | Steffen Opel | @Nick - I've hoped for and expected something along these lines, so thanks for jumping in with an authoritative statement! Does this imply that @Kevins assumption of IP+AppId being trivially forged has actually been unfounded and IP+AppId is an/the appropriate solution instead, so all this would have been much ado about nothing (including the just released custom workaround)? | |
| Oct 28, 2010 at 15:14 | comment | added | Nick Johnson | AppID isn't trivially forged: We (App Engine) include the App ID in the user-agent header, and we don't let users set the user-agent header on outgoing requests. If the IP comes from our pool (_netblocks.google.com), you can trust that the App ID in the user-agent is accurate. | |
| Oct 20, 2010 at 21:06 | comment | added | Kevin Montrose | @Shay - How would the key owner know the key had been leaked? We can't force them to check any metrics. The burden ultimately falls on the SO team. Trying to certify [app]s (high rep on anything but SO is irrelevant, and its a stretch even on SO; security is not easy) is going to take us down the App Store rabbit hole, which is not even worth considering. | |
| Oct 20, 2010 at 21:00 | comment | added | Shay Erlichmen | The key revocation can be done automatically by the key owner without any intervention on your behalf. The problem is how do you certified an application, I would start with ones that have a decent reputation on one of the SE sites. | |
| Oct 20, 2010 at 20:33 | comment | added | Kevin Montrose | @Dan - how do we get the domain? If it comes across in the request, its easily forged. We can't look it up based on the IP, because thats shared. Its equivalent to any of the other suggestions, and just as flawed. Trust me, alot of thought went into how quotas work; and we settled on "the way everyone else has been forced to do it." Its not ideal, but its the reality of the internet as it exists today. | |
| Oct 20, 2010 at 20:30 | comment | added | Dan Dumitru | @Kevin - You haven't said anything about Key + Top level domain. I don't know how/if that would work, but it seems feasible... | |
| Oct 20, 2010 at 20:19 | comment | added | Kevin Montrose | @Shay - that's an awfully Utopian outlook. And remember, we'd have to do that for every Google App Engine [app] (or similar service). Logistically, handling that many potential key revocations is a nightmare. | |
| Oct 20, 2010 at 20:06 | comment | added | Shay Erlichmen | @Kevin why do you think that the key will leak? If the code runs on the server no one will see it and its the best interest of the key owner to take care so that the key won't leak. If worse come to worse and the key leak, the owner will notice and request a new key. | |
| Oct 20, 2010 at 18:53 | comment | added | Kevin Montrose | @Shay - how do we identify those [app]s? They'd have to have a dedicated IP already, or its just a (historically, short) matter of time before the key is leaked. Now, if an [app] is already on a dedicated IP we can raise the quota (this has already been done for some [app]s, in fact). | |
| Oct 20, 2010 at 18:50 | comment | added | Shay Erlichmen | How about white listing certified [app]s? Those apps will be throttled based on key only. | |
| Oct 20, 2010 at 18:36 | history | answered | Kevin Montrose | CC BY-SA 2.5 |