Subject: Off-topic: making WebRTC work in practice (Re: a brief pondering)

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Apr 2020 13:53:31 +0200

In the university, a lot of WebRTC is using Jitsi as a tool.
This works mostly well, with occasional surprises.
What we could use now is a better way to diagnose these surprises.
This requires WebRTC knowledge that our IT people don’t have.
A WebRTC troubleshooting guide that I could point them to would be most helpful.
(Debugging and fixing Jitsi so it works reliably with both Firefox and Chrome would also help.)

Grüße, Carsten

> On 2020-03-22, at 06:45, Carsten Bormann <[email-masked]> wrote:
> 
> On 2020-03-21, at 16:54, Livingood, Jason <[email-masked]> wrote:
>> 
>> what can this community (and similar/adjacent ones) do productively together to help
> 
> The one thing that would be most useful for me right now would be a document with operational considerations for keeping WebRTC running (e.g., How not to mess it up with your firewall).
> 
> Grüße, Carsten
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 1 Apr 2020 10:12:27 -0500

Hi, Carsten,

> (Debugging and fixing Jitsi so it works reliably with both Firefox and

Just so I understand, are you talking about

   - something that needs to happen in RTCWeb, or
   - something that needs to happen in network operations, or
   - something that needs to happen in the Jitsi implementation itself?

If the answer is two or more of these, that's also good to know.

Best,

Spencer

> > The one thing that would be most useful for me right now would be a
> document with operational considerations for keeping WebRTC running (e.g.,
> How not to mess it up with your firewall).
> >
> > Grüße, Carsten
> >
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Apr 2020 18:36:18 +0200

On 2020-04-01, at 17:12, Spencer Dawkins at IETF <[email-masked]> wrote:
> 	• something that needs to happen in RTCWeb, or

That would be addressing diagnosability, or more specifically the accessibility of this diagnosability to system and network admins.

> 	• something that needs to happen in network operations, or

I was pointed to RFC 4787 already.
This continues to be great background material, but I’m not sure that is a very realistic document to point network admins to, today.
A more restricted set of “this is what you really minimally need to do” might be a useful companion.
Also, exposing any diagnostic information that already is there and that of course every WebRTCer knows but unfortunately nobody else.

> 	• something that needs to happen in the Jitsi implementation itself?

Definitely that (e.g., getting rid of DTLS 1.0), but of course the developers are approaching headless chicken mode already with all the recent attention.  So I was thinking more in the direction what we, and in particular the instigators of WebRTC, could do to make life more productive for both the developers and the admins.

Grüße, Carsten

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 1 Apr 2020 19:27:42 +0200

hey Carsten,

> What we could use now is a better way to diagnose these surprises.

https://test.webrtc.org/ (opensource but mostly abandoned) might help or 
https://network-test.testrtc.com/ (commercial)
chrome://webrtc-internals or firefox about:webrtc are useful but require 
you to be an expert.

> A WebRTC troubleshooting guide that I could point them to would be most helpful

https://support.google.com/a/users/answer/7380413
is pretty good. Some of it is specific to Google meet but there is quite 
some general advice.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 2 Apr 2020 14:30:21 -0600

Many of the things you need to do this were identified in developing WebRTC and put in specs. Many of them had the API in W3C specs that you need. But then the W3C marked them at risk because browser vendors did not implement them and removed them. Now if you write a patch to browser them implements them, they will not accept the patch because it is not in the spec. 

The net effect is what is possible in the browsers experience is just worse than what is possible with non browser clients (it did not need to be like this but it is). Because of this you see all the major meeting systems heavily push users towards using a downloaded client instead of the browser experience. 

The basic problem AFAIC is that at W3C, the browser have a defacto veto on anything so the API is not a negotiation between the the apps need and the browsers provide, it is more of a fait acompli of what Chrome is willing to provide. Anything chrome does not want to do, will effectively get removed from the spec because it will not have enough implementations. Once the app vendors realized that, most of them moved their focus outside of the browsers which is really unfortunate as the browsers protect the users from many security problems you are seeing today. 

> On Apr 1, 2020, at 5:53 AM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 5 Apr 2020 16:09:10 +0200

Since I've been part of almost every single one of the removals that 
Cullen refers to, it's no surprise that my perspective differs.

The push towards apps is, to my mind, mostly pushing towards *mobile* 
apps - they try to push users into the Android/IOS ecosystems because 
that's where most of the users are, and therefore most of the money is. 
On the desktop, the single vendor focusing near-exclusively on an app 
solution is Zoom.

Once you have a mobile-focused codebase, it is easy to come to depend on 
features (like, obviously, sending IP packets directly to your peer or 
other entities without going through WebRTC's protocol stack) that would 
be a security disaster if introduced into the Web ecosystem. (One can 
argue that they are a security disaster in the mobile-app ecosystem as 
well, but that's a different story.)

FWIW, the W3C has half a dozen extension documents to the WebRTC API.

That's where things are put while we try to make sure the core specs are 
in a state one can refer to as "stable" - which includes 
implementations, and yes, includes removing stuff that nobody's been 
able to show can be implemented in a browser. This is part of what the 
IETF process is supposed to do between "proposed standard" and 
"standard" (but rarely does).

The process of feature removal in no way blocks the implementation of 
new features. But the lack of a stable base specification is hampering 
(not blocking) the work of defining extensions.

Cluster 238 is eagerly awaited.

Harald

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 5 Apr 2020 09:42:23 -0700

> On the desktop, the single vendor focusing near-exclusively on an app 

It's true that Zoom does try to get me to install an app even on my linux
desktop, but my colleagues who use macOS or Windows systems find that Zoom
is hardly the only vendor that nudges them away from webRTC towards an app.
Cisco's Webex suite, in particular, has enough apps that I'm not sure I
could enumerate them all...

-Ben

---

From: Bob Hinden <[email-masked]>
Date: Sun, 5 Apr 2020 10:06:10 -0700

> On Apr 5, 2020, at 9:42 AM, Benjamin Kaduk <[email-masked]> wrote:
> 
> could enumerate them all…

By the way, can someone point me to a list of conferencing solutions that use WebRTC?

Bob

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 5 Apr 2020 22:07:23 +0200

LMGTFY - http://www.webrtcworld.com/webrtc-list.aspx came up near the 
top of the list when I searched for "list of video conferencing software 
that uses webrtc".

It looks a little dated (whereby is still called appear.in); the point 
is - it's long enough that just having the list tells you almost nothing.

---

From: Larry Masinter <[email-masked]>
Date: Sun, 5 Apr 2020 16:14:13 -0700

Does this come down to who does the implementations of extensions to WebRTC?

> Cullen refers to, it's no surprise that my perspective differs.

I can't quite tell if the difference is just who does the browser implementation
to demonstrate the extensions that WebEx and Zoom would need to avoid the
cost of maintaining separate implementations for each client platform?
Or is there some kind of driver issue? Performance? Usability? Device access?

> On the desktop, the single vendor focusing near-exclusively on an app

I  think market segmentation by platform type doesn't work here --
If you're hosting a meeting, you want success for everyone who wants to attend.
There should be no benefit to native app except for vendor lock-in.
--
https://LarryMasinter.net  https://Going-Remote.info

---

From: Keith Moore <[email-masked]>
Date: Sun, 5 Apr 2020 19:20:18 -0400

> There should be no benefit to native app except for vendor lock-in.

Well, don't discount vendor lock-in.   But of course if the app can 
communicate directly between peers, whereas the browser cannot, that 
consumes fewer resources than routing the traffic through the vendor's 
servers, and likely provides better service to users also.   An app is 
also better positioned to act as spyware.

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 5 Apr 2020 23:21:11 -0400

> also better positioned to act as spyware.

I did some of that Web stuff back in the day. I was even the first person
to write a WebMail server. But really, why are we trying to run everything
through one client stack? And in particular one with roughly four UNIX-es
worth of complexity in it at this point?

Proprietary apps do provide an opportunity to load malware. But ever since
JavaScript was added into the Web without any thought for the security
consequences, the Browser is hardly better in that respect.

I would much rather it was possible to do my email, social media and
conferencing through a single app that was not the same app as my Web
browser. I don't want my contacts information to share an address space
with active code from a Web site. I don't want my private keys or my
plaintext messages sharing context either.

We need an open standard for such a client. Because that is the only way
users can be assured the client they are downloading hasn't got a backdoor.
It isn't a perfect guarantee but it is better than the situation I have now
where my messaging provider reconfigures its app every ten days or so.
Being forced to install code updates from a single source is a security
risk in itself. And don't tell me that frequent updates are necessary for
security, if the code is so buggy it has to have an urgent security patch
more than once a month, you are doing it wrong.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Apr 2020 11:23:28 -0400

> more than once a month, you are doing it wrong.

This.

Lots of people have explained why XMPP sucks, but I prefer the suck I know
and foster some competition without a fork-lift upgrade, to the single source
of code (no matter how "open" source it is).

I don't think that the IETF is going to get anywhere with standardized video
conferencing.
I don't think W3C will either (I think they have less of a chance actually).

WebRTC is a good start, and I'm happier with javascript I have to download
and trust than native code I have to download.

Having said this, eating our own dogfood is really important.
IPv6, webrtc, QUIC, TLS1.3.

I understand from this thread that webrtc solutions can *not* send p2p
streams between end points?  I find this surprising, since I observe failures
in webrtc which seem to be lack of a clear n X n media flow.
(Alice and Bob can talk, and Alice and Carmen can talk, but Bob and Carmen can't talk)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Apr 2020 08:48:28 -0700

On Mon, Apr 6, 2020 at 8:28 AM Michael Richardson <[email-masked]>
wrote:

> streams between end points?

No, they can. However, many WebRTC-based conferencing systems still
use a centralized topology, for a variety of reasons.

-Ekr

I find this surprising, since I observe failures

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Apr 2020 15:53:31 +0000

Hi,
    
>    IPv6, webrtc, QUIC, TLS1.3.

Many native apps use webrtc too.
 
Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 6 Apr 2020 10:06:48 -0600

On 4/6/20 9:48 AM, Eric Rescorla wrote:
> 
> 
> On Mon, Apr 6, 2020 at 8:28 AM Michael Richardson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     Phillip Hallam-Baker <[email-masked]
>     <mailto:[email-masked]>> wrote:
>         > We need an open standard for such a client. Because that is
>     the only way
>         > users can be assured the client they are downloading hasn't
>     got a backdoor.
>         > It isn't a perfect guarantee but it is better than the
>     situation I have now
>         > where my messaging provider reconfigures its app every ten
>     days or so.
>         > Being forced to install code updates from a single source is a
>     security
>         > risk in itself. And don't tell me that frequent updates are
>     necessary for
>         > security, if the code is so buggy it has to have an urgent
>     security patch
>         > more than once a month, you are doing it wrong.
> 
>     This.
> 

Among other things, a selective forwarding unit is needed in order to
scale a videoconference beyond 3-4 participants (because few devices can
decode more video streams than that at once).

Peter

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 Apr 2020 12:49:24 -0500

On Sun, Apr 05, 2020 at 11:21:11PM -0400, Phillip Hallam-Baker wrote:
> risk in itself. [...]

The problem is that all things infrastructure get commoditized, so
there's no easy way to monetize them.  No profit -> no product.  Clients
are infrastructure in this sense, and if you can monetize the service,
you can fund open source clients.  Peer-to-peer... leaves out or
minimizes the service... which further reduces opportunities for
monetization.

What's the answer?  I dunno.  There are multiple business models that
could give you what you (and I) want.  But it's very challenging.  It's
just much easier, business-wise, to build a proprietary conferencing/IM
system than an open one.

>          [...]. And don't tell me that frequent updates are necessary for

Doing it right costs labor, meaning money.  See above.

Nico
--

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 6 Apr 2020 12:03:21 -0600

> On Apr 5, 2020, at 2:07 PM, Harald Alvestrand <[email-masked]> wrote:
> 
> LMGTFY - http://www.webrtcworld.com/webrtc-list.aspx <http://www.webrtcworld.com/webrtc-list.aspx> came up near the top of the list when I searched for "list of video conferencing software that uses webrtc".
> 
> It looks a little dated (whereby is still called appear.in); the point is - it's long enough that just having the list tells you almost nothing.

I note it is missing Jitsi, Hangouts, MS Teams, Zoom, & Webex

---

From: Mary B <[email-masked]>
Date: Mon, 6 Apr 2020 14:51:12 -0500

I'm gonna guess a lot of folks using it for their apps aren't on that
list.  My doctor is using doxy.me for her Telehealth sessions.    I didn't
find it to be the greatest app which is I went digging and found that it
uses WebRTC.  I now may be too easy for folks to build these apps ;)

On Mon, Apr 6, 2020 at 1:04 PM Cullen Jennings <[email-masked]> wrote:

> LMGTFY - http://www.webrtcworld.com/webrtc-list.aspx came up near the top
> of the list when I searched for "list of video conferencing software that
> uses webrtc".
>
> It looks a little dated (whereby is still called appear.in); the point is
> - it's long enough that just having the list tells you almost nothing.
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 6 Apr 2020 23:11:05 +0200

> also better positioned to act as spyware.
WebRTC was designed to allow communication directly between peers.
Much of the complexity in the stack (which RIPT is trying to get rid of)
comes precisely from the decision to make it peer to peer.

Nobody's come up with a popular way to do session establishment without
a server of some kind yet, though. (Some have tried.)

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Apr 2020 21:28:08 +0000

Hi,

> comes precisely from the decision to make it peer to peer.

As far a peer to peer communication is concerned, what complexity does RIPT get rid of?

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 07 Apr 2020 09:21:03 +0200

RIPT trives to get rid of ICE and use HTTP/3 with existing backends. It does not support peer to peer.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Apr 2020 07:26:58 +0000

Hi,

>RIPT trives to get rid of ICE and use HTTP/3 with existing backends. It does not support peer to peer.
Correct. I got confused when you talked about RIPT and peer to peer, because that is not what people have been talking about when it comes to RIPT :)
Regards,
Christer

Regards,

Christer

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 7 Apr 2020 10:21:07 +0200

> Il giorno 6 apr 2020, alle ore 20:03, Cullen Jennings <[email-masked]> ha scritto:
> 
> 
> 
>> On Apr 5, 2020, at 2:07 PM, Harald Alvestrand <[email-masked] <mailto:[email-masked]>> wrote:
>> 

+ Meetecho.

Simon

                     				            _\\|//_
                           				   ( O-O )
      ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
       ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 8 Apr 2020 23:46:24 +0200

[adding manycouches as this is really technical. ]
[can not well Bcc ietf as mailman seems to hate it]

Thanks for the insight, Cullen, Harald.

I can well understand that it is frustrating if you really want to build
a high-functional browser based app and are then not given all the
necessary support by browsers. It also makes perfect sense though for google
to only care for where their money comes from, and if that
means that android is the reference for what to do across all other
platforms and forces this onto W3C, then one just needs to take
this into account accordingly and make the community understand those
limitations of RTCweb/W3C solutions.

The question for IETF/manycouches is IMHO, what IETFs priority order of
requirements against conference tools in the future should be.
I would ideally like an open source solution working on Mac, Windows,
Linux. In other communities i would include android, but i think for
our work style its irrelevant, and if the solution is open 
source, someone will port it from linux to android anyhow when needed.
Could the solution be RTCweb based ? Sure, why not, but thats just 
an option to achieve such results, it should not be a mandate.

I do not quite understand Haralds argument, that full standards 
should only include what vendors utimately implemented in draft standard stage.
Assume that there are only 2 vendors implementing some protocol and they 
just could not be bothered to implement the security requirements,
does that mean the full IETF standard should drop the security requirements ?

I am not sure though how this all relates to what i thought the
root of the discusion was, diagnostics: 

I would certainly be interested to better understand what tracing options at
the RTCweb ap-to-browser API level exist, because my past decades
troubleshooting of (native) conferencing app networking issues always
came down to logs, syscall-traces and network traces. All the TLS
security of course makes that tracing a lot more difficult.

Cheers
    Toerless

On Thu, Apr 02, 2020 at 02:30:21PM -0600, Cullen Jennings wrote:
> > This requires WebRTC knowledge that our IT people don???t have.

-- 
---
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 9 Apr 2020 12:16:14 +0200

Keeping this particular thread on ietf.org....

> does that mean the full IETF standard should drop the security requirements ?

Of course not. What RFC 6410 (echoing RFC 2026) says about the matter is:

   The characterization of an Internet Standard remains as described in
   RFC 2026 [1], which says:

      An Internet Standard is characterized by a high degree of
      technical maturity and by a generally held belief that the
      specified protocol or service provides significant benefit to the
      Internet community.

   The IESG, in an IETF-wide Last Call of at least four weeks, confirms
   that a document advances from Proposed Standard to Internet Standard.
   The request for reclassification is sent to the IESG along with an
   explanation of how the criteria have been met.  The criteria are:

   (1) There are at least two independent interoperating implementations
       with widespread deployment and successful operational experience.

My interpretation of the requirement for "implementations" is that all
the features have been implemented. The point here is that if a feature
has not been implemented and shown to interoperate, *we don't know that
this feature is adequately specified*.
(To my mind, this includes optional features. We've had long debates on
this in the past, and I don't think we've called this one way or the
other. A badly specified, unimplementable feature is just as worthy of
removal when it's optional as when it's mandatory.)

If a document specifying a protocol has a requirement in it, and
existing implementations don't fulfil that requirement because of
missing features, we can't advance this document to Full Standard (or
W3C Proposed Recommendation). We have three possible outcomes:

- The requirement is changed. Perhaps the protocol didn't need that
requirement in order to be useful on the Internet.

- The feature is implemented, and shown to interoperate - or another
feature is specified, implemented, and shown to fulfil the requirement.

- The document does not advance.

That's all.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 15 Apr 2020 18:07:05 +0200

Hi,
>
> Which leads me to a question: what can this community (and similar/adjacent ones) do productively together to help? What new things are happening on the network from which we can learn and quickly adapt/improve?
>
In my wish list, I would see this community helping with a COVID-19 
contacts tracker:
     - with clear specifications
     - that respects the privacy concerns, for all parties
     - in opensource, for everybodys 'review
     - validated by the community
     - with decentralized databases
     - (limited in time, i.e. not becoming the new norm)
     - ...

We can clearly see such a contacts tracker coming. I know that some 
commercial companies could easily provide this but I would prefer that 
such an effort would stem from a community, such as the IETF.

Background:
https://www.theguardian.com/world/2020/apr/10/apple-google-coronavirus-us-app-privacy
https://www.cnbc.com/2020/04/10/apple-google-team-up-to-track-coronavirus-spread-using-iphone-android.html
etc.

Regards, Benoit

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Apr 2020 18:25:18 +0200

On 2020-04-15, at 18:07, Benoit Claise <bclaise=[email-masked]> wrote:
> 
> In my wish list, I would see this community helping with a COVID-19 contacts tracker:

(1) We are not fast enough.  (Some of us are, but as an organization we aren’t.)

(2) Most of the real work needs to be on the legal side.  Few of the privacy problems can be solved with technical solutions alone; in the end we’ll need good assurances that donated data are actually going to be deleted and that abusers will be seriously punished.  But yes, where tech can help, many of us can indeed help.

So maybe the job of the IETF could simply be to bring the right people together and provide a neutral forum for discussion.

Grüße, Carsten

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Apr 2020 12:42:29 -0400

On 4/15/20 12:07 PM, Benoit Claise wrote:

> Hi,
>>
>> Which leads me to a question: what can this community (and 
>> similar/adjacent ones) do productively together to help? What new 
>> things are happening on the network from which we can learn and 
>> quickly adapt/improve?
>>

I don't think it's possible.  Anything that can be used to trace 
contacts for medical purposes can be used to trace contacts for 
political purposes.

Keith

---

From: John Wroclawski <[email-masked]>
Date: Wed, 15 Apr 2020 13:13:27 -0400

> On Apr 15, 2020, at 12:42 PM, Keith Moore <[email-masked]> wrote:
> I don't think it's possible.  Anything that can be used to trace contacts for medical purposes can be used to trace contacts for political purposes.
> Keith

I imagine many people here are aware of efforts such as PACT

https://pact.mit.edu/
https://pact.mit.edu/wp-content/uploads/2020/04/The-PACT-protocol-specification-ver-0.1.pdf

and the quite similar Apple-Google proposal:

Privacy Safe Contact Tracing using Bluetooth Low Energy
https://blog.google/documents/57/Overview_of_COVID-19_Contact_Tracing_Using_BLE.pdf

(More, with links to preliminary technical specs, at:
https://blog.google/inside-google/company-announcements/apple-and-google-partner-covid-19-contact-tracing-technology )

I think the existence of these things, and the speed they’re moving at, pretty much validates Carsten’s observation that:

> On Apr 15, 2020, at 12:25 PM, Carsten Bormann <[email-masked]> wrote:

but also, it’s interesting to see how these ideas address “privacy preserving”, what the model they’ve adopted is, and how they might at least try to address Keith’s point.

cheers, -john

---

From: Bob Hinden <[email-masked]>
Date: Wed, 15 Apr 2020 11:30:01 -0700

John, Carsten,

> On Apr 15, 2020, at 10:13 AM, John Wroclawski <[email-masked]> wrote:
> 
> ….
> 

Yes, but I think it’s a mistake to think that this is a one time thing and that it will be done anytime soon.   We shouldn’t get in the way of what MIT/Google/Apple/etc. are doing in the short term, but I do think there is long term value developing something in the IETF that will prepare for the long term.   That has a reasonable balance between tracking for medical vs. political tracking.

Until there is a vaccine this will reoccur, and other pandemics will happen.

Bob

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Wed, 15 Apr 2020 20:46:05 +0200

> I don't think it's possible.  Anything that can be used to trace contacts for medical purposes can be used to trace contacts for political purposes.

I would beg to differ, though by no means perfect or yet there, the EU recommendations:

	https://ec.europa.eu/info/files/recommendation-apps-contact-tracing_en <https://ec.europa.eu/info/files/recommendation-apps-contact-tracing_en>

set out quite a 'hard' set of requirements; that by and large match the manifest/expectations of the CCC, de Waag and similar more activist/vigilant privacy groups:

	https://www.ccc.de/en/updates/2020/contact-tracing-requirements <https://www.ccc.de/en/updates/2020/contact-tracing-requirements> 

(I picked the DE one, as I could not find english version of the substancially similar NL, FR, SE and DK versions) and designs such as de DP3T design (with a few nits and warts) by and large meet those requirements. 

	https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf <https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf>

This is done by de-centralizing; and essentially constructing the cryptography such that only 'on' the phone is it possible to reconstruct 'has there been a contact' and limiting the scope/purpose to exactly that - have I been close. So no location, no tracking, no recording of position, etc. And with sufficient means for an outside observer to verify this.

The apple/google proposals are very similar - but are not as limited in `time and place'; potentially more generic.

Now obviously - there is nothing stopping someone of using the very same spec to accomplish something different; to spike the app, put hidden code in it, etc, etc.  But that is something that we have any way - those that control the phone in your pocket can put a spy in your pocket.

Dw

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Apr 2020 14:58:18 -0400

On 4/15/20 2:46 PM, Dirk-Willem van Gulik wrote:

> Now obviously - there is nothing stopping someone of using the very 
> same spec to accomplish something different; to spike the app, put 
> hidden code in it, etc, etc.  But that is something that we have any 
> way - those that control the phone in your pocket can put a spy in 
> your pocket.

Exactly.   And I believe the chance that this will not be misused, 
somewhere in the world, and probably many places, is zero.

If the net has taught us anything I think it's that anything that can be 
misused will be misused, especially to violate privacy. And the bad guys 
have time on their side.

To be clear, I don't think this is a problem that can be solved by 
protocol design.   Unless/until we can actually audit both the hardware 
and software in our mobile devices, we're vulnerable to whatever the big 
companies put in those devices, and to whatever governments demand of them.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 15 Apr 2020 15:04:48 -0400

I am either misunderstanding the context of this thread, or I am missing 
an important technical point.

I get the potential value and complexity (in many dimensions including 
privacy) of Covid-19 trackers.

If the thread is intended to encourage folks as individuals to help with 
ongoing efforts to build such things, then okay, I can understand that. 
(Although that is not what I thought I read.)

If the goal is for the IETF to do something, I am missing the technical 
point.  I do not see a protocol development or specification issue.  The 
task has lots of hard parts.  Most in the application space and in the 
data crunching spaces.  (And probably other aspects that I am not 
noticing, but that are also not protocol issues.)  What is the IETF task 
that is being asked for?

Yours,
Joel

On 4/15/2020 2:46 PM, Dirk-Willem van Gulik wrote:
> 
> On 15 Apr 2020, at 18:42, Keith Moore <[email-masked] 
> <mailto:[email-masked]>> wrote:
> https://ec.europa.eu/info/files/recommendation-apps-contact-tracing_en
> 
> set out quite a 'hard' set of requirements; that by and large match the 
> manifest/expectations of the CCC, de Waag and similar more 
> activist/vigilant privacy groups:
> 
> https://www.ccc.de/en/updates/2020/contact-tracing-requirements
> 
> (I picked the DE one, as I could not find english version of the 
> substancially similar NL, FR, SE and DK versions) and designs such as de 
> DP3T design (with a few nits and warts) by and large meet those 
> requirements.
> 
> https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf 
> <https://github.com/DP-3T/documents/blob/master/DP3T White Paper.pdf>
> 
> This is done by de-centralizing; and essentially constructing the 
> cryptography such that only 'on' the phone is it possible to reconstruct 
> 'has there been a contact' and limiting the scope/purpose to exactly 
> that - have I been close. So no location, no tracking, no recording of 
> position, etc. And with sufficient means for an outside observer to 
> verify this.
> 
> The apple/google proposals are very similar - but are not as limited in 
> `time and place'; potentially more generic.
> 
> Now obviously - there is nothing stopping someone of using the very same 
> spec to accomplish something different; to spike the app, put hidden 
> code in it, etc, etc.  But that is something that we have any way - 
> those that control the phone in your pocket can put a spy in your pocket.
> 
> Dw
> 
> 
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 15 Apr 2020 19:13:44 +0000

Bob and Benoît,

I agree for a long-term plan (but also for a short-term action like Hackathon and leveraging some IETF technologies to DISTRIBUTE -- no centralization -- of private info).

The DRIP WG (Drone Remote ID Protocol) has related use cases and technologies (also using Bluetooth BTW)

-éric

-----Original Message-----
From: ietf <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Date: Wednesday, 15 April 2020 at 20:31
To: John Wroclawski <[email-masked]>, Carsten Bormann <[email-masked]>
Cc: Bob Hinden <[email-masked]>, IETF <[email-masked]>, Keith Moore <[email-masked]>
Subject: Re: COVID-19 contacts tracker (Re: a brief pondering)

    John, Carsten,

    
    
    Bob

---

From: John Wroclawski <[email-masked]>
Date: Wed, 15 Apr 2020 15:35:44 -0400

> On Apr 15, 2020, at 2:58 PM, Keith Moore <[email-masked]> wrote:
> 
> To be clear, I don't think this is a problem that can be solved by protocol design.   Unless/until we can actually audit both the hardware and software in our mobile devices, we're vulnerable to whatever the big companies put in those devices, and to whatever governments demand of them.

But these are two distinct issues.

It’s entirely possible to design a protocol that has specific, effective privacy preserving properties, and possibly even some interesting "subversion resistance” properties, and then subvert it. 

It’s also possible to design a protocol that doesn’t have those properties in the first place - at which point I don’t need to subvert it.

It seems to me that one of these approaches should still seem more attractive than the other one to the privacy-concerned, even if neither is perfect.

cheers, -john

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Apr 2020 15:45:46 -0400

On 4/15/20 3:35 PM, John Wroclawski wrote:

>> On Apr 15, 2020, at 2:58 PM, Keith Moore<[email-masked]>  wrote:
>>

oh sure.   but IMO it's very naive to assume that leaking of information 
won't take place outside the scope of the protocol.

Keith

---

From: John Wroclawski <[email-masked]>
Date: Wed, 15 Apr 2020 15:48:16 -0400

Hi Bob,

> On Apr 15, 2020, at 2:30 PM, Bob Hinden <[email-masked]> wrote:
> 

I think you, Carsten, and I probably all agree at the top level, that the most useful place for the IETF to put energy is in directions that match its timescale, skillset, and culture. 

And I also agree that this is not a one time thing.

But that doesn’t mean that it’s useful for the IETF to put significant energy into this particular space if what ends up coming out of the MIT/Google/Apple/others efforts is a competent, open-standards result that also has the weight of significant deployment behind it. Put another way, your framing suggests that the IETF _could_ somehow do the longer-term version better in some dimension, but in this particular case it’s not obvious that that’s true, either technically or from the code-actually-getting-used point of view. 

In which case, it would seem better to consciously turn our energy to places where there's both need and room, rather than zooming off towards the me-too because it’s the cool topic of the day. I’m not _sure_ that’s how things will turn out in this space, of course, but it does seem (at least to me) very extremely likely.

A side observation addressing the other point in this thread: I have no inside knowledge, but I strongly suspect that one reason both the MIT and (believe it or not) Apple/Google groups are pushing as fast and hard as they are to get something out is to short circuit the people who are pushing equally hard for alternative tools that aren’t remotely privacy preserving or anything else. 

Precisely for the reason you mention (not a one time thing..) _something_ is going to happen in near time, and then will very likely get dug in for the longer haul. Having a reasonably competent, reasonably privacy-preserving protocol/app/whatever _already deployed and running_ is one of the better possible defenses when someone comes along with the idea to create a central-reporting-of-everything app using Covid-19 as an excuse. Which, as you may have noticed, is already starting to happen in a couple of quarters.

cheers, -john

---

From: Rob Sayre <[email-masked]>
Date: Thu, 16 Apr 2020 00:18:21 -0700

On Wed, Apr 15, 2020 at 12:53 PM John Wroclawski <[email-masked]> wrote:

>
> Precisely for the reason you mention (not a one time thing..) _something_
> is going to happen in near time, and then will very likely get dug in for
> the longer haul. Having a reasonably competent, reasonably
> privacy-preserving protocol/app/whatever _already deployed and running_ is
> one of the better possible defenses ...
>

It's not clear that any of these tracker proposals actually harm privacy.
Certainly the government in most places can get this data from phone
companies and correlate it themselves.

thanks,
Rob

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Apr 2020 00:41:44 -0700

> On Apr 16, 2020, at 12:18 AM, Rob Sayre <[email-masked]> wrote:
> 
> It's not clear that any of these tracker proposals actually harm privacy. Certainly the government in most places can get this data from phone companies and correlate it themselves.

The second statement is no doubt true. The first; as I understand the EU Privacy Court, the Data Retention Initiative violated privacy in a list of ways, and the tracker proposals are each some variation on that - not I communicated with that individual", but "I was in that individual's immediate locality".

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 16 Apr 2020 07:28:44 -0400

A data point from Dave Farber's IP list (h/t to Nick):

	Decentralized Privacy-Preserving Proximity Tracing (research from EPFL, ETHZ, Oxford..)
	https://github.com/DP-3T/documents

I've only skimmed this (so far) but it appears to be relevant.

---rsk

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Apr 2020 08:51:05 -0400

On 4/16/20 3:18 AM, Rob Sayre wrote:

> It's not clear that any of these tracker proposals actually harm 
> privacy. Certainly the government in most places can get this data 
> from phone companies and correlate it themselves.

I think that's almost true but not quite true.   The governments can get 
location data, but the location data is not that helpful at learning who 
was within virus exposure range of whom, or at learning who was actually 
within conversational range of whom (say, to spread ideas thought to be 
subversive by the leaders of a regime).    What's being talked about for 
contact tracing is using Bluetooth or other means to try to measure that 
kind of proximity.   So these would be new capabilities in addition to 
capabilities that already exist and those new capabilities might present 
new threats to people.

Keith

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 16 Apr 2020 16:56:27 +0200 (CEST)

>     Il 16/04/2020 09:18 Rob Sayre <[email-masked]> ha scritto:
> 
No, because covid19-oriented contact tracing requires much more precision than what can be provided by any location data that the operators can trace through their cellular networks; location data are unsuitable to determine a one-time contact with accuracy (though they could still be used to find longer term correlations between individuals).

This is why contact tracing is generally being done on the phone via Bluetooth low energy, with a contact range of ~10m (the other reason is that this approach allows you to trace contacts even if the cellular and/or GPS connectivity is unavailable, for example inside big buildings or underground).

Many European countries already put out calls for proposals in the past weeks and are near to selecting an app for this purpose, with the European Commission working on an EU-interoperable approach; the dominant mobile OS vendors already came up with a joint standard API to support the above; so it is unclear what the IETF could add to this in such a short timeframe.

--

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 16 Apr 2020 17:03:13 +0200

On Thu, Apr 16, 2020 at 04:56:27PM +0200,
 Vittorio Bertola <vittorio.bertola=[email-masked]> wrote 
 a message of 70 lines which said:

> Many European countries already put out calls for proposals in the
> past weeks and are near to selecting an app for this purpose,

Note that there are many reasons why it is not a good idea to fight
COVID-19 but this is another matter.

> with the European Commission working on an EU-interoperable
> approach; the dominant mobile OS vendors already came up with a
> joint standard API to support the above; so it is unclear what the
> IETF could add to this in such a short timeframe.

For the current COVID-19 outbreak, certainly nothing, IETF is not
real-time. But such worldwide pandemics may appear again in the future
so if one thinks that contact-tracing apps are a good idea, there is
still something to do.

(On the wire format, I mean. APIs are a different thing.)

---

From: John Wroclawski <[email-masked]>
Date: Thu, 16 Apr 2020 13:11:55 -0400

> On Apr 16, 2020, at 10:56 AM, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> 
> No, because covid19-oriented contact tracing requires much more precision than what can be provided by any location data that the operators can trace through their cellular networks; location data are unsuitable to determine a one-time contact with accuracy […] (the other reason is that this approach allows you to trace contacts even if the cellular and/or GPS connectivity is unavailable, 

Yes, exactly. The other interesting thing about the BTLE protocols being proposed is that they’re being designed to report that you came into close proximity to a person of interest, but not (depending on details) where, exactly when, etc. This, plus requiring you to explicitly release your tracking information, is the sense in which they’re “privacy preserving” - implementing minimum semantics needed for this specific purpose and no more.

Of course, one could always cross-correlate with other information (eg, cell-tower-trianguation-level location tracking) to peel some of this back. But if you’re worried about that, the next observation is that the BTLE protocols work even if your LTE radio is turned off - they remember things for later. So you can, at least conceptually, carry your phone with the wide area radio off when you want to, and still learn retrospectively that you were in proximity to a contact.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 16 Apr 2020 13:22:34 -0700

> Yes, exactly. The other interesting thing about the BTLE protocols being proposed is that they’re being designed to report that you came into close proximity to a person of interest, but not (depen…
Most of the anonymization schemes presented in the past ended up broken.
I understand that people at MIT, Apple, Google and other places are
trying real hard to prevent that, but history is not on their side. I
can easily imagine correlation with adtech surveillance, beacons in
physical places, cameras and face tracking, fingerprinting of Bluetooth
radios, etc. Surveillance capitalism is almost guaranteed to invest there.
> Of course, one could always cross-correlate with other information (eg, cell-tower-trianguation-level location tracking) to peel some of this back. But if you’re worried about that, the next observ…

And here comes the slippery slope. The efficiency of this reporting
varies as the square of the penetration. There will be a huge incentive
for authorities to increase that efficiency and make installation
mandatory. That means mandating carrying your phone with Bluetooth
turned on. See previous point about surveillance capitalism. Then mix
that with an alliance between states and corporations. Am I the only one
getting anxious there?

-- Christian Huitema

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 16 Apr 2020 13:39:31 -0700

I’m with you Christian!
Our privacy/rights will inevitably be abused if the technology allows to do so.
History always repeats itself.

Regards,
Jeff

> On Apr 16, 2020, at 13:23, Christian Huitema <[email-masked]> wrote:
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 17 Apr 2020 00:59:44 +0200

I am afraid our privacy/rights are already being abused as technology
developed outside of IETF already allows to do so. Pegasus  spyware is just
one example of it. There are many more ....

---

From: Rob Sayre <[email-masked]>
Date: Thu, 16 Apr 2020 17:33:25 -0700

On Thu, Apr 16, 2020 at 10:12 AM John Wroclawski <[email-masked]> wrote:

>
> > On Apr 16, 2020, at 10:56 AM, Vittorio Bertola <vittorio.bertola=
> [email-masked]> wrote:
> >
> privacy. Certainly the government in most places can get this data from
> phone companies and correlate it themselves.
> > No, because covid19-oriented contact tracing requires much more
> precision than what can be provided by any location data that the operators
> can trace through their cellular networks; location data are unsuitable to
> determine a one-time contact with accuracy […] (the other reason is that
> this approach allows you to trace contacts even if the cellular and/or GPS
> connectivity is unavailable,
>
> Yes, exactly. The other interesting thing about the BTLE protocols being
> proposed is that they’re being designed to report that you came into close
> proximity to a person of interest, but not (depending on details) where,
> exactly when, etc. This, plus requiring you to explicitly release your
> tracking information, is the sense in which they’re “privacy preserving” -
> implementing minimum semantics needed for this specific purpose and no more.
>
> Of course, one could always cross-correlate with other information (eg,
> cell-tower-trianguation-level location tracking) to peel some of this back.
> But if you’re worried about that, the next observation is that the BTLE
> protocols work even if your LTE radio is turned off - they remember things
> for later. So you can, at least conceptually, carry your phone with the
> wide area radio off when you want to, and still learn retrospectively that
> you were in proximity to a contact.
>

Here are some angles being tried:
https://www.wsj.com/articles/government-tracking-how-people-move-around-in-coronavirus-pandemic-11585393202
https://twitter.com/TectonixGEO/status/1242628347034767361

BTLE would be more accurate, but it does seem like other data sources are
good enough to get within 10m. Even with BTLE, there are cases like the
phone running out of batteries or just not carrying one...

thanks,
Rob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 17 Apr 2020 01:10:41 -0400

I am not surprised to see the privacy point raised here. And the
Apple/Google proposal is certainly very robust as far as protecting privacy
goes. I made a video presentation looking at the proposal in detail for my
YouTube cryptography course which should be out in the next couple of days.

It does have a major problem though. The task here is not to protect
privacy, we can do that with no app at all. The task is to either reduce
the spread of the disease or to enable the authorities to lift the
lockdown. Protecting privacy is a side condition. It may be a blocking side
condition such that we don't use the app at all if it isn't met. But it is
still a side condition.

If there was a therapeutic that had passed at least some non anecdotal
trials, I would be absolutely loading the app onto my phone and using it.
But that is months off even if the Gilead rumor is correct. And frankly,
having know-nothings and quacks hawking snake oil cures we know don't work
is making it harder for the legit research to take place.

So right now I am much less sanguine about this proposal than I would like.
I see it as a first attempt not a final product. It is not going to be
possible to provide absolute privacy protection and enforce targeted
quarantine. But that doesn't mean we need to sacrifice all privacy
permanently to produce something that helps lift the lockdown which is also
an infringement of civil liberties.

The bad news is that this isn't going to be a silver bullet situation and
we may have to make a messy compromise.

The good news from a technical standpoint is that going beyond this initial
proposal is actually a more interesting technical challenge. Specifically
we are going to need techniques that are from the 'exotic cryptography'
toolkit. Possibly something in the threshold toolkit or something related
to zero knowledge or oblivious transfer.

I really like what this scheme can achieve just using one way functions. It
is terrific. But it is only one point on the privacy-effectiveness
continuum and not necessarily the one we need.

This needs to be a discussion, not a unilateral proposal from the tech
camp. We are not the only stakeholders.

---

From: Harish Pillay <[email-masked]>
Date: Fri, 17 Apr 2020 17:51:34 +0800

I would like to offer up a solution using BLE that was open sourced
last week. The code is available on a GPLv3 license.

The project is called OpenTrace [0] and it implements a protocol
called Blue Trace - bluetrace.io [1] has the whitepaper [2] describing
it.

The protocol is designed to be able to federate authorised health
authorities. The protocol does not define what data is captured from
the user. That is entirely up to the authorised health authority to
decide/implement.

The operational reference implementation of the upstream OpenTrace is
called TraceTogether [3]. TraceTogether was rolled out here in
Singapore on 20 March 2020. TraceTogether was built by GovTech [4] -
the Singapore Government Technology Agency. One of the GovTech
engineers who helped build it, Joel Kek, speaks about it here [5].

I am helping with the OpenTrace project and one of the ideas the
community is considering is to see if it makes sense to have BlueTrace
be drafted as a RFC. Disclosure: I assisted GovTech in open sourcing
TraceTogerher as a member of the open source community.

In a nutshell, TraceTogether works by asking for the mobile phone # of
the user at initial run. That is the only detail - granted, a possible
personally identifiable information - that is captured. The phone
number is what the app sends to the health authority. Once the phone
number is sent, a SMS containing an OTP is sent and the user enters
that in to complete the registration. The user is then sent an
encrypted ID which is the identifier the phone will use. This
encrypted ID is signed by the private key of the health authority.

When similarly registered phones come within the 10m bluetooth range,
they exchange the encrypted ID, their signal strengths and a
timestamp. Should one of the users become infected and goes to the
hospital, with the permission of that user, the user will unlock the
phone and the health authority (in our case the Singapore Ministry of
Health) will extract the contact log. With that log, the MOH will
decrypt the IDs in the logs and check against their system for a
matching mobile phone number. From that moment on, the rest of the
contact tracing effort is human-led. The contact tracing will
determine things like how long ago was a contact established, how
close-by was the contact, how long was the encounter etc. Contact data
stored in the phone that is 21 days or older is automatically deleted.
The user can also opt out of the app at anytime.

Comments/criticisms welcome especially is we should even consider
drafting a proposal for a RFC. Also welcome are any and all interested
devs to make the project even more robust and privacy
enforcing/respecting.

Harish
[0] https://github.com/opentrace-community
[1] https://bluetrace.io/
[2] https://bluetrace.io/static/bluetrace_whitepaper-938063656596c104632def383eb33b3c.pdf
[3] https://www.tracetogether.gov.sg/
[4] https://tech.gov.sg/
[5] https://www.youtube.com/watch?v=638Hwg0pkX0

---

From: Andrew Campling <[email-masked]>
Date: Fri, 17 Apr 2020 10:04:29 +0000

On Fri, Apr 17, 2020 at 06:11 Phillip Hallam-Baker <[email-masked]> wrote:

> This needs to be a discussion, not a unilateral proposal from the tech camp. We are not the only stakeholders.

This is an important point and is well made.  Sometimes it is too easy to get carried away with technical solutions and lose sight of the other stakeholders and their needs / views, some of which may at times need to take precedence.  It’s a discussion that we are taking into EuroDig where one of the workshop will look at whether and how public policy priorities and requirements from various stakeholder groups can be taken into account in the development of new internet standards.

Andrew

---

From: Christian <[email-masked]>
Date: Fri, 17 Apr 2020 11:16:57 +0100

Yes exactly. This data is otherwise available  as part of the 
connectivity  services (onto 3GPP networks) So I don't understand why 
using Bluetooth has become a thing - particularly with the proposed NHS 
app. It sort of breaks the architecture - not that that ever bothers a 
web app shop / developer.

The idea I gather is that bluetooth locally holds device ids (Mac 
addresses?) of devices that come within range and so if an owner of a 
device comes into range of another device  it will have a record of 
that.  So what the NHS app developers are  asking for is access to this 
bluetooth historic proximity data.

That seems to miss some important points about the information 
epidemiological experts have informed us about corvid 19 so far. It  
persists on surfaces. It can be picked up off a surface and redeposited 
on another surface. It is not clear if covid-19 is mainly being 
transmitted due to face to face transmission, or via infected droplets 
being left on surfaces. Those infections do not reliably fall within the 
range of bluetooth.

So the timescale when an infected person might have provided the virus 
to other people may well not coincide tightly with the location track of 
people using bluetooth.  The bulk of infections may well fall outside 
the range of bluetooth. I think this needs to be investigated.

As Rob and others have mentioned. Given we have pretty good location 
data anyway and given that  bluetooth could lead to more false positives 
whilst completely missing many perhaps most transmissions. I think these 
app developers and health services really need to explain very clearly 
what it is they are trying to achieve.

I agree with my namesake Christian H. The privacy and business / 
societal implications of getting this wrong are really serious.

Christian de Larrinaga

On 17/04/2020 01:33, Rob Sayre wrote:
> On Thu, Apr 16, 2020 at 10:12 AM John Wroclawski <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     > On Apr 16, 2020, at 10:56 AM, Vittorio Bertola
>     <vittorio.bertola=[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     >> Il 16/04/2020 09:18 Rob Sayre <[email-masked]
>     <mailto:[email-masked]>> ha scritto:o
>     >> It's not clear that any of these tracker proposals actually
>     harm privacy. Certainly the government in most places can get this
>     data from phone companies and correlate it themselves.
>     precision than what can be provided by any location data that the
>     operators can trace through their cellular networks; location data
>     are unsuitable to determine a one-time contact with accuracy […]
>     (the other reason is that this approach allows you to trace
>     contacts even if the cellular and/or GPS connectivity is unavailable,
>
>     Yes, exactly. The other interesting thing about the BTLE protocols
>     being proposed is that they’re being designed to report that you
>     came into close proximity to a person of interest, but not
>     (depending on details) where, exactly when, etc. This, plus
>     requiring you to explicitly release your tracking information, is
>     the sense in which they’re “privacy preserving” - implementing
>     minimum semantics needed for this specific purpose and no more.
>
>     Of course, one could always cross-correlate with other information
>     (eg, cell-tower-trianguation-level location tracking) to peel some
>     of this back. But if you’re worried about that, the next
>     observation is that the BTLE protocols work even if your LTE radio
>     is turned off - they remember things for later. So you can, at
>     least conceptually, carry your phone with the wide area radio off
>     when you want to, and still learn retrospectively that you were in
>     proximity to a contact.
>
>
> BTLE would be more accurate, but it does seem like other data sources 
> are good enough to get within 10m. Even with BTLE, there are cases 
> like the phone running out of batteries or just not carrying one...
>
> thanks,
> Rob

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 17 Apr 2020 07:40:10 -0400

On Fri, Apr 17, 2020 at 11:16:57AM +0100, Christian wrote:
> epidemiological experts have informed us about corvid 19 so far. It??
> persists on surfaces. It can be picked up off a surface and redeposited on
> another surface.

On that point, please see:

	Aerosol and Surface Stability of SARS-CoV-2 as Compared with SARS-CoV-1 | NEJM
	https://www.nejm.org/doi/full/10.1056/NEJMc2004973?query=RP

	Early Release - Aerosol and Surface Distribution of Severe Acute Respiratory Syndrome Coronavirus 2 in Hospital Wards, Wuhan, China, 2020 - Volume 26, Number 7 July 2020 - Emerging Infectious Diseases journal - CDC
	https://wwwnc.cdc.gov/eid/article/26/7/20-0885_article
e

Let me attempt to summarize: it spreads readily through the air and on
surfaces.  It can survive on surfaces for varying lengths of time from
hours to days.  The second study notes that "half of the samples from
the soles of the ICU medical staff shoes tested positive".

Thus any attempt to track propagation must not only account for
person-to-person spread, but person-to-object-to-person spread, which
varying time delays between those two persons' contact with the object.

---rsk

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Apr 2020 17:20:32 +0200

On Fri, Apr 17, 2020 at 11:16:57AM +0100,
 Christian <[email-masked]> wrote 
 a message of 229 lines which said:

> It  persists on surfaces. It can be picked up off a surface and
> redeposited on another surface. It is not clear if covid-19 is
> mainly being transmitted due to face to face transmission, or via
> infected droplets being left on surfaces. Those infections do not
> reliably fall within the range of bluetooth.

The PACT protocol, in its specification, mentions the issue and
suggests a possible solution: a phone (or, actually, any thing that
has Bluetooth and runs software) left on the surface on sensitive
places (such as a shop counter), redistributing the IDs it detected.

---

From: Christian <[email-masked]>
Date: Mon, 20 Apr 2020 16:35:34 +0100

> places (such as a shop counter), redistributing the IDs it detected.

This has  the feel of tech looking for a solution. If I walk into 2 
railway stations two times a day five days a week. take two trains a 
day.  A supermarket three times a week. open and close a park gate twice 
a day.  How many indirect bluetooth proximity alerts will I receive?

How long will it be after getting possibly thousands of covid infection 
warnings that I decide to turn bluetooth off?  It is not as if there is 
any reliable anti body testing going on. So the only action to take is 
to go into self isolation for another two weeks.

This does this idea improve targeting? It looks more capable of just 
pissing people off.

C

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Apr 2020 07:24:58 -0600

>>> The one thing that would be most useful for me right now would be a document with operational considerations for keeping WebRTC running (e.g., How not to mess it up with your firewall).

Do what https://tools.ietf.org/html/rfc4787 <https://tools.ietf.org/html/rfc4787> (BCP 127) recommends. That’s about it.