Forgot your password?

Comment: Re:Simulations are limited by imagination (Score 4, Interesting) 112

by swillden (#47734021) Attached to: Google Wants To Test Driverless Cars In a Simulation

The problem with simulator testing is that you can't test scenarios that you didn't think of. This is particularly important to find problems arising from multiple simultaneous situations. For example, you might test the scenarios "front camera obscured by rain", "car ahead of you performs emergency stop", and "dog runs into street", but that doesn't necessarily tell you how the car will respond to a combination of the three.

Real life is far more creative than any scenario designer.

Which is why you should do both. A simulation can test millions of permutations -- including arbitrary combinations of events, and in far more variety than could be tested in a reasonable amount of time on real roads -- and can verify that software changes don't introduce regressions. Real-world testing introduces an element of randomness which provides additional insights for the simulation test cases.

Ultimately, governments should probably develop their own simulators which run the autonomous car through a large battery of scenarios, including scenarios which include disabling some of the car's sensors. Then autonomous vehicles from different manufacturers could be validated on a standard test suite before being allowed on the roads, and when real-world incidents occur in which an automated car makes a bad decision, those incidents can and should be replicated in the simulator and all certified vehicles tested. They should also do real-world testing, but I suspect that in the long run simulations will provide much greater confidence.

Comment: Re:tl;dr (Score 1) 67

by vux984 (#47733761) Attached to: Researchers Hack Gmail With 92 Percent Success Rate

Although I agree with you in general, the thing is that you need to think of what the effects of a false positive are. Imagine starting up your game of solitaire and then seeing a Gmail-like login window.

I'm not an android dev.. but on platforms I do write for, any app can determine the name of the foreground process/task.

So the worst that happens, is an oddly timed credentials box for the app you WERE using. That's going to set off far fewer alarm bells than you would think.

Comment: Re:tl;dr (Score 1) 67

by vux984 (#47733527) Attached to: Researchers Hack Gmail With 92 Percent Success Rate

Everybody knows that 'carefully designed timing' and generalisable match very poorly.

Agreed -- however, a visible glitch or hiccup would that really set the majority of android users on guard? I'm skeptical.

Honestly, the entire timing element is almost superfluous; for a large number of users simply throwing up a fishing screen while they are IN another app would garner high success rates.

Launch gmail app... Popup "connection to server failed", "please enter username password". It would be horrifying to see how high a success percentage that gets you."

This attack is impressive in that it generates 98% success rate at detecting and invisibly injecting its phishing screen 'just so'. But honestly -- they'd probably snatch a shocking high portion of credentials simply timing the popup to coincide with 1-2 seconds after a given app starts for a large number of apps.

Granted the sophistication of a finely tuned and well crafted attack would mean even I'd fall for it without being any wiser, and it enables them to go after some more complicated apps, in more complicate scenarios. And yes, a finely tuned profile using knowledge about the particular model of phone, and particular application set etc are required for to pull it off.

But the reality remains that the low hanging fruit (dumb users + easily predictable apps) is going to be very easily harvested.

Comment: Re:Blast from the past (Score 3) 67

by vux984 (#47733231) Attached to: Researchers Hack Gmail With 92 Percent Success Rate

Memory allocation is still controlled by the OS. (At least insofar as apps request memory from the OS, and release it back to the OS).

Normally, an app would have no need to know what another app was doing with memory. However, the instrumentation for another app to track the memory usage of another app exists and is not restricted to elevated / trusted apps.

Clearly it should be.

I can't honestly imagine what a regular app would need this for anyway. Its very much a 'task manager' or 'debugging tool' class of information - and only developers and system level apps need this information.

That along with the fact that apps should not be able to pre-empt eachother and go into the foreground on their own. (iOS apps for example, apparently can't pre-empt; unless they have exceptional permissions (e.g. sideloaded by developers or enterprises or if the device is rooted/jailbroken) so on ios even if the app can determine the app activity, it won't be able to prempt it with its phishing screen.

Comment: Re:tl;dr (Score 3, Interesting) 67

by vux984 (#47733097) Attached to: Researchers Hack Gmail With 92 Percent Success Rate

An immediate work-around would be to randomly place the log-in screen within a pre-determined area such that the hostile app would be unable to immediately overlap it. The double image will tell the user something is wrong.

The double image will tell the user something is wrong.

How is that a work around?

Its a phone. The login 'window' is going into a 3" to 5" space and is full screen in nearly every implementation. The 'popup' that the hostile app preempts simply covers the whole screen.
All in all not a particularly powerful attack vector.

Quite the opposite. Its a very powerful attack vector; and given the surprisingly good ability to time the pre-emption a very dangerous one.

Comment: Re:Blast from the past (Score 5, Informative) 67

by vux984 (#47732993) Attached to: Researchers Hack Gmail With 92 Percent Success Rate

Blocking access to the memory space of other processes has been a solved problem since timesharing in the '60s and '70s, right?

Sure it was. That isn't what is happening though.

Its not accessing the apps memory itself. Its accessing the shared memory *statistics* of a process.

Then its using pre-calculated patterns of the shared memory usage (presumably allocation order, sizes allocated, NOT the actual memory contents etc) to guess what the user is doing in the other app. Then, when it detects a pattern that corresponds with "I'm about to log in" it pre-empts the app with its own phishing login screen skinned to look like the original. The user is -expecting- a login screen to popup, and one that looks right does... so they enter their credentials.

I assume they...

All your assumptions and proposed solutions were completely wrong.

The solutions are:

a) to remove untrusted apps ability to monitor memory USAGE statstics

b) to remove untrusted apps ability to pre-empt the screen.
c) better permissions controls and better CURATION limiting
d) it may also help to let apps enter 'critical sections' that cannot be preempted by other apps (?)

Comment: Re:The real crime here (Score 1) 392

by BasilBrush (#47732811) Attached to: 33 Months In Prison For Recording a Movie In a Theater

This is not a crime and there is no victimization. Nothing is being stolen. The person recording videos just disagrees with what is clearly out of line. It is a civil matter.

That might be what you want to believe, but it's not true.

"Both men pleaded guilty to charges of committing offences under the Fraud Act 2006 and the Copyright, Designs and Patent Act 1988."

It's criminal law. Legally, the mistake he made was selling copies. Yes, selling things you don't own is fraud and fraud is a crime.

The common sense errors he made were selling the copies (at £1.50 each) via facebook, and using the same username for both the torrent uploads, and online profiles such as the plentyoffish dating website, which made it trivial to trace him.

panic: kernel trap (ignored)