I have:
When sending hyperlinks, Signal currently displays no previews.
This may be a feature lowering adaptation of Signal, as with #5445.
_Google Allo_
_Telegram_
Greets.
I would rather a feature like this be optional and off by default. It will just generate more traffic and create unnecessary potential security holes. Perhaps when a link is created or detected by Signal, Signal could offer a checkbox or option to include a hyperlink preview into the mix.
I agree with @TimesEnemy that this is at least a privacy issue and can also be a security issue concerning automatic loading of content from literally any source.
WhatsApp does this on the client-side and only for the sender. When the sender types a link in the compose box WA detects it and fetches a preview.
Desktop version also needs this :)
Having the sender generate the preview is reasonable, i guess. A checkbox (that remembers the previous choice) would be great, as i'd propably never want to use this feature.
Preview is a horrible privacy killer. Why even bother to use Signal if you want this? Just use Fb messenger or WhatsApp. Please close issue as N/A.
At least in iMessage this feature sucks ;-) http://rsmck.co.uk/blog/imessage-preview/
@E3V3A what's wrong with the approach proposed in this thread?
To me that looks like a zero privacy issue for the recipient. The current model sucks from usability perspective.
Only the last step should be needed in a modern messenger.
i like the proposal of @oittaa . Eleminate the privacy issue by only letting the sender device download stuff and put the result in a message. I'd like to see that feature for random cat content gif urls I paste in the text field. Like Telegram does, but with only let my device download it.
This is one of my favorite features in other IMs. I see some comments about security / privacy issues but they are not giving any examples. I can't think of any issue with that and i'm interested to know.
Actually, I find myself often not needing to open the link because I already know what the link is about so if anything, it's a 馃憤 for privacy / security :-)
Anyway, it's a huge plus for usability IMO.
There is a library for fetching the preview information like this
https://github.com/LeonardoCardoso/Android-Link-Preview/
So when someone pastes/type in/shares a link, it shouldn't be that hard to use this to fetch the preview information. Then this could be sent as some kind of attachment with the link.
I would also love to see this.
Like others, I cannot see a privacy/security issue -- if I am sharing the link then I have visited it on my phone and there is no additional privacy risk by loading those links again through Signal (though Tor browsing would have to be managed).
As somebody else said, there is much more risk in me clicking an unexplained YouTube link that, in hindsight, I would rather not have viewed on work WiFi etc.
This feature in WhatsApp got some attention here:
https://twitter.com/mulander/status/874370124932943874
The WhatsApp app seems to attempt fetching a preview while you are typing a URL, like:
https://github.com/W
https://github.com/Wh
https://github.com/Whi
https://github.com/WhisperSystems
Fetching is done on the sender's phone as suggested in this thread but the user agent seems to be exposed under certain conditions. If the user types the URL manually or pastes it from somewhere (not a browser) he/she didn't necessarily visit the URL (at least from the device he/she is using at the moment). If we decide to implement this, we should be careful.
IMO this feature is needed especially for users willing to switch from WhatsApp.
Additional idea:
When sharing a weblink, Twitter for example generates an image preview of the webpage, which automatically focuses on a certain place of the webpage. This place is usually the header text of the article or blogpost.
For signal I would propose to do a simulair thing, but with one addition: allow to user to edit the scroll position of the preview.
More in detail:
<main> <div id='main'> <div class="main"> <header> <article> <h1> and microdata attributes.
These suggestions might be ambigious, but on long term these could be implemented (not nessesarily all at once). I just post them here now so the idea is open to discussion.
GitHub Issue Cleanup:
See #7598 for more information.
Most helpful comment
@E3V3A what's wrong with the approach proposed in this thread?
To me that looks like a zero privacy issue for the recipient. The current model sucks from usability perspective.
Only the last step should be needed in a modern messenger.