Subject: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

From: Nalini J Elkins <[email-masked]>
Date: Thu, 18 Oct 2018 03:49:57 +0000 (UTC)

All,
We have posted a draft on filtering techniques.   Would appreciate comments from the group.

A new version of I-D, draft-elkins-hrpc-ifilter-00.txt
has been successfully submitted by Nalini Elkins and posted to the
IETF repository.

Name:           draft-elkins-hrpc-ifilter
Revision:       00
Title:          Human Rights Considerations of Internet Filtering
Document date:  2018-10-17
Group:          Individual Submission
Pages:          16
URL:            https://www.ietf.org/internet-drafts/draft-elkins-hrpc-ifilter-00.txt
Status:         https://datatracker.ietf.org/doc/draft-elkins-hrpc-ifilter/
Htmlized:       https://tools.ietf.org/html/draft-elkins-hrpc-ifilter-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-elkins-hrpc-ifilter

Abstract:
   This document is a survey of the filtering of content.  The focus is
   on the human rights involved as cited in the Universal Declaration of
   Human Rights" which is one of the foundational documents for HRPC.
   The recent years have seen an increase in content filtering for a
   variety of reasons including to further the aims of governments who
   wish to maintain their rule and suppress dissent but also to enforce
   cultural norms, human rights and compliance with the law.  Filters
   also exist for security (botnets, malware etc.), user-defined
   policies (parental control, corporate blocking of social networks
   during work time, etc.), spam control, upload of copyrighted material
   and other reasons. This document is based on several real world
   considerations: the existence of national and regional sovereignty,
   Internet Service Providers (ISPs) and Content Distribution Networks
   (CDNs) that provide connectivity and content hosting services, Over-
   the-top (OTTs) and Content Delivery Platforms (CDPs) that play a
   disproportionate role in capturing the attention and "eyeballs" of
   many of the users of the Internet.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
Thanks,Nalini ElkinsPresidentEnterprise Data Center Operatorswww.e-dco.com

---

From: Fred Baker <[email-masked]>
Date: Wed, 17 Oct 2018 21:50:34 -0700

> We have posted a draft on filtering techniques.   Would appreciate comments from the group.

I guess I might summarize the draft with "we can and do filter content. The question isn't capability, it is motivation and intent. The Law of Unexpected Consequences strongly suggests that even intents that appear completely benign can have negative consequences. And 'not filtering' is itself a filter that catches nothing, and is subject to the same cast of unintended consequences."

I obviously have not gone to the detail that you have. Apart from that fact, does my precis lack in accuracy?

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 18 Oct 2018 07:47:03 +0200 (CEST)

>     Il 18 ottobre 2018 alle 6.50 Fred Baker < [email-masked] mailto:[email-masked] > ha scritto:
> 
> 
> 
> 
>     On Oct 17, 2018, at 8:49 PM, Nalini J Elkins < [email-masked] mailto:[email-masked] > wrote:
> 
The draft attempts to make a comprehensive survey of the forms of content filtering and prioritization that are going on over the Internet, as a starting point for a subsequent discussion on whether and under which conditions these practices should be considered in protocol and architecture design or even addressed by specific technical standards. While usually there is a brief mentioning of the rights that are at stake and of the reasons why the adopters of each of these practices think they are a good idea, this does not mean that the document endorses or condemns any of them - it's just meant to be informational about all the use cases for content filtering, as a (hopefully) non-controversial reference for future discussions.

By the way, I found it particularly hard to distinguish between the different sets of actors that manage content hosting and distribution at the core of the network; we had different terms coming and going (over-the-top platforms, content delivery platforms, content delivery networks) to identify those who provide global content-based products and services (Google, Facebook etc) and those who provide the infrastructure to serve it to end users (CDNs plus hosting providers and domain name registr*s). I don't know if there is standard terminology at the I*TF and where - any suggestion is appreciated.

Regards,

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 18 Oct 2018 12:14:19 +0200

On 10/18/2018 07:47 AM, Vittorio Bertola wrote:
> 
>> Il 18 ottobre 2018 alle 6.50 Fred Baker < [email-masked]
>> <mailto:[email-masked]>> ha scritto:
>>
>>
>>
>>
>> On Oct 17, 2018, at 8:49 PM, Nalini J Elkins <
>> [email-masked]
>> <mailto:[email-masked]>> wrote:
>> I guess I might summarize the draft with "we can and do filter
>> content. The question isn't capability, it is motivation and intent.
>> The Law of Unexpected Consequences strongly suggests that even intents
>> that appear completely benign can have negative consequences. And 'not
>> filtering' is itself a filter that catches nothing, and is subject to
>> the same cast of unintended consequences."
>>
> The draft attempts to make a comprehensive survey of the forms of
> content filtering and prioritization that are going on over the
> Internet, as a starting point for a subsequent discussion on whether and
> under which conditions these practices should be considered in protocol
> and architecture design or even addressed by specific technical
> standards. While usually there is a brief mentioning of the rights that
> are at stake and of the reasons why the adopters of each of these
> practices think they are a good idea, this does not mean that the
> document endorses or condemns any of them - it's just meant to be
> informational about all the use cases for content filtering, as a
> (hopefully) non-controversial reference for future discussions.
> 
> By the way, I found it particularly hard to distinguish between the
> different sets of actors that manage content hosting and distribution at
> the core of the network; we had different terms coming and going
> (over-the-top platforms, content delivery platforms, content delivery
> networks) to identify those who provide global content-based products
> and services (Google, Facebook etc) and those who provide the
> infrastructure to serve it to end users (CDNs plus hosting providers and
> domain name registr*s). I don't know if there is standard terminology at
> the I*TF and where - any suggestion is appreciated.
> 

There are some serious issues with this draft. The draft does not
differentiate WHO makes the filtering decision, based on WHAT evidence
and/or process, WHERE it is enacted, HOW that is done, and WHERE people
can seek recourse. In this sense this document is not a survey.

Next to that the document does not reflect whatsoever on when or where
filtering is legitimate within which framework. There is a mention of
the UDHR and 'legislation', but there is no actual use of human rights
frameworks. In this sense this document does not offer human rights
considerations.

There is also a mix up between European Commission, the European
Parliament, the European Union and the Council of Europe. All of which
are relevant, but all of whom are also different :)

If the authors want to engage with legal frameworks vis a vis filtering,
this might be a useful resource:
https://www.article19.org/data/files/medialibrary/38586/Blocking_and_filtering_final.pdf

Cheers,

Niels

> [email-masked] <mailto:[email-masked]> 
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488
                   643A 0ED8 3F3A 468A C8B3

---

From: Nalini J Elkins <[email-masked]>
Date: Thu, 18 Oct 2018 14:26:29 +0000 (UTC)

Fred,

>I guess I might summarize the draft with "we can and do filter content. The question isn't capability, it is motivation and intent.
>The Law of Unexpected Consequences strongly suggests that even intents that appear completely benign can have negative consequences. 

>And 'not filtering' is itself a filter that catches nothing, and is subject to the same cast of unintended consequences."

The road to hell is paved with good intentions.  I totally agree with you that both action and inaction have unintended consequences.
I have done lots of humanitarian work.  Believe me, I know very well that good intentions are not enough.
Having said that, entities (government, platforms, etc) ARE taking action.  But, the action is in isolation.  Frankly, I can't say
that I blame them but I believe that this is causing a fair amount of chaos and may be leading people to feel that the Internet is 
an unreliable medium.  This is anecdotal but I can definitely say that my non-techy friends are starting to say that they really 
don't believe "anything" on the Internet.  This would be an unfortunate unintended consequence of inaction. What we (the co-authors) 

wanted to do is to start the conversation so that by the IETF community coming together we can maybe think of some way forward.
There are other drafts which need to be written in this area.  We thought of two (I am sure there are more): "Architectural 
Considerations of Filtering" and "Protocol Specification for Content Tagging and Distribution". (The content tagging is a  
potential protocol solution.)  But, we chose to concentrate first on taking a look at just what is going on.  We wanted to
do a survey of what people are doing in terms of filtering.  

In some ways, I am going to say that maybe motivation and intent is besides the point. It is the result of what happens that is 
germane.  That is, just because you have good intent does not mean that what you actually achieve is good. (Which is what you are 

also saying with unintended consequences.)  The reason we did the survey of what is happening now is that many people were 
saying to us that we have not specified the problem enough.  So, our draft is an attempt to at least describe what is going on.
One thing I believe has happened before in HRPC is that all filtering is seen as censorship.  Of course, sometimes it is true that 
filtering IS censorship. But, not always.  We wanted to discuss the scenario dispassionately, as engineers.   Let's take a
look at reality, see if we can describe the problem and find a way forward.

Internally, we (the co-authors) have taken a look at RPZ for DNS ( https://tools.ietf.org/html/draft-vixie-dnsop-dns-rpz-00)
(among other protocols), which try to address something like the problem we may be talking about.  But, that is going too 
fast.  Let's see if we can at least specify the problem and use cases.

Nalini

---

From: [email-masked]
Date: Fri, 19 Oct 2018 23:33:05 -0400

My interest in this tagging effort is much more in the realm of
mechanism rather than policy though an overview of policy seems like a
good idea so as to document motivations.

On the one hand this can be a fairly simple proposal whose main value
would be in establishing a standardized, universal, content tagging
format, much like RPZ has attempted for DNS.

Technical implementation is somewhat more complicated. How does one
effectively insert tagging into another party's stream for example?

That's likely beyond the scope of this effort and should be, but the
design should make it possible.

Even given all that an actual implementation could be one of the most
massive undertakings ever conceived for the internet.

How does one taxonomize the internet's content?

Also beyond the scope of this effort unless one wishes to argue it's
impossible so why try?

I would like to think the use cases are both positive and negative.

Positive might be essentially a search and filter tool. One wants to
see more about baseball, another wants to see less, another wants to
subscribe to a service which makes their child's access more
child-safe, etc.

One example of an end-user application I suggested was not seeing for
example NSFW content at work but automatically filing it for later
private viewing.

Negative would be unreasonable censorship policies. Fraudulent or
malicious tagging could also be a problem.

Tools can be like that.

Ideally I'd like to see as much of the use of tagging as possible be a
tool for end users rather than a bludgeon for central authorities.

How does one achieve that?

At the very least by making it a tool which could be used by end-users
rather than designing it from the start to only be of practical use to
centralized authorities.

We (the internet community) have been grappling with this basic
problem for many years in many different ways.

For example inserting DKIM (&c) headers into email to categorize
email, or tagging content NSFW by various actionable means.

Lately we've been grappling with the same basic problems on the web
and social media and broadening the scope of the content (e.g., fake
news.)

A unified format and evolving taxonomic dictionary could be more
useful than attacking this problem anew for every application.

It might be impossible to fully realize but also might be an
improvement nonetheless.

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

---

From: Melinda Shore <[email-masked]>
Date: Fri, 19 Oct 2018 20:13:08 -0800

> useful than attacking this problem anew for every application.

For the little it's worth it's not that clear to me what's actually
under discussion.  This particular document looks at content
filtering by unspecified means.  The previous document proposed
tagging content that might have human rights implications in
terms of those implications, rather than by topic.  I'm not
really a fan of either, but I'll note that content tagging
by topic and using a standardized, controlled vocabulary is
1980s technology and, I hope, not under consideration here or
anywhere else in the IETF.  Still, if what's under consideration
is just the syntax for doing so (and it would be awesome if
the chairs could weigh in on whether or not this is in scope
for this RG), I would hope that we realize that there's already
a lot out there, whether it's MARC, or Dublin Core (which has been
published by the IETF as an informational RFC, although I don't
believe an encoding specification has been published by us).

But it seems to me that in the context of HRPC it's best to
stick to 1) research topics, that 2) have something to do with
protocol issues that impinge on human rights.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Fred Baker <[email-masked]>
Date: Sat, 20 Oct 2018 10:07:29 +0200

> On Oct 20, 2018, at 6:13 AM, Melinda Shore <[email-masked]> wrote:
> This particular document looks at content filtering by unspecified means.

I suspect that "means" is an important question. The obvious interpretation of filtering for content is to in some way look for words that are of interest to the filtering party in the content of the message, and "do something". That is something that is generally not done in real time. For example, in Great Britain, child pornography is unlawful. There is an organization that is tasked with identifying relevant URLs and adding them to a list. That affects BGP routing; routing to the indicated service goes via a DPI system, which looks for an HTTP request for the URL in question and replies with a negative response, which is a form of content filtering. In China, a similar technique is used, I'm told, regarding content on the Internet that contains the word "China" in any language, and specifically anything that might criticize the Chinese government. OpenDNS has a service (they have several, and this one is as optional as any of them) that uses reputation services to identify URLs or services that have a high probability of delivering malware or unlawful content (read "pornography"), and respond with a manufactured resource record. That is also content filtering at the name level. And what an ISP does to mitigate DDOS and other attacks, which is essentially self-defense and in US FCC regulation is often called "reasonable network management". It is similarly an instance of content and protocol filtering.

My thought is that we're welcome to beat any drums we want on the topic of filtering. We're unlikely to do much more than turn electrical potential into hot air. The first example I mentioned is a matter of law, and governmental agencies probably don't monitor this list. The second is a service that administrators use by choice, and they discriminate against malware for financial and security reasons. The third is frequently a reason that Internet access actually works.

The list goes on.

> protocol issues that impinge on human rights.

Yes, I'd be interested in seeing anything that has resulted in or is targeted to result in published research papers, and is following something resembling the scientific method to produce results from data.

I don't think it is limited to protocol issues, however. If one wants to talk about OpenDNS malware filtering, for example, it will have to be the behavior of a DNS resolver (of which OpenDNS is an example).

---

From: [email-masked]
Date: Sat, 20 Oct 2018 15:03:15 -0400

I have mentioned MARC, SKU, RFID, ISBN, Library of Congress
Classification System, even Xanadu, etc in side conversations on this
topic. Mostly to champion mechanism over policy as I said in my note
being responded to here.

Something which many of those have in common is they are limited to a
very large level of granularity. For example MARC might suggest the
topic or topics of a book but makes no attempt, for example, to
identify or categorize images within a book.

Modern computing and networking has made a very fine level of
granularity possible.

To say this sort of thing has long existed outside of the computing
realm is, to me, tantamount to noting that people tabulated numbers
prior to computing.

True, but at some point a difference in quantity becomes a difference
in quality.

I don't think there should be any attempt here to actually populate
such a mechanism, only to suggest a standardized format and
technology. Much like DNS in spirit, for example.

As to keywords, a few thoughts:

DNS is basically a hierarchical keyword system with a mixture of
stringent controls (e.g., on TLDs) and almost no control on semantics.

