toxcore
toxcore copied to clipboard
irungentoo
Implement Stickers.
This is a copy of an issue I submitted to tux3/qtox. Developers should decide whether or not special types of file transfers designated as auto-accepted inline images belong in core or not. This decision likely also affects inline auto-accepted audio messages, and other non-sticker things like that.
Emoticons and emoji have been popular almost since instant messaging began. They are small, inline images, that typically replace typed-in, ASCII-character smilies. Emoji are usually differentiated by being represented by the actual unicode characters for what they depict.
qTox currently implements emoticons/emoji by displaying text smilies as graphical ones, and also by offering a panel of graphical smilies that are sent as unicode characters. There is currently one nonstandard graphical smiley in qTox that illustrates an important point: the :Kappa: face.
With emoticons/emoji, you have to worry about what the other person is going to see. This is exacerbated by the free and open nature of Tox. You have no guarantee that other people's clients will display emoticons the same way yours does. This often leads to confusing mishaps, such as emoticons getting inserted where they don't belong, or people not understanding the intended message due to clients using different graphical emoji. The :Kappa: face is exemplary. It's just a joke, and not likely something that other clients will or should implement. But many users WANT to send silly things like that, and have their friends see the intended image. Other users want nothing to do with that, and will be displeased if faces pop up in unrelated text (which does happen, no matter how obscure the replacement strings try to be.)
Emoticons and emoji are from the days of singular, exclusive clients, tied to singular, exclusive servers. Tox breaks free from this paradigm, and this makes it uniquely suited to the new paradigm that many other popular messaging services have already embraced: stickers.
Stickers are inline images that are much larger than single-character emoticons or emoji. They can be animated, and for our purposes they could even be webms. The main difference is that stickers are files that get sent. There's no worrying- your friend will see exactly what you mean to send. We don't need closed systems to regulate emoticon replacement, and all the hassle that causes, and we have plenty of bandwidth to send proper images now. It's time that we do so.
Stickers are the perfect platform to demonstrate the benefits of openness and freedom in a very immediate and concrete way. We know that users love stickers on closed systems like Facebook and Path, and with a freedom-oriented system like Tox, everyone can easily make and share their own, fostering the sort of incredible creative community that makes something more than just another app.
To recap:
- Stickers solve problems that arise when emoticons are used for more than they're meant for. Emoticons are great for standard smilies; stickers are right for everything else.
- Stickers cure headaches caused by string replacement and unicode problems.
- Stickers are a feature that users love, and will prove to be just another bonus of Tox.
- Stickers can show average users why freedom is better.
I suggest copying Facebook's sticker interface implementation, as it's clean, well-known, and working, and then making improvements where needed through further FOSS evolution. Thanks for reading.
Related:
https://github.com/irungentoo/toxcore/issues/1080
https://github.com/irungentoo/toxcore/issues/1084
Kappa is what all true warriors should strive for! But no, honestly, +1 for kappa.
As long as the client can decide on whether or not to NOT show these emoticons, it should be fine.
Reason I'm saying that is - imagine your friend gets drunk and starts sending you R-18 rated stickers - and you're visiting someone and you don't want them to see that.
Please refer to stickers as stickers instead of emoticons, due to the technical differences I outlined in the OP, so we can avoid confusion.
And of course clients can offer the option to turn them off, maybe display them on hover, anything the client dev likes. But before that they have to be implemented. Maybe as a subset of a general auto-accept-and-display-inline type of file transfer in core, that would allow for inline audio and video messages too, and other things in the future.
Closed as won't implement? Or closed due to stale?
Tickets don't need an update every month to show they're still needed.
The problem with all binary data is that, it could be used to hide other malicious things in it. This is the reason why I would prefer to send plain text SVG and animated SVG. Yes, they are animated SVG.
@Jeeppler Check out the WIP spec, svgs would be awesome.
If exploits are getting in through images, though, that's a bug with the image lib.
@ProMcTagonist you always have a problem with binary files. They can contain anything, but SVG can be parsed, part's extracted or transformed.
It does not have to be just a bug, you can also put your executable into an image file and activate it through another channel.
Thanks for the WIP spec, interesting.
Since no of the standard image formats png and jpg having support for animation and gif sucks. I would prefer to just concentrate on a proper SVG animation implementation.
Have a look here: http://wiki.inkscape.org/wiki/images/Bouncing_ball2.svg
@Jeeppler
Since no of the standard image formats png and jpg having support for animation and gif sucks. I would prefer to just concentrate on a proper SVG animation implementation.
Right. Note though that feature should be usable by normal users - they certainly don't know the difference between jpg and png, although they might know that gif is "the moving image". By limiting to svg, feature becomes useless for >99% of users.
What I would want to say, is that using svg for animations does sound like an awesome idea, but feature shouldn't be limited to it - unless there's a clever way to allow conversion binary img → svg, including animated "images" ?
@zetok for me a sticker comes in a pack of stickers. Let's say in a pack of stickers are 10 stickers with a dog motive and another pack with 7 stickers with an penguin motive. In the first pack there is a happy birthday dog, an angry dog, an dog with flowers between his teeth, a drunk dog, teacher dog etc. For the penguin stickers, there are: kissing penguins, angry penguin, student penguin, professor penguin, dancing penguins and so on. All of those stickers are animated. This is pretty much how Facebook uses stickers: in packs.
But it is important to note that creating animated stickers is not easy for most people. So, most people download the sticker packs (in Facebook select them) and use them. This means I don't see a problem in using SVG. For me the real challenge is to get people to create high quality animated sticker packs and distribute them.
@zetok
conversion binary img → svg
No, I've tried, they look awful.
@Jeeppler Stickers must be able to be created by lots of typical artists. Most artists cannot create animated (or normal) SVGs easily. Therefore, stickers will not be restricted to SVG.
@GrayHatter :)
@ProMcTagonist is this just your opinion or do you know artists which don't know SVG or better vector graphics in common?
@Jeeppler People other than artists make stickers too. If it was SVG I'd have to learn how to make those for shitty inside jokes. And for me, using the magic wand on GIMP is hard enough.
@wallnutkraken +1, they need to be accessible.
@Jeeppler Yes, I can confirm that the vast majority of artists I know have no idea how to make animated SVGs, and typically don't even export their work as normal SVGs.
This is a really weird and arbitrary time to start worrying about images carrying exploits. File transfers have been a thing for a while now. The sticker format will not be limited to SVG.
What is the difference between sticker and a normal file transfer?
@ProMcTagonist after reading your intro text to this issue again and your last post. I really have no idea what you think a sticker is. Maybe you can give an example or describe it a little bit more in detail?
what is the difference between sticker and a normal file transfer?
It's described on the wiki page. You're familiar with Facebook stickers, so you already understand the concept.
Bad things have happened before and absolutely WILL happen again. Remote execution vulnerabilities by a carefully crafted MSN messanger pic or a carefully crafted video. The last bug existed for years on most platforms.
What are we trying to do here, create a secure platform users can trust or treat users like idiots that would prefer to look at kappa pics than remain secure? Surely there are plenty of platforms for such people and we shouldn't hand a bunch of potential backdoors out to anyone that can infiltrate an image library project?
@redfacedquark We're trying to replace Skype with something that your chosen TLA can't read/listen into. And to do so, we have to offer features that users want. Yes, it's another attack vector, if you want a totally secure client, write one that rejects everything except the most basic features.
I think it's a false dichotomy that implementing stickers will make you LESS secure than not. And either way, there's already file transfers, so toxcore already literally supports sending exploits...
@GrayHatter File transfers must be accepted by the user by default and are not executed. The idea of allowing user-generated content to be rendered by the system image library by default is dangerous and proved fatal in the examples I referenced.
If we do not learn the lessons of history we are doomed to repeat them. It is absolutely not a false dichotomy and WILL make you less secure. If it was off by default I would be happier.
It would be nice to see clients implement a literal convenience / security slider presented to the user at install. This may put a lot of the friction regarding the project's aims that I see in various comments to bed.
File transfers must be accepted by the user by default and are not executed.
Avatars.
allowing user-generated content to be rendered by the system image library by default is dangerous
So I take it you would also have people disable images in their web browser?
and proved fatal in the examples I referenced.
Two past remote exec bugs ever, across all messaging software with inline media? That's insanely good. Software has bugs. Software has the capacity to have bugs. If you only use software that never had any bugs, you're not going to be using any software.
If I were the sort of person whose life depended on privacy then yes, I would disable avatars long with the AV features. This is probably a client issue about choosing your security vs convenience setting rather than a toxcore issue.
This project is not responsible for browsers so browser security is out of scope. A tails browser user would not be associated with a permanent identity while a tox client user would. Also, a browser will only display images at the behest of the user from a particular site, while profiles and silly kappa images are injectable from an unknown assailant whenever the client is online.
a browser will only display images at the behest of the user from a particular site
nope
@ProMcTagonist I think he's saying, a browser is pull vs tox which is push/pull (re: data transfer)
But I get your point, ads that hijack a browser are a thing.
@redfacedquark it could be client settings - to display sticker, to display sticker at press on sticker placeholder which shown by default in message, or to ignore stickers.
@Renha +1. I'm new to this conversation but also think an "open sticker format" would be pretty cool.
I'm also late to the party here, but I like the idea of stickers. It's also good to see a discussion about this feature adding to the attack surface. These things should be explicitly considered up front. Automatic image parsing would make a fantastic attack vector, and it sounds like that's already an option via Avatars (per @ProMcTagonist's comment). Also, don't think that SVG parsers are flawless, as evidenced by a recent Firefox exploit which affected Tor Browser Bundle users (https://lists.torproject.org/pipermail/tor-talk/2016-November/042639.html). So whether it's GIF, PNG, JPG, SVG or some other format, I think we can all agree that it adds attack surface (just like adding most features). I also think @Renha and @redfacedquark hit the nail on the head by suggesting that clients (and users) should be able to choose whether these should be automatically displayed, click to show, or flat out disabled.
According to the WIP spec, it looks like the only change to core is adding TOX_FILE_KIND_STICKER to TOX_FILE_KIND, right? The rest of the spec seems to be suggestions for how clients should implement things. The question of which image formats to support (if any) appears to be left to the clients, not made the toxcore.
Given that the proposed change to core is just adding one enum, what is the next step to getting this change adopted so the clients can implement their parts?
