Subject: [Http-grease] Getting started

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Jul 2020 21:19:18 +1000

I think there are two things we need to discuss / figure out to make some progress:

1) How to make clients comfortable enough to start sending grease values. This might be by all acting at the same time, automatically falling back without grease, being able to pull grease values out of production quickly, only greasing in alpha/beta channels, etc. I'd very much like to hear from client vendors about what concerns / limitations they have along these lines.

2) How to get WAF deployments and vendors (and others who are likely to unintentionally cause ossification risk) to react in a timely way so that it's possible to introduce new extensions without unacceptable risk. Note that I'm _not_ stating the goal as "grease everything all the time." My draft tries to outline a process that encourages that, but that's just one example.

What do others think about those? What else should we be focusing on?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 09 Jul 2020 12:43:04 -0700

> On Jul 9, 2020, at 4:19 AM, Mark Nottingham <[email-masked]> wrote:
> 

From an iOS client perspective, one concern is devices that might not get updated and fail to fetch new greasing instructions. Based on that:
- Having an expiration on a given greasing experiment seems important, so a client doesn’t have to do it forever
- Having a robust fallback mechanism should be required
- Deploying on betas (or for us, internal builds) makes this *much* more palatable in general, so it may be good to start out with clients doing it on beta deployments, and only move to production-scale later

Tommy

> Http-grease mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-grease

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 10 Jul 2020 17:20:47 +1000

> On 10 Jul 2020, at 5:43 am, Tommy Pauly <[email-masked]> wrote:
> 

This makes me wonder whether we should just try it with as many clients as can opt in on those channels, with a value that's really simple. As a bonus, we could use it to get more folks to participate here -- e.g., 

Grease-1: "https://bit.ly/http-grease"

... where that link would lead to a document explaining what we're doing, or it could be an implementation-specific link. After appropriate notice and discussion, of course.

Cheers,

---

From: David Schinazi <[email-masked]>
Date: Tue, 21 Jul 2020 17:04:36 -0700

Hi folks,

Adding some thoughts from the Chrome client perspective.
First off, I think this is interesting, important, and timely.
I'll do what I can to ensure Chrome participates in this effort.

As par as deployment process, we would most likely start
this off in Chrome Canary, then proceed through Dev,
Beta and Stable if the breakage is low enough (though
I don't yet know what exact number is "low enough"...).
For this to be a success, I think we're going to need to
deploy this is stable/prod channels to make it impossible
to ignore. We would be able to leverage Chrome's
experimentation framework to allow dynamically configuring
grease parameters and roll things back if the breakage is
way too high.

I would argue against any type of fallback, because if the
user does not see the failure, they won't report it, and it'll
never get fixed. Even something that increases pain by
making the request take longer won't be enough to cause
change.

I think it's important for clients to coordinate, so the breakage
and corresponding triaging is spread across all of us. That said,
I don't think we need to pick an explicit date like we did for the
deprecation of TLS 1.0/1.1. In particular, I think it would be useful
to coordinate on the exact scope of the greasing: what characters
are part of the random set for example. Similarly, we'll all benefit
from sharing results: if the exclamation point character is known
to break 42% of  the Web, then it's not worth greasing that in our
first wave of grease attempts.

Hope this helps,
David

On Fri, Jul 10, 2020 at 12:21 AM Mark Nottingham <[email-masked]> wrote:

> > - Deploying on betas (or for us, internal builds) makes this *much* more
> palatable in general, so it may be good to start out with clients doing it
> on beta deployments, and only move to production-scale later
>
> This makes me wonder whether we should just try it with as many clients as
> can opt in on those channels, with a value that's really simple. As a
> bonus, we could use it to get more folks to participate here -- e.g.,
>
> .... where that link would lead to a document explaining what we're doing,
> or it could be an implementation-specific link. After appropriate notice
> and discussion, of course.
>
> Cheers,
>
>
> --