<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><br></div><div>With apologies, I'm going to take this off the public list and redirect to fxa-staff; there's nothing confidential here, but it feels like the sort of discussion that could accidentally bring up some supposed-to-be-secret details of our production security infrastructure.<br></div><div><br></div><div dir="ltr">On Thu, 20 Sep 2018 at 15:49, Phil Booth <<a href="mailto:pbooth@mozilla.com">pbooth@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Fwiw, I have two somewhat conflicting thoughts related to this:</div><div><br></div><div>1. The email service needs to grow rate-limiting soon and if there's a standalone service available to use already, that will probably save me some time.</div><div><br></div><div>2. Historically I've found the customs server code hard to grok. Part of me dreads the prospect of working with it again.</div><div><br></div><div class="gmail_extra">Of course, extracting it into its own service might also involve improving readability/maintainability, which would abate my dread. But if a 3rd-party option can do the same job (I haven't dug into the ratelimit/limitd links yet), I might be more inclined to take that option.<br></div></div></blockquote><div><br></div><div>FxA does one interesting thing that I haven't seen in other third-party tools, where we sometimes rate-limit by "breadth" instead of "depth".  For example, we allow you to call the /account/status endpoint for a single email address as many times as you like.  But we rate-limit the number of different email addresses that you can call /account/status on in a certain period of time.</div><div><br></div><div>Maintaining this capability may require us to continue to maintain our own service rather than use something off-the-shelf.</div><div><br></div><div><br></div><div>  Ryan<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 20, 2018 at 6:11 AM, Julien Vehent <span dir="ltr"><<a href="mailto:jvehent@mozilla.com" target="_blank">jvehent@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">+alm & g-k</div><div class="m_-4591234188778319736HOEnZb"><div class="m_-4591234188778319736h5"><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 20, 2018, 00:52 Ryan Kelly <<a href="mailto:rfkelly@mozilla.com" target="_blank">rfkelly@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, 20 Sep 2018 at 14:35, Ryan Kelly <<a href="mailto:rfkelly@mozilla.com" rel="noreferrer" target="_blank">rfkelly@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><br></div><div>Hi All,</div><div><br></div><div>Over in github we've been discussing our options of rate-limiting pairing channel creation attempts:</div><div><br></div><div>  <a href="https://github.com/mozilla-services/channelserver/issues/21" rel="noreferrer" target="_blank">https://github.com/mozilla-services/channelserver/issues/21</a></div><div><br></div><div>One obvious approach would be to use the existing fxa-customs-server, and just add some new action types like "createPairingChannel" and "connetToPairingChannel" that the channelserver can send over for checking.  However, the fxa-customs-server is currently run as a private "sidecar" service for fxa-auth-server, exposed only over a localhost interface.</div><div><br></div><div>Does it make sense for us to try to extract fxa-customs-server into its own standalone service that can be accessed by multiple consumers?  Or is that likely to be more work than just adding rate-limiting code directly into the channelserver?</div></div></div></blockquote><div><br></div><div>Another option would be to try running a third-party ratelimiting daemon that can be shared among different services, such as:</div><div><br></div><div>  <a href="https://github.com/lyft/ratelimit" rel="noreferrer" target="_blank">https://github.com/lyft/ratelimit</a></div><div>  <a href="https://github.com/limitd/limitd" rel="noreferrer" target="_blank">https://github.com/limitd/limitd</a></div><div><br></div><div>Which may be less work than adding custom rate-limiting code in channelserver.</div><div><br></div><div>+ulfr for possible opinions from opsec team.</div><div><br></div><div>  Cheers,</div><div><br></div><div>    Ryan<br></div></div></div></div></div>
</blockquote></div>
</div></div><br>_______________________________________________<br>
Dev-fxacct mailing list<br>
<a href="mailto:Dev-fxacct@mozilla.org" target="_blank">Dev-fxacct@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/dev-fxacct" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/dev-fxacct</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div></div>