| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hmm, my understanding is that we intentionally avoids strings to avoid binary bloat. +12k for debugging is probably unacceptable. Adding nico...@chromium.org to confirm.
We have a script to convert hash to string. For the bug case:
```
$ vpython3 tools/traffic_annotation/scripts/auditor/hashes.py | grep 114234406
kiosk_app_icon 114234406
```
Is it sufficient for debugging?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hmm, my understanding is that we intentionally avoids strings to avoid binary bloat. +12k for debugging is probably unacceptable. Adding nico...@chromium.org to confirm.
We have a script to convert hash to string. For the bug case:
```
$ vpython3 tools/traffic_annotation/scripts/auditor/hashes.py | grep 114234406
kiosk_app_icon 114234406
```Is it sufficient for debugging?
(opening)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hmm, my understanding is that we intentionally avoids strings to avoid binary bloat. +12k for debugging is probably unacceptable. Adding nico...@chromium.org to confirm.
We have a script to convert hash to string. For the bug case:
```
$ vpython3 tools/traffic_annotation/scripts/auditor/hashes.py | grep 114234406
kiosk_app_icon 114234406
```Is it sufficient for debugging?
Ah, that's nice. Let me change the ReportBadMessage just output the id instead of the string.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Yoichi OsatoHmm, my understanding is that we intentionally avoids strings to avoid binary bloat. +12k for debugging is probably unacceptable. Adding nico...@chromium.org to confirm.
We have a script to convert hash to string. For the bug case:
```
$ vpython3 tools/traffic_annotation/scripts/auditor/hashes.py | grep 114234406
kiosk_app_icon 114234406
```Is it sufficient for debugging?
Ah, that's nice. Let me change the ReportBadMessage just output the id instead of the string.
Hmm, my understanding is that we intentionally avoids strings to avoid binary bloat. +12k for debugging is probably unacceptable. Adding nico...@chromium.org to confirm.
Correct. IIRC there was also a concern around the runtime cost of passing the string with each request. I don't think we ever benchmarked it.
12.7KiB is a *little* large... this won't(?) be used often, and we already have a two-way mapping in the form of `hashes.py`. So probably not worth it IMO
If the problem is that `hashes.py` is not discoverable enough, maybe we can try a slightly different approach that doesn't affect binary size? Like adding the hashed ID in `annotations.xml`, so you can trivially find it with codesearch.
"traffic_annotation_id=",
traffic_annotation.unique_id}));if we use the hash instead: maybe mention `hashes.py` in this message, so it's more discoverable
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Yoichi Osato abandoned this change.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |