RFE: NS Flash blocking to be on par with Click-to-play

[milithruldur]

Click-to-play is a Chromium/Chrome feature that temporarily prevents loading of plugin objects on a webpage until clicked upon.

A great use for this feature is preventing playback of Flash plugins upon page load, and selecting which object is allowed to play. NoScript provides such features to Firefox and more (prompt before allowing plugin execution, and examine plugin URL and execution parameters, to mention a few).

However, there is a subtle difference I noticed between Chromium's implementation and NoScript's. Whereas in Chromium when you click upon a blocked Flash object it runs and works all the time, with NoScript the Flash object that was temporarily blocked may sometimes not work properly.

Having only the NoScript extension on a clean profile, with "Apply these restrictions to trusted sites too" and "Forbid Adobe Flash" checked inside the Embeddings tab, adding attachments to a new message inside Yahoo Mail's new interface, one is met with a blocked Flash object on top of the "Attach" button. Clicking on the placeholder activates the button for use, but it does not upload the attachments as it was intended to.

The possible workarounds for this are 1) to temporarily allow all shockwave-flash objects via NoScripts context menu on the site, and 2) to temporarily uncheck "Forbid Adobe Flash." In both workarounds, a page reload is needed to fix the broken function. Unlike Click-to-play, the Flash uploader cannot work on-demand with NoScripts unblocking mechanisms in this case.

This is also the case with Facebook Flash games. However, unblocking Youtube videos play back just fine.

What can be improved to NoScripts unblocking so that all Flash objects could work on-demand, like in Chromium's Click-to-play?

[Tom T.]

Having only the NoScript extension on a clean profile, with "Apply these restrictions to trusted sites too" and "Forbid Adobe Flash" checked inside the Embeddings tab, adding attachments to a new message inside Yahoo Mail's new interface, one is met with a blocked Flash object on top of the "Attach" button. Clicking on the placeholder activates the button for use, but it does not upload the attachments as it was intended to.

I've used Classic Yahoo mail for years, going back to Firefox 2. Ymail used to work fine until they introduced these separate up-and-download attachment objects some years back, which seemed unnecessary (and therefore, dumb). Since then, it's always been glitchy in this regard. One had to attempt an attachment upload or download just to get the object to show in the menu, then temp-allow it, then reload the page (or use your other workarounds).

Recently, uploaded attachments have been working without doing this, but downloads still require pointing to Blocked Objects and allowing the download object.

I'm not familiar with the New Yahoo, and don't care to use it because of the change in the Privacy Policy, which permits them to read the contents of the email and scan for keywords to provide even more-targeted advertising, as Gmail and others have always done. Reading subject lines etc. is invasive enough, IMHO. YMMV. Perhaps someone who uses the New Ymail can comment further on how the u/l and d/l work.

I don't know Chrome very well. If Yahoo mail is different on Chrome, I'd make an off-the-cuff guess that Chrome is prefetching such objects regardless of whether needed, especially because it cannot support anything anywhere close to NoScript's selectivity. (There are entire threads here on that, including the inferiority of ScriptNo and other Chrome NS wanna-bes.) That would save the above inconvenience, but consume resources and bandwidth unnecessarily, and in some cases, may have implications for privacy and safety. Input from those familiar with Chrome is welcome here, but on this specific issue only, please, and not rehashing the entire Chrome vs. Firefox thread.

Giorgio Maone has been trying to port NoScript to Chrome for more than two years, but Chrome lacks the needed infrastructure.

[milithruldur]

Thank you for your input. I don't mean to sound someone adding fuel to the fire between Chrome and Firefox differences. What I have given as a use-case scenario is the first thing that came to my mind, whenever composing new mail messages and switching back and forth Chromium and Firefox, Windows and Linux. I too didn't have much love for the new interface, but it was forced upon me on login some time ago (and still searching if there's a way back to the classic interface).

The point of my RFE is that Chromium/Chrome, according to my not-so-knowledgeable observations, can pause the state of any Flash objects on a page, and start it on-demand without having to reload the whole page. So if I click on a Click-to-play placeholder in Chromium, that object functions without a glitch. In the case of NoScript, this is not a guaranteed behavior. I click upon a NoScript placeholder for a blocked object and it activates, but the object does not function properly (as the case with YMail's uploader Flash object from its new interface).

A reload of the page is sometimes necessary (because as the case with Youtube videos, it works upon activation). Or sometimes it is needed to temporarily allow all objects within a site if the reload results back in the same object still being blocked by NoScript (which I find counter-intuitive, considering I have temporarily allowed the same object before the reload).

The point of this difference is that it seems NoScript breaks some objects on a page that is not activated upon completion of the page load, and that a reload of the page is necessary so that the same object is active upon completion of the page load, and is therefore _not broken_ in function (an object could load, like a Flash button, but the function behind the button is broken). Click-to-play has no problem with activating blocked objects and maintaining the working function of the said objects.

[Tom T.]

... I too didn't have much love for the new interface, but it was forced upon me on login some time ago

They kept threatening me that Classic would end, and I must switch before September something in 2011. I didn't. So they changed the deadline to October 2011. I didn't. So they presented the change thing, with a teensy link to where you could opt out, which I did. Not quite "forced", but they surely didn't make it easy to avoid.

(and still searching if there's a way back to the classic interface).

http://answers.yahoo.com/question/index ... 220AAYixpa
See if that still works.

A reload of the page is sometimes necessary (because as the case with Youtube videos, it works upon activation). Or sometimes it is needed to temporarily allow all objects within a site if the reload results back in the same object still being blocked by NoScript (which I find counter-intuitive, considering I have temporarily allowed the same object before the reload).

I have to agree with you there. I go to YouTube, select a video, and click the placeholder. If I reload the page, even while the video is playing, the *very same video* is blocked again. Temporary script permissions persist until the session is ended, or the user revokes them, but these temporary object permissions seem to be good only until the page is reloaded. Not sure if that's deliberate (for some type of safety reason) or a bug. Giorgio is relatively unavailable until the completion of his relocation and connection to his new ISP, but I'll drop him a note anyway, for when he's able to be with us full-time again.

Sorry that Yahoo's own issues distracted from the main thrust of your post.

[milithruldur]

They kept threatening me that Classic would end, and I must switch before September something in 2011. I didn't. So they changed the deadline to October 2011. I didn't. So they presented the change thing, with a teensy link to where you could opt out, which I did. Not quite "forced", but they surely didn't make it easy to avoid.

In my case they just presented me a page upon login where I could not find such a link to get the "mandatory" upgrade page out of the way. And so to be able to enter my inbox I had to agree to have my mailbox interface upgraded.

http://answers.yahoo.com/question/index ... 220AAYixpa
See if that still works.

Thanks, will give that a try.

I have to agree with you there. I go to YouTube, select a video, and click the placeholder. If I reload the page, even while the video is playing, the *very same video* is blocked again. Temporary script permissions persist until the session is ended, or the user revokes them, but these temporary object permissions seem to be good only until the page is reloaded. Not sure if that's deliberate (for some type of safety reason) or a bug. Giorgio is relatively unavailable until the completion of his relocation and connection to his new ISP, but I'll drop him a note anyway, for when he's able to be with us full-time again.

Thank you for that insight. I would like that the same "Temporary" behavior that applies to scripts, also apply to blocked objects, unless of course there is a consideration unbeknownst to a casual user like me. I don't want to be working around that subtle behavior by allowing all objects from the page, even if temporarily. And if possible too, never require a page reload upon activation of certain objects (like that of YMail's Flash uploader) if _only_ to fix function breakage. And perhaps the answer to that might also lead to the reason why NoScript is apparently breaking some objects upon activation, which requires a page reload to bring back the function of said objects.

[milithruldur]

Oh and please give my good luck to Mr. Maone on his relocation. Starting the new year with a new ISP must be great improvements for a change.

[Tom T.]

Oh and please give my good luck to Mr. Maone on his relocation. Starting the new year with a new ISP must be great improvements for a change.

Apparently, it's quite a pain. Moving from one place to another usually is. And not all places are so Internet-friendly, with quick activation.
Won't bore you with the details of the Italian telecommunications industry...

I would like that the same "Temporary" behavior that applies to scripts, also apply to blocked objects, unless of course there is a consideration unbeknownst to a casual user like me. I don't want to be working around that subtle behavior by allowing all objects from the page, even if temporarily. And if possible too, never require a page reload upon activation of certain objects (like that of YMail's Flash uploader) if _only_ to fix function breakage. And perhaps the answer to that might also lead to the reason why NoScript is apparently breaking some objects upon activation, which requires a page reload to bring back the function of said objects

I agree. Hopefully Giorgio will soon tell us why it must be that way, or that it can be improved. Thank you for your patience.

[Giorgio Maone]

When you grant temporary permissions to an embedded object by clicking on its placeholder, you're allowing the exact URL + content type combination (pending some simplifications on the URL meant exactly to mitigate the "block on reload" issue we're talking about here): therefore, if the URL changes on reload (e.g. because a timestamp or an unique request identifier is appended) the "same" object will be blocked again.

