Gmail will block .js file attachments starting February 13, 2017
gsuiteupdates.googleblog.com
Gmail will block .js file attachments starting February 13, 2017
1–10 of 11 posts
Re: Gmail will block .js file attachments starting February 13, 2017
#2I don't know which is weirder, that jscript files are still executable by default on Windows in 2017 or that google only just decided to block .js files to handle this security problem.
Re: Gmail will block .js file attachments starting February 13, 2017
#3This blog article don't say if this includes archives, but I assume that it probably does.
Re: Gmail will block .js file attachments starting February 13, 2017
#4I have never, ever sent a JavaScript file to a person capable of reading JavaScript, who actually wanted or needed a JavaScript file sent to them via email. No one has ever requested such a thing from me.
That is something that has never happened to me.
Re: Gmail will block .js file attachments starting February 13, 2017
#5This blog article don't say if this includes archives, but I assume that it probably does.
In the past I've been hit it's the "non exe" permission and for a while you were able to bypass it by putting it in an archive file (Always found emailing myself files handy when I didn't have a thumb drive to hand), but they scan the file types of the files inside of archives these days so emailing a zip with a exe in it doesn't work.
I guess the same will apply for .js files which might be a pain when emailing a client a zip of the programming work you have done for them, but they do say you can use Google Drive to host the file and send them a link to the google drive download.
Re: Gmail will block .js file attachments starting February 13, 2017
#6I have never, ever sent a JavaScript file to a person capable of reading JavaScript, who actually wanted or needed a JavaScript file sent to them via email. No one has ever requested such a thing from me. That is something that has never happened to me.
I have. I'll do what I do with .EXEs already -- zip them and rename to .jpg.
Re: Gmail will block .js file attachments starting February 13, 2017
#7I have never, ever sent a JavaScript file to a person capable of reading JavaScript, who actually wanted or needed a JavaScript file sent to them via email. No one has ever requested such a thing from me. That is something that has never happened to me.
I have. I'll do what I do with .EXEs already -- zip them and rename to .jpg.
In a world where email clients were maintained as actively as web browsers, this behavior would be a default feature, in the same way we have weird workarounds for HTTP proxies.
Re: Gmail will block .js file attachments starting February 13, 2017
#8This blog article don't say if this includes archives, but I assume that it probably does.
In the past I've been hit it's the "non exe" permission and for a while you were able to bypass it by putting it in an archive file (Always found emailing myself files handy when I didn't have a thumb drive to hand), but they scan the file types of the files inside of archives these days so emailing a zip with a exe in it doesn't work. I guess the same will apply for .js files which might be a pain when emailing a cl…
If you password protect the archive you should be good
Re: Gmail will block .js file attachments starting February 13, 2017
#9They’ve been blocking .vbs since at least 2013. But they’re starting to block functionally equivalent .js just now. Smart.
Re: Gmail will block .js file attachments starting February 13, 2017
#10Earlier quoted context omitted.
In the past I've been hit it's the "non exe" permission and for a while you were able to bypass it by putting it in an archive file (Always found emailing myself files handy when I didn't have a thumb drive to hand), but they scan the file types of the files inside of archives these days so emailing a zip with a exe in it doesn't work. I guess the same will apply for .js files which might be a pain when emailing a cl…
If you password protect the archive you should be good
Got to make sure that the table of contents can not be read at all. You might not be able to extract the files without the password but if you can determine the file type (and most password protected archives I've come across will happily display the file names/types/protection status of each of the files without the password) and still preform the block.