1099418 - [SMS] Receiving an MMS with a .txt file attached has entire file parsed into the text of the message

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::SMS, defect)

Description

[Brogan Zumwalt [Inactive]]

Attachment: Logcat

Description:
When user recieves a MMS with a .txt filetype attached, the contents of the .txt file is parsed into the text of the MMS message. No file appears to be attached.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141114001204
2) Have second device send an MMS to Flame device with a .txt file attached
3) View MMS

Actual:
.txt file attached to received MMS is parsed as SMS text.
  
Expected: 
.txt file is attached to received MMS.

Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141114001204
Gaia: af6533781356acc62b0f40c9e040aa5b47d3b709
Gecko: 551326425826
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
Repro frequency: 3/3, 100%
See attached: screenshot & logcat

Comment 1

[Brogan Zumwalt [Inactive]]

Youtube video showing issue: http://youtu.be/hcmb1jnI3_k

Comment 2

[Brogan Zumwalt [Inactive]]

Issue DOES occur on Flame 2.0 and Flame 2.2

Actual Results: .txt file attached to received MMS is parsed as SMS text.

Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash)
Build ID: 20141114000200
Gaia: 28991b28d54fc4ef8112c8fa678bf20f9faca8c8
Gecko: 62294be0fc98
Version: 32.0 (2.0)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141114040205
Gaia: 1e300eac2e56d98ad51d414766d031db7d33221f
Gecko: bbb68df450c2
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Comment 3

[Julien Wajsberg [:julienw]]

This is actually working like we expect. Otherwise we have no way to display it anyway...

Comment 4

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

NI SMS qa owner to see if this bug should be invalid.

Comment 5

[Eric Chang [:ericcc] [:echang]]

ni UX for more info, the feature looks fine to me.

Comment 6

[Jenny Lee]

Hi Julien, 
Gonna ask a stupid question just in case: 
Is it possible that parsing the .txt file automatically may cause security problem??

Comment 7

[Julien Wajsberg [:julienw]]

I don't think this is possible but we can ask to the security people who knows better about the attack vectors.

Stéphanie I think you studied how we parse MMS and display them?

Comment 8

[Stephanie Ouillon [:arroway] (needinfo me)]

Hi,

I see some possible scenarios, I only have one question for case 3:

1) The content of the attachement file is rendered as something else than text (code execution) because of unsafe parsing 
-> shouldn't be an issue

2) The text file is not a text file 
-> shouldn't be an issue. The type of the attachment file is retrieved from the mime type. Even if it were messed up (text type showing for video, etc), you wouldn't get very far. 

3) The attachment file is very large and overloads the sms app when it is displayed. 
-> I don't see a limit size for displaying the file attachment in the case it is text. I do see the code for the thumbnail, and for image and video, the size is checked when loading them in the gallery/video app.

Comment 9

[Julien Wajsberg [:julienw]]

Yes, this is a valid point.

The max size for a MMS is 300KB on most networks, could be 600KB on others. 300KB of text is a lot of text.

Let's ask Jenny how we could handle this.
I can think that we could display part of the text with a "read more" link that would display the text in full page. Or we can create a simple separate application to simply read text blobs and use an activity for this.

Comment 10

[Jenny Lee]

I prefer creating a separate application and use an activity, this is to make clear there's a .txt attachment as opposed to directly display the content that can potentially be mistaken as SMS body text. 
But since receiving MMS with .txt attachment is somewhat rare, I wonder if it's worth your time to create an application for this? Let me know, thanks!

Comment 11

[Julien Wajsberg [:julienw]]

It can be worth a contributor's time :) (unless we decide it's a securitu issue serious enough to be fixed soon)

Note that I don't know if we can distinguish normal MMS text from a text attachment. That's why my idea was to have a length limit.

Steve, since you know SMIL better than me, do you know if we can distinguish them?

Comment 12

[Steve Chung [:steveck]]

I think it would depend on the SMIL created from sender. The only chance that we can know whether the text source comes from file or not is from SMIL tag. If the text file is wrapped as <ref> tag in SMIL like vcard or vcalender, we will treat it as a media file and use activity to open it. If the file is wrapped as <text> in SMIL or no SMIL at all, there is no way to distinguish if the blob is from normal text or file. These kind of messages with txt attachment are very likely sent from email, and these message usually don't not SMIL. I don't think we'll have chance to receive a mms with txt attachment will have corresponding SMIL for it since txt is not part of mms standard.

So, it's nice to have a separated app for txt, but it's hardly been used in this case ;)

Comment 13

[Julien Wajsberg [:julienw]]

Ok,

so Jenny, what do you think of my idea in comment 9 then? Do you think we should limit the length of text displayed with a "read more" link? Or if the text has a big length we don't display it as text but as attachment?

Having a separate app as a text viewer should be really easy.

Comment 14

[Jenny Lee]

I think we should simply use text viewer for all size txt attachment, to align with how we handle other types of attachment (ex. image viewer) ;)

Comment 15

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 16

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(