First attempt to write some privacy considerations #501
Conversation
This ended up in more text that I thought. I'm not certain if we need all of it. Further I'm unsure about the concrete wording in many cases, so any comments are more than welcome!
|
This is supposed to address issue #177 |
|
I do mentioned name resolution, however, leakage though DNS might rather be a DNS problem and not necessarily an issue that needs to be considered in taps. Sharing cache state is a good point. I vaguely remember that we already address that somewhere else (could also be in the implementation draft as this is rather an implementation issue). But maybe we can add a pointer...? |
|
Leakage though DNS may need to be addressed by TAPS, as with the current sockets API, the application has complete control about when DNS resolution is done (and, at least as long as things like DoH/DoT are predominantly implemented by nonsystem resolver libraries, how). TAPS as envisioned gives the system more control over resolution. |
|
(IIRC the architecture does explicitly address and mention the shared cache issue; adding a line to refer to that in privacy considerations might be nice but isn't IMO necessary.) |
Some nits and typos
draft-ietf-taps-interface.md
Outdated
|
|
||
| The desribed API is used to exchange information between an application and the transport system. While | ||
| it is not necessarily expected that both systems are implemented by the same authority, it is expected | ||
| that the transport system implementation is either provided as library that is selected by the application |
draft-ietf-taps-interface.md
Outdated
| from a trusted party, or that it is part of the operating system that the application also relies on for | ||
| other tasks. | ||
|
|
||
| In any case the TAPS API is an internal interface that is used to change information locally between two systems. |
There was a problem hiding this comment.
/In any case/In either case/ ?
- and add comma?
draft-ietf-taps-interface.md
Outdated
| potentially share any information provided by the application with the network or another communication peer. | ||
| Most of the information provided over the TAPS API are useful to configure and select protocols and paths | ||
| and are not necessarily privacy sensitive. Still, there is some information that could be privacy sensitve as | ||
| it might reveal usage characteristics and habits of the user of an application. |
draft-ietf-taps-interface.md
Outdated
| and are not necessarily privacy sensitive. Still, there is some information that could be privacy sensitve as | ||
| it might reveal usage characteristics and habits of the user of an application. | ||
|
|
||
| It should first be noted that of course any communication over a network reveals usage characteristics, as all |
There was a problem hiding this comment.
/It should first be noted/
-Could be deleted top read easier?
draft-ietf-taps-interface.md
Outdated
|
|
||
| It should first be noted that of course any communication over a network reveals usage characteristics, as all | ||
| packets as well as their timing and size are part of the network-visible wire image {{?RFC8546}}. However, of | ||
| course the selection of a protocol and its configuration impacts which information is visible, potentially in |
There was a problem hiding this comment.
/of course/
- could be deleted?
draft-ietf-taps-interface.md
Outdated
| It should first be noted that of course any communication over a network reveals usage characteristics, as all | ||
| packets as well as their timing and size are part of the network-visible wire image {{?RFC8546}}. However, of | ||
| course the selection of a protocol and its configuration impacts which information is visible, potentially in | ||
| clear text, to which other enties. In most cases information that is provided for protocol and path selection |
There was a problem hiding this comment.
/to which other entities/
- seem to read wrong.. is this: and the other entities that can access this, or something else?
draft-ietf-taps-interface.md
Outdated
| packets as well as their timing and size are part of the network-visible wire image {{?RFC8546}}. However, of | ||
| course the selection of a protocol and its configuration impacts which information is visible, potentially in | ||
| clear text, to which other enties. In most cases information that is provided for protocol and path selection | ||
| should not directly translate in information that is visible on the path. But there might be specific configuration |
There was a problem hiding this comment.
/in information/to information/?
/that is visible on the path/... /that can be observed by netwoprkl devices on the path/?
draft-ietf-taps-interface.md
Outdated
| benefit from innovations and new protocols in the transport system but at the same time may reduce transparency of the | ||
| underlying communication actions to the application itself. The TAPS API is designed such that protocol and path selection | ||
| can be limited to a small and controlled set if required by the application for functional or security purposes. Further | ||
| TAPS implementations should provide an interface to pull information about which protocol and path is currently in use as |
There was a problem hiding this comment.
/Further,/
"pull" ... probably a better word is needed... is this "provide"
draft-ietf-taps-interface.md
Outdated
| underlying communication actions to the application itself. The TAPS API is designed such that protocol and path selection | ||
| can be limited to a small and controlled set if required by the application for functional or security purposes. Further | ||
| TAPS implementations should provide an interface to pull information about which protocol and path is currently in use as | ||
| well as provide logging about communication events of each connection. |
There was a problem hiding this comment.
insert /the/ before /communications/
|
Gorry, I addressed all your nits/comments. |
This ended up in more text that I thought. I'm not certain if we need all of it. Further I'm unsure about the concrete wording in many cases, so any comments are more than welcome!