Re: [Wpack] Problem statement and scope for BoF

[Jeffrey Yasskin <[e-mail]>]

Inline:

On Wed, Aug 7, 2019 at 10:14 AM Salz, Rich <[e-mail]> wrote:

> >    * Other users run out of paid-for data in their mobile plan part-way
>     through a month, or aggressively disable mobile data to make sure it's
>     not wasted.
>
> Strike this item; there is *zero* data to indicate that it is because of
> users (inadvertently) loading web pages, as opposed to other reasons, such
> as push notifications, geo-tracking, and so on.
>

I think our messages crossed and you do think it's ok to mention that users
without data can't load web pages even if they don't have data because of a
native app's misbehavior? I've tried
<https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_bv0PZUxAVtR1GYA/edit#heading=h.c53xc7lulyqi>
"Users can't fetch websites if they've run out of paid-for data in their
mobile plan part-way through a month or if they've aggressively disabled
mobile data to make sure other apps don't waste it in the background."

>    These users currently have to, at best, tell their browsers to
>     pre-fetch sites when they have a cheap real-time connection available
>     or wait until they find such a connection, and at worst, can't browse
>     the content at all.
>
> Yes, this characterizes the previous items.  HOWEVER, I strongly suggest
> that we need a new first item, and this paragraph then becomes diluted.
> Some restructuring will be necessary.
>
> >    Even users with highly-available internet connections want to be able
>     to read and interact with web pages as quickly as possible after
>     clicking a link. Needing to make extra connections in the critical
>     path, and having multiple connections competing for bandwidth without
>     the ability to prioritize, interfere with that goal.
>
> I am not sure I agree with this.  There is a large body of user experience
> studies that show how long a delay can be and zero isn't it. :)
>
> NEW FIRST ITEM.  I believe the following captures the real driver behind
> this work. So much so that this should be the first listed motivator of the
> problem statement. While the other use-cases are important, I am less
> sanguine -- or perhaps just more cynical -- that those things will ever be
> addressed.  The main driver has billions of dollars behind it after all.
>
> * Third-party aggregators, such as social media and search engines, want
> to push external content to the user while the page is being loaded and/or
> displayed. This enables previews, or thumbnails, etc., to be displayed
> without the user committing to seeing the full content (and therefore
> without the origin getting notification). All three parties -- the user,
> the origin, and the aggregator -- want this content to be cryptographically
> secure and tamper-evident.
>

Thank you for the suggested wording. I think it's explained to me one place
we're miscommunicating here and in your ESCAPE paper. While aggregators do
want to push external content to the user while the referring page is being
displayed, it's not to enable previews, since those could be done with a
referring-origin image. The only (I think?) place cross-origin-signed
content is actually required is in loading the next page quickly, at which
point the origin gets notification, either via unsigned subresources,
Javascript, or (not fleshed out yet) the Reporting API
<https://w3c.github.io/reporting/>.

I do still have the impression that the IETF values the "other use cases"
over this one, and that if we want to maximize the chances of those other
use cases actually being addressed, we should emphasize them in the charter.

I prefer to have discussions on the mailing list for greater visibility,
> archiving, and because it's more IETF-like.
>

That works for me. Are you ok with maintaining the current state of the
document in Google Docs, or would you rather it move to Github? My
experience is that Docs is better for collaborative authoring, but if other
folks prefer another storage location, I can deal.

On Wed, Aug 7, 2019 at 10:19 AM Salz, Rich <[e-mail]> wrote:

> >I'm happy to take changes here, but I need those changes to be designed
> to maximize the chance of chartering a working group. The ideal change
> comes with a statement along the lines of "I don't support chartering a WG
> with the current problem/scope/charter, but I would support it after this
> change." Rich, judging from your ESCAPE submission, you don't want the IETF
> to do this work at all, so I worry that if I take your suggestions, it'll
> make the IETF less likely to create the WG. If I've misread your post, and
> you actually think the IETF is enthusiastic to prioritize AMP first, let me
> know.
>
>
>
> So I only get one chance to make suggestions or comments? And if, after
> that one change I’m not willing to commit to supporting your project you
> will ignore me?
>
>
>
> Surely, you don’t mean that, and I am just mis-reading what you wrote, and
> I look forward to seeing your correction.
>
>
Indeed: I don't expect all or even most the changes I take to be "ideal"; I
just need to be confident that they're motivated by increasing the chance
that a WG is created, and then increasing the quality of the work that WG
winds up doing.

Thanks,
Jeffrey