Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding a "contact point" fixed-length field to ad serialization #1

Open
ZmnSCPxj opened this issue Sep 16, 2019 · 1 comment

Comments

@ZmnSCPxj
Copy link
Collaborator

ZmnSCPxj commented Sep 16, 2019

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:

  1. An advertiser is concerned about privacy for itself and its potential customers, thus uses a Tor v3 address.
  2. 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.

@tamasblummer
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants