On Wed, Sep 20, 2017 at 7:06 AM, Shane Tomlinson <[email protected]> wrote:
> > > On Mon, Sep 18, 2017 at 7:54 PM, Alex Davis <[email protected]> wrote: >> >> 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. >> > > This seems to me to just maintain the status quo. > > 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. > > 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. I agree that there's no middle ground in that case - we either support them properly or we remove them entirely. 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. > AFAICT, Firefox used context=fx_desktop_v1 up until Firefox 45 and our switch to webchannels in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1218022 If then used context=fx_desktop_v2 for a while one release, when we landed this bug for Firefox 46: https://bugzilla.mozilla.org/show_bug.cgi?id=1204714 So IIUC dropping support for those two integrations would disable Fxa login on Firefox 45 and earlier, which seems reasonable to me. That said, I'll note that the fx_ios_v1 broker currently extends fx_desktop_v1: https://github.com/mozilla/fxa-content-server/blob/master/app/scripts/models/auth_brokers/fx-ios-v1.js So we'll have to double-check that we don't accidentally lose test coverage for iOS if we remove the desktop version. > 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. > I can confirm this was intensely painful for all concerned and I'd rather not repeat it... Ryan
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
