I was thinking more along the lines of sending up an anti-drone drone to grab it and drag it back down. After that you can rely on the legal precedent of "finders, keepers" to add it to your drone collection.

I don't think having access to the source code to VS 2015 is going to allow anyone to compile VS for any non-Windows platform. Not unless you have a few million man-hours available for porting and redesign (since much of the functionality present in VS wouldn't even make sense outside of Windows)

When the critical Samsung keyboard exploit hit the news, I was able to do this (and you were not):

mount -o remount,rw /system
cd /system/app
mv SamsungIME.apk SamsungIME.banished
scp cyanogen:/tmp/LatinIME.apk .
cd
mount -o remount,ro /system
reboot

I have no intention of relinquishing my ability to repair this vendor-inflicted brain damage because of your foolish misconceptions.

You might try creating it as a directory first - you're trying to sabotage whatever script is running that restores these files, and the simplest sabotage is the best.

Here is the description of the immutable flag from the chattr man page:

A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

...and I hope the class action lawsuits provide a useful object lesson to the Android marketplace about the importance of security patches. The more vendor agony, the better at this point.

Try installing zero-size files of the same name. Set the permissions to 000, and apply the immutable bit (chattr +i). The chattr command is bundled with the SuperSU; it is also included with busybox.

In the ksh, applying the output redirection operator to a file without a preceding command will serve to truncate the target file (i.e.: > facebook.apk).

If you have rooted your device, you can remount /system in read-write mode, and from there you can remove any file in /system/app (thus removing Google Hangouts if it was installed in this location).

Google, the OEMs, and the carriers have formally abdicated any security stewardship for Android (case in point - Towelroot).

If you wish to maintain a secure Android device, you must root it yourself. No one else can or will help you until you root.

The problem appears to lie in one of the files /system/lib/libstagefright*

NPR is saying that Google Hangouts makes the problem worse:

The messaging app Hangouts instantly processes videos, to keep them ready in the phone's gallery... this setup invites the malware right in. If you're using the phone's default messaging app, he explains, it's "a tiny bit less dangerous." You would have to view the text message before it processes the attachment. But, to be clear, "it does not require in either case for the targeted user to have to play back the media at all," Drake says.

It would appear prudent to uninstall Google Hangouts. If you can disable MMS with your carrier, do so, otherwise do not look at text messages from originators that you do not know - delete the conversations.

Carriers are unlikely to patch (look at SamsungIME.apk if you think OEMs or carriers will lift a finger to help us).

Root your phone, and await a new set of /system/lib/libstagefright* files - Cyanogenmod will likely provide KitKat copies if they ever shirk their laziness long enough to deliver the final promised KitKat milestone.

The technical problems you mention have obvious solutions.

Not enough roof space on a high-rise to supply power to all of its residents? No problem, just put the solar panels somewhere else instead. Wires make it easy to move electricity from one place to another.

Need more power when the sun isn't shining? That's a bit more expensive to solve, but the solution is obvious -- generate excess power in advance and store it in batteries, so that it is available when you need it. The cell phone, laptop, tablet, and electric car markets are all driving the costs of battery storage down to the point where this will soon be economical to do at scale.

193 square miles is 0.006% of the surface area of the United States.

Or, if we wanted to only put the solar panels on existing residential roofs -- there are currently about 6184 square miles of residential roof space in the USA. (ref)

Of course in a non-corporate/general-email environment, all of those things won't happen (or at least, not all at the same time), so there is a big chicken-and-egg problem if we require all of that. Fortunately, I don't think we need to require all of that.

I don't think it is necessary to rely on an unauthenticated message being invalid. An unauthenticated message is just that -- unauthenticated. It might be valid or invalid. If it's something important, the "unauthenticated" flag is an indication to the user that he should verify the message's authenticity using other means (e.g. by calling the boss and asking him about it).

You wouldn't ignore it, you'd call the boss (or email him) and ask him if he really send the message you received.

And hopefully the boss would almost never "forget" to sign an email, because all of his emails would be automatically signed simply as part of the act of sending them from his regular email account.

True, you can't fix stupid. But you can at least make it easier for people to see a difference between a known-authentic email and an email of unproven origin.

It seems like relying solely on peoples' good judgement to figure out which emails are legitimate vs which ones are phishing spam (or worse, spear-phishing spam) is asking for trouble.

I can imagine email service providers using cryptographic signing techniques to assist the email client in reliably identifying which emails are definitely coming from their boss (or at least, from their boss's legitimate email account) vs which ones are unauthenticated and could have been written by anyone.

With that implemented, after a few weeks people would grow used to seeing the happy green "sender authenticated" sign at the top of each email from their boss, and if an email came in purporting to be from the boss, but with a big angry red "WARNING -- UNAUTHENTICATED MESSAGE -- MAY BE FRAUDULENT" (or whatever) sign at the top, they'd be less likely to hand over the company jewels without first confirming the email's validity.

Does something like this exist? If so, it seems like it's not widely used. If GMail/hotmail/yahoo could agree on a method and then start implementing it by default, I think that would go a long way towards reducing the effectiveness of email phishing attacks.

The stock browser is a primary avenue of exploit for this malware. Stock lives in /system where it is installed read-only.

This was a colossally foolish thing to do. Browser libraries, executables, and sundry components MUST retain the ability to receive patches.

LD_LIBRARY_PATH should point to /data/lib, then resolve to /system/lib only if an override library is not installed, allowing update capability for stock webkit.