Community modals (#11, #32) #41

QR codes now reside in output/qr-codes; this exposes users to a tracking vector until further addressed.

QR codes now reside in `output/qr-codes`; this exposes users to a tracking vector until further addressed.

WIP commentary:

a) What's the reason behind qr-codes not being in the cache folder anymore?

b) In theory SOGS can change their domain or IP but keep the same public key, therefore previously downloaded QR codes will be invalid. From a quick glance this edge case is not handled.

c) Please elaborate on the tracking vector.

WIP commentary: a) What's the reason behind qr-codes not being in the cache folder anymore? b) In theory SOGS can change their domain or IP but keep the same public key, therefore previously downloaded QR codes will be invalid. From a quick glance this edge case is not handled. c) Please elaborate on the tracking vector.

@SomeGuy
a) The qr-codes folder is not in the cache folder anymore because the codes are now being served over HTTP, and the only place exposed to the web is the output folder. This is the solution to #11 that I've opted for. This way, QR code images can be referenced as web URLs in the site instead of shipping duplicates of base64 / relying on parsed base64 as a single source of truth to hydrate the modal. QR codes should still not be tracked by Git.

b) Yes, IP or domain changes break our QR codes, but this is not a new issue, and such a move displaces current users in Session clients too. In case of VPS compromise, one ought not to use the same key anyway. If hostname changes are a concern, then we can take a look at introducing an extended room identifier for use with QR codes, including a hostname hash.

c) Tracking can occur by us when users view a certain details modal and load the QR code on demand from our servers. Furthermore, not prefetching these codes causes flickering of the QR code when hydrating the modal.

@SomeGuy a) The `qr-codes` folder is not in the `cache` folder anymore because the codes are now being served over HTTP, and the only place exposed to the web is the `output` folder. This is the solution to #11 that I've opted for. This way, QR code images can be referenced as web URLs in the site instead of shipping duplicates of base64 / relying on parsed base64 as a single source of truth to hydrate the modal. QR codes should still not be tracked by Git. b) Yes, IP or domain changes break our QR codes, but this is not a new issue, and such a move displaces current users in Session clients too. In case of VPS compromise, one ought not to use the same key anyway. If hostname changes are a concern, then we can take a look at introducing an extended room identifier for use with QR codes, including a hostname hash. c) Tracking can occur by us when users view a certain details modal and load the QR code on demand from our servers. Furthermore, not prefetching these codes causes flickering of the QR code when hydrating the modal.

There seems to be a minor issue in tbl_communities.php

Seems like return " title='Click to sort by $name'."; is supposed to be return " title='Click to sort by $name.'";, but I can't fix it right now because of SSH authentication issues.

![image](/attachments/68f830be-629d-401b-8f8f-41e1aaeaaf74) There seems to be a minor issue in `tbl_communities.php` Seems like `return " title='Click to sort by $name'.";` is supposed to be `return " title='Click to sort by $name.'";`, but I can't fix it right now because of SSH authentication issues.

image.png

67 KiB

Labels Milestones

Community modals (#11, #32) #41