Check-in [385b2a8aa4]
Not logged in

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Markdown edits
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1:385b2a8aa412fc3d086eef23a787c6aa92513a5a
User & Date: bernd 2019-03-09 12:11:20
Context
2019-03-09
13:56
Replace memcpy with memmove, non-ambiguous copy check-in: a90f1eb37d user: bernd tags: trunk
12:11
Markdown edits check-in: 385b2a8aa4 user: bernd tags: trunk
2019-03-07
20:38
Markdown adjustments check-in: b289b99d73 user: bernd tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to cmd.fs.

437
438
439
440
441
442
443
444
445
446
447
448
449
450
451

0 net2o: dummy ( -- ) ;

[IFDEF] docgen
    :noname ( -- )
	>in @ >r ')' parse ."  ( " type ." )" cr r> >in ! ; is doc(gen
    :noname ( n "name" -- )
	." + " dup hex. >in @ >r parse-name type r> >in ! ; is .n-name
[THEN]

: ?version ( addr u -- )
    net2o-version 2over str< IF
	<err> ." Other side has more recent net2o version: " forth:type
	<warn> ." , ours: " net2o-version forth:type <default> forth:cr
    ELSE  2drop  THEN ;







|







437
438
439
440
441
442
443
444
445
446
447
448
449
450
451

0 net2o: dummy ( -- ) ;

[IFDEF] docgen
    :noname ( -- )
	>in @ >r ')' parse ."  ( " type ." )" cr r> >in ! ; is doc(gen
    :noname ( n "name" -- )
	." * " dup hex. >in @ >r parse-name type r> >in ! ; is .n-name
[THEN]

: ?version ( addr u -- )
    net2o-version 2over str< IF
	<err> ." Other side has more recent net2o version: " forth:type
	<warn> ." , ours: " net2o-version forth:type <default> forth:cr
    ELSE  2drop  THEN ;

Changes to squid.fs.

140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165

pay-table $save

}scope

\g 
\g ### Contracts ###
\g
\g Contracts are state changes to wallets.  A serialized wallet is a contract
\g that contains all the changes from an empty wallet to fill it; it is not
\g checked for balance.
\g
\g A dumb contract is checked for balance.  It consists of several selectors
\g (source/account, asset), transactions (amounts added or subtracted from an
\g asset), comments (encoded for the receiver, with a ephermeral pubkey as
\g start and a HMAC as end). Comments are fixed 64 bytes, either plain text or
\g hashes to files.  Transactions have to balance, which is facilitated with
\g the balance command, which balances the selected asset.
\g
\g The signature of a contract signs the wallet's state (serialized in
\g normalized form) after the contract has been executed.  The current
\g contract's hash is part of the serialization.

Variable SwapDragonChain# ( "hash" -- "contract" )
Variable SwapDragonKeys#  ( "pk" -- "hash+[asset,amount]*" )
\ Updates go to SwapDragonKeys'#; only one transaction per pk&cycle!







|



|






|







140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165

pay-table $save

}scope

\g 
\g ### Contracts ###
\g 
\g Contracts are state changes to wallets.  A serialized wallet is a contract
\g that contains all the changes from an empty wallet to fill it; it is not
\g checked for balance.
\g 
\g A dumb contract is checked for balance.  It consists of several selectors
\g (source/account, asset), transactions (amounts added or subtracted from an
\g asset), comments (encoded for the receiver, with a ephermeral pubkey as
\g start and a HMAC as end). Comments are fixed 64 bytes, either plain text or
\g hashes to files.  Transactions have to balance, which is facilitated with
\g the balance command, which balances the selected asset.
\g 
\g The signature of a contract signs the wallet's state (serialized in
\g normalized form) after the contract has been executed.  The current
\g contract's hash is part of the serialization.

Variable SwapDragonChain# ( "hash" -- "contract" )
Variable SwapDragonKeys#  ( "pk" -- "hash+[asset,amount]*" )
\ Updates go to SwapDragonKeys'#; only one transaction per pk&cycle!

Changes to wiki/client-auth.md.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
..
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
..
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
..
60
61
62
63
64
65
66
67
68
69
# Client Authentication #

As discussed in the [pki](pki.md) section, it is quite difficult to
solve the trust problem in a PKI system where the client has to trust
the server. The centralized Certification Authority scheme is broken,
and a distributed system is hard.

However, let's take a step back, and look <b>when</b> do we really want a
secure connection? When we have private data on a server, when we want to
authenticate us, and send our credentials over the Internet.

## Inverted Trust ##

The case we have here thus is the other way round: The server wants to know
our identity, and will present us data only when it trusts us. This is a case
................................................................................
where public keys still help us: it is sufficient when one side of a
communication verifies the identity of the partner, as a man in the middle
attack has to replace both identities to actually intercept the communication
(if there is an identity exchange).

So what happens if we use the public key as sign-in to the server? The user
presents its public key, which establishes a shared secret that allows to
verify that this user is legitimate (i.e. knows his secret key), <b>and</b> at
the same time allows to establish a secure connection.

The trust model is again "we know each other" model. This time, we have a
much better position than in the "unknown server case": The first time an
unknown new user accesses a server is when he creates his account. This is
still critical, you don't want to create an account while a man-in-the-middle
attack is ongoing (this is a "captive environment" problem; if you never leave
................................................................................
## Identity Captcha ##

And, as a captcha is usually part of signing onto a server, you can test the
connection with something that is hard for an automatic interception system to
emulate. You send a normal captcha (a distorted image, voice, a program that
generates the text through some non-trivial logic, etc.), which the automatic
interception is not able to process. You encrypt the answer to this captcha on
the client side using the shared secret, and sending <b>only</b> the encryption
checksum of this answer. The intercepting system can not generate the answer to
the captcha itself, and therefore can not generate the correct checksum. The
intercepted client does not have the correct shared secret, and therefore can't
create the correct checksum even though the user correctly answers the captcha.

This verifies that when creating the account, a secure, non-intercepted
connection was present. The server now stores the user's public key as primary
................................................................................
This approach still fails in an environment, where all connections are
intercepted, and the miniluv spends the effort to solve captcha
puzzles, or whatever computationally expensive task (but easy enough
to solve for humans) is done to reduce that risk.

If identity providers like Google, Yahoo, or Facebook would simply use
client certificates to verify the identity of their customers (self-singed
client certificates are perfect, what matters is that the certificate <b>does
not change</b>), much of the SSL dilemma would already be solved in a practical
way. No trust chain with the weakest CA as link anymore.







|







 







|







 







|







 







|
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
..
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
..
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
..
60
61
62
63
64
65
66
67
68
69
# Client Authentication #

As discussed in the [pki](pki.md) section, it is quite difficult to
solve the trust problem in a PKI system where the client has to trust
the server. The centralized Certification Authority scheme is broken,
and a distributed system is hard.

However, let's take a step back, and look **when** do we really want a
secure connection? When we have private data on a server, when we want to
authenticate us, and send our credentials over the Internet.

## Inverted Trust ##

The case we have here thus is the other way round: The server wants to know
our identity, and will present us data only when it trusts us. This is a case
................................................................................
where public keys still help us: it is sufficient when one side of a
communication verifies the identity of the partner, as a man in the middle
attack has to replace both identities to actually intercept the communication
(if there is an identity exchange).

So what happens if we use the public key as sign-in to the server? The user
presents its public key, which establishes a shared secret that allows to
verify that this user is legitimate (i.e. knows his secret key), **and** at
the same time allows to establish a secure connection.

The trust model is again "we know each other" model. This time, we have a
much better position than in the "unknown server case": The first time an
unknown new user accesses a server is when he creates his account. This is
still critical, you don't want to create an account while a man-in-the-middle
attack is ongoing (this is a "captive environment" problem; if you never leave
................................................................................
## Identity Captcha ##

And, as a captcha is usually part of signing onto a server, you can test the
connection with something that is hard for an automatic interception system to
emulate. You send a normal captcha (a distorted image, voice, a program that
generates the text through some non-trivial logic, etc.), which the automatic
interception is not able to process. You encrypt the answer to this captcha on
the client side using the shared secret, and sending **only** the encryption
checksum of this answer. The intercepting system can not generate the answer to
the captcha itself, and therefore can not generate the correct checksum. The
intercepted client does not have the correct shared secret, and therefore can't
create the correct checksum even though the user correctly answers the captcha.

This verifies that when creating the account, a secure, non-intercepted
connection was present. The server now stores the user's public key as primary
................................................................................
This approach still fails in an environment, where all connections are
intercepted, and the miniluv spends the effort to solve captcha
puzzles, or whatever computationally expensive task (but easy enough
to solve for humans) is done to reduce that risk.

If identity providers like Google, Yahoo, or Facebook would simply use
client certificates to verify the identity of their customers (self-singed
client certificates are perfect, what matters is that the certificate **does
not change**), much of the SSL dilemma would already be solved in a practical
way. No trust chain with the weakest CA as link anymore.

Changes to wiki/commands.md.

20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452

453
454
455

456
457
458
459
460
461

462
463
464

## List of Commands ##

Commands are context-sensitive in an OOP method hierarchy sense.

### base commands ###

+ $0 end-cmd ( -- )
  end command buffer
+ $1 lit ( #u -- u )
  literal
+ $2 -lit ( #n -- n )
  negative literal, inverted encoded
+ $3 string ( #string -- $:string )
  string literal
+ $4 flit ( #dfloat -- r )
  double float literal
+ $5 end-with ( o:object -- )
  end scope
+ $6 oswap ( o:nest o:current -- o:current o:nest )
+ $7 tru ( -- f:true )
  true flag literal
+ $8 fals ( -- f:false )
  false flag literal
+ $9 words ( ustart -- )
  reflection
+ $A nestsig ( $:cmd+sig -- )
  check sig+nest
+ $B secstring ( #string -- $:string )
  secret string literal
+ $C nop ( -- )
  do nothing
+ $D 4cc ( #3letter -- )
  At the beginning of a file, this can be used as FourCC code
+ $E padding ( #len -- )
  add padding to align fields
+ $F version ( $:version -- )
  version check

### reply commands ###

+ $10 push' ( #cmd -- )
  push command into answer packet
+ $11 push-lit ( u -- )
  push unsigned literal into answer packet
+ $13 push-$ ( $:string -- )
  push string into answer packet
+ $14 push-float ( r -- )
  push floating point number
+ $15 ok ( utag -- )
  tagged response
+ $16 ok? ( utag -- )
  request tagged response
+ $17 ko ( uerror -- )
  receive error message
+ $18 nest ( $:string -- )
  nested (self-encrypted) command
+ $19 token ( $:token n -- )
  generic inspection token
+ $1A error-id ( $:errorid -- )
  error-id string
+ $1B version? ( $:version -- )
  version cross-check

### connection generic commands ###

+ $20 request-done ( ureq -- )
  signal request is completed
+ $21 set-cookie ( utimestamp -- )
  cookies and round trip delays
+ $22 punch-load, ( $:string -- )
  use for punch payload: nest it
+ $23 punch ( $:string -- )
  punch NAT traversal hole
+ $24 punch-done ( -- )
  punch received

### connection setup commands ###

+ $30 tmpnest ( $:string -- )
  nested (temporary encrypted) command
+ $31 encnest ( $:string -- )
  nested (completely encrypted) command
+ $32 close-tmpnest ( -- )
  cose a opened tmpnest, and add the necessary stuff
+ $33 close-encnest ( -- )
  cose a opened encnest, and add the necessary stuff
+ $34 new-data ( addr addr u -- )
  create new data mapping
+ $35 new-code ( addr addr u -- )
  crate new code mapping
+ $36 store-key ( $:string -- )
  store key
+ $37 map-request ( addrs ucode udata -- )
  request mapping
+ $38 set-tick ( uticks -- )
  adjust time
+ $39 get-tick ( -- )
  request time adjust
+ $3A receive-tmpkey ( $:key -- )
  receive emphemeral key
+ $3B tmpkey-request ( -- )
  request ephemeral key
+ $3C keypair ( $:yourkey $:mykey -- )
  select a pubkey
+ $3D update-key ( -- )
  update secrets
+ $3E gen-ivs ( $:string -- )
  generate IVs
+ $3F addr-key! ( $:string -- )
  set key for reply
+ $40 punch? ( -- )
  Request punch addresses
+ $41 >time-offset ( n -- )
  set time offset
+ $42 context ( -- )
  make context active
+ $43 gen-reply ( -- )
  generate a key request reply
+ $44 gen-punch-reply ( -- )
+ $45 invite ( $:nick+sig $:pk -- )
  invite someone
+ $46 request-invitation ( -- )
  ask for an invitation as second stage of invitation handshake
+ $47 sign-invite ( $:signature -- )
  send you a signature
+ $48 request-qr-invitation ( -- )
  ask for an invitation as second stage of invitation handshake
+ $49 tmp-secret, ( -- )
+ $4A qr-challenge ( $:challenge $:respose -- )
+ $4B invite-result ( flag -- )

### connection commands ###

+ $25 disconnect ( -- )
  close connection
+ $26 set-ip ( $:string -- )
  set address information
+ $27 get-ip ( -- )
  request address information
+ $28 set-blocksize ( n -- )
  set blocksize to 2^n
+ $29 set-blockalign ( n -- )
  set block alignment to 2^n
+ $2A close-all ( -- )
  close all files
+ $2B set-top ( utop flag -- )
  set top, flag is true when all data is sent
+ $2C slurp ( -- )
  slurp in tracked files
+ $2D ack-reset ( -- )
  reset ack state

### file commands ###

+ $30 file-id ( uid -- o:file )
  choose a file object
+ $20 open-file ( $:string mode -- )
  open file with mode
+ $21 file-type ( n -- )
  choose file type
+ $22 close-file ( -- )
  close file
+ $23 set-size ( size -- )
  set size attribute of current file
+ $24 set-seek ( useek -- )
  set seek attribute of current file
+ $25 set-limit ( ulimit -- )
  set limit attribute of current file
+ $26 set-stat ( umtime umod -- )
  set time and mode of current file
+ $27 get-size ( -- )
  request file size
+ $28 get-stat ( -- )
  request stat of current file
+ $29 set-form ( w h -- )
  if file is a terminal, set size
+ $2A get-form ( -- )
  if file is a terminal, request size
+ $2B poll-request ( ulimit -- )
  poll a file to check for size changes

### ack commands ###

+ $31 ack ( -- o:acko )
  ack object
+ $20 ack-addrtime ( utime addr -- )
  packet at addr received at time
+ $21 ack-resend ( flag -- )
  set resend toggle flag
+ $22 set-rate ( urate udelta-t -- )
  set rate 
+ $23 resend-mask ( addr umask -- )
  resend mask blocks starting at addr
+ $24 track-timing ( -- )
  track timing
+ $25 rec-timing ( $:string -- )
  recorded timing
+ $26 send-timing ( -- )
  request recorded timing
+ $27 ack-b2btime ( utime addr -- )
  burst-to-burst time at packet addr
+ $28 ack-resend# ( addr $:string -- )
  resend numbers
+ $29 ack-flush ( addr -- )
  flushed to addr
+ $2C set-rtdelay ( ticks -- )
  set round trip delay only
+ $2D seq# ( n -- )
  set the ack number and check for smaller

### log commands ###

+ $19 log-token ( $:token n -- )
+ $20 emit ( utf8 -- )
  emit character on server log
+ $21 type ( $:string -- )
  type string on server log
+ $22 cr ( -- )
  newline on server log
+ $23 . ( n -- )
  print number on server log
+ $24 f. ( r -- )
  print fp number on server log
+ $25 .time ( -- )
  print timer to server log
+ $26 !time ( -- )
  start timer
+ $32 log ( -- o:log )
  free all parts of the subkey

### key storage commands ###
+ $2 slit ( #lit -- )
  deprecated slit version
+ $F kversion ( $:string -- )
  key version
+ $11 privkey ( $:string -- )
  private key
+ $12 keytype ( n -- )
  key type (0: anon, 1: user, 2: group)
+ $13 keynick ( $:string -- )
  key nick
+ $14 keyprofile ( $:string -- )
  key profile (hash of a resource)
+ $15 keymask ( x -- )
  key access right mask
+ $16 keygroups ( $:groups -- )
  access groups
+ $17 +keysig ( $:string -- )
  add a key signature
+ $18 keyimport ( n -- )
+ $19 rskkey ( $:string --- )
  revoke key, temporarily stored
+ $1A keypet ( $:string -- )
+ $1B walletkey ( $:seed -- )
+ $1C avatar ( $:string -- )
  key profile (hash of a resource)
  read a nested key into sample-key

### address commands ###

+ $11 addr-pri# ( n -- )
  priority
+ $12 addr-id ( $:id -- )
  unique host id string
+ $13 addr-anchor ( $:pubkey -- )
  anchor for routing further
+ $14 addr-ipv4 ( n -- )
  ip address
+ $15 addr-ipv6 ( $:ipv6 -- )
  ipv6 address
+ $16 addr-portv4 ( n -- )
  ipv4 port
+ $17 addr-portv6 ( n -- )
  ipv6 port
+ $18 addr-port ( n -- )
  ip port, both protocols
+ $19 addr-route ( $:net2o -- )
  net2o routing part
+ $1A addr-key ( $:addr -- )
  key for connection setup
+ $1B addr-revoke ( $:revoke -- )
  revocation info
+ $1C addr-ekey ( $:ekey timeout -- )
  ephemeral key

### dht commands ###

+ $33 dht-id ( $:string -- o:o )
  set DHT id for further operations on it
+ $20 dht-host+ ( $:string -- )
  add host to DHT
+ $21 dht-host- ( $:string -- )
  delete host from DHT
+ $22 dht-host? ( -- )
  query DHT host
+ $23 dht-tags+ ( $:string -- )
  add tags to DHT
+ $24 dht-tags- ( $:string -- )
  delete tags from DHT
+ $25 dht-tags? ( -- )
  query DHT tags
+ $26 dht-owner+ ( $:string -- )
  add owner to DHT
+ $27 dht-owner- ( $:string -- )
  delete owner from DHT
+ $28 dht-owner? ( -- )
  query DHT owner
+ $29 dht-have+ ( $:string -- )
  add have to DHT
+ $2A dht-have- ( $:string -- )
  delete have from DHT
+ $2B dht-have? ( -- )
  query DHT have

### vault commands ###

+ $20 dhe ( $:pubkey -- )
  start diffie hellman exchange
+ $21 vault-keys ( $:keys -- )
  vault keys can be opened with the dhe secret; each key is IV+session key+checksum
+ $22 vault-file ( $:content -- )
  this is the actual content of the vault
  if blockwise, there may be multiple parts
+ $23 vault-sig ( $:sig -- )
  the signature of the vault, using the keyed hash over the file
+ $24 vault-crypt ( n -- )
  set encryption mode and key wrap size
+ $25 vault-auth ( $:auth -- )
  block authentication, 64 byte block

### message commands ###

+ $20 msg-start ( $:pksig -- )
  start message
+ $21 msg-tag ( $:tag -- )
  tagging (can be anywhere)
+ $22 msg-id ( $:id -- )
  a hash id
+ $23 msg-chain ( $:dates,sighash -- )
  chained to message[s]
+ $24 msg-signal ( $:pubkey -- )
  signal message to one person
+ $25 msg-re ( $:hash )
  relate to some object
+ $26 msg-text ( $:msg -- )
  specify message string
+ $27 msg-object ( $:object type -- )
  specify an object, e.g. an image
+ $28 msg-action ( $:msg -- )
  specify action string
+ $29 msg-payment ( $:contract -- )
  payment transaction
+ $2A msg-otrify ( $:date+sig $:newdate+sig -- )
  turn a past message into OTR
+ $2B msg-coord ( $:gps -- )
  GPS coordinates
+ $2C msg-url ( $:url -- )
  specify message URL
+ $2D msg-like ( xchar -- )
  add a like
### group description commands ###
+ $20 group-name ( $:name -- )
  group symbolic name
+ $21 group-id ( $:group -- )
  group id, is a pubkey
+ $22 group-member ( $:memberkey -- )
  add member key
+ $23 group-admin ( $:adminkey -- )
  set admin key
+ $24 group-perms ( 64u -- )
  permission/modes bitmask

### messaging commands ###

+ $34 message ( -- o:msg )
  push a message object
+ $21 msg-group ( $:group -- )
  set group
+ $22 msg-join ( $:group -- )
  join a chat group
+ $23 msg-leave ( $:group -- )
  leave a chat group
+ $24 msg-reconnect ( $:pubkey+addr -- )
  rewire distribution tree
+ $25 msg-last? ( start end n -- )
+ $26 msg-last ( $:[tick0,msgs,..tickn] n -- )
+ $A msg-nestsig ( $:cmd+sig -- )
  check sig+nest

### DVCS patch commands ###

DVCS metadata is stored in messages, containing message text, refs
and patchset objects. Patchset objects are constructed in a way
that makes identical transactions have the same hash.

+ $20 dvcs-read ( $:hash -- )
  read in an object
+ $21 dvcs-rm ( $:hash+name -- )
  delete file
+ $22 dvcs-rmdir ( $:name -- )
  delete directory
+ $23 dvcs-patch ( $:diff len -- )
  apply patch, len is the size of the result
+ $24 dvcs-write ( $:perm+name size -- )
  write out file
+ $25 dvcs-unzip ( $:diffgz size algo -- $:diff )
  unzip an object
+ $26 dvcs-ref ( $:hash+perm+name -- )
  external hash reference

### payment commands ###

+ $20 pay-source ( $:source -- )
  source, pk[+hash] for lookup
+ $21 pay-sink ( n $:sig -- )
  sink, signature
+ $22 pay-asset ( asset -- )
  select global asset type
+ $23 pay-obligation ( $:enc-asset -- )
  select per-contract obligation
+ $24 pay-amount ( 64amount -- )
  add/subtract amount to current asset
+ $25 pay-damount ( 128amount -- )
  add/subtract 128 bit amount
+ $26 pay-comment ( $:enc-comment -- )
  comment, encrypted for selected key
+ $27 pay-balance ( u -- )
  select&balance asset
+ $28 pay-#source ( u -- )
  select source

### Contracts ###

Contracts are state changes to wallets.  A serialized wallet is a contract
that contains all the changes from an empty wallet to fill it; it is not
checked for balance.

A dumb contract is checked for balance.  It consists of several selectors
(source/account, asset), transactions (amounts added or subtracted from an
asset), comments (encoded for the receiver, with a ephermeral pubkey as
start and a HMAC as end). Comments are fixed 64 bytes, either plain text or
hashes to files.  Transactions have to balance, which is facilitated with
the balance command, which balances the selected asset.

The signature of a contract signs the wallet's state (serialized in
normalized form) after the contract has been executed.  The current
contract's hash is part of the serialization.







|

|

|

|

|

|

|
|

|

|

|

|

|

|

|

|




|

|

|

|

|

|

|

|

|

|

|




|

|

|

|

|




|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|

|
|

|

|

|

|
|
|



|

|

|

|

|

|

|

|

|




|

|

|

|

|

|

|

|

|

|

|

|

|




|

|

|

|

|

|

|

|

|

|

|

|

|




|
|

|

|

|

|

|

|

|



|

|

|

|

|

|

|

|

|

|
|

|
|
|





|

|

|

|

|

|

|

|

|

|

|

|




|

|

|

|

|

|

|

|

|

|

|

|

|




|

|

|


|

|

|




|

|

|

|

|

|

|

|

|

|

|

|

|

|


|

|

|

|

|




|

|

|

|

|

|
|
|








|

|

|

|

|

|

|




|

|

|

|

|

|

|

|

|



>



>






>



20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467

## List of Commands ##

Commands are context-sensitive in an OOP method hierarchy sense.

### base commands ###

* $0 end-cmd ( -- )
  end command buffer
* $1 lit ( #u -- u )
  literal
* $2 -lit ( #n -- n )
  negative literal, inverted encoded
* $3 string ( #string -- $:string )
  string literal
* $4 flit ( #dfloat -- r )
  double float literal
* $5 end-with ( o:object -- )
  end scope
* $6 oswap ( o:nest o:current -- o:current o:nest )
* $7 tru ( -- f:true )
  true flag literal
* $8 fals ( -- f:false )
  false flag literal
* $9 words ( ustart -- )
  reflection
* $A nestsig ( $:cmd+sig -- )
  check sig+nest
* $B secstring ( #string -- $:string )
  secret string literal
* $C nop ( -- )
  do nothing
* $D 4cc ( #3letter -- )
  At the beginning of a file, this can be used as FourCC code
* $E padding ( #len -- )
  add padding to align fields
* $F version ( $:version -- )
  version check

### reply commands ###

* $10 push' ( #cmd -- )
  push command into answer packet
* $11 push-lit ( u -- )
  push unsigned literal into answer packet
* $13 push-$ ( $:string -- )
  push string into answer packet
* $14 push-float ( r -- )
  push floating point number
* $15 ok ( utag -- )
  tagged response
* $16 ok? ( utag -- )
  request tagged response
* $17 ko ( uerror -- )
  receive error message
* $18 nest ( $:string -- )
  nested (self-encrypted) command
* $19 token ( $:token n -- )
  generic inspection token
* $1A error-id ( $:errorid -- )
  error-id string
* $1B version? ( $:version -- )
  version cross-check

### connection generic commands ###

* $20 request-done ( ureq -- )
  signal request is completed
* $21 set-cookie ( utimestamp -- )
  cookies and round trip delays
* $22 punch-load, ( $:string -- )
  use for punch payload: nest it
* $23 punch ( $:string -- )
  punch NAT traversal hole
* $24 punch-done ( -- )
  punch received

### connection setup commands ###

* $30 tmpnest ( $:string -- )
  nested (temporary encrypted) command
* $31 encnest ( $:string -- )
  nested (completely encrypted) command
* $32 close-tmpnest ( -- )
  cose a opened tmpnest, and add the necessary stuff
* $33 close-encnest ( -- )
  cose a opened encnest, and add the necessary stuff
* $34 new-data ( addr addr u -- )
  create new data mapping
* $35 new-code ( addr addr u -- )
  crate new code mapping
* $36 store-key ( $:string -- )
  store key
* $37 map-request ( addrs ucode udata -- )
  request mapping
* $38 set-tick ( uticks -- )
  adjust time
* $39 get-tick ( -- )
  request time adjust
* $3A receive-tmpkey ( $:key -- )
  receive emphemeral key
* $3B tmpkey-request ( -- )
  request ephemeral key
* $3C keypair ( $:yourkey $:mykey -- )
  select a pubkey
* $3D update-key ( -- )
  update secrets
* $3E gen-ivs ( $:string -- )
  generate IVs
* $3F addr-key! ( $:string -- )
  set key for reply
* $40 punch? ( -- )
  Request punch addresses
* $41 >time-offset ( n -- )
  set time offset
* $42 context ( -- )
  make context active
* $43 gen-reply ( -- )
  generate a key request reply
* $44 gen-punch-reply ( -- )
* $45 invite ( $:nick+sig $:pk -- )
  invite someone
* $46 request-invitation ( -- )
  ask for an invitation as second stage of invitation handshake
* $47 sign-invite ( $:signature -- )
  send you a signature
* $48 request-qr-invitation ( -- )
  ask for an invitation as second stage of invitation handshake
* $49 tmp-secret, ( -- )
* $4A qr-challenge ( $:challenge $:respose -- )
* $4B invite-result ( flag -- )

### connection commands ###

* $25 disconnect ( -- )
  close connection
* $26 set-ip ( $:string -- )
  set address information
* $27 get-ip ( -- )
  request address information
* $28 set-blocksize ( n -- )
  set blocksize to 2^n
* $29 set-blockalign ( n -- )
  set block alignment to 2^n
* $2A close-all ( -- )
  close all files
* $2B set-top ( utop flag -- )
  set top, flag is true when all data is sent
* $2C slurp ( -- )
  slurp in tracked files
* $2D ack-reset ( -- )
  reset ack state

### file commands ###

* $30 file-id ( uid -- o:file )
  choose a file object
* $20 open-file ( $:string mode -- )
  open file with mode
* $21 file-type ( n -- )
  choose file type
* $22 close-file ( -- )
  close file
* $23 set-size ( size -- )
  set size attribute of current file
* $24 set-seek ( useek -- )
  set seek attribute of current file
* $25 set-limit ( ulimit -- )
  set limit attribute of current file
* $26 set-stat ( umtime umod -- )
  set time and mode of current file
* $27 get-size ( -- )
  request file size
* $28 get-stat ( -- )
  request stat of current file
* $29 set-form ( w h -- )
  if file is a terminal, set size
* $2A get-form ( -- )
  if file is a terminal, request size
* $2B poll-request ( ulimit -- )
  poll a file to check for size changes

### ack commands ###

* $31 ack ( -- o:acko )
  ack object
* $20 ack-addrtime ( utime addr -- )
  packet at addr received at time
* $21 ack-resend ( flag -- )
  set resend toggle flag
* $22 set-rate ( urate udelta-t -- )
  set rate 
* $23 resend-mask ( addr umask -- )
  resend mask blocks starting at addr
* $24 track-timing ( -- )
  track timing
* $25 rec-timing ( $:string -- )
  recorded timing
* $26 send-timing ( -- )
  request recorded timing
* $27 ack-b2btime ( utime addr -- )
  burst-to-burst time at packet addr
* $28 ack-resend# ( addr $:string -- )
  resend numbers
* $29 ack-flush ( addr -- )
  flushed to addr
* $2C set-rtdelay ( ticks -- )
  set round trip delay only
* $2D seq# ( n -- )
  set the ack number and check for smaller

### log commands ###

* $19 log-token ( $:token n -- )
* $20 emit ( utf8 -- )
  emit character on server log
* $21 type ( $:string -- )
  type string on server log
* $22 cr ( -- )
  newline on server log
* $23 . ( n -- )
  print number on server log
* $24 f. ( r -- )
  print fp number on server log
* $25 .time ( -- )
  print timer to server log
* $26 !time ( -- )
  start timer
* $32 log ( -- o:log )
  free all parts of the subkey

### key storage commands ###
* $2 slit ( #lit -- )
  deprecated slit version
* $F kversion ( $:string -- )
  key version
* $11 privkey ( $:string -- )
  private key
* $12 keytype ( n -- )
  key type (0: anon, 1: user, 2: group)
* $13 keynick ( $:string -- )
  key nick
* $14 keyprofile ( $:string -- )
  key profile (hash of a resource)
* $15 keymask ( x -- )
  key access right mask
* $16 keygroups ( $:groups -- )
  access groups
* $17 +keysig ( $:string -- )
  add a key signature
* $18 keyimport ( n -- )
* $19 rskkey ( $:string --- )
  revoke key, temporarily stored
* $1A keypet ( $:string -- )
* $1B walletkey ( $:seed -- )
* $1C avatar ( $:string -- )
  key profile (hash of a resource)
  read a nested key into sample-key

### address commands ###

* $11 addr-pri# ( n -- )
  priority
* $12 addr-id ( $:id -- )
  unique host id string
* $13 addr-anchor ( $:pubkey -- )
  anchor for routing further
* $14 addr-ipv4 ( n -- )
  ip address
* $15 addr-ipv6 ( $:ipv6 -- )
  ipv6 address
* $16 addr-portv4 ( n -- )
  ipv4 port
* $17 addr-portv6 ( n -- )
  ipv6 port
* $18 addr-port ( n -- )
  ip port, both protocols
* $19 addr-route ( $:net2o -- )
  net2o routing part
* $1A addr-key ( $:addr -- )
  key for connection setup
* $1B addr-revoke ( $:revoke -- )
  revocation info
* $1C addr-ekey ( $:ekey timeout -- )
  ephemeral key

### dht commands ###

* $33 dht-id ( $:string -- o:o )
  set DHT id for further operations on it
* $20 dht-host+ ( $:string -- )
  add host to DHT
* $21 dht-host- ( $:string -- )
  delete host from DHT
* $22 dht-host? ( -- )
  query DHT host
* $23 dht-tags+ ( $:string -- )
  add tags to DHT
* $24 dht-tags- ( $:string -- )
  delete tags from DHT
* $25 dht-tags? ( -- )
  query DHT tags
* $26 dht-owner+ ( $:string -- )
  add owner to DHT
* $27 dht-owner- ( $:string -- )
  delete owner from DHT
* $28 dht-owner? ( -- )
  query DHT owner
* $29 dht-have+ ( $:string -- )
  add have to DHT
* $2A dht-have- ( $:string -- )
  delete have from DHT
* $2B dht-have? ( -- )
  query DHT have

### vault commands ###

* $20 dhe ( $:pubkey -- )
  start diffie hellman exchange
* $21 vault-keys ( $:keys -- )
  vault keys can be opened with the dhe secret; each key is IV+session key+checksum
* $22 vault-file ( $:content -- )
  this is the actual content of the vault
  if blockwise, there may be multiple parts
* $23 vault-sig ( $:sig -- )
  the signature of the vault, using the keyed hash over the file
* $24 vault-crypt ( n -- )
  set encryption mode and key wrap size
* $25 vault-auth ( $:auth -- )
  block authentication, 64 byte block

### message commands ###

* $20 msg-start ( $:pksig -- )
  start message
* $21 msg-tag ( $:tag -- )
  tagging (can be anywhere)
* $22 msg-id ( $:id -- )
  a hash id
* $23 msg-chain ( $:dates,sighash -- )
  chained to message[s]
* $24 msg-signal ( $:pubkey -- )
  signal message to one person
* $25 msg-re ( $:hash )
  relate to some object
* $26 msg-text ( $:msg -- )
  specify message string
* $27 msg-object ( $:object type -- )
  specify an object, e.g. an image
* $28 msg-action ( $:msg -- )
  specify action string
* $29 msg-payment ( $:contract -- )
  payment transaction
* $2A msg-otrify ( $:date+sig $:newdate+sig -- )
  turn a past message into OTR
* $2B msg-coord ( $:gps -- )
  GPS coordinates
* $2C msg-url ( $:url -- )
  specify message URL
* $2D msg-like ( xchar -- )
  add a like
### group description commands ###
* $20 group-name ( $:name -- )
  group symbolic name
* $21 group-id ( $:group -- )
  group id, is a pubkey
* $22 group-member ( $:memberkey -- )
  add member key
* $23 group-admin ( $:adminkey -- )
  set admin key
* $24 group-perms ( 64u -- )
  permission/modes bitmask

### messaging commands ###

* $34 message ( -- o:msg )
  push a message object
* $21 msg-group ( $:group -- )
  set group
* $22 msg-join ( $:group -- )
  join a chat group
* $23 msg-leave ( $:group -- )
  leave a chat group
* $24 msg-reconnect ( $:pubkey+addr -- )
  rewire distribution tree
* $25 msg-last? ( start end n -- )
* $26 msg-last ( $:[tick0,msgs,..tickn] n -- )
* $A msg-nestsig ( $:cmd+sig -- )
  check sig+nest

### DVCS patch commands ###

DVCS metadata is stored in messages, containing message text, refs
and patchset objects. Patchset objects are constructed in a way
that makes identical transactions have the same hash.

* $20 dvcs-read ( $:hash -- )
  read in an object
* $21 dvcs-rm ( $:hash+name -- )
  delete file
* $22 dvcs-rmdir ( $:name -- )
  delete directory
* $23 dvcs-patch ( $:diff len -- )
  apply patch, len is the size of the result
* $24 dvcs-write ( $:perm+name size -- )
  write out file
* $25 dvcs-unzip ( $:diffgz size algo -- $:diff )
  unzip an object
* $26 dvcs-ref ( $:hash+perm+name -- )
  external hash reference

### payment commands ###

* $20 pay-source ( $:source -- )
  source, pk[+hash] for lookup
* $21 pay-sink ( n $:sig -- )
  sink, signature
* $22 pay-asset ( asset -- )
  select global asset type
* $23 pay-obligation ( $:enc-asset -- )
  select per-contract obligation
* $24 pay-amount ( 64amount -- )
  add/subtract amount to current asset
* $25 pay-damount ( 128amount -- )
  add/subtract 128 bit amount
* $26 pay-comment ( $:enc-comment -- )
  comment, encrypted for selected key
* $27 pay-balance ( u -- )
  select&balance asset
* $28 pay-#source ( u -- )
  select source

### Contracts ###

Contracts are state changes to wallets.  A serialized wallet is a contract
that contains all the changes from an empty wallet to fill it; it is not
checked for balance.

A dumb contract is checked for balance.  It consists of several selectors
(source/account, asset), transactions (amounts added or subtracted from an
asset), comments (encoded for the receiver, with a ephermeral pubkey as
start and a HMAC as end). Comments are fixed 64 bytes, either plain text or
hashes to files.  Transactions have to balance, which is facilitated with
the balance command, which balances the selected asset.

The signature of a contract signs the wallet's state (serialized in
normalized form) after the contract has been executed.  The current
contract's hash is part of the serialization.

Changes to wiki/ed25519.md.

128
129
130
131
132
133
134
135
136
137
To implement the necessary changes (add scalar multiplication with “constant”
execution time for the DHE, i.e. no secret dependent operation), I cloned
floodberry's ed25519-donna code and added autoconf stuff for build process, so
you need a

git clone [https://github.com/forthy42/ed25519-donna.git](https://github.com/forthy42/ed25519-donna.git)

and to compile&install it, just run ``./autogen.sh && make && sudo make
install``.  To install 32 bit libaries on a 64 bit system, run ``autogen.sh``
with ``CC="gcc -m32"``







|
|
|
128
129
130
131
132
133
134
135
136
137
To implement the necessary changes (add scalar multiplication with “constant”
execution time for the DHE, i.e. no secret dependent operation), I cloned
floodberry's ed25519-donna code and added autoconf stuff for build process, so
you need a

git clone [https://github.com/forthy42/ed25519-donna.git](https://github.com/forthy42/ed25519-donna.git)

and to compile&install it, just run `./autogen.sh && make && sudo make
install`.  To install 32 bit libaries on a 64 bit system, run `autogen.sh`
with `CC="gcc -m32"`

Changes to wiki/eu-dsgvo.md.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
..
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
..
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
..
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
...
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
...
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
...
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
...
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
...
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
...
624
625
626
627
628
629
630
631
632
633
634
# Datenschutzerklärung #

[→English](eu-gdpr.md)

## TL;DR ##

Tatsächliche Speicherung auf dieser Web-Site:

### Angaben gemäß § 13 TMG ###

Alle auf dieser Site erhobenen Daten werden in Deutschland gespeichert.  Das
bedeutet, dass alle Zugriffe vom
[BND](https://de.wikipedia.org/wiki/Bundesnachrichtendienst) mit
[XKeyscore](https://de.wikipedia.org/wiki/XKeyscore) am
[DE-CIX](https://de.wikipedia.org/wiki/DE-CIX) abgegriffen und verarbeitet
werden, und wenn sie einem
[Selektor](https://de.wikipedia.org/wiki/Selektor_%28Geheimdienstabfrage%29)
entsprechen, werden sie gespeichert und womöglich mit Partnerdiensten wie
beispielsweise der
[NSA](https://de.wikipedia.org/wiki/National_Security_Agency) und dem
[GCHQ](https://de.wikipedia.org/wiki/Government_Communications_Headquarters)
geteilt.  Durch Verschlüsselung allen Datenverkehrs minimieren wir die
................................................................................
abzuwenden.

Cookies werden nur gespeichert, wenn man sich im Fossil einloggt. Wenn man im
Fossil navigiert, kann man auch einen Cookie bekommen, abhängig davon, was man
tut.  Gleiches gilt für gitlab.

Tickets können anonym erstellt werden und händisch auf Anfrage wieder gelöscht
werden. Geben Sie keine privaten Informationen in das Ticket-System ein!

IP-Adressen werden auf 3 Bytes (IPv4) bzw. 5 Bytes (IPv6) verkürzt im Log
gespeichert. Die Logs werden nach 12 Wochen endgültig gelöscht.

Ankommende E-Mails mit sinnvollem Inhalt werden (wie üblich) dauerhaft
gespeichert, und zwar alle Informationen, die in der E-Mail drin sind. Wir
gehen davon aus, dass der Absender durch das Absenden uns das Recht dazu
gibt. E-Mail ist ein Store&Forward-Protokoll, d.h. auch alle Relays dazwischen
speichern die E-Mail zumindest temporär. Nein, wir delegieren E-Mail-Empfang
an keine dritte Partei, aber der E-Mail-Server des Senders kann dies tun. Es
wird auf jeden Fall stark empfohlen, E-Mail verschlüsselt (z.B. mit PGP) zu
schicken.

Wir senden keine Datenschutzbelehrung an die Absender ankommender E-Mails,
weil Absender gerade in Spam-Mails immer noch gefälscht werden, und der
unschuldige als Absender eingetragene nicht auch noch mit unserer
Datenschutzbelehrung zugespammt werden soll.

## Willkommen ##

Wir freuen uns sehr über Ihr Interesse an unserem Unternehmen. Datenschutz hat
einen besonders hohen Stellenwert für die Geschäftsleitung der net2o secure
................................................................................
Internetseite in Anspruch nehmen möchte, könnte jedoch eine Verarbeitung
personenbezogener Daten erforderlich werden. Ist die Verarbeitung
personenbezogener Daten erforderlich und besteht für eine solche Verarbeitung
keine gesetzliche Grundlage, holen wir generell eine Einwilligung der
betroffenen Person ein.

Die Verarbeitung personenbezogener Daten, beispielsweise des Namens, der
Anschrift, E-Mail-Adresse oder Telefonnummer einer betroffenen Person, erfolgt
stets im Einklang mit der Datenschutz-Grundverordnung und in Übereinstimmung
mit den für die net2o secure communication geltenden landesspezifischen
Datenschutzbestimmungen. Mittels dieser Datenschutzerklärung möchte unser
Unternehmen die Öffentlichkeit über Art, Umfang und Zweck der von uns
erhobenen, genutzten und verarbeiteten personenbezogenen Daten
informieren. Ferner werden betroffene Personen mittels dieser
Datenschutzerklärung über die ihnen zustehenden Rechte aufgeklärt.

................................................................................
Wegen, beispielsweise telefonisch, oder über net2o, unser sicheres
Kommunikationsprotokoll, an uns zu übermitteln.

## 1. Begriffsbestimmungen ##

Die Datenschutzerklärung der net2o secure communication beruht auf den
Begrifflichkeiten, die durch den Europäischen Richtlinien- und
Verordnungsgeber beim Erlass der Datenschutz-Grundverordnung (DS-GVO)
verwendet wurden. Unsere Datenschutzerklärung soll sowohl für die
Öffentlichkeit als auch für unsere Kunden und Geschäftspartner einfach lesbar
und verständlich sein. Um dies zu gewährleisten, möchten wir vorab die
verwendeten Begrifflichkeiten erläutern.

Wir verwenden in dieser Datenschutzerklärung unter anderem die folgenden
Begriffe:

### a)    personenbezogene Daten ###

Personenbezogene Daten sind alle Informationen, die sich auf eine
identifizierte oder identifizierbare natürliche Person (im Folgenden
„betroffene Person“) beziehen. Als identifizierbar wird eine natürliche Person
angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer
Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer
Online-Kennung oder zu einem oder mehreren besonderen Merkmalen, die Ausdruck
der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen,
kulturellen oder sozialen Identität dieser natürlichen Person sind,
identifiziert werden kann.

### b)    betroffene Person ###

Betroffene Person ist jede identifizierte oder identifizierbare natürliche
Person, deren personenbezogene Daten von dem für die Verarbeitung
Verantwortlichen verarbeitet werden.

### c)    Verarbeitung ###

Verarbeitung ist jeder mit oder ohne Hilfe automatisierter Verfahren
ausgeführte Vorgang oder jede solche Vorgangsreihe im Zusammenhang mit
personenbezogenen Daten wie das Erheben, das Erfassen, die Organisation, das
Ordnen, die Speicherung, die Anpassung oder Veränderung, das Auslesen, das
Abfragen, die Verwendung, die Offenlegung durch Übermittlung, Verbreitung oder
eine andere Form der Bereitstellung, den Abgleich oder die Verknüpfung, die
Einschränkung, das Löschen oder die Vernichtung.

### d)    Einschränkung der Verarbeitung ###

Einschränkung der Verarbeitung ist die Markierung gespeicherter
personenbezogener Daten mit dem Ziel, ihre künftige Verarbeitung
einzuschränken.

### e)    Profiling ###

Profiling ist jede Art der automatisierten Verarbeitung personenbezogener
Daten, die darin besteht, dass diese personenbezogenen Daten verwendet werden,
um bestimmte persönliche Aspekte, die sich auf eine natürliche Person
beziehen, zu bewerten, insbesondere, um Aspekte bezüglich Arbeitsleistung,
wirtschaftlicher Lage, Gesundheit, persönlicher Vorlieben, Interessen,
Zuverlässigkeit, Verhalten, Aufenthaltsort oder Ortswechsel dieser natürlichen
Person zu analysieren oder vorherzusagen.

### f)     Pseudonymisierung ###

Pseudonymisierung ist die Verarbeitung personenbezogener Daten in einer Weise,
auf welche die personenbezogenen Daten ohne Hinzuziehung zusätzlicher
Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet
werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt
werden und technischen und organisatorischen Maßnahmen unterliegen, die
gewährleisten, dass die personenbezogenen Daten nicht einer identifizierten
oder identifizierbaren natürlichen Person zugewiesen werden.

### g)    Verantwortlicher oder für die Verarbeitung Verantwortlicher ###

Verantwortlicher oder für die Verarbeitung Verantwortlicher ist die natürliche
oder juristische Person, Behörde, Einrichtung oder andere Stelle, die allein
oder gemeinsam mit anderen über die Zwecke und Mittel der Verarbeitung von
personenbezogenen Daten entscheidet. Sind die Zwecke und Mittel dieser
Verarbeitung durch das Unionsrecht oder das Recht der Mitgliedstaaten
vorgegeben, so kann der Verantwortliche beziehungsweise können die bestimmten
Kriterien seiner Benennung nach dem Unionsrecht oder dem Recht der
Mitgliedstaaten vorgesehen werden.

### h)    Auftragsverarbeiter ###

Auftragsverarbeiter ist eine natürliche oder juristische Person, Behörde,
Einrichtung oder andere Stelle, die personenbezogene Daten im Auftrag des
Verantwortlichen verarbeitet.

### i)      Empfänger ###

Empfänger ist eine natürliche oder juristische Person, Behörde, Einrichtung
oder andere Stelle, der personenbezogene Daten offengelegt werden, unabhängig
davon, ob es sich bei ihr um einen Dritten handelt oder nicht. Behörden, die
im Rahmen eines bestimmten Untersuchungsauftrags nach dem Unionsrecht oder dem
Recht der Mitgliedstaaten möglicherweise personenbezogene Daten erhalten,
gelten jedoch nicht als Empfänger.

### j)      Dritter ###

Dritter ist eine natürliche oder juristische Person, Behörde, Einrichtung oder
andere Stelle außer der betroffenen Person, dem Verantwortlichen, dem
Auftragsverarbeiter und den Personen, die unter der unmittelbaren
Verantwortung des Verantwortlichen oder des Auftragsverarbeiters befugt sind,
die personenbezogenen Daten zu verarbeiten.

### k)    Einwilligung ###

Einwilligung ist jede von der betroffenen Person freiwillig für den bestimmten
Fall in informierter Weise und unmissverständlich abgegebene Willensbekundung
in Form einer Erklärung oder einer sonstigen eindeutigen bestätigenden
Handlung, mit der die betroffene Person zu verstehen gibt, dass sie mit der
Verarbeitung der sie betreffenden personenbezogenen Daten einverstanden ist.

## 2. Name und Anschrift des für die Verarbeitung Verantwortlichen ##

Verantwortlicher im Sinne der Datenschutz-Grundverordnung, sonstiger in den Mitgliedstaaten der Europäischen Union geltenden Datenschutzgesetze und anderer Bestimmungen mit datenschutzrechtlichem Charakter ist die:

    Bernd Paysan
    net2o secure communication
    Wilbrechtstr. 85
    81477 München

    Deutschland

    Tel.: +𝟦𝟫‧𝟪𝟫‧𝟦𝟣 𝟣𝟧 𝟦𝟨 𝟧𝟧

    E-Mail: bernd (at) net2o (dot) de

    Website: net2o.de
	
	net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

## 3. Cookies ##

Die Internetseiten der net2o secure communication verwenden Cookies. Cookies
sind Textdateien, welche über einen Internetbrowser auf einem Computersystem
abgelegt und gespeichert werden.

Zahlreiche Internetseiten und Server verwenden Cookies. Viele Cookies
enthalten eine sogenannte Cookie-ID. Eine Cookie-ID ist eine eindeutige
Kennung des Cookies. Sie besteht aus einer Zeichenfolge, durch welche
Internetseiten und Server dem konkreten Internetbrowser zugeordnet werden
können, in dem das Cookie gespeichert wurde. Dies ermöglicht es den besuchten
Internetseiten und Servern, den individuellen Browser der betroffenen Person
von anderen Internetbrowsern, die andere Cookies enthalten, zu
unterscheiden. Ein bestimmter Internetbrowser kann über die eindeutige
Cookie-ID wiedererkannt und identifiziert werden.

Durch den Einsatz von Cookies kann die net2o secure communication den Nutzern
dieser Internetseite nutzerfreundlichere Services bereitstellen, die ohne die
Cookie-Setzung nicht möglich wären.

Mittels eines Cookies können die Informationen und Angebote auf unserer
Internetseite im Sinne des Benutzers optimiert werden. Cookies ermöglichen
uns, wie bereits erwähnt, die Benutzer unserer Internetseite
wiederzuerkennen. Zweck dieser Wiedererkennung ist es, den Nutzern die
Verwendung unserer Internetseite zu erleichtern. Der Benutzer einer
Internetseite, die Cookies verwendet, muss beispielsweise nicht bei jedem
Besuch der Internetseite erneut seine Zugangsdaten eingeben, weil dies von der
Internetseite und dem auf dem Computersystem des Benutzers abgelegten Cookie
übernommen wird. Ein weiteres Beispiel ist das Cookie eines Warenkorbes im
Online-Shop. Der Online-Shop merkt sich die Artikel, die ein Kunde in den
virtuellen Warenkorb gelegt hat, über ein Cookie.

Die betroffene Person kann die Setzung von Cookies durch unsere Internetseite
jederzeit mittels einer entsprechenden Einstellung des genutzten
Internetbrowsers verhindern und damit der Setzung von Cookies dauerhaft
widersprechen. Ferner können bereits gesetzte Cookies jederzeit über einen
Internetbrowser oder andere Softwareprogramme gelöscht werden. Dies ist in
allen gängigen Internetbrowsern möglich. Deaktiviert die betroffene Person die
Setzung von Cookies in dem genutzten Internetbrowser, sind unter Umständen
nicht alle Funktionen unserer Internetseite vollumfänglich nutzbar.

## 3a. HSTS & HPKP ##

Wir weisen Ihren Browser beim Besuch unserer Webseiten an, sich zu merken,
dass diese Webseiten nur verschlüsselt erreichbar sind, und mit welchem
Schlüssel dies geschieht. Diese Information speichert ihr Browser und wird bei
einem späteren Zugriff nicht mehr versuchen, eine unverschlüsselte Verbindung
herzustellen. Zur Löschung dieser Information konsultieren Sie bitte die
Anleitung Ihres Browsers.
................................................................................
eine Reihe von allgemeinen Daten und Informationen. Diese allgemeinen Daten
und Informationen werden in den Logfiles des Servers gespeichert. Erfasst
werden können die (1) verwendeten Browsertypen und Versionen, (2) das vom
zugreifenden System verwendete Betriebssystem, (3) die Internetseite, von
welcher ein zugreifendes System auf unsere Internetseite gelangt (sogenannte
Referrer), (4) die Unterwebseiten, welche über ein zugreifendes System auf
unserer Internetseite angesteuert werden, (5) das Datum und die Uhrzeit eines
Zugriffs auf die Internetseite, (6) eine Internet-Protokoll-Adresse
(IP-Adresse), (7) der Internet-Service-Provider des zugreifenden Systems und
(8) sonstige ähnliche Daten und Informationen, die der Gefahrenabwehr im Falle
von Angriffen auf unsere informationstechnologischen Systeme dienen.

Bei der Nutzung dieser allgemeinen Daten und Informationen zieht die net2o
secure communication keine Rückschlüsse auf die betroffene Person. Diese
Informationen werden vielmehr benötigt, um (1) die Inhalte unserer
Internetseite korrekt auszuliefern, (2) die Inhalte unserer Internetseite
................................................................................
unserer Internetseite zu gewährleisten sowie (4) um Strafverfolgungsbehörden
im Falle eines Cyberangriffes die zur Strafverfolgung notwendigen
Informationen bereitzustellen. Diese anonym erhobenen Daten und Informationen
werden durch die net2o secure communication daher einerseits statistisch und
ferner mit dem Ziel ausgewertet, den Datenschutz und die Datensicherheit in
unserem Unternehmen zu erhöhen, um letztlich ein optimales Schutzniveau für
die von uns verarbeiteten personenbezogenen Daten sicherzustellen. Die
anonymen Daten der Server-Logfiles werden getrennt von allen durch eine
betroffene Person angegebenen personenbezogenen Daten gespeichert.

## 5. Routinemäßige Löschung und Sperrung von personenbezogenen Daten ##

Der für die Verarbeitung Verantwortliche verarbeitet und speichert
personenbezogene Daten der betroffenen Person nur für den Zeitraum, der zur
Erreichung des Speicherungszwecks erforderlich ist oder sofern dies durch den
................................................................................
und Verordnungsgeber oder einem anderen zuständigen Gesetzgeber
vorgeschriebene Speicherfrist ab, werden die personenbezogenen Daten
routinemäßig und entsprechend den gesetzlichen Vorschriften gesperrt oder
gelöscht.

## 6. Rechte der betroffenen Person ##

### a)    Recht auf Bestätigung ###

Jede betroffene Person hat das vom Europäischen Richtlinien- und
Verordnungsgeber eingeräumte Recht, von dem für die Verarbeitung
Verantwortlichen eine Bestätigung darüber zu verlangen, ob sie betreffende
personenbezogene Daten verarbeitet werden. Möchte eine betroffene Person
dieses Bestätigungsrecht in Anspruch nehmen, kann sie sich hierzu jederzeit an
einen Mitarbeiter des für die Verarbeitung Verantwortlichen wenden.

### b)    Recht auf Auskunft ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, jederzeit
von dem für die Verarbeitung Verantwortlichen unentgeltliche Auskunft über die
zu seiner Person gespeicherten personenbezogenen Daten und eine Kopie dieser
Auskunft zu erhalten. Ferner hat der Europäische Richtlinien- und
Verordnungsgeber der betroffenen Person Auskunft über folgende Informationen
zugestanden:

  + die Verarbeitungszwecke
  + die Kategorien personenbezogener Daten, die verarbeitet werden
  + die Empfänger oder Kategorien von Empfängern, gegenüber denen die
    personenbezogenen Daten offengelegt worden sind oder noch offengelegt
    werden, insbesondere
  + bei Empfängern in Drittländern oder bei internationalen Organisationen
    falls möglich die geplante Dauer, für die die personenbezogenen Daten
    gespeichert werden, oder, falls dies nicht möglich ist, die Kriterien für
    die Festlegung dieser Dauer
  + das Bestehen eines Rechts auf Berichtigung oder Löschung der sie
    betreffenden personenbezogenen Daten oder auf Einschränkung der
    Verarbeitung durch den Verantwortlichen oder eines Widerspruchsrechts
    gegen diese Verarbeitung
  + das Bestehen eines Beschwerderechts bei einer Aufsichtsbehörde
  + wenn die personenbezogenen Daten nicht bei der betroffenen Person erhoben
    werden: Alle verfügbaren Informationen über die Herkunft der Daten
  + das Bestehen einer automatisierten Entscheidungsfindung einschließlich
    Profiling gemäß Artikel 22 Abs.1 und 4 DS-GVO und — zumindest in diesen
    Fällen — aussagekräftige Informationen über die involvierte Logik sowie
    die Tragweite und die angestrebten Auswirkungen einer derartigen
    Verarbeitung für die betroffene Person

Ferner steht der betroffenen Person ein Auskunftsrecht darüber zu, ob
personenbezogene Daten an ein Drittland oder an eine internationale
Organisation übermittelt wurden. Sofern dies der Fall ist, so steht der
betroffenen Person im Übrigen das Recht zu, Auskunft über die geeigneten
Garantien im Zusammenhang mit der Übermittlung zu erhalten.

Möchte eine betroffene Person dieses Auskunftsrecht in Anspruch nehmen, kann
sie sich hierzu jederzeit an einen Mitarbeiter des für die Verarbeitung
Verantwortlichen wenden.

### c)    Recht auf Berichtigung ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, die
unverzügliche Berichtigung sie betreffender unrichtiger personenbezogener
Daten zu verlangen. Ferner steht der betroffenen Person das Recht zu, unter
Berücksichtigung der Zwecke der Verarbeitung, die Vervollständigung
unvollständiger personenbezogener Daten — auch mittels einer ergänzenden
Erklärung — zu verlangen.

Möchte eine betroffene Person dieses Berichtigungsrecht in Anspruch nehmen,
kann sie sich hierzu jederzeit an einen Mitarbeiter des für die Verarbeitung
Verantwortlichen wenden.

### d)    Recht auf Löschung (Recht auf Vergessen werden) ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, von dem
Verantwortlichen zu verlangen, dass die sie betreffenden personenbezogenen
Daten unverzüglich gelöscht werden, sofern einer der folgenden Gründe zutrifft
und soweit die Verarbeitung nicht erforderlich ist:

  + Die personenbezogenen Daten wurden für solche Zwecke erhoben oder auf
    sonstige Weise verarbeitet, für welche sie nicht mehr notwendig sind.
  + Die betroffene Person widerruft ihre Einwilligung, auf die sich die
    Verarbeitung gemäß Art. 6 Abs. 1 Buchstabe a DS-GVO oder Art. 9 Abs. 2
    Buchstabe a DS-GVO stützte, und es fehlt an einer anderweitigen
    Rechtsgrundlage für die Verarbeitung.
  + Die betroffene Person legt gemäß Art. 21 Abs. 1 DS-GVO Widerspruch gegen
    die Verarbeitung ein, und es liegen keine vorrangigen berechtigten Gründe
    für die Verarbeitung vor, oder die betroffene Person legt gemäß Art. 21
    Abs. 2 DS-GVO Widerspruch gegen die Verarbeitung ein.
  + Die personenbezogenen Daten wurden unrechtmäßig verarbeitet.
  + Die Löschung der personenbezogenen Daten ist zur Erfüllung einer
    rechtlichen Verpflichtung nach dem Unionsrecht oder dem Recht der
    Mitgliedstaaten erforderlich, dem der Verantwortliche unterliegt.
  + Die personenbezogenen Daten wurden in Bezug auf angebotene Dienste der
    Informationsgesellschaft gemäß Art. 8 Abs. 1 DS-GVO erhoben.

Sofern einer der oben genannten Gründe zutrifft und eine betroffene Person die
Löschung von personenbezogenen Daten, die bei der net2o secure communication
gespeichert sind, veranlassen möchte, kann sie sich hierzu jederzeit an einen
Mitarbeiter des für die Verarbeitung Verantwortlichen wenden. Der Mitarbeiter
der net2o secure communication wird veranlassen, dass dem Löschverlangen
unverzüglich nachgekommen wird.

Wurden die personenbezogenen Daten von der net2o secure communication
öffentlich gemacht und ist unser Unternehmen als Verantwortlicher gemäß
Art. 17 Abs. 1 DS-GVO zur Löschung der personenbezogenen Daten verpflichtet,
so trifft die net2o secure communication unter Berücksichtigung der
verfügbaren Technologie und der Implementierungskosten angemessene Maßnahmen,
auch technischer Art, um andere für die Datenverarbeitung Verantwortliche,
welche die veröffentlichten personenbezogenen Daten verarbeiten, darüber in
Kenntnis zu setzen, dass die betroffene Person von diesen anderen für die
Datenverarbeitung Verantwortlichen die Löschung sämtlicher Links zu diesen
personenbezogenen Daten oder von Kopien oder Replikationen dieser
personenbezogenen Daten verlangt hat, soweit die Verarbeitung nicht
erforderlich ist. Der Mitarbeiter der net2o secure communication wird im
Einzelfall das Notwendige veranlassen.

### e)    Recht auf Einschränkung der Verarbeitung ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, von dem
Verantwortlichen die Einschränkung der Verarbeitung zu verlangen, wenn eine
der folgenden Voraussetzungen gegeben ist:

  + Die Richtigkeit der personenbezogenen Daten wird von der betroffenen
    Person bestritten, und zwar für eine Dauer, die es dem Verantwortlichen
    ermöglicht, die Richtigkeit der personenbezogenen Daten zu überprüfen.
  + Die Verarbeitung ist unrechtmäßig, die betroffene Person lehnt die
    Löschung der personenbezogenen Daten ab und verlangt stattdessen die
    Einschränkung der Nutzung der personenbezogenen Daten.
  + Der Verantwortliche benötigt die personenbezogenen Daten für die Zwecke
    der Verarbeitung nicht länger, die betroffene Person benötigt sie jedoch
    zur Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen.
  + Die betroffene Person hat Widerspruch gegen die Verarbeitung gem. Art. 21
    Abs. 1 DS-GVO eingelegt und es steht noch nicht fest, ob die berechtigten
    Gründe des Verantwortlichen gegenüber denen der betroffenen Person
    überwiegen.

Sofern eine der oben genannten Voraussetzungen gegeben ist und eine betroffene
Person die Einschränkung von personenbezogenen Daten, die bei der net2o secure
communication gespeichert sind, verlangen möchte, kann sie sich hierzu
jederzeit an einen Mitarbeiter des für die Verarbeitung Verantwortlichen
wenden. Der Mitarbeiter der net2o secure communication wird die Einschränkung
der Verarbeitung veranlassen.

### f)     Recht auf Datenübertragbarkeit ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, die sie
betreffenden personenbezogenen Daten, welche durch die betroffene Person einem
Verantwortlichen bereitgestellt wurden, in einem strukturierten, gängigen und
maschinenlesbaren Format zu erhalten. Sie hat außerdem das Recht, diese Daten
einem anderen Verantwortlichen ohne Behinderung durch den Verantwortlichen,
dem die personenbezogenen Daten bereitgestellt wurden, zu übermitteln, sofern
die Verarbeitung auf der Einwilligung gemäß Art. 6 Abs. 1 Buchstabe a DS-GVO
oder Art. 9 Abs. 2 Buchstabe a DS-GVO oder auf einem Vertrag gemäß Art. 6
Abs. 1 Buchstabe b DS-GVO beruht und die Verarbeitung mithilfe automatisierter
Verfahren erfolgt, sofern die Verarbeitung nicht für die Wahrnehmung einer
Aufgabe erforderlich ist, die im öffentlichen Interesse liegt oder in Ausübung
öffentlicher Gewalt erfolgt, welche dem Verantwortlichen übertragen wurde.

Ferner hat die betroffene Person bei der Ausübung ihres Rechts auf
Datenübertragbarkeit gemäß Art. 20 Abs. 1 DS-GVO das Recht, zu erwirken, dass
die personenbezogenen Daten direkt von einem Verantwortlichen an einen anderen
Verantwortlichen übermittelt werden, soweit dies technisch machbar ist und
sofern hiervon nicht die Rechte und Freiheiten anderer Personen beeinträchtigt
werden.

Zur Geltendmachung des Rechts auf Datenübertragbarkeit kann sich die
betroffene Person jederzeit an einen Mitarbeiter der net2o secure
communication wenden.

### g)    Recht auf Widerspruch ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, aus
Gründen, die sich aus ihrer besonderen Situation ergeben, jederzeit gegen die
Verarbeitung sie betreffender personenbezogener Daten, die aufgrund von Art. 6
Abs. 1 Buchstaben e oder f DS-GVO erfolgt, Widerspruch einzulegen. Dies gilt
auch für ein auf diese Bestimmungen gestütztes Profiling.

Die net2o secure communication verarbeitet die personenbezogenen Daten im
Falle des Widerspruchs nicht mehr, es sei denn, wir können zwingende
schutzwürdige Gründe für die Verarbeitung nachweisen, die den Interessen,
Rechten und Freiheiten der betroffenen Person überwiegen, oder die
Verarbeitung dient der Geltendmachung, Ausübung oder Verteidigung von
................................................................................
Direktwerbung, so wird die net2o secure communication die personenbezogenen
Daten nicht mehr für diese Zwecke verarbeiten.

Zudem hat die betroffene Person das Recht, aus Gründen, die sich aus ihrer
besonderen Situation ergeben, gegen die sie betreffende Verarbeitung
personenbezogener Daten, die bei der net2o secure communication zu
wissenschaftlichen oder historischen Forschungszwecken oder zu statistischen
Zwecken gemäß Art. 89 Abs. 1 DS-GVO erfolgen, Widerspruch einzulegen, es sei
denn, eine solche Verarbeitung ist zur Erfüllung einer im öffentlichen
Interesse liegenden Aufgabe erforderlich.

Zur Ausübung des Rechts auf Widerspruch kann sich die betroffene Person direkt
jeden Mitarbeiter der net2o secure communication oder einen anderen
Mitarbeiter wenden. Der betroffenen Person steht es ferner frei, im
Zusammenhang mit der Nutzung von Diensten der Informationsgesellschaft,
ungeachtet der Richtlinie 2002/58/EG, ihr Widerspruchsrecht mittels
automatisierter Verfahren auszuüben, bei denen technische Spezifikationen
verwendet werden.

### h)    Automatisierte Entscheidungen im Einzelfall einschließlich Profiling ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, nicht einer
ausschließlich auf einer automatisierten Verarbeitung — einschließlich
Profiling — beruhenden Entscheidung unterworfen zu werden, die ihr gegenüber
rechtliche Wirkung entfaltet oder sie in ähnlicher Weise erheblich
beeinträchtigt, sofern die Entscheidung (1) nicht für den Abschluss oder die
................................................................................
Verantwortlichen, auf Darlegung des eigenen Standpunkts und auf Anfechtung der
Entscheidung gehört.

Möchte die betroffene Person Rechte mit Bezug auf automatisierte
Entscheidungen geltend machen, kann sie sich hierzu jederzeit an einen
Mitarbeiter des für die Verarbeitung Verantwortlichen wenden.

### i)      Recht auf Widerruf einer datenschutzrechtlichen Einwilligung ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, eine
Einwilligung zur Verarbeitung personenbezogener Daten jederzeit zu widerrufen.

Möchte die betroffene Person ihr Recht auf Widerruf einer Einwilligung geltend
machen, kann sie sich hierzu jederzeit an einen Mitarbeiter des für die
Verarbeitung Verantwortlichen wenden.

## 7. Rechtsgrundlage der Verarbeitung ##

Art. 6 I lit. a DS-GVO dient unserem Unternehmen als Rechtsgrundlage für
Verarbeitungsvorgänge, bei denen wir eine Einwilligung für einen bestimmten
Verarbeitungszweck einholen. Ist die Verarbeitung personenbezogener Daten zur
Erfüllung eines Vertrags, dessen Vertragspartei die betroffene Person ist,
erforderlich, wie dies beispielsweise bei Verarbeitungsvorgängen der Fall ist,
die für eine Lieferung von Waren oder die Erbringung einer sonstigen Leistung
oder Gegenleistung notwendig sind, so beruht die Verarbeitung auf Art. 6 I
lit. b DS-GVO. Gleiches gilt für solche Verarbeitungsvorgänge die zur
Durchführung vorvertraglicher Maßnahmen erforderlich sind, etwa in Fällen von
Anfragen zur unseren Produkten oder Leistungen. Unterliegt unser Unternehmen
einer rechtlichen Verpflichtung durch welche eine Verarbeitung von
personenbezogenen Daten erforderlich wird, wie beispielsweise zur Erfüllung
steuerlicher Pflichten, so basiert die Verarbeitung auf Art. 6 I lit. c
DS-GVO. In seltenen Fällen könnte die Verarbeitung von personenbezogenen Daten
erforderlich werden, um lebenswichtige Interessen der betroffenen Person oder
einer anderen natürlichen Person zu schützen. Dies wäre beispielsweise der
Fall, wenn ein Besucher in unserem Betrieb verletzt werden würde und daraufhin
sein Name, sein Alter, seine Krankenkassendaten oder sonstige lebenswichtige
Informationen an einen Arzt, ein Krankenhaus oder sonstige Dritte
weitergegeben werden müssten. Dann würde die Verarbeitung auf Art. 6 I lit. d
DS-GVO beruhen. Letztlich könnten Verarbeitungsvorgänge auf Art. 6 I lit. f
DS-GVO beruhen. Auf dieser Rechtsgrundlage basieren Verarbeitungsvorgänge, die
von keiner der vorgenannten Rechtsgrundlagen erfasst werden, wenn die
Verarbeitung zur Wahrung eines berechtigten Interesses unseres Unternehmens
oder eines Dritten erforderlich ist, sofern die Interessen, Grundrechte und
Grundfreiheiten des Betroffenen nicht überwiegen. Solche Verarbeitungsvorgänge
sind uns insbesondere deshalb gestattet, weil sie durch den Europäischen
Gesetzgeber besonders erwähnt wurden. Er vertrat insoweit die Auffassung, dass
ein berechtigtes Interesse anzunehmen sein könnte, wenn die betroffene Person
ein Kunde des Verantwortlichen ist (Erwägungsgrund 47 Satz 2 DS-GVO).

## 8. Berechtigte Interessen an der Verarbeitung, die von dem Verantwortlichen oder einem Dritten verfolgt werden ##

Basiert die Verarbeitung personenbezogener Daten auf Artikel 6 I lit. f DS-GVO
ist unser berechtigtes Interesse die Durchführung unserer Geschäftstätigkeit
zugunsten des Wohlergehens all unserer Mitarbeiter und unserer Anteilseigner.

## 9. Dauer, für die die personenbezogenen Daten gespeichert werden ##

Das Kriterium für die Dauer der Speicherung von personenbezogenen Daten ist
die jeweilige gesetzliche Aufbewahrungsfrist. Nach Ablauf der Frist werden die
................................................................................
Nichtbereitstellung der personenbezogenen Daten hätte.

## 11. Bestehen einer automatisierten Entscheidungsfindung ##

Als verantwortungsbewusstes Unternehmen verzichten wir auf eine automatische
Entscheidungsfindung oder ein Profiling.

Diese Datenschutzerklärung wurde durch den Datenschutzerklärungs-Generator der
DGD Deutsche Gesellschaft für Datenschutz GmbH, die als Externer
Datenschutzbeauftragter Fürth tätig ist, in Kooperation mit dem IT- und
Datenschutzrecht Anwalt Christian Solmecke erstellt.






|







|







 







|

|


|
|

|
|
|
|


|
|







 







|
|







 







|








|






|




|





|









|





|









|









|










|





|








|







|









|










|


|
|








|






|



|










|











|







 







|
|







 







|







 







|








|









|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|











|













|







|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|










|











|






|
|
|
|
|
|
|
|
|
|
|
|
|








|








|
|
|





|









|





|







 







|











|







 







|











|






|





|






|
|







|



|







 







|



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
..
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
..
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
..
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
...
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
...
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
...
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
...
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
...
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
...
624
625
626
627
628
629
630
631
632
633
634
# Datenschutzerklärung #

[→English](eu-gdpr.md)

## TL;DR ##

Tatsächliche Speicherung auf dieser WebSite:

### Angaben gemäß § 13 TMG ###

Alle auf dieser Site erhobenen Daten werden in Deutschland gespeichert.  Das
bedeutet, dass alle Zugriffe vom
[BND](https://de.wikipedia.org/wiki/Bundesnachrichtendienst) mit
[XKeyscore](https://de.wikipedia.org/wiki/XKeyscore) am
[DECIX](https://de.wikipedia.org/wiki/DE-CIX) abgegriffen und verarbeitet
werden, und wenn sie einem
[Selektor](https://de.wikipedia.org/wiki/Selektor_%28Geheimdienstabfrage%29)
entsprechen, werden sie gespeichert und womöglich mit Partnerdiensten wie
beispielsweise der
[NSA](https://de.wikipedia.org/wiki/National_Security_Agency) und dem
[GCHQ](https://de.wikipedia.org/wiki/Government_Communications_Headquarters)
geteilt.  Durch Verschlüsselung allen Datenverkehrs minimieren wir die
................................................................................
abzuwenden.

Cookies werden nur gespeichert, wenn man sich im Fossil einloggt. Wenn man im
Fossil navigiert, kann man auch einen Cookie bekommen, abhängig davon, was man
tut.  Gleiches gilt für gitlab.

Tickets können anonym erstellt werden und händisch auf Anfrage wieder gelöscht
werden. Geben Sie keine privaten Informationen in das TicketSystem ein!

IPAdressen werden auf 3 Bytes (IPv4) bzw. 5 Bytes (IPv6) verkürzt im Log
gespeichert. Die Logs werden nach 12 Wochen endgültig gelöscht.

Ankommende EMails mit sinnvollem Inhalt werden (wie üblich) dauerhaft
gespeichert, und zwar alle Informationen, die in der EMail drin sind. Wir
gehen davon aus, dass der Absender durch das Absenden uns das Recht dazu
gibt. EMail ist ein Store&ForwardProtokoll, d.h. auch alle Relays dazwischen
speichern die EMail zumindest temporär. Nein, wir delegieren E–Mail–Empfang
an keine dritte Partei, aber der EMailServer des Senders kann dies tun. Es
wird auf jeden Fall stark empfohlen, EMail verschlüsselt (z.B. mit PGP) zu
schicken.

Wir senden keine Datenschutzbelehrung an die Absender ankommender EMails,
weil Absender gerade in SpamMails immer noch gefälscht werden, und der
unschuldige als Absender eingetragene nicht auch noch mit unserer
Datenschutzbelehrung zugespammt werden soll.

## Willkommen ##

Wir freuen uns sehr über Ihr Interesse an unserem Unternehmen. Datenschutz hat
einen besonders hohen Stellenwert für die Geschäftsleitung der net2o secure
................................................................................
Internetseite in Anspruch nehmen möchte, könnte jedoch eine Verarbeitung
personenbezogener Daten erforderlich werden. Ist die Verarbeitung
personenbezogener Daten erforderlich und besteht für eine solche Verarbeitung
keine gesetzliche Grundlage, holen wir generell eine Einwilligung der
betroffenen Person ein.

Die Verarbeitung personenbezogener Daten, beispielsweise des Namens, der
Anschrift, EMailAdresse oder Telefonnummer einer betroffenen Person, erfolgt
stets im Einklang mit der DatenschutzGrundverordnung und in Übereinstimmung
mit den für die net2o secure communication geltenden landesspezifischen
Datenschutzbestimmungen. Mittels dieser Datenschutzerklärung möchte unser
Unternehmen die Öffentlichkeit über Art, Umfang und Zweck der von uns
erhobenen, genutzten und verarbeiteten personenbezogenen Daten
informieren. Ferner werden betroffene Personen mittels dieser
Datenschutzerklärung über die ihnen zustehenden Rechte aufgeklärt.

................................................................................
Wegen, beispielsweise telefonisch, oder über net2o, unser sicheres
Kommunikationsprotokoll, an uns zu übermitteln.

## 1. Begriffsbestimmungen ##

Die Datenschutzerklärung der net2o secure communication beruht auf den
Begrifflichkeiten, die durch den Europäischen Richtlinien- und
Verordnungsgeber beim Erlass der DatenschutzGrundverordnung (DSGVO)
verwendet wurden. Unsere Datenschutzerklärung soll sowohl für die
Öffentlichkeit als auch für unsere Kunden und Geschäftspartner einfach lesbar
und verständlich sein. Um dies zu gewährleisten, möchten wir vorab die
verwendeten Begrifflichkeiten erläutern.

Wir verwenden in dieser Datenschutzerklärung unter anderem die folgenden
Begriffe:

### a) personenbezogene Daten ###

Personenbezogene Daten sind alle Informationen, die sich auf eine
identifizierte oder identifizierbare natürliche Person (im Folgenden
„betroffene Person“) beziehen. Als identifizierbar wird eine natürliche Person
angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer
Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer
OnlineKennung oder zu einem oder mehreren besonderen Merkmalen, die Ausdruck
der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen,
kulturellen oder sozialen Identität dieser natürlichen Person sind,
identifiziert werden kann.

### b) betroffene Person ###

Betroffene Person ist jede identifizierte oder identifizierbare natürliche
Person, deren personenbezogene Daten von dem für die Verarbeitung
Verantwortlichen verarbeitet werden.

### c) Verarbeitung ###

Verarbeitung ist jeder mit oder ohne Hilfe automatisierter Verfahren
ausgeführte Vorgang oder jede solche Vorgangsreihe im Zusammenhang mit
personenbezogenen Daten wie das Erheben, das Erfassen, die Organisation, das
Ordnen, die Speicherung, die Anpassung oder Veränderung, das Auslesen, das
Abfragen, die Verwendung, die Offenlegung durch Übermittlung, Verbreitung oder
eine andere Form der Bereitstellung, den Abgleich oder die Verknüpfung, die
Einschränkung, das Löschen oder die Vernichtung.

### d) Einschränkung der Verarbeitung ###

Einschränkung der Verarbeitung ist die Markierung gespeicherter
personenbezogener Daten mit dem Ziel, ihre künftige Verarbeitung
einzuschränken.

### e) Profiling ###

Profiling ist jede Art der automatisierten Verarbeitung personenbezogener
Daten, die darin besteht, dass diese personenbezogenen Daten verwendet werden,
um bestimmte persönliche Aspekte, die sich auf eine natürliche Person
beziehen, zu bewerten, insbesondere, um Aspekte bezüglich Arbeitsleistung,
wirtschaftlicher Lage, Gesundheit, persönlicher Vorlieben, Interessen,
Zuverlässigkeit, Verhalten, Aufenthaltsort oder Ortswechsel dieser natürlichen
Person zu analysieren oder vorherzusagen.

### f)  Pseudonymisierung ###

Pseudonymisierung ist die Verarbeitung personenbezogener Daten in einer Weise,
auf welche die personenbezogenen Daten ohne Hinzuziehung zusätzlicher
Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet
werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt
werden und technischen und organisatorischen Maßnahmen unterliegen, die
gewährleisten, dass die personenbezogenen Daten nicht einer identifizierten
oder identifizierbaren natürlichen Person zugewiesen werden.

### g) Verantwortlicher oder für die Verarbeitung Verantwortlicher ###

Verantwortlicher oder für die Verarbeitung Verantwortlicher ist die natürliche
oder juristische Person, Behörde, Einrichtung oder andere Stelle, die allein
oder gemeinsam mit anderen über die Zwecke und Mittel der Verarbeitung von
personenbezogenen Daten entscheidet. Sind die Zwecke und Mittel dieser
Verarbeitung durch das Unionsrecht oder das Recht der Mitgliedstaaten
vorgegeben, so kann der Verantwortliche beziehungsweise können die bestimmten
Kriterien seiner Benennung nach dem Unionsrecht oder dem Recht der
Mitgliedstaaten vorgesehen werden.

### h) Auftragsverarbeiter ###

Auftragsverarbeiter ist eine natürliche oder juristische Person, Behörde,
Einrichtung oder andere Stelle, die personenbezogene Daten im Auftrag des
Verantwortlichen verarbeitet.

### i) Empfänger ###

Empfänger ist eine natürliche oder juristische Person, Behörde, Einrichtung
oder andere Stelle, der personenbezogene Daten offengelegt werden, unabhängig
davon, ob es sich bei ihr um einen Dritten handelt oder nicht. Behörden, die
im Rahmen eines bestimmten Untersuchungsauftrags nach dem Unionsrecht oder dem
Recht der Mitgliedstaaten möglicherweise personenbezogene Daten erhalten,
gelten jedoch nicht als Empfänger.

### j) Dritter ###

Dritter ist eine natürliche oder juristische Person, Behörde, Einrichtung oder
andere Stelle außer der betroffenen Person, dem Verantwortlichen, dem
Auftragsverarbeiter und den Personen, die unter der unmittelbaren
Verantwortung des Verantwortlichen oder des Auftragsverarbeiters befugt sind,
die personenbezogenen Daten zu verarbeiten.

### k) Einwilligung ###

Einwilligung ist jede von der betroffenen Person freiwillig für den bestimmten
Fall in informierter Weise und unmissverständlich abgegebene Willensbekundung
in Form einer Erklärung oder einer sonstigen eindeutigen bestätigenden
Handlung, mit der die betroffene Person zu verstehen gibt, dass sie mit der
Verarbeitung der sie betreffenden personenbezogenen Daten einverstanden ist.

## 2. Name und Anschrift des für die Verarbeitung Verantwortlichen ##

Verantwortlicher im Sinne der DatenschutzGrundverordnung, sonstiger in den Mitgliedstaaten der Europäischen Union geltenden Datenschutzgesetze und anderer Bestimmungen mit datenschutzrechtlichem Charakter ist die:

    Bernd Paysan
    net2o secure communication
    Wilbrechtstr. 85
    81477 München

    Deutschland

    Tel.: +𝟦𝟫‧𝟪𝟫‧𝟦𝟣 𝟣𝟧 𝟦𝟨 𝟧𝟧

    EMail: bernd (at) net2o (dot) de

    Website: net2o.de
    
    net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*

## 3. Cookies ##

Die Internetseiten der net2o secure communication verwenden Cookies. Cookies
sind Textdateien, welche über einen Internetbrowser auf einem Computersystem
abgelegt und gespeichert werden.

Zahlreiche Internetseiten und Server verwenden Cookies. Viele Cookies
enthalten eine sogenannte CookieID. Eine CookieID ist eine eindeutige
Kennung des Cookies. Sie besteht aus einer Zeichenfolge, durch welche
Internetseiten und Server dem konkreten Internetbrowser zugeordnet werden
können, in dem das Cookie gespeichert wurde. Dies ermöglicht es den besuchten
Internetseiten und Servern, den individuellen Browser der betroffenen Person
von anderen Internetbrowsern, die andere Cookies enthalten, zu
unterscheiden. Ein bestimmter Internetbrowser kann über die eindeutige
CookieID wiedererkannt und identifiziert werden.

Durch den Einsatz von Cookies kann die net2o secure communication den Nutzern
dieser Internetseite nutzerfreundlichere Services bereitstellen, die ohne die
CookieSetzung nicht möglich wären.

Mittels eines Cookies können die Informationen und Angebote auf unserer
Internetseite im Sinne des Benutzers optimiert werden. Cookies ermöglichen
uns, wie bereits erwähnt, die Benutzer unserer Internetseite
wiederzuerkennen. Zweck dieser Wiedererkennung ist es, den Nutzern die
Verwendung unserer Internetseite zu erleichtern. Der Benutzer einer
Internetseite, die Cookies verwendet, muss beispielsweise nicht bei jedem
Besuch der Internetseite erneut seine Zugangsdaten eingeben, weil dies von der
Internetseite und dem auf dem Computersystem des Benutzers abgelegten Cookie
übernommen wird. Ein weiteres Beispiel ist das Cookie eines Warenkorbes im
OnlineShop. Der OnlineShop merkt sich die Artikel, die ein Kunde in den
virtuellen Warenkorb gelegt hat, über ein Cookie.

Die betroffene Person kann die Setzung von Cookies durch unsere Internetseite
jederzeit mittels einer entsprechenden Einstellung des genutzten
Internetbrowsers verhindern und damit der Setzung von Cookies dauerhaft
widersprechen. Ferner können bereits gesetzte Cookies jederzeit über einen
Internetbrowser oder andere Softwareprogramme gelöscht werden. Dies ist in
allen gängigen Internetbrowsern möglich. Deaktiviert die betroffene Person die
Setzung von Cookies in dem genutzten Internetbrowser, sind unter Umständen
nicht alle Funktionen unserer Internetseite vollumfänglich nutzbar.

## 3a. HSTS \& HPKP ##

Wir weisen Ihren Browser beim Besuch unserer Webseiten an, sich zu merken,
dass diese Webseiten nur verschlüsselt erreichbar sind, und mit welchem
Schlüssel dies geschieht. Diese Information speichert ihr Browser und wird bei
einem späteren Zugriff nicht mehr versuchen, eine unverschlüsselte Verbindung
herzustellen. Zur Löschung dieser Information konsultieren Sie bitte die
Anleitung Ihres Browsers.
................................................................................
eine Reihe von allgemeinen Daten und Informationen. Diese allgemeinen Daten
und Informationen werden in den Logfiles des Servers gespeichert. Erfasst
werden können die (1) verwendeten Browsertypen und Versionen, (2) das vom
zugreifenden System verwendete Betriebssystem, (3) die Internetseite, von
welcher ein zugreifendes System auf unsere Internetseite gelangt (sogenannte
Referrer), (4) die Unterwebseiten, welche über ein zugreifendes System auf
unserer Internetseite angesteuert werden, (5) das Datum und die Uhrzeit eines
Zugriffs auf die Internetseite, (6) eine InternetProtokollAdresse
(IPAdresse), (7) der Internet–Service–Provider des zugreifenden Systems und
(8) sonstige ähnliche Daten und Informationen, die der Gefahrenabwehr im Falle
von Angriffen auf unsere informationstechnologischen Systeme dienen.

Bei der Nutzung dieser allgemeinen Daten und Informationen zieht die net2o
secure communication keine Rückschlüsse auf die betroffene Person. Diese
Informationen werden vielmehr benötigt, um (1) die Inhalte unserer
Internetseite korrekt auszuliefern, (2) die Inhalte unserer Internetseite
................................................................................
unserer Internetseite zu gewährleisten sowie (4) um Strafverfolgungsbehörden
im Falle eines Cyberangriffes die zur Strafverfolgung notwendigen
Informationen bereitzustellen. Diese anonym erhobenen Daten und Informationen
werden durch die net2o secure communication daher einerseits statistisch und
ferner mit dem Ziel ausgewertet, den Datenschutz und die Datensicherheit in
unserem Unternehmen zu erhöhen, um letztlich ein optimales Schutzniveau für
die von uns verarbeiteten personenbezogenen Daten sicherzustellen. Die
anonymen Daten der ServerLogfiles werden getrennt von allen durch eine
betroffene Person angegebenen personenbezogenen Daten gespeichert.

## 5. Routinemäßige Löschung und Sperrung von personenbezogenen Daten ##

Der für die Verarbeitung Verantwortliche verarbeitet und speichert
personenbezogene Daten der betroffenen Person nur für den Zeitraum, der zur
Erreichung des Speicherungszwecks erforderlich ist oder sofern dies durch den
................................................................................
und Verordnungsgeber oder einem anderen zuständigen Gesetzgeber
vorgeschriebene Speicherfrist ab, werden die personenbezogenen Daten
routinemäßig und entsprechend den gesetzlichen Vorschriften gesperrt oder
gelöscht.

## 6. Rechte der betroffenen Person ##

### a) Recht auf Bestätigung ###

Jede betroffene Person hat das vom Europäischen Richtlinien- und
Verordnungsgeber eingeräumte Recht, von dem für die Verarbeitung
Verantwortlichen eine Bestätigung darüber zu verlangen, ob sie betreffende
personenbezogene Daten verarbeitet werden. Möchte eine betroffene Person
dieses Bestätigungsrecht in Anspruch nehmen, kann sie sich hierzu jederzeit an
einen Mitarbeiter des für die Verarbeitung Verantwortlichen wenden.

### b) Recht auf Auskunft ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, jederzeit
von dem für die Verarbeitung Verantwortlichen unentgeltliche Auskunft über die
zu seiner Person gespeicherten personenbezogenen Daten und eine Kopie dieser
Auskunft zu erhalten. Ferner hat der Europäische Richtlinien- und
Verordnungsgeber der betroffenen Person Auskunft über folgende Informationen
zugestanden:

+ die Verarbeitungszwecke
+ die Kategorien personenbezogener Daten, die verarbeitet werden
+ die Empfänger oder Kategorien von Empfängern, gegenüber denen die
  personenbezogenen Daten offengelegt worden sind oder noch offengelegt
  werden, insbesondere
+ bei Empfängern in Drittländern oder bei internationalen Organisationen
  falls möglich die geplante Dauer, für die die personenbezogenen Daten
  gespeichert werden, oder, falls dies nicht möglich ist, die Kriterien für
  die Festlegung dieser Dauer
+ das Bestehen eines Rechts auf Berichtigung oder Löschung der sie
  betreffenden personenbezogenen Daten oder auf Einschränkung der
  Verarbeitung durch den Verantwortlichen oder eines Widerspruchsrechts
  gegen diese Verarbeitung
+ das Bestehen eines Beschwerderechts bei einer Aufsichtsbehörde
+ wenn die personenbezogenen Daten nicht bei der betroffenen Person erhoben
  werden: Alle verfügbaren Informationen über die Herkunft der Daten
+ das Bestehen einer automatisierten Entscheidungsfindung einschließlich
  Profiling gemäß Artikel 22 Abs.1 und 4 DSGVO und — zumindest in diesen
  Fällen — aussagekräftige Informationen über die involvierte Logik sowie
  die Tragweite und die angestrebten Auswirkungen einer derartigen
  Verarbeitung für die betroffene Person

Ferner steht der betroffenen Person ein Auskunftsrecht darüber zu, ob
personenbezogene Daten an ein Drittland oder an eine internationale
Organisation übermittelt wurden. Sofern dies der Fall ist, so steht der
betroffenen Person im Übrigen das Recht zu, Auskunft über die geeigneten
Garantien im Zusammenhang mit der Übermittlung zu erhalten.

Möchte eine betroffene Person dieses Auskunftsrecht in Anspruch nehmen, kann
sie sich hierzu jederzeit an einen Mitarbeiter des für die Verarbeitung
Verantwortlichen wenden.

### c) Recht auf Berichtigung ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, die
unverzügliche Berichtigung sie betreffender unrichtiger personenbezogener
Daten zu verlangen. Ferner steht der betroffenen Person das Recht zu, unter
Berücksichtigung der Zwecke der Verarbeitung, die Vervollständigung
unvollständiger personenbezogener Daten — auch mittels einer ergänzenden
Erklärung — zu verlangen.

Möchte eine betroffene Person dieses Berichtigungsrecht in Anspruch nehmen,
kann sie sich hierzu jederzeit an einen Mitarbeiter des für die Verarbeitung
Verantwortlichen wenden.

### d) Recht auf Löschung (Recht auf Vergessen werden) ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, von dem
Verantwortlichen zu verlangen, dass die sie betreffenden personenbezogenen
Daten unverzüglich gelöscht werden, sofern einer der folgenden Gründe zutrifft
und soweit die Verarbeitung nicht erforderlich ist:

+ Die personenbezogenen Daten wurden für solche Zwecke erhoben oder auf
  sonstige Weise verarbeitet, für welche sie nicht mehr notwendig sind.
+ Die betroffene Person widerruft ihre Einwilligung, auf die sich die
  Verarbeitung gemäß Art. 6 Abs. 1 Buchstabe a DSGVO oder Art. 9 Abs. 2
  Buchstabe a DSGVO stützte, und es fehlt an einer anderweitigen
  Rechtsgrundlage für die Verarbeitung.
+ Die betroffene Person legt gemäß Art. 21 Abs. 1 DSGVO Widerspruch gegen
  die Verarbeitung ein, und es liegen keine vorrangigen berechtigten Gründe
  für die Verarbeitung vor, oder die betroffene Person legt gemäß Art. 21
  Abs. 2 DSGVO Widerspruch gegen die Verarbeitung ein.
+ Die personenbezogenen Daten wurden unrechtmäßig verarbeitet.
+ Die Löschung der personenbezogenen Daten ist zur Erfüllung einer
  rechtlichen Verpflichtung nach dem Unionsrecht oder dem Recht der
  Mitgliedstaaten erforderlich, dem der Verantwortliche unterliegt.
+ Die personenbezogenen Daten wurden in Bezug auf angebotene Dienste der
  Informationsgesellschaft gemäß Art. 8 Abs. 1 DSGVO erhoben.

Sofern einer der oben genannten Gründe zutrifft und eine betroffene Person die
Löschung von personenbezogenen Daten, die bei der net2o secure communication
gespeichert sind, veranlassen möchte, kann sie sich hierzu jederzeit an einen
Mitarbeiter des für die Verarbeitung Verantwortlichen wenden. Der Mitarbeiter
der net2o secure communication wird veranlassen, dass dem Löschverlangen
unverzüglich nachgekommen wird.

Wurden die personenbezogenen Daten von der net2o secure communication
öffentlich gemacht und ist unser Unternehmen als Verantwortlicher gemäß
Art. 17 Abs. 1 DSGVO zur Löschung der personenbezogenen Daten verpflichtet,
so trifft die net2o secure communication unter Berücksichtigung der
verfügbaren Technologie und der Implementierungskosten angemessene Maßnahmen,
auch technischer Art, um andere für die Datenverarbeitung Verantwortliche,
welche die veröffentlichten personenbezogenen Daten verarbeiten, darüber in
Kenntnis zu setzen, dass die betroffene Person von diesen anderen für die
Datenverarbeitung Verantwortlichen die Löschung sämtlicher Links zu diesen
personenbezogenen Daten oder von Kopien oder Replikationen dieser
personenbezogenen Daten verlangt hat, soweit die Verarbeitung nicht
erforderlich ist. Der Mitarbeiter der net2o secure communication wird im
Einzelfall das Notwendige veranlassen.

### e) Recht auf Einschränkung der Verarbeitung ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, von dem
Verantwortlichen die Einschränkung der Verarbeitung zu verlangen, wenn eine
der folgenden Voraussetzungen gegeben ist:

+ Die Richtigkeit der personenbezogenen Daten wird von der betroffenen
  Person bestritten, und zwar für eine Dauer, die es dem Verantwortlichen
  ermöglicht, die Richtigkeit der personenbezogenen Daten zu überprüfen.
+ Die Verarbeitung ist unrechtmäßig, die betroffene Person lehnt die
  Löschung der personenbezogenen Daten ab und verlangt stattdessen die
  Einschränkung der Nutzung der personenbezogenen Daten.
+ Der Verantwortliche benötigt die personenbezogenen Daten für die Zwecke
  der Verarbeitung nicht länger, die betroffene Person benötigt sie jedoch
  zur Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen.
+ Die betroffene Person hat Widerspruch gegen die Verarbeitung gem. Art. 21
  Abs. 1 DSGVO eingelegt und es steht noch nicht fest, ob die berechtigten
  Gründe des Verantwortlichen gegenüber denen der betroffenen Person
  überwiegen.

Sofern eine der oben genannten Voraussetzungen gegeben ist und eine betroffene
Person die Einschränkung von personenbezogenen Daten, die bei der net2o secure
communication gespeichert sind, verlangen möchte, kann sie sich hierzu
jederzeit an einen Mitarbeiter des für die Verarbeitung Verantwortlichen
wenden. Der Mitarbeiter der net2o secure communication wird die Einschränkung
der Verarbeitung veranlassen.

### f) Recht auf Datenübertragbarkeit ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, die sie
betreffenden personenbezogenen Daten, welche durch die betroffene Person einem
Verantwortlichen bereitgestellt wurden, in einem strukturierten, gängigen und
maschinenlesbaren Format zu erhalten. Sie hat außerdem das Recht, diese Daten
einem anderen Verantwortlichen ohne Behinderung durch den Verantwortlichen,
dem die personenbezogenen Daten bereitgestellt wurden, zu übermitteln, sofern
die Verarbeitung auf der Einwilligung gemäß Art. 6 Abs. 1 Buchstabe a DSGVO
oder Art. 9 Abs. 2 Buchstabe a DSGVO oder auf einem Vertrag gemäß Art. 6
Abs. 1 Buchstabe b DSGVO beruht und die Verarbeitung mithilfe automatisierter
Verfahren erfolgt, sofern die Verarbeitung nicht für die Wahrnehmung einer
Aufgabe erforderlich ist, die im öffentlichen Interesse liegt oder in Ausübung
öffentlicher Gewalt erfolgt, welche dem Verantwortlichen übertragen wurde.

Ferner hat die betroffene Person bei der Ausübung ihres Rechts auf
Datenübertragbarkeit gemäß Art. 20 Abs. 1 DSGVO das Recht, zu erwirken, dass
die personenbezogenen Daten direkt von einem Verantwortlichen an einen anderen
Verantwortlichen übermittelt werden, soweit dies technisch machbar ist und
sofern hiervon nicht die Rechte und Freiheiten anderer Personen beeinträchtigt
werden.

Zur Geltendmachung des Rechts auf Datenübertragbarkeit kann sich die
betroffene Person jederzeit an einen Mitarbeiter der net2o secure
communication wenden.

### g) Recht auf Widerspruch ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, aus
Gründen, die sich aus ihrer besonderen Situation ergeben, jederzeit gegen die
Verarbeitung sie betreffender personenbezogener Daten, die aufgrund von Art. 6
Abs. 1 Buchstaben e oder f DSGVO erfolgt, Widerspruch einzulegen. Dies gilt
auch für ein auf diese Bestimmungen gestütztes Profiling.

Die net2o secure communication verarbeitet die personenbezogenen Daten im
Falle des Widerspruchs nicht mehr, es sei denn, wir können zwingende
schutzwürdige Gründe für die Verarbeitung nachweisen, die den Interessen,
Rechten und Freiheiten der betroffenen Person überwiegen, oder die
Verarbeitung dient der Geltendmachung, Ausübung oder Verteidigung von
................................................................................
Direktwerbung, so wird die net2o secure communication die personenbezogenen
Daten nicht mehr für diese Zwecke verarbeiten.

Zudem hat die betroffene Person das Recht, aus Gründen, die sich aus ihrer
besonderen Situation ergeben, gegen die sie betreffende Verarbeitung
personenbezogener Daten, die bei der net2o secure communication zu
wissenschaftlichen oder historischen Forschungszwecken oder zu statistischen
Zwecken gemäß Art. 89 Abs. 1 DSGVO erfolgen, Widerspruch einzulegen, es sei
denn, eine solche Verarbeitung ist zur Erfüllung einer im öffentlichen
Interesse liegenden Aufgabe erforderlich.

Zur Ausübung des Rechts auf Widerspruch kann sich die betroffene Person direkt
jeden Mitarbeiter der net2o secure communication oder einen anderen
Mitarbeiter wenden. Der betroffenen Person steht es ferner frei, im
Zusammenhang mit der Nutzung von Diensten der Informationsgesellschaft,
ungeachtet der Richtlinie 2002/58/EG, ihr Widerspruchsrecht mittels
automatisierter Verfahren auszuüben, bei denen technische Spezifikationen
verwendet werden.

### h) Automatisierte Entscheidungen im Einzelfall einschließlich Profiling ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, nicht einer
ausschließlich auf einer automatisierten Verarbeitung — einschließlich
Profiling — beruhenden Entscheidung unterworfen zu werden, die ihr gegenüber
rechtliche Wirkung entfaltet oder sie in ähnlicher Weise erheblich
beeinträchtigt, sofern die Entscheidung (1) nicht für den Abschluss oder die
................................................................................
Verantwortlichen, auf Darlegung des eigenen Standpunkts und auf Anfechtung der
Entscheidung gehört.

Möchte die betroffene Person Rechte mit Bezug auf automatisierte
Entscheidungen geltend machen, kann sie sich hierzu jederzeit an einen
Mitarbeiter des für die Verarbeitung Verantwortlichen wenden.

### i) Recht auf Widerruf einer datenschutzrechtlichen Einwilligung ###

Jede von der Verarbeitung personenbezogener Daten betroffene Person hat das
vom Europäischen Richtlinien- und Verordnungsgeber gewährte Recht, eine
Einwilligung zur Verarbeitung personenbezogener Daten jederzeit zu widerrufen.

Möchte die betroffene Person ihr Recht auf Widerruf einer Einwilligung geltend
machen, kann sie sich hierzu jederzeit an einen Mitarbeiter des für die
Verarbeitung Verantwortlichen wenden.

## 7. Rechtsgrundlage der Verarbeitung ##

Art. 6 I lit. a DSGVO dient unserem Unternehmen als Rechtsgrundlage für
Verarbeitungsvorgänge, bei denen wir eine Einwilligung für einen bestimmten
Verarbeitungszweck einholen. Ist die Verarbeitung personenbezogener Daten zur
Erfüllung eines Vertrags, dessen Vertragspartei die betroffene Person ist,
erforderlich, wie dies beispielsweise bei Verarbeitungsvorgängen der Fall ist,
die für eine Lieferung von Waren oder die Erbringung einer sonstigen Leistung
oder Gegenleistung notwendig sind, so beruht die Verarbeitung auf Art. 6 I
lit. b DSGVO. Gleiches gilt für solche Verarbeitungsvorgänge die zur
Durchführung vorvertraglicher Maßnahmen erforderlich sind, etwa in Fällen von
Anfragen zur unseren Produkten oder Leistungen. Unterliegt unser Unternehmen
einer rechtlichen Verpflichtung durch welche eine Verarbeitung von
personenbezogenen Daten erforderlich wird, wie beispielsweise zur Erfüllung
steuerlicher Pflichten, so basiert die Verarbeitung auf Art. 6 I lit. c
DSGVO. In seltenen Fällen könnte die Verarbeitung von personenbezogenen Daten
erforderlich werden, um lebenswichtige Interessen der betroffenen Person oder
einer anderen natürlichen Person zu schützen. Dies wäre beispielsweise der
Fall, wenn ein Besucher in unserem Betrieb verletzt werden würde und daraufhin
sein Name, sein Alter, seine Krankenkassendaten oder sonstige lebenswichtige
Informationen an einen Arzt, ein Krankenhaus oder sonstige Dritte
weitergegeben werden müssten. Dann würde die Verarbeitung auf Art. 6 I lit. d
DSGVO beruhen. Letztlich könnten Verarbeitungsvorgänge auf Art. 6 I lit. f
DSGVO beruhen. Auf dieser Rechtsgrundlage basieren Verarbeitungsvorgänge, die
von keiner der vorgenannten Rechtsgrundlagen erfasst werden, wenn die
Verarbeitung zur Wahrung eines berechtigten Interesses unseres Unternehmens
oder eines Dritten erforderlich ist, sofern die Interessen, Grundrechte und
Grundfreiheiten des Betroffenen nicht überwiegen. Solche Verarbeitungsvorgänge
sind uns insbesondere deshalb gestattet, weil sie durch den Europäischen
Gesetzgeber besonders erwähnt wurden. Er vertrat insoweit die Auffassung, dass
ein berechtigtes Interesse anzunehmen sein könnte, wenn die betroffene Person
ein Kunde des Verantwortlichen ist (Erwägungsgrund 47 Satz 2 DSGVO).

## 8. Berechtigte Interessen an der Verarbeitung, die von dem Verantwortlichen oder einem Dritten verfolgt werden ##

Basiert die Verarbeitung personenbezogener Daten auf Artikel 6 I lit. f DSGVO
ist unser berechtigtes Interesse die Durchführung unserer Geschäftstätigkeit
zugunsten des Wohlergehens all unserer Mitarbeiter und unserer Anteilseigner.

## 9. Dauer, für die die personenbezogenen Daten gespeichert werden ##

Das Kriterium für die Dauer der Speicherung von personenbezogenen Daten ist
die jeweilige gesetzliche Aufbewahrungsfrist. Nach Ablauf der Frist werden die
................................................................................
Nichtbereitstellung der personenbezogenen Daten hätte.

## 11. Bestehen einer automatisierten Entscheidungsfindung ##

Als verantwortungsbewusstes Unternehmen verzichten wir auf eine automatische
Entscheidungsfindung oder ein Profiling.

Diese Datenschutzerklärung wurde durch den DatenschutzerklärungsGenerator der
DGD Deutsche Gesellschaft für Datenschutz GmbH, die als Externer
Datenschutzbeauftragter Fürth tätig ist, in Kooperation mit dem IT- und
Datenschutzrecht Anwalt Christian Solmecke erstellt.

Changes to wiki/eu-gdpr.md.

78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
...
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
...
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
...
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
Protection Regulation (GDPR). Our data protection declaration should be
legible and understandable for the general public, as well as our customers
and business partners. To ensure this, we would like to first explain the
terminology used.

In this data protection declaration, we use, inter alia, the following terms:

### a)    Personal data ###

Personal data means any information relating to an identified or identifiable
natural person (“data subject”). An identifiable natural person is one who can
be identified, directly or indirectly, in particular by reference to an
identifier such as a name, an identification number, location data, an online
identifier or to one or more factors specific to the physical, physiological,
genetic, mental, economic, cultural or social identity of that natural person.

### b)    Data subject ###

Data subject is any identified or identifiable natural person, whose personal
data is processed by the controller responsible for the processing.

### c)    Processing ###

Processing is any operation or set of operations which is performed on
personal data or on sets of personal data, whether or not by automated means,
such as collection, recording, organisation, structuring, storage, adaptation
or alteration, retrieval, consultation, use, disclosure by transmission,
dissemination or otherwise making available, alignment or combination,
restriction, erasure or destruction.

### d)    Restriction of processing ###

Restriction of processing is the marking of stored personal data with the aim
of limiting their processing in the future.

### e)    Profiling ###

Profiling means any form of automated processing of personal data consisting
of the use of personal data to evaluate certain personal aspects relating to a
natural person, in particular to analyse or predict aspects concerning that
natural person's performance at work, economic situation, health, personal
preferences, interests, reliability, behaviour, location or movements.

### f)     Pseudonymisation ###

Pseudonymisation is the processing of personal data in such a manner that the
personal data can no longer be attributed to a specific data subject without
the use of additional information, provided that such additional information
is kept separately and is subject to technical and organisational measures to
ensure that the personal data are not attributed to an identified or
identifiable natural person.

### g)    Controller or controller responsible for the processing ###

Controller or controller responsible for the processing is the natural or
legal person, public authority, agency or other body which, alone or jointly
with others, determines the purposes and means of the processing of personal
data; where the purposes and means of such processing are determined by Union
or Member State law, the controller or the specific criteria for its
nomination may be provided for by Union or Member State law.

### h)    Processor ###

Processor is a natural or legal person, public authority, agency or other body
which processes personal data on behalf of the controller.

### i)      Recipient ###

Recipient is a natural or legal person, public authority, agency or another
body, to which the personal data are disclosed, whether a third party or
not. However, public authorities which may receive personal data in the
framework of a particular inquiry in accordance with Union or Member State law
shall not be regarded as recipients; the processing of those data by those
public authorities shall be in compliance with the applicable data protection
rules according to the purposes of the processing.

### j)      Third party ###

Third party is a natural or legal person, public authority, agency or body
other than the data subject, controller, processor and persons who, under the
direct authority of the controller or processor, are authorised to process
personal data.

### k)    Consent ###

Consent of the data subject is any freely given, specific, informed and
unambiguous indication of the data subject's wishes by which he or she, by a
statement or by a clear affirmative action, signifies agreement to the
processing of personal data relating to him or her.

## 2. Name and Address of the controller ##

Controller for the purposes of the General Data Protection Regulation (GDPR),
other data protection laws applicable in Member states of the European Union
and other provisions related to data protection is:

    Bernd Paysan
	net2o secure communication
    Wilbrechtstr. 85
    81477 München
	
	Deutschland
    
    Phone: +𝟦𝟫‧𝟪𝟫‧𝟦𝟣 𝟣𝟧 𝟦𝟨 𝟧𝟧

    Email: bernd (at) net2o (dot) de

    Website: net2o.de
	
    net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*


## 3. Cookies ##

The Internet pages of the net2o secure communication use cookies. Cookies are
text files that are stored in a computer system via an Internet browser.
................................................................................

Each data subject shall have the right granted by the European legislator to
obtain from the controller free information about his or her personal data
stored at any time and a copy of this information. Furthermore, the European
directives and regulations grant the data subject access to the following
information:

  + the purposes of the processing;
  + the categories of personal data concerned;
  + the recipients or categories of recipients to whom the personal data have
    been or will be disclosed, in particular recipients in third countries or
    international organisations;
  + where possible, the envisaged period for which the personal data will be
    stored, or, if not possible, the criteria used to determine that period;
  + the existence of the right to request from the controller rectification or
    erasure of personal data, or restriction of processing of personal data
    concerning the data subject, or to object to such processing;
  + the existence of the right to lodge a complaint with a supervisory
    authority;
  + where the personal data are not collected from the data subject, any
    available information as to their source;
  + the existence of automated decision-making, including profiling, referred
    to in Article 22(1) and (4) of the GDPR and, at least in those cases,
    meaningful information about the logic involved, as well as the
    significance and envisaged consequences of such processing for the data
    subject.

Furthermore, the data subject shall have a right to obtain information as to
whether personal data are transferred to a third country or to an
international organisation. Where this is the case, the data subject shall
have the right to be informed of the appropriate safeguards relating to the
transfer.

................................................................................

Each data subject shall have the right granted by the European legislator to
obtain from the controller the erasure of personal data concerning him or her
without undue delay, and the controller shall have the obligation to erase
personal data without undue delay where one of the following grounds applies,
as long as the processing is not necessary:

  + The personal data are no longer necessary in relation to the purposes for
    which they were collected or otherwise processed.
  + The data subject withdraws consent to which the processing is based
    according to point (a) of Article 6(1) of the GDPR, or point (a) of
    Article 9(2) of the GDPR, and where there is no other legal ground for the
    processing.
  + The data subject objects to the processing pursuant to Article 21(1) of
    the GDPR and there are no overriding legitimate grounds for the
    processing, or the data subject objects to the processing pursuant to
    Article 21(2) of the GDPR.
  + The personal data have been unlawfully processed.
  + The personal data must be erased for compliance with a legal obligation in
    Union or Member State law to which the controller is subject.
  + The personal data have been collected in relation to the offer of
    information society services referred to in Article 8(1) of the GDPR.

If one of the aforementioned reasons applies, and a data subject wishes to
request the erasure of personal data stored by the net2o secure communication,
he or she may, at any time, contact any employee of the controller. An
employee of net2o secure communication shall promptly ensure that the erasure
request is complied with immediately.

................................................................................

### e) Right of restriction of processing ###

Each data subject shall have the right granted by the European legislator to
obtain from the controller restriction of processing where one of the
following applies:

  + The accuracy of the personal data is contested by the data subject, for a
    period enabling the controller to verify the accuracy of the personal
    data.
  + The processing is unlawful and the data subject opposes the erasure of the
    personal data and requests instead the restriction of their use instead.
  + The controller no longer needs the personal data for the purposes of the
    processing, but they are required by the data subject for the
    establishment, exercise or defence of legal claims.
  + The data subject has objected to processing pursuant to Article 21(1) of
    the GDPR pending the verification whether the legitimate grounds of the
    controller override those of the data subject.

If one of the aforementioned conditions is met, and a data subject wishes to
request the restriction of the processing of personal data stored by the net2o
secure communication, he or she may at any time contact any employee of the
controller. The employee of the net2o secure communication will arrange the
restriction of the processing.








|








|




|








|




|







|








|








|




|









|






|













|


|
|






|







 







|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|







 







|
|
|
|
|
|
|
|
|
|
|
|
|
|
|







 







|
|
|
|
|
|
|
|
|
|
|







78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
...
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
...
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
...
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
Protection Regulation (GDPR). Our data protection declaration should be
legible and understandable for the general public, as well as our customers
and business partners. To ensure this, we would like to first explain the
terminology used.

In this data protection declaration, we use, inter alia, the following terms:

### a) Personal data ###

Personal data means any information relating to an identified or identifiable
natural person (“data subject”). An identifiable natural person is one who can
be identified, directly or indirectly, in particular by reference to an
identifier such as a name, an identification number, location data, an online
identifier or to one or more factors specific to the physical, physiological,
genetic, mental, economic, cultural or social identity of that natural person.

### b) Data subject ###

Data subject is any identified or identifiable natural person, whose personal
data is processed by the controller responsible for the processing.

### c) Processing ###

Processing is any operation or set of operations which is performed on
personal data or on sets of personal data, whether or not by automated means,
such as collection, recording, organisation, structuring, storage, adaptation
or alteration, retrieval, consultation, use, disclosure by transmission,
dissemination or otherwise making available, alignment or combination,
restriction, erasure or destruction.

### d) Restriction of processing ###

Restriction of processing is the marking of stored personal data with the aim
of limiting their processing in the future.

### e) Profiling ###

Profiling means any form of automated processing of personal data consisting
of the use of personal data to evaluate certain personal aspects relating to a
natural person, in particular to analyse or predict aspects concerning that
natural person's performance at work, economic situation, health, personal
preferences, interests, reliability, behaviour, location or movements.

### f) Pseudonymisation ###

Pseudonymisation is the processing of personal data in such a manner that the
personal data can no longer be attributed to a specific data subject without
the use of additional information, provided that such additional information
is kept separately and is subject to technical and organisational measures to
ensure that the personal data are not attributed to an identified or
identifiable natural person.

### g) Controller or controller responsible for the processing ###

Controller or controller responsible for the processing is the natural or
legal person, public authority, agency or other body which, alone or jointly
with others, determines the purposes and means of the processing of personal
data; where the purposes and means of such processing are determined by Union
or Member State law, the controller or the specific criteria for its
nomination may be provided for by Union or Member State law.

### h) Processor ###

Processor is a natural or legal person, public authority, agency or other body
which processes personal data on behalf of the controller.

### i) Recipient ###

Recipient is a natural or legal person, public authority, agency or another
body, to which the personal data are disclosed, whether a third party or
not. However, public authorities which may receive personal data in the
framework of a particular inquiry in accordance with Union or Member State law
shall not be regarded as recipients; the processing of those data by those
public authorities shall be in compliance with the applicable data protection
rules according to the purposes of the processing.

### j) Third party ###

Third party is a natural or legal person, public authority, agency or body
other than the data subject, controller, processor and persons who, under the
direct authority of the controller or processor, are authorised to process
personal data.

### k) Consent ###

Consent of the data subject is any freely given, specific, informed and
unambiguous indication of the data subject's wishes by which he or she, by a
statement or by a clear affirmative action, signifies agreement to the
processing of personal data relating to him or her.

## 2. Name and Address of the controller ##

Controller for the purposes of the General Data Protection Regulation (GDPR),
other data protection laws applicable in Member states of the European Union
and other provisions related to data protection is:

    Bernd Paysan
    net2o secure communication
    Wilbrechtstr. 85
    81477 München
    
    Deutschland
    
    Phone: +𝟦𝟫‧𝟪𝟫‧𝟦𝟣 𝟣𝟧 𝟦𝟨 𝟧𝟧

    Email: bernd (at) net2o (dot) de

    Website: net2o.de
    
    net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*


## 3. Cookies ##

The Internet pages of the net2o secure communication use cookies. Cookies are
text files that are stored in a computer system via an Internet browser.
................................................................................

Each data subject shall have the right granted by the European legislator to
obtain from the controller free information about his or her personal data
stored at any time and a copy of this information. Furthermore, the European
directives and regulations grant the data subject access to the following
information:

* the purposes of the processing;
* the categories of personal data concerned;
* the recipients or categories of recipients to whom the personal data have
  been or will be disclosed, in particular recipients in third countries or
  international organisations;
* where possible, the envisaged period for which the personal data will be
  stored, or, if not possible, the criteria used to determine that period;
* the existence of the right to request from the controller rectification or
  erasure of personal data, or restriction of processing of personal data
  concerning the data subject, or to object to such processing;
* the existence of the right to lodge a complaint with a supervisory
  authority;
* where the personal data are not collected from the data subject, any
  available information as to their source;
* the existence of automated decision-making, including profiling, referred
  to in Article 22(1) and (4) of the GDPR and, at least in those cases,
  meaningful information about the logic involved, as well as the
  significance and envisaged consequences of such processing for the data
  subject.

Furthermore, the data subject shall have a right to obtain information as to
whether personal data are transferred to a third country or to an
international organisation. Where this is the case, the data subject shall
have the right to be informed of the appropriate safeguards relating to the
transfer.

................................................................................

Each data subject shall have the right granted by the European legislator to
obtain from the controller the erasure of personal data concerning him or her
without undue delay, and the controller shall have the obligation to erase
personal data without undue delay where one of the following grounds applies,
as long as the processing is not necessary:

* The personal data are no longer necessary in relation to the purposes for
  which they were collected or otherwise processed.
* The data subject withdraws consent to which the processing is based
  according to point (a) of Article 6(1) of the GDPR, or point (a) of
  Article 9(2) of the GDPR, and where there is no other legal ground for the
  processing.
* The data subject objects to the processing pursuant to Article 21(1) of
  the GDPR and there are no overriding legitimate grounds for the
  processing, or the data subject objects to the processing pursuant to
  Article 21(2) of the GDPR.
* The personal data have been unlawfully processed.
* The personal data must be erased for compliance with a legal obligation in
  Union or Member State law to which the controller is subject.
* The personal data have been collected in relation to the offer of
  information society services referred to in Article 8(1) of the GDPR.

If one of the aforementioned reasons applies, and a data subject wishes to
request the erasure of personal data stored by the net2o secure communication,
he or she may, at any time, contact any employee of the controller. An
employee of net2o secure communication shall promptly ensure that the erasure
request is complied with immediately.

................................................................................

### e) Right of restriction of processing ###

Each data subject shall have the right granted by the European legislator to
obtain from the controller restriction of processing where one of the
following applies:

* The accuracy of the personal data is contested by the data subject, for a
  period enabling the controller to verify the accuracy of the personal
  data.
* The processing is unlawful and the data subject opposes the erasure of the
  personal data and requests instead the restriction of their use instead.
* The controller no longer needs the personal data for the purposes of the
  processing, but they are required by the data subject for the
  establishment, exercise or defence of legal claims.
* The data subject has objected to processing pursuant to Article 21(1) of
  the GDPR pending the verification whether the legitimate grounds of the
  controller override those of the data subject.

If one of the aforementioned conditions is met, and a data subject wishes to
request the restriction of the processing of personal data stored by the net2o
secure communication, he or she may at any time contact any employee of the
controller. The employee of the net2o secure communication will arrange the
restriction of the processing.

Changes to wiki/guidelines.md.

14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
..
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
..
48
49
50
51
52
53
54
55
56
57
58
59
60
machine, make that machine do what you told it to.

The harder part of all those spells is to make sure the wizard survives.  Only
well debugged spells give them a chance.

Wizards are depicted as old, bearded white men, but that’s just a stereotype.

## <s>Rules</s> <u>Guidelines</u>

1. Thou shallst not assassinate any superior to get into their place. This is
   not limited to physical harm, but also character assassination, doxxing,
   mobbing, etc.<br />
   _(Ridcully’s Razor)_

2. Thy level in the wizardry bases on talent, education, proven wizardry
................................................................................
   8^(8-n) positions in level n.<br />
   _(Previous Supreme Law Number 1, <s>cast in</s> <u>turned into</u> stone)_

3. It matters what thou doest for the magic, not what thou art, and it matters
   that this is fun.<br />
   _(Alberto Malich’s Rule 1)_

## <s>Guidelines</s> <u>Suggestions</u>

4. Thou art supposed to teach what thou knowest to those with the appropriate
   talent, and learn what thou doest not if thou hast the talent.

5. In case thy temper is going full bursar, eat dried frog pills and calm down.

6. Celibacy¹ is mandatory.  Up to seven sons are tolerated, but keep track of
................................................................................

7. Dress and grow thy white facial hair accordingly to look authentic.

8. Monitor thy caffeine level to avoid being too far into the sober side, eat
   enough pizza, go to bed late, and sleep long.  Unless thou art one of those
   early risers, then just stay quiet during thy morning exercise.

## <s>Suggestions</s> <u>The End</u>

Signed by Mustrum Ridcully in invisible ink.

¹) Note: All available data from the seamstresses’ guild suggests that the
closest thing to actual celibacy is a stable relationship, i.e. a marriage.







|







 







|







 







|





14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
..
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
..
48
49
50
51
52
53
54
55
56
57
58
59
60
machine, make that machine do what you told it to.

The harder part of all those spells is to make sure the wizard survives.  Only
well debugged spells give them a chance.

Wizards are depicted as old, bearded white men, but that’s just a stereotype.

## ~~Rules~~ __Guidelines__

1. Thou shallst not assassinate any superior to get into their place. This is
   not limited to physical harm, but also character assassination, doxxing,
   mobbing, etc.<br />
   _(Ridcully’s Razor)_

2. Thy level in the wizardry bases on talent, education, proven wizardry
................................................................................
   8^(8-n) positions in level n.<br />
   _(Previous Supreme Law Number 1, <s>cast in</s> <u>turned into</u> stone)_

3. It matters what thou doest for the magic, not what thou art, and it matters
   that this is fun.<br />
   _(Alberto Malich’s Rule 1)_

## ~~Guidelines~~ __Suggestions__

4. Thou art supposed to teach what thou knowest to those with the appropriate
   talent, and learn what thou doest not if thou hast the talent.

5. In case thy temper is going full bursar, eat dried frog pills and calm down.

6. Celibacy¹ is mandatory.  Up to seven sons are tolerated, but keep track of
................................................................................

7. Dress and grow thy white facial hair accordingly to look authentic.

8. Monitor thy caffeine level to avoid being too far into the sober side, eat
   enough pizza, go to bed late, and sleep long.  Unless thou art one of those
   early risers, then just stay quiet during thy morning exercise.

## ~~Suggestions~~ __The End__

Signed by Mustrum Ridcully in invisible ink.

¹) Note: All available data from the seamstresses’ guild suggests that the
closest thing to actual celibacy is a stable relationship, i.e. a marriage.

Changes to wiki/nsa-backdoor.md.

23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Distributing a secret (without byzantine fault tolerance) is easy with
[ed25519](ed25519.md).  A secret chain _pkn=base\*(sk1\*..\*skn)_ can be
generated through a chain of HSMs, which each generate the next pubkey by
producing _pki=pkj\*(ski)_ (the order is irrelevant, every _ski_ must be used
just once).  To verify that all secrets have been used, use a chain signature.
The device itself generates the starting point of this chain signature, by
signing its own unlock throw-away secret, producing a tuple
_(k)\*base,(z*sk+k)_ (after producing that tuple and the unlock pubkey, this
secret is no longer needed and thrown away).  Each node (HSM) in the chain
will need to modify that signature by adding its own secret _ki_ and
multiplying it with its own secret _ski_, so you first form
_(k)\*base+(ki)*base=(k+ki)*base_ and _(z*sk+k+ki)_, and then
_(ski)\*(k+ki)\*base=(ski(k+ki))*base_, and
_(ski)\*(z\*sk+k+ki)=(z\*sk\*ski+ski(k+ki))_.  The final signature then will
verify correctly against _pkn_, a pubkey only the device itself knows, because
it generated it itself by taking in _pkn-1_ and multiplying its own secret key
_skn_ with it.

The device does not need to keep this pubkey as plaintext, it is sufficient if
this pubkey (or a salted hash over it; using that salt as _z_ value of the







|



|
|







23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Distributing a secret (without byzantine fault tolerance) is easy with
[ed25519](ed25519.md).  A secret chain _pkn=base\*(sk1\*..\*skn)_ can be
generated through a chain of HSMs, which each generate the next pubkey by
producing _pki=pkj\*(ski)_ (the order is irrelevant, every _ski_ must be used
just once).  To verify that all secrets have been used, use a chain signature.
The device itself generates the starting point of this chain signature, by
signing its own unlock throw-away secret, producing a tuple
_(k)\*base,(z\*sk+k)_ (after producing that tuple and the unlock pubkey, this
secret is no longer needed and thrown away).  Each node (HSM) in the chain
will need to modify that signature by adding its own secret _ki_ and
multiplying it with its own secret _ski_, so you first form
_(k)\*base+(ki)\*base=(k+ki)\*base_ and _(z\*sk+k+ki)_, and then
_(ski)\*(k+ki)\*base=(ski(k+ki))\*base_, and
_(ski)\*(z\*sk+k+ki)=(z\*sk\*ski+ski(k+ki))_.  The final signature then will
verify correctly against _pkn_, a pubkey only the device itself knows, because
it generated it itself by taking in _pkn-1_ and multiplying its own secret key
_skn_ with it.

The device does not need to keep this pubkey as plaintext, it is sufficient if
this pubkey (or a salted hash over it; using that salt as _z_ value of the

Changes to wiki/pki.md.

57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
members drop out earliest—because someone paid them a lot of money (Mark
Shuttleworth sold Thawte, the first CA, for $500M to VeriSign in
1999). However, the actual trustworthyness of the CAs itself is not the real
problem. The real problem is that any CA can sign any combination of domain
name and public key, as they like. And any intruder into one of the CAs, who
get access to the signing script can do the same. This is what happened with
DigiNotar. An intruder used DigiNotar's signing key to create a
`*.google.com` certificate. Iran used this certificate to spy on users who
used Google. This came to light, because Google does not really trust the SSL
scheme, and Chrome has a priori knowledge over the google.com domain
signatures, which are signed by Google's own CA. Iran needed to intrude some
other CAs like DigiNotar, because they don't have their own CA, while e.g.
China or the USA have one. Now you have that trust problem again: You don't
know which of the 600 CAs are trustworthy and which are not. And it is
sufficient if **one** of them is not, even when the vast majority would be







|







57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
members drop out earliest—because someone paid them a lot of money (Mark
Shuttleworth sold Thawte, the first CA, for $500M to VeriSign in
1999). However, the actual trustworthyness of the CAs itself is not the real
problem. The real problem is that any CA can sign any combination of domain
name and public key, as they like. And any intruder into one of the CAs, who
get access to the signing script can do the same. This is what happened with
DigiNotar. An intruder used DigiNotar's signing key to create a
`\*.google.com` certificate. Iran used this certificate to spy on users who
used Google. This came to light, because Google does not really trust the SSL
scheme, and Chrome has a priori knowledge over the google.com domain
signatures, which are signed by Google's own CA. Iran needed to intrude some
other CAs like DigiNotar, because they don't have their own CA, while e.g.
China or the USA have one. Now you have that trust problem again: You don't
know which of the 600 CAs are trustworthy and which are not. And it is
sufficient if **one** of them is not, even when the vast majority would be

Changes to wiki/squid-contracts.md.

35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
..
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
...
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
Mortgages and loans with interest rates are too complicated for a dumb
contract, which is a good thing.

## State of an Asset Account

An asset account contains the following state:

+ A hash of the contract that last changed the state
+ A table of assets and their values (how many)
+ A timestamped signature of all that in canonical form

An asset account is addressed by its pubkey.  Contracts are addressed by their
hashes.

A wallet has a securely created random number as seed to create a sequence of
secret keys and their corresponding pubkeys.

................................................................................
(the last source is always the active one).  B is a shortcut for balancing an
asset, and can be used instead of the last value on that asset type.  Also,
previously used assets can be selected by number.

All sources specify the date of the source state, so that a contract can be
performed only once — the destination date must be later than the source date.

+ Claimed money cheque (anybody who has the transaction can claim the money;
  requires trust to the ledger node that accepts the cheque): SA-DSA+D
+ Money transfer (only the designated recipient can claim the money): SA-SA+D1D
+ Creation of asset and obligation: SA+OBD
+ Two party purchase: SA¹+A²-S¹B²B1D2D
+ Two party purchase delivery: SA-SOB1D2D (annihilates the asset)
+ Bid/Ask in an exchange: SA¹+A²-D, finalized by SA¹+A²-DS¹B²BD. Note that
  bids/asks in an exchange can be more complicated when they are only partly
  fulfilled; the splitting requires action by the bidder; and also note that
  this kind of bid requires, like the cheque, trust in the ledger node; but
  less than: The ledger node can only buy for the same price, not steal the
  money.
  Better finalize the contract with the other side.
+ Auction offer: SA¹-, auction bid: SA¹-S¹BA²-D, auction conclusion:
  SA¹-S¹BA²-D1²BD. Auction offers are signed with an end-of-auction
  beginning to indicate the timeout, and the offering party can select the
  best match, allowing other algorithms as maximum price, too, or other
  timeout algorithms than the fixed deadline; e.g. 15 minutes after last bid
  or so.

The evaluation of a dumb contract is rather easy: All sources and destinations
................................................................................
you want to anonymize your account, you need to distribute the value into
difficult to track coins (e.g. powers of two), and to do so without being
tracked, many other people have to do the same thing, and do it in the same
big merged contract.

## Size of a transaction

+ Opcodes are one byte (there aren't that many); literals are bytewise encoded
  and strings have a length preceeding the raw data — see
  [commands](commands.md)
+ Sources are 8+32=40 bytes strings
+ Assets are an integer (index into the set of assets), an optional describing
  string (not needed for a currency)
+ Values are 64 bit integers.  For a legal tender, the scale is in cents, for
  deflationary coins the scale can be considerably larger.  Sums are always
  kept in 128 bits, so for really large transactions, you can use double
  values (two 64 bit integers).
+ Destinations are signatures with timestamp and expiration, i.e. 80 bytes
  strings.

A minimal transaction is somewhat less than 300 bytes, and that's already
non-emtpy to non-empty account.

## Descriptive Assets








|
|
|







 







|

|
|
|
|
|






|







 







|


|
|

|



|







35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
..
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
...
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
Mortgages and loans with interest rates are too complicated for a dumb
contract, which is a good thing.

## State of an Asset Account

An asset account contains the following state:

* A hash of the contract that last changed the state
* A table of assets and their values (how many)
* A timestamped signature of all that in canonical form

An asset account is addressed by its pubkey.  Contracts are addressed by their
hashes.

A wallet has a securely created random number as seed to create a sequence of
secret keys and their corresponding pubkeys.

................................................................................
(the last source is always the active one).  B is a shortcut for balancing an
asset, and can be used instead of the last value on that asset type.  Also,
previously used assets can be selected by number.

All sources specify the date of the source state, so that a contract can be
performed only once — the destination date must be later than the source date.

* Claimed money cheque (anybody who has the transaction can claim the money;
  requires trust to the ledger node that accepts the cheque): SA-DSA+D
* Money transfer (only the designated recipient can claim the money): SA-SA+D1D
* Creation of asset and obligation: SA+OBD
* Two party purchase: SA¹+A²-S¹B²B1D2D
* Two party purchase delivery: SA-SOB1D2D (annihilates the asset)
* Bid/Ask in an exchange: SA¹+A²-D, finalized by SA¹+A²-DS¹B²BD. Note that
  bids/asks in an exchange can be more complicated when they are only partly
  fulfilled; the splitting requires action by the bidder; and also note that
  this kind of bid requires, like the cheque, trust in the ledger node; but
  less than: The ledger node can only buy for the same price, not steal the
  money.
  Better finalize the contract with the other side.
* Auction offer: SA¹-, auction bid: SA¹-S¹BA²-D, auction conclusion:
  SA¹-S¹BA²-D1²BD. Auction offers are signed with an end-of-auction
  beginning to indicate the timeout, and the offering party can select the
  best match, allowing other algorithms as maximum price, too, or other
  timeout algorithms than the fixed deadline; e.g. 15 minutes after last bid
  or so.

The evaluation of a dumb contract is rather easy: All sources and destinations
................................................................................
you want to anonymize your account, you need to distribute the value into
difficult to track coins (e.g. powers of two), and to do so without being
tracked, many other people have to do the same thing, and do it in the same
big merged contract.

## Size of a transaction

* Opcodes are one byte (there aren't that many); literals are bytewise encoded
  and strings have a length preceeding the raw data — see
  [commands](commands.md)
* Sources are 8+32=40 bytes strings
* Assets are an integer (index into the set of assets), an optional describing
  string (not needed for a currency)
* Values are 64 bit integers.  For a legal tender, the scale is in cents, for
  deflationary coins the scale can be considerably larger.  Sums are always
  kept in 128 bits, so for really large transactions, you can use double
  values (two 64 bit integers).
* Destinations are signatures with timestamp and expiration, i.e. 80 bytes
  strings.

A minimal transaction is somewhat less than 300 bytes, and that's already
non-emtpy to non-empty account.

## Descriptive Assets

Changes to wiki/squid-literature.md.

10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
  6. [Adam Ludwin explains crypto currencies](https://blog.chain.com/a-letter-to-jamie-dimon-de89d417cb80)
  7. [Bangladesh Bank Robbery](https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery)
  8. [Flying Money](http://www.baike.com/wiki/%E9%A3%9E%E9%92%B1)
  9. [Is a git repository a BlockChain](https://medium.com/@shemnon/is-a-git-repository-a-blockchain-35cb1cd2c491)
  10. [Is my blockchain a blockchain](https://gist.github.com/joepie91/e49d2bdc9dfec4adc9da8a8434fd029b)
  11. [Der „Wolf of Wall Street“ warnt vor ICOs](http://www.handelsblatt.com/finanzen/maerkte/devisen-rohstoffe/hype-um-krypto-boersengaenge-der-wolf-of-wall-street-warnt-vor-icos/20490646.html)
  12. [„Warum BitCoin (jetzt aber wirklich!) TOT ist“-Kwizz](https://www.heise.de/forum/heise-online/News-Kommentare/Bitcoin-klettert-auf-ueber-7000-US-Dollar/Das-monatliche-Warum-Bitcoin-jetzt-aber-wirklich-TOT-ist-Kwizz/posting-31300715/show/)
  13. [Bitcoin Mining Electricy Consumption](https://motherboard.vice.com/en_us/article/ywbbpm/bitcoin-mining-electricity-consumption-ethereum-energy-climate-change
)
  14. [BitCoin Stromverbrauch Energie](http://t3n.de/news/bitcoin-stromverbrauch-energie-872715/)
  15. [BitCoin Energy Consumption Index](https://digiconomist.net/bitcoin-energy-consumption)
  16. [BitCoin is reactionary](http://www.ianwelsh.net/bitcoin-is-a-bad-way-to-do-something-necessary/)
  17. [Skinner box](https://en.wikipedia.org/wiki/Operant_conditioning_chamber)
  18. [BitCoin bubble from 2013](https://www.forbes.com/sites/jessecolombo/2013/12/19/bitcoin-may-be-following-this-classic-bubble-stages-chart/#61f0969d36b8)
  19. [760,000 transactions per second](http://shanghaiist.com/2017/01/31/14-billion-virtual-hongbao.php)
  20. [Math proof of why lightning network won't work](https://medium.com/@jonaldfyookball/mathematical-proof-that-the-lightning-network-cannot-be-a-decentralized-bitcoin-scaling-solution-1b8147650800)
  21. [A short summary of Chinese money history](https://www.nbbmuseum.be/en/2007/09/chinese-invention.htm)
  22. [I am a time-traveler from the future, here to beg you to stop what you are doing.](https://www.reddit.com/r/Bitcoin/comments/1lfobc/i_am_a_timetraveler_from_the_future_here_to_beg/)
  23. [Decentralized and trustless crypto-paradise is actually a medieval hellhole](https://medium.com/@kaistinchcombe/decentralized-and-trustless-crypto-paradise-is-actually-a-medieval-hellhole-c1ca122efdec)

[up](squid.md) [back](squid-contracts.md)







|
<












10
11
12
13
14
15
16
17

18
19
20
21
22
23
24
25
26
27
28
29
  6. [Adam Ludwin explains crypto currencies](https://blog.chain.com/a-letter-to-jamie-dimon-de89d417cb80)
  7. [Bangladesh Bank Robbery](https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery)
  8. [Flying Money](http://www.baike.com/wiki/%E9%A3%9E%E9%92%B1)
  9. [Is a git repository a BlockChain](https://medium.com/@shemnon/is-a-git-repository-a-blockchain-35cb1cd2c491)
  10. [Is my blockchain a blockchain](https://gist.github.com/joepie91/e49d2bdc9dfec4adc9da8a8434fd029b)
  11. [Der „Wolf of Wall Street“ warnt vor ICOs](http://www.handelsblatt.com/finanzen/maerkte/devisen-rohstoffe/hype-um-krypto-boersengaenge-der-wolf-of-wall-street-warnt-vor-icos/20490646.html)
  12. [„Warum BitCoin (jetzt aber wirklich!) TOT ist“-Kwizz](https://www.heise.de/forum/heise-online/News-Kommentare/Bitcoin-klettert-auf-ueber-7000-US-Dollar/Das-monatliche-Warum-Bitcoin-jetzt-aber-wirklich-TOT-ist-Kwizz/posting-31300715/show/)
  13. [Bitcoin Mining Electricy Consumption](https://motherboard.vice.com/en_us/article/ywbbpm/bitcoin-mining-electricity-consumption-ethereum-energy-climate-change)

  14. [BitCoin Stromverbrauch Energie](http://t3n.de/news/bitcoin-stromverbrauch-energie-872715/)
  15. [BitCoin Energy Consumption Index](https://digiconomist.net/bitcoin-energy-consumption)
  16. [BitCoin is reactionary](http://www.ianwelsh.net/bitcoin-is-a-bad-way-to-do-something-necessary/)
  17. [Skinner box](https://en.wikipedia.org/wiki/Operant_conditioning_chamber)
  18. [BitCoin bubble from 2013](https://www.forbes.com/sites/jessecolombo/2013/12/19/bitcoin-may-be-following-this-classic-bubble-stages-chart/#61f0969d36b8)
  19. [760,000 transactions per second](http://shanghaiist.com/2017/01/31/14-billion-virtual-hongbao.php)
  20. [Math proof of why lightning network won't work](https://medium.com/@jonaldfyookball/mathematical-proof-that-the-lightning-network-cannot-be-a-decentralized-bitcoin-scaling-solution-1b8147650800)
  21. [A short summary of Chinese money history](https://www.nbbmuseum.be/en/2007/09/chinese-invention.htm)
  22. [I am a time-traveler from the future, here to beg you to stop what you are doing.](https://www.reddit.com/r/Bitcoin/comments/1lfobc/i_am_a_timetraveler_from_the_future_here_to_beg/)
  23. [Decentralized and trustless crypto-paradise is actually a medieval hellhole](https://medium.com/@kaistinchcombe/decentralized-and-trustless-crypto-paradise-is-actually-a-medieval-hellhole-c1ca122efdec)

[up](squid.md) [back](squid-contracts.md)

Changes to wiki/squid-money.md.

6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

We'll mostly look into Chinese history, because all the important
inventions in currencies happened there.  Except maybe the cowry shell
money, but we don't know.

### Terms

  + Commodity money: Objects with inherent value used as money
  + Representative money: Note promising exchange with objects with
    inherent values used as money (also: promissory notes)
  + Fiat money: Medium with no inherent value and no promise for
    exchange with such an object used as money
  + Legal tender: Medium of payment by law, can be any of the above

People tend to confuse legal tender with fiat money, because nobody
would accept a fiat money if it's not a legal tender.  Or would you?
So the common English definition of “fiat money” implies that it is a
legal tender.

### Early forms of money







|
|
|
|
|
|







6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

We'll mostly look into Chinese history, because all the important
inventions in currencies happened there.  Except maybe the cowry shell
money, but we don't know.

### Terms

* Commodity money: Objects with inherent value used as money
* Representative money: Note promising exchange with objects with
  inherent values used as money (also: promissory notes)
* Fiat money: Medium with no inherent value and no promise for
  exchange with such an object used as money
* Legal tender: Medium of payment by law, can be any of the above

People tend to confuse legal tender with fiat money, because nobody
would accept a fiat money if it's not a legal tender.  Or would you?
So the common English definition of “fiat money” implies that it is a
legal tender.

### Early forms of money

Changes to wiki/squid-pow.md.

37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

## What is a BlockChain?

We need an actual definition; technically, even a git repository has
some important properties of a BlockChain.  The chain of hashed blocks
is one aspect, the consensus algorithm the other:

  + Merkle-tree or equivalent hash-it-all approach (loose definition)
  + no single point of trust
  + consensus algorithm based on the contents only (no external arbiter)

## How to cheaply secure the BlockChain

So let's take a step back, and look why there's a need for the proof of work
(the consensus algorithm): The basic idea is that of securing the BlockChain
against an attack that allows double spending.  The BlockChain itself is
immutable if you have access to the last hashed block: Through a link of







|
|
|







37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

## What is a BlockChain?

We need an actual definition; technically, even a git repository has
some important properties of a BlockChain.  The chain of hashed blocks
is one aspect, the consensus algorithm the other:

* Merkle-tree or equivalent hash-it-all approach (loose definition)
* no single point of trust
* consensus algorithm based on the contents only (no external arbiter)

## How to cheaply secure the BlockChain

So let's take a step back, and look why there's a need for the proof of work
(the consensus algorithm): The basic idea is that of securing the BlockChain
against an attack that allows double spending.  The BlockChain itself is
immutable if you have access to the last hashed block: Through a link of

Changes to wiki/squid.md.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
# The $quid – CryptoCurrency and BlockChain

![Squid](../doc/squid-logo.png)

## Abstract

*10 years after BitCoins “whitepaper”, the BlockChain and crypto
currencies are a big hype. Time to look at the results of the
experiment, see what failed and what works, check the consequences for
society, and propose improvements.*

*BitCoin's technology has three problems which need to be fixed:*

  + *The unfair distribution of coins*
  + *The energy consumption of proof of work*
  + *The non-scaleable replicated, but not partitioned ledger*

The lightning network tries to address the last point, by doing transactions
off-chain.

## Subtopic List

+ [Bullshit Bingo Sheet](squid-bingo.md)
+ [Purpose & History of Currencies](squid-money.md)
+ [Proof of What?](squid-pow.md)
+ [Speculation Objects?](squid-speculation.md)
+ [SwapDragonChain](squid-chain.md)
+ [Ethical Mining](squid-mining.md)
+ [The Decentral Bank](squid-fed.md)
+ [Dumb Contracts](squid-contracts.md)
+ [Appendix: Literature](squid-literature.md)

### Share and enjoy!

_Note: I want to point out that a service-oriented business model for free
software works, but inevitably pushes the companies into a business model,
where only the complaint department makes money.  If you don't want to stick
your head into a pig due to the depressive AI of the useless Sirius
Cypernetics Corporation products you got, make sure that there is a business
model for creating good, easy to use, and cheap to maintain software._

Incentives matter.  Economy is all about game theory.






|


|

|

|
|
|






|
|
|
|
|
|
|
|
|











1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
# The $quid – CryptoCurrency and BlockChain

![Squid](../doc/squid-logo.png)

## Abstract

_10 years after BitCoins “whitepaper”, the BlockChain and crypto
currencies are a big hype. Time to look at the results of the
experiment, see what failed and what works, check the consequences for
society, and propose improvements._

_BitCoin's technology has three problems which need to be fixed:_

* _The unfair distribution of coins_
* _The energy consumption of proof of work_
* _The non-scaleable replicated, but not partitioned ledger_

The lightning network tries to address the last point, by doing transactions
off-chain.

## Subtopic List

* [Bullshit Bingo Sheet](squid-bingo.md)
* [Purpose & History of Currencies](squid-money.md)
* [Proof of What?](squid-pow.md)
* [Speculation Objects?](squid-speculation.md)
* [SwapDragonChain](squid-chain.md)
* [Ethical Mining](squid-mining.md)
* [The Decentral Bank](squid-fed.md)
* [Dumb Contracts](squid-contracts.md)
* [Appendix: Literature](squid-literature.md)

### Share and enjoy!

_Note: I want to point out that a service-oriented business model for free
software works, but inevitably pushes the companies into a business model,
where only the complaint department makes money.  If you don't want to stick
your head into a pig due to the depressive AI of the useless Sirius
Cypernetics Corporation products you got, make sure that there is a business
model for creating good, easy to use, and cheap to maintain software._

Incentives matter.  Economy is all about game theory.

Changes to wiki/topology.md.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
..
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
..
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
# Topology

net2o assumes a hierarchical topology, i.e. a tree topology. &nbsp;There may
be multiple paths reaching the same destination, so this doesn't exclude that
parts of the tree are actually mesh networks. &nbsp;This reflects reality in
the current Internet, and the expensive layer 1 infrastructure isn't likely to
be replaced soon.

Most connections send a larger number of packets, so routing each packet is
wasteful, drives up costs and lowers speed. &nbsp;Therefore the decision is to
switch packets, and route connections - at the source. &nbsp;I call this
combination

## Path Switching

The path is a 128 bit field in the packet, the switching algorithm is as
follows:

................................................................................
* Take the first _n_ bits of the path field and use those to select
  the destination
* Shift the path field by _n_ bits to the left
* Insert the bit-reversed _n_ bit source into the rear end of the
  path field to mark the way back

The receiver bit-reverses the entire path, and thereby gets a way back to
the sender. &nbsp;This makes spoofing impossible, and eases
[handover](handover.wiki), as only the device that
switches networks needs to calculate a new path; the receiver will accept any
properly authenticated packet and use the new path to send data back.

## Packet Format

Packets have a power-of-two size from 64 bytes to 2MB data. Assuming network
................................................................................
The packet contains these elements:

1. 2 bytes flags: 2 bits QoS (00 highest to 11 lowest), 2 bits
   protocol version (default is now 01), 4 bits packet size
   (64\*2^_n_), 2 bit switch flags (broadcast, multicast), 3 bits
   reserved, 3 bits for flow control (resend-toggle, burst-toggle,
   ack-toggle).
2. 16 bytes path (rough Internet 1.0 equivalent: "address")
3. 8 bytes address: this is the address in the destination buffer where the
   packet will be stored (roughly equivalent to port+sequence number)
4. 64\*2^_size_ bytes data
5. 16 bytes authentication data (keyed cryptographic checksum)

The "abstraction" at packet level is shared memory; the model is read
locally and write remotely (you can't read remotely, you can ask for the other
side to send you packets). &nbsp;Of course, the addresses are virtual, so you
can't write into arbitrary memory - only into the buffers provided by the other
side.

## Why Source Routing?

There are three possible schemes:

1. switched circuit (POTS, virtual: ATM, MPLS)


|

|




|
|







 







|







 







|





|

|
|







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
..
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
..
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
# Topology

net2o assumes a hierarchical topology, i.e. a tree topology.  There may
be multiple paths reaching the same destination, so this doesn't exclude that
parts of the tree are actually mesh networks.  This reflects reality in
the current Internet, and the expensive layer 1 infrastructure isn't likely to
be replaced soon.

Most connections send a larger number of packets, so routing each packet is
wasteful, drives up costs and lowers speed.  Therefore the decision is to
switch packets, and route connections  at the source.  I call this
combination

## Path Switching

The path is a 128 bit field in the packet, the switching algorithm is as
follows:

................................................................................
* Take the first _n_ bits of the path field and use those to select
  the destination
* Shift the path field by _n_ bits to the left
* Insert the bit-reversed _n_ bit source into the rear end of the
  path field to mark the way back

The receiver bit-reverses the entire path, and thereby gets a way back to
the sender.  This makes spoofing impossible, and eases
[handover](handover.wiki), as only the device that
switches networks needs to calculate a new path; the receiver will accept any
properly authenticated packet and use the new path to send data back.

## Packet Format

Packets have a power-of-two size from 64 bytes to 2MB data. Assuming network
................................................................................
The packet contains these elements:

1. 2 bytes flags: 2 bits QoS (00 highest to 11 lowest), 2 bits
   protocol version (default is now 01), 4 bits packet size
   (64\*2^_n_), 2 bit switch flags (broadcast, multicast), 3 bits
   reserved, 3 bits for flow control (resend-toggle, burst-toggle,
   ack-toggle).
2. 16 bytes path (rough Internet 1.0 equivalent: address)
3. 8 bytes address: this is the address in the destination buffer where the
   packet will be stored (roughly equivalent to port+sequence number)
4. 64\*2^_size_ bytes data
5. 16 bytes authentication data (keyed cryptographic checksum)

The abstraction at packet level is shared memory; the model is read
locally and write remotely (you can't read remotely, you can ask for the other
side to send you packets).  Of course, the addresses are virtual, so you
can't write into arbitrary memory  only into the buffers provided by the other
side.

## Why Source Routing?

There are three possible schemes:

1. switched circuit (POTS, virtual: ATM, MPLS)