With the exception of a handful of TLDs -- .EDU, .COOP, there must be
others, .BANK? .MUSEUM? Some ccTLDs and regional TLDs -- most any SLD
string less than 64 characters can be registered in most any TLD.

Yet the format and technology (mechanisms) for DNS lookups is
well-defined and generally adhered to as is the system of registries
and registrars and guarantee of uniqueness for example.

I believe Nalini brought up the appropriateness of this topic to this
group and whether a new group should be created but I think the
general suggestion was that there wasn't all that much traffic here,
there could be some overlap and synergy, so why not continue and see
where it goes?

At any rate what I do not have any interest in is actually trying to
populate a tagging mechanism.

Where I do think there is a common interest is in standardizing a
mechanism and trying to ensure that it is accessible both in control
and usage by anyone and not only central authorities: An open
standard.

The draft tries to document that this "tagging" is going on ad hoc
globally so perhaps some attempt to propose a standard for it would be
worthwhile.

Finally, I don't believe that tagging is at all limited to textual
content.

Currently, I would guess, the most "tagged" content on the internet
tends to be images, specifically the well known "NSFW" indicator. And
much of that is either voluntarily tagged by the publisher (as it
were), some informal site moderation process, or some automated means
of recognizing features in images.

-- 
        -Barry Shein

---

From: Melinda Shore <[email-masked]>
Date: Sat, 20 Oct 2018 11:29:50 -0800

Well, look - even leaving aside the fact that this is a
research group working on human rights issues, not a
working group developing standards - at this point I
think that it's pretty clear that the world has moved on
from subject/content tagging to more sophisticated
retrieval mechanisms.  Fortunately we've now got the
computational horsepower, massive storage, and sufficient
algorithmic progress that it's no longer necessary
to do subject tagging, in general.

Be that as it may, what you're discussing here is really
not what's in the document mentioned in the subject header
(mistagged, I guess), and the fact that there's not much
traffic on this mailing doesn't seem to me to justify having
an off-topic discussion here (I can think of a number of IETF
mailing lists which are quiet at the moment).

At any rate, what you're proposing outside of the document
is redundant with existing tagging mechanisms and frankly a
bit retrograde in terms of how retrieval is done.

Melinda

---

From: [email-masked]
Date: Sat, 20 Oct 2018 15:54:14 -0400

I don't know what any of this has to do with content retrieval,
perhaps there's some fundamental misunderstanding of the topic?

Clearly tagging and filtering are going on as the referenced draft
tries to document and categorize though I would be surprised if anyone
doubts the general claim.

A lot of what is going on currently has human rights implications
particularly in its opacity and ad hoc nature, also discussed in the
draft.

The question this leads to is: Is there any value in proposing an open
standard for content tagging and, thus, encouragement of a more
transparent and open infrastructure to effect it?

At any rate I will look for others' reactions.

-- 
        -Barry Shein

---

From: Melinda Shore <[email-masked]>
Date: Sat, 20 Oct 2018 12:47:40 -0800

It seems to me that this would be an appropriate situation for
requesting a non-WG mailing list from the IETF secretariat,
rather than continuing to drag this list off-topic.

And putting my IAB hat back on for a moment, I would hope that
any future draft on this topic would address why none of the
existing standards are adequate, vocabulary control (i.e.
would there be a controlled vocabulary and if so, whether or
not you'd be requesting a new IANA registry, how you'd deal with
synonyms and translation issues), and transport (for example, would
you also be requesting a new HTTP header?).

Thanks,

Melinda

---

From: Bill Jouris <[email-masked]>
Date: Sat, 20 Oct 2018 20:57:39 +0000 (UTC)

Modern computing and networking has made a very fine level of
granularity possible.
In fact, this kind of classification seems practically made to order for an AI application.  Perhaps one of those which learns as it goes along.
Bill Jouris
Inside Products

      From: "[email-masked]" <[email-masked]>
 To: [email-masked] 
 Sent: Saturday, October 20, 2018 12:03 PM
 Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

-- 
        -Barry Shein

---

From: Vittorio Bertola <[email-masked]>
Date: Sat, 20 Oct 2018 23:54:16 +0200 (CEST)

>     Il 20 ottobre 2018 alle 10.07 Fred Baker < [email-masked] mailto:[email-masked] > ha scritto:
> 
My motivation for attempting to work on this follows from having noticed an inherent tension. As you point out, there will be cases when filtering is bad, cases in which filtering is good, and cases in which it may be bad or good but it is also unavoidable since it is mandated by force by people (governments) that have the mandate to do so. At the same time, the IETF seems to churn out protocols (lastly DNS-over-HTTPS) that make filtering harder or impossible at all, as if filtering did not exist or, if it existed, all of it were bad.

So how can we get the IETF to analyze the topic and come to a shared view on how to deal with this in protocols, i.e. either accept the fact that protocols have to support (or at least not to impede) the cases in which filtering is good, or take a public stance that all filtering is bad and be ready to explain it to a number of other parties that need it?

I take the suggestion that this might not be the place where this is on topic, yet this does raise human rights concerns which I absolutely recognize and actually share, so having a discussion here seemed useful. If not, I'm happy to go for a non-WG list or any other instruments - suggestions welcome. The plan, however, is not to start immediately to standardize a tagging/classification mechanism (and I agree that, today, the classification machine is likely to be flexible and AI-based, and maybe even out of scope for standardization). First of all, we need a conclusion on the basic choice above, and a list of use cases for filtering seemed to be the first thing to do to prevent that discussion from focusing on just a few of them and forgetting about the others.

P.S. In the last few weeks I had conversations with policy people from British and French telcos. They are unanimous in saying that if blocking content by DNS hostname at the local resolver becomes impossible for a significant share of their citizens, their governments will just start ordering the ISPs to block stuff at the IP address / routing level, which means way more overblocking. Isn't this relevant to free expression?

Ciao,

--

Vittorio Bertola
Head of Policy & Innovation

Cell: 	+39 348 7015022
Skype: 	[email-masked]
Email: 	[email-masked] mailto:[email-masked]

Twitter: @openexchange http://twitter.com/openexchange - Facebook: OpenXchange https://www.facebook.com/OpenXchange - Web: www.open-xchange.com http://www.open-xchange.com
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin
Chairman of the Board: Richard Seibt

European Office:
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718
Managing Director: Frank Hoberg

US Office:
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA

Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 20 Oct 2018 23:17:28 +0100

On 20/10/2018 22:54, Vittorio Bertola wrote:
> At the same time, the IETF seems to churn out protocols (lastly
> DNS-over-HTTPS) that make filtering harder or impossible at all, as
> if filtering did not exist or, if it existed, all of it were bad.
IMO the above is a fairly gross mis-characterisation of the
IETF's outputs and of the processes that lead to those outputs.

It'd also be unwise to try argue this topic on this list, as
it's an IETF topic (increasing use of confidentiality mechanisms)
that has been of considerable controversy every time it's been
discussed over the last 20 or so years. And it has been thoroughly
discussed quite a few times in the IETF.

To be frank - I find it hard to separate out how much this is a
real discussion of HR issues and how much it's just an attempt
to continue recent attempts to weaken the security of protocols
like TLS. If the proponents here are really interested in HR
issues, then I would argue they'd be wiser to ensure that such
confusion isn't likely. And that's quite doable - just focus on
HR issues that do not overlap with weakening crypto - seems to
me there are many of those ripe for discussion that are nothing
to do with crypto. (E.g. troll farms being used at the application
layer to influence discussions and what that might mean in terms
of technical requirements to create accounts at services.)

S.

---

From: Nalini J Elkins <[email-masked]>
Date: Sat, 20 Oct 2018 23:15:33 +0000 (UTC)

>To be frank - I find it hard to separate out how much this is a real discussion of HR issues and how much it's just an attempt to continue recent attempts to weaken the security of protocols
>like TLS.
As far as I am concerned, this is an entirely separate issue from the recent attempt to provide much needed operational feedback from industry to the TLS group.   In fact, my co-authors may noteven know what you are referring to as TLS has not come up even once in our private discussions.
I consider DNS over HTTPS to be an entirely separate issue from TLS.   
>troll farms being used at the application layer to influence discussions and what that might mean in terms of technical requirements to create accounts at services.)
That is a very good point.   Those should be put into the problem description. Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Stephen Farrell <[email-masked]>
 To: Vittorio Bertola <[email-masked]>; Fred Baker <[email-masked]>; Melinda Shore <[email-masked]> 
Cc: [email-masked]
 Sent: Saturday, October 20, 2018 3:18 PM
 Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

S.

---

From: Nalini J Elkins <[email-masked]>
Date: Sat, 20 Oct 2018 23:19:23 +0000 (UTC)

Melinda,
>protocol issues that impinge on human rights
People are actually getting killed as a result of things like posts by the Myanmar military on Facebook.
If that is not a violation of human rights, then I would like to know what is.
I frankly think that there are very few things better suited for this list than a problem description of such human rights violations. Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Melinda Shore <[email-masked]>
 To: [email-masked] 
 Sent: Friday, October 19, 2018 9:13 PM
 Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

Melinda

---

From: Nalini J Elkins <[email-masked]>
Date: Sat, 20 Oct 2018 23:20:52 +0000 (UTC)

> And putting my IAB hat back on for a moment, I would hope that any future draft on this topic would address why none of the existing standards are adequate, vocabulary control (i.e.
> would there be a controlled vocabulary and if so, whether or not you'd be requesting a new IANA registry, how you'd deal with synonyms and translation issues), and transport (for example, would
Guys, let's step back for a minute and only describe the problem and use cases.  We may be jumping too quickly to a solution.   Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Melinda Shore <[email-masked]>
 To: [email-masked] 
 Sent: Saturday, October 20, 2018 1:47 PM
 Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

Thanks,

Melinda

---

From: Nalini J Elkins <[email-masked]>
Date: Sat, 20 Oct 2018 23:23:47 +0000 (UTC)

Fred,
> The obvious interpretation of filtering for content is to in some way look for words that are of interest to the filtering party in the content of the message, and "do something".
We wanted to keep content and taxonomy separate from a potential protocol solution.  I do not think they need to be co-mingled.
It may be unavoidable that a draft on content and taxonomy needs to be done.  We have been trying to stay away from that.   If any people from academia feel inclined to work in this area with us, please contact any of the co-authors.  I will also put it on my todo list to reach out to academics. Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Fred Baker <[email-masked]>
 To: Melinda Shore <[email-masked]> 
Cc: [email-masked]
 Sent: Saturday, October 20, 2018 1:07 AM
 Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

The list goes on.

I don't think it is limited to protocol issues, however. If one wants to talk about OpenDNS malware filtering, for example, it will have to be the behavior of a DNS resolver (of which OpenDNS is an example)._______________________________________________
hrpc mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/hrpc

---

From: Melinda Shore <[email-masked]>
Date: Sat, 20 Oct 2018 15:37:05 -0800

On 10/20/18 3:20 PM, Nalini J Elkins wrote:
>> And putting my IAB hat back on for a moment, I would hope that any
>> future draft on this topic would address why none of the existing
> standards are adequate, vocabulary control (i.e.
>> would there be a controlled vocabulary and if so, whether or not
>> you'd be requesting a new IANA registry, how you'd deal
> with synonyms and translation issues), and transport (for example,
> would
> Guys, let's step back for a minute and only describe the problem and
> use cases.  We may be jumping too quickly to a solution.

Barry specifically advocated working on subject tagging ("this
document is about elephants") and continuing the discussion
on this mailing list.  It is only tangentially related to the
posted draft and, as such, can't really be considered a solution,
anyway.  As I said in the mail you're responding to, this should
be taken to a more appropriate mailing list.

I am not a fan of the intended direction of the filtering
discussion and am profoundly uncomfortable with the notion of
working on technology that can specifically be used to abridge
speech rights, but I agree that an examination of filtering
practices can be viewed as being within the scope of this RG.

Melinda

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 21 Oct 2018 00:37:31 +0100

On 21/10/2018 00:15, Nalini J Elkins wrote:
>> real discussion of HR issues and how much it's just an attempt to
>> continue recent attempts to weaken the security of protocols like
>> TLS.
> As far as I am concerned, this is an entirely separate issue from the
> recent attempt to provide much needed operational feedback from
> industry to the TLS group.  

Sure. (Not that I agree with that description of the debate:-)
I do accept that you consider this a different issue but I'd
ask you to consider whether it's wise to conflate the two, or
to explicitly try ensure a clean separation between these two
quite different discussions.

> In fact, my co-authors may noteven know
> what you are referring to as TLS has not come up even once in our
> private discussions. 

FWIW, I consider it normal that the dramatis personae change
with each iteration of this debate. The arguments remain the
same of course, as (so far) has the IETF's rough consensus on
the topic.

> I consider DNS over HTTPS to be an entirely

It is entirely related if one is interested in inspection
of protocol payload and metadata.

>> troll farms being used at the application layer to influence
>> discussions and what that might mean in terms of technical
>> requirements to create accounts at services.)

I think you're missing my point - sorry for not explaining
it well, but I'll try again.

ISTM that people expressing valid concerns about the use
of Internet services at the application layer that might
impinge on human rights, would be wise(r) to ensure they
aren't being seen as attacking the mechanisms we use to
improve the security and privacy properties of Internet
protocols, but would make more progress leveraging the real
alignments they may have with the technical requirements of
people who would like to improve the privacy aspects of the
Internet as commonly used by us all.

S.

> 
> Nalini Elkins CEO and Founder Inside Products, Inc. 
> www.insidethestack.com (831) 659-8360
> 
> From: Stephen Farrell <[email-masked]> To: Vittorio
> Bertola <[email-masked]>; Fred Baker
> <[email-masked]>; Melinda Shore
> <[email-masked]> Cc: [email-masked] Sent: Saturday,
> October 20, 2018 3:18 PM Subject: Re: [hrpc] New Version Notification
> for draft-elkins-hrpc-ifilter-00.txt
> 
> 
> 
>> DNS-over-HTTPS) that make filtering harder or impossible at all,
>> as if filtering did not exist or, if it existed, all of it were
>> bad.
> IMO the above is a fairly gross mis-characterisation of the IETF's
> outputs and of the processes that lead to those outputs.
> 
> It'd also be unwise to try argue this topic on this list, as it's an
> IETF topic (increasing use of confidentiality mechanisms) that has
> been of considerable controversy every time it's been discussed over
> the last 20 or so years. And it has been thoroughly discussed quite a
> few times in the IETF.
> 
> To be frank - I find it hard to separate out how much this is a real
> discussion of HR issues and how much it's just an attempt to continue
> recent attempts to weaken the security of protocols like TLS. If the
> proponents here are really interested in HR issues, then I would
> argue they'd be wiser to ensure that such confusion isn't likely. And
> that's quite doable - just focus on HR issues that do not overlap
> with weakening crypto - seems to me there are many of those ripe for
> discussion that are nothing to do with crypto. (E.g. troll farms
> being used at the application layer to influence discussions and what
> that might mean in terms of technical requirements to create accounts
> at services.)
> 
> S. _______________________________________________ hrpc mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
> 
> 
> 
> 
> 
> _______________________________________________ hrpc mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Nalini J Elkins <[email-masked]>
Date: Sat, 20 Oct 2018 23:52:46 +0000 (UTC)

Melinda.

>am profoundly uncomfortable with the notion of working on technology that can specifically be used to abridge speech rights,

I completely understand.  I am very uncomfortable also.   I lived for two years in a nation which was a military dictatorship with no freedom of speech.  I am well aware of how that plays out in people's lives.

But, I am also very uncomfortable with the prospect of people getting hurt as a result of unfettered freedom.   This has happened in the past and I see it being more and more of a possibility in the future.  That is why I am spending my cycles on this issue.

Sometimes, there are no good solutions, only least bad solutions.

I think let's go very slowly.   Let's at least talk about the problem.  I think ignoring reality does no one any good.   I know my we (my co-authors and I) have tentatively proposed solutions but I want us to have some discipline and not go to solutions yet.

I have faith that if people of good will talk things out carefully and if maybe at the IETF we can come to some kind of rough consensus, it may be the "least bad alternative". 

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

________________________________
From: Melinda Shore <[email-masked]>
To: Nalini J Elkins <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Saturday, October 20, 2018 4:37 PM
Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

Melinda

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 21 Oct 2018 06:14:01 +0200

Hi,

On Sat, Oct 20, 2018 at 11:54:16PM +0200, Vittorio Bertola wrote:

> My motivation for attempting to work on this follows from having
> noticed an inherent tension. As you point out, there will be cases
> when filtering is bad, cases in which filtering is good, and cases
> in which it may be bad or good but it is also unavoidable since it
> is mandated by force by people (governments) that have the mandate
> to do so. At the same time, the IETF seems to churn out protocols
> (lastly DNS-over-HTTPS) that make filtering harder or impossible at
> all, as if filtering did not exist or, if it existed, all of it were
> bad.

I think that the DoH work was an attempt to improve certain privacy
aspects of name resolution (possibly at the expense of certain other
privacy aspects -- indeed, in some deployments DoH would make
filtering quite a bit easier), not to act as though filtering did not
exist or is bad.  Moreover, it's not like this topic has never been
considered by anyone; the IAB put out a pretty comprehensive
discussion of the topic some while ago
(https://tools.ietf.org/html/rfc7754). 

> So how can we get the IETF to analyze the topic and come to a shared
>view on how to deal with this in protocols, i.e. either accept the
>fact that protocols have to support (or at least not to impede) the
>cases in which filtering is good, or take a public stance that all
>filtering is bad and be ready to explain it to a number of other
>parties that need it?

I think that, to get that party started, you'd need to define what
"filtering is good" and "filtering is bad" means.  I am not sure I
know how to do that, but I do encourate reading of RFC 7754 for an
exploration of some effects on the Internet.

> their governments will just start ordering the ISPs to block stuff at the IP address / routing level
> 

"Start"?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Sun, 21 Oct 2018 10:02:41 +0200

Hi Andrew,

On 21.10.18 06:14, Andrew Sullivan wrote:
> Moreover, it's not like this topic has never been

Indeed.  That work sets out a pretty good framework, and it took a lot
of work to get it to that point.  It would be good for this draft to
either talk about the examples given in the context of that work, or to
maybe explain whatever different framework the authors have in mind.  I
do like this draft having come up with more real world examples, and I
especially like the exploration of the doubled-edged sword to much of
this.  I also agree with Fred that delving a bit more into mechanism
would be useful.  That can at least in part happen by referencing RFC 7754.

Long ago, I wrote with a few people RFC 1627 whose subtitle is, “Some
practices shouldn’t be codified”.  If this draft wanted to tackle the
value and risks in the context of HR of various mechanisms, that would
also be interesting, and perhaps even a continuation of 7754.

But a further caution- much of this technology is “dual use”.  Let me
give an example.  Suppose there were a mechanism for content tagging. 
Tools within a business might use it to flag content that contains PII
that is restricted in some way,  within the business (e.g., content not
leaving a particular country's borders) or requiring encryption to the
customer or even within a business' borders.  It is true that some
businesses do this today not via tagging, but within the business logic,
but it requires a lot of CPU, and a lot of planning and work.  Could
that be eased?  I don't know.  There are definite differences in model,
whether one implements such tagging within our outside the envelope of
encryption, and those would have dramatic HR differences.

Also, such mechanisms tug on another tension. Going WAY WAY back to
early discussions in this group,  you wrote on 14. Nov. 2016:

> Still, the Internet (as opposed to the IETF) might
> have as its core value that expansion of Internet-type communications
> and connectivity is a good (this is like the "selfish gene" value some
> biologists and sociobiologists believe in).  From this we can infer
> that anything that improves that connectivity is positive and anything
> that impedes that connectivity is negative.  

To be clear, in the context of the above note, I think you were merely
arguing that this *could* be true, not that it is true.  If it is true,
then does it hold that we should standardize mechanisms that might have
human rights harms associated with them that encourage a single
Internet?  Certainly content filtering and tagging have harms, so we
seem to have a good test case at hand ;-)
**
Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 21 Oct 2018 10:35:13 +0200

> seem to have a good test case at hand ;-)

I think there's a lot to unpack in your "should", and I want to be
quite careful.

What I was trying out in that passage you quote was really the
plausibility of an alternative ethical framework.  The HRPC RG starts
from the assumption that human rights are a framework for what amount
to ethical considerations in protocol design.  That is the basis for
Niels' oft-repeated quoting that protocols are politics by other
means.

Certain ethical stances (such as various environmental ethics authors
starting perhaps from John Muir and perhaps from Baruch Spinoza)
regard many ethical systems as anthropocentric or even speciesist.
That is, there is too great an emphasis on the state of the humans in
the ethical stance, and not enough attention paid to other agents of
the world.  This strain is particularly evident in environmental
philosophy, because we are part of the natural world and yet we seem
perfectly willing to despoil that world in our own interests.  This
strain of environmental ethics requires that we take into account in
evaluating what is "good" (and therefore what we should do) not only
good-for-people but also good-for-animals, good-for-trees,
good-for-forest-system, &c &c.  In a different vein, Aristotelean
virtue ethics cultivates a view of virtue that need not extend only to
humans, but that almost certainly requires a kind of proportionality
in just about every case (which would at least arguably extend to the
wider world, and not only to humanity).

Now, let us take seriously the idea that we create certain kinds of
systemic technologies which alter reality such that the systemic
technology has a certain logic of its own that is not necessarily the
same as the instrumental logic that created the technology in the
first place.  This is one of the meanings of that aphorism I like, "We
shape our tools, and thereafter they shape us."[1] It seems to me at
least plausible that the Internet is one such tool.  And in that case,
it might be that there is an "ethic of the network" that has as its
overarching value connecting nodes.

I owe to Ted Hardie the observation that such an ethic could be
paradoxical across different layers.  You might get _fewer_ connection
paths through a social media network in the sense that the social
media environments are often not really _part of_ the Internet but
simply on top of it; but in that case, you might still get _more
connection_ because of the ease of use for ordinary humans, who can
use it to build more connections.

Under this view, there isn't a conflict of rights in the sense that a
mechanism that could be used to harm human rights get standardized,
but instead a conflict of ethical systems (in rather the way that
utilitarian and deontological ethical frameworks can sometimes yield
different results).

Anyway, I hope that explains what I was on about.  Whether it is
germaine to the topic I will leave for others to determine.

Best regards,

A

[1] Interestingly, an obvious example of this is the built
environment.  A version of this quote, substituting "buildings" for
"tools", is attributed to Winston Churchill, though I've never tracked
down the original.

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Sun, 21 Oct 2018 11:14:27 +0200

Hi Andrew,

Thanks for the explanation.  I’m glad you made the distinction between
ethics systems, but that in itself leads to a question for our
community: do we as a community (if that is what we are) subscribe to a
single ethics system, and if not, can we reconcile the differences
between such systems in our code?  Is adherence to a single ethics
system required as part of our standardization efforts, and what are the
ramifications either way?  Might someone form an alternative
Nihilist-Network Engineering Task Force ;-)?

The reason I revived this earlier point is because it is fundamental to
blocking and filtering, as to whether we have one Internet or more than
one Internet, and it is a question that is squarely in view, given Eric
Schmidt's comments in September, and a New York Times Editorial this
past week.

Eliot

---

From: Nalini J Elkins <[email-masked]>
Date: Sun, 21 Oct 2018 14:43:17 +0000 (UTC)

Stephen,
> ISTM that people expressing valid concerns about the use of Internet services at the application layer that might impinge on human rights, would be wise(r) to ensure they aren't being seen as attacking the mechanisms we use to
> improve the security and privacy properties of Internet protocols, but would make more progress leveraging the real alignments they may have with the technical requirements of people who would like to improve the privacy aspects of the
This is very interesting and a good point.  I am thinking about this.  If you have a few moments in Bangkok, I would like to sit down and talk with you about this face to face.   I am always interested in finding common ground. Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Stephen Farrell <[email-masked]>
 To: Nalini J Elkins <[email-masked]>; Vittorio Bertola <[email-masked]>; Fred Baker <[email-masked]>; Melinda Shore <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>
 Sent: Saturday, October 20, 2018 4:37 PM
 Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

S.

hrpc mailing list
[email-masked]

---

From: Vittorio Bertola <[email-masked]>
Date: Sun, 21 Oct 2018 17:44:25 +0200 (CEST)

>     Il 21 ottobre 2018 alle 0.17 Stephen Farrell < [email-masked] mailto:[email-masked] > ha scritto:
> 
It seems you have really misunderstood my intentions (and, I think, those of the other authors as well). No one ever mentioned weakening cryptography or TLS - in fact, encrypting connections is such a good thing that I have been spending a significant chunk of my time for the last two years in meeting telcos around the globe and explaining them how to adopt DANE. Also, the company I work for is AFAIK the first major name server software maker adding DNS-over-HTTPS support in their application.

The problem with DNS-over-HTTPS is rather that, as it is being deployed now, it is solving a privacy threat deriving from ISPs sniffing DNS queries in transit to profile individual users (something honestly unheard of, at least in Europe), and creating a much bigger privacy threat by allowing dominant OTTs to centralize DNS query data in their hands and possibly feed their well known user data monetization and pervasive monitoring systems.

But this is not a problem with the encryption in the protocol, it is a problem of troubling and covert architectural mutations (turning DNS into an over-the-top application) and of lack of understanding and attention for how the DNS works today and what it is being used for, up to the point of breaking stuff that, as Fred put it, "is frequently a reason that Internet access actually works", to create more privacy threats than it solves. Yet if you go through the draft there is no consideration on how to mitigate this, no justification or responsibility taken for this, just a note on "yes this may break some security stuff", and no solution provided. Do you still wonder why so many DNS and security people are upset?

The problem is that encryption is not a silver bullet for privacy, and once you deploy it, the real privacy risk lies at the endpoint of the connection; and that endpoint is also the only place available to exert some content control when necessary. The desirable (or undesirable) interactions between those endpoints and the existing use cases for content control should have been considered and addressed before releasing this stuff as a standard - and writing down those use cases is IMHO a way to start that long due discussion.

Regards,

--

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Oct 2018 01:31:26 +0200

> Nihilist-Network Engineering Task Force ;-)?

That was part of the point of the argument I was making the first time
around.  You don't actually need to have a common framework for the
ethics to undertake the technology.  If you are a relativist, you
might think that all of these frames are morally equivalent.  If you
think human rights as defined by the UDHR are morally primary, you
might be more concerned with that stance (and might wish to include a
"human rights considerations" section).  But there is more than one
way to describe this stance, and I was arguing at the time that
treating protocols as _necessarily_ political was itself a
frame-choosing stance (and therefore itself possibly political in a
way that some stances would not accept).  Kantians, for instance,
don't accept moral relativism.  But that's not going to convince the
moral relativist that Kantians are correct in their universal and
rationalist stance.

> Schmidt's comments in September, and a New York Times Editorial this

I'm not sure I agree.  On blocking and filtering and the "multinet"
world, there's more than one way to describe it.  One is the stance
"this is fragmenting the Internet".  But I actually think it's
different, and that Schmidt's piece is just basically wrong.  In one
version of what he's describing, there a world with the Internet, and
a new and much larger AOL on the side.  The ChinAOL he is describing
is a centrally-contolled and permission-goverened walled garden that
sometimes (when it is convenient) connects to resources on the
Internet.  The Internet remains the relatively open network of
networks that we already have.  There is nothing new about this model:
only the size of the population behind the wall is different.

The human rights-centric description of this is that this is a bad
political choice with negative consequences for the population behind
the restrictions.  This puts us squarely into the world of arguing
that our political stance (free expression) is better.  I am dubious
about the prospects for success there.

The "networking ethic"-centric description of this is that the walled
garden approach is a bad network choice, because it harms the ability
of the network to increase connectivity.  Incidentally, as a necessary
consequence, it deprives those inside the more-restrictive network of
the potential of potentially innovative opportunities in the
less-restrictive network, thereby in theory harming the opportunities
available to those inside the more-restrictive system.  This might be
a viable choice for a restrictor power who has a mostly-homogenous
domestic market of more than 1 billion consumers with ready disposable
income.  Whether this is a viable path for other restrictor powers is
not clear to me, but it seems at least open to doubt.  So there might
be follow-on policy consequences for this "networking ethic"-centric
description, but the actual moral value of those choices does not
immediately become a political argument in which netowrk-loving people
need to argue in political terms against the values of some nation-states.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Oct 2018 09:28:09 +0200

Hi Andrew,

In replying to your note, I realized that a graphic would be useful, and
I'm not quite sure how our mailers will handle them.  Therefore, they
are also located at https://www.ofcourseimright.com/pages/internets.pdf.

> only the size of the population behind the wall is different.

Right.  Mr. Schmidt might even be told, "Look behind you," because that
line was passed years ago.  But blocking and filtering comes in many
forms, as Richard & Olaf et. al documented.  One of those forms is from
the source, and we are certainly seeing that in the form of
organizations not willing to risk offering content to Europeans due to
the GDPR.  One could reasonably argue that the Internet right now is
beginning to look a little like this (page one of the above link):

A little like that, although it's really multi-dimensional.  Also, the
controls for each system vary from blocking to filtering to import
controls to various SP regulations,  etc.

This would clearly violate the network ethic, if you will.  It also has
certain attendant economic limitations.  It also puts the economically
disadvantaged at a further disadvantage if they cannot meet the
obligations of entering a market.  (Another component of that green
bubble, by the way, is the so-called “Dark Net”).

The network ethic, however, is not just that but an economic paradigm,
and so the above seems ripe for consolidation along these lines (page 2
of the above link):

I think this was what Mr. Schmidt was getting at.   One might say, “but
these are not really three Internets”.  For all intents and purposes, if
communication is prevented due to whatever rules are in place, they are.

Each of these systems requires different technical capabilities.  The
question is how these systems then interact with each other, and in the
context of this RG, human rights.  At this point, it becomes a
manageable problem for people to participate in all THREE of these
communities, so long as they obey the rules of each and are aware of
which rules the other side is demanding.  There clearly is mechanism
required for such a system to work, and tagging (perhaps at a very gross
level) might be one approach.  Here I think one would say that the
network ethic would encourage the building of such tools.

By the way, I do not claim that this is desirable, merely that it is a
possible future that we should consider.  As we have seen, however,
international concerns will want to sell to all comers.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Oct 2018 08:57:54 +0100

Hiya,

On 21/10/2018 16:44, Vittorio Bertola wrote:
> 
>> Il 21 ottobre 2018 alle 0.17 Stephen Farrell <
>> [email-masked] mailto:[email-masked] > ha
>> scritto:
>> 
>> TLS. If the proponents here are really interested in HR issues,
>> then I would argue they'd be wiser to ensure that such confusion
>> isn't likely. And that's quite doable - just focus on HR issues
>> that do not overlap with weakening crypto - seems to me there are
>> many of those ripe for discussion that are nothing tcao do with
>> crypto. (E.g. troll farms being used at the application layer to
>> influence discussions and what that might mean in terms of
>> technical requirements to create accounts at services.)
>> 
> It seems you have really misunderstood my intentions (and, I think,
> those of the other authors as well). 

I wasn't questioning your intentions specifically, but it
is fair to say that those interested in filtering are sometimes
unhappy with proper use of TLS - so that they can do the DPI
they claim is needed.

That was specifically called out in this discussion earlier,
e.g. as seen at [1] and filtering of various kinds was also
one of the justifications offered for the most recent proposal
for weakening TLS [2] that did not garner IETF consensus.

So the background here is relevant, hence my encouraging
you and co-authors to make it clear if you're not actually
arguing to weaken security mechanisms in order to make it
easier to do what you see as "good" filtering.

Your draft also says we need to try "to establish principles,
guidelines and technical protocols that can increase transparency
and user control over these practices, allowing users to
distinguish between the bad and the good uses of content
classification and filtering schemes" which, to this reader,
could be read as calling for weakened security. Again, I'm not
saying that is your intention, but you are also not clearly
stating that it is not. And "technical protocols that can
increase transparency" is the kind of phraseology that fairly
strongly reminds me of the (ab)use of the term "visibility"
in [2].

   [1] https://www.ietf.org/mail-archive/web/hrpc/current/msg01715.html
   [2] https://tools.ietf.org/html/draft-rhrd-tls-tls13-visibility-01

> No one ever mentioned weakening
> cryptography or TLS - in fact, encrypting connections is such a good
> thing that I have been spending a significant chunk of my time for
> the last two years in meeting telcos around the globe and explaining
> them how to adopt DANE. Also, the company I work for is AFAIK the
> first major name server software maker adding DNS-over-HTTPS support
> in their application.
> 
> The problem with DNS-over-HTTPS is rather that, as it is being
> deployed now, it is solving a privacy threat deriving from ISPs
> sniffing DNS queries in transit to profile individual users
> (something honestly unheard of, at least in Europe),

IIUC, there are issues with such filtering in some places, at
least that's one of the justifications offered by those who
developed DoH.

> and creating a
> much bigger privacy threat by allowing dominant OTTs to centralize
> DNS query data in their hands and possibly feed their well known user
> data monetization and pervasive monitoring systems.

Yes, those trade offs are real but ISTM that e.g. quad9 are
as well or better able to filter as an ISP, in terms of any
kind(s) of filtering that might be claimed to be desirable
for the user of the stub resolver. (Not that most end users
are at all aware of their DNS traffic.)

I do agree about the downsides to the wider use of megascalers'
recursives. That's a real concern. But setting up one's own
recursive isn't a great fix there, so I'm not sure what real
options exist that are that much better. (That's a space that
is worth exploring though, but off-topic for hrpc probably.)

> But this is not a problem with the encryption in the protocol, it is
> a problem of troubling and covert architectural mutations (turning
> DNS into an over-the-top application) and of lack of understanding
> and attention for how the DNS works today and what it is being used
> for, up to the point of breaking stuff that, as Fred put it, "is
> frequently a reason that Internet access actually works", to create
> more privacy threats than it solves. Yet if you go through the draft
> there is no consideration on how to mitigate this, no justification
> or responsibility taken for this, just a note on "yes this may break
> some security stuff", and no solution provided. Do you still wonder
> why so many DNS and security people are upset?

I'm not surprised that DoH has upset people, no - such changes
always upset someone. I'm fairly sure that proponents of DoH
wouldn't accept your description above though (what is a "covert
architectural mutation" - perhaps modifying a whiteboard while
someone went for coffee? :-)

> The problem is that encryption is not a silver bullet for privacy,
> and once you deploy it, the real privacy risk lies at the endpoint of
> the connection; and that endpoint is also the only place available to
> exert some content control when necessary. The desirable (or
> undesirable) interactions between those endpoints and the existing
> use cases for content control should have been considered and
> addressed before releasing this stuff as a standard 

Where was that consideration omitted? I'm not clear what you
mean. IIRC, there was plenty of discussion of DoH on the DPRIVE
list. It may well be that the FF/CF stuff took people who weren't
active on that list by surprise - perhaps that's what you mean?

>- and writing
> down those use cases is IMHO a way to start that long due
> discussion.

Hmm, maybe. The centralisation tendencies of DoH seem pretty far
from a HR discussion though.

Cheers,
S.

> [email-masked]
> mailto:[email-masked] Office @ Via Treviso 12,
> 10144 Torino, Italy
> 
>

---

From: Amelia Andersdotter <[email-masked]>
Date: Mon, 22 Oct 2018 11:13:00 +0200

On 2018-10-21 17:44, Vittorio Bertola wrote:
>> [email-masked] <mailto:[email-masked]>> ha
>> scritto:
>>
> those of the other authors as well). No one ever mentioned weakening
> thing that I have been spending a significant chunk of my time for the
> last two years in meeting telcos around the globe and explaining them
> how to adopt DANE. Also, the company I work for is AFAIK the first
> major name server software maker adding DNS-over-HTTPS support in
> their application.
>
> sniffing DNS queries in transit to profile individual users (something
> honestly unheard of, at least in Europe), and creating a much bigger
> privacy threat by allowing dominant OTTs to centralize DNS query data
> in their hands and possibly feed their well known user data
> monetization and pervasive monitoring systems.

Nothing in principle has stopped ISPs, especially large ISPs in the EU,
from taking a lead on privacy-friendly DNS. In fact, as they themselves
frequently and verbosely point out, they are under some of the strongest
legal obligations in the world to do so. They just don't wanna, and now
someone else is doing something that actually does create better
transparency (and therefore better consumer empowerment), and that's
wrong too. Every activity is wrong as long as it helps consumers
understand what's going on! It's the whine-ocracy: rather than doing
great stuff, whine.

If privacy was truly a concern of a broader range of stakeholders,
especially in the "non-OTT sector" (as it were), these stakeholders
would be involved in developing stronger DNS privacy data management
standards at the DPRIV WG[1].

With such a standard we would have a gold standard and something against
the backdrop of which we could measure the new OTT powerhouses
objectively. Unsurprisingly, whiners have instead expressed caution
about such developments for a variety of reasons (ranging from "we don't
wanna" to "IETF should not be doing this"). Prior examples of the IETF
doing Best Practise Documents including data management, is however the
existing similar data management guidelines for DNSSEC (which were
specifically made to help smaller actors manage keys and other vital
information securely and competently). Apparently, it's OK to whine
about data management standards that would be genuinely helpful to
smaller market players, and provide objective metrics for the OTTs, as
long as there is an objective benefit for consumers and/or individuals
to be had from such practises. Why?

I find this very frustrating: OTTs, at the end of the day, are gaining a
lot of commercial ground because they're actually trying to do good
stuff (broadly, in this context, implying "transparency towards
consumers"). Nothing stops anyone else from doing good stuff too! In
particular, I do not see whining about user-friendly developments
contributing to the success of non-OTTs.

[1] https://tools.ietf.org/html/draft-dickinson-dprive-bcp-op-01

best,

Amelia

>
> But this is not a problem with the encryption in the protocol, it is a
> problem of troubling and covert architectural mutations (turning DNS
> into an over-the-top application) and of lack of understanding and
> attention for how the DNS works today and what it is being used for,
> up to the point of breaking stuff that, as Fred put it, "is frequently
> a reason that Internet access actually works", to create more privacy
> threats than it solves. Yet if you go through the draft there is no
> consideration on how to mitigate this, no justification or
> responsibility taken for this, just a note on "yes this may break some
> security stuff", and no solution provided. Do you still wonder why so
> many DNS and security people are upset?
>
> The problem is that encryption is not a silver bullet for privacy, and
> once you deploy it, the real privacy risk lies at the endpoint of the
> connection; and that endpoint is also the only place available to
> undesirable) interactions between those endpoints and the existing use
> cases for content control should have been considered and addressed
> before releasing this stuff as a standard - and writing down those use
> cases is IMHO a way to start that long due discussion.
>
> Regards,
>
> -- 
>

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55

---

From: Amelia Andersdotter <[email-masked]>
Date: Mon, 22 Oct 2018 11:14:36 +0200

Hi all,

I have two comments:

1. The draft makes no distinction between "filtering" and "censorship".
While it seeks to establish that filtering can be done for morally valid
reasons, it does so by saying censorship is morally valid.

This is unlike most other rationalisations of filtering that I have
seen, which typically go along the lines of "it is not censorship to
filter child sexual abuse images, since it is not a human right to
express child sexual abuse images". If I could make a suggestion to the
drafters, it would be to keep separate censorship within the meaning of
human rights law (i.e. ensuring there is a distinction between
inhibiting expressions that would enjoy human rights protection and
inhibiting expressions that would not).

2. The draft contains no technical information so serve as a basis for
the evaluation of protocols. It references no technical mechanisms at
the IETF or the IRTF, or indeed any technology used for any filtering
anywhere. It merely establishes that the authors believe there are
morally valid censorship/filtering activities ongoing in different
context. One could imagine it would otherwise be interesting to
distinguish between DNS-based filtering, or software-implemented
filtering, or even plug-in-based filtering (such as some commonly used
ad-blockers), as well as the different methods of filtering that are
chosen by consumers, employers, service providers or governments for
different contexts. We could imagine a mapping of trade-offs, for
instance the trade-off between intercepting an encrypted website with a
warning message from the government, and having reliable encryption and
forwarding to protect users against phishing (essentially the same
issues that are being discussed in relation to captive portals).

While the deficiencies of the draft in terms of the 1st point makes it
objectionable to me as such unless it is changed, the deficiencies
pointed to in my 2nd comment could make the draft an actually useful
survey if they were remedied.

best regards,

Amelia

On 2018-10-18 05:49, Nalini J Elkins wrote:
> URL:           
> https://www.ietf.org/internet-drafts/draft-elkins-hrpc-ifilter-00.txt
> Status:       
>  https://datatracker.ietf.org/doc/draft-elkins-hrpc-ifilter/
> Htmlized:     
>  https://datatracker.ietf.org/doc/html/draft-elkins-hrpc-ifilter
>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org/>.
>
> The IETF Secretariat
>
>
>
> -- 
> Thanks,
> Nalini Elkins
> President
> Enterprise Data Center Operators
> www.e-dco.com <http://www.e-dco.com/>
>
>
>
>

ARTICLE19
www.article19.org

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 22 Oct 2018 09:29:55 +0000 (UTC)

Thanks for these suggestions, Amelia. And to others on the list who have given concrete feedback for how to improve the draft.

This feedback is not easy to fix and in some cases might require structural changes from the authors.

I think while discussion has been sparked by the draft it would be best to see a new revised version based on these concrete suggestions before restarting the debate in Bangkok. Without these changes we risk having to raise the same points again in the meeting.

If we can get a new version, I suggest we debate that newer version in Bangkok or Prague, depending on the timeline.

-M

----- Original Message -----
From: Amelia Andersdotter <[email-masked]>
To: [email-masked]
Sent: Mon, 22 Oct 2018 09:14:36 -0000 (UTC)
Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

Hi all,

I have two comments:

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Oct 2018 11:46:10 +0200

Mallory,

Can I offer an alternative suggestion?  Rather than blocking discussion
at the HRPC meeting altogether, might you consider asking the authors at
the meeting to focus on responses to the comments received?

Eliot

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 22 Oct 2018 09:51:08 +0000 (UTC)

Hi Eliot,

I am suggesting that the face to face meeting be productive and progress the discussion. 

If a new version cannot be posted into the datatracker before 5 November, it would be fine to have a new version addressing the current suggestions simply available to others perhaps via GitHub or another web-based link as the basis for a renewed debate. That’s up to the authors.

-M

----- Original Message -----
From: Eliot Lear <[email-masked]>
To: Mallory Knodel <[email-masked]>, Amelia Andersdotter <[email-masked]>
Cc: [email-masked]
Sent: Mon, 22 Oct 2018 09:46:10 -0000 (UTC)
Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

Mallory,

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Oct 2018 12:26:16 +0200

Hi,

> I am suggesting that the face to face meeting be productive and progress the discussion. 

So am I. 

Let us put this in classic IETF terms.  People have raised issues (some
of them big ones) with the draft, a'la Github issue tracking.  One could
then reasonably spend the time focusing on each issue such that each may
be resolved.  It helps for the authors to have proposals for each, and
it's not unreasonable to ask for authors and others to come prepared
with their views as to how those issues should be resolved.  What is
unreasonable two weeks before a conference is to ask them to restructure
a document and address all issues as a prerequisite for discussion.

Eliot

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 22 Oct 2018 14:02:36 +0200

On 10/21/2018 10:35 AM, Andrew Sullivan wrote:
>>> biologists and sociobiologists believe in).  

Still not sure I understand how biological theories apply inanimate
assemblages such as the Internet. Does that mean that engineers and
companies are not actors? Or that engineers lose their subjectivity and
get overcome with this larger identity called the Internet when they
work on it, so that they can only do things 'for the good of the Internet'?

>>> From this we can infer

My recent favorite is Shapiro and Varian's: 'standards are a wild mix of
politics and economics' ;)

> good-for-forest-system, &c &c. 

But not inanimate objects, right?

