Subject: [Wpack] Problem statement and scope for BoF

From: Jeffrey Yasskin <[email-masked]>
Date: Mon, 5 Aug 2019 10:49:34 -0700

I've drafted an initial problem statement and scope for the WPACK
working group we're hoping to create at a BoF at IETF106 in Singapore.
I've pasted it below, and you can suggest changes at
https://bit.ly/wpack-draft-charter. I intend to draft a charter once I
have some indication that the group here likes the scope I'm
proposing.

Thanks,
Jeffrey

Problem
=======

There are large populations of users who have trouble making direct
connections to HTTPS origin servers over the public internet. For
example:

* 55% of internet users live in countries where political, social, or
religious content was blocked online.
(https://freedomhouse.org/sites/default/files/FOTN_2018_Final%20Booklet_11_1_2018.pdf).

* 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.

* Others use satellite connections with high latency and packet loss.
Anecdotally, see
https://meyerweb.com/eric/thoughts/2018/08/07/securing-sites-made-them-less-accessible/.

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.

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.

All of these users deserve to know whether the content they're reading
or application they're running actually comes from the origin it
claims, and the publishers of those origins value their users being
able to verify that the content is authentic. Both groups also value
the users' ability to store data within websites and web applications
(e.g. preferences and content they've created) and have it available
the next time they load the same URL.

Scope
=====

1. Define a way to package the public portion of one or more websites
or web apps into one or more files that can be distributed and used
without a direct connection to the origin server.

2. Define a way to sign these packages such that the result gives the
recipient confidence in the integrity and authenticity of what they
received. This work will ensure that a client loading a Web Package
signed using the initial specification has security and privacy
properties that are at least as good as a transferring the contained
resources over HTTPS+TLS1.3 from the publishers' origin server(s)
except that:

    a. Packages do not guarantee confidentiality, but if the channel
that transfers the package provides confidentiality guarantees,
packages at most compromise that by revealing information to the
original origin server of the resources in the package and by making a
TLS1.3-or-later private connection to that origin server.

    b. Packages only guarantee their contents were vouched by the
origin servers' keys within the life of the signature, not during the
life of the connection(s) that transferred them.

    c. Packages do not provide any of the security "guarantees" of the
DNS system.

    d. A package generated for one client can be shared to other clients.

    e. TBD: Are the above sufficient? Can/should we give the WG
permission to change this list?

3. Optionally define a way for clients to check that an origin server
still vouches for its package in real time.

4. Define a way for an end-user to package their view of a site in
order to show a peer what they saw. This could just be an update of
RFC2557 (MHTML) but could instead be an un-signed variant of the same
format as above. This kind of package will not guarantee integrity or
authenticity from the origin server, but might from the end-user who
packaged the site.

5. Define the resulting security and privacy model and compare it to
the status quo security and privacy model of HTTPS. Search for places
the existing web platform depends on the fact that HTTPS provides
transport security and describe how those have to change or not given
Packaging's addition of object security. This may involve working with
W3C groups like WebAppSec and PING.

6. Formats that this group defines should be usable efficiently:

    a. When individual contained resources are either small (~10s of
bytes) or large (~GB),

    b. When the total number of contained resources is either small
(1) or large (thousands for the initial format with enough
extensibility for an update to expand it to millions or billions),

    c. When the total size of all contained resources is either small
(~KB) or large (~TB (matching El Paquete Semanal in Cuba) initially,
with enough extensibility for an update to expand it to EB), and

    d. When the format is either streamed to the client or loaded from
a slow but random-access medium like an SD card.

7. Ensure that any formats or protocols this group defines can be
migrated to better cryptography when their original cryptography is
broken.

8. As long as it doesn't compromise or delay the above goals, try to:

    a. Support signed statements about the content beyond just
assertions that it's the representation of a particular URL. For
example, that it appears on a transparency log, that it passed a
certain kind of static analysis, or that a particular real-world
entity vouches for it.

    b. Address the threat model of a website whose frontend might be
compromised after a user first uses the site.

    c. Support books being published in the format.

    d. Support long-lived archival storage.

    e. Optimize transport of large numbers of small same-origin resources.

    f. Allow the format to be used in self-extracting executables.

    g. Allow publishers to efficiently combine sub-packages from other
publishers.

Out of scope
------------

1. DRM

2. A way to distribute the private portions of a website. For example,
WPACK might define a way to distribute GMail's application but
wouldn't define a way to distribute individual emails without a direct
connection to GMail's origin server.

3. Defining the details of how web browsers load the formats and
interact with any protocols we define here. The W3C and/or WHATWG are
more appropriate fora for that effort.

4. A way to automatically discover the URL for an accessible package
that includes content for a blocked or expensive-to-access URL that
the user wants to browse.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 5 Aug 2019 23:27:47 +0000

Commenting only on the "problem" part of your post; I reserve the right to comment on other parts later :)

I am surprised that search carousel and AMP isn't mentioned, as frankly it is the use-case with the most economic incentive/impact. Honesty compels us to explicitly mention it, plainly, and first.

We have seen no evidence that this is done because of surfing, as opposed to tracking or other app activity.

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 7 Aug 2019 10:04:16 -0700

On Mon, Aug 5, 2019 at 4:28 PM Salz, Rich <[email-masked]> wrote:

> I am surprised that search carousel and AMP isn't mentioned, as frankly it
> is the use-case with the most economic incentive/impact. Honesty compels us
> to explicitly mention it, plainly, and first.
>

The AMP and Search Carousel use case is mentioned as "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." The use case
is broader than just one framework or piece of search result UI, so it
seemed wrong to call out particular brands.

Further, my impression of IETF charters is that they discuss and prioritize
the goals of the IETF working group, not just the goals of the company
employing the individuals who are proposing the WG. My impression is that
the IETF sets a lower priority on fixing the AMP URL problem than improving
access to the global internet, so I wrote the higher priority use case
first.

It's true that a lot of Google's investment in the problem is driven by
trying to fix things around AMP, but I think it's fair to solve a problem
for less-wealthy users by using funding from a wealthier client who can
also benefit from the same solution.

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.

> to tracking or other app activity.

I agree. The inference I'm going for here is that, if users have turned off
or run out of their data, even because of native-app misbehavior, they
can't then browse to and install a web app. I'm having trouble coming up
with wording that would make that clearer without being too wordy. Any
ideas?

Jeffrey

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 7 Aug 2019 12:12:19 -0500

> you actually think the IETF is enthusiastic to prioritize AMP first, let me

Well, given the recent breadth of discussion around expanding the
Internet threat model, there's also been a bit of introspection about
the way we think about the work we do in general.  So that we are not
just going to consider what the stated goals are (and whether they can
be achieved), but what the side effects of doing that work would be, and
whether there are other (potentially harmful) consequences of building a
given technology.  The IAB has explicitly indicated that the risk of
consolidation into a small number of service providers is something they
are concerned about, and so if one should expect them (and, presumably,
the IESG as well) to take that risk into account when considering
chartering new work.  Having an honest discussion of what the possible
and likely side effects of a given technology could be seems to be a
generally helpful thing for the IAB and IESG in their consideration of
proposed ne work, and I for one would welcome such a discussion here.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 7 Aug 2019 17:14:15 +0000

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.

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.

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.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 7 Aug 2019 17:19:34 +0000

>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.

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 7 Aug 2019 11:20:46 -0700

On Wed, Aug 7, 2019 at 10:12 AM Benjamin Kaduk <[email-masked]> wrote:

> > > Commenting only on the "problem" part of your post; I reserve the
> right to
> > > comment on other parts later :)
> > >

That's a great point, and I'm adding a section
<https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_bv0PZUxAVtR1GYA/edit#heading=h.neomzorgyz5f>
for it to my document. However, I don't have very good content for that
section. We had the ESCAPE workshop partly to try to find ways that Web
Packaging might increase the risk of consolidation, and Martin is writing
the report from there, but I didn't come away with any mechanisms that seem
likely to have a big effect.

Martin, do you have a good list of ways folks are worried that Packaging
will centralize service providers?

Ben, do you have any examples of charters that have incorporated this kind
of discussion? I'd like to be able to copy the structure if possible.

Thanks,
Jeffrey

---

From: "Kaduk, Ben" <[email-masked]>
Date: Wed, 7 Aug 2019 18:39:32 +0000

On 8/7/19, 11:21, "Jeffrey Yasskin" <[email-masked]> wrote:
 
>    Ben, do you have any examples of charters that have incorporated this kind of discussion? I'd like to be able to copy the structure if possible.

Unfortunately not; my understanding is that it's been a fairly recent revelation that we should explicitly be thinking about our work in this way.

Sorry,

Ben

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 7 Aug 2019 11:45:57 -0700

On Wed, Aug 7, 2019 at 11:39 AM Kaduk, Ben <[email-masked]> wrote:

> >    Ben, do you have any examples of charters that have incorporated this
> kind of discussion? I'd like to be able to copy the structure if possible.
>
> Unfortunately not; my understanding is that it's been a fairly recent
> revelation that we should explicitly be thinking about our work in this way.
>

No worries. I mostly expected that but was hoping to be surprised. :) We'll
make something up and iterate.

Thanks,
Jeffrey

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 7 Aug 2019 18:46:44 +0000

> The use case is broader than just one framework or piece of search result UI, so it seemed wrong to call out particular brands.

I did not mention any brands in my note, I only mentioned two use cases.

>The inference I'm going for here is that, if users have turned off or run out of their data, even because of native-app misbehavior, they can't then browse to and install a web app. I'm having trouble coming up with wording that would make that clearer without being too wordy. Any ideas?

I think you just wrote it in the sentence above. :)

---

From: Jeffrey Yasskin <[email-masked]>
Date: Wed, 7 Aug 2019 16:22:37 -0700

Inline:

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

> 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."

> 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.
>
> 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 <[email-masked]> 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
> 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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 08 Aug 2019 09:52:38 +1000

On Thu, Aug 8, 2019, at 04:21, Jeffrey Yasskin wrote:
> [...] for it to my document. However, I don't have very good content for that section. We had the ESCAPE workshop partly to try to find ways that Web Packaging might increase the risk of consolidation, and Martin is writing the report from there, but I didn't come away with any mechanisms that seem likely to have a big effect.

I agree that there wasn't much at the workshop that suggested how this could avoid some of the consolidation effects.
> 
> Martin, do you have a good list of ways folks are worried that 
> Packaging will centralize service providers?

Mozilla's position paper has my best thinking on that subject, but a few points for the purposes of summary...

The consolidation effects might be felt in several ways: in terms of driving traffic to sites that have the resources to preload links, in terms of inventivizing provision of content for majority clients, and as a secondary effect of raising the cost of business for publishers.

The latter point is not one standards organizations are well-equipped to handle.  It's a natural byproduct of having more standards.  There are two ways of dealing with that: 

1. Stop adding to the pile.  I know it's hard to tell engineers not to engineer, so I don't expect this to happen.  New stuff is just too appealing.

2. Having more and more accessible software for handling any complexity.  For instance, HTTPS didn't really take off until we had really good support infrastructure.  Jeffrey has done some of that with the tools around building packages, but that's a very small part of the picture.  We need more and better tools, including cognitive tools for understanding the effect of this sort of change.  The availability of those tools will always lag standardization.  I might speculate and say that the extent to which consolidation is driven by this sort of effort will depend on how big that lag is.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 8 Aug 2019 11:46:46 +0000

> 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.

My motivation is to increase what I see as the accuracy of the statement.  We’re all like the blind people and the elephant I guess.

Thanks.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 8 Aug 2019 21:35:49 +0000

I’ll review and comment on the actual problem statement later; right now, I’m replying solely to this e-mail.

Thank you for clearly stating your standard for taking changes; I would submit that it’s the wrong standard.  The point of a BoF is not the formation of a working group.  It’s to determine whether the IETF as a whole desires to take up a certain project – whether the project is clearly defined and there are enough people interested in doing the work.  If a change to the problem statement and scope makes it easier for the IETF to make that assessment, it’s beneficial, even if the eventual assessment is that the IETF doesn’t want to do it.

Not to say that we do or don’t – but I believe your role is to help the IESG make an informed decision, not merely to shepherd them to a particular predetermined decision.

From: Wpack <[email-masked]> On Behalf Of Jeffrey Yasskin
Sent: Wednesday, August 7, 2019 1:04 PM
To: Salz, Rich <[email-masked]>
Cc: [email-masked]
Subject: Re: [Wpack] Problem statement and scope for BoF

On Mon, Aug 5, 2019 at 4:28 PM Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:
Commenting only on the "problem" part of your post; I reserve the right to comment on other parts later :)

The AMP and Search Carousel use case is mentioned as "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." The use case is broader than just one framework or piece of search result UI, so it seemed wrong to call out particular brands.

Further, my impression of IETF charters is that they discuss and prioritize the goals of the IETF working group, not just the goals of the company employing the individuals who are proposing the WG. My impression is that the IETF sets a lower priority on fixing the AMP URL problem than improving access to the global internet, so I wrote the higher priority use case first.

It's true that a lot of Google's investment in the problem is driven by trying to fix things around AMP, but I think it's fair to solve a problem for less-wealthy users by using funding from a wealthier client who can also benefit from the same solution.

I agree. The inference I'm going for here is that, if users have turned off or run out of their data, even because of native-app misbehavior, they can't then browse to and install a web app. I'm having trouble coming up with wording that would make that clearer without being too wordy. Any ideas?

Jeffrey

---

From: Jeffrey Yasskin <[email-masked]>
Date: Thu, 8 Aug 2019 17:02:17 -0700

Thanks Mike. I agree that a clear statement after the BoF that ~"the IETF
does not want to take up this project" would be one of the two useful
outcomes, even though it's not the outcome I prefer.

If the problem statement, scope, and charter do not "maximize the chance of
chartering a working group", there's no way to get that clear statement,
since one could tweak them to call the decision into question.

I don't have a lot of experience with BoFs at the IETF, but it seems like
the right place to add information that will help inform the IETF would be
in parallel I-Ds and during the presentations at the BoF. Would it make
sense to invite Rich or another skeptic to give one of those presentations?
I'd be happy to review it for factual accuracy like I did with Mozilla's
position paper. You can talk to MT about how that went. This does
contradict the advice in https://tools.ietf.org/html/rfc5434#section-4,
which recommends avoiding "presentations that do not directly support the
goal" where "the goal is to form a WG". But think I'd rather have the room
evaluate an organized presentation about why the IETF shouldn't do this
than disorganized questions at the microphone.

Am I still missing the point?

Thanks,
Jeffrey

On Thu, Aug 8, 2019 at 2:35 PM Mike Bishop <[email-masked]> wrote:

> Thank you for clearly stating your standard for taking changes; I would
> submit that it’s the wrong standard.  The point of a BoF is not the
> formation of a working group.  It’s to determine whether the IETF as a
> whole desires to take up a certain project – whether the project is clearly
> defined and there are enough people interested in doing the work.  If a
> change to the problem statement and scope makes it easier for the IETF to
> make that assessment, it’s beneficial, even if the eventual assessment is
> that the IETF doesn’t want to do it.
>
>
>
> Not to say that we do or don’t – but I believe your role is to help the
> IESG make an informed decision, not merely to shepherd them to a particular
> predetermined decision.
>
>
>
> *From:* Wpack <[email-masked]> *On Behalf Of * Jeffrey Yasskin
> *Sent:* Wednesday, August 7, 2019 1:04 PM
> *To:* Salz, Rich <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Wpack] Problem statement and scope for BoF
>
>
>
> Further, my impression of IETF charters is that they discuss and
> prioritize the goals of the IETF working group, not just the goals of the
> company employing the individuals who are proposing the WG. My impression
> is that the IETF sets a lower priority on fixing the AMP URL problem than
> improving access to the global internet, so I wrote the higher priority use
> case first.
>
>
>
> I agree. The inference I'm going for here is that, if users have turned
> off or run out of their data, even because of native-app misbehavior, they

---

From: Jeffrey Yasskin <[email-masked]>
Date: Mon, 12 Aug 2019 15:48:32 -0700

Thanks for the summary. I've made sure everything here is mentioned in the
draft charter document:

> The consolidation effects might be felt in several ways: in terms of
driving traffic to sites that have the resources to preload links

https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_bv0PZUxAVtR1GYA/edit#bookmark=kix.f8rqaam5jvj3

> in terms of inventivizing provision of content for majority clients,

https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_bv0PZUxAVtR1GYA/edit#bookmark=id.ehwkcplglqgw

> as a secondary effect of raising the cost of business for publishers.

https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_bv0PZUxAVtR1GYA/edit#bookmark=id.ewnchx4da6jc
and
https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_bv0PZUxAVtR1GYA/edit#bookmark=id.knz0ld5p7r8f

I think I've also included all the concrete mechanisms you pointed out in
https://www.iab.org/wp-content/IAB-uploads/2019/06/mozilla.pdf.
Specifically:

The "Centralization and control" section is covered by
https://docs.google.com/document/d/1OUZcl6yQSJ5eZxMrbo6O2tVRW_U_bv0PZUxAVtR1GYA/edit#bookmark=kix.acmvx6oznsq,
I think. There is additional discussion about the aggregator ranking power
in that section, but no further statements about web packaging that I could
find.

The "certainly has the effect of applying pressure toward consolidation of
market share in a few worrying ways" paragraph lists only 2 ways, which
you've helpfully repeated in your email.

I think that's it?

Thanks,
Jeffrey

On Wed, Aug 7, 2019 at 4:52 PM Martin Thomson <[email-masked]> wrote:

> > [...] for it to my document. However, I don't have very good content for
> that section. We had the ESCAPE workshop partly to try to find ways that
> Web Packaging might increase the risk of consolidation, and Martin is
> writing the report from there, but I didn't come away with any mechanisms
> that seem likely to have a big effect.
>
> I agree that there wasn't much at the workshop that suggested how this
> could avoid some of the consolidation effects.
> >
> The consolidation effects might be felt in several ways: in terms of
> driving traffic to sites that have the resources to preload links, in terms
> of inventivizing provision of content for majority clients, and as a
> secondary effect of raising the cost of business for publishers.
>
> The latter point is not one standards organizations are well-equipped to
> handle.  It's a natural byproduct of having more standards.  There are two
> ways of dealing with that:
>
> 1. Stop adding to the pile.  I know it's hard to tell engineers not to
> engineer, so I don't expect this to happen.  New stuff is just too
> appealing.
>
> 2. Having more and more accessible software for handling any complexity.
> For instance, HTTPS didn't really take off until we had really good support
> infrastructure.  Jeffrey has done some of that with the tools around
> building packages, but that's a very small part of the picture.  We need
> more and better tools, including cognitive tools for understanding the
> effect of this sort of change.  The availability of those tools will always
> lag standardization.  I might speculate and say that the extent to which
> consolidation is driven by this sort of effort will depend on how big that
> lag is.
>
> _______________________________________________
> Wpack mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpack
>