Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Comment Re:meh (Score 1) 113 113

What do you mean "locked to a single platform". I admit that I haven't tried it, but they give away the source code to VS 2015.

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)

Comment Rooting is under-rated (Score 2) 120 120

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 .
mount -o remount,ro /system

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

Comment immutable (Score 2) 197 197

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.

Comment Re:Root your device. Do not purchase locked device (Score 1) 197 197

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).

Comment Root your device. Do not purchase locked devices. (Score 3, Informative) 197 197

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.

Comment /system/lib/libstagefright* (Score 5, Informative) 197 197

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.

Comment Re:Suburban thinking (Score 2) 560 560

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.

Comment Re:How big is a "solar panel"? (Score 5, Informative) 560 560

I'm kind of wondering where they would all go.
If each panel was a square meter, that's 193 square miles of solar panels.

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)

Comment Re:Can email service providers do more? (Score 1) 58 58

For it to work in a corporate environment, it must be mandated by the company so that everyone does it, everyone must have a client that supports it, keys must exist and be distributed

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.

then can everyone rely on an unsigned message being invalid

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).

If your boss forgets to sign a message telling you to do something and you ignore it, you better have a company policy backing you up.

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.

That puts it in the realm of a social problem, not a technical one. And it does not solve the problem of external sources of email that don't sign anything being the alleged source of the email asking you to "click here" because your train reservation has changed and you need to pay a bit extra.

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.

Comment Can email service providers do more? (Score 2) 58 58

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.

Comment Android's stock browser MUST be removed (Score 3, Interesting) 91 91

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.

"Gravitation cannot be held responsible for people falling in love." -- Albert Einstein