390776 - Implement nsIDOMFile.lastModified

Status: RESOLVED DUPLICATE of bug 673586

(Core :: DOM: Core & HTML, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

It seems to me that properties directoryName, extension, lastModified and mimeType would also be useful for nsIDOMFile.

Comment 1

[Martijn Wargers (dead)]

Attachment: patch

Comment 2

[Martijn Wargers (dead)]

The bug that implemented this initially, is bug 371432.

Comment 3

[Biju]

directoryName will that expose path?
(if so see Bug 143220)

Comment 4

[Boris Zbarsky [:bzbarsky]]

Yeah, I don't think we want directoryName.  At least not in unprivileged code.

For the rest... are these part of the web apps spec?

As for lastModified... it's a little odd to see the mm/dd/yyyy format there.  Again, is that in a spec?  If not, should it use the user's locale instead?  Or something?

Comment 5

[Biju]

of lastModified why cant it be a date object?
if is date object it will be much easier to format/manipulate what ever form.

PS: MS-Sharepoint coders will love lastModified, 
at present in sharepoint the lastModified date dont match actual date of the upload file on the local/network drive.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Would lastModified be considered a privacy leak? Also, this is technically a new feature way past feature freeze.

Comment 7

[Biju]

(In reply to comment #6)
> Would lastModified be considered a privacy leak? 

Yes....
 
But JPG, ODF and other OOo files, OOXML file, ZIP, JAR, XPI, EXE, email, many database/log/backup files, many tool created html/xml files etc...
all have embedded date/time in it, 
so what remains will be only text files or hand edited files for which we leak this extra info.

We can reduce the abuse of somebody using lastModified info, 
by making it less reliable.

Method 1:
Have an about:config setting which make lastModified values as
0 - provide actual lastModified 
1 - provide null / not lastModified readable
2 - provide a value which is user set +/- offset from actual lastModified 
3 - provide a value which is user set +/- offset * random from actual

Method 2:
* First implement bug 178506 
  – save original timestamp (last-modified date) on file downloads
* Then Encourage online service provides (or by Firefox addon) to make a services to modify lastModified info of a file to a user decided value, 
which should also set the embedded dates in file.

We need a third party because mozilla.org dont know all the file formats users have. 

Implement bug 178506 is needed so, Method 2 will happen automatically.
Adding method 1 also to it will make somebody depending on last-modified to do mischiefs a real stupid.

Comment 8

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Let's not do this without a spec, shall we?

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

lastModified is in spec so we should do that

extension seems like syntax sugar which I don't feel strongly about. mimeType is the same as type. directoryName would be harmful on non-system-principal content and for system-principal content we already expose the full path through .mozFullPath.

Comment 10

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(In reply to Jonas Sicking (:sicking) from comment #9)
> lastModified is in spec so we should do that

Let's scope this bug to doing that, then.