TinyMCE allows users to drag-and-drop images directly into a textarea, bypassing the filepicker. Our faculty and students are consistently adding images to various parts of Moodle in this fashion. This works inconsistently based on the source of the image and the browser in question. I'm going to enumerate a few use cases below. All of these assume that the source location is the textarea under Front page settings -> Edit settings.

Drag image from local file:
Chrome) Fails completely; chrome loads the image in the window, leaving Moodle.
Firefox 11) Adds the image as a Base64-encoded image directly in the text; the image appears to the user.
Safari) Inserts the raw filesystem URI instead of the image (e.g. file://localhost/Users/user/Downloads/img_0003.jpg). The image is not displayed.

Drag image from another open web browser:
Chrome) Inserts a proper img tag linking to the remote image; the image appears to the user.
Firefox 11) Inserts a proper img tag linking to the remote image; the image appears to the user.
Safari) Inconsistent. Sometimes it will insert a proper img tag linking to the remote image (as Chrome and Firefox do), sometimes it will add the image as a base64-encoded image directly to the text. For example, dragging an image from Google Image search will add it as base64, while clicking through to the source image and dragging THAT instead will produce the link. Chrome and Firefox had no problem with the Google Image result.

As a further issue, the 2.x wiki seems to strip out base64-encoded data altogether, after showing it in the preview. This is inconsistent with other parts of Moodle.

We're really concerned about the cases which involve base64 encoding, because that's a lot of TEXT in an unexpected place. Prior to MDL-31985 this caused crashes on some our MySQL instances since really big images would break the 64K limit. We also don't like users being able to bypass the built-in filepicker. We tried using TinyMCE's paste_block_drop to prevent this behavior but discovered that Firefox (apparently) ignores this limit. See https://bugzilla.mozilla.org/show_bug.cgi?id=729587 for a discussion of this issue as it relates to Firefox. We're wondering about the downstream effects of larger-than-expected backups, for example.

A solution we're considering at Lafayette is to add a validation check for base64-encoded data but that's not an ideal solution.