Re: [Wpack] About content-based origins

[Ben Schwartz <[e-mail]>]

For a lighter example: if I'm distributing updates to a single-player
videogame, does the client have to get online and ping the server before
the game can access my local saved state?

(I can think of ways to avoid this while preserving the origin separation,
by forking the local state and blocking network access, but it seems
complicated.)

On Tue, Mar 24, 2020 at 1:48 PM Ted Hardie <[e-mail]> wrote:

> Hi Martin,
>
> Thanks for your note.  A question in-line.
>
> On Mon, Mar 23, 2020 at 5:34 PM Martin Thomson <[e-mail]> wrote:
>
>> Ted's note prompted me to send a much-belated announcement (sorry folks,
>> I forgot).
>>
>> The draft is here:
>> https://tools.ietf.org/html/draft-thomson-wpack-content-origin-00
>>
>> A nicer version here:
>>
>> https://martinthomson.github.io/wpack-content/draft-thomson-wpack-content-origin.html
>>
>> This approach could a dramatically different approach to addressing the
>> use cases set out in our charter.
>>
>> In short, this aims to address the core question of how offline content
>> might *ultimately* be attributed to a web origin in a fundamentally
>> different way.  There are two key concepts:
>>
>> 1. Content is given its own origin, using a new system for identification.
>>
>> 2. A target origin can "accept" content and state from one of these new
>> origins.
>>
>>
> I note that you did not include "hashing is a key element of
> identification" in the key concepts here, despite it being pretty prominent
> in the draft.  Is it something you consider fundamental here, or is it an
> approach to demonstrate a method of achieving the two desiderata above?
>
>
>
>> There are a lot of details here (read the draft), but the major advantage
>> I see is that you don't have to make an offline decision about authority,
>> and that means you can be offline for much longer (lifting the 7 day limit).
>>
>> I would personally describe this as a trade-off, rather than an
> advantage.  The inability to make an offline decision about authority has
> consequences for how different resources available to the client relate to
> each other (e.g some come from a bundle and some from a cache).  To take an
> unfortunately pressing example, let's assume a local authority has provided
> a set of resources to local residents.  A new item is created and
> distributed.  For those getting it via direct connection to the local
> authority's server, the new item can be related to the other items.  With a
> signed exchange and a signature verification, those receiving it
> peer-to-peer can as well.  In a content-origin approach, my understanding
> is that the new item could be received and displayed, but the ability to
> integrate it with the rest of set is not active until the client can go
> online and confirm with the local authority's serve that it verifies that
> "ni:hashmumble" is the target.   The problem here for an offline client is
> pretty serious, as it cannot determine whether the new resource is from the
> local health authority or not..  If it updates information like a set of
> symptoms or treatments, the consequences are large.
>
> Have I missed something here?  If I have not, then this approach makes a
> trade-off that limits its utility in ways that make peer-to-peer usage of
> the approach problematic for use cases I personally care about it.  Others,
> of course, may make other assessments of that trade-off.
>
> regards,
>
> Ted
>
>
>
>
>> What it does have in common with signed exchanges approach is the need
>> for a bundling format, but in its current form it is less dependent on the
>> details of the format.  That might allow that to be simpler, but I'm sure
>> that the need to mint new identifier types will more than make up for any
>> slack there.
>>
>> The draft is quite rough.  I'm sure that it has the remnants of a few bad
>> ideas still hanging around.  Ask questions if you think something is
>> unclear.
>>
>> _______________________________________________
>> Wpack mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/wpack
>>
> _______________________________________________
> Wpack mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wpack
>