> In a different vein, Aristotelean
> first place.  
> This is one of the meanings of that aphorism I like, "We

This is where I lose you. I agree that a network has its own
technlogical affordances (Hutchby 2001), which shapes, stimulates and
contrains behavior. But I don't see where this would lead to an ethics.
It is the kind of post-humanism that alludes me and seems to erase/hide
the work and choices of the 1000s of people working on it.

Instead of an ethic, isn't this some kind of 'health indicator', in the
ways in which Mozilla uses it with its Internet Health Report?

Happy to discuss!

Cheers,

Niels

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 22 Oct 2018 14:10:13 +0200

On 10/22/2018 01:31 AM, Andrew Sullivan wrote:
> way that some stances would not accept).  

In the way that every stance is a frame-choosing stance, or do you mean
something else? There are different (philosphical and sociological
understandings of what 'frames' are (epistemological or strategic, etc).

> Kantians, for instance,

I am still surprised that there is this much resistance in our community
against accepting human rights as a framework. There literally is not
another framework that is so widely shared and adopted.

I have also not said or implied we should enforce anything, but rather
know-and-show what our (potential) impact is.

After 4 years in this community I am still flabbergasted people argue
against adopting human rights as a framework.

> need to argue in political terms against the values of some nation-states.

May I point out that these nation-states have adopted the UDHR, ICCPR,
and ICESCR ?

Best,

Niels

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Oct 2018 08:40:42 -0400

> another framework that is so widely shared and adopted.

When you try and try to communicate something to a group of people and they don't seem to be hearing you, there are several explanations that could account for the phenomenon.   One is that they just disagree with you, and you haven't made your case.   Another is that they don't understand what you are saying—that you aren't expressing it in a way that makes sense to them.   Another is that they agree with you but don't see how to put it into practice.

When you say "accepting human rights as a framework," I have literally no idea what you are talking about.   Human rights are important to me.   How what we do in the IETF impacts human rights is important to me.   But I have no idea how "accepting human rights as a framework" relates to that.

Maybe rather than expressing frustration that you have failed thus far to communicate whatever it is that you mean, you could take a more methodical approach to figuring out what is going on.

One thing you might consider is that this group produces so much verbiage that it's impossible to follow.   As I said, I have a keen interest in the subject matter, but I find that I rarely manage to actually follow a conversation.   And when I do, I often find that what is being communicated is being communicated very poorly.

For example, you recently raised a topic on the IETF mailing list about "offensive language."   I was absolutely astounded that you would do such a thing.   The effect of this was to poison the well.   The term you chose was really poorly chosen, and had exactly the effect one could have predicted: it started a flame war.

It's great that your heart is in the right place, but you need more than that to be effective in the IETF.   I say this as one who has long experience screwing it up, of course.   You need to learn how to communicate effectively.   This message to which I am replying is an example of not communicating effectively.  It feels like it's just another ongoing flame war.

Ongoing flame wars damage discourse.   The most obvious reason is that they act as a denial-of-service attack: if the verbiage goes on forever, I can't follow it, and hence can't either agree with you or disagree with you, because I have been effectively excluded from the conversation.   You might want to consider whether this particular effect has something to do with the frustration you are expressing here.

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 22 Oct 2018 14:59:53 +0200

Hi Ted,

On 10/22/2018 02:40 PM, Ted Lemon wrote:
> On Oct 22, 2018, at 8:10 AM, Niels ten Oever <[email-masked]
> <mailto:[email-masked]>> wrote:
> When you try and try to communicate something to a group of people and
> they don't seem to be hearing you, there are several explanations that
> could account for the phenomenon.   One is that they just disagree with
> you, and you haven't made your case.   Another is that they don't
> understand what you are saying—that you aren't expressing it in a way
> that makes sense to them.   Another is that they agree with you but
> don't see how to put it into practice.
> 
> When you say "accepting human rights as a framework," I have literally
> no idea what you are talking about.   Human rights are important to me.
>   How what we do in the IETF impacts human rights is important to me.  
> But I have no idea how "accepting human rights as a framework" relates
> to that.

This was a response to the ethical frameworks discussion with Andrew,
who proposed 'other ethical frameworks'. There I argued that human
rights (as defined in treaties such as the Universal Declaration of
Human Rights, the International Covenant of Civil and Political Rights,
and others) is the most widely accepted framework to in which people and
states have expressed norms and values.

> 
> Maybe rather than expressing frustration that you have failed thus far
> to communicate whatever it is that you mean, you could take a more
> methodical approach to figuring out what is going on.
> 
> One thing you might consider is that this group produces so much
> verbiage that it's impossible to follow.   As I said, I have a keen
> interest in the subject matter, but I find that I rarely manage to
> actually follow a conversation.   And when I do, I often find that what
> is being communicated is being communicated very poorly.
> 

I am very sorry to hear that.

> For example, you recently raised a topic on the IETF mailing list about
> "offensive language."   I was absolutely astounded that you would do
> such a thing.   The effect of this was to poison the well.   The term
> you chose was really poorly chosen, and had exactly the effect one could
> have predicted: it started a flame war.
> 

I did not see that coming to be frank, but I have sought to learn from
it and that has resulted in a new draft:

https://datatracker.ietf.org/doc/draft-knodel-terminology/

I hope the text in here is less poorly chosen, but if you have
suggestions for other text I would be more than happy to change!

> It's great that your heart is in the right place, but you need more than
> that to be effective in the IETF.   I say this as one who has long
> experience screwing it up, of course.   You need to learn how to
> communicate effectively.   This message to which I am replying is an
> example of not communicating effectively.  It feels like it's just
> another ongoing flame war.

I do not feel that the discussion we have been having about network
ethics, which has resulted in draft-irtf-hrpc-political-00, is useless
at all. At least I have learned a lot, and outlining these positions has
been interesting.

It saddens me you feel differently.
> 
> Ongoing flame wars damage discourse.   The most obvious reason is that
> they act as a denial-of-service attack: if the verbiage goes on forever,
> I can't follow it, and hence can't either agree with you or disagree
> with you, because I have been effectively excluded from the
> conversation.   You might want to consider whether this particular
> effect has something to do with the frustration you are expressing here.

I will, and am more than happy to also talk further about it in Bangkok.

Thanks for sharing.

Niels

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 22 Oct 2018 15:08:07 +0200 (CEST)

> Il 22 ottobre 2018 alle 11.13 Amelia Andersdotter <[email-masked]> ha scritto:
> 
> legal obligations in the world to do so. They just don't wanna, 

You do have a point here, and this will be a very positive effect of DoH: create the pressure necessary for ISPs to spend the money to update their DNS service to DoH/DoT (though I stress that as long as the IETF does not provide a standard way for them to publish the availability of such service, like DHCP does for unencrypted DNS resolvers, users will still not be available to use it).

However, this was mostly not about "we don't like privacy", but rather that the network path between the user's device and the ISP's resolver only traverses the ISP's network, so if the ISP keeps their network secure, the actual risk of interception is very low or non-existent. This is why transport security is a much bigger concern in an OTT architecture than it is in traditional DNS resolution services. So I think it was a technical judgement, not an ethical one.

> and now
> transparency (and therefore better consumer empowerment),

How does DoH create "better transparency"? Maybe I don't get what you mean by transparency in this context.
 
> consumers"). Nothing stops anyone else from doing good stuff too!

Are you really serious? I mean, do you really think that these companies strive to "don't be evil"? They simply have found a business model for which they need to gather as much data as posisble about each human being on the planet; DNS queries are just one more dataset that they can put their hands upon, grind it into AI algorithms and turn it into advertising, customization and data flow revenues. I am not attaching moral judgements on this, but I also don't think it's useful to design standards and architectures by saying that certain business models are better than others.

Regards,
--

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Oct 2018 15:18:07 +0200

On Mon, Oct 22, 2018 at 02:02:36PM +0200, Niels ten Oever wrote:

> assemblages such as the Internet.

It's just an analogy, not an equivalence.

> But not inanimate objects, right?

This may depend on whether you think rocks and landscapes are
inanimate objects.

> the work and choices of the 1000s of people working on it.

No, no, it's just a duck-rabbit gestalt shift.  From the point of view
of the engineer, such-and-thus is good, but from the point of view of
the network such-and-other is good.  Maybe they're the same, but the
telos, to the extent there is one, differs.

It is a strange thing to think, I fully concede.  The idea that the
network itself has an end it is pursuing strikes me as faintly absurd.
But we don't seem to find the intentional stance strange when applied
to toasters or economic systems (or even data that "wants to be
free"!), so it's maybe a useful way of thinking about the network and
the pressures it _itself_ applies on its development.

> ways in which Mozilla uses it with its Internet Health Report?

No, I don't think so.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Oct 2018 15:28:15 +0200

> In the way that every stance is a frame-choosing stance, or do you mean

But rationalists, of course, don't actually accept that they're
choosing a "frame".  They think they're choosing truth.  Similarly,
many political types do not think that their gloss on "human rights"
is the wrong one, even though I may disagree with them pretty
strongly.

> another framework that is so widely shared and adopted.

I don't resist the acceptance of that framework.  I'm saying that one
doesn't _need_ to accept it in order to get good results for the
network.  That's important, because cutting out path dependencies for
protocols seems to me to be important.  To be clear, though, I don't
disagree with the project of figuring out how a protocol design
impinges on human rights.  I am just interested in seeing whether
there are other analyses that lead us to the same happy results
without having to argue about which rights count more than others, how
to balance them, or whether a given government-ordered shutdown is in
fact a violation of this or that right.  I have a different problem
than yours. :)

> May I point out that these nation-states have adopted the UDHR, ICCPR,

Sure, and they claim that turning off the network, or interfering with
packet flows, or so on, are all conforming to those.  I believe,
strongly, in "Turn it on, keep it on", but for me it's just as
important to be able to argue that in the terms of someone else.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 22 Oct 2018 15:31:35 +0200

> This may depend on whether you think rocks and landscapes are

Valid and elegant point.

> network itself has an end it is pursuing strikes me as faintly absurd.

But also interesting and insightful :)

> the pressures it _itself_ applies on its development.

Fascinating! But economic systems try to understand and predict larger
events as systems, and not an ethical framework, right?

I fully agree that a higher level lens is useful for analysis,
especially if one is looking at such a large infrastructure (even though
Bowker et al* would probably argue differently). But then again, this
theory would be descriptive and not normative, right?

it would say something about what the network /does/ not what it /should
do/.

* https://link.springer.com/chapter/10.1007/978-1-4020-9789-8_5

Warm regards,

Niels

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Oct 2018 15:59:57 +0200

> events as systems, and not an ethical framework, right?

Well, certain _economists_ certainly think that it's an ethical
framework.  Whether the economy itself thinks it is an ethical
framework (or maybe "value system") I don't know, but some
interpreters sure seem to feel that way.

> theory would be descriptive and not normative, right?

That depends how you're standing.  If you take the "stance of the
network" and just think more connection is better (assuming that's a
coherent thing to do), then it does amount to a kind of normative
structure.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Oct 2018 16:01:10 +0200

On 22.10.18 15:28, Andrew Sullivan wrote:
> To be clear, though, I don't
> impinges on human rights. 

Nor do I, by the way.  so long as the full set of rights is considered.

Eliot

---

From: Nalini J Elkins <[email-masked]>
Date: Mon, 22 Oct 2018 14:04:26 +0000 (UTC)

Mallory,
>If we can get a new version, I suggest we debate that newer version in Bangkok or Prague, depending on the timeline.

There are only a few hours left before the submission deadline.   I do not believe that is enough time for a new version.
I think that given the amount of discussion on this topic, it would be very surprising if the chairs did not want to have this topic on the agenda for further discussion. Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Mallory Knodel <[email-masked]>
 To: Amelia Andersdotter <[email-masked]> 
Cc: [email-masked]
 Sent: Monday, October 22, 2018 2:30 AM
 Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

-M

----- Original Message -----
From: Amelia Andersdotter <[email-masked]>
To: [email-masked]
Sent: Mon, 22 Oct 2018 09:14:36 -0000 (UTC)
Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

Hi all,

I have two comments:

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Nalini J Elkins <[email-masked]>
Date: Mon, 22 Oct 2018 14:12:44 +0000 (UTC)

> What is unreasonable two weeks before a conference is to ask them to restructure a document and address all issues as a prerequisite for discussion.
Thank you, Eliot.   Mallory, I need to go to India in 4 days to help them to increase their IETF participation.     A number of us get together in India before the Asian IETF.    (Actually, any one who is interested in joining us in 2019, please contact me offline.  We are happy to have you.)
I have a huge number of things to do before I leave.
Frankly, I have never heard of this kind of objection in any other Working Group I have been involved in at the IETF  / IRTF.   Most people in these circumstances would be eager to discuss this draft.    Your objections surprise me greatly. Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Eliot Lear <[email-masked]>
 To: Mallory Knodel <[email-masked]> 
Cc: [email-masked]; Amelia Andersdotter <[email-masked]>
 Sent: Monday, October 22, 2018 3:26 AM
 Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt
   
Hi,

So am I. 

Eliot

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 22 Oct 2018 14:12:47 +0000 (UTC)

Thanks for chiming in, Nalini. It’s important to hear from the Aithors on what will be the difference between this discussion and what progress can be made, eg what would be discussed in Bangkok. Can you speak to that?

-M

----- Original Message -----
From: Nalini J Elkins <[email-masked]>
To: Mallory Knodel <[email-masked]>, Amelia Andersdotter <[email-masked]>
Cc: [email-masked]
Sent: Mon, 22 Oct 2018 14:04:26 -0000 (UTC)
Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

Mallory,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

-M

----- Original Message -----
From: Amelia Andersdotter <[email-masked]>
To: [email-masked]
Sent: Mon, 22 Oct 2018 09:14:36 -0000 (UTC)
Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

Hi all,

I have two comments:

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Nalini J Elkins <[email-masked]>
Date: Mon, 22 Oct 2018 14:30:58 +0000 (UTC)

>Thanks for chiming in, Nalini. It’s important to hear from the Aithors on what will be the difference between this discussion and what progress can be made, eg what would be discussed in Bangkok. Ca…
Yes, sorry, it is 7:00am my time here.  You guys were busy while I was sleeping away!   Got a bit behind on the email chain here.
Most of what we can do will be while I am sitting at airports in the next two weeks, so I am trying to be conservative with what we can accomplish.   (I also have another actual protocol draft to finish for IPPM!) 
I think what we can do is:
-  Consolidate the comments into groups.
I really don't think we can do much else.   There are structural comments, content comments, and many others.    
You know, f2f is really very important.   I think it gives people a chance to try to understand what the other is saying.  I would suggest that we use the time at the group to try to reach some sort of common ground.

Quite a few people have said some very interesting things.  I need some time to think and then the co-authors need to think it out together.   Then we all need to think together.  I am not good with rushing to do things.  It has not worked well for me.   I need to let things be in my mind for a while so I can reflect on them.
You know, in other IETF / IRTF WGs I am involved in, it is totally OK not to have all your i's dotted and t's crossed.  I trust the community.   We (the co-authors) need your help.   When you talk to each other in a trusting, open, vulnerable way, ideas come out and ways forward that you could never have thought of on your own.  I have seen it over and over again in different parts of the IETF.    
My suggestion would be to think and work together and see where we get to.   I have seen many quite thoughtful and productive comments on this topic.   Thank you, everyone! Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Mallory Knodel <[email-masked]>
 To: Nalini J Elkins <[email-masked]> 
Cc: [email-masked]; Amelia Andersdotter <[email-masked]>
 Sent: Monday, October 22, 2018 7:13 AM
 Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

-M

----- Original Message -----
From: Nalini J Elkins <[email-masked]>
To: Mallory Knodel <[email-masked]>, Amelia Andersdotter <[email-masked]>
Cc: [email-masked]
Sent: Mon, 22 Oct 2018 14:04:26 -0000 (UTC)
Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

Mallory,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

-M

----- Original Message -----
From: Amelia Andersdotter <[email-masked]>
To: [email-masked]
Sent: Mon, 22 Oct 2018 09:14:36 -0000 (UTC)
Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

Hi all,

I have two comments:

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Amelia Andersdotter <[email-masked]>
Date: Mon, 22 Oct 2018 19:16:46 +0200

> However, this was mostly not about "we don't like privacy", but rather that the network path between the user's device and the ISP's resolver only traverses the ISP's network, so if the ISP keeps t…

I have not seen these market entities lift any fingers to leverage any
opportunity to improve user privacy or user empowerment, but I have
consistently seen them whine both about competitors' efforts and
legislators' efforts to achieve such improvements.

I would like to say it was different. But ok, I thought I outlined an
idea for how adjustments can be made to current developments, in a way
which builds on the good work which unfortunately has not been done
previously (in the form of DoH or any other form). If one does not lead,
one risks having to follow.

> How does DoH create "better transparency"? Maybe I don't get what you mean by transparency in this context.

It shifts visibility to user-land in the browser. It creates visibility
of choices in a way that wasn't possible previously.

> Are you really serious? I mean, do you really think that these companies strive to "don't be evil"? 

I believe there's a bunch of participants in IETF standardisation
efforts that are better able to leverage increasing demands for privacy
and security for their own commercial ends than non-OTTs have been. It
doesn't need to be selfless or altruistic, it just needs to be more
efficient and credible.

In this framing, I believe it's more efficient and credible what they
are doing.

best regards,

Amelia

> They simply have found a business model for which they need to gather as much data as posisble about each human being on the planet; DNS queries are just one more dataset that they can put their hands upon, grind it into AI algorithms and turn it into advertising, customization and data flow revenues. I am not attaching moral judgements on this, but I also don't think it's useful to design standards and architectures by saying that certain business models are better than others.
>
> Regards,

ARTICLE19
www.article19.org

---

From: Eliot Lear <[email-masked]>
Date: Mon, 22 Oct 2018 19:56:46 +0200

On 22.10.18 19:16, Amelia Andersdotter wrote:
> [DoH] shifts visibility to user-land in the browser. It creates visibility

Technically?  Sure.  As a matter of practice?  Maybe.  It will depend on
whether the user has the ability to make good choices about who he or
she trusts.  That, to me, is a research question.

Eliot

---

From: Mark Perkins <[email-masked]>
Date: Mon, 22 Oct 2018 20:42:29 +0000 (UTC)

Amelia

I think that the current distinctions between 'filtering' and 'censorship' are in fact semantic hair-splitting.

"filter child sexual abuse images, since it is not a human right to express child sexual abuse images"

Clearly, such filtering is censorship - the question is whether it is justifiable from a Human Rights (UDHR, ICCPR, ICESCR). Plus, most censorship is justified by states on the exceptions within these Human Rights treaties - it is just that others disagree with the justification.

A more useful distinction is that of 'content neutral' filtering. As I understand this, it is where the blocking of the transmission of content is justified on grounds other than the content itself. For example, advertising panels on the pavements (side-walks) outside shops being illegal, no matter what their content; graffiti on buildings being illegal, no matter their content or intrinsic worth.

Therefore, I suggest a 2 way split: 

Filtering = content neutral blocking
Censorship = blocking based on content

Within the latter, we could indicate (near) universal agreement on justifed censorship -  eg. child pornography, incitement to direct racial violence (illegal even in US). Not satifactory, perhaps - but at least a lowest common denominator.

Regards

Mark P.

    On Monday, October 22, 2018, 8:30:11 PM GMT+11, Mallory Knodel <[email-masked]> wrote:  

-M

----- Original Message -----
From: Amelia Andersdotter <[email-masked]>
To: [email-masked]
Sent: Mon, 22 Oct 2018 09:14:36 -0000 (UTC)
Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt

Hi all,

I have two comments:

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 22 Oct 2018 23:56:54 +0200 (CEST)

> Il 22 ottobre 2018 alle 19.16 Amelia Andersdotter <[email-masked]> ha scritto:
>
> It shifts visibility to user-land in the browser. It creates visibility of choices in a way that wasn't possible previously.

Er, which choices? In the current consumer DNS resolution architecture, you can set your name server at once for all your applications. You get the one suggested by your network, but you can still change and set it in a second to 8.8.8.8 or whatever else, and with DNS-over-TLS (or even DoH deployed in a proper way) no one can prevent that choice; and while it's not a possibility as easy and widely known as it could be, we have 30 years of online guides and user experience in learning how to do it, and estimates are that about one fourth of the users is using a non-local resolver.

In the new world of DoH, you only get from your browser the message in the attached screenshot:

"Mozilla is working to improve privacy and security on the web. We are conducting studies that send encrypted DNS requests to Cloudflare, a secure, cloud-based service. [Learn more] [Disable DNS studies] [Ok, got it]".

This is for the study phase where they only duplicate the queries, so I hope that when the system DNS gets actually disabled the message will be more informative. Yet, what kind of choice is this? It isn't asking whether the user would like to use their local DNS or Cloudflare's. There is not even a question in the sentence. It more or less says: we're giving you privacy and security [Ok] [No I want to be insecure].

This does not look like a choice, nor like proper information about all the implications of such change. Moreover, each application will now pick the name server it likes, so if you don't like it, even if we assume that all software makers will actually give you a choice, you will have to replicate your choice dozens of times application by application. (Yet another example of how moving the DNS to the application layer is a terrible idea.)

> In this framing, I believe it's more efficient and credible what they are doing.
 
This is your opinion and I respect it, but I will note that pretty much everyone else in the privacy sphere seems quite concerned with the immense accumulation of data that the OTTs have built. In many cases, starting from Google and Facebook, almost the entirety of their revenues comes from targeted advertising and other data-based products, for which personal information is the raw material - so they have a direct economic incentive to erode the user's privacy and gather as much information as possible. ISPs usually have a more traditional business model in which they get paid directly by the end users for the services they give. I'm not making ethical judgements on which one is better, but one of the two models is basically undermined by privacy, so IMHO it's not credible that companies that have been offering so many "free" services in exchange for pervasive tracking and profiling of their users will now offer "free" DNS resolution without extracting any drop of value from the da
 ta they gain from it.

If you need a couple of very recent and unrelated examples of what I mean by "eroding privacy":
https://blog.cryptographyengineering.com/2018/09/23/why-im-leaving-chrome/
https://www.apnews.com/828aefab64d4411bac257a07c1af0ecb

Regards,
--

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 22 Oct 2018 23:49:34 +0100

Just on a couple of points...

On 22/10/2018 22:56, Vittorio Bertola wrote:
> This does not look like a choice, nor like proper information about
> all the implications of such change. Moreover, each application will
> now pick the name server it likes, so if you don't like it, even if
> we assume that all software makers will actually give you a choice,
> you will have to replicate your choice dozens of times application by
> application. (Yet another example of how moving the DNS to the
> application layer is a terrible idea.)

That discussion would be better on the dprive list.

FWIW, my take is that people do not have real choice now
as to their DNS recursive, as they don't know such a thing
exists. The same is true with the FF/CF setup, i.e. there
is no real choice for real people either way.

Architecturally, both allow technical folks to change the
settings in more or less the same way. There are ops and
control differences between the ISP-chosen, and FF-chosen
DNS settings that are interesting but IMO off topic here.

>> efforts that are better able to leverage increasing demands for
>> privacy and security for their own commercial ends than non-OTTs
>> have been. It doesn't need to be selfless or altruistic, it just
>> needs to be more efficient and credible.
>> 
> This is your opinion and I respect it, but I will note that pretty
> much everyone else in the privacy sphere seems quite concerned with
> the immense accumulation of data that the OTTs have built. 

Calling them OTTs seems wrong to me. ISTM that all for-profit mega-
organisations pose a pervasive monitoring threat. That includes
the organisations I assume you mean by "OTTs," various well known
government agencies and others some of whom are also ISPs, others
of whom are in advertising or finance. It is I think the case that
IETF/IRTF participants have an easier time considering mitigating
the PM actions of government agencies than the other kinds of
organisation. That topic is, I think, germane for this list but
I think it'd be an error to try put the blame on "OTTs" or any
other functionally-defined subset of for-profits - seems to me
that it's mega-scale money making that causes the threat to be
significant, and much less the specifics of a business model.

Cheers,
S.

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 23 Oct 2018 00:54:58 +0200

Eliot, you brought up several times that not a full range of rights has
been considered in doing human rights reviews and in discussions here.

Can I invite you to do a human rights review of a protocol to show how
we can take other considerations into account than we have not taken
into account thusfar?

I would also be very happy if you could help point out rights we have
missed in existing reviews. Maybe the most recent QUIC review could be
an interesting start?

https://tools.ietf.org/html/draft-martini-hrpc-quichr-00

Based on that we can improve the methodology as laid out in:
https://tools.ietf.org/html/draft-irtf-hrpc-guidelines (which is of
course an adaptation of RFC8280).

Best,

Niels

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Oct 2018 10:49:52 +0200

Hi Stephen,

> DNS settings that are interesting but IMO off topic here.

Yes, this is what I was trying to say as well, but the tie-in to HR is
this matter of REAL choice.  I think this might be a good question for
someone like Angela Sasse at UCL or Serge Egelman at Berkeley or Ross
Anderson at Cambridge to consider.  It is a matter of providing the
invidual (at home) and the enterprise (at work) some *meaningful*
control over trust.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Oct 2018 10:10:27 +0100

Hiya,

> invidual (at home) and the enterprise (at work) some *meaningful*

I reckon "trust" is a term that's just likely to confuse here.
(Given that term is only meaningful if we say whom we're
considering trusting for what, I'm not sure if applies in a
case like this where a person has no idea any setting exists
at all.)

But fair enough - I buy that the general issue of developer
(or manufacturer or admin or deployer) chosen settings vs.
"real" user/owner choice is a topic that might be valid for
HRPC. In that case DoH is just one example. Another would be
sources for s/w updates, or sinks for sensor data, or the
set of CAs public keys in force. In all of those cases we do
seem to end up with architectures that allow technical folks
some level of control but that offer no choice at all to
people who don't know what's under the hood. I've no idea
myself if that could be avoided though but it is an aspect
that could be called out e.g. in reviews.

Cheers,
S.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 23 Oct 2018 11:24:21 +0200 (CEST)

> Il 21 ottobre 2018 alle 6.14 Andrew Sullivan <[email-masked]> ha scritto:
>

Thanks for the pointer, very interesting. Sorry for missing it, and I'd say it accomplishes at least part of what we meant to do with the first draft. It also allows to frame some of the problems better.

I agree that filtering at the endpoint, as recommended by that RFC, would be preferrable for a number of reasons, but it is too expensive and too hard to manage for many users, and impossible in a growing number of cases (e.g. the "dumb" IoT devices - we used to have one or two connected devices per home network, now we have dozens). Also, as the text points out, that is only possible with the cooperation of the end user, so it does not work in many security cases (e.g. when the user is a spammer or a bot) and in all law enforcement cases (where, by definition, the user wants to access illegal resources and actively tries to circumvent the filters). As network blocking in an encrypted world only works at the IP address level (which is the most prone to inaccuracy and overblocking, so IMHO it's the least desirable), we're left with the "rendezvous" blocking, i.e. DNS.

So perhaps we need to give up the pretense that blocking doesn't exist, and find ways to make it work "better", with more accuracy, with more transparency (I mean by making the filter apparent, the list of filtered content publicly available and the filtering devices available to everyone), and even with some form of authentication of the "party who sets blocking policies", and secure transmission of these policies to the technical operators that implement them.

> exploration of some effects on the Internet.

I think it's impossible to define in an universal way which cases are good and which ones are bad (though there could be an agreement on some cases). This is why I'd rather focus on making things more standard and transparent.

> > their governments will just start ordering the ISPs to block stuff at the IP address / routing level

In Europe, at least for what I know, that's not the common way to implement law/court-mandated blocking. Many years ago, it actually was a battle of the pro-rights side (me included) to convince governments that they should require blocks by hostnames (via DNS) rather than by IP addresses, as that would much reduce overblocking, even if that would also make it easier to circumvent blocks by using foreign resolvers, which was acceptable as it only affected a small minority of smarter users. I don't know what will happen if this balance is rediscussed.

Regards,
--

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 23 Oct 2018 11:34:28 +0200 (CEST)

> Il 23 ottobre 2018 alle 0.49 Stephen Farrell <[email-masked]> ha scritto:
>  

Happy to move it, though I think it's hard to separate the human rights issues from the privacy ones, the network security ones and even more. Perhaps a first conclusion (in Bangkok?) would be whether this needs a specific non-WG list or, if enough people are interested, a specific WG.
 
Also we are mixing a general discussion on blocking and a specific discussion on DoH (sorry about that).
 
> is no real choice for real people either way.

So, regarding the DoH implementation part, perhaps the IETF (DPrive?) could focus on ensuring that all the technical pieces are there to allow users to discover all existing encrypted DNS providers and make informed choices.
 
> organisations pose a pervasive monitoring threat.

Yes, I agree with that. However, no telco has a truly global scale - at most, the biggest ones cover a few countries, often with several relatively independent companies. However, it's true that, given the success of the OTTs (some of them in just a few years became the biggest and richest companies the world has ever seen), everyone else is also moving into the "data economy" - and the data economy is inherently allergic to privacy. But in the end, I think we should write another RFC entitled "Centralization and consolidation are an attack" :-)
 
Regards,
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Oct 2018 11:32:19 +0100

Hiya,

On 23/10/2018 10:34, Vittorio Bertola wrote:
> Happy to move it, though I think it's hard to separate the human
> rights issues from the privacy ones, the network security ones and
> even more. Perhaps a first conclusion (in Bangkok?) would be whether
> this needs a specific non-WG list or, if enough people are
> interested, a specific WG.
> 
>> FWIW, my take is that people do not have real choice now as to
>> their DNS recursive, as they don't know such a thing exists. The
>> same is true with the FF/CF setup, i.e. there is no real choice for
>> real people either way.
> 
> So, regarding the DoH implementation part, perhaps the IETF (DPrive?)
> could focus on ensuring that all the technical pieces are there to
> allow users to discover all existing encrypted DNS providers and make
> informed choices.

Discovery of recursives doing DoH or DNS/TLS
seems to me to be a topic that'd be right in
scope for the dprive wg. I think it has been
mentioned before, but forget if there's been
substantive work on the topic. I would guess
there may be controversial aspects to that,
e.g., some may argue that allowing discovery
of all DoH services would merely allow censors
to block those and thereby defeat one purpose
of DoH. I do agree that depending on Sara to
maintain a list in stubby.yml [1] isn't that
optimal either;-)

   [1] https://github.com/getdnsapi/stubby/issues/79

To offer another, purely anecdotal, angle, DNS/TLS
kept my home n/w working fine a while back when my
ISP has a DNS outage, [2] so moving or adding points
of control can also improve resiliency. (OTOH, when
I first set up DNS/TLS on my home router, I broke the
TV service 72 hours later when the set top box DHCP
lease expired, and I'd buggered up a setting, so
this anecdote works both ways:-)

   [2]
https://www.independent.ie/irish-news/we-apologise-for-the-inconvenience-eir-says-broadband-service-now-restored-37416857.html

> 
>>> This is your opinion and I respect it, but I will note that
>>> pretty much everyone else in the privacy sphere seems quite
>>> concerned with the immense accumulation of data that the OTTs
>>> have built.
>> 
>> Calling them OTTs seems wrong to me. ISTM that all for-profit
>> mega- organisations pose a pervasive monitoring threat.
> 
> Yes, I agree with that. However, no telco has a truly global scale -
> at most, the biggest ones cover a few countries, often with several
> relatively independent companies.

From the POV of a stub resolver though, telcos aren't
that different in that they often see a lot or all
of a given person's traffic and, for mobiles, location
data. And while I can (and do) choose to not use most
of the services of what you call OTTs (almost all of
the time), I do need some ISP. So I don't accept that
one kind of commercial entity is inherently the bad
one and another the good one - certainly the level of
goodness or badness doesn't logically depend on the
OSI layer at which they offer services.

> However, it's true that, given the
> success of the OTTs (some of them in just a few years became the
> biggest and richest companies the world has ever seen), everyone else
> is also moving into the "data economy" - and the data economy is
> inherently allergic to privacy. 

So far, yes. The optimist in me hopes that that may
change as the advertising business model exhausts
itself (and gets regulated).

> But in the end, I think we should
> write another RFC entitled "Centralization and consolidation are an
> attack" :-)

I'll be interested in reading that draft,

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 23 Oct 2018 15:36:19 +0200

Hi Niels,

> we can take other considerations into account than we have not taken

I'll be happy to try at some point.  However, it is, as I've said
elsewhere, a difficult task; because some of the rights one seeks to
protect are themselves offended in the protection of others.  How do we
reconcile that in our protocols?

Eliot

---

From: [email-masked]
Date: Tue, 23 Oct 2018 14:33:39 -0400

Would a work product of this group be to recommend that this group,
and the IETF, adopt the UN UDHR, ICCPR, and IECSCR as a framework?

Analogous to the IETF's IPR, Anti-Harrassment policies, etc.

My thoughts:

Although the discussion here is interesting, and you might be
surprised that I have read most every word of it and many suggested
supporting documents, I don't think this group is likely to produce
anything with the footprint or insights of those documents.

Given such a generally agreed upon policy recommendation or even
adoption these could form a reference framework to work forward from
as to their effects on protocols and technologies per se.

I think this is what Niels ten Oever has been championing, no?

-- 
        -Barry Shein

---

From: [email-masked]
Date: Tue, 23 Oct 2018 15:51:34 -0400

On October 23, 2018 at 11:24 [email-masked] (Vittorio Bertola) wrote:
 > I agree that filtering at the endpoint, as recommended by that RFC,
 > would be preferrable for a number of reasons, but it is too
 > expensive and too hard to manage for many users, and impossible in
 > a growing number of cases (e.g. the "dumb" IoT devices - we used to
 > have one or two connected devices per home network, now we have
 > dozens).

Why would filtering at the endpoint be any more difficult than
anti-virus or netnanny services which already exist and are popular?

As with those one could subscribe, or be subscribed automatically, to
some third-party service maintaining updates and/or real-time
information which the endpoint software accesses.

Plus, for the more energetic, various options and control panels to
tune that or even shut it off entirely.

An ok user-facing architecture model might be Microsoft's various
bundled anti-virus tools. One can just use them as-is, turn them off,
or tweak them.

Plus the many third-party tools available to end-users.

-- 
        -Barry Shein

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 24 Oct 2018 14:06:09 +0200 (CEST)

> Il 23 ottobre 2018 alle 21.51 [email-masked] ha scritto:
>

It's not, and it's great if you can run an endpoint security application, but:

1) there are now many Internet-connected consumer devices that simply don't have the resources to run that kind of application (smart TVs, smart appliances, surveillance cameras, whatever) or even don't have update capabilities or local storage (two prerequisites for workable endpoint security);

2) even if the device allows it, running an antivirus requires attention and some skills by the user: you have to turn it on, you have not to turn it off the first time it blocks a malware-infected site hosting that football match video stream that you really want to see, you have to update it when it needs to, you have to renew your subscriptions, you have to be sure that nothing (e.g. some new malware that escaped its checks) blocked its functionality... not every user is going to get this right;

3) and in many cases, unless the security is really basic, the user has to pay quite some money for it, which not everyone is willing to do - splitting the cost of a single network-based solution among all the ISP's subscribers is much more cost-effective.

This is why many parental control/network security services (e.g. OpenDNS, DNSFilter...) rather adopted the DNS filtering model, and now network security devices for the home are appearing, e.g. Norton Core ( https://us.norton.com/core ): even antivirus makers are moving in that direction.

Regards,
--

---

From: [email-masked]
Date: Wed, 24 Oct 2018 14:27:07 -0400

> 1) there are now many Internet-connected consumer devices that simply don't have the resources to run that kind of application (smart TVs, smart appliances, surveillance cameras, whatever) or even…

Oh hasn't that been a historically bad bet in the computing and
standards world?

I started with machines with 64KB (kilo) max memory and computing
measured in KIPS (maybe 150 kiloinstructions/second.)

We are engaged in a rather painful transition from IPv4 to IPv6
because we thought 32-bits of address should be plenty and machines of
the day could compare and move 32-bits relatively quickly.

Now the $5 Raspberry PI zero has more computrons than entire defense
labs had back then and smartphones more computrons than 1990s
super-computers costing millions of dollars...Gordon Bell offered $1M
around 1990 to anyone who could produce a machine which could sustain
1 teraflop...now any decent phone can do that.

(ok, I'm an old fart, I had fun writing that, forgive me!)

 > 2) even if the device allows it, running an antivirus requires attention and some skills by the user: you have to turn it on, you have not to turn it off the first time it blocks a malware-infecte…

No different really than e.g. Microsoft's bundled anti-virus software.

I think one shouldn't argue against current use cases numbering in the
billions as being unworkable.

In many ways this "filtering" idea resembles the anti-virus software
ecosystem: Where does the software come from, how are filters updated,
etc.

 > 3) and in many cases, unless the security is really basic, the user has to pay quite some money for it, which not everyone is willing to do - splitting the cost of a single network-based solution…

Again, MS anti-virus software comes bundled which in turn comes
bundled with machines and their OS, few notice the cost. And third
party anti-virus packages are popular.

But the real point is, and speaking even as an ISP, I don't WANT the
ISP to filter content unless I ask them to and even then. We might
have to due to a legal order but that's different and both can go on.

I want ISPs to only filter what is relevant to their operational or
specific legal concerns.

We block a lot of spam sources primarily because they often resemble a
denial of service attack flooding our bandwidth and slowing our
servers, not because we don't trust the quality of the content per se.

Ok we run a virus filter and spamassassin for example also as a
courtesy to customers but our interest is primarly operational,
including not having our support etc have to deal with virus-infected
customers with flooded mailboxes.

 > This is why many parental control/network security services (e.g. OpenDNS, DNSFilter...) rather adopted the DNS filtering model, and now network security devices for the home are appearing, e.g. N…

That's really little different than what I am advocating.

-- 
        -Barry Shein

---

From: Mallory Knodel <[email-masked]>
Date: Thu, 25 Oct 2018 11:20:33 +0200

Hi,

I like the direction that this particular sub-debate is doing and after
talking to Vittorio in Barcelona and ICANN I'd just highlight two points
that have been made by both of you (and others in the thread) at one
point or another:

 * Filtering/blocking is an exception. It is, literally and by
definition, an exception. So what does a standards setting body do with
exceptions? I think it requires us to think very carefully about whether
or not a standard should treat an exception and if so, how it does that
very carefully without refactoring other standards to the lowest common
denominator.

 * Filtering/blocking (exceptions!) should be handled as close to the
end point as possible. This is anti-virus, netnanny, etc. The end user
must opt-in, have control, or at the very least have awareness and
clarity around their choice to not receive content. When it's framed
this way-- user empowerment-- it actually resonates a lot more closely
with nuanced legal positions on the human right to freedom of expression
(vs hate speech, incitement to violence, etc etc).

-Mallory

-- 
Mallory Knodel
Head of Digital :: article19.org
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9  B071 0C32 A271 BD3C C780

---

From: Nalini J Elkins <[email-masked]>
Date: Thu, 25 Oct 2018 14:13:15 +0000 (UTC)

> * Filtering/blocking is an exception. It is, literally and by definition, an exception. 
Agreed.    As minimally intrusive as possible. Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Mallory Knodel <[email-masked]>
 To: [email-masked] 
 Sent: Thursday, October 25, 2018 2:20 AM
 Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt
   
Hi,

-Mallory

On 24/10/2018 20:27, [email-masked] wrote:
>  > > Il 23 ottobre 2018 alle 21.51 [email-masked] ha scritto:
>  > >
>  > > Why would filtering at the endpoint be any more difficult than
>  > > anti-virus or netnanny services which already exist and are popular?
>  > 
>  > It's not, and it's great if you can run an endpoint security application, but:
>  > 
>  > 1) there are now many Internet-connected consumer devices that simply don't have the resources to run that kind of application (smart TVs, smart appliances, surveillance cameras, whatever) or even don't have update capabilities or local storage (two prerequisites for workable endpoint security);
> 
>  > 
>  > 2) even if the device allows it, running an antivirus requires attention and some skills by the user: you have to turn it on, you have not to turn it off the first time it blocks a malware-infected site hosting that football match video stream that you really want to see, you have to update it when it needs to, you have to renew your subscriptions, you have to be sure that nothing (e.g. some new malware that escaped its checks) blocked its functionality... not every user is going to get this right;
> 
>  > 
>  > 3) and in many cases, unless the security is really basic, the user has to pay quite some money for it, which not everyone is willing to do - splitting the cost of a single network-based solution among all the ISP's subscribers is much more cost-effective.
> 
>  > 
>  > This is why many parental control/network security services (e.g. OpenDNS, DNSFilter...) rather adopted the DNS filtering model, and now network security devices for the home are appearing, e.g. Norton Core ( https://us.norton.com/core ): even antivirus makers are moving in that direction.
> 
>  > 
>  > Regards,
>  > -- 
>  > 
>  > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
>  > [email-masked]
>  > Office @ Via Treviso 12, 10144 Torino, Italy
>  > 
>  > _______________________________________________
>  > hrpc mailing list
>  > [email-masked]
>  > https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: [email-masked]
Date: Thu, 25 Oct 2018 16:56:34 -0400

>  * Filtering/blocking is an exception.

By numbers, I wish filtering and blocking spam were an exception but
some estimate it's up to 90% of all email traffic which as an ISP I
believe.

But there is the issue of quantity vs quality. Blocking everything
critical of the King of Lower Slobbovia (pick a venue, Twitter,
Facebook, etc) would probably be very little traffic but could still
be significant event.

That's probably just a nit in the scheme of things.

I too have been advocating for keeping it as close to the endpoint as
possible, as you express. We agree!

A possible longer term goal is some sort of technical standards to
effect all this.

I've offered, as a broad analogy, DNS as a distributed framework but
other models exist (anti-viral, anti-spam, etc.), again as you also
express.

-- 
        -Barry Shein

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Oct 2018 09:55:26 +0200

I think the key issue here is about who and where, not mechanism.

Eliot

---

From: [email-masked]
Date: Fri, 26 Oct 2018 14:42:23 -0400

> I think the key issue here is about who and where, not mechanism.

I'd agree the issues will be resolved in roughly that order, no point
in expending great effort on the details of a mechanism unless there's
some sort of common vision on what should be done.

But I think there's use in thumbnailing a mechanism even if just to
answer "how would such a thing even work?!"

Note that some have expressed here that moving it out to the endpoints
would be unworkable for people so drawing (strong) analogies to DNS,
anti-virus and similar software seems like it should allay such
concerns at least as deal-killers.

-- 
        -Barry Shein

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Oct 2018 20:48:34 +0200

Hi Barry,

> answer "how would such a thing even work?!"

I think that's fair, and the more specific the better, if it actually is
being used today.

> concerns at least as deal-killers.
I'm having difficulty parsing this sentence.  My view is that some
functions cannot or should not reasonably be performed on end systems
(cf spam filtering).  But that doesn't meant that the user shouldn't
have visibility to what is being done.  That's a hard problem unto itself.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 26 Oct 2018 20:59:22 +0100

Hiya,

On 26/10/2018 19:48, Eliot Lear wrote:
>  My view is that some
> (cf spam filtering). 

I'm not sure I'd agree as there are junk/spam reporting
buttons in most MUAs, but moreso as the mail ecosystem,
being one that really connects any mail sender to any
mail recipient via highly capable mail intermediaries,
is not at all the same as protocols that are intended
to operate without such intermediaries, and that typically
do not have to attempt to allow message delivery from
anywhere to anywhere. And of course we have decades of
not getting rid of spam to perhaps help convince us that
not all is well in the anti-spam world.

So we need to be a bit careful what lessons we try read
from spam filtering.

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Oct 2018 23:38:54 +0200

On 26.10.18 21:59, Stephen Farrell wrote:
> buttons in most MUAs, 

As you know, by the time the mail is delivered the harm is largely
done.  In fact that was a very interesting paper by Stefan Savage and
friends some time ago about pharma spam.  We couldn't weed the stuff out
fast enough, with whatever blocking mechanism because these people had
made their money in 72 hours on already-delivered mail.  It's an
interesting area because it argues for retroactive removal of stuff in
peoples' mailboxes.

ButI think there is another issue lurking here with regard to the email
system.  While the protocols allow for agency and permission etc, at
least at the host level, a vast swathe of people just use gmail and
yahoo for their mail, meaning that they are choke points for filtering
in a way that we might not like.  And it's not that easy to change your
email address.  In fact it's a pain in the butt.  That topic may be
worth exploring a bit.

Eliot

---

From: [email-masked]
Date: Fri, 26 Oct 2018 17:49:21 -0400

> have visibility to what is being done.  That's a hard problem unto itself.

Sorry, I just meant that other services are controlled at the endpoint
such as spam and antivirus. Not all aspects of them but nonetheless
they are endpoint applications for many -- I think it's safe to say
"billions" of endpoints.

So the proposal that filtering and blocking be as much at the
endpoints as possible certainly has its analogues, and in production.

I've mentioned for example legal takedowns which arguably have to
occur in middleboxes if not at the core services depending on where
control can be exerted.

But much of the content discussed for filtering and blocking such as
"objectionable content" is largely in the eyes of the beholder even if
that means many eyes with the same opinion -- "many" still doesn't
/prima facie/ argue for centralized blocking.

And, as with spam, viruses, etc hybrid solutions are not only possible
but likely desirable.

For example an application on an endpoint which queries a service
about certain qualities of a host or content about to be accessed (we
already have this in web malware avoidance) and might automatically
block certain content or entire hosts via something like a netnanny
program or just warn.

Or a proxy or even content-originating service which tags content
continuously in a way that an endpoint application can filter.

For example the well-known NSFW tag often added voluntarily by the
content creator or distributor.

Much of that, I will argue, should be under the control of the
endpoint.

If one is ok with NSFW-tagged material then shut off any filtering of
that in your endpoint application, if not then enable that filter. &c.

-- 
        -Barry Shein

---

From: [email-masked]
Date: Fri, 26 Oct 2018 18:04:01 -0400

> So we need to be a bit careful what lessons we try read

Indeed, spam is the repeated warning shot across everyone's bow.

Gilmore's famous comment that "the internet views censorship as damage
and routes around it" is very much true of spam as we've seen where
"the internet" is obviously intended as a metonymy for everyone who
has access to the internet, including spammers.

In our mind's eye we continue to imagine qualities of the internet
which simply may not exist.

Just as certain FBI directors imagined that an encryption protocol
should exist which is safe for desirable use but contains a backdoor
for law enforcement.

Such an easily understood concept! Why not? Like a good door lock
which also provides a master key to those authorized.

Yet one cryptography expert after another has warned that as simple as
that might seem it's impossible with current technology, and may be
impossible with any technology.

Similar for filtering and blocking, at least based on our experience
with spam.

It's the scaling problem writ big.

Nonetheless there might be value in producing standards around what
might be folly if for no other reason than to minimize collateral
damage from really dumb and/or ham-handed attempts, including simply
productivity waste re-inventing the square wheel endlessly. And surely
that's one major function of most engineering standards.

-- 
        -Barry Shein

---

From: [email-masked]
Date: Fri, 26 Oct 2018 18:14:28 -0400

> interesting area because it argues for retroactive removal of stuff in

It was several years ago but the lead attorney for a big Verizon
anti-spam case said they discovered the typical lifetime for a host
for a link mentioned in a spam message was 30 MINUTES.

The spammers use that host for about 30 minutes and then abandon it
because they know it will be blocked and/or taken down.

 > email address.  In fact it's a pain in the butt.  That topic may be

A lot of people used Google+...500M regularly I think is the usual
number. And it's shutting down. Such are the ways of free to the user
services.

And what about all the corporate etc sites which run their own email
systems?

I'm not sure I buy these sorts of stochastic / demographic arguments
unless they really lead to the conclusion that the potential
beneficiaries are miniscule in numbers.

And who says one wouldn't want protection from gmail, yahoo, etc? That
is, a superset of their filtering. As we've seen it's likely to tend
towards their own internal groupthink idea of social pariah or not.

But a lot of this revolves around web and similar content.

-- 
        -Barry Shein

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 26 Oct 2018 23:15:54 +0100

Fully agree that spam is hard and a FUSSP won't be found.

> that's one major function of most engineering standards.

Disagree there though. IMO neither research groups in the IRTF
nor the IETF ought set out to add to the piles of nonsense that
are inevitably associated with hard problems. Aiming to do way
better than that is one of this community's strengths IMO. (We
of course fail often, but such is life;-)

S.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 27 Oct 2018 15:46:32 +0200

Hi Stephen,

> of course fail often, but such is life;-)

When I consider this problem in another context I find myself wondering
whether we really do have a role: _Consider Keys Under Doormats_**and
LI.  In that paper the authors raise three general concerns:

 1. Loss of PFS
 2. System complexity
 3. Target concentration

I think we could imagine a lengthier list with sub-bullets.  But suppose
each proposed mechanism coming from various communities were put to an
evaluation of these concerns.  To start that evaluation one needs to
have the mechanisms documented.  At the very least it seems to me such
an evaluation has academic, of not practical, merit.  Whether those
mechanisms are documented  as RFC or something else doesn't really
matter, so long as they are well described.  Once implemented, however,
at that point one has to evaluate whether one wants to encourage least
worst.  From a vendor standpoint, as someone who might otherwise be
required to implement multiple mechanisms to enter various markets,  all
but one of which would be worse than the least worst, surely that is
what I would want.

That mechanism would *surely* have HR implications, but does that make
it the wrong thing to do? 

I view filtering in this same light.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 27 Oct 2018 16:20:11 +0100

Hiya,

> it the wrong thing to do? 

I'm not sure enough of what "it" you mean to have an
answer.

I can say though that if the E in IETF means anything
at all, then we ought not set out to produce what we
know is crap, which is the part of Barry's argument
with which I was disagreeing.

We do have to deal with crap that exists in the world,
but we don't have to, and shouldn't, invent crap.

S.

---

From: Vittorio Bertola <[email-masked]>
Date: Sat, 27 Oct 2018 17:52:59 +0200 (CEST)

> Il 27 ottobre 2018 alle 17.20 Stephen Farrell <[email-masked]> ha scritto:
>  

Let me understand better your views: while I restate one more time that weakening cryptography is indeed crap, would any other mechanism for content control be crap as well in your opinion? Let's say we create a mechanism for anti-malware company X or content classification provider Y to publish and transmit a list of "bad stuff to be blocked/put behind a warning screen" in a secure and authenticated way, and for anyone to pick it up and implement it if they want (or if they are required by law). Would this in your opinion be crap, on the grounds that blocking stuff is always crap even if well engineered, or not?

Regards,
--

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 27 Oct 2018 17:17:02 +0100

On 27/10/2018 16:52, Vittorio Bertola wrote:
>> I can say though that if the E in IETF means anything at all, then
>> we ought not set out to produce what we know is crap, which is the
>> part of Barry's argument with which I was disagreeing.
>> 
>> We do have to deal with crap that exists in the world, but we don't
>> have to, and shouldn't, invent crap.
> 
> Let me understand better your views: while I restate one more time
> that weakening cryptography is indeed crap, would any other mechanism
> for content control be crap as well in your opinion? Let's say we
> create a mechanism for anti-malware company X or content
> classification provider Y to publish and transmit a list of "bad
> stuff to be blocked/put behind a warning screen" in a secure and
> authenticated way, and for anyone to pick it up and implement it if
> they want (or if they are required by law). Would this in your
> opinion be crap, on the grounds that blocking stuff is always crap
> even if well engineered, or not?

Can't say from the above, sorry.

I can say that the Google Safe Browsing scheme [1] isn't too
bad, if used in what they appear to now call update mode (when
client sends a prefix hash to server). I could imagine a useful
standard built along those lines that'd allow clients to use
a set of servers. (Note - I'm not clear if that scheme is
getting worse or better, I didn't recall it having a variant
where the browser sends actual URLs before for example but
that now seems to exist.)

I also liked the scheme Roland presented a couple of IETF's
ago (more recently presented at [2] I guess) for using Bloom
filters to log DNS queries in a better manner. Something like
that could also be an enabler for a sane filtering scheme
perhaps.

Point is - with a bit of thought and paying actual attention
to privacy (rather than the lip service that seems the norm
for many companies), one can do what's needed and not damage
other parts of Internet security and privacy.

S.

[1] https://developers.google.com/safe-browsing/v4/
[2] https://tnc18.geant.org/getfile/4238

---

From: Nalini J Elkins <[email-masked]>
Date: Sat, 27 Oct 2018 20:42:17 +0000 (UTC)

All,
Sorry for the top post.  I am in transit to India.   Made it to Singapore!  I am trying unsuccessfully to keep up with emails.   
Some very positive and constructive comments by many people.
I will work with Vittorio & Barry to summarize comments.    We need to separate the DNS over HTTPS issues from filtering (both are important!).
Need to get the privacy folks involved.   I will talk to some on this email chain who will also be in India.
Let's think about venue also.  I have gotten interest from ETSI and ITU.   But frankly, IMHO, IETF / IRTF needs to be involved.   No one has time to waste so let's also think about what we want to gain from each venue, if needed. Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

      From: Eliot Lear <[email-masked]>
 To: Stephen Farrell <[email-masked]>; [email-masked] 
Cc: Mallory Knodel <[email-masked]>; [email-masked]
 Sent: Saturday, October 27, 2018 9:46 PM
 Subject: Re: [hrpc] New Version Notification for draft-elkins-hrpc-ifilter-00.txt
   
 Hi Stephen,

 When I consider this problem in another context I find myself wondering whether we really do have a role: Consider Keys Under Doormats and LI.  In that paper the authors raise three general concerns:
    
   - Loss of PFS
   - System complexity
   - Target concentration
 I think we could imagine a lengthier list with sub-bullets.  But suppose each proposed mechanism coming from various communities were put to an evaluation of these concerns.  To start that evaluation one needs to have the mechanisms documented.  At the very least it seems to me such an evaluation has academic, of not practical, merit.  Whether those mechanisms are documented  as RFC or something else doesn't really matter, so long as they are well described.  Once implemented, however, at that point one has to evaluate whether one wants to encourage least worst.  From a vendor standpoint, as someone who might otherwise be required to implement multiple mechanisms to enter various markets,  all but one of which would be worse than the least worst, surely that is what I would want. That mechanism would surely have HR implications, but does that make it the wrong thing to do?  
  I view filtering in this same light.
  Eliot _______________________________________________
hrpc mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/hrpc

---

From: [email-masked]
Date: Sun, 28 Oct 2018 15:01:16 -0400

> of course fail often, but such is life;-)

I put "might be" folly to allow wriggle room.

We don't really know for certain.

And we probably won't know until we follow down that path some more.

Again analogous to the demands for a cryptography standard which works
for desirable uses but provides a back-door for law enforcement.

How was it determined whether that's folly or not?

By pursuing the idea as if it is reasonable -- it has the superficial
qualities of a reasonable request -- and then concluding it is not
reasonable and explaining why.

And our experience with 20+ years of trying to control the spam
problem which in many ways is much simpler* hasn't been encouraging
even though the problem space is similar (block stuff I don't want.)

* I say simpler because there's wide agreement on what is spam at
least in a lot of cases such as phishing, extortion (very popular
right now), you just won a lottery or donation, dicey products from
dicier sources, I am the wife of Qaddaffi, 419 spam, etc.

There are edge cases but if all the spam we got were the edge cases I
suspect it would be considered less of a problem.

What is "objectionable content" won't be so easily defined.

-- 
        -Barry Shein

---

From: [email-masked]
Date: Sun, 28 Oct 2018 15:38:01 -0400

An HR implication of a universal, standardized content tagging
mechanism would be that it would likely make the job of those who
would suppress others' rights based on posted content easier.

For example if the govt of Slobbovia decided to round up everyone
within their purview who was critical of the King of Slobbovia then
starting with everything tagged as "King of Slobbovia: criticism"
would probably be a good place to start.

And it's reasonable to assume that some organization would do their
best to archive such tags and perhaps content and/or metadata and sell
access to that as a service.

RAAS -- Repression As A Service.

Perhaps this just falls under: Any powerful tool can be used for good
or evil.

Put another way, such a tagging mechanism might make such repression a
little easier but it's not very difficult to do now, e.g., via widely
available search tools and data mining.

-- 
        -Barry Shein

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 28 Oct 2018 19:45:10 +0000

Hiya,

> reasonable and explaining why.

That's fair. I would assert though that such research
shouldn't need any RFCs or standards. If the work shows
that there is no acceptable solution, (as in backdoor'd
crypto) then we're better off without things that are
easily confused with standards. If the work shows that
there are some acceptable solutions, then standardisation
of those can be pursued, and I'm guessing we'd all agree
that ending up with a minimal number of standards (be
that 0 or more) is desirable.

> What is "objectionable content" won't be so easily defined.

Yep. Esp given the subjectivity in that case is far more
pronounced than in the case of spam, which we've so far
failed to control. (In case someone objects that they do
not see spam, see [1] which is a bit salesy but worth a
read.)

Cheers,
S.

[1]
https://www.sendforensics.com/kbfiles/SendForensics-IEEE-Software-Article-Aug2017.pdf

---

From: [email-masked]
Date: Sun, 28 Oct 2018 15:50:39 -0400

Ah the struggle between voluminous quoting vs paraphrasing.

I didn't say we know it is "crap" or anything quite like that.

I said it* "might be folly" due to scaling problems, the net's strong
tendency to "route around censorship", and experience with blocking
and filtering spam.

My point being that we likely can't really know whether it's folly or
not without exploring the idea further.

That's quite different from knowing it's "crap" and pursuing it
anyhow.

We don't know.

* Where "it" is some standardized mechanism for filtering, tagging,
and less likely blocking, blocking per se is probably an application
of the first two though it might benefit from some elucidated
standardization (e.g., a way to inform the endpoint a block is
VOLUNTARY, INVOLUNTARY, REGIONAL, IPR, ADVISORY, etc.)

-- 
        -Barry Shein

---

From: Niels ten Oever <[email-masked]>
Date: Mon, 29 Oct 2018 09:16:18 +0100

> reconcile that in our protocols?

This has been mentioned several times, but if we want to find a solution
it is probably better if we work from concrete data. So it would be
great if you could have a look at the Human Rights Reviews that have
been done, or do one yourself, and point out where the pressure points are.

Best,

Niels