Bug #1043
Transformations not specified by the protocol, should be opt-in not opt-out
Status: | New | Start: | 04/24/2015 | |
Priority: | Urgent | Due date: | ||
Assigned to: | Mirco Bauer | % Done: | 0% |
|
Category: | Engine | |||
Target version: | 1.1 | |||
Complexity: | Medium |
Found in Version: | ||
Votes: | 1 (View) |
Description
Currently the smuxi engine transforms certain substrings such as emoji etc into richer objects for the frontend to consume. Older frontends sometimes can't consume these, and ignore these objects, resulting in data loss.
Sometimes the transformation is specified by the protocol (e.g. Twitter?), but sometimes this is a non-standard extension (e.g. in IRC) chosen by Smuxi - or adapted from elsewhere like mIRC.
(1) For the latter case, such arbitrary transformations are not expected by users. This poses a potential security risk, and therefore should not be enabled by default. For example, cryptographic strings are sometimes given in the format xx:yy:zz:etc and the current emoji regex clobbers these. (But a more complex regex probably wouldn't be completely safe either, and might clobber other things.)
(2) Even when enabled, frontends should not simply ignore things they don't understand, but at least emit a placeholder to the UI to tell the user that something unrecognised is missing.
16:46:22 <meebey> infinity0: Twitter is doing emojis without image support I think
16:46:38 <infinity0> sure, that is part of the official protocol specification
16:46:47 <infinity0> they would be like "a string :) should be interpreted by clients as an emoji"
16:46:53 <infinity0> this fact however is NOT part of the IRC protocol
16:47:04 <infinity0> i don't expect this, as an IRC user
16:46:49 <meebey> ok I think I get your point
16:47:02 <meebey> when the protocol does not support metadata to do something nice to the user
16:47:11 <meebey> dont make a feature that transforms regular text into something else
16:47:16 <meebey> I get the point now
16:47:21 <meebey> and I agree I think :)
Associated revisions
Revision 4b5dc76e3d0cbff7677b92ce955881c32f353ba4
Engine: make Emojis opt-in for now (refs: #1043)
History
Updated by Mirco Bauer 3497 days ago
- Category set to Engine
- Assigned to set to Mirco Bauer
Features (like metadata) not specified in the respective protocol specification should not be enabled by default to enhance the user experience. It can lead to issue as reported in this issue. So Smuxi should disable mIRC color support, URI detection (turning into clickable links) and heuristic link detection for the IRC protocol is that is a bare text protocol. The same needs to be considered and verified for Twitter, XMPP, Campfire, JabbR. If message patterns also fall into this category has to be discussed.
Updated by Mirco Bauer 3497 days ago
- Priority changed from Normal to Urgent
Updated by Mirco Bauer 3497 days ago
The fallback of unknown/unsupported message part types needs to be dealt with in a separate issue/ticket. Smuxi should probably show an broken image placeholder or something with a mouse-over hint that says that the frontend can't display a part of the message. This is important so the user is aware that he is not seeing all information. This is "data loss" but not strictly as other frontends that connect at the same time or a bit later (not too late, because the message could move out of displayable buffer) and it will still show/render the message completely.
Updated by Mirco Bauer 3427 days ago
- Target version changed from 1.0 to 1.1
- Complexity set to Medium
For Smuxi 1.0 emojis are now opt-in, other transformations have to be reviewed for 1.1, thus this ticket stays open for 1.1