Subject: [hrpc] Human Rights relating to racism and xenophobia

From: Tony Rutkowski <[email-masked]>
Date: Tue, 10 Jul 2018 13:42:21 -0400

Hi all,

This rather extensive body of human rights law is rather visible and of
significant global concern these days.   See, e.g.,
http://www.circleid.com/posts/20180702_trumps_tweets_flouting_the_cybercrime_treaty_curbs_on_racist/

Somewhat disconcerting is the apparent lack of this body of human right
law ever being raised in hrpc, much less considered.  Is there an
explanation?  Or nobody cares?

--tony

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 10 Jul 2018 22:09:18 +0200

Hi Tony,

> http://www.circleid.com/posts/20180702_trumps_tweets_flouting_the_cybercrime_treaty_curbs_on_racist/

Are you calling the Budapest Convention human rights law? That might be
a bit of a stretch.

> explanation?  Or nobody cares?

Out of curiosity: how do you think these concerns could or should be
addressed on a protocol level?

I thought you were of the opinion that RFC8280 was 'decidedly
non-technical' and should refrain from launching 'into bizarre territory
when dealing with non-technical matters' [0]. So maybe we're just
following your advice by not discussing the Budapest Convention here?

Always happy to discuss how we could work on anti-discrimination on
protocol level.

Best,

Niels

[0]
http://www.circleid.com/posts/20171112_weaponizing_the_internet_using_the_end_to_end_principle_myth/

Best,

Niels

> --tony
> 
> 
> 
> 
> _______________________________________________
> 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: Tony Rutkowski <[email-masked]>
Date: Tue, 10 Jul 2018 16:51:45 -0400

Hi Niels,

Clearly the additional protocol is regarded as human rights law.  I
don't know of any credible human rights lawyer who would dismiss it and
the many other human rights instruments dealing with xenophobia and
racism.  FYI,  a portion of my career over the past 50 years has
included many significant human rights legal activities at local and
Federal levels in the U.S., and internationally in multiple bodies; and
one of my majors at one of the more notable U.S. law schools was Human
Rights Law.  I was also one of the UNHCR's experts at the 1997 Geneva
workshop on this subject.  As some of my relatives about 80 years ago
were the victims of xenophobic regimes in power in Europe, I'll admit to
being especially sensitive on the matter.

Clearly what has occurred over the past two years in the U.S. and is
unfolding in many countries worldwide in promoting xenophobia and racism
on a level never witnessed before - especially on social media protocols
- gives rise to concern.  Indeed, some of the major industry players
here have taken some responsive steps - at least in part because of
pressure from the EU authorities.  There was even a proposal in ETSI to
produce a structured information exchange protocol for reporting abuses
in promoting racism and xenophobia.  It is one of many potential
technical protocol steps that could be taken.

I continue to have concerns about the underlying ontology of RFC8280 -
which are in fact exemplified by the "use cases" at issue here. 
Significant classes of human rights seem to be simply totally ignored -
such as people subject to social media led efforts to bring harm to them
because of their race, nationality, or ethnic origin.  Even perfunctory
search suggests the exponentially increased scale of the problem and the
impact.  See, e.g.,
http://www.politicalanthropologist.com/2018/04/11/cyber-racism-can-learnt-australia/

So the question remains, does this hrpc venue care...or not?  One would
expect some nominal responsive activity.

--tony

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 10 Jul 2018 22:56:20 +0200

Hi Tony,

> expect some nominal responsive activity.

I very much recognize the problem and its severity, but I don't see how
this is an issue that can be addressed through protocols and standards.
Again, am more than willing to consider your suggestions.

All the best.

Niels

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Jul 2018 17:03:49 -0400

Niels, to take an example that we've all seen, SMTP is horrible from this
perspective, because it's totally non-consensual.   If you can receive
email, anyone can send it to you.   Compare to social networks, like
facebook, where people can't see your information or communicate with you
without your consent (unless they are advertisers, of course, but I'm
talking about the paradigm, not the bad implementation).   If someone were
inventing SMTP today, it would look very different.

It seems pretty clear to me that protocols *can* be designed to make
problems of the sort Tony is talking about less serious.   Can they be
entirely eliminated?   Perhaps not, but I think it's an interesting
question, not something we should dismiss out of hand.   And of course
there are implications to these mitigation strategies as well—the ability
of someone who has been excluded from speaking is very strongly inhibited
by opt-in communication.   If that person is a spammer, we all rejoice.
If they are poor and disenfranchised, it might be a relief not to hear from
them, but it's also a problem that they have nowhere to turn.

I think that ultimately these problems will not be *solved* by
communications protocols, but that is not the same thing as saying that
communications protocols have no role in solving them.

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 10 Jul 2018 17:28:58 -0400

There are a considerable array of protocols and standards that can be
mapped out.  Attached is a fairly simply initial standard protocol
discussed two years ago dealing with only one requirement.

A Google Scholar search on "internet + xenophobia + racism" provides
about 26,000 results.  Try narrowing on this year and last.  If you add
AI to the mix, you get a sense of the ongoing R&D today.

--tony

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Jul 2018 11:09:55 +1000

Good points, Ted. This is interesting, and reminds me of the different natures of work at the IETF:

1) We work on a number of established protocols, e.g., IP, TCP, BGP, HTTP. Here, changes are typically constrained by existing deployment; in other discussions, we call this ossification when it prevents us from meeting goals like security, performance, operability, scalability, etc. 

However, it also prevents changes to many characteristics that might harm *or* help human rights. For example, we can't address the fundamental problems with SMTP (because it would be backwards-incompatible), but we also can't introduce extensions to share what people do over HTTPS with their networks (because that breaks the fundamental assumptions of HTTPS and TLS).

Often, the best we can do is document the existing properties of the protocols and work around the edges (e.g., new status codes -- although I still question the value that 451 provides).

I'd assert that this is largely good; systems that behave in stable and predictable ways give humans a chance to familiarise themselves with their properties and build models and expectations over time. Even if there are HR-negative properties, they can be mitigated by users avoiding those properties / systems where appropriate. This is better than unpredictable change.

2) We also work on new things, when the stars line up. Here we have the chance to create new systems and properties out of thin air -- as Lessig says, code is law.

It's easy to think of new work as a clean slate, but it's constrained by what's technically viable, what will work in the marketplaces of implementers *and* users, and who has energy to put into it.

For example, WebRTC's lack of federation is seen by some as necessary for its success, and by others (AIUI) as an unfortunate omission. What's interesting to me is that federation seems to have left a very positive impression on many who also espouse the importance of human rights (please correct me if I'm wrong!), and yet its omission seems to help avoid the problems that SMTP has encountered.

The upcoming MLS would be interesting to analyse in this light. 

Cheers,

> On 11 Jul 2018, at 7:03 am, Ted Lemon <[email-masked]> wrote:
> 
> Niels, to take an example that we've all seen, SMTP is horrible from this perspective, because it's totally non-consensual.   If you can receive email, anyone can send it to you.   Compare to social networks, like facebook, where people can't see your information or communicate with you without your consent (unless they are advertisers, of course, but I'm talking about the paradigm, not the bad implementation).   If someone were inventing SMTP today, it would look very different.
> 
> It seems pretty clear to me that protocols can be designed to make problems of the sort Tony is talking about less serious.   Can they be entirely eliminated?   Perhaps not, but I think it's an interesting question, not something we should dismiss out of hand.   And of course there are implications to these mitigation strategies as well—the ability of someone who has been excluded from speaking is very strongly inhibited by opt-in communication.   If that person is a spammer, we all rejoice.   If they are poor and disenfranchised, it might be a relief not to hear from them, but it's also a problem that they have nowhere to turn.
> 
> I think that ultimately these problems will not be solved by communications protocols, but that is not the same thing as saying that communications protocols have no role in solving them.
> 
> On Tue, Jul 10, 2018 at 4:56 PM, Niels ten Oever <[email-masked]> wrote:
> Hi Tony,
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Mallory Knodel <[email-masked]>
Date: Wed, 11 Jul 2018 10:06:21 +0300

I agree that this is really interesting. And I can see some overlap with
issues of sexism and gender discrimination online as well.

As for Tony's original question: Yes, I can speak for myself that
absolutely I have interest in this topic. And for the group, perhaps
expertise and interest is simply not demonstrated by posting to the list
and writing drafts on the topic.

I also think that racism is often overlooked and important to raise
again and again. So thanks for doing that. And sharing resources to get
us started on a discussion.

-Mallory

