Link previews #327
Comments
My notes
|
Community
Channel
User
Group
|
|
@endulab @cammellos could you please confirm that we're currently not publicly broadcasting group chat details (i.e. photo, emoji, name, members count, color), and if so help me create and estimate issues for related repos? Cc @pedro-et (for sanity check on the required fields) |
|
@felicio we will handle only 1. community, 2. channel and 3. user links. |
Sharing links to ad-hoc group chats (with group chat name, image, etc...) is out of scope for MVP, but highly likely to be something we will do shortly after MVP (while preserving the current fully private group chat functionality of course - users would effectively have the choice of converting a private ad-hoc group chat into a publicly sharable ad-hoc group chat if they wanted to). The design for such post-MVP 'sharable ad-hoc group chat' functionality is tbd. Post MVP we will also be introducing many more types of URL links (e.g. links to request money including a message, links to individual messages in communities or 'open' ad-hoc group chats, etc..). But we don't need to worry about this for now, because we have more than enough items that are in-scope for MVP that we need to direct our energies towards. |
1 similar comment
Sharing links to ad-hoc group chats (with group chat name, image, etc...) is out of scope for MVP, but highly likely to be something we will do shortly after MVP (while preserving the current fully private group chat functionality of course - users would effectively have the choice of converting a private ad-hoc group chat into a publicly sharable ad-hoc group chat if they wanted to). The design for such post-MVP 'sharable ad-hoc group chat' functionality is tbd. Post MVP we will also be introducing many more types of URL links (e.g. links to request money including a message, links to individual messages in communities or 'open' ad-hoc group chats, etc..). But we don't need to worry about this for now, because we have more than enough items that are in-scope for MVP that we need to direct our energies towards. |
@endulab please,
|
|
|
@endulab thank you, and to follow up
Let me try to rephrase then. Will, or can, desktop open and handle links starting with
Which technically is the community's compressed public key later then used for content topic and symmetric key, correct? If not, could you make a reference to the code? |
Oh, I see. The app can't do it right now, but we can try to do it this way. However, I understand that if we have universal links, the app will be opened directly w/o need of our website. Is it the workflow we want to have ? I will have to do some research how to do this. Also, we need this functionality on Windows. Let me know if we need this feature; I will create the ticket then.
Yes, the community key in the community channel key is a 33-bytes compressed public key. However, in order to expose keys, we use a different compression, which is called "multiformat" compression - zQ3sh........ |
Yes, both desktop and mobile should open and handle links starting with https:// , it's really important that they do this. @endulab the URL format is going to change, @felicio @prichodko are working on some improvements to the URL format so I'll set up a call so we can discuss later in the week |
|
@John-44 please, could you review the individual "Matrix: Community" and "Matrix: Channel" sheets at https://docs.google.com/spreadsheets/d/1JD4kp0aUm90piUZ7FgM_c2NGe2PdN8BFB11wmt5UZIY/edit?usp=sharing and let me know if data encoded and total url lengths, from the product point of view, are worth not using and exposing public keys to servers? While the final encoding may undo some of the compression causing the total number to go up or down by ~5%, I do believe it can be stabilized and further reduced (e.g. LZ compression, text trimming) but still placing it somewhere between 150-250 characters. |
|
|
|
@Samyoul gave me a great feedback:
@Samyoul , @cammellos , @richard-ramos , @iurimatias , @saledjenic , @jakubgs , @fryorcraken, @prichodko I was going to propose an extension to status-im/specs#159 in form of a single url search parameter carrying the serialized, compressed and encoded content as per "Matrix:*" sheets at https://docs.google.com/spreadsheets/d/1JD4kp0aUm90piUZ7FgM_c2NGe2PdN8BFB11wmt5UZIY/edit?usp=sharing. However after considering the above, I now propose For the url scheme:
For clients:
And for the infrastructure:
Please, would you agree?
|
|
If we are re-doing deep links the we need to revisit using hash arguments to preserve privacy. Using paths or URL arguments means the paths end up on the backend side. If we use hash arguments we prevent whatever is hosting the deep-linking UI from knowing what people are actually linking. |
|
As for the |
|
@jakubgs thank you,
that is true, even for whatever backend/server is generating the previews, however without an access to the public key I cannot fetch content like profile images from Waku nor verify the encoded content in url. Because if it contained a signature the public key could be recovered anyway. On the other hand, and considering "IPNS's hashes of public keys instead, probably of those used for chatting" I've mentioned above, I think the verification could be done by comparing the hashes after visiting the urls (and in our apps even before clicking or resolving). But previews outside our apps would still need to be considered untrusted, I believe. @rymnc @s1fr0 it might be a reach mentioning you on this issue, but I'm convinced your take on the matter:
would be helpful. |
|
@felicio, thanks for the tag - let me get up to speed with this issue and let you know soon |
|
Following has been decided to address above mentioned concerns in short term,
limiting proposals to following two,
@John-44 please, could you confirm with 👍 or otherwise comment below? Also, do let me know if I should schedule a call and clarify anything. Cc @prichodko
|
|
At the beginning I pointed out,
Please, where are these being addressed/tracked now? Cc @John-44 |
|
@felicio I created 2 tasks for MacOS and Windows: |
|
In addition to #327 (comment),
Cc @John-44 |
|
@endulab @cammellos probably obvious (so apologies for stating the obvious) , and I'm not sure if this is the correct place to mention this, but the generation of this URL needs to happen in status-go so the same URL generation code can be used by both Status Desktop and Status Mobile |
Cc @pedro-et |
|
@felicio apologies for the delay, created issue on mobile side status-im/status-mobile#15325 |
|
I see we have introduced a The goal is preserve annonimity of users, and this scheme does allow for correlating the IP with most of the URL on backend. |
That, as well as public keys or ENS names.
To ensure integrity of the encoded content. More on that at status-im/specs#169 (comment).
No, as per above. Also, since we're using secp256k1, public keys can be recovered on the client side from the encoded content and the signature.
The now encoded content could also be moved after the hash. Which would however mean that none of it could be used in social previews/cards. Cc @John-44 |
Any data that identifies what channel/person/group the link is for.
I discussed it with myself. My understanding is that the things before the hash still reveal information about what channel/person/group is being linked and that can be correlated with IP and also client data. Is my understanding correct then that this decision is between preserving privacy and not being able to do previews, and not preserving privacy but having fancy previews? |
Based on the above, I thought you have discussed this with others thus could provide more context as to who and why exactly. If not, no worries. My other questions were just to figure out whether your concern was only public keys or other (encoded) content too, and simply note the implication. @John-44 please, could you leave a comment here addressing the following concern @jakubgs has raised? I could then make changes accordingly, if necessary.
|
|
Yes there is a trade between privacy / adoption here, because yes a sufficiently determined attacker could perform a correlation attack (however to do so in this instance would not be trivial). This has already been discussed a bunch, and it was from this discussion that the decision to not have images in unrolls (so the keys would be shielded by the # from the server) but to have URL specific metadata in unrolls (at the cost of exposing this metadata to the server) was made. It might be a good idea to log a feature request in https://status-desktop.featureupvote.com/ for post MVP that is titled something like "give users option to share URLs without metadata for privacy purposes". Then we can give the user the choice of whether or not they want to share A) URLs that unroll nicely with meta info but where the server also sees this meta info or B) URLs that don't contain the meta info but which also don't contain any URL specific content in the unroll. Such as feature would not be for MVP because we are busy trying to cut scope, and we really can't afford to add scope at the moment. For MVP the decision has been made to go with the trade I've described above |
|
Very well, if this is a conscious trade off that people are ware of, fair enough. |
|
I think it's fine if we add an option to have the privacy preserving URLs without nice previews for users to pick in the UI later on, as long as we actually remember to do that. And not just keep it as a "nice to have" forever. |
|
Closing in favor of https://github.com/orgs/status-im/projects/91 for tracking. |
What
How
Current:
Branch:
Relates:
ñchar is present in the title and the length is 30 chars status-desktop#6032The text was updated successfully, but these errors were encountered: