profile
viewpoint
Eloy Durán alloy Microsoft Amsterdam, the Netherlands https://twitter.com/alloy

alloy/AxeMode 60

:monkey::wrench: for Xcode

alloy/cocoapods 32

[!] THIS REPO HAS BEEN MOVED

alloy/clang-compilation-database-tool 29

Tool that can be used to generate Clang Compilation DBs from Xcode.

alloy/active_merchant 6

Active Merchant is a simple payment abstraction library used in and sponsored by Shopify. It is written by Tobias Luetke, Cody Fauser, and contributors. The aim of the project is to feel natural to Ruby users and to abstract as many parts as possible away from the user to offer a consistent interface across all supported gateways.

alloy/art.c 6

Artsy Salon 2019 art exhibition entry.

alloy/anthology 5

Where stories are chronicled.

alloy/CocoaAsyncSocket 3

Asynchronous socket networking library for Mac and iOS

alloy/AFNetworking 2

A delightful iOS and OS X networking framework

push eventmicrosoft/react-native-test-app

Eloy Durán

commit sha 837241549fb27a9ed9bed3dd9beb2694a0de2d95

fix(iOS): Set base config at the project level

view details

push time in 4 hours

delete branch microsoft/react-native-macos

delete branch : add-hermes

delete time in 5 hours

Pull request review commentmicrosoft/react-native-test-app

fix(iOS): Split out Xcode build configuration

 def make_project!(xcodeproj, project_root, target_platform)   FileUtils.cp(File.join(src_xcodeproj, 'project.pbxproj'), dst_xcodeproj)   FileUtils.ln_sf(File.join(src_xcodeproj, 'xcshareddata'), dst_xcodeproj) +  # Copy Xcode build configuration files+  common_xcconfig = project_path('ReactTestApp.common.xcconfig', target_platform)+  if File.exist?(common_xcconfig)+    FileUtils.cp(common_xcconfig, destination)+    %w[debug release].each do |config|+      xcconfig = project_path("ReactTestApp.#{config}.xcconfig", target_platform)+      next unless File.exist?(xcconfig)++      dst_xcconfig = File.expand_path("ReactTestApp.#{config}.xcconfig", destination)+      File.open(dst_xcconfig, 'w') do |fo|+        pods_xcconfig_path = File.join(+          project_root.relative_path_from(destination).to_s,+          'Pods',+          'Target Support Files',+          'Pods-ReactTestApp',+          "Pods-ReactTestApp.#{config}.xcconfig"+        )

Yeah that should be stable enough 👍

tido64

comment created time in 5 hours

issue commentmicrosoft/react-native-test-app

Split out Xcode build configuration to separate files

I don’t think we need to do that inclusion, we can just assign those xcconfig files at the project level. I’ve created a PR for this branch that does that https://github.com/microsoft/react-native-test-app/pull/143

tido64

comment created time in 5 hours

PR opened microsoft/react-native-test-app

Reviewers
Set base configuration at the project level instead

Rather than setting the base configuration at the target levels and having to include the target configurations generated by CocoaPods, we can set it at the project level and have all targets inherit the settings. Currently there are no settings being set that would get overridden by CocoaPods, so this makes it all a bit simpler.

I also removed any hardcoded project level settings, as they are all being set by the xcconfigs now.

Project/target build configurations

Note how I reverted the target level setting to just those that CocoaPods generated, but assigned our xcconfig file to the project level.

build-configurations

Combined settings before

build-settings-before

Combined settings after

build-settings-after

+8 -127

0 comment

2 changed files

pr created time in 5 hours

create barnchmicrosoft/react-native-test-app

branch : alloy/extract-xcconfig

created branch time in 5 hours

create barnchalloy/one-sup

branch : master

created branch time in 6 hours

created repositoryalloy/one-sup

Meet new people across the company and learn what’s on their mind through randomised diverse virtual standups.

created time in 6 hours

Pull request review commentmicrosoft/react-native-macos

