Re: [Pearg] I-D Action: draft-irtf-pearg-safe-internet-measurement-00.txt

Hi Ian,

As Eric points out, criteria for shipping software is well outside the scope of this RG. Thus, it should not be used as a basis for specifying measurement practices. More generally, as a document describing safe Internet measurements in a privacy-oriented RG, issues such as code quality are out of scope. While it’s true that software bugs can lead to privacy issues, criteria for preventing bugs is not a topic this group is chartered to work on. That said, being mindful of privacy when conducting A/B testing is good (though not very actionable) advice.

Also, for what it’s worth, I think it’s prudent to consider the advice and recommendations from folks who have done these experiments at scale. 

Best,
Chris, on behalf of the chairs 

On Mon, Jul 8, 2019, at 8:27 AM, Eric Rescorla wrote:
> 
> 
> On Mon, Jul 8, 2019 at 8:00 AM Iain Learmonth <irl@torproject.org> wrote:
> > Hi Eric,
> > 
> >  On 08/07/2019 15:15, Eric Rescorla wrote:
> >  > This seems like the kind of product question that is well out of scope
> >  > for PEARG. Software vendors have a wide variety of processes for
> >  > determining whether a given piece of code is suitable for shipping to
> >  > their users, ranging (at least) from "some developer thought it was
> >  > good" to "multiple detailed code reviews".
> > 
> >  The point is not so much to define what make code suitable for shipping,
> >  but to say that you should not use A/B testing as an excuse to ship code
> >  that you would not have otherwise shipped.
> 
> But again, that's precisely the point of much A/B testing: to verify that the
> code is good enough to ship. It's *part* of the shipping process.
> 
> 
> >  Your criteria for shipping to some users should be the same as the
> >  criteria for shipping to all users. The code quality should be the same,
> >  it should have undergone the same pre-shipping testing, etc. The only
> >  difference should be the feature that is enabled/disabled.
> > 
> >  This is also needed to make the experiment into good science. If you've
> >  got other variables like relaxed review processes then you've introduced
> >  other factors that don't make it a fair comparison between the A/B groups.
> > 
> >  This all comes back to implied consent, and when it is appropriate to
> >  presume that users will be expecting something. If you typically have
> >  stringent review processes, users will expect this from future updates.
> >  You violate the user's expectations, and also their trust, when you push
> >  a shoddy update to them. This is true even if you've only pushed it to a
> >  tiny fraction of your users.
> 
> As I said to Niels, the question of precisely what code to ship to users
> seems well outside the charter of this group, which is focused strictly
> on privacy. Can you please point to some charter text which would
> authorize the group to work on this?
> 
> -Ekr
> 
> 
> 
> 
> 
> > 
> >  Thanks,
> >  Iain.
> > 
> -- 
> Pearg mailing list
> Pearg@irtf.org
> https://www.irtf.org/mailman/listinfo/pearg
>