On 11/07/18 04:09, Mark Nottingham wrote:
> 1) We work on a number of established protocols, e.g., IP, TCP, BGP,
> HTTP. Here, changes are typically constrained by existing deployment;
> in other discussions, we call this ossification when it prevents us
> from meeting goals like security, performance, operability,
> scalability, etc.
> 
> However, it also prevents changes to many characteristics that might
> harm *or* help human rights. For example, we can't address the
> fundamental problems with SMTP (because it would be
> backwards-incompatible), but we also can't introduce extensions to
> share what people do over HTTPS with their networks (because that
> breaks the fundamental assumptions of HTTPS and TLS).
> 
> Often, the best we can do is document the existing properties of the
> protocols and work around the edges (e.g., new status codes --
> although I still question the value that 451 provides).
> 
> I'd assert that this is largely good; systems that behave in stable
> and predictable ways give humans a chance to familiarise themselves
> with their properties and build models and expectations over time.
> Even if there are HR-negative properties, they can be mitigated by
> users avoiding those properties / systems where appropriate. This is
> better than unpredictable change.
> 
> 2) We also work on new things, when the stars line up. Here we have
> the chance to create new systems and properties out of thin air -- as
> Lessig says, code is law.
> 
> It's easy to think of new work as a clean slate, but it's constrained
> by what's technically viable, what will work in the marketplaces of
> implementers *and* users, and who has energy to put into it.
> 
> For example, WebRTC's lack of federation is seen by some as necessary
> for its success, and by others (AIUI) as an unfortunate omission.
> What's interesting to me is that federation seems to have left a very
> positive impression on many who also espouse the importance of human
> rights (please correct me if I'm wrong!), and yet its omission seems
> to help avoid the problems that SMTP has encountered.
> 
>> Niels, to take an example that we've all seen, SMTP is horrible
>> from this perspective, because it's totally non-consensual.   If
>> you can receive email, anyone can send it to you.   Compare to
>> social networks, like facebook, where people can't see your
>> information or communicate with you without your consent (unless
>> they are advertisers, of course, but I'm talking about the
>> paradigm, not the bad implementation).   If someone were inventing
>> SMTP today, it would look very different.
>> 
>> It seems pretty clear to me that protocols can be designed to make
>> problems of the sort Tony is talking about less serious.   Can they
>> be entirely eliminated?   Perhaps not, but I think it's an
>> interesting question, not something we should dismiss out of hand.
>> And of course there are implications to these mitigation strategies
>> as well—the ability of someone who has been excluded from speaking
>> is very strongly inhibited by opt-in communication.   If that
>> person is a spammer, we all rejoice.   If they are poor and
>> disenfranchised, it might be a relief not to hear from them, but
>> it's also a problem that they have nowhere to turn.
>> 
>> I think that ultimately these problems will not be solved by
>> communications protocols, but that is not the same thing as saying
>> that communications protocols have no role in solving them.
>> 
>> On Tue, Jul 10, 2018 at 4:56 PM, Niels ten Oever
>> <[email-masked]> wrote: Hi Tony,
>> 
>>> I continue to have concerns about the underlying ontology of
>>> RFC8280 - which are in fact exemplified by the "use cases" at
>>> issue here. Significant classes of human rights seem to be simply
>>> totally ignored - such as people subject to social media led
>>> efforts to bring harm to them because of their race, nationality,
>>> or ethnic origin.  Even perfunctory search suggests the
>>> exponentially increased scale of the problem and the impact.
>>> See, e.g., 
>> I very much recognize the problem and its severity, but I don't see
>> how this is an issue that can be addressed through protocols and
>> standards. Again, am more than willing to consider your
>> suggestions.
>> 
>> All the best.
>> 
>> Niels
>> 
>> 
>> -- 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
>> 
>> _______________________________________________ hrpc mailing list 
>> [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
>> 
>> _______________________________________________ hrpc mailing list 
>> [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
> 
> -- Mark Nottingham   https://www.mnot.net/
> 
> _______________________________________________ hrpc mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/hrpc
> 

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

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 11 Jul 2018 09:17:46 +0200

Hi Tony,

Thanks for the pointer. In that sense I think the latest report of the
Special Rapporteur for Freedom of Expression is also relevant:

https://freedex.org/a-human-rights-approach-to-platform-content-regulation/

I am still having a hard time understanding how networking protocols can
help make this better, because it rather seems (also from your example)
that this needs institutional intervention or approaches at the
application layer.

As always, happy to discuss.

Best,

Niels

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 11 Jul 2018 09:28:21 +0200

Hi Ted,

On 07/10/2018 11:03 PM, Ted Lemon wrote:
> Niels, to take an example that we've all seen, SMTP is horrible from
> this perspective, because it's totally non-consensual.   If you can
> receive email, anyone can send it to you.   Compare to social networks,
> like facebook, where people can't see your information or communicate
> with you without your consent (unless they are advertisers, of course,
> but I'm talking about the paradigm, not the bad implementation).   If
> someone were inventing SMTP today, it would look very different.
> 

Interesting. I thought that the success of email could at least in part
be attributed to the fact that everyone can send you email. So people
who would like to get in contact don't need consent.

In case people cross the line one can set filters for them, but then
again they can create new accounts.

Where it comes to spam there is of course the issue around spamfilters
and RPZ. We have tried to talk about it before in an earlier version of
draft-association to see whether sending unwarranted information could
be seen as part of freedom of association and assembly, or as part of
freedom of expression. But because it would simply drown out other
communication and then again it would be harmful for exactly the same
rights.

I still have some issues with RPZ though, because it could exactly be
used to exclude speech, in a way that is almost impossible to counter.
Everyone whose IP ranges have ever been blacklisted can account for
this, also because it is often nearly impossible to find out what
triggered it.

The latest trend, as Tony mentioned, seems to be more algorithms to
differentiate spam from ham, but these are hard to query and to hold to
account. At the same time the sheer volume of messages is too large for
people to check, let alone the privacy considerations of such an endeavor.

In short: I think it would be great to address this on a networking
protocol level, but I am having a hard time thinking of what it would
look like.

If we could come up with a set of conditions for an SMTP like protocol,
we could write a human rights review for that which could inform new
protocol development - I'd be all up for that!

Best,

Niels

> It seems pretty clear to me that protocols /can/ be designed to make
> there are implications to these mitigation strategies as well—the
> ability of someone who has been excluded from speaking is very strongly
> inhibited by opt-in communication.   If that person is a spammer, we all
> rejoice.   If they are poor and disenfranchised, it might be a relief
> not to hear from them, but it's also a problem that they have nowhere to
> turn.
> 
> I think that ultimately these problems will not be /solved/ by
> On Tue, Jul 10, 2018 at 4:56 PM, Niels ten Oever <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi Tony,
> 
>     <http://www.politicalanthropologist.com/2018/04/11/cyber-racism-can-learnt-australia/>
>     >
>     [email-masked] <mailto:[email-masked]>
>     <https://www.irtf.org/mailman/listinfo/hrpc>
> 
>

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 11 Jul 2018 10:43:30 +0200 (CEST)

> Il 11 luglio 2018 alle 9.28 Niels ten Oever <[email-masked]> ha scritto:

This is also true for email blacklists in general. If a big player like Gmail or Hotmail or a widely used anti-abuse vendor blacklists your server for whatever reason, you are effectively prevented from communicating with a significant chunk of the planet. Servers are usually blacklisted automatically and algorithmically, and, if you are a small sender, usually it is near to impossible, or completely impossible, to get someone to review the decision or even to get any reply at all. (In some cases, with some blacklist providers, a review is possible only as long as you agree to pay them money, which sometimes looks like extortion.) These algorithms are intransparent and they do make mistakes, which are generally considered as collateral damage that no one cares about. 

So this, maybe, would be a technically significant issue that could be dealt with at the protocol level, though I must say that it is mostly about policies, rather than about protocols. But some standardized best practice on how to deal with these problems, i.e. whether and how ISPs that implement web/email blacklisting for their end users should remediate false positives, could be useful, at least if it had sufficient authoritativeness to be cared about by companies that of course are very focused on their cost effectiveness.

On the other hand, I am not sure how a racist tweet is different from a racist sentence uttered on a bus - it looks to me like a generic content issue that does not depend on technical issues or protocols. The blacklisting problem is created by the way the Internet works, but racist content could be propagated over any communication protocol, and I cannot imagine any protocol-based mechanism specifically conceived to detect and prevent racist content, assuming that it is actually legal to prevent it (depends on jurisdiction). But if people have practical proposals, I'd be happy to hear them.

> protocol development - I'd be all up for that!

Thinking at "email 2.0" for one of the biggest vendors in this space is actually part of my job description. However, I'm sure that if "SMTP II" were to be written today, it would possibly work a lot like HTTPS (see JMAP vs IMAP for example) and be focused on authenticating and authorizing senders, which, as we were saying, might actually be negative for people that no one wants to listen to.

Regards,
-- 

Vittorio Bertola
Head of Policy & Innovation

Cell:+39 348 7015022Skype:[email-masked]
Email:[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: Tony Rutkowski <[email-masked]>
Date: Wed, 11 Jul 2018 07:00:27 -0400

Hi Niels,

The Special Rapporteur's report is only on Freedom of Expression and
doesn't recognize or attempt to deal with violation of human rights to
be free of acts of a racist and xenophobic nature, or the Additional
Protocol.  It is devoted largely to government regulation.  Nonetheless,
the framework found in para. 11 does encompass multiple protocol related
actions appropriate for providers.  See esp. 11(d).

Is this  group's work constrained to networking protocols?

--tony

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 11 Jul 2018 13:25:39 +0200

Hi Tony,

On 07/11/2018 01:00 PM, Tony Rutkowski wrote:
> Protocol. 

I think the Special Rapporteur explicitly tries to incorporate other
rights, because only jointly they create an 'enabling environment for
freedom of expression'. Therefore he proposes a 'framework for the
moderation of user-generated online content that puts human rights at
the very centre' (so not just FoE).

David Kaye has discussed hate speech and xenophobia explicitly when he
spoke at hrpc and in his statements [0].

> It is devoted largely to government regulation. 

The document explicitly says: 'The present report focuses on the
regulation of user-generated content, principally by States _and social
media companies, but in a way that is applicable to all relevant actors
in the information and technology (ICT) sector._' (emphasis added).

> Nonetheless,

Yes, but this will application layer providers, right?

> Is this  group's work constrained to networking protocols?

I think that depends how one read the charter [1]. I personally have
understood standards and protocols as the ones described in RFCs.

I maybe misunderstood you earlier because in your earlier post on Human
Rights in the IETF/IRTF you mentioned that non-technical issues such as
human rights should not be discussed here, but am more than happy to do
so of course.

One example of how we discussed xenophobia, exclusion and discrimination
was in the context of the presentation by Ramsey Nasser who showed us
how the Internet (including its protocols) explicitly exclude non-latin
scripts. [2].

Best,

Niels

[0]
https://www.ohchr.org/EN/NewsEvents/Pages/DisplayNews.aspx?NewsID=22300&LangID=E
[1] https://datatracker.ietf.org/rg/hrpc/about/
[2] http://animalnewyork.com/2014/artists-notebook-ramsey-nasser/

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jul 2018 08:15:26 -0400

Niels, I think you very nicely captured the reason why solving this at a
protocol level is better than solving it at some other level: it is clear
what is happening.   If we are using something like RPZ, then who knows
what went wrong?   If we are using Google's (quite excellent) spam filter,
we might be excluded without even knowing it.   This is because *there is
no protocol*.

Something like facebook's friend protocol, based in cryptographic
identities, solves the problem of making sure that the people I want to
communicate with can communicate with me.   It doesn't solve the problem of
making it possible for people *I don't know *to communicate with me, but
that's okay.   That's a different problem.   We also need a way to solve
that problem, and we have ways to solve that problem.

In the analog world, if somebody who doesn't know me wants to communicate
with me, they can advertise.  They can assemble in public.   They can
canvass.   And there are ways that they can't do this, or shouldn't.   They
are not allowed to harass me, and there are laws that forbid this, and
processes for dealing with violations of those laws.   And it's difficult
to harass me anonymously in person.  Not impossible, but difficult.   Of
course, we still have catcalling and racist microaggression, so these
solutions are imperfect.   And the digital world is not the real world--the
right solution to these problems may be different.   But the basic point is
that we shouldn't place the burden of solving all problems on a single
protocol.  SMTP fails because it's supposed to solve the problem of how
someone with whom I want to communicate can communicate with me, but also
solves a different problem: how someone with whom I do not wish to
communicate can communicate with me.

The theme I would suggest here is that to the extent that real-world
anonymous communication works, it works because it requires effort, and is
moderated *successfully *by community and place.   If there are ways to
achieve similar effects in the digital space, this is more likely to work
than simply saying "all protocols must allow anonymous communication."   :)

On Wed, Jul 11, 2018 at 3:28 AM, Niels ten Oever <[email-masked]>
wrote:

> RFC8280 -
> how

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 11 Jul 2018 09:18:08 -0400

Hi Niels,

Perhaps hrpc could focus - as several on this list have done - on the
recognition of the rapidly scaling importance today of the human rights
norms concerning propagation of racism and xenophobia, and means of
implementing those rights.  This might include involvement of the many
providers and national authorities (pursuant to the Additional Protocol)
who are faced with the challenge, and the thousands of academic
community researchers engaged in related R&D.  There are significant
numbers of ethnic groups, populations, and nations today being
profoundly adversely affected by what is occurring. 

--tony

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 11 Jul 2018 09:27:09 -0400

On Tue, Jul 10, 2018 at 05:03:49PM -0400, Ted Lemon wrote:
> not the bad implementation).   If someone were inventing SMTP today, it would
> look very different.

This is a bold claim.  One of the use cases of SMTP is for contact
from people I don't know, which is why it is so often used to
bootstrap other forms of interaction.  I have yet to see a proposal I
found plausible that continued to offer low barriers to communication
from unknown others, and wasn't also subject to spam problems.  I
don't think that's surprising: when the cost of sending is low enough
then spamming is a natural consequence, and we see this in lots of
different environments.

More generally (and not with specific reference to what Ted wrote) I'm
also somewhat concerned about the conflation of policy and protocol
that seems to be part of this thread.  Historically, the IETF has
attempted to make policy-neutral protocols.  The entire effort of
linking human rights to protocols is a way of stating, indeed, that
certain policies are actually not neutral, but violate fundamental
values that the network is supposed to embody.  But we ought to be
clear that that is at least a part of what we are doing.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jul 2018 10:12:56 -0400

Andrew, I think that lack of policy is also not neutral.   As for your
point about SMTP, if you need a way to contact people you don't know,
that's perfectly valid.   However, then what you need is "a protocol for
contacting people you don't know," not "a protocol for transferring mail."
 The fact that SMTP does both is a design choice, and one that I think
history has shown us is not ideal.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 11 Jul 2018 10:32:21 -0400

On Wed, Jul 11, 2018 at 10:12:56AM -0400, Ted Lemon wrote:
> Andrew, I think that lack of policy is also not neutral.

Well, ok, but that's at least by my reading a long way from IETF
consensus.  As it is basically built on independent network
interoperation, the Internet is not a single thing and therefore you
literally cannot make a single policy for "the Internet".  This is a
point that is more and more obscured in the way we talk about "the
internet", and maybe what that really means is that people will be
content to have a single utility called "the internet" but governed
and ruled as a single network.  I think that'd be a loss.

>   As for your point
> about SMTP, if you need a way to contact people you don't know, that's
> perfectly valid.   However, then what you need is "a protocol for contacting
> people you don't know," not "a protocol for transferring mail."   The fact that
> SMTP does both is a design choice, and one that I think history has shown us is
> not ideal.

Except that from the POV of the user experience, I need a single
interface.  And since the interface will end up getting spam from the
"people I don't know" category anyway, that protocol might end up
dead.  And we'd lose a bit of functionality.

I'm not really disagreeing with the premise that SMTP design decisions
would probably be different in light of experience.  But I disagree
strongly with the suggestion that the compromises to make are
self-evident, because I think even a little napkin exercise shows that
these are tricky.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jul 2018 10:58:12 -0400

> and ruled as a single network.  I think that'd be a loss.

HRPC is a research group, so IETF consensus is interesting but not strictly
applicable.

I am not proposing that we should have some big authority that sets policy
for the internet.   Remember, the context here is whether protocols have
implications on how users of the protocol can be treated.   I think it's
clear that they can.   So if how the details of a protocol will affect
people is not considered, that's not a neutral thing.   That's what I mean
by "lack of policy is not neutral."

> interface.

That may or may not be true.   It's worth talking about whether it's true,
and what the implications are of it being true if it is.   Simply accepting
that it's true because that's what you're used to is the default; what I'm
suggesting is that this is not the right default.   Remember that people
who didn't grow up with email have a very different relationship to it than
we do.   I have friends who still believe it's okay to call me on the phone
and expect that I'll answer it, even though we didn't make a plan to have a
phone call.   That doesn't mean that this is the correct default assumption
for telephone users.

Think of this: because I must have a phone that rings and that I answer in
order to successfully interface with some bureaucracies, this has really
significant implications on my privacy and on the types of harassment to
which I can be subjected.   Having an explicit protocol for how I can
establish a relationship with those bureaucracies such that they can
contact me as required, but that doesn't mean everyone else in the world
can too, would be a really big deal.

> And since the interface will end up getting spam from the

In social culture we already have ways of dealing with this.  You can come
knock on my door, but that requires effort, so you can't do it unless it's
fairly important to you, and that serves as a filter, and is the reason why
there isn't someone knocking on my door 24/7.   In the city, you might live
in an apartment with a buzzer; it turns out that the value to me of buzzing
your apartment if I don't know you is sufficiently low that this sort of
behavior isn't typically a nuisance for people.   For people for whom it
might be a nuisance, there are buildings with concierges.   A similar
practice could work in an introduction protocol: if I am a target of
harassment, I might simply reject introductions that don't come from some
social interaction with someone I already know.   If I am wealthy, I might
pay someone to vet requests for introduction.   If I am a business, I might
set things up so that it's really easy to get in touch with me, and might
hire staff to deal with the noise that this creates.

This wasn't a thread about how to fix SMTP, but the point I'm making here
is that how you design the protocol really does have a strong impact on
what modes of operation are possible, and this in turn has impact on how
successfully the protocol can be employed to harass someone.

> self-evident, because I think even a little napkin exercise shows that

That they are tricky is why this is a research problem.   We shouldn't just
throw our hands up in despair whenever we encounter a tricky problem.
Tricky problems are the most interesting problems! :)

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 11 Jul 2018 13:19:32 -0400

There are two other rather basic reasons for the "no single thing" approach.

First is that the parties holding the IETF IPR signed an agreement in
Feb 2000 that the term "internet" was "generic" and "not inherently
distinctive."  The agreement ended years of litigation because the
banking system's ATM internet organization held the internet trademark. 
See attached.

Second is that many internets and related connectionless protocols
emerged in the 1970s beginning with Louis Pouzin's CYCLADES internet,
and a significant number of diverse internets exist today.  There are
many internet architectures and protocols, and the IETF's derives from
the "host-to-host protocol" of the DARPA internet.   The DARPA Director
who approved and funded that version recently wrote a lengthy, detailed
history available at
https://www.academia.edu/34728504/WHY_THE_ARPANET_WAS_BUILT.  As he
sometimes states in public comments "I paid for it, so I get to describe
why." 

--tony

---

From: Amelia Andersdotter <[email-masked]>
Date: Thu, 12 Jul 2018 00:02:42 +0200

On 2018-07-10 22:51, Tony Rutkowski wrote:
> Hi Niels,
>
> Clearly the additional protocol is regarded as human rights law.  

It's "international law".

I think a useful way to think about it (for myself), is that human
rights imply obligations on states (or companies) with respect to
individuals/private persons or groups of individuals/private persons
acting in a private/individual capacity.

While "international law" in a more generic sense may also entail
agreements between governments on competencies they should grant
institutional actors (such as public authorities, international bodies)
or legal persons (companies, NGOs, what have you).

I have never come across the use of the word "human rights law" for
international agreements that aim to steer governments in the direction
of providing rights, duties or competencies to public authorities (I may
not even, in general, have come across the word "human rights law", but
it's a separate issue, I guess).

best regards,

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

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

---

From: [email-masked]
Date: Wed, 11 Jul 2018 18:41:36 -0400

Hi,

Submitting a draft is a good way to get the discussion going in earnest.

Just saying.

avri

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 11 Jul 2018 20:58:59 -0400

Hi Amelia,

Perhaps one of the "lost in translation" problems here involves the way
lawyers conceptualize and treat these matters.  In short, human rights
law is principally manifested through international law in diverse
forms.  My law school alma mater - Washington College of Law - has for
many decades been a center for human rights law, and indeed created a
Center for Human Rights and Humanitarian Law.  See
https://www.wcl.american.edu/impact/initiatives-programs/center/ 
Indeed, at the time, the dean was one of the world's prominent human
rights jurists and several of my professors played leading roles in
shaping the that body of law for some decades.  Other prominent law
schools also have Human Rights Law programs.  See
https://law.yale.edu/study-law-yale/areas-study/human-rights-law  And,
when I taught the graduate program course on international
telecommunications law at NY Law School in the 1980s, I included human
rights law material. 

You might want to be aware also that the first major initiative to deal
with human rights and new technologies including internets, was the
Commission chaired by Sean MacBride in 1979 generally named after him. 
Sean at the time had just won the Nobel Peace Prize for his formation of
Amnesty International, the International Commission of Jurists, and in
general instantiating much of what constitutes human rights law in
international instruments and bodies.  Although controversial at the
time, the report which the Commission produced perhaps remains today the
most comprehensive study done on the subject.  See
http://www.un-documents.net/macbride-report.pdf

Because of my engineering-legal roles at the FCC and in inter-agency and
international bodies at the time, I had the good fortune of being
seconded to be Sean's technical advisor not only at the seminal New
Delhi meeting of the Commission  (see attached), but also over the many
months of followup meetings with him in Paris, Geneva, and New York.  We
became friends.  Now about 40 years later, the input provided seems
still largely accurate in envisioning subsequent decades. 
http://unesdoc.unesco.org/images/0004/000491/049100eb.pdf

There is a cautionary note here that is worth telling.  Sean in his
public speeches would hold up audio tapes as an example of an "internet
packet technology" that was at that time being used by activists
attempting to bring about regime change in Iran.  Sean was passionate
about human rights and viewed his role leading the Commission as a kind
of culmination of his long activist life - which also included major
roles in the formation of the Irish Republic and Sinn Féin.  (Sean's
mother was Maud Gonne, and his father was hanged in the Easter Uprising
when he was 14).   However, when the outcome of the Iranian Revolution
wasn't quite the human rights friendly regime he anticipated, he became
somewhat despondent and largely disappeared from public view - passing
away a few years later in his mother's famous Roebuck House in Dublin.

The reason that this note of caution is worth telling, is that after the
1988 Melbourne Treaty enabling international public internets
(notwithstanding the KGB's vocal expression of concern), the DARPA
internet began to be advanced in the 1990s as an instrument of group
activism and regime change.  However, it became quickly apparent that
there were attributes of the platform that could have potentially
catastrophic societal consequences via both state and non-state actors. 
The past several years have significantly amplified the concern and the
trends are not good.

--tony

---

From: [email-masked]
Date: Wed, 11 Jul 2018 22:34:43 -0400

> Thinking at "email 2.0" for one of the biggest vendors in this
 > space is actually part of my job description. However, I'm sure
 > that if "SMTP II" were to be written today, it would possibly work
 > a lot like HTTPS (see JMAP vs IMAP for example) and be focused on
 > authenticating and authorizing senders, which, as we were saying,
 > might actually be negative for people that no one wants to listen
 > to.

FWIW, the ASRG (Anti-Spam Research Group, IRTF) seemed to spend an
inordinate amount of time going around and around some sort of
"SMTP-ng" (SMTP 2.0, SMTP-II, whatever.)

My quick summary is:

1. It would take many years to have any significant penetration tho
I'll admit that was an objection many years ago (ASRG started
ca. 2003...)!

2. Since SMTP itself is extensible, it's really only "COMMAND ARG" and
then whatever that implies, for example "RCPT <address>" or even just
"STARTTLS" (no ARG), it would be a lot more practical to just propose
a new command as has been done many times previously.

That would also ensure indefinite backwards compatiblity -- your
software supports this particular verb or not but can generally
proceed with the transaction without it.

IMHO it's difficult to imagine what a complete redesign of SMTP would
accomplish.

Or at least that would be what I would want to hear about first, why
not just propose a new SMTP command?

Then again, I suppose the reference to JMAP does open a reasonable
line of discussion. For example why should there be separate client
and server protocols? That always implied separate authentication and
authorization infrastructures even if they have been shoehorned
together in various ways.

-- 
        -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: [email-masked]
Date: Wed, 11 Jul 2018 23:11:12 -0400

Not surprisingly a spam discussion veers off into personal experiences
with one's own inbox versus how it looks to those who've actually run
sizeable mail systems.

Spam per se is a problem because spammers send on the order of
billions of spams per day, literally.

If they couldn't you'd rarely see spam and it wouldn't be much of a
systems operational problem either which it is.

There's a reason I can start a post with "A Nigerian prince just
promised me..." and you'd all chuckle. Unfortunately it's become one
of our global common experiences.

Once one grasps that then one begins to think about not so much why
sending an email is free and easy but why sending a billion emails per
day is just about as free and just about as easy once one gets the
mechanisms (oftentimes criminal) in place.

For example if one were limited to 100,000 emails per month free
spammers could not operate, or at least not as we know them. That is
probably just as true for a million emails per month.

It's reminiscent of the Chris Rock joke about whether you know anyone
who has ever used an ATM at 4AM for anything they were PROUD of?

Do you know anyone who sends more than a million emails a month
(perhaps a few huge corporations excepted) which they were, or should
be, PROUD of?

If not a million per month pick a number, it's likely not a billion
per day.

Without beating to death how one might accomplish what that implies I
hope it puts a different perspective on the core of the problem.

-- 
        -Barry Shein

---

From: Amelia Andersdotter <[email-masked]>
Date: Thu, 12 Jul 2018 22:22:12 +0200

Dear Tony,

On 2018-07-12 02:58, Tony Rutkowski wrote:
> forms. 

*snip*

I did not contest that human rights law would be a subheading under
"international law". I contested that specifically the additional
protocol to the Budapest Convention was human rights law rather than
international law.

Thank you for all your informative references.

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 12 Jul 2018 17:18:33 -0400

Dear Amelia,

In the legal community, it seems fair to say that legal instruments
which establish and implement human rights norms are human rights law.

Two other references may be helpful: the legislative history of the
Additional Protocol at
<https://rm.coe.int/CoERMPublicCommonSearchServices/DisplayDCTMContent?documentId=09000016800d37ae>
and the abundant information on the CERD Wikipedia page at
<https://en.wikipedia.org/wiki/International_Convention_on_the_Elimination_of_All_Forms_of_Racial_Discrimination>

It is worth noting that failure to effectively implement the provisions
of these human rights instruments in internet service provisioning has
led to quite massive harm visited upon those individuals and people they
are meant to protect.   There is also a dramatic asymmetry in available
internet resources - including at one extreme, the chief executive of a
major nation using those resources publicly to incite racism and
xenophobia globally for political gain, and the intelligence services of
another major nation using those resources clandestinely to accomplish
its chief executive's objectives.  Those who are adversely affected have
essentially no internet resources whatsoever and are part of
large-scale, escalating humanitarian crises.

Although these human rights and contemporary developments do not appear
to have been the focus of hrpc participants, perhaps that can be
changed.  Minimally, perhaps, the human rights here can be recognized.

--tony

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 13 Jul 2018 21:48:30 +0200

Hi Tony,

> <https://en.wikipedia.org/wiki/International_Convention_on_the_Elimination_of_All_Forms_of_Racial_Discrimination>

Equating the CERD and the Additional Protocol seems a far fetch to me, but maybe this is not the most relevant of discussions to have here...

> changed.  

I really do not understand where you base this observation on if you look at the mailing list archive of this RG.

> Minimally, perhaps, the human rights here can be recognized.

I don't think an RG is there to recognize human rights because we have no authority, but I think we have shown to care about racism, xenofobia, exclusion of minority groups, access to rights, political participation, due process, etc. 

If you have suggestion on how we can do that better, I am sure the people on this list would be happy to work with you on it.

Best,

Niels

-- 

Niels ten Oever

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 13 Jul 2018 19:13:41 -0400

Hi Niels,

My observations were gleaned from multiple searches of keyword terms on
the list and in conjunction with hrpc.  Xenophobia, for example never
appears.  Racism was found once.  Privacy was found 15,000 times. 
Association 2,270 times.  Democracy 164 times - although largely via the
CDT name in postings.  Speech appears 173 times.  Perhaps these searches
end up in skewing the characterisation, but they are probably generally
indicative of where interests exist.  Maybe that's the best that can be
done.

However, the human rights law field is complex, and the topic of the
relationship between communication network technologies and those rights
is one that has existed for many decades.  The MacBride Commission
report is exemplary.   How "protocols" facilitate or exacerbate
contemporary human rights challenges is also complex and go far beyond
just privacy.  Today's events in London and Washington rather underscore
the magnitude of the concerns - where you have a national leader
prominently championing Racism and Xenophobia on one side, and another
leader clandestinely abetting doing so on the other and profoundly
adversely affecting democratic institutions and trust.

Perhaps the group might begin by collectively developing a structured
ontology of human rights articulated in legal instruments, and how
different classes of protocols intersect with those rights to both
facilitate them or deny them.  Just an idea.

Another suggestion is to use tools like Google Scholar to understand the
vast array of related contemporary studies and R&D occurring among
academic communities and institutions in this area.

--tony

---

From: Niels ten Oever <[email-masked]>
Date: Sat, 14 Jul 2018 01:24:19 +0200

Hi Tony,

> facilitate them or deny them.  Just an idea.

Thanks for the suggestion. This is part of what we aimed to do in
RFC8280 - https://tools.ietf.org/html/rfc8280#section-5.2.2

If you have suggestions on how this could be improved, it could perhaps
feed into one of our drafts, or even be the basis for a new document.

https://datatracker.ietf.org/doc/search?name=hrpc&sort=&rfcs=on&activedrafts=on&by=group&group=

Best,

Niels

---

From: Shivan <[email-masked]>
Date: Fri, 13 Jul 2018 23:33:34 -0700

Hi Tony,

The interests and discussions a groups has is a function of the people who
participate. Thank you for bringing up this topic! As mentioned by Avri,
Niels and others, the best way of ensuring that the group considers a topic
is to submit a draft. Happy to help in any way on that.

Side note:  As a consequence of your posting this thread, next time someone
does a search of keyword terms on hrpc, 'xenophobia' will appear :)

On Fri, Jul 13, 2018 at 4:24 PM Niels ten Oever <[email-masked]>
wrote:

> >>> <
> https://rm.coe.int/CoERMPublicCommonSearchServices/DisplayDCTMContent?documentId=09000016800d37ae
> >
> >>> <
> https://en.wikipedia.org/wiki/International_Convention_on_the_Elimination_of_All_Forms_of_Racial_Discrimination
> >
> >>>
> >> Equating the CERD and the Additional Protocol seems a far fetch to me,
> but maybe this is not the most relevant of discussions to have here...
> >>
> >> I really do not understand where you base this observation on if you
> look at the mailing list archive of this RG.
> >>
> >> I don't think an RG is there to recognize human rights because we have
> no authority, but I think we have shown to care about racism, xenofobia,
> exclusion of minority groups, access to rights, political participation,
> due process, etc.
> >>
> >> If you have suggestion on how we can do that better, I am sure the
> people on this list would be happy to work with you on it.
> >>
> >> Best,
> >>
> >> Niels
> >>
> >>> --tony
> >>>

---

From: Eliot Lear <[email-masked]>
Date: Sat, 14 Jul 2018 11:09:19 +0200

Mark,

> However, it also prevents changes to many characteristics that might harm *or* help human rights. For example, we can't address the fundamental problems with SMTP (because it would be backwards-inc…

I don't see that as the fundamental problem with SMTP, and even with BGP
it's not so much the bits as the model.  In fact, one could easily
bypass SMTP altogether if one could come up with an appropriate
alternative, as we have sufficient signaling capability in the DNS to
provide for this.  As Barry has alluded, there are more fundamental
issues.  One of the issues is the economic asymmetry of email in its
design.  In one of his earlier designs, and Barry can correct me if my
memory is faulty, he proposed a micro-payments approach.  Maybe even a
micro-credits approach.

In the case of spam, there are a handful of well known methods for
injection:

  * botnets – depending on the day, a single botnet can account for as
    much as 60% of spam.  We know this from experience of watching
    volume when we shut them down.   It's rare these days that the email
    comes directly from a client to a receiving network, thanks to tools
    like DKIM and SPF.  Instead, end systems are speaking the message
    submission protocol, and generating individually relatively few
    messages, but as a network quite a few.
  * bgp prefix hijacking.  Here, an attacker has compromised an SP
    router and starts advertising various prefixes in order to receive
    traffic for those prefixes.  From a protocol perspective, deploying
    security mechanisms in BGP has proven challenging, as ANRP winner
    (and her students) Professor Sharon Goldberg @ BU has repeatedly
    shown.[1]. Here again, it is not the protocol bits per se that are
    the issue, but the trust model itself that can cause perverse
    situations in the absence of a Red Flag Day.
  * Unused VMs, such as WordPress.  Again, I don't measures on this one
    today, although I'm sure folk at MAAWG do.  Nothing like free
    compute power!

A number of mitigations of these problems are available.

  * In the case of BGP, Richard Clayton @ Cambridge/Yahoo! studied and
    identified many of the prefixes and then in one fell swoop took out
    the lot of them.  I'm sure some are back, and smarter.
  * Across these threats, two key measures play an important role: honey
    pots and content scanning/modification.  Honey pots provide means to
    grey/black list whole networks that have been infested.  They are
    more or less successful depending on granularity.  If you have one
    bot sitting in a network of 100,000 devices that produces relatively
    little spam, you're not going to blacklist the network, though you
    may use ARF reports or some other means to inform the network owner.
  * Content screening and modification has become an important aspect
    for consumers in particular.  Here, either the content is blocked
    based on inspection, or it is retroactively removed once it is
    determined to be spam or unsafe.  Large MSPs are in the position to
    do the latter, and Savage et al showed that it very useful to do so
    in order to disrupt the PharmaSpam economy.[2]. The key point there
    is that the bad guys made their money out of a new domain name in
    something less than 72 hours from initial use.  Note the need for
    access to the content to cut into those times.
  * DKIM in particular can limit – but not eliminate prefix hijacking. 
    After all, if you have control of prefix that controls the DNS
    server, you could add a DKIM record.

One clear take-away is that the protocol bits are rarely if ever the
problem.  The underlying operating model is much more the issue.  It may
be that there are considerably more radical approaches that need to be
considered, that somehow impose curation or accountability.  But any
such model would have substantial privacy issues.  TANSTAAFL.

Another clear takeaway is that consent isn't necessarily the issue. 
Were it so, we could lend considerably more credence to those in our
address books, and the vast majority of the problem would have
evaporated.  It hasn't.

When I served on the IAB I really did want us to take another crack at
this problem, not because it is easy to solve, but quite the opposite.

Eliot

[1] https://irtf.org/anrp
[2] http://cseweb.ucsd.edu/~voelker/pubs/namevalue-weis14.pdf

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Jul 2018 10:00:10 -0400

Eliot, not to belabor the point, but everything you said in your message
about why the issue is how the protocol is used and not the protocol itself
is actually pointing to the fact that it's the protocol itself and not how
it's used.   BGP spoofing is a problem because the protocol wasn't designed
to reject unwanted mail.   You need micropayments because they are a way to
reject unwanted mail.   Et cetera.   Why is the protocol willing to accept
unwanted mail?   Because that's a core element of the design.   If SMTP had
been designed so that only wanted mail would be delivered, then SMTP
wouldn't be able to deliver certain kinds of wanted mail, and we'd have to
have a protocol for making it possible to deliver that kind of mail.   But
we would not have a spam problem.  At all.   And harassment would be a
*lot* harder,
if practical at all.

On Sat, Jul 14, 2018 at 5:09 AM, Eliot Lear <[email-masked]> wrote:

> However, it also prevents changes to many characteristics that might harm **or** help human rights. For example, we can't address the fundamental problems with SMTP (because it would be backwards-incompatible), but we also can't introduce extensions to share what people do over HTTPS with their networks (because that breaks the fundamental assumptions of HTTPS and TLS).
>
>
> it's not so much the bits as the model.  In fact, one could easily bypass
> SMTP altogether if one could come up with an appropriate alternative, as we
> have sufficient signaling capability in the DNS to provide for this.  As
> Barry has alluded, there are more fundamental issues.  One of the issues is
> the economic asymmetry of email in its design.  In one of his earlier
> designs, and Barry can correct me if my memory is faulty, he proposed a
> micro-payments approach.  Maybe even a micro-credits approach.
>
>    - botnets – depending on the day, a single botnet can account for as
>    much as 60% of spam.  We know this from experience of watching volume when
>    we shut them down.   It's rare these days that the email comes directly
>    from a client to a receiving network, thanks to tools like DKIM and SPF.
>    Instead, end systems are speaking the message submission protocol, and
>    generating individually relatively few messages, but as a network quite a
>    few.
>    - bgp prefix hijacking.  Here, an attacker has compromised an SP
>    router and starts advertising various prefixes in order to receive traffic
>    for those prefixes.  From a protocol perspective, deploying security
>    mechanisms in BGP has proven challenging, as ANRP winner (and her students)
>    Professor Sharon Goldberg @ BU has repeatedly shown.[1]. Here again, it is
>    not the protocol bits per se that are the issue, but the trust model itself
>    that can cause perverse situations in the absence of a Red Flag Day.
>    - Unused VMs, such as WordPress.  Again, I don't measures on this one
>    today, although I'm sure folk at MAAWG do.  Nothing like free compute power!
>
>    - In the case of BGP, Richard Clayton @ Cambridge/Yahoo! studied and
>    identified many of the prefixes and then in one fell swoop took out the lot
>    of them.  I'm sure some are back, and smarter.
>    - Across these threats, two key measures play an important role: honey
>    grey/black list whole networks that have been infested.  They are more or
>    less successful depending on granularity.  If you have one bot sitting in a
>    network of 100,000 devices that produces relatively little spam, you're not
>    going to blacklist the network, though you may use ARF reports or some
>    other means to inform the network owner.
>    - Content screening and modification has become an important aspect
>    for consumers in particular.  Here, either the content is blocked based on
>    inspection, or it is retroactively removed once it is determined to be spam
>    or unsafe.  Large MSPs are in the position to do the latter, and Savage et
>    al showed that it very useful to do so in order to disrupt the PharmaSpam
>    economy.[2]. The key point there is that the bad guys made their money out
>    of a new domain name in something less than 72 hours from initial use.
>    Note the need for access to the content to cut into those times.
>    - DKIM in particular can limit – but not eliminate prefix hijacking.
>    After all, if you have control of prefix that controls the DNS server, you
>    could add a DKIM record.
>
> problem.  The underlying operating model is much more the issue.  It may be
> that there are considerably more radical approaches that need to be
> considered, that somehow impose curation or accountability.  But any such
> model would have substantial privacy issues.  TANSTAAFL.
>
> Another clear takeaway is that consent isn't necessarily the issue.  Were
> it so, we could lend considerably more credence to those in our address
> books, and the vast majority of the problem would have evaporated.  It
> hasn't.
>

---

From: Eliot Lear <[email-masked]>
Date: Sat, 14 Jul 2018 16:11:19 +0200

Ted,

On 14.07.18 16:00, Ted Lemon wrote:
> Eliot, not to belabor the point, but everything you said in your
> message about why the issue is how the protocol is used and not the
> protocol itself is actually pointing to the fact that it's the
> protocol itself and not how it's used.   BGP spoofing is a problem
> because the protocol wasn't designed to reject unwanted mail.

The point is that to avoid spoofing you need an authentication
infrastructure in place.  What are you authenticating?  The source of
the announcement for authority of that announcement and the means by
which it is announced.  In other words, you would have to recreate the
RPKI, ROAs, and SIDR.  Put another way: it's easy to say, “let's just do
it all over again”, but if you did, you might very much end up right
back to where you started.

There's one exception to that with SIDR, which is that some of the
transition states themselves cause problems.

>  You need micropayments because they are a way to reject unwanted mail.

As Ron Natalie might say, “there are response codes for people like
you!”  Seriously, we have plenty of response codes.  We just need a way
to make payments when the bill comes due.  No need to replace SMTP.

>  Et cetera.   Why is the protocol willing to accept unwanted mail? 
>  Because that's a core element of the design.   If SMTP had been
> designed so that only wanted mail would be delivered, then SMTP
> wouldn't be able to deliver certain kinds of wanted mail, and we'd
> have to have a protocol for making it possible to deliver that kind of
> mail.   But we would not have a spam problem.  At all.   And
> harassment would be a /lot/ harder, if practical at all.
If it were that simple, it would have been done.  And many have tried. 
From scratch.  That includes FB, Twitter, and the like.  Want to talk
about unwanted traffic?  I believe there's a scandal going on right now
that has nothing to do with email.  And let's not even start with reddit.

Eliot

>
> On Sat, Jul 14, 2018 at 5:09 AM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Mark,
>
>     I don't see that as the fundamental problem with SMTP, and even
>     with BGP it's not so much the bits as the model.  In fact, one
>     could easily bypass SMTP altogether if one could come up with an
>     appropriate alternative, as we have sufficient signaling
>     capability in the DNS to provide for this.  As Barry has alluded,
>     there are more fundamental issues.  One of the issues is the
>     economic asymmetry of email in its design.  In one of his earlier
>     designs, and Barry can correct me if my memory is faulty, he
>     proposed a micro-payments approach.  Maybe even a micro-credits
>     approach.
>
>       * botnets – depending on the day, a single botnet can account
>         for as much as 60% of spam.  We know this from experience of
>         watching volume when we shut them down.   It's rare these days
>         that the email comes directly from a client to a receiving
>         network, thanks to tools like DKIM and SPF.  Instead, end
>         systems are speaking the message submission protocol, and
>         generating individually relatively few messages, but as a
>         network quite a few.
>         router and starts advertising various prefixes in order to
>         receive traffic for those prefixes.  From a protocol
>         perspective, deploying security mechanisms in BGP has proven
>         challenging, as ANRP winner (and her students) Professor
>         Sharon Goldberg @ BU has repeatedly shown.[1]. Here again, it
>         is not the protocol bits per se that are the issue, but the
>         trust model itself that can cause perverse situations in the
>         absence of a Red Flag Day.
>       * Unused VMs, such as WordPress.  Again, I don't measures on
>         this one today, although I'm sure folk at MAAWG do.  Nothing
>         like free compute power!
>
>       * In the case of BGP, Richard Clayton @ Cambridge/Yahoo! studied
>         and identified many of the prefixes and then in one fell swoop
>         took out the lot of them.  I'm sure some are back, and smarter.
>       * Across these threats, two key measures play an important role:
>         honey pots and content scanning/modification.  Honey pots
>         provide means to grey/black list whole networks that have been
>         infested.  They are more or less successful depending on
>         granularity.  If you have one bot sitting in a network of
>         100,000 devices that produces relatively little spam, you're
>         not going to blacklist the network, though you may use ARF
>         reports or some other means to inform the network owner.
>       * Content screening and modification has become an important
>         aspect for consumers in particular.  Here, either the content
>         is blocked based on inspection, or it is retroactively removed
>         once it is determined to be spam or unsafe.  Large MSPs are in
>         the position to do the latter, and Savage et al showed that it
>         very useful to do so in order to disrupt the PharmaSpam
>         economy.[2]. The key point there is that the bad guys made
>         their money out of a new domain name in something less than 72
>         hours from initial use.  Note the need for access to the
>         content to cut into those times.
>       * DKIM in particular can limit – but not eliminate prefix
>         hijacking.  After all, if you have control of prefix that
>         controls the DNS server, you could add a DKIM record.
>
>     One clear take-away is that the protocol bits are rarely if ever
>     the problem.  The underlying operating model is much more the
>     issue.  It may be that there are considerably more radical
>     approaches that need to be considered, that somehow impose
>     curation or accountability.  But any such model would have
>     substantial privacy issues.  TANSTAAFL.
>
>     Another clear takeaway is that consent isn't necessarily the
>     issue.  Were it so, we could lend considerably more credence to
>     those in our address books, and the vast majority of the problem
>     would have evaporated.  It hasn't.
>
>     When I served on the IAB I really did want us to take another
>     crack at this problem, not because it is easy to solve, but quite
>     the opposite.
>
>     Eliot
>
>     <http://cseweb.ucsd.edu/%7Evoelker/pubs/namevalue-weis14.pdf>
>
>
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Jul 2018 10:20:18 -0400

No, you don't have to do any of that.   If you are my friend, I have your
key, and I register that key with the "SMTP" server.   If you want to send
me email, you send email to my "SMTP" server, and the first thing you have
to do, before you even start sending the message, is that you prove your
identity.   And then if you are on my whitelist, then we start the
transfer.   Otherwise, you don't get to send mail.   There's no need for
RPKI here, any more than you need RPKI to use facebook.

On Sat, Jul 14, 2018 at 10:11 AM, Eliot Lear <[email-masked]> wrote:

> to reject unwanted mail.
> infrastructure in place.  What are you authenticating?  The source of the
> announcement for authority of that announcement and the means by which it
> is announced.  In other words, you would have to recreate the RPKI, ROAs,
> and SIDR.  Put another way: it's easy to say, “let's just do it all over
> again”, but if you did, you might very much end up right back to where you
> started.
>
> As Ron Natalie might say, “there are response codes for people like you!”
> Seriously, we have plenty of response codes.  We just need a way to make
> payments when the bill comes due.  No need to replace SMTP.
>
>
>  Because that's a core element of the design.   If SMTP had been designed
> so that only wanted mail would be delivered, then SMTP wouldn't be able to
> deliver certain kinds of wanted mail, and we'd have to have a protocol for
> making it possible to deliver that kind of mail.   But we would not have a
> spam problem.  At all.   And harassment would be a *lot* harder, if
> practical at all.
>
> From scratch.  That includes FB, Twitter, and the like.  Want to talk about
> unwanted traffic?  I believe there's a scandal going on right now that has
> nothing to do with email.  And let's not even start with reddit.
>
> Eliot
>
>
>>    - Across these threats, two key measures play an important role:
>>    honey pots and content scanning/modification.  Honey pots provide means to

---

From: Eliot Lear <[email-masked]>
Date: Sat, 14 Jul 2018 16:25:33 +0200

On 14.07.18 16:20, Ted Lemon wrote:
> No, you don't have to do any of that.   If you are my friend, I have
> your key, and I register that key with the "SMTP" server.
Well I am your friend.  Unfortunately, I've been botted and so someone
else has your key.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Jul 2018 10:30:41 -0400

Er, no, they have your key.   There are lots of attacks on what I'm
describing, but they aren't spam attacks.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 14 Jul 2018 16:46:01 +0200

Ok, they have my key.  Now you're getting spam from "me", only not
really me.  By the way, nothing you're describing requires a fundamental
rework of SMTP.  All you're talking about is a new authentication method
within SMTP and a means to register keys, the latter of which sounds
like a pretty straightforward IMAP extension.

And then we have an introduction problem.  That is, Ted has introduced
Eliot to Mark, and now Mark needs Eliot's key, and Eliot needs Mark's,
which would both need to be transported securely.  Perhaps that's a new
protocol?  Except we have some great protocols for transporting keying
material already, from PGP to CMS (let's assume we got through the key
management problem through some sort of PKI).  Not really an SMTP problem.

Apart from the fact that I'm not really me, and Mark's not really Mark,
you're good to go.  And of course, when we start to talk about key
rollover, there's a bit of work to do to inform you that Mark or I have
both rolled over our keys.  We know how well that has worked in the past
with PGP.  PKIs have their own problems, as well.  And now imagine us
having done it when we're not really us!

And then we have, in the process of all of this, lost the utility of
being contacted by people I don't know but I want to know, as Andrew
pointed out.  Again, TANSTAAFL.

Eliot

On 14.07.18 16:30, Ted Lemon wrote:
> On Sat, Jul 14, 2018 at 10:25 AM, Eliot Lear <[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Jul 2018 10:55:49 -0400

I didn't say that it was a trivial problem.   But you appear essentially to
be saying it's not perfect—that there are ways to break through it.   This
is true, but the alternative is that you just get spammed constantly.   So
that's actually a pretty low bar to get over.   If we don't seriously try
to solve these problems, we'll just be stuck in the cesspool.

As for using SMTP as the transport, the point of this discussion is not "we
should replace SMTP."   It's that the hidden assumptions in protocols
designs have human rights implications, and it's *not* the case that
protocol design is neutral to human rights.   Leaving human rights to the
policy layer leaves you with the spam problem, and problems like it.

Yes, being able to contact strangers is useful.   It's also not a hard
problem to solve.  It's not really one problem—there are lots of reasons
why you might want to be able to contact a stranger, and a single solution
to all of those would almost certainly also turn into a problem.   E.g.,
with micropayments, if you set the price to prevent spam, then it does
nothing about harassment, because harassment can be done with a much
smaller number of messages.   We have ways of solving all of these problems
in the real world.  And those solutions are varied—there isn't one
solution.   So why would we expect it to be any different online?

There's a tendency in our world to come up with generalized solutions to
problems; what I'm suggesting here is that that is not a universal
benison.   There are benefits to generality, and there are costs, and we
tend never to consider the costs, but only the benefits.

On Sat, Jul 14, 2018 at 10:46 AM, Eliot Lear <[email-masked]> wrote:

> Ok, they have my key.  Now you're getting spam from "me", only not really
> me.  By the way, nothing you're describing requires a fundamental rework of
> SMTP.  All you're talking about is a new authentication method within SMTP
> and a means to register keys, the latter of which sounds like a pretty
> straightforward IMAP extension.
>
> And then we have, in the process of all of this, lost the utility of being
> contacted by people I don't know but I want to know, as Andrew pointed
> out.  Again, TANSTAAFL.
>
> Eliot
>

---

From: Eliot Lear <[email-masked]>
Date: Sat, 14 Jul 2018 17:15:02 +0200

Ted,

On 14.07.18 16:55, Ted Lemon wrote:
> I didn't say that it was a trivial problem.   But you appear
> essentially to be saying it's not perfect—that there are ways to break
> through it.   This is true, but the alternative is that you just get
> spammed constantly.   So that's actually a pretty low bar to get
> over.   If we don't seriously try to solve these problems, we'll just
> be stuck in the cesspool.
And I'm not disagreeing.  Quite the contrary.  Here we think in terms of
protocols.  When was the last time your email interface got a serious
face lift that made a difference in your life?  We fixate on one small
aspect of the problem and don't think about the rest.  I went to the
fundamentals because they are what need to be addressed.  Things like
identity and authorization, not to mention usability, are hard problems
no matter how you slice them.  And those fundamentals, even absent any
protocol elements, are where the human rights considerations really come
into play.  If we could provide strong identity that could be attested
to end-to-end, one can easily imagine the linkability issues that are
introduced.  Protocol bits are REALLY the tail, not the dog.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Jul 2018 11:19:20 -0400

Again, you are pushing an extreme.   Protocol bits are neither the tail nor
the dog.   Policy is neither the tail nor the dog.   Both are part of
system.   But the protocol bits determine what is _possible_.   A protocol
whose bits determine that something undesirable is possible is not a good
design.   That's all I'm saying.

---

From: Mallory Knodel <[email-masked]>
Date: Sat, 14 Jul 2018 15:37:07 -0400

> dead.  And we'd lose a bit of functionality.

This user expectation has by now absolutely changed in every conceivable
way. I have no fewer than a dozen chat applications on my phone. I have
four active email addresses. (Ok, admittedly that actually verges on
being a problem for me-- it's the other extreme.)

Having a special email account that requires senders to authenticate
(perhaps using the same email client interface as one's other
old-fashioned emails) could be a Very Useful Thing for academics,
businesses, activists, journalists, etc, which is why services and
non-email communications do implement such a thing. But not at the
protocol level.

-Mallory

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 14 Jul 2018 15:58:33 -0400

On Wed, Jul 11, 2018 at 10:58:12AM -0400, Ted Lemon wrote:
> the internet.   Remember, the context here is whether protocols have
> implications on how users of the protocol can be treated.   I think it's clear
> that they can.   So if how the details of a protocol will affect people is not
> considered, that's not a neutral thing.   That's what I mean by "lack of policy
> is not neutral."

This is quite confusing to me.  You might be saying one of several
things.

1.  You might be asserting the same thing that Niels and others keep
saying, "Protocols are politics by other means."  This is of course
sometimes true, but it is not always true and I don't think the
universal propositional form is even close to having a sound argument
in its favour.

2.  You might be asserting that a protocol without a presumptive
policy is itself a political stance.  I suppose it is a neutralist or
relativist position from one point of view.  But it is also the point
of view I've previously suggested is the network ethic: that more
connections are better than fewer, and that an indifferent policy
stance aids an increasing connections and is therefore itself
preferable.

3.  You might be asserting that, where different policies cause
different effects for users of a given protocol, the consequences for
the user must be taken into account in the protocol design and the
protocol ought to constrain policy choices to prefer certain user
outcomes.  (I think this is (1) in another guise.)

4.  You might be asserting that, where different policies cause
different effects for users of a given protocol, it is inadequate to
examine the protocol for its HR effects; only the combination of a
given protocol and a particular policy can be considered.  If that's
the claim, then this RG is misnamed :)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Jul 2018 16:04:11 -0400

I didn't mean any of those things.   I meant what I said.   But apparently
I didn't say it clearly, so let me see if I can try again.

It can be claimed that a protocol that is very general, which in principle
can support many policies, is neutral.   I am saying that this is not
necessarily true, because a very general protocol may in fact support
policies that nobody intends for it to support, which are not neutral.  Or
it may be that the protocol is intended to support behaviors the
implications of which are less benign than the protocol implementors
intended, such that although their intentions were neutral, the effect was
not.

The reason I use SMTP as an example for this is that it's such a red hot
smoking ruin of an example of the problem.   None of the authors of SMTP
intended spam or online harassment.

On Sat, Jul 14, 2018 at 3:58 PM, Andrew Sullivan <[email-masked]>
wrote:

> clear

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 14 Jul 2018 17:00:27 -0400

https://humanrights.uconn.edu/human-rights-organizations/

Seems appropriate to register hrpc.  Their compilation of human rights
documents and instruments is also useful.

Considering the meeting in Canada, it is worth noting the listing -
Human Rights Internet - organization which is Canada based.  See
https://hri.ca/  It might be possible to have HRI give a presentation.

--tony

---

From: Eliot Lear <[email-masked]>
Date: Sat, 14 Jul 2018 23:02:54 +0200

Ted,

On 14.07.18 17:19, Ted Lemon wrote:

> Again, you are pushing an extreme.   Protocol bits are neither the
> tail nor the dog.   Policy is neither the tail nor the dog.   Both are
> part of  system.   But the protocol bits determine what is
> _possible_.   A protocol whose bits determine that something
> undesirable is possible is not a good design.   That's all I'm saying.

I think what you are suggesting is occasionally possible, but on the
whole, runs the risk of being boiled down to an Evil Bit<tm>.  That is,
I can certainly think of optimizations that, for instance, reduce or
protect data elements in order to provide a service, but then if the
point of a protocol is to provide, for instance, anonymity and it is
used to commit crimes, what could be said about its design?  Is it
policy-neutral?  Perhaps not.  Perhaps it favors anarchy, or perhaps it
favors improved confidence in the infrastructure, thus propelling the
network further as a good unto itself, as Andrew has out forth.  I find
that distinction incredibly hard to draw.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Jul 2018 18:14:14 -0400

The point is, if you want a protocol that allows for anonymity, which
provides for the very important human right of being able to express
oneself anonymously, it must be the case that I, as a listener, can say "I
do not want anonymous communication."   In the case of SMTP, this is not
possible, because there is only one kind of communication: anonymous
communication.   If I want any communication at all, I _must_ be receptive
to anonymous communication.   Of course, we pretend that it is not
anonymous, but in practice it is—there is no way with SMTP to accept only
messages from senders who are on my whitelist and can prove that they are
who they claim to be.   And of course I can envision an SMTP extension that
would do this, but because SMTP is so widely deployed, and because it
"works" right now without this feature, in practice there is no way for me
to do it.   And this is why, as Mallory pointed out, people are using all
kinds of closed, non-interoperating services instead of SMTP.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 15 Jul 2018 08:51:59 +0200

On 15.07.18 00:14, Ted Lemon wrote:
> oneself anonymously, it must be the case that I, as a listener, can
> say "I do not want anonymous communication."   In the case of SMTP,
> this is not possible, because there is only one kind of communication:
> anonymous communication.   If I want any communication at all, I
> _must_ be receptive to anonymous communication.   Of course, we
> pretend that it is not anonymous, but in practice it is—there is no
> way with SMTP to accept only messages from senders who are on my
> whitelist and can prove that they are who they claim to be.

Of course there is.  You could choose to receive mail from those sites
that attest their user's identities.  Nothing in the protocol stops you
from doing that.  Want to limit your access to the big boys?  Go on. 
Your complaint is not with the protocol, but how it is used.

>    And of course I can envision an SMTP extension that would do this,
> but because SMTP is so widely deployed, and because it "works" right
> now without this feature, in practice there is no way for me to do it.  

It has certainly been tried, and quite successfully in some
environments.  If you want Facebook to manage all of your personal
communications, you can rely on its notion of identity.  And even with
FB, the issue is not the protocol but governance over identity.  And
that is my point.

It is true that they can introduce features faster because they are not
operating in a heterogeneous environment, but rather in something closer
a two-sided market.  Blame/credit apps for the lack of need of a
standard, not the standards themselves.

Eliot

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 15 Jul 2018 06:47:51 -0400

Hi Eliot,

There are two sides to almost all the protocol uses.  They facilitate
some rights, and harm others.

If anyone is interested in any studies as to what the current internet
human rights ecosystem looks like in the area of hate related rights,
see
http://www.internationalhatestudies.com/topic/hate-crime-and-technology/ 
<http://www.internationalhatestudies.com/topic/hate-crime-and-technology/>

The metrics in particular are profoundly troubling.

--tony

On 15-Jul-18 2:51 AM, Eliot Lear wrote:
>> this is not possible, because there is only one kind of
>> communication: anonymous communication.   If I want any communication
>> at all, I _must_ be receptive to anonymous communication.   Of
>> course, we pretend that it is not anonymous, but in practice it
>> is—there is no way with SMTP to accept only messages from senders who
>> are on my whitelist and can prove that they are who they claim to be.
>
> that attest their user's identities.  Nothing in the protocol stops
> you from doing that.  Want to limit your access to the big boys?  Go
> on.  Your complaint is not with the protocol, but how it is used.
>
> It is true that they can introduce features faster because they are
> not operating in a heterogeneous environment, but rather in something
> closer a two-sided market.  Blame/credit apps for the lack of need of
> a standard, not the standards themselves.
>
> Eliot
>
>
>

---

From: [email-masked]
Date: Sun, 15 Jul 2018 14:14:12 -0400

On July 14, 2018 at 11:09 lear=[email-masked] (Eliot Lear) wrote:
 > I don't see that as the fundamental problem with SMTP, and even with BGP it's
 > not so much the bits as the model.  In fact, one could easily bypass SMTP
 > altogether if one could come up with an appropriate alternative, as we have
 > sufficient signaling capability in the DNS to provide for this.  As Barry has
 > alluded, there are more fundamental issues.  One of the issues is the economic
 > asymmetry of email in its design.  In one of his earlier designs, and Barry can
 > correct me if my memory is faulty, he proposed a micro-payments approach. 
 > Maybe even a micro-credits approach.

It could be described as an e-postage approach.

Cryptographic postage (meaning some longish hex string) could be
issued perhaps analogous in administrative structure to how SSL
certificates are issued but preferably more automated to minimize
costs.

Anyone (TBD) could get free postage for 1 million emails per month or
pick a number.

Beyond that some cost invokes.

Any site or individual could elect whether to honor the presence or
reject the absence of valid e-postage.

The usual objection is the double-spend problem but:

1. It could be a good fit for blockchain or analogous technology which
could provide a mechanism to issue and validate e-postage.

2. A bad plan, i.e., one with some hypothetical potential for abuse,
is better than no plan at all, given the huge scope of the actual
problem.

What's the downside? Some spam etc slips through until a hole is
plugged. We have other additional (anti-spam) methods to deal with
that until help arrives.

The other potential objection which is more relevant to this group is
that an e-postage system could work against anonymity since to be
issued e-postage, again analgous to SSL certificates, there would need
to be some method to identify the applicant so a bad actor couldn't
just acquire multiple allocations.

But one could imagine third-party arrangements. For example acquiring
e-postage via one's ISP or similar, even as a service which preserves
anonymity.

For use the e-postage only needs to identify a sending address, not an
individual.

Validation could be reduced to presenting (sending address, e-postage
string) and receiving back yes or no.

And as I said anyone with administrative authority over their own
email could elect to receive email without valid e-postage, or even
only from certain addresses (whitelisting.)

Obviously the devil is in the details and few have even read this far.

I don't offer the above as a complete specification.

-- 
        -Barry Shein

---

From: [email-masked]
Date: Sun, 15 Jul 2018 15:04:00 -0400

> intended spam or online harassment.

Perhaps not the earliest authors.

But when we put a high-speed microwave link between Boston University
and Harvard ca. 1987 thus completing a three-way high-speed path with
MIT we formed an administrative mailing list.

One of the first issues discussed was: If a student et al at one of
the other institutions misbehaves on our network what process is
available?

(Note: the assumption was that this mind-bogglingly fast 10mbit WAN
opened possibilities for misuse not conceived of with the 56kb
ARPAnet.)

Not much later, 1989, when I began offering the general public access
to the internet I was called into a videoconference at BBN with Postel
and some DARPA representatives (probably 1990.)

They were curious what we would do if some member of this general
public misbehaved? Was there any process available?

I admitted I had no great answer and I think it's safe to say it all
went downhill from there.

It's always or almost always, in my experience, been an issue in one
way or another.

-- 
        -Barry Shein

---

From: Amelia Andersdotter <[email-masked]>
Date: Sun, 15 Jul 2018 21:16:27 +0200

On 2018-07-14 22:04, Ted Lemon wrote:
> I didn't mean any of those things.   I meant what I said.   But
> apparently I didn't say it clearly, so let me see if I can try again.
>
> It can be claimed that a protocol that is very general, which in
> principle can support many policies, is neutral.   I am saying that
> this is not necessarily true, because a very general protocol may in
> fact support policies that nobody intends for it to support, which are
> not neutral.  Or it may be that the protocol is intended to support
> behaviors the implications of which are less benign than the protocol
> implementors intended, such that although their intentions were
> neutral, the effect was not.
>
*snip*
>
> On Sat, Jul 14, 2018 at 3:58 PM, Andrew Sullivan
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>

I think these two texts are fairly well matched. Not equivalent, but
along the same lines.

But say a protocol is flexible and allows for many different policies,
neither of which are neutral in a human rights sense (or some other
sense, let's say consumer rights sense). Is it then the meaning that the
flexibility of the protocol itself absolves the protocol's developers of
the consequences of its deployment from moral accountability (I
explicitly avoid legal accountability here, of course)?

In the IEEE 802.11 we've been working a lot on trying to make clear for
users of the standards we develop what the consequences are of doing one
thing or the other thing: the point is not to optimize away from
features, but to clarify to consumers of the standard what risks arise
from having default certain features or others. In practical terms, this
means a bit of extra documentation and effort to map out effects, of
course. It requires considerations of pessimist use cases in addition to
optimist use cases. I've also read some very to-the-point remarks in
this regard in response to Gurshabad's HR review of SUIT drafts earlier
this week.

best regards,

ARTICLE19
www.article19.org

---

From: [email-masked]
Date: Sun, 15 Jul 2018 15:19:01 -0400

I've proposed that a nearly trivial way to achieve this is to just
agree on a safeword between two email correspondents.

So one could manually, not difficult, or automatically via software
agree to add the mail header:

   X-Safeword: headcheese

arrived at between parties.

It's just another tuple in one's contacts database, and there'd be a
very high confidence that for example if you sent me an email with
that header it must be you. Again, I could have it checked
automatically against my contacts database and visually flagged as
good or bad or missing.

If one is willing to manage that manually, pretty trivial, it's
available to any pair of email correspondents without any need for
anyone else on the planet to help or approve.

Yes one can go into a knee-jerk security dance (shall we use RPKI?
what if I get botted?) but...honestly...think it through. It'd
probably work for 99.99% of use cases 99.99% of the time and make it
nearly impossible to impersonate a correspondant.

On July 14, 2018 at 18:14 [email-masked] (Ted Lemon) wrote:
 > The point is, if you want a protocol that allows for anonymity, which provides
 > for the very important human right of being able to express oneself
 > anonymously, it must be the case that I, as a listener, can say "I do not want
 > anonymous communication."   In the case of SMTP, this is not possible, because
 > there is only one kind of communication: anonymous communication.   If I want
 > any communication at all, I _must_ be receptive to anonymous communication. 
 >  Of course, we pretend that it is not anonymous, but in practice it is—there is
 > no way with SMTP to accept only messages from senders who are on my whitelist
 > and can prove that they are who they claim to be.   And of course I can
 > envision an SMTP extension that would do this, but because SMTP is so widely
 > deployed, and because it "works" right now without this feature, in practice
 > there is no way for me to do it.   And this is why, as Mallory pointed out,
 > people are using all kinds of closed, non-interoperating services instead of
 > SMTP.
 > 

-- 
        -Barry Shein

---

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Jul 2018 16:15:56 -0400

Barry, with all due respect, one of the things that any solution has to
take into account is how it will be used.   In this modern day, we are not
concerned with how knowledgable protocol weenies like you and I can avoid
getting spammed if we are willing to only communicate with other
knowledgable protocol weenies.   We are concerned with how you can I can
communicate with people who are not knowledgable, and how people who are
not knowledgable can communicate with each other.

Any solution that requires a Barry Shein to operate is it not going to
survive the laugh test.

The problem with any of the solutions that we've talked about is that they
require me to stop using gmail as my mail client, and more importantly they
require that everybody with whom I am going to communicate to also stop
doing that.   That is literally the *only way* that SMTP can ever be
rehabilitated.   I don't know how to make that happen.

It's fairly easy to see that a different protocol, which had end-to-end
authentication and default-reject as a basic assumption, if it were as
widely deployed as SMTP is, would not share this problem.

That is what I mean when I say that generality is not neutral.   I think
that we protocol designers need to be very careful about premature
generalization.

On Sun, Jul 15, 2018 at 3:19 PM, <[email-masked]> wrote:

> provides

---

From: [email-masked]
Date: Sun, 15 Jul 2018 17:46:52 -0400

So your point is that entering:

     X-Safeword: headcheese

is much more complicated than entering:

     To: Ted Lemon <[email-masked]>

and requires advanced technical skills.

ok.

On July 15, 2018 at 16:15 [email-masked] (Ted Lemon) wrote:
 > Barry, with all due respect, one of the things that any solution has to take
 > into account is how it will be used.   In this modern day, we are not concerned
 > with how knowledgable protocol weenies like you and I can avoid getting spammed
 > if we are willing to only communicate with other knowledgable protocol
 > weenies.   We are concerned with how you can I can communicate with people who
 > are not knowledgable, and how people who are not knowledgable can communicate
 > with each other.
 > 
 > Any solution that requires a Barry Shein to operate is it not going to survive
 > the laugh test.
 > 
 > require that everybody with whom I am going to communicate to also stop doing
 > that.   That is literally the only way that SMTP can ever be rehabilitated.   I
 > don't know how to make that happen.
 > 
 > authentication and default-reject as a basic assumption, if it were as widely
 > deployed as SMTP is, would not share this problem.
 > 
 > That is what I mean when I say that generality is not neutral.   I think that
 > we protocol designers need to be very careful about premature generalization.
 > 
 >      > The point is, if you want a protocol that allows for anonymity, which
 >     provides
 >      > for the very important human right of being able to express oneself
 >      > anonymously, it must be the case that I, as a listener, can say "I do
 >     not want
 >      > anonymous communication."   In the case of SMTP, this is not possible,
 >     because
 >      > there is only one kind of communication: anonymous communication..   If
 >     I want
 >      > any communication at all, I _must_ be receptive to anonymous
 >     communication. 
 >      >  Of course, we pretend that it is not anonymous, but in practice it
 >     is—there is
 >      > no way with SMTP to accept only messages from senders who are on my
 >     whitelist
 >      > and can prove that they are who they claim to be.   And of course I can
 >      > envision an SMTP extension that would do this, but because SMTP is so
 >     widely
 >      > deployed, and because it "works" right now without this feature, in
 >     practice
 >      > there is no way for me to do it.   And this is why, as Mallory pointed
 >     out,
 >      > people are using all kinds of closed, non-interoperating services
 >     instead of
 >      > SMTP.
 >      >
 >      > On Sat, Jul 14, 2018 at 5:02 PM, Eliot Lear <[email-masked]> wrote:
 >      >
 >      >     Ted,
 >      >   
 >      >     On 14.07.18 17:19, Ted Lemon wrote:
 >      >
 >      >     > Again, you are pushing an extreme.   Protocol bits are neither the
 >      >     > tail nor the dog.   Policy is neither the tail nor the dog.   Both
 >     are
 >      >     > part of  system.   But the protocol bits determine what is
 >      >     > _possible_.   A protocol whose bits determine that something
 >      >     > undesirable is possible is not a good design.   That's all I'm
 >     saying.
 >      >
 >      >     I think what you are suggesting is occasionally possible, but on the
 >      >     whole, runs the risk of being boiled down to an Evil Bit<tm>.  That
 >     is,
 >      >     I can certainly think of optimizations that, for instance, reduce or
 >      >     protect data elements in order to provide a service, but then if the
 >      >     point of a protocol is to provide, for instance, anonymity and it is
 >      >     used to commit crimes, what could be said about its design?  Is it
 >      >     policy-neutral?  Perhaps not.  Perhaps it favors anarchy, or perhaps
 >     it
 >      >     favors improved confidence in the infrastructure, thus propelling
 >     the
 >      >     network further as a good unto itself, as Andrew has out forth.  I
 >     find
 >      >     that distinction incredibly hard to draw.
 >      >   
 >      >     Eliot
 >      >
 >      >
 >      >
 >      >
 >      > _______________________________________________
 >      > hrpc mailing list
 >      > [email-masked]
 >      > https://www.irtf.org/mailman/listinfo/hrpc
 > 
 >     --
 >             -Barry Shein
 > 

-- 
        -Barry Shein

---

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Jul 2018 17:48:56 -0400

Correct.  Nobody types email addresses. It has to be automatic.

On Sun, Jul 15, 2018 at 5:47 PM <[email-masked]> wrote:

> take
> survive
> doing
>  >      > anonymously, it must be the case that I, as a listener, can say
> "I do
>  >     not want
>  >      > anonymous communication."   In the case of SMTP, this is not
> possible,
>  >     because
>  >      > there is only one kind of communication: anonymous
> communication..   If
>  >     I want
>  >      >  Of course, we pretend that it is not anonymous, but in practice
> it
>  >     is—there is
>  >      > no way with SMTP to accept only messages from senders who are on
> my
>  >     whitelist
>  >      > envision an SMTP extension that would do this, but because SMTP
> is so
>  >     widely
>  >      > deployed, and because it "works" right now without this feature,
> in
>  >     practice
>  >      > there is no way for me to do it.   And this is why, as Mallory
> pointed
>  >     out,
>  >      >     > tail nor the dog.   Policy is neither the tail nor the
> dog.   Both
>  >     are
>  >      >     > undesirable is possible is not a good design.   That's all
> I'm
>  >     saying.
>  >      >
>  >      >     whole, runs the risk of being boiled down to an Evil
> Bit<tm>.  That
>  >     is,
>  >      >     policy-neutral?  Perhaps not.  Perhaps it favors anarchy, or
> perhaps
>  >     it
>  >      >     favors improved confidence in the infrastructure, thus
> propelling
>  >     the
>  >      >     network further as a good unto itself, as Andrew has out
> forth.  I
>  >     find

---

From: [email-masked]
Date: Sun, 15 Jul 2018 18:45:45 -0400

And I said a "safeword" could be trivially incorporated into one's
same email contact database if there were interest.

And that it would be a lot of bang for little effort or change.

People do use per-contact generated email addresses similarly but that
really is complicated unless well-automated.

Anyhow, my point is that my proposal is so simple that a person with
almost no technical ability could use it, just swap safe words with a
friend and stick:

  X-Safeword: headcheese

in your headers, and look for one if there's any doubt.

On July 15, 2018 at 17:48 [email-masked] (Ted Lemon) wrote:
 >      > Barry, with all due respect, one of the things that any solution has to
 >     take
 >      > into account is how it will be used.   In this modern day, we are not
 >     concerned
 >      > with how knowledgable protocol weenies like you and I can avoid getting
 >     spammed
 >      > if we are willing to only communicate with other knowledgable protocol
 >      > weenies.   We are concerned with how you can I can communicate with
 >     people who
 >      > are not knowledgable, and how people who are not knowledgable can
 >     communicate
 >      > with each other.
 >      >
 >      > Any solution that requires a Barry Shein to operate is it not going to
 >     survive
 >      > the laugh test.
 >      >
 >      > The problem with any of the solutions that we've talked about is that
 >     they
 >      > require me to stop using gmail as my mail client, and more importantly
 >     they
 >      > require that everybody with whom I am going to communicate to also stop
 >     doing
 >      > that.   That is literally the only way that SMTP can ever be
 >     rehabilitated.   I
 >      > don't know how to make that happen.
 >      >
 >      > It's fairly easy to see that a different protocol, which had end-to-end
 >      > authentication and default-reject as a basic assumption, if it were as
 >     widely
 >      > deployed as SMTP is, would not share this problem.
 >      >
 >      > That is what I mean when I say that generality is not neutral.   I think
 >     that
 >      > we protocol designers need to be very careful about premature
 >     generalization.
 >      >
 >      > On Sun, Jul 15, 2018 at 3:19 PM, <[email-masked]> wrote:
 >      >
 >      >
 >      >     I've proposed that a nearly trivial way to achieve this is to just
 >      >     agree on a safeword between two email correspondents.
 >      >
 >      >     So one could manually, not difficult, or automatically via software
 >      >     agree to add the mail header:
 >      >
 >      >        X-Safeword: headcheese
 >      >
 >      >     arrived at between parties.
 >      >
 >      >     It's just another tuple in one's contacts database, and there'd be a
 >      >     very high confidence that for example if you sent me an email with
 >      >     that header it must be you. Again, I could have it checked
 >      >     automatically against my contacts database and visually flagged as
 >      >     good or bad or missing.
 >      >
 >      >     If one is willing to manage that manually, pretty trivial, it's
 >      >     available to any pair of email correspondents without any need for
 >      >     anyone else on the planet to help or approve.
 >      >
 >      >     Yes one can go into a knee-jerk security dance (shall we use RPKI?
 >      >     what if I get botted?) but...honestly...think it through. It'd
 >      >     probably work for 99.99% of use cases 99.99% of the time and make it
 >      >     nearly impossible to impersonate a correspondant.
 >      >
 >      >     On July 14, 2018 at 18:14 [email-masked] (Ted Lemon) wrote:
 >      >      > The point is, if you want a protocol that allows for anonymity,
 >     which
 >      >     provides
 >      >      > for the very important human right of being able to express
 >     oneself
 >      >      > anonymously, it must be the case that I, as a listener, can say
 >     "I do
 >      >     not want
 >      >      > anonymous communication."   In the case of SMTP, this is not
 >     possible,
 >      >     because
 >      >      > there is only one kind of communication: anonymous
 >     communication..   If
 >      >     I want
 >      >      > any communication at all, I _must_ be receptive to anonymous
 >      >     communication. 
 >      >      >  Of course, we pretend that it is not anonymous, but in practice
 >     it
 >      >     is—there is
 >      >      > no way with SMTP to accept only messages from senders who are on
 >     my
 >      >     whitelist
 >      >      > and can prove that they are who they claim to be.   And of course
 >     I can
 >      >      > envision an SMTP extension that would do this, but because SMTP
 >     is so
 >      >     widely
 >      >      > deployed, and because it "works" right now without this feature,
 >     in
 >      >     practice
 >      >      > there is no way for me to do it.   And this is why, as Mallory
 >     pointed
 >      >     out,
 >      >      > people are using all kinds of closed, non-interoperating services
 >      >     instead of
 >      >      > SMTP.
 >      >      >
 >      >      > On Sat, Jul 14, 2018 at 5:02 PM, Eliot Lear <[email-masked]>
 >     wrote:
 >      >      >
 >      >      >     Ted,
 >      >      >   
 >      >      >     On 14.07.18 17:19, Ted Lemon wrote:
 >      >      >
 >      >      >     > Again, you are pushing an extreme.   Protocol bits are
 >     neither the
 >      >      >     > tail nor the dog.   Policy is neither the tail nor the
 >     dog.   Both
 >      >     are
 >      >      >     > part of  system.   But the protocol bits determine what is
 >      >      >     > _possible_.   A protocol whose bits determine that
 >     something
 >      >      >     > undesirable is possible is not a good design.   That's all
 >     I'm
 >      >     saying.
 >      >      >
 >      >      >     I think what you are suggesting is occasionally possible, but
 >     on the
 >      >      >     whole, runs the risk of being boiled down to an Evil Bit
 >     <tm>.  That
 >      >     is,
 >      >      >     I can certainly think of optimizations that, for instance,
 >     reduce or
 >      >      >     protect data elements in order to provide a service, but then
 >     if the
 >      >      >     point of a protocol is to provide, for instance, anonymity
 >     and it is
 >      >      >     used to commit crimes, what could be said about its design? 
 >     Is it
 >      >      >     policy-neutral?  Perhaps not.  Perhaps it favors anarchy, or
 >     perhaps
 >      >     it
 >      >      >     favors improved confidence in the infrastructure, thus
 >     propelling
 >      >     the
 >      >      >     network further as a good unto itself, as Andrew has out
 >     forth.  I
 >      >     find
 >      >      >     that distinction incredibly hard to draw.
 >      >      >   
 >      >      >     Eliot
 >      >      >
 >      >      >
 >      >      >
 >      >      >
 >      >      > _______________________________________________
 >      >      > hrpc mailing list
 >      >      > [email-masked]
 >      >      > https://www.irtf.org/mailman/listinfo/hrpc
 >      >
 >      >     --
 >      >             -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*
 >      >
 >      >

-- 
        -Barry Shein

---

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Jul 2018 19:30:41 -0400

Barry, I feel that perhaps you are mocking me.   This isn't really
constructive.   Are you *seriously* suggesting that your proposal fixes the
problem I'm pointing to?

On Sun, Jul 15, 2018 at 6:45 PM, <[email-masked]> wrote:

>  >      > into account is how it will be used.   In this modern day, we
> are not
>  >     concerned
>  >      > with how knowledgable protocol weenies like you and I can avoid
> getting
>  >     spammed
>  >      > weenies.   We are concerned with how you can I can communicate
> with
>  >     people who
>  >      > The problem with any of the solutions that we've talked about is
> that
>  >     they
>  >      > require me to stop using gmail as my mail client, and more
> importantly
>  >     they
>  >      >      > The point is, if you want a protocol that allows for
> anonymity,
>  >     which
>  >      >     provides
>  >      >      > for the very important human right of being able to
> express
>  >     oneself
>  >      >      > any communication at all, I _must_ be receptive to
> anonymous
>  >      >     communication.
>  >      >      > and can prove that they are who they claim to be.   And
> of course
>  >     I can
>  >      >      > people are using all kinds of closed, non-interoperating
> services
>  >      >     instead of
>  >      >      > SMTP.
>  >      >      >
>  >      >      > On Sat, Jul 14, 2018 at 5:02 PM, Eliot Lear <
> [email-masked]>
>  >     wrote:
>  >      >      >
>  >      >      >     Ted,
>  >      >      >
>  >      >      >     > Again, you are pushing an extreme.   Protocol bits
> are
>  >     neither the
>  >      >      >     I think what you are suggesting is occasionally
> possible, but
>  >     on the
> Bit
>  >      >      >     I can certainly think of optimizations that, for
> instance,
>  >     reduce or
>  >      >      >     protect data elements in order to provide a service,
> but then
>  >     if the
>  >      >      >     point of a protocol is to provide, for instance,
> anonymity
>  >     and it is
>  >      >      >     used to commit crimes, what could be said about its
> design?
>  >     Is it
>  >      >     Software Tool & Die    | [email-masked]             |
> http://
>  >      >     www.TheWorld.com

---

From: Seth Johnson <[email-masked]>
Date: Sun, 15 Jul 2018 23:17:08 -0400

I'd rather get adoption of generality than conceiving rights as baking
in specialized use cases.

Plus:

“Freedom of expression is the matrix, the indispensable condition, of
nearly every other form of freedom.”

— U.S. Supreme Court Justice Benjamin N. Cardozo in Palko v. Connecticut

I like that.

But then again, I liked it when you just had a phone that rang at any
time and you just answered it unless you wanted to pretend you weren't
home.  :-)

Seth

On Sun, Jul 15, 2018 at 7:30 PM, Ted Lemon <[email-masked]> wrote:
> constructive.   Are you seriously suggesting that your proposal fixes the
> problem I'm pointing to?
>
>>  >      > are not knowledgable, and how people who are not knowledgable
>> can
>>  >     communicate
>>  >      > with each other.
>>  >      >
>>  >      >      > On Sat, Jul 14, 2018 at 5:02 PM, Eliot Lear
>> <[email-masked]>
>>  >     wrote:
>>  >      >      >
>>  >      >      >     Ted,
>>  >      >      >
>> http://www.TheWorld.com

---

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Jul 2018 23:18:55 -0400

Do you still have a phone like that?  How many spam calls per day?

On Sun, Jul 15, 2018 at 11:17 PM Seth Johnson <[email-masked]>
wrote:

> >>  >      > Barry, with all due respect, one of the things that any
> solution
> >> has to
> >>  >     take
> >>  >      >     Yes one can go into a knee-jerk security dance (shall we
> use
> >> RPKI?
> >>  >      >     probably work for 99.99% of use cases 99.99% of the time
> and
> >> make it
> >>  >      >      > anonymous communication."   In the case of SMTP, this
> is
> >> not
> >>  >     possible,
> >>  >      >     because
> >>  >      >      > no way with SMTP to accept only messages from senders
> who
> >> are on
> >>  >     my
> >>  >      >     whitelist
> >>  >      >      >     > tail nor the dog.   Policy is neither the tail
> nor
> >> the
> >>  >     dog.   Both
> >>  >      >     are
> >>  >      >      >     > part of  system.   But the protocol bits
> determine
> >> what is
> >>  >      >      >     > _possible_.   A protocol whose bits determine
> that
> >>  >     something
> >>  >      >      >     network further as a good unto itself, as Andrew
> has
> >> out
> >>  >     forth.  I
> >>  >      >     find

---

From: Seth Johnson <[email-masked]>
Date: Sun, 15 Jul 2018 23:27:08 -0400

I also liked it when "stalking" was handled by first telling a
lovelorn lout leave me alone, then having your brother talk to him,
then a few friends take him for drinks and a pow wow, then your
parents, then a friendly policeman who'd talk in an unthreatening way,
then ramp up from there.

That was before Caller ID.  I remember specifically the time in the
1980's when Caller ID was promoted by introducing the threat of
stalking.  I remember the specific commercial, how odd that moment
was.  Seriously.  We just picked up the phone when it rang.  :-)

Seth

On Sun, Jul 15, 2018 at 11:18 PM, Ted Lemon <[email-masked]> wrote:
>> >>  >      > authentication and default-reject as a basic assumption, if
>> >> it
>> >> were as
>> >>  >     widely
>> >>  >      > That is what I mean when I say that generality is not
>> >> neutral.
>> >> I think
>> >>  >     that
>> >>  >      >     I've proposed that a nearly trivial way to achieve this
>> >> is
>> >> to just
>> >>  >      >     So one could manually, not difficult, or automatically
>> >> via
>> >> software
>> >>  >      >     If one is willing to manage that manually, pretty
>> >> trivial,
>> >> it's
>> >>  >      >      > anonymously, it must be the case that I, as a
>> >> listener,
>> >> can say
>> >>  >     "I do
>> >>  >      >     not want
>> >>  >      >      >  Of course, we pretend that it is not anonymous, but
>> >> in
>> >> practice
>> >>  >     it
>> >>  >      >     is—there is
>> >>  >      >      > deployed, and because it "works" right now without
>> >> this
>> >> feature,
>> >>  >     in
>> >>  >      >     practice

---

From: [email-masked]
Date: Mon, 16 Jul 2018 01:49:56 -0400

> constructive.   Are you seriously suggesting that your proposal fixes the

No, not mocking.

But this has drifted totally off-topic.

-- 
        -Barry Shein

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 16 Jul 2018 07:13:02 -0400

The Cybercrime Convention signatories plenary last week reviewed the
Mapping study on cyberviolence with recommendations.  See
<https://rm.coe.int/t-cy-2017-10-cbg-study-provisional/16808c4914>

Among other things, it provides a useful formal ontology of the various
manifestations of cyberviolence and how they map to the various human
rights instruments.  hrpc might wish to use the mapping and
recommendations to study what standards and protocols can enable,
strengthen or threaten cyberviolence related human rights. 

--tony

---

From: Mark Perkins <[email-masked]>
Date: Thu, 19 Jul 2018 23:15:03 +0000 (UTC)

Tony

For my Library and Information Studies Masters I studied the New World Information and Communication Order and all the controversy surrounding it, so I am particularly jealous of your collaboration with Sean MacBride. 

However, I do not draw the same conclusions as you from this.

One of the main issues of NWICO and the MacBride report was the unequal diffusion / flow of information and its centralisation in a few hands & colonial countries. The counter arguement was of one against censorship.

The Internet, and especially the Web changed this balance and the argument. For a while the new free flow of information was seen as by some as the New Revolution, though as always - social problems do not have technical solutions.

States have since gained in capacity & willingness to censor, in mass surveillance and to use the tools to repress opposition.

Corporations have moved from centres of information flow (the old paradigm) to centres of 'attention'. 

There are also moves towards recentering the Internet, from intelligence at the edges to intelligence at the centre.

Your anecdote regarding MacBride and his deception regarding the Iran Revolution is revealing. The US/CIA backed Iranian surveillance apparatus (SAVAK) had repressed any secular opposition, leaving the mosque and bazaar the only places to organize. A similar process had occured prior (& post) to the Arab Spring, with similar backers but this time with much more sophisticated surveillance tools.

The main threats of xenophobia, racism, homophobia & misogny are in practice from states. This is not to minimize the effects of non-state actors on individuals - but it is states that have the surveillance tools and can compel the facebooks, googles, etc to hand over their data. And it is states that carry out the worst acts of xenophobia, racism, homophobia & misogny.

Increasing tracability, or diminishing the options for pseudonymity / anonymity on the grounds of enhancing accountability will have the perverse effect of increasing the surveillance power of states and thus their powers of xenophobia, racism, homophobia & misogny. This has even been recognised as the case by UN Special Rapporteurs...

My (more than) two pacific francs

Mark Perkins

    On Thursday, July 12, 2018, 11:59:16 AM GMT+11, Tony Rutkowski <[email-masked]> wrote:  
 
 Hi Amelia,

--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 20 Jul 2018 07:28:00 -0400

Hi Mark,

For me, the activity and report was a part of my life where the people
involved were colleagues and Sean became a good friend over more than a
period of a year as we met in a variety of places and trying to deal
with the profound changes in communication technology underway, the
implications, and how developments could be vectored to foster
widespread availability and beneficial communications.  It also helped
generate multiple peripheral groups much like yours here.  Progressive
Communications.  Critical Communications.  Meanwhile, some countries -
the U.S. in particular - was disparaging everything occurring.

Larry Roberts had left DARPA and started up Telenet Corp to proliferate
packet data networks worldwide via the ITU.  Indeed, he sent some of the
best engineers there to develop all the standards and use that venue to
drive the technology worldwide.  It was so successful and fast that many
were worried about concentration and U.S. domination.  Louis Pouzin's
internet technology was picked up by a variety of groups and companies
and moving forward as an array of innovative OSI internet standards in
CCITT and ISO.  The USGOV NCS declared it as the strategic basis for the
integrated government infrastructure.  Much of Europe was proceeding
with ISDN everywhere.  Bell Labs was moving forward with their own
internet based Intelligent Network out-of-band infrastructure. 
Satellite systems were proliferating everywhere as were mobile networks
in Europe.  Encryption technology was undergoing a revolution.  The
former DARPA Director how had led much of the work there for the
previous 20 years had moved to the FCC to pave the way for new internet
use via the Computer proceedings, and forced declassification of CDMA
and enabled spread spectrum use in the regulations.  ITU had started up
its huge global telecom tradeshows and policy forums.  In the States,
the Airlie House policy research conferences became great week long
events bringing together government policy makers, industry management,
and academic community researchers.  In fact, MacBride appeared at the
1978 event.  Without blathering endlessly...this was an exciting,
seminal time, and I was the goto technology person seconded to the FCC's
Office of Plans and Policy with a remit to coordinate across all the
government agencies and internationally and finishing up at night at
Washington's best known human right law school to add to an engineering
degree.  I was admitted in part because of of my civil rights legal work
earlier in the decade in the U.S. South while being part of the Apollo
launch team.

So let's agree to disagree on the characterizations of events. 
Furthermore, going forward, the evolution and importance of what you
characterize as The Internet and Web seems like hyperbole.  There were
many internets and overlay services.  As to the "revolution," much of
that was pumped up because of anti-Europe paranoia courtesy of $2.4
billion in U.S. funding.  I strongly recommend Evgeny Morozov's
descriptions of how and why things occurred. 

I expect we may agree on some matters, and disagree on others.  My two
Euros is that the world is a complex place with many developments and
competing needs that have to be reconciled through equally complex
societal and economic processes.  The DARPA Director who approved and
paid for the tcp/ip portion has spent the last twenty years doing red
team exercises and expressing concerns about where we are heading using
the technology.  At the moment, it's definitely not in a good
direction...and it is worth asking why.

--tony

On 19-Jul-18 7:15 PM, Mark Perkins wrote:
> Tony
>
> For my Library and Information Studies Masters I studied the New World
> Information and Communication Order and all the controversy
> surrounding it, so I am particularly jealous of your collaboration
> with Sean MacBride.
>
> One of the main issues of NWICO and the MacBride report was the
> unequal diffusion / flow of information and its centralisation in a
> few hands & colonial countries. The counter arguement was of one
> against censorship.
>
> The Internet, and especially the Web changed this balance and the
> argument. For a while the new free flow of information was seen as by
> some as the New Revolution, though as always - social problems do not
> have technical solutions.
>
> States have since gained in capacity & willingness to censor, in mass
> surveillance and to use the tools to repress opposition.
>
> There are also moves towards recentering the Internet, from
> intelligence at the edges to intelligence at the centre.
>
> Your anecdote regarding MacBride and his deception regarding the Iran
> Revolution is revealing. The US/CIA backed Iranian surveillance
> apparatus (SAVAK) had repressed any secular opposition, leaving the
> mosque and bazaar the only places to organize. A similar process had
> occured prior (& post) to the Arab Spring, with similar backers but
> this time with much more sophisticated surveillance tools.
>
> The main threats of xenophobia, racism, homophobia & misogny are in
> practice from states. This is not to minimize the effects of non-state
> actors on individuals - but it is states that have the surveillance
> tools and can compel the facebooks, googles, etc to hand over their
> data. And it is states that carry out the worst acts of xenophobia,
> racism, homophobia & misogny.
>
> Increasing tracability, or diminishing the options for pseudonymity /
> anonymity on the grounds of enhancing accountability will have the
> perverse effect of increasing the surveillance power of states and
> thus their powers of xenophobia, racism, homophobia & misogny. This
> has even been recognised as the case by UN Special Rapporteurs...
>
> <https://www.wcl.american.edu/impact/initiatives-programs/center/%C2%A0>
> https://law.yale.edu/study-law-yale/areas-study/human-rights-law 
> <https://law.yale.edu/study-law-yale/areas-study/human-rights-law%C2%A0%20>And,

---

From: Corinne Cath <[email-masked]>
Date: Fri, 20 Jul 2018 14:36:45 +0200

Hi Mark,

Some comments in-line:

On Fri, Jul 20, 2018 at 1:15 AM, Mark Perkins <
marknoumea=[email-masked]> wrote:

> Information and Communication Order and all the controversy surrounding it,
> so I am particularly jealous of your collaboration with Sean MacBride.
>

​+1​

> One of the main issues of NWICO and the MacBride report was the unequal
> diffusion / flow of information and its centralisation in a few hands &
> colonial countries. The counter arguement was of one against censorship.
>
> argument. For a while the new free flow of information was seen as by some
> as the New Revolution, though as always - social problems do not have
> technical solutions.
>
> There are also moves towards recentering the Internet, from intelligence
> at the edges to intelligence at the centre.
>
> Revolution is revealing. The US/CIA backed Iranian surveillance apparatus
> (SAVAK) had repressed any secular opposition, leaving the mosque and bazaar
> the only places to organize. A similar process had occured prior (& post)
> to the Arab Spring, with similar backers but this time with much more
> sophisticated surveillance tools.
>
> actors on individuals - but it is states that have the surveillance tools
> and can compel the facebooks, googles, etc to hand over their data. And it
> is states that carry out the worst acts of xenophobia, racism, homophobia &
> misogny.
>

​I am not sure it is helpful to argue that states are 'more evil' than
companies. I know its an American proclivity to worry mostly about states
but from my perspective it is simply not possible to cleanly separate what
nefarious things states do from what nefarious things companies do. States
buy their surveillance tools from company, as well as developing them in
house. They, as you indicate, get data from companies who provide this
sensitive information because they are compelled to for legal or economic
reasons.

> anonymity on the grounds of enhancing accountability will have the perverse
> effect of increasing the surveillance power of states and thus their powers
> of xenophobia, racism, homophobia & misogny. This has even been recognised
> as the case by UN Special Rapporteurs...
>

​Those same special rapporteurs have also carefully considered the roll of
private actors in facilitating government surveillance. Imo, any discussion
of the problem that actually gets to the root must be include a careful
picture of the interplay between these two actors. ​

Best,

> <https://www.wcl.american.edu/impact/initiatives-programs/center/>
> <https://law.yale.edu/study-law-yale/areas-study/human-rights-law>And,

-- 
Corinne Cath
Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute

Web: www.oii.ox.ac.uk/people/corinne-cath
Email: [email-masked] & [email-masked]
Twitter: @C_Cath

---

From: Seth Johnson <[email-masked]>
Date: Fri, 20 Jul 2018 14:28:22 -0400

Good points from Corinne -- except: state and private roles can be
distinguished.  That's in fact exactly what's needed to get clarity.

On Fri, Jul 20, 2018 at 8:36 AM, Corinne Cath <[email-masked]> wrote:
> Hi Mark,
>
> Some comments in-line:
>
> On Fri, Jul 20, 2018 at 1:15 AM, Mark Perkins
> <marknoumea=[email-masked]> wrote:
>>
>> Tony
>>
> +1
>> the only places to organize. A similar process had occured prior (& post) to
>> the Arab Spring, with similar backers but this time with much more
> I am not sure it is helpful to argue that states are 'more evil' than
> Those same special rapporteurs have also carefully considered the roll of
> picture of the interplay between these two actors.
>
> Best,
>>
>>
> Web: www.oii..ox.ac.uk/people/corinne-cath