<div dir="ltr"><div class="gmail_extra"><div class="gmail-h5"><br><div class="gmail_quote">On Wed, Sep 20, 2017 at 7:06 AM, Shane Tomlinson <span dir="ltr"><<a href="mailto:stomlinson@mozilla.com" target="_blank">stomlinson@mozilla.com</a>></span> wrote:<br><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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Sep 18, 2017 at 7:54 PM, Alex Davis <span dir="ltr"><<a href="mailto:adavis@mozilla.com" target="_blank">adavis@mozilla.com</a>></span> wrote: <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"><span class="gmail-m_-255515167139115378m_-6124494321562078898gmail-"></span><div>Talking to Karlof in SF on Friday, he proposed something similar. Seems like the second bullet would make the most sense. We stop fixing old versions but don't prevent users from using them. This way we can be a bit more aggressive with which version we want to support and it encourages users to update.</div></div></blockquote><div><br></div></span><div><div>This seems to me to just maintain the status quo.</div><div><br></div><div><div>The implicit assumption in not removing support for legacy integrations is that "keeping code around" has little to no cost. Keeping old code always has a cost, human and monetary. Being blunt, continuing to support legacy browsers is *already* slowing our development cycle, as a result, every feature costs more than it needs to. Not only that, but if we leave the code in place largely unmaintained, we have a security footgun waiting to happen.<br></div></div></div><div><br></div></div></div></div></blockquote><div><br></div><div>You make a good point here that may not be obvious to casual readers of the thread - "support for older browsers" can mean something very different for FxA than it might mean for your usual website.  We're not a case of "older browsers don't support this fancy new styling feature we want to use" where it may be fine to just let the experience degrade.  We have a custom event-based communication protocol that's used to drive the signed-in state of the browser, and thanks to the product evolving over time we actually have several such protocols.</div><div><br></div><div>I agree that there's no middle ground in that case - we either support them properly or we remove them entirely.<br></div><div><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 class="gmail_extra"><div class="gmail_quote"><div><div><div>I advocate for a more proactive approach - I want to explicitly remove support for fx_desktop_v1 and fx_desktop_v2. I want to remove the code. I want to remove the tests. I argue that in the long run, this is the most responsible thing we can do for both Mozilla and our users.<br></div></div></div></div></div></div></blockquote><div><br></div><div>AFAICT, Firefox used context=fx_desktop_v1 up until Firefox 45 and our switch to webchannels in this bug:</div><div><br></div><div>  <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1218022">https://bugzilla.mozilla.org/show_bug.cgi?id=1218022</a></div><div><br></div><div>If then used context=fx_desktop_v2 for a while one release, when we landed this bug for Firefox 46:</div><div><br></div><div>  <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1204714">https://bugzilla.mozilla.org/show_bug.cgi?id=1204714</a></div><div><br></div><div>So IIUC dropping support for those two integrations would disable Fxa login on Firefox 45 and earlier, which seems reasonable to me.</div><div><br></div><div>That said, I'll note that the fx_ios_v1 broker currently extends fx_desktop_v1:</div><div><br></div><div>  <a href="https://github.com/mozilla/fxa-content-server/blob/master/app/scripts/models/auth_brokers/fx-ios-v1.js">https://github.com/mozilla/fxa-content-server/blob/master/app/scripts/models/auth_brokers/fx-ios-v1.js</a></div><div><br></div><div>So we'll have to double-check that we don't accidentally lose test coverage for iOS if we remove the desktop version.<br></div><div><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 class="gmail_extra"><div class="gmail_quote"><div><div><div><br></div><div><div>Finally, what do we do if a major security problem is found in the unmaintained code? Do we ignore it? To me, that's the worst of all, that's downright irresponsible. We fixed security problems in Persona right up to the end, because it was the right thing to do. It was painful. I can't speak for Ryan, but I know I would have rather spent that time making FxA better instead.</div></div></div></div></div></div></div></blockquote><div><br></div><div>I can confirm this was intensely painful for all concerned and I'd rather not repeat it...<br></div><div> </div></div><div class="gmail_quote"><br></div><div class="gmail_quote">   Ryan</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div></div></div></div>