This is a sensible behavior from a security standpoint, because especially if you choose "Apply these restrictions to trusted sites as well" you may trust a certain object but not another, and the only thing which differentiate them from the browser point of view is their respective URLs.

So the question here is, do the page create an unique URL for the embedded object each time is loaded? If it does, the behavior is expected and by design.

In order to work around, if needed, you can use any of the less granular options listed under the "Blocked Objects" submenu of the NoScript menu.

[milithruldur]

This is a sensible behavior from a security standpoint, because especially if you choose "Apply these restrictions to trusted sites as well" you may trust a certain object but not another, and the only thing which differentiate them from the browser point of view is their respective URLs.

Hmm, it makes sense now. In the case of the repeatedly blocked Flash uploader from YMail's new interface, the object's URL changes after every reload.

However, why does NoScript apparently break the function of some objects upon activation, which is why the reload of a page is necessary? In the case of the Flash uploader from YMail, even though it was activated and made possible to select which files to attach to the new mail message, it wasn't really uploading said files. A page reload is necessary, in which case the now unblocked object must still be unblocked after the reload finishes, to bring back the working function of the object?

This is unlike the other implementation, Click-to-play, in which activating the placeholder for a blocked objects does not break function of the object. The object functions normally like it would have, had it not been blocked in the first place.

[Tom T.]

When you grant temporary permissions to an embedded object by clicking on its placeholder, you're allowing the exact URL + content type combination ...: therefore, if the URL changes on reload (e.g. because a timestamp or an unique request identifier is appended) the "same" object will be blocked again.

This is a sensible behavior from a security standpoint, because especially if you choose "Apply these restrictions to trusted sites as well" you may trust a certain object but not another, and the only thing which differentiate them from the browser point of view is their respective URLs.

So the question here is, do the page create an unique URL for the embedded object each time is loaded? If it does, the behavior is expected and by design.