Add Hermes engine as option for macOS

 - (void)start       executorFactory = [cxxDelegate jsExecutorFactoryForBridge:self];     }     if (!executorFactory) {-      executorFactory = std::make_shared<JSCExecutorFactory>(nullptr);+      auto installBindings =

Thanks for being vigilant!

alloy

comment created time in 18 hours

push eventDefinitelyTyped/DefinitelyTyped

twsfy

commit sha 569e843ea7f85337efac40ee3622ce75e57bb950

[@types/react-native] touchSoundDisabled TouchableWithoutFeedback prop (#45727) * touchSoundDisabled TouchableWithoutFeedback prop * update disabled, touchSoundDisabled props

view details

push time in a day

PR merged DefinitelyTyped/DefinitelyTyped

[@types/react-native] touchSoundDisabled TouchableWithoutFeedback prop Owner Approved Perf: Same Popular package Untested Change

Added touchSoundDisabled prop for TouchableWithoutFeedback component

Please fill in this template.

Use a meaningful title for the pull request. Include the name of the package modified. Test the change in your own code. (Compile and run.) Add or edit tests to reflect the change. (Run with npm test.) Follow the advice from the readme. Avoid common mistakes. Run npm run lint package-name (or tsc if no tslint.json is present).

prop docs link: https://reactnative.dev/docs/touchablewithoutfeedback#touchsounddisabled

flow src link: https://github.com/facebook/react-native/blob/master/Libraries/Components/Touchable/TouchableWithoutFeedback.js#L68

+12 -2

6 comments

1 changed file

alexeymolchan

pr closed time in a day

Pull request review commentDefinitelyTyped/DefinitelyTyped

[@types/react-native] touchSoundDisabled TouchableWithoutFeedback prop

 export interface TouchableWithoutFeedbackPropsIOS {     tvParallaxProperties?: TVParallaxProperties; } +export interface TouchableWithoutFeedbackPropsAndroid {+    /**+     * If true, doesn't play a system sound on touch.+     *+     * @platform android+     */+    touchSoundDisabled?: boolean;

Great, thanks!

alexeymolchan

comment created time in a day

Pull request review commentmicrosoft/react-native-macos

Add Hermes engine as option for macOS

 - (void)start       executorFactory = [cxxDelegate jsExecutorFactoryForBridge:self];     }     if (!executorFactory) {-      executorFactory = std::make_shared<JSCExecutorFactory>(nullptr);+      auto installBindings =

Both the HermesExecutorFactory and the JSCExecutorFactory need this block, which is why I moved it out of JSCExecutorFactory.mm into here.

alloy

comment created time in a day

Pull request review commentDefinitelyTyped/DefinitelyTyped

[@types/react-native] touchSoundDisabled TouchableWithoutFeedback prop

 export interface TouchableWithoutFeedbackPropsIOS {     tvParallaxProperties?: TVParallaxProperties; } +export interface TouchableWithoutFeedbackPropsAndroid {+    /**+     * If true, doesn't play a system sound on touch.+     *+     * @platform android+     */+    touchSoundDisabled?: boolean;

@Allow i see but disabled prop has the same prefixed question mark. So should we change it as well then ?

Yup, please do 👍

To be honest, there are probably more cases that should be covered, but for now I mostly want to make sure we don’t introduce any new cases.

alexeymolchan

comment created time in a day

push eventDefinitelyTyped/DefinitelyTyped

Andrew Goodale

commit sha eaf827fcc3ef334a2ecce2f3b8fe4d334a77e947

[react-native] Add declaration for URL global type (#45803) * Add declaration for global `URL` class * Fix typo

view details

push time in a day

PR merged DefinitelyTyped/DefinitelyTyped

Reviewers
[react-native] Add declaration for URL global type Perf: Same Popular package

React Native has included a global URL type since 0.48, and since 0.59 it has an implementation usable for very basic use cases. This declaration enables using the URL type either provided by React Native itself or via a polyfill such as https://www.npmjs.com/package/react-native-url-polyfill when an application needs a more complete implementation.

Please fill in this template.

  • [x] Use a meaningful title for the pull request. Include the name of the package modified.
  • [x] Test the change in your own code. (Compile and run.)
  • [x] Add or edit tests to reflect the change. (Run with npm test.)
  • [x] Follow the advice from the readme.
  • [x] Avoid common mistakes.
  • [x] Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If changing an existing definition:

  • [x] Provide a URL to documentation or source code which provides context for the suggested changes: https://github.com/facebook/react-native/blob/master/Libraries/Blob/URL.js
  • [ ] If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.
  • [ ] Include tests for your changes
  • [ ] If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }. If for reason the any rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.
+30 -1

4 comments

2 changed files

newyankeecodeshop

pr closed time in a day

Pull request review commentmicrosoft/react-native-test-app

fix: Always copy 'app.json'

 def resources_pod(project_root, target_platform)   app_manifest = find_file('app.json', project_root)   return if app_manifest.nil? -  resources = resolve_resources(JSON.parse(File.read(app_manifest)), target_platform)-  return if !resources.instance_of?(Array) || resources.empty?+  manifest_resources = resolve_resources(JSON.parse(File.read(app_manifest)), target_platform)+  resources = ['app.json'] + (manifest_resources.instance_of?(Array) ? manifest_resources : [])

Gotcha. Just FYI, a more idiomatic way could be to use the ‘splat’ operator:

irb(main):001:0> ["app.json", *nil]
=> ["app.json"]
irb(main):002:0> ["app.json", *["foo"]]
=> ["app.json", "foo"]
tido64

comment created time in a day

issue commentmicrosoft/react-native-test-app

Add support for user provided Xcode build configuration files (.xcconfig)

👍

I extracted some settings and set it in the source .pbxproj, made sure that it got picked up, but when I try to consume it, CocoaPods would replace them with the generated ones.

This sounds like a bug in CocoaPods, but if there’s no great need for this feature right now for react-native-test-app then we probably don’t need to burden the CocoaPods team with that at this time either.

tido64

comment created time in a day

Pull request review commentmicrosoft/react-native-test-app

fix: Always copy 'app.json'

 def resources_pod(project_root, target_platform)   app_manifest = find_file('app.json', project_root)   return if app_manifest.nil? -  resources = resolve_resources(JSON.parse(File.read(app_manifest)), target_platform)-  return if !resources.instance_of?(Array) || resources.empty?+  manifest_resources = resolve_resources(JSON.parse(File.read(app_manifest)), target_platform)+  resources = ['app.json'] + (manifest_resources.instance_of?(Array) ? manifest_resources : [])

What else could manifest_resources be and should it warrant throwing an error?

tido64

comment created time in a day

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.++4. If the real upload (call to /postkeys) is done, cancel the first remaining decoy message if it has not been sent yet.++This ensures that number of calls done across the day does not reveal whether a real upload has been done, except when all of the following conditions hold: ++* the user has opened the upload screen twice or more times this day++* the user did a real upload++* the random number of decoy messages has been set at 3 (chance of 1/10000)++* the real upload occurred after the 10 random decoy messages have been sent, towards the end of the day.++This scenario is unlikely, but it is possible. The risk that this scenario occurs and an observer thus can detect a real key upload, has to be accepted.++## Random simulated TEK upload++In terms of decoy traffic volume, we will generate about 20 times the expected genuine TEK upload traffic. This is a number that we expect will hide the genuine traffic well, and at the same time does not burden the back end servers too much.++Let us calculate how much this 20x decoy traffic will be on average.++The daily infection numbers of the pandemic over the course of March to June 2020 is shown in the following graph (retrieved 22 Jun 2020 from [https://www.rivm.nl/coronavirus-covid-19/grafieken](https://www.rivm.nl/coronavirus-covid-19/grafieken)).++![Graph Dutch daily infection numbers march-june 2020](images/image_0.png)++So for the calculation of the required decoy traffic volume let us take a number of daily infections of 1000. ++And let us assume (optimistically) that half of these infected persons use the app and are willing to do the key upload. That would mean 500 genuine uploads per day. And that would mean 20x 500 = 10000 decoy uploads per day.++From our assumption that half of the infected persons use the app it follows that about half of the Dutch population has the app, which is about 8M app users.++This means that each app installation needs to generate 10000 / 8M = 0,00125 average decoy TEK upload sequence per day, or 0,0375 per 30 days. Let us round this to 4% chance per 30 days.++Note that the total amount of decoy traffic is proportional with the number of app users and with the key uploads that those app users perform. So a lower number of app users will maintain the 20:1 rate of decoy traffic versus genuine traffic.++The decoy traffic is then generated by the app as follows:++1. Each 30 days, determine whether a decoy traffic sequence is scheduled with a probability of X. X is a configuration parameter that is part of the server’s /appconfig response. X is a decimal between 0 and 1. The default value of X when the app has not successfully retrieved /appconfig yet, is 0.04 (the aforementioned 4%).+So take a number R = random(0..1) and only if R < X, continue with the next step.+Otherwise, stop this procedure and wait for the next round (in 30 days).++2. Pick a random day in the next 30 days to schedule the decoy upload sequence.+Note: we do not take into account Sundays and holidays that may have lower genuine upload traffic. We simply distribute randomly over 30 days.++3. Pick a random time between 7AM and 7PM to schedule the decoy sequence start.++4. Schedule a decoy TEK upload sequence for this random day and time.++Each decoy TEK upload sequence must behave as follows:++1. The decoy TEK upload sequence mimics the decoy traffic sequence as described in the previous paragraph, including the 14th TEK upload the following day..++2. The app maintains a counter DECOYCOUNTER of decoy traffic sent during the day by the scheduled decoy TEK upload sequence. This counter is set to 0 at the start of each decoy TEK upload sequence. Each time a decoy message is sent, the counter is increased by 1.

Even better 👍

damaarten

comment created time in a day

Pull request review commentDefinitelyTyped/DefinitelyTyped

[@types/react-native] touchSoundDisabled TouchableWithoutFeedback prop

 export interface TouchableWithoutFeedbackPropsIOS {     tvParallaxProperties?: TVParallaxProperties; } +export interface TouchableWithoutFeedbackPropsAndroid {+    /**+     * If true, doesn't play a system sound on touch.+     *+     * @platform android+     */+    touchSoundDisabled?: boolean;

A Flow type prefixed with a question mark is a “maybe” type. Both undefined and null are assignable to Flow’s “maybe” types: https://flow.org/en/docs/types/maybe/

alexeymolchan

comment created time in 2 days

issue openedreact-native-community/releases

V0.63.1 Discussion

⚠️ NOTE: v0.63.0 stable has not been released yet, but the changes it will include are final; so we have this issue ahead of time for people to already start tracking changes they need.

Conversations on this thread should be limited to reporting issues that are new in this minor version or requests to cherry-pick bug fixes that have landed in master.

In all other cases, please report the issue to http://github.com/facebook/react-native/issues.

created time in 3 days

issue commentreact-native-community/upgrade-support

Flipper shouldn't be included in Release builds

@guanhuay Alas there is no way for CocoaPods to have control over this, as Xcode does not offer that ability.

javiercr

comment created time in 3 days

pull request commentmicrosoft/react-native-test-app

chore(iOS): Remove traces of CocoaPods from source Xcode project

@NeoNacho Is this issue on your radar? (Pun intended)

tido64

comment created time in 4 days

pull request commentmicrosoft/react-native-test-app

chore(iOS): Remove traces of CocoaPods from source Xcode project

So these are unused references? Little hard to tell just from the pbxproj diff.

tido64

comment created time in 4 days

Pull request review commentDefinitelyTyped/DefinitelyTyped

[@types/react-native] touchSoundDisabled TouchableWithoutFeedback prop

 export interface TouchableWithoutFeedbackPropsIOS {     tvParallaxProperties?: TVParallaxProperties; } +export interface TouchableWithoutFeedbackPropsAndroid {+    /**+     * If true, doesn't play a system sound on touch.+     *+     * @platform android+     */+    touchSoundDisabled?: boolean;

Technically the upstream Flow typing is:

    touchSoundDisabled?: boolean | null;
alexeymolchan

comment created time in 6 days

Pull request review commentDefinitelyTyped/DefinitelyTyped

[@types/react-native] touchSoundDisabled TouchableWithoutFeedback prop

 export interface TouchableWithoutFeedbackPropsIOS {     tvParallaxProperties?: TVParallaxProperties; } +export interface TouchableWithoutFeedbackPropsAndroid {

👍

alexeymolchan

comment created time in 6 days

pull request commentDefinitelyTyped/DefinitelyTyped

[@types/react-native] touchSoundDisabled TouchableWithoutFeedback prop

@alexeymolchan Please be sure to provide links to the docs and/or Flow types in the upstream code-base, as per the instructions in the PR template 🙏

alexeymolchan

comment created time in 6 days

issue commentmicrosoft/react-native-test-app

Add support for user provided Xcode build configuration files (.xcconfig)

Re-reading the thread, there appear to be 2 subtly related questions—or perhaps, quite possibly, I’m the only one thinking of those:

  1. The question @tido64 asked was spurred by an example like https://github.com/microsoft/fluentui-react-native/tree/master/apps/ios/src, which I understood to mean ‘do we need to provide users the ability to bring their own xcconfig’ (in a generic manner)?

  2. And then there’s the question wether or not the react-native-test-app Xcode project itself should use a xcconfig file for any of its custom build settings.

As for question 1; I wonder if the specific example at hand should be enough to consider this right now, as it seems like these build settings may not strictly be needed in this context. Although having said that, I guess there’s the possibility (or perhaps even goal?) to completely retire such custom example apps, in which case the react-native-test-app would be the place to surface build warnings like these. Is that the case?

As for question 2; I don’t even know if there really are any react-native-test-app specific build settings? If they exist and don’t happen to clash with those provided typically by CocoaPods, then a simple solution would be to assign the xcconfig to the project level, rather than the target level that CocoaPods uses.

tido64

comment created time in 6 days

pull request commentmicrosoft/react-native-macos

Add Hermes engine as option for macOS

The current CI failures are identical to those on the fb62merge branch.

alloy

comment created time in 6 days

push eventmicrosoft/react-native-macos

Anandraj Govindan

commit sha 868a025d0a4509e93a0db0e2c7d0c092188303fd

Changes for modern commenting in devmain

view details

Anandraj

commit sha 1f83c4b28e262fd40cb524cb47b8a2142b66c8b1

Consuming V8JSI nuget instead of buildign V8JSI layer in react native

view details

Anandraj

commit sha 912f7852970ab150004d3eca9689508056ed286c

Ensure jsinpector is loaded before react native

view details

Eloy Durán

commit sha 5ea4f9abafc7e8a32c57547f731622ca632c2d4f

[CocoaPods] Add Hermes and get app to build & run

view details

Eloy Durán

commit sha dabc0e730e40a82f15e12c7c2fc01b3a80a62920

[Hermes] Create instance of VM from within Cxx codebase Closes https://github.com/microsoft/react-native-macos/projects/4#card-37781762

view details

Eloy Durán

commit sha b82f58109beb9f7e31c72a1102f17d7e2881de0e

[Hermes] Actually use Hermes for RN bridge.

view details

Eloy Durán

commit sha 7248255279b644c984a6274f96015ad5fe207329

[Hermes] Use a release build to speed things up

view details

Eloy Durán

commit sha a964b7ac3818d884158848a7ba5b7e06cd4c9bcf

[Hermes] Use a binary distribution for now

view details

Eloy Durán

commit sha cb48b3cb57d32a1753b6f60f3267f541e79790a8

[Hermes] Fix binary distribution

view details

Eloy Durán

commit sha 4f2fbd9ec9b0c902192c5882773abecea67708f1

[Hermes] Bind native logger, which enables console.js polyfill This fixes the lack of console.assert and consequent exception from event-target-shim.js Fixes https://github.com/microsoft/react-native-macos/projects/4#card-38201832

view details

Eloy Durán

commit sha a710e8bdf62901543321f7add79d797c42914fc4

[Hermes] Add reentrancy check Closes https://github.com/microsoft/react-native-macos/projects/4#card-38298715

view details

Eloy Durán

commit sha c12739478a959fce41330fc189656a19746bf000

[Hermes] Compile and use bytecode bundle with RNTester Closes https://github.com/microsoft/react-native-macos/projects/4#card-38307271

view details

Eloy Durán

commit sha 45ef55ef9bbf2e43d0b9da1603a9b0555b2428a2

[Hermes] Build with debugger support. Closes https://github.com/microsoft/react-native-macos/projects/4#card-38726225

view details

Eloy Durán

commit sha c9b5ff7a265da2ec8f052afb5cce83ef2ea988d8

[Hermes] Use v0.5.0 bin release

view details

Eloy Durán

commit sha 6b82e8e76d37522895d73389786a964efc952da3

[Hermes] Enable on macOS when sources exist

view details

Eloy Durán

commit sha 3e767efcef600de5852b8da628d7fec3e7379e87

[Hermes] Use optimizations in release builds

view details

Eloy Durán

commit sha 71822f30d88c9ded88dbe01a21efcedafe0b9109

[CxxBridge] Share logger binding between engines

view details

Eloy Durán

commit sha 8a39db7a360d6007b19146550437c517e82dc7d1

[Hermes] Share Android and macOS executor code.

view details

Eloy Durán

commit sha 63c10f9266910b7d873727d280dde461da64e896

[Xcode] Remove need to sign locally Fixes https://github.com/microsoft/react-native-macos/projects/4#card-37781557

view details

Eloy Durán

commit sha 2d2549c1a7451c8e99dbd607f2380e2fcff213ba

[Pods] Build libevent from source and use prebuilt hermes framework

view details

push time in 6 days

push eventmicrosoft/react-native-macos

Eloy Durán

commit sha 23daa81e6ca628cec7fe24772614860934debe09

Minor cleanups

view details

push time in 6 days

push eventalloy/react-native-macos

Eloy Durán

commit sha 23daa81e6ca628cec7fe24772614860934debe09

Minor cleanups

view details

push time in 6 days

push eventDefinitelyTyped/DefinitelyTyped

twsfy

commit sha daa2ee51cb11ace9e0b93704e1c3038ba5762acd

statusBarTranslucent modal prop (#45722)

view details

push time in 6 days

PR merged DefinitelyTyped/DefinitelyTyped

Reviewers
[@types/react-native] statusBarTranslucent modal prop Popular package Untested Change

Closes: #45711

Added statusBarTranslucent prop for Modal component

Please fill in this template.

Use a meaningful title for the pull request. Include the name of the package modified. Test the change in your own code. (Compile and run.) Add or edit tests to reflect the change. (Run with npm test.) Follow the advice from the readme. Avoid common mistakes. Run npm run lint package-name (or tsc if no tslint.json is present).

+5 -0

3 comments

1 changed file

alexeymolchan

pr closed time in 6 days

issue closedDefinitelyTyped/DefinitelyTyped

[@types/react-native] Modal component statusBarTranslucent prop is missing

  • [x] I tried using the @types/react-native package and had problems.
  • [x] I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
  • [x] [Mention] the authors (see Definitions by: in index.d.ts) so they can respond.
    • Authors: @NickGerleman @alloy @zusinShinpei @Esemesek @jeremybarbet @akrger

Hi, statusBarTranslucent prop is missing for Modal component

Снимок экрана 2020-06-25 в 23 36 05

closed time in 6 days

alexeymolchan

pull request commentDefinitelyTyped/DefinitelyTyped

[@types/react-native] statusBarTranslucent modal prop

Great, thanks! 🙏

alexeymolchan

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.++4. If the real upload (call to /postkeys) is done, cancel the first remaining decoy message if it has not been sent yet.++This ensures that number of calls done across the day does not reveal whether a real upload has been done, except when all of the following conditions hold: ++* the user has opened the upload screen twice or more times this day++* the user did a real upload++* the random number of decoy messages has been set at 3 (chance of 1/10000)++* the real upload occurred after the 10 random decoy messages have been sent, towards the end of the day.++This scenario is unlikely, but it is possible. The risk that this scenario occurs and an observer thus can detect a real key upload, has to be accepted.++## Random simulated TEK upload++In terms of decoy traffic volume, we will generate about 20 times the expected genuine TEK upload traffic. This is a number that we expect will hide the genuine traffic well, and at the same time does not burden the back end servers too much.++Let us calculate how much this 20x decoy traffic will be on average.++The daily infection numbers of the pandemic over the course of March to June 2020 is shown in the following graph (retrieved 22 Jun 2020 from [https://www.rivm.nl/coronavirus-covid-19/grafieken](https://www.rivm.nl/coronavirus-covid-19/grafieken)).++![Graph Dutch daily infection numbers march-june 2020](images/image_0.png)++So for the calculation of the required decoy traffic volume let us take a number of daily infections of 1000. ++And let us assume (optimistically) that half of these infected persons use the app and are willing to do the key upload. That would mean 500 genuine uploads per day. And that would mean 20x 500 = 10000 decoy uploads per day.++From our assumption that half of the infected persons use the app it follows that about half of the Dutch population has the app, which is about 8M app users.++This means that each app installation needs to generate 10000 / 8M = 0,00125 average decoy TEK upload sequence per day, or 0,0375 per 30 days. Let us round this to 4% chance per 30 days.++Note that the total amount of decoy traffic is proportional with the number of app users and with the key uploads that those app users perform. So a lower number of app users will maintain the 20:1 rate of decoy traffic versus genuine traffic.++The decoy traffic is then generated by the app as follows:++1. Each 30 days, determine whether a decoy traffic sequence is scheduled with a probability of X. X is a configuration parameter that is part of the server’s /appconfig response. X is a decimal between 0 and 1. The default value of X when the app has not successfully retrieved /appconfig yet, is 0.04 (the aforementioned 4%).+So take a number R = random(0..1) and only if R < X, continue with the next step.+Otherwise, stop this procedure and wait for the next round (in 30 days).++2. Pick a random day in the next 30 days to schedule the decoy upload sequence.+Note: we do not take into account Sundays and holidays that may have lower genuine upload traffic. We simply distribute randomly over 30 days.++3. Pick a random time between 7AM and 7PM to schedule the decoy sequence start.++4. Schedule a decoy TEK upload sequence for this random day and time.++Each decoy TEK upload sequence must behave as follows:++1. The decoy TEK upload sequence mimics the decoy traffic sequence as described in the previous paragraph, including the 14th TEK upload the following day..++2. The app maintains a counter DECOYCOUNTER of decoy traffic sent during the day by the scheduled decoy TEK upload sequence. This counter is set to 0 at the start of each decoy TEK upload sequence. Each time a decoy message is sent, the counter is increased by 1.

Perhaps the following, if I understood it correctly?

2. The app maintains a counter DECOYCOUNTER of decoy traffic sent during the day as scheduled by the decoy TEK upload sequence. This counter is set to 0 at the start of each decoy TEK upload sequence. Each time a decoy message is sent, the counter is increased by 1.
damaarten

comment created time in 6 days

Pull request review commentmicrosoft/react-native-test-app

test: Add tests for autolink_script_path, autolink_script_version

 def fixture_path(*args) end  class TestTestApp < Minitest::Test+  def test_autolink_script_path+    cli = fixture_path('test_app', 'node_modules', '@react-native-community', 'cli-platform-ios')+    stub :resolve_module, cli do

Interesting. It looks like it does stub the right method, but then lookup of the Pod constant fails 🤔

tido64

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.++4. If the real upload (call to /postkeys) is done, cancel the first remaining decoy message if it has not been sent yet.++This ensures that number of calls done across the day does not reveal whether a real upload has been done, except when all of the following conditions hold: ++* the user has opened the upload screen twice or more times this day++* the user did a real upload++* the random number of decoy messages has been set at 3 (chance of 1/10000)++* the real upload occurred after the 10 random decoy messages have been sent, towards the end of the day.++This scenario is unlikely, but it is possible. The risk that this scenario occurs and an observer thus can detect a real key upload, has to be accepted.

It’s unclear to me which scenario exactly is being referred to by “this”.

damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.++4. If the real upload (call to /postkeys) is done, cancel the first remaining decoy message if it has not been sent yet.++This ensures that number of calls done across the day does not reveal whether a real upload has been done, except when all of the following conditions hold: ++* the user has opened the upload screen twice or more times this day++* the user did a real upload++* the random number of decoy messages has been set at 3 (chance of 1/10000)++* the real upload occurred after the 10 random decoy messages have been sent, towards the end of the day.++This scenario is unlikely, but it is possible. The risk that this scenario occurs and an observer thus can detect a real key upload, has to be accepted.++## Random simulated TEK upload++In terms of decoy traffic volume, we will generate about 20 times the expected genuine TEK upload traffic. This is a number that we expect will hide the genuine traffic well, and at the same time does not burden the back end servers too much.++Let us calculate how much this 20x decoy traffic will be on average.++The daily infection numbers of the pandemic over the course of March to June 2020 is shown in the following graph (retrieved 22 Jun 2020 from [https://www.rivm.nl/coronavirus-covid-19/grafieken](https://www.rivm.nl/coronavirus-covid-19/grafieken)).++![Graph Dutch daily infection numbers march-june 2020](images/image_0.png)++So for the calculation of the required decoy traffic volume let us take a number of daily infections of 1000. ++And let us assume (optimistically) that half of these infected persons use the app and are willing to do the key upload. That would mean 500 genuine uploads per day. And that would mean 20x 500 = 10000 decoy uploads per day.++From our assumption that half of the infected persons use the app it follows that about half of the Dutch population has the app, which is about 8M app users.++This means that each app installation needs to generate 10000 / 8M = 0,00125 average decoy TEK upload sequence per day, or 0,0375 per 30 days. Let us round this to 4% chance per 30 days.++Note that the total amount of decoy traffic is proportional with the number of app users and with the key uploads that those app users perform. So a lower number of app users will maintain the 20:1 rate of decoy traffic versus genuine traffic.++The decoy traffic is then generated by the app as follows:++1. Each 30 days, determine whether a decoy traffic sequence is scheduled with a probability of X. X is a configuration parameter that is part of the server’s /appconfig response. X is a decimal between 0 and 1. The default value of X when the app has not successfully retrieved /appconfig yet, is 0.04 (the aforementioned 4%).+So take a number R = random(0..1) and only if R < X, continue with the next step.+Otherwise, stop this procedure and wait for the next round (in 30 days).++2. Pick a random day in the next 30 days to schedule the decoy upload sequence.+Note: we do not take into account Sundays and holidays that may have lower genuine upload traffic. We simply distribute randomly over 30 days.++3. Pick a random time between 7AM and 7PM to schedule the decoy sequence start.++4. Schedule a decoy TEK upload sequence for this random day and time.++Each decoy TEK upload sequence must behave as follows:++1. The decoy TEK upload sequence mimics the decoy traffic sequence as described in the previous paragraph, including the 14th TEK upload the following day..
1. The decoy TEK upload sequence mimics the decoy traffic sequence as described in the previous paragraph, including the 14th TEK upload the following day.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.++4. If the real upload (call to /postkeys) is done, cancel the first remaining decoy message if it has not been sent yet.++This ensures that number of calls done across the day does not reveal whether a real upload has been done, except when all of the following conditions hold: ++* the user has opened the upload screen twice or more times this day++* the user did a real upload++* the random number of decoy messages has been set at 3 (chance of 1/10000)++* the real upload occurred after the 10 random decoy messages have been sent, towards the end of the day.++This scenario is unlikely, but it is possible. The risk that this scenario occurs and an observer thus can detect a real key upload, has to be accepted.++## Random simulated TEK upload++In terms of decoy traffic volume, we will generate about 20 times the expected genuine TEK upload traffic. This is a number that we expect will hide the genuine traffic well, and at the same time does not burden the back end servers too much.++Let us calculate how much this 20x decoy traffic will be on average.++The daily infection numbers of the pandemic over the course of March to June 2020 is shown in the following graph (retrieved 22 Jun 2020 from [https://www.rivm.nl/coronavirus-covid-19/grafieken](https://www.rivm.nl/coronavirus-covid-19/grafieken)).++![Graph Dutch daily infection numbers march-june 2020](images/image_0.png)++So for the calculation of the required decoy traffic volume let us take a number of daily infections of 1000. ++And let us assume (optimistically) that half of these infected persons use the app and are willing to do the key upload. That would mean 500 genuine uploads per day. And that would mean 20x 500 = 10000 decoy uploads per day.++From our assumption that half of the infected persons use the app it follows that about half of the Dutch population has the app, which is about 8M app users.

I don’t quite follow this assumption. Could you elaborate on how you arrive at “half the Dutch population” and how “half the Dutch population” adds up to 8M users?

damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.++4. If the real upload (call to /postkeys) is done, cancel the first remaining decoy message if it has not been sent yet.++This ensures that number of calls done across the day does not reveal whether a real upload has been done, except when all of the following conditions hold: ++* the user has opened the upload screen twice or more times this day++* the user did a real upload++* the random number of decoy messages has been set at 3 (chance of 1/10000)++* the real upload occurred after the 10 random decoy messages have been sent, towards the end of the day.++This scenario is unlikely, but it is possible. The risk that this scenario occurs and an observer thus can detect a real key upload, has to be accepted.++## Random simulated TEK upload++In terms of decoy traffic volume, we will generate about 20 times the expected genuine TEK upload traffic. This is a number that we expect will hide the genuine traffic well, and at the same time does not burden the back end servers too much.++Let us calculate how much this 20x decoy traffic will be on average.++The daily infection numbers of the pandemic over the course of March to June 2020 is shown in the following graph (retrieved 22 Jun 2020 from [https://www.rivm.nl/coronavirus-covid-19/grafieken](https://www.rivm.nl/coronavirus-covid-19/grafieken)).++![Graph Dutch daily infection numbers march-june 2020](images/image_0.png)++So for the calculation of the required decoy traffic volume let us take a number of daily infections of 1000. ++And let us assume (optimistically) that half of these infected persons use the app and are willing to do the key upload. That would mean 500 genuine uploads per day. And that would mean 20x 500 = 10000 decoy uploads per day.++From our assumption that half of the infected persons use the app it follows that about half of the Dutch population has the app, which is about 8M app users.++This means that each app installation needs to generate 10000 / 8M = 0,00125 average decoy TEK upload sequence per day, or 0,0375 per 30 days. Let us round this to 4% chance per 30 days.++Note that the total amount of decoy traffic is proportional with the number of app users and with the key uploads that those app users perform. So a lower number of app users will maintain the 20:1 rate of decoy traffic versus genuine traffic.++The decoy traffic is then generated by the app as follows:++1. Each 30 days, determine whether a decoy traffic sequence is scheduled with a probability of X. X is a configuration parameter that is part of the server’s /appconfig response. X is a decimal between 0 and 1. The default value of X when the app has not successfully retrieved /appconfig yet, is 0.04 (the aforementioned 4%).+So take a number R = random(0..1) and only if R < X, continue with the next step.+Otherwise, stop this procedure and wait for the next round (in 30 days).++2. Pick a random day in the next 30 days to schedule the decoy upload sequence.+Note: we do not take into account Sundays and holidays that may have lower genuine upload traffic. We simply distribute randomly over 30 days.++3. Pick a random time between 7AM and 7PM to schedule the decoy sequence start.++4. Schedule a decoy TEK upload sequence for this random day and time.++Each decoy TEK upload sequence must behave as follows:++1. The decoy TEK upload sequence mimics the decoy traffic sequence as described in the previous paragraph, including the 14th TEK upload the following day..++2. The app maintains a counter DECOYCOUNTER of decoy traffic sent during the day by the scheduled decoy TEK upload sequence. This counter is set to 0 at the start of each decoy TEK upload sequence. Each time a decoy message is sent, the counter is increased by 1.

The first sentence reads a bit hard, in my opinion.

damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.++4. If the real upload (call to /postkeys) is done, cancel the first remaining decoy message if it has not been sent yet.

Done, as in finished? Or ‘performed’, i.e. it could still be in-flight?

damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.

The first sentence appears to be missing some words, is the following correct?

Another datum that may be observed during a genuine TEK upload (/register and /postkeys calls) is that the user might be in a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.++4. If the real upload (call to /postkeys) is done, cancel the first remaining decoy message if it has not been sent yet.++This ensures that number of calls done across the day does not reveal whether a real upload has been done, except when all of the following conditions hold: ++* the user has opened the upload screen twice or more times this day++* the user did a real upload++* the random number of decoy messages has been set at 3 (chance of 1/10000)++* the real upload occurred after the 10 random decoy messages have been sent, towards the end of the day.++This scenario is unlikely, but it is possible. The risk that this scenario occurs and an observer thus can detect a real key upload, has to be accepted.++## Random simulated TEK upload++In terms of decoy traffic volume, we will generate about 20 times the expected genuine TEK upload traffic. This is a number that we expect will hide the genuine traffic well, and at the same time does not burden the back end servers too much.++Let us calculate how much this 20x decoy traffic will be on average.++The daily infection numbers of the pandemic over the course of March to June 2020 is shown in the following graph (retrieved 22 Jun 2020 from [https://www.rivm.nl/coronavirus-covid-19/grafieken](https://www.rivm.nl/coronavirus-covid-19/grafieken)).++![Graph Dutch daily infection numbers march-june 2020](images/image_0.png)++So for the calculation of the required decoy traffic volume let us take a number of daily infections of 1000. ++And let us assume (optimistically) that half of these infected persons use the app and are willing to do the key upload. That would mean 500 genuine uploads per day. And that would mean 20x 500 = 10000 decoy uploads per day.++From our assumption that half of the infected persons use the app it follows that about half of the Dutch population has the app, which is about 8M app users.++This means that each app installation needs to generate 10000 / 8M = 0,00125 average decoy TEK upload sequence per day, or 0,0375 per 30 days. Let us round this to 4% chance per 30 days.
This means that each app installation needs to generate 10000 / 8M = 0,00125 average decoy TEK upload sequences per day, or 0,0375 per 30 days. Let us round this to 4% chance per 30 days.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:
Whenever a user opens the upload screen and /register is invoked:
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.++4. If the real upload (call to /postkeys) is done, cancel the first remaining decoy message if it has not been sent yet.++This ensures that number of calls done across the day does not reveal whether a real upload has been done, except when all of the following conditions hold: ++* the user has opened the upload screen twice or more times this day++* the user did a real upload++* the random number of decoy messages has been set at 3 (chance of 1/10000)++* the real upload occurred after the 10 random decoy messages have been sent, towards the end of the day.++This scenario is unlikely, but it is possible. The risk that this scenario occurs and an observer thus can detect a real key upload, has to be accepted.++## Random simulated TEK upload++In terms of decoy traffic volume, we will generate about 20 times the expected genuine TEK upload traffic. This is a number that we expect will hide the genuine traffic well, and at the same time does not burden the back end servers too much.++Let us calculate how much this 20x decoy traffic will be on average.++The daily infection numbers of the pandemic over the course of March to June 2020 is shown in the following graph (retrieved 22 Jun 2020 from [https://www.rivm.nl/coronavirus-covid-19/grafieken](https://www.rivm.nl/coronavirus-covid-19/grafieken)).++![Graph Dutch daily infection numbers march-june 2020](images/image_0.png)++So for the calculation of the required decoy traffic volume let us take a number of daily infections of 1000. ++And let us assume (optimistically) that half of these infected persons use the app and are willing to do the key upload. That would mean 500 genuine uploads per day. And that would mean 20x 500 = 10000 decoy uploads per day.++From our assumption that half of the infected persons use the app it follows that about half of the Dutch population has the app, which is about 8M app users.
From our assumption that half of the infected people use the app it follows that about half of the Dutch population has the app, which is about 8M app users.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.++4. If the real upload (call to /postkeys) is done, cancel the first remaining decoy message if it has not been sent yet.++This ensures that number of calls done across the day does not reveal whether a real upload has been done, except when all of the following conditions hold: ++* the user has opened the upload screen twice or more times this day++* the user did a real upload
* the user performed a real upload
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.++4. If the real upload (call to /postkeys) is done, cancel the first remaining decoy message if it has not been sent yet.++This ensures that number of calls done across the day does not reveal whether a real upload has been done, except when all of the following conditions hold: ++* the user has opened the upload screen twice or more times this day++* the user did a real upload++* the random number of decoy messages has been set at 3 (chance of 1/10000)++* the real upload occurred after the 10 random decoy messages have been sent, towards the end of the day.++This scenario is unlikely, but it is possible. The risk that this scenario occurs and an observer thus can detect a real key upload, has to be accepted.++## Random simulated TEK upload++In terms of decoy traffic volume, we will generate about 20 times the expected genuine TEK upload traffic. This is a number that we expect will hide the genuine traffic well, and at the same time does not burden the back end servers too much.++Let us calculate how much this 20x decoy traffic will be on average.++The daily infection numbers of the pandemic over the course of March to June 2020 is shown in the following graph (retrieved 22 Jun 2020 from [https://www.rivm.nl/coronavirus-covid-19/grafieken](https://www.rivm.nl/coronavirus-covid-19/grafieken)).++![Graph Dutch daily infection numbers march-june 2020](images/image_0.png)++So for the calculation of the required decoy traffic volume let us take a number of daily infections of 1000. ++And let us assume (optimistically) that half of these infected persons use the app and are willing to do the key upload. That would mean 500 genuine uploads per day. And that would mean 20x 500 = 10000 decoy uploads per day.
And let us assume (optimistically) that half of these infected persons use the app and are willing to perform the key upload. That would mean 500 genuine uploads per day. And that would mean 20x 500 = 10000 decoy uploads per day.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)
1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload).
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.++4. If the real upload (call to /postkeys) is done, cancel the first remaining decoy message if it has not been sent yet.++This ensures that number of calls done across the day does not reveal whether a real upload has been done, except when all of the following conditions hold: 
This ensures that the number of calls performed across the day does not reveal whether a real upload has been performed, except when all of the following conditions hold: 
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable
1. Generate decoy traffic when the user opens upload screen, to make genuine and simulated TEK uploads indistinguishable
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)++* more than 2 calls in a day: very likely upload (/register and/or /postkeys has been retried. /postkeys might have failed, but unlikely.)++## Combination of TEK upload and phone call++Another datum that may be observed is that during a genuine TEK upload (/register and /postkeys calls) is having a phone call with the health care worker. If this is a VoIP call, this will be visible on the WiFi network. If this is a cell phone call, its call metadata could be analysed by e.g. corporate device management software, or by a nearby observer.++Decoy traffic as described below will make this analysis less valuable.++# Decoy traffic design++We take two measures to introduce decoy traffic:++1. Generate decoy traffic when user opens upload screen, to make genuine and simulated TEK uploads indistinguishable++2. Generate simulated TEK uploads on random days.++These two measures are described in the following two paragraphs.++## Upload screen decoy traffic++Whenever a user opens upload screen and /register is invoked:++1. Schedule a first decoy message after random (5 .. 120) seconds (emulating a real upload)++2. Determine random number of additional decoy messages to send: rand (0 .. 3), negative exponential distribution: 0 additional decoys very likely, 3 additional decoys very unlikely, e.g. probability 1/10000.++3. Schedule those randomly across the rest of the day, until Midnight.
3. Schedule those randomly across the rest of the day, until midnight.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)++* 2 calls on a day with interval < 5 min: very likely upload (/register and /postkeys have been invoked, or /register has been retried, which is unlikely)++* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened upload screen twice or more that day.)
* 2 calls on a day with interval > 5 min: very likely upload (/register and /postkeys have been invoked, and for some reason the user opened the upload screen twice or more that day.)
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.

🤷‍♂️

* The user may change his mind about uploading his keys after the /register call has been made. In this case the /postkeys call will not be invoked.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:

I personally would write “on one day” or “on a single day” in all the below sentences, but perhaps too personal 🤷‍♂️

damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.

Afaik midnight should not be capitalised unless it’s at the start of a sentence of used as part of a name.

In between the second and the third call is a number of hours until a little after midnight, when the framework allows retrieval of the 14th key.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)++* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after Midnight, and another /register)
* 1 call on a day and 2 calls on following day: possible upload (/register may have been called twice; or /register, 1st /postkeys delayed until after midnight, and another /register)
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.

For consistency:

All calls to /register and /postkeys will have equal request and response lengths, by using padding.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.++# Equal request and response message lengths++An observer can detect and analyse all the Txxx_xxx request and response times, and all the Lxxx_xxx message lengths in the above table.++A first measure to mitigate traffic analysis is:++All calls to /register and /postkeys will have equal request and response sizes, by using padding.++* Lreg_req must be equal to Lpst_req++* Lreg_rsp must be equal to Lpst_rsp.++This requires both the apps (Android and iOS) and the back end server to agree upon the request and response message lengths for the /register and /postkey implementations, so that the request and response payload will always fit.++As a consequence of this measure, an observer cannot distinguish between /register calls and /postkeys calls.++# TEK upload observation++Without any decoy traffic, an observer can deduce the following:++* 0 calls on a day: no upload ++* 1 call on a day and no call on day after: no upload++* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after Midnight)
* 1 call on a day and 1 call on following day: possible upload (/register may have been called twice; or genuine /register and a delayed /postkeys after midnight)
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.++* The first call (to /register) might fail due to communications failure or server failure, resulting in one or even more retries.++* The second call (to /postkeys) might fail due to communications failure or server failure, resulting in one or even more retries.++* The user may change his mind about uploading his keys after the /register call has been made. Then the /postkeys call will not be invoked.
* The user may change their mind about uploading their keys after the /register call has been made. Then the /postkeys call will not be invoked.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.++<table>+  <tr>+    <td>Timestamp+example (sec:ms)</td>+    <td>Duration+example (sec:ms)</td>+    <td>Duration label</td>+    <td>Action</td>+    <td>Network+packet length</td>+    <td>Actor</td>+  </tr>+  <tr>+    <td>0:000</td>+    <td>0:100</td>+    <td>Treg_req</td>+    <td>Send /register request</td>+    <td>Lreg_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>0:100</td>+    <td>0:300</td>+    <td>Treg_prc</td>+    <td>Process /register request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:400</td>+    <td>0:100</td>+    <td>Treg_rsp</td>+    <td>Send/register response</td>+    <td>Lreg_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>0:500</td>+    <td>20:000</td>+    <td>Tuser</td>+    <td>Read lab conf code to operator; duration 20s in this example</td>+    <td>-</td>+    <td>User</td>+  </tr>+  <tr>+    <td>20:500</td>+    <td>0:100</td>+    <td>Tkey_req</td>+    <td>Send /postkeys request</td>+    <td>Lkey_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>20:600</td>+    <td>0:500</td>+    <td>Tkey_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>21:100</td>+    <td>0:150</td>+    <td>Tkey_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lpst_rsp</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:100</td>+    <td>0:150</td>+    <td>Tp14_req</td>+    <td>Send /postkeys request for 14th TEK; 8000s later in this example</td>+    <td>Lp14_req</td>+    <td>App</td>+  </tr>+  <tr>+    <td>8021:250</td>+    <td>0:200</td>+    <td>Tp14_prc</td>+    <td>Process /postkeys request</td>+    <td>-</td>+    <td>Server</td>+  </tr>+  <tr>+    <td>8021:450</td>+    <td>0:100</td>+    <td>Tp14_rsp</td>+    <td>Send /postkeys response</td>+    <td>Lp14_rsp</td>+    <td>Server</td>+  </tr>+</table>+++ ++Additional scenarios to take into account are:++* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads his keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.

Inclusivity:

* When the user opens the key upload screen, the app does a /register call and caches the labConfirmationID and the confirmationKey until the expiration of these, at 6AM next morning. If the user opens the screen more than once on a day and eventually uploads their keys, the time between the /register call and the /postkeys call may be much longer than some seconds or minutes.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.++The following table plots this observable network traffic on a timeline. An example delay of 20 seconds is used between the first and the second call, and an example 8000 seconds between the second and the third call.

Just some wordsmithing, following the style of the above suggestion.

The following table plots this observable network traffic on a timeline. For this example, a delay of 20 seconds is used between the first and second call, and a delay of 8000 seconds is used between the second and third call.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.

Remove this here, if moving it to the top.

damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.++* If user uses a corporate VPN, the corporate employer can continuously monitor the VPN network traffic to detect possible infections among employees.++* If user is on a home Wifi network, any housemates can monitor the network traffic.++This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.++# TEK upload sequence++Genuine TEK uploads are a sequence of 3 calls from app to server:++1. /register, to request a one-time password (labConfirmationID) and an accompanying confirmationKey and bucketID++2. /postkeys, to submit the TEK keys up to today.++3. /postkeys, once more to submit the 14th TEK key.  (NOTE:  It may be that in a next release of the GAEN framework the 14th (current) TEK is delivered together with the last 13 TEKs, followed immediately by a TEK renewal inside the framework, in the interest of privacy.)++In between the first two calls, the user reads the labConfirmationID to the health care worker over the phone. This will take some time, typically from 5 to 60 seconds (this is an estimation; not a result from a user test).++In between the second and the third call is a number of hours until a little after Midnight, when the framework allows retrieval of the 14th key.

I feel like this sentence could be phrased differently to clarify its intent. Am I understanding it correctly with the following?

There’s a few hours of delay in between the second and third call, until just after Midnight when the framework allows retrieval of the 14th key.
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:

Perhaps best to be clear as early as possible in the document that the goal is to address the issue, before listing all possible scenarios?

The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app’s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. This document describes how to mitigate network traffic analysis by systematically sending ‘decoy’ traffic that is indistinguishable from real TEK uploads.

Persons or entities that can listen in on network traffic include:
damaarten

comment created time in 6 days

Pull request review commentminvws/nl-covid19-notification-app-coordination

decoy traffic design

+Traffic analysis mitigation with decoy traffic+==============================================++# Introduction++The COVID-19 notification app allows a user who has been tested positive to upload TEKs (Temporary Exchange Keys) to the app´s back end servers. Anybody who can monitor the network traffic of the user’s device (smartphone) could potentially derive from the upload traffic that the user has a COVID-19 infection. This is a major privacy concern. Persons or entities that can listen in on network traffic include:++* If user is on a public wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.
* If user is on a public Wifi hotspot, anybody on the same public Wifi hotspot can monitor network traffic.
damaarten

comment created time in 6 days

Pull request review commentmicrosoft/react-native-test-app

test: Add tests for autolink_script_path, autolink_script_version

 def fixture_path(*args) end  class TestTestApp < Minitest::Test+  def test_autolink_script_path+    cli = fixture_path('test_app', 'node_modules', '@react-native-community', 'cli-platform-ios')+    stub :resolve_module, cli do

In fact, perhaps it might be cleaner to move all those top-level methods into a RNTA namespace module? 🤔

module RNTA
  def self.resolve_module(…)
  end
end

Anyways, for another PR.

tido64

comment created time in 6 days

Pull request review commentmicrosoft/react-native-test-app

test: Add tests for autolink_script_path, autolink_script_version

 def fixture_path(*args) end  class TestTestApp < Minitest::Test+  def test_autolink_script_path+    cli = fixture_path('test_app', 'node_modules', '@react-native-community', 'cli-platform-ios')+    stub :resolve_module, cli do

Just an FYI, but top-level methods exist on the Kernel module, so it might read a bit more clear if it was explicitly written as:

    Kernel.stub :resolve_module, cli do

Not in any way a blocker, though.

tido64

comment created time in 6 days

issue commentDefinitelyTyped/DefinitelyTyped

[@types/react-native] Modal component statusBarTranslucent prop is missing

@alexeymolchan Thanks for letting us know. Would you be willing to create a PR for this?

alexeymolchan

comment created time in 6 days

PR opened microsoft/react-native-macos

Add Hermes engine as option for macOS

Please select one of the following

  • [ ] I am removing an existing difference between facebook/react-native and microsoft/react-native-macos :thumbsup:
  • [ ] I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos :thumbsup:
  • [x] I am making a fix / change for the macOS implementation of react-native
  • [ ] I am making a change required for Microsoft usage of react-native

Summary

This adds the Hermes engine as an optional replacement to JavaScriptCore for macOS targets.

  • Hermes is enabled by virtue of adding the React-Core/Hermes dependency to one’s Podfile.
  • The engine is shipped as a prebuilt framework binary, optimised for release.
  • It comes with a separate debug symbols bundle (dSYM) for debugging/crash report symbolication.
  • Support to generate source-maps when building release builds has been added, both with and without Hermes enabled.

TODO

  • [ ] Finish this PR: review it myself and finish the PR description.
  • [ ] The changes required to build the binary are currently still here in my fork. I am reaching out to the upstream team about incorporating those changes upstream and releasing npm packages with the binary from their account, especially going forward.

Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. See https://github.com/facebook/react-native/wiki/Changelog for an example. -->

[CATEGORY] [TYPE] - Message

Test Plan

  • Update Podfile with use_react_native!(hermes_enabled => true)
  • Uncomment FORCE_BUNDLING in bundle build-script phase.
  • Verify that attaching a Chrome debugger works.
+781 -32

0 comment

15 changed files

pr created time in 7 days

push eventalloy/react-native-macos

Eloy Durán

commit sha 9df980831284ed5668456f57ee48a505340274c5

[Pods] Move hermes deps to autolink script

view details

push time in 7 days

push eventmicrosoft/react-native-macos

Eloy Durán

commit sha 9df980831284ed5668456f57ee48a505340274c5

[Pods] Move hermes deps to autolink script

view details

push time in 7 days

create barnchmicrosoft/react-native-macos

branch : add-hermes

created branch time in 7 days

push eventalloy/react-native-macos

Eloy Durán

commit sha a29aa138e61f80a2a4f97fedc0ac8a8ac1a8c34a

[Pods] Make React-Core/Hermes an optional dep

view details

Eloy Durán

commit sha 64144614030ee33bf87580c8ff0315f334bb7494

[Xcode] Add ability to create source-maps for release builds, including for hermes.

view details

Eloy Durán

commit sha 66aa4d940c990138f171a03745c6b8d639c72177

Tiny doc fix.

view details

push time in 7 days

pull request commentmicrosoft/react-native-test-app

fix: Wrong pods get installed with release candidates

@tido64 minitest comes with mocking and stubbing facilities.

tido64

comment created time in 7 days

Pull request review commentmicrosoft/react-native-test-app

Add support for 0.63

 def nearest_node_modules(project_root)  def package_version(package_path)   package_json = JSON.parse(File.read(File.join(package_path, 'package.json')))-  package_json['version'].match(/(?<major>\d+)\.(?<minor>\d+)\.(?<patch>\d+)/)+  match = package_json['version'].match(/(?<major>\d+)\.(?<minor>\d+)\.(?<patch>\d+)/)+  Gem::Version.new(match[0])

Hah, perfect 👍

tido64

comment created time in 8 days

Pull request review commentmicrosoft/react-native-test-app

Add support for 0.63

 def nearest_node_modules(project_root)  def package_version(package_path)   package_json = JSON.parse(File.read(File.join(package_path, 'package.json')))-  package_json['version'].match(/(?<major>\d+)\.(?<minor>\d+)\.(?<patch>\d+)/)+  match = package_json['version'].match(/(?<major>\d+)\.(?<minor>\d+)\.(?<patch>\d+)/)+  Gem::Version.new(match[0])

Why is there still a need to match at all, instead of Gem::Version.new(package_json['version'])?

tido64

comment created time in 8 days

Pull request review commentmicrosoft/react-native-test-app

Add support for 0.63

 def nearest_node_modules(project_root)  def package_version(package_path)   package_json = JSON.parse(File.read(File.join(package_path, 'package.json')))-  package_json['version'].match(/(?<major>\d+)\.(?<minor>\d+)\.(?<patch>\d+)/)+  match = package_json['version'].match(/(?<major>\d+)\.(?<minor>\d+)\.(?<patch>\d+)/)++  # Convert #<MatchData "0.62.2" major:"0" minor:"62" patch:"2">+  #      => {:major=>0, :minor=>62, :patch=>2}+  # Source: https://gist.github.com/bchase/d9ecfc1d58e38f158793525864583b17+  [match.names.map(&:to_sym), match.captures.map(&:to_i)].transpose.to_h

No, because stdlib libraries won’t show up in gem list:

irb(main):001:0> require "rubygems/version"
=> false
irb(main):002:0> Gem::Version.new("0.63.0-rc.1") < Gem::Version.new("0.63.0-rc.2")
=> true
irb(main):003:0> Gem::Version.new("0.63.0-rc.1") < Gem::Version.new("0.63.0-rc.0")
=> false
tido64

comment created time in 8 days

issue commentmicrosoft/react-native-windows

Manual verification checklist before release

Aye, it’s pretty much what @kmelmon lists: https://github.com/react-native-community/releases/blob/master/docs/publish-release.md

(There’s some more docs too https://github.com/react-native-community/releases/tree/master/docs)

kmelmon

comment created time in 8 days

Pull request review commentmicrosoft/react-native-test-app

Add support for 0.63

+#+# Copyright (c) Microsoft Corporation+#+# This source code is licensed under the MIT license found in the+# LICENSE file in the root directory of this source tree.+#++def include_react_native!(react_native:, target_platform:, project_root:, flipper_versions:)+  require_relative "#{File.join(project_root, react_native)}/scripts/react_native_pods"
  require_relative File.join(project_root, react_native, "scripts", "react_native_pods")
tido64

comment created time in 8 days

Pull request review commentmicrosoft/react-native-test-app

Add support for 0.63

 def nearest_node_modules(project_root)  def package_version(package_path)   package_json = JSON.parse(File.read(File.join(package_path, 'package.json')))-  package_json['version'].match(/(?<major>\d+)\.(?<minor>\d+)\.(?<patch>\d+)/)+  match = package_json['version'].match(/(?<major>\d+)\.(?<minor>\d+)\.(?<patch>\d+)/)++  # Convert #<MatchData "0.62.2" major:"0" minor:"62" patch:"2">+  #      => {:major=>0, :minor=>62, :patch=>2}+  # Source: https://gist.github.com/bchase/d9ecfc1d58e38f158793525864583b17+  [match.names.map(&:to_sym), match.captures.map(&:to_i)].transpose.to_h

The Ruby stdlib should include RubyGems iirc, which means you may just as well require its Version class: https://github.com/rubygems/rubygems/blob/master/lib/rubygems/version.rb

tido64

comment created time in 8 days

issue commentmicrosoft/react-native-test-app

Add support for user provided Xcode build configuration files (.xcconfig)

That strategy makes sense to me, but what does it mean for this thread?

tido64

comment created time in 9 days

delete branch alloy/nl-covid19-notification-app-community-website

delete branch : copy-improvement-suggestions

delete time in 9 days

Pull request review commentminvws/nl-covid19-notification-app-community-website

Copy improvement suggestions

 lang: nl index: 2 title: Ontwikkel mee-subtitle: De app is open source en je kunt de ontwikkeling volgen op Github.+subtitle: De broncode van de app is publiekelijk beschikbaar en je kunt de ontwikkeling volgen op Github.

Done

alloy

comment created time in 9 days

push eventalloy/nl-covid19-notification-app-community-website

Eloy Durán

commit sha 93206de87706dcb441aa2f4bdf58213fcb7797e7

Fix capitalization in GitHub

view details

Eloy Durán

commit sha 1dfe3502216008cf9b379645cd3ef7a68ab30c0c

Fix minor language issues.

view details

Benjamin W. Broersma

commit sha 2bb38835531465486c5ee3beb59fdf0d73d9ea05

Merge pull request #23 from alloy/fix-github-naming Fix capitalization in GitHub

view details

Benjamin W. Broersma

commit sha d337b415d621e20b0ce60f1593864cc97c4fb92d

Merge pull request #24 from alloy/fix-minor-language-issues Fix minor language issues.

view details

Eloy Durán

commit sha fdbc36e137f651068d43c185485dee7db14cfcf7

Make copy more self-actionable/explainable.

view details

Eloy Durán

commit sha 64f953963be06b50b8f14726ba085baa273582a6

Make copy more friendly

view details

Eloy Durán

commit sha 7c7ae76315276e774324f15709809ca047806d7c

Prefer using 'open-source software' terminology.

view details

push time in 9 days

Pull request review commentminvws/nl-covid19-notification-app-community-website

Copy improvement suggestions

 lang: nl index: 2 title: Ontwikkel mee-subtitle: De app is open source en je kunt de ontwikkeling volgen op Github.+subtitle: De broncode van de app is publiekelijk beschikbaar en je kunt de ontwikkeling volgen op Github.

this would deviate from the open source mentioned in the timeline (Dutch).

The timeline mentions “open source software”, which hints at the definition of OSS, as per OSI. The way it was used here–i.e. only mentioning the concept of source being available to review–and how the rest of the copy is phrased, it seemed to me like the target audience wasn’t necessarily tech-savvy people.

Seeing as this is the case, how about changing it to “open-source software”?

alloy

comment created time in 9 days

delete branch alloy/relay

delete branch : ide-friendly-errors-with-new-graphql-js

delete time in 9 days

delete branch alloy/nl-covid19-notification-app-community-website

delete branch : fix-minor-language-issues

delete time in 9 days

delete branch alloy/nl-covid19-notification-app-community-website

delete branch : fix-github-naming

delete time in 9 days

issue commentmicrosoft/react-native-test-app

Add support for user provided Xcode build configuration files (.xcconfig)

None of the settings used in those xcconfig files seem to actually influence the compilation of the host app in a functional way, are they really needed in this context?

Regardless, because of how xcconfig files work, there is no easy way to inherit from one xcconfig file into another. You can include them as is actually done in those examples, but it’s a very manual process.

Finding a way to automate that in the react-native-test-app should, I think, require us to have an example that actually enables functional changes in the test app.

tido64

comment created time in 9 days

push eventalloy/react-native-macos

Eloy Durán

commit sha ab9135f294d80cd64e684e84b25049afdb23ee8e

[Pods] Build libevent from source and use prebuilt hermes framework

view details

push time in 10 days

push eventalloy/react-native-macos

Eloy Durán

commit sha 34a64fb618159e3cb748b069c10b082612ff2753

[Hermes] Share Android and macOS executor code.

view details

Eloy Durán

commit sha c7069dd4b183a99438f1f455ec145c3b6776de59

[Xcode] Remove need to sign locally Fixes https://github.com/microsoft/react-native-macos/projects/4#card-37781557

view details

Eloy Durán

commit sha d76ab1571c77271e263d6eba6e7a9a556446ee9b

[Pods] Build libevent from source and use prebuilt hermes framework

view details

push time in 10 days

Pull request review commentmicrosoft/react-native-test-app

fix: Enable Flipper by default when on 0.62+

 def use_react_native!(project_root, target_platform)   include_react_native!(react_native: react_native.relative_path_from(project_root).to_s,                         target_platform: target_platform,                         project_root: project_root,-                        use_flipper: @use_flipper)+                        use_flipper: @use_flipper.nil? ? {} : @use_flipper)

Ahh, gotcha 👍

tido64

comment created time in 10 days

Pull request review commentmicrosoft/react-native-test-app

fix: Enable Flipper by default when on 0.62+

 def make_project!(xcodeproj, project_root, target_platform)     next if target.name != 'ReactTestApp'      target.build_configurations.each do |config|-      use_flipper = config.name == 'Debug' && @use_flipper+      use_flipper = config.name == 'Debug' && @flipper_versions != false

Seems like testing against a boolean here is not correct any longer? Perhaps just check for any falsy value?

      use_flipper = config.name == 'Debug' && @flipper_versions
tido64

comment created time in 10 days

Pull request review commentmicrosoft/react-native-test-app

fix: Enable Flipper by default when on 0.62+

 def use_react_native!(project_root, target_platform)   include_react_native!(react_native: react_native.relative_path_from(project_root).to_s,                         target_platform: target_platform,                         project_root: project_root,-                        use_flipper: @use_flipper)+                        flipper_versions: @flipper_versions.nil? ? {} : @flipper_versions)

Mostly a idiomatic Ruby FYI:

                        flipper_versions: @flipper_versions || {})
tido64

comment created time in 10 days

more