Bug #1043

avatar

Transformations not specified by the protocol, should be opt-in not opt-out

Added by Infinity Zero 1513 days ago. Updated 1442 days ago.

Status:New Start:04/24/2015
Priority:Urgent Due date:
Assigned to:avatarMirco 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
Added by Mirco Bauer 1454 days ago

Engine: make Emojis opt-in for now (refs: #1043)

History

Updated by Mirco Bauer 1512 days ago

avatar
  • 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 1512 days ago

avatar
  • Priority changed from Normal to Urgent

Updated by Mirco Bauer 1512 days ago

avatar

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 1442 days ago

avatar
  • 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

Also available in: Atom PDF