Giorgio is spot-on (now, there's a surprise! ) regarding YouTube Flash videos.

I went to http://www.youtube.com/watch?v=Z-DVi0ugelc
clicked the placeholder, and copied the contents of the Confirm box to a text file.

Then, after TA, and *while it was playing*, reloaded the page. Placeholder reappears. Again, I copy the contents to a text file. (URL in browser bar doesn't change, of course.)

Third trial: Leave the site, clear everything, go back to the same video. (Same browser URL). Again, click placeholder and copy contents to text file.

To avoid blindness, used Windows File Compare utility (comp.exe).
Indeed, each is different from the others. Fortunately, the differences showed up as early as the first line, so I can post them here in case they're of any informational value. Trials 1, 2, and 3, with nothing in between for easy comparison:

Code: Select all

Temporarily allow http://s.ytimg.com/yt/swfbin/watch_as3-vfl7SkMGe.swf#!flashvars#tmi=1&fexp=912305%

Code: Select all

Temporarily allow http://s.ytimg.com/yt/swfbin/watch_as3-vfl7SkMGe.swf#!flashvars#tmi=1&fexp=907605%

Code: Select all

Temporarily allow http://s.ytimg.com/yt/swfbin/watch_as3-vfl7SkMGe.swf#!flashvars#tmi=1&fexp=909513%

Note that they're identical until the end, "&fexp=xxxxxx%". This identifier changes every time. (No clue what that was, but a quick search showed it to be an SQL query tool, "Fast Export".) So the *entire* URL+content ID, as Giorgio said, does in fact change. Perhaps some of this Contents ID may be excluded safely in mitigating the issue, but overall, I see the point that we are trusting an object by unique ID, and that browsers that do not have that degree of selectivity may be more vulnerable.

In order to work around, if needed, you can use any of the less granular options listed under the "Blocked Objects" submenu of the NoScript menu.

Indeed. Instead of clicking placeholder, I used the most restrictive of the BO menu that would *not* produce the lengthy Contents ID, namely

Code: Select all

Temporarily allow shockwave-flash@http://s.ytimg.com (http://www.youtube.com)

Now, after page reload, the video still plays without further permission.

Also, choosing any other video there will play without further permission. That may be desirable or undesirable, depending on your preferences.

Now that I know what to look for, I'll look more deeply into the mechanics of the Yahoo attachment object, when time permits.

Oh, and the choice of YT song was not an attempt to flatter the boss. I've enjoyed it since long before the Internet was invented.

[Tom T.]

@ milithruldur: (and all else interested)

I'm glad that there was this motivation to investigate Yahoo mail attachments.
I'm sorry that the following applies only to Classic mail.
I have no idea whether it would work for New mail, and don't care to try, given the uncertainty of returning.
(Or the time/trouble to create a new account.)

If you're unable to return to Classic, perhaps you could see if these work on New.

All of the following was identical on both Firefox 3.6.25 and 9.01, both with NS 2.2.5, RequestPolicy 0.5.24, on Win XP.

This is my Yahoo-related whitelist:
mail.yahoo.com
mail.yimg.com

Note that yahoo.com is not allowed, nor is yahooapis.com. (Some may need them for other reasons. Only trying to solve this issue at the moment.)

RP allows requests from yahoo.com to yimg.com.

Uploads now work without any further permissions, objects, etc.
I noticed this change some months ago, but did not investigate.
The reason is that they've gone back to doing uploads via only scripting, like they did eight years ago when it also worked.

This was seen by a script displayed in JSView,

Code: Select all

http://mail.yimg.com/zz/combo?/nq/mc/15_0_2/js/upload.js

Since the third-level domain of mail.yimg.com is already whitelisted (see above), the script runs without ado. Done.
*************************
Downloads are still are more complicated than years ago.

One can allow the blocked object, as we've been doing it, or (shudder) uncheck Forbid <IFRAME> in NS Embeddings.
Or various other ways.

Won't bore you with the investigation and details, but it turns out that there's a "hidden" domain, presumably the one inserted by the IFRAME or object, and that is ymail.com. Never heard of it before; never seen it until today.

So, add to the whitelist:
ymail.com

If you have RequestPolicy, allow requests from yahoo.com to ymail.com.

Next, the most restrictive, but permanent, way to solve the whole Yahoo mail problem is with an ABE rule (NS Options > Advanced > ABE). In the USER box, add this:

Code: Select all

#Yahoo mail download rule
Site *@http://mud.attach.mail.yahoo.com
Accept from mail.yahoo.com *.mail.yahoo.com
Deny

Now downloads of attachments work without fuss.

IIUC, Yahoo attachments work for "out-of-the-box" NS, because yahooapis.com is in the default whitelist, and, IIRC, "Apply these restrictions to whitelisted sites too" is unchecked by default. (I may be mistaken on the latter.) These also will allow the attachment process, which is why Giorgio put them in the defaults -- so that new users could use Yahoo services without running into these issues. For those of us who like to fine-tune permissions, these appear to be the most restrictive set of permissions that will still allow u/l and d/l without any further issues.-- at least, so far. That's enough investigating and fine-tuning for a while.

Please let me know if they work for you. Also, any other users of Yahoo mail, either Classic or New, please advise likewise, thanks.

btw, the tests were done on a recent e-mail from a friend who toured Europe in a van. Here's one of the pics downloaded:



It's Mount Etna, in Sicily. ... and yes, that was a nod to the boss.