Re: [Add] ECS privacy concerns, alternatives?

[Brian Dickson <[e-mail]>]

On Tue, Apr 16, 2019 at 2:58 PM Mark Delany <[e-mail]> wrote:

> On 16Apr19, Brian Dickson allegedly wrote:
>
> > There are other ways to improve the whole ECS model by moving to GEO.
>
> There are other reasons for using ECS besides GEO and that is
> topological proximity and path costs.
>
> While it is true that many are using GEO as a proxy for topology
> because it's close enough for their application, e.g:
>
>     if countryCode[ip] == "UK" then serve a London IP.
>     if countryCode[ip] == "AU" then serve a Sydney IP.
>
>
> there are others who use ECS as input into path and cost metrics as
> part of calculating an answer.
>
> They do this because latency means everything or costs mean everything
> or both! Such calculations fail to work with geo-only data -
> particularly if your deployment is more fine-grained than country-code
> level.
>
>
Yes, I agree with what you are saying.

That's why I indicated that by "geo", I meant OPTIONALLY more fine-grained
than country-level:

>country and sub-country levels, e.g. ISO-3166, with 3166-1 being
countries, and 3166-2 being sub-country 3-letter codes.

(This may or may not be adequate for some of those currently doing ECS;
however, without GEO, there is no alternative.)

The original question raised by JL was what alternatives there might be to
ECS, that could preserve privacy without requiring encryption?

In general, the existence of two solutions, ECS and GEO, would facilitate
various "consenting adults" to agree on ECS where there is reason to do so.

It might be a bit more data to stuff into a query (either or both of ECS
and GEO), and for the answer returned to indicate which one was used (ECS
or GEO).

But I think that way would support multiple use cases, including encrypted
or not (according to agreements with e.g. browser vendors for inclusion on
some list).

So, "moving" might not mean the same thing for everyone, it is more a
question of "supporting a new standard, with or without supporting an older
standard"..

I'm pretty sure we are not in a one-size-fits-all world here.

Brian