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
An ad is pointless if there is no way to respond to the ad.
Thus, we can expect that most ad texts will include also, some way to contact the advertiser, most likely via a website.
However, consider the cases below:
An advertiser is concerned about privacy for itself and its potential customers, thus uses a Tor v3 address.
An advertiser could not possibly care less about privacy, and thus uses a link compressor.
Not only can the ISP of the advertiser and the customer learn about the connection between them, but also the link compressor service learns about every customer that uses the compressed link.
The advertiser might inadvertently use some low-level software that includes in its logs about IP addresses of accessors of the advertiser website, which might be acquired by third parties without knowledge of the advertiser.
Thus, roughly speaking we can expect a massive loss in privacy in case 2 compared to case 1.
But advertisers using case 1 will be penalized compared to those in case 2, due to simply the number of characters involved.
Thus I propose, the addition of a required field, 33 bytes in length in the serialization, to serve as the link or "contact point" for someone to respond to the advertisement. With Tor v3, it can instead store the ED25519 curve point, with the software automatically translating it to/from a .onion address. For non-Tor-v3 usages, it could be a plaintext link.
The first byte could encode an enumeration, such as "no link", "Tor v3 with point having positive Y coord", "Tor v3 with point having negative Y coord", "ascii link" etc.
The principle, is that we should design our software to reduce useability-to-privacy tradeoffs.
The text was updated successfully, but these errors were encountered:
I agree with your observation, which goes much further than we have now. I focused on proving the concept and spent the bare minimum on network serialization. It is auto-generated in CBOR format for now. If reworking that, your comments should be incorporated.
An ad is pointless if there is no way to respond to the ad.
Thus, we can expect that most ad texts will include also, some way to contact the advertiser, most likely via a website.
However, consider the cases below:
Thus, roughly speaking we can expect a massive loss in privacy in case 2 compared to case 1.
But advertisers using case 1 will be penalized compared to those in case 2, due to simply the number of characters involved.
Thus I propose, the addition of a required field, 33 bytes in length in the serialization, to serve as the link or "contact point" for someone to respond to the advertisement. With Tor v3, it can instead store the ED25519 curve point, with the software automatically translating it to/from a .onion address. For non-Tor-v3 usages, it could be a plaintext link.
The first byte could encode an enumeration, such as "no link", "Tor v3 with point having positive Y coord", "Tor v3 with point having negative Y coord", "ascii link" etc.
The principle, is that we should design our software to reduce useability-to-privacy tradeoffs.
The text was updated successfully, but these errors were encountered: