You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
and either transmitting that information to a specific user defined location or transmitting this
14
+
information with Crypto Tools.
15
+
8
16
### Conventions used in this document
9
17
10
18
The key words
@@ -20,7 +28,7 @@ versions of these libraries have no logging or metrics publishing
20
28
to either a local application or to an observability service like AWS CloudWatch.
21
29
22
30
As client side encryption libraries emitting metrics must be done carefully as
23
-
to avoid accidentally [leaking](https://github.com/aws/aws-encryption-sdk-python/pull/105/files) any information related to the plaintext that could lead to a
31
+
to avoid accidentally leaking any information related to the plaintext that could lead to a
24
32
loss of customer trust.
25
33
26
34
A popular feature request has been for in depth insights into CT libraries. Many customers
@@ -38,7 +46,7 @@ a better customer experience.
38
46
### Issue 1: What will be the default behavior?
39
47
40
48
As a client-side encryption library CT should be as cautious as possible.
41
-
Customers of CT libraries should be on the driver seat and determine for
49
+
Customers of CT libraries should be in the driver's seat and determine for
42
50
themselves if their application could benefit from emitting metrics.
43
51
Making that decision for customers can erode customer trust.
44
52
@@ -61,7 +69,7 @@ will not change. Perhaps a bold implication this is ultimately what the customer
61
69
will feel like; getting no choice on the matter and opting to not upgrade.
62
70
Going from never emitting metrics to always emitting them says to customers
63
71
that their application no matter its use case will always benefit from metrics.
64
-
Without letting customers make that choice, CT looses hard earned customer trust.
72
+
Without letting customers make that choice, CT loses hard earned customer trust.
65
73
66
74
This also forces customers to make a choice, start collecting metrics and pick up
67
75
additional updates CT provides or get stuck in a version of the library that will
@@ -100,6 +108,19 @@ Keeping in line with the rest of CT features, a well defined interface with out
100
108
of the box implementations should satisfy the feature request.
101
109
102
110
Out of the box implementations should cover publishing metrics to an
103
-
existing observability service like AWS CloudWatch and to the local file system.
111
+
existing observability service like AWS CloudWatch and to the local file system using
112
+
a hardened framework for that particular language implementation.
104
113
These implementations should offer customers a guide into implementing their own
105
114
if they wish to do so.
115
+
116
+
### Issue 4: Should out of the box solutions be custom implementations
117
+
118
+
#### No (recommended)
119
+
120
+
There is no need to reinvent the wheel. Other metric frameworks have solved many
121
+
of the issues that are described above, (e.g. handling failing requests, perform
122
+
blocking requests to CT libraries, use a separate thread/thread pool that handles
123
+
these request). By just providing a wrapper, customers can use the framework they
### Issue 0: Should Metric Agents be supported on client construction?
181
+
182
+
#### Yes
183
+
184
+
#### No
185
+
186
+
## Appendix
187
+
188
+
The following API changes are not complete. These changes assume that the new optional parameter is supplied to any additional downstream consumer that may or may not be listed here.
0 commit comments