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.
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.
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.
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.
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 (?)
We actually do send people into space, and that kind of disaster could sort of happen.
But we didn't send anyone named Dr. Ryan Stone on space shuttle mission STS-157, and none of the other events in the film ever happened... so its CLEARLY fiction.
And it is science fiction because many of the antagonists/obstacles are consequences of the known rules of physics.
It handily meets any definition of science fiction I would ever care to use.
And that's really cool--what seems so much like SF is actually a real-life job that some people do everyday.
We all live moments away from science fiction. A fictional story about the challenge of escaping a car after it goes over a bridge into a river can be science fiction if the accident is modelled according to our understanding of science instead of just done for dramatic effect. The juxtaposition of the vehicles crumple zones with how they'd react hitting a river from 30 feet up, how much time would the occupants REALLY have, how could they REALLY get out... etc.
Most good Science fiction are simply stories about people reacting to their environment within the bounds of their humanity, and the constraints of known science.
That environment can be trumped up with constructs which are not explained... whether its faster than light travel, or an alien race governed by a hive mind... or it can be entirely mundane (as in Gravity or my imagined car accident story).
What makes it science fiction is that once the rules of the environment is established, the characters react to it constrained by the rules of science.
What separates good science fiction from fantasy is that fantasy is not bound to establish and then follow a set of physics. It's free to continually introduce whatever capabilities the characters need as the story needs it. Fantasy follows whatever path the author wishes without constraint. Science fiction's defining characteristic is that the narrative is constrained and driven by known physics or known or speculative physics.
Now you might say, but that's true of James Joyce's Dubliners; it too is constrained by the rules of phyiscs. None of the characters are magical or fantastical and nothing impossible according to known physics happens. And that's true. The difference between science fiction and ordinary (non-fantasy) fiction is that in science fiction the narrative is driven in part by the science. Dubliners narratives are not driven by science.
So even CSI could have been really good science fiction. Except its not, because despite the trappings of science they toss it out the window left and right. Star Trek with its particle-du-jour... often is science fiction, because you are allowed to "pre-suppose" an alternate physics -- the trick is to play out the rest of the story constrained by it. Star Trek of course, as often as not, also fails to follow the rules it sets out for itself, and so deviates to space-fantasy or something... but many of its good episodes are good SF.
Address Space Layout Randomization (ASLR): In older versions of Windows, core processes tended to be loaded into predictable memory locations upon system startup. Some exploits work by targeting memory locations known to be associated with particular processes. ASLR randomizes the memory locations used by system files and other programs, making it much harder for an attacker to correctly guess the location of a given process. The combination of ASLR and DEP creates a fairly formidable barrier for attackers to overcome in order to achieve reliable code execution when exploiting vulnerabilities.
ASLR was introduced in Windows Vista and has been included in all subsequent releases of Windows. As with DEP, ASLR is only enabled by default for core operating system binaries and applications that are explicitly configured to use it via a new linker switch.
As for EMET and ASLR:
Basically EMET can force recent versions of Windows to use ASLR even on applications that don't explicitly build with support for it:
EMET can force a non-Microsoft application to perform ASLR on every component it loads, whether the program wants it or not. Please note that before you install EMET, youâ(TM)ll need to have Microsoftâ(TM)s.NET Framwork 4 platform installed. And while EMET does work on Windows XP (Service Pack 3 only), XP users cannot take advantage of mandatory ASLR and a few other notable protections included in this tool.
I agree that there are better alternatives to sharing passwords in many cases.
I just think that the scenarios where "sharing" is so far-and-away the easier (perhaps even "better") solution that they shouldn't be classified as a 'rare exception'. Its pretty common.
For example, my wife and I both need the passwords to all of our utility accounts. The teenaged kids have the login to netflix. We all share the login to the HTPC in the living room rather than having separate accounts. These are all cases where I "have" to share passwords.
If I had a trusted guest house-sitting while I was away? Would I change the netflix and wifi and htpc and alarm code just for their visit? No. I could, but I wouldn't bother. Not in a million years. This is a case, where I *could* change the password and change it back... but I wouldn't.
If I had to give my some tech at my cell carrier my password so they could log into my account to look at it with me (something I HAVE had to do in the past) then yes, I do change it, give them a temp, and then change it back.
People need to think about it on a case by case basis. A "sharing passwords is always wrong" mentality is absurd... a "give your password to anyone who needs into your account" mentality is just as absurd.
Each case needs to be evaluated on its own merit... value of what is being protected, level of trust to the individual, level of hassle, etc. Neither scenario is exceptional or rare.
Unfortunately, the exemption you quoted doesn't cover what I am doing,
I read it as the law targeting drones that show a guided intent to record someone, you read it as the law including anything that happens to catch an image of anybody.
It proposes "filming people unawares from a drone" as being a problem. I see that as being distinct from simply having an image of somebody in the shot as you fly by.
Just as I can tell the difference between being incidentally in the background of someone's photograph, and someone photographing me. Or the difference between someone behing behind me, and someone following me.
I see the law as only targeting deliberate use of the drone to take video of people unawares, not your backyard scenario.
I fly my drone I'm guilty -- for flying my own drone in my own backyard with the clear intent of videoing only my backyard. Oops, caught a bit of the neighbors again. Here come the cops....
So move where you have a less idiotic neighbor. Because even if they don't pass this law, the neighbor can STILL call the cops if he sees you flying a drone around his yard with a camera, and you'll potentially STILL get charged under the existing anti-peeping laws, or at the very least harassed and questioned, and have the contents of your camera examined to establish you weren't peeping.
Hell, you don't even need a drone. The minute you pull a camera out on your deck, those neighbors can call the cops and accuse you of trying take pictures through their windows... using a camera or telescope (or zoom) to look through your neighbors window is ALREADY illegal.
My point HERE is that if you have THOSE neighbors, you are already screwed.
Either a vendor thinks the market is large enough to bother with or not. The "level of bother" factor is largely irrelevant.
ROI.
What is the Return on the Investment? The "level of bother" is the "I". The smaller the "level of bother", the better the ROI, the more likely the vendor will do something.
That said, I DO agree that if the R in ROI is sufficiently small, then even if the I goes to zero it still won't be worth the vendors while. Lots of large companies require both a high absolute R, plus a reasonable ROI, which is why you get companies shutting down small but otherwise perfectly profitable business units. (which is VERY frustrating...)
Are you seriously attempting to imply that the rare exception should justify the rule for normal behavior? I really hope not, but that's how I read what you wrote.
Not at all. When you can change to a temporary and back you should. But the exceptions where that isn't simple aren't all that rare. (And in the case of systems that won't let you change back, you often don't find out until after you've gone down the rabbit hole; so its especially annoying.)
Wifi pre-shared keys for example are a prime common-as-dirt scenario, where its a giant PITA to change them for a temporary guest, just to avoid sharing your password.
Even if you trust someone to fix a problem, why would you trust them with your password? Set a temporary password so they can fix something, then change it back when they are done fixing.
These days, common as not, you aren't allowed to set it back to what it was before. I think gmail, for example, now enforces password history for example. Pretty infuriating, because I DO generally change passwords before giving someone temporary access.
If you want a "proper" car analogy...
You would talk about those cars with the little number pad above the door handle?
I have no idea why you would give someone the temptation, especially when there are simple safe alternatives.
a) You can't change the password from where you are. Happens all the time. Maybe you are giving the person the password precisely so they can help resolve the problem preventing you from logging in where you are.
Your buddy borrowed your truck, you lent him the keys, and he locked them in the cab... he's 500 miles from anywhere. Do you tell him the keypad code?
Best practices says if you do this, change the code when you get the truck back. No problem.
Maybe you have a whole fleet of trucks, and for simplicity you had the same code on all of them. Now your fucked and have to re-key the whole fleet...
b) Cases where changing the password creates rolling chaos. Think scenarios where the same password is on several devices. For example you want to let a guest onto your home wifi but don't want to give him the password -- changing it while he visits knocks everything else you have off the network. Other scenarios -- backups, where multiple computers backup to a service and all use the same key, or various file sync things, where changing the password will throw errors up all over the place.
Yeah, because using my own drone to video in my own backyard is SUCH a douchebaggy thing to do, because it might possibly see over the fence I PAID TO INSTALL and catch a bit of you in your yard while I'm using it.
Its not. And its highly unlikely to fall afoul of the law. That was my point.
Well, if I'm taking video of me in my own backyard them I'm identifiable, and I'm going to hazard a guess that those people in my neighbor's yard that is in view will be identifiable, and I'm not doing artistic or journalistic operations...
Nor are going out of your way to record them in any way; and presumably you'll blur or edit them out before you post any video/stills online... so...?
I think it should not be illegal for me to fly my drone in my backyard just because the focal length of the lens on the camera it carries means it will take images of my backyard and a bit of someone else's.
It doesn't appear the law would make that illegal. It proposes to make filming people unawares from a drone illegal. Catching a "bit of someone elses back yard" while flying in your own hardly sounds like you are filming other people.
Certainly the law should not allow someone to damage my drone while I am flying it in my backyard just because they are paranoid that it might have a camera and that the camera might be catching them in its view.
I must have really missed something. Where did it say they may damage the drone in your own backyard based simply on a suspicion that it MIGHT have a camera?
If the goal is to make "doing X" illegal, then make that illegal and don't waste time adding "from a drone".
Your realize we don't actually have the draft proposal in front of us. Perhaps it merely calls out low altitude aerial photography and doesn't call out "from a drone". Perhaps "from a drone" was simply added to the news release because drone is a good keyword that gets hits, and "drone photography" is the root cause prompting this law. But perhaps, just perhaps, the proposed law doesn't specify it has to be "from a drone".
As for the rest, according to the news article:
"However, the proposal has many exceptions, which include permissible taping and photographing for mapping or artistic or journalistic purposes as long as the recording shows several residences and no individual is identifiable. The ordinance also would allow violators a defense if the person destroyed the photos or tapes upon learning of the law as long as he or she did not record or photograph children, sex or nudity or distribute the images or recordings."
So it seems pretty clear that unless you are being a douchebag, you won't run afoul of this law, and your fears about being harassed for flying a drone in your backyard where you might catch a bit of the neighbors yard are just hysterics.
Why should the platform matter, when the alleged goal is "privacy" and the taking of pictures?
The law reacts to a perceived problem, written by people who are primarily adept at things like fundraising and image management.
"residency" and "citizenship" are prerequisites for the job. "Writing good Legislation 101" isn't.
Should there be a law that makes it illegal to use a tripod with a camera to take pictures of people that violate their privacy? How about using a stedi-cam to do the same thing?
These don't generally allow different vantage points than just holding it. So the rules and norms for already in place for photography are reasonably adequate. A drone enables a heretofore generally inaccessible vantage point. It is the new "problem" in question.
Can I throw my camera up in the air to get over-the-fence shots?
If that actually becomes a widespread problem, then we can expect a new law to be passed.
Just as a law was recently passed in response to someone taking upskirts after it was found the existing laws didn't close off the loophole the photographer was using.
You are right, in the sense that the law outlawing the 'platform to take photos' is silly, that it should be a law defining what a "privacy invading photo" is and then outlawing that.
But that's ultimately a circular argument, since the definition is going to be one that includes "taking low altitude shots of people otherwise unaware, from vantage points a photographer could not normally stand, such as from a drone" anyway; and some smart ass is immediately going to ask... "what I drop my camera on the trampoline and it bounces up goes off and just happens to snap the neighbors back yard, am I a criminal now?"
The issue is not "should be", it is a matter of legality.
The law is an very imperfect expression of what society wants the rules to be, usually written re-actively to problems as they arise.
If your complaint is that its a pretty shitty system, then we agree.:)
If your complaint is that you should be able to take photos of your neighbors yard from a drone, then we don't.
Specifically reinterpret_cast. It's almost as unsafe, if not as unsafe, as good old C style casting.
Its exactly as unsafe. The difference is that it cannot happen by accident. You are telling the compiler, in very explicit terms that you WANT the reinterpret_cast behavior.
And strongly typed means you can't change the type.
Casting doesn't change the type of the thing being cast. It just lets you treat the thing being cast as if it were a different type. typeof(x) never changes.
Only if they went up there to take pictures of the neighbors instead of fix the roof.
Did he violate her privacy (during the day, it wasn't obvious from the outside that the elevator walls were see though so if she was a visitor, she might not have known).
First she was sunbathing on the roof of a smaller building adjacent to a taller one. Even if she didn't know the elevator was see through it would have been pretty obvious to her that there was would be all kinds of windows and such on the building overlooking her.
Second, like a lot of law, intent comes into play.
She wasn't really in a private place (given the building next to her that you were in was taller; and second, all you did was happen to see her in your normal course of doing what you were doing.
Now, if you'd rented a room on the top floor, brought your telescope and camera, and spent the day looking for undressed women to photograph and post onto your blog --- then that's an ENTIRELY different class of behaviour, and I really shouldn't even have to explain that to someone.
Even a child can tell the difference between the happenstance of seeing someone naked, and going out of their way to see (and photograph) someone naked. I find it amusing (disappointing!) that so many on/. try to pretend one is the same as the other.
How much of the high price of smartphones when purchased up front comes from an expectation that hardware will be subsidized by an inflated monthly bill for voice and data service?
I actually think you are right here, that a considerable amount of the price is inflated due to the cost rarely being directly paid, preventing competitive pricing to take effect.
We can however, use wifi tablets as a proxy for the pricing. A basic ipad Mini wifi runs $400, a galaxy tab pro 8.4 runs $329; the cheaper galaxy tab 4 runs $250. These are all for devices with ~8" screens give or take.
If we assume (and I concede its significant assumption) that the "savings" by shrinking the screen to ~5" is offset by higher costs making it that small... and then add a $100 cellular radio markup on it.
Then premium phones in a properly competitive market would run $350-$500. Instead of $500-$700.
So it MAY be inflated pricing due to carrier subsidy arrangements; or it may be the assumption that shrinking to 5" actually costs quite a bit more than we allowed for.
Slashdot Mirror
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.
Hence my point:
"b) to remove untrusted apps ability to pre-empt the screen"
Its silly that this is possible, and hopefully we see patches real soon.
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.
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.
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.
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 (?)
The premise was "given enough time...".
By taking the site down, you limited the time.
That's not an "exception", that's violating the premise.
Gravity isn't science fiction
Of course it is.
We actually do send people into space, and that kind of disaster could sort of happen.
But we didn't send anyone named Dr. Ryan Stone on space shuttle mission STS-157, and none of the other events in the film ever happened... so its CLEARLY fiction.
And it is science fiction because many of the antagonists/obstacles are consequences of the known rules of physics.
It handily meets any definition of science fiction I would ever care to use.
And that's really cool--what seems so much like SF is actually a real-life job that some people do everyday.
We all live moments away from science fiction. A fictional story about the challenge of escaping a car after it goes over a bridge into a river can be science fiction if the accident is modelled according to our understanding of science instead of just done for dramatic effect. The juxtaposition of the vehicles crumple zones with how they'd react hitting a river from 30 feet up, how much time would the occupants REALLY have, how could they REALLY get out... etc.
Most good Science fiction are simply stories about people reacting to their environment within the bounds of their humanity, and the constraints of known science.
That environment can be trumped up with constructs which are not explained... whether its faster than light travel, or an alien race governed by a hive mind... or it can be entirely mundane (as in Gravity or my imagined car accident story).
What makes it science fiction is that once the rules of the environment is established, the characters react to it constrained by the rules of science.
What separates good science fiction from fantasy is that fantasy is not bound to establish and then follow a set of physics. It's free to continually introduce whatever capabilities the characters need as the story needs it. Fantasy follows whatever path the author wishes without constraint. Science fiction's defining characteristic is that the narrative is constrained and driven by known physics or known or speculative physics.
Now you might say, but that's true of James Joyce's Dubliners; it too is constrained by the rules of phyiscs. None of the characters are magical or fantastical and nothing impossible according to known physics happens. And that's true. The difference between science fiction and ordinary (non-fantasy) fiction is that in science fiction the narrative is driven in part by the science. Dubliners narratives are not driven by science.
So even CSI could have been really good science fiction. Except its not, because despite the trappings of science they toss it out the window left and right. Star Trek with its particle-du-jour ... often is science fiction, because you are allowed to "pre-suppose" an alternate physics -- the trick is to play out the rest of the story constrained by it. Star Trek of course, as often as not, also fails to follow the rules it sets out for itself, and so deviates to space-fantasy or something... but many of its good episodes are good SF.
Or a kid's first attempt at a project... backed by his family... who knows.
There's also nothing stopping a thief from stealing a phone, dismantling it for the screen, then selling the screen.
So because it will only stop most phone theft crime instead of ALL phone theft crime that it's a bad idea? Is THAT your argument?
They say ASLR is disabled
I *think* what they are saying is that:
ASLR is disabled in their build of the software. (It must be enabled via compiler option).
However, ASLR is enabled in windows itself.
from Microsoft:
http://www.microsoft.com/secur...
Address Space Layout Randomization (ASLR): In older versions of Windows, core processes tended to be loaded into predictable memory locations upon system startup. Some exploits work by targeting memory locations known to be associated with particular processes. ASLR randomizes the memory locations used by system files and other programs, making it much harder for an attacker to correctly guess the location of a given process. The combination of ASLR and DEP creates a fairly formidable barrier for attackers to overcome in order to achieve reliable code execution when exploiting vulnerabilities.
ASLR was introduced in Windows Vista and has been included in all subsequent releases of Windows. As with DEP, ASLR is only enabled by default for core operating system binaries and applications that are explicitly configured to use it via a new linker switch.
As for EMET and ASLR:
Basically EMET can force recent versions of Windows to use ASLR even on applications that don't explicitly build with support for it:
http://krebsonsecurity.com/tag...
EMET can force a non-Microsoft application to perform ASLR on every component it loads, whether the program wants it or not. Please note that before you install EMET, youâ(TM)ll need to have Microsoftâ(TM)s .NET Framwork 4 platform installed. And while EMET does work on Windows XP (Service Pack 3 only), XP users cannot take advantage of mandatory ASLR and a few other notable protections included in this tool.
Not really sure which post is "GP" at this point.
I agree that there are better alternatives to sharing passwords in many cases.
I just think that the scenarios where "sharing" is so far-and-away the easier (perhaps even "better") solution that they shouldn't be classified as a 'rare exception'. Its pretty common.
For example, my wife and I both need the passwords to all of our utility accounts. The teenaged kids have the login to netflix. We all share the login to the HTPC in the living room rather than having separate accounts. These are all cases where I "have" to share passwords.
If I had a trusted guest house-sitting while I was away? Would I change the netflix and wifi and htpc and alarm code just for their visit? No. I could, but I wouldn't bother. Not in a million years. This is a case, where I *could* change the password and change it back... but I wouldn't.
If I had to give my some tech at my cell carrier my password so they could log into my account to look at it with me (something I HAVE had to do in the past) then yes, I do change it, give them a temp, and then change it back.
People need to think about it on a case by case basis. A "sharing passwords is always wrong" mentality is absurd... a "give your password to anyone who needs into your account" mentality is just as absurd.
Each case needs to be evaluated on its own merit... value of what is being protected, level of trust to the individual, level of hassle, etc. Neither scenario is exceptional or rare.
Unfortunately, the exemption you quoted doesn't cover what I am doing,
I read it as the law targeting drones that show a guided intent to record someone, you read it as the law including anything that happens to catch an image of anybody.
It proposes "filming people unawares from a drone" as being a problem. I see that as being distinct from simply having an image of somebody in the shot as you fly by.
Just as I can tell the difference between being incidentally in the background of someone's photograph, and someone photographing me. Or the difference between someone behing behind me, and someone following me.
I see the law as only targeting deliberate use of the drone to take video of people unawares, not your backyard scenario.
I fly my drone I'm guilty -- for flying my own drone in my own backyard with the clear intent of videoing only my backyard. Oops, caught a bit of the neighbors again. Here come the cops....
So move where you have a less idiotic neighbor. Because even if they don't pass this law, the neighbor can STILL call the cops if he sees you flying a drone around his yard with a camera, and you'll potentially STILL get charged under the existing anti-peeping laws, or at the very least harassed and questioned, and have the contents of your camera examined to establish you weren't peeping.
Hell, you don't even need a drone. The minute you pull a camera out on your deck, those neighbors can call the cops and accuse you of trying take pictures through their windows... using a camera or telescope (or zoom) to look through your neighbors window is ALREADY illegal.
My point HERE is that if you have THOSE neighbors, you are already screwed.
Either a vendor thinks the market is large enough to bother with or not. The "level of bother" factor is largely irrelevant.
ROI.
What is the Return on the Investment? The "level of bother" is the "I". The smaller the "level of bother", the better the ROI, the more likely the vendor will do something.
That said, I DO agree that if the R in ROI is sufficiently small, then even if the I goes to zero it still won't be worth the vendors while. Lots of large companies require both a high absolute R, plus a reasonable ROI, which is why you get companies shutting down small but otherwise perfectly profitable business units. (which is VERY frustrating...)
Are you seriously attempting to imply that the rare exception should justify the rule for normal behavior? I really hope not, but that's how I read what you wrote.
Not at all. When you can change to a temporary and back you should. But the exceptions where that isn't simple aren't all that rare. (And in the case of systems that won't let you change back, you often don't find out until after you've gone down the rabbit hole; so its especially annoying.)
Wifi pre-shared keys for example are a prime common-as-dirt scenario, where its a giant PITA to change them for a temporary guest, just to avoid sharing your password.
You only believe an urban legend, a myth, a falsehood was true.
Give me a break. Everybody who lived at the time buying computers used MHz as a proxy for performance.
Those of us who did measure performance of machine over the past four decades used benchmarks.
I'm sure you did. I remember the benchmarking tools too. I know anyone professionally measuring performance used them.
But the majority of the buying public, and a great deal of corporate/business/enterprise/educational buyers too made all their decisions based on MHz.
The reason there were so many articles about the "MHz myth" -- it was precisely because a LOT of people were using MHz as a performance metric.
Its simply ridiculous to claim that nobody was using MHz as a performance metric.
Even if you trust someone to fix a problem, why would you trust them with your password? Set a temporary password so they can fix something, then change it back when they are done fixing.
These days, common as not, you aren't allowed to set it back to what it was before. I think gmail, for example, now enforces password history for example. Pretty infuriating, because I DO generally change passwords before giving someone temporary access.
If you want a "proper" car analogy...
You would talk about those cars with the little number pad above the door handle?
http://support.ford.com/vehicl...
I have no idea why you would give someone the temptation, especially when there are simple safe alternatives.
a) You can't change the password from where you are. Happens all the time. Maybe you are giving the person the password precisely so they can help resolve the problem preventing you from logging in where you are.
Your buddy borrowed your truck, you lent him the keys, and he locked them in the cab... he's 500 miles from anywhere. Do you tell him the keypad code?
Best practices says if you do this, change the code when you get the truck back. No problem.
Maybe you have a whole fleet of trucks, and for simplicity you had the same code on all of them. Now your fucked and have to re-key the whole fleet...
b) Cases where changing the password creates rolling chaos. Think scenarios where the same password is on several devices. For example you want to let a guest onto your home wifi but don't want to give him the password -- changing it while he visits knocks everything else you have off the network. Other scenarios -- backups, where multiple computers backup to a service and all use the same key, or various file sync things, where changing the password will throw errors up all over the place.
Yeah, because using my own drone to video in my own backyard is SUCH a douchebaggy thing to do, because it might possibly see over the fence I PAID TO INSTALL and catch a bit of you in your yard while I'm using it.
Its not. And its highly unlikely to fall afoul of the law. That was my point.
Well, if I'm taking video of me in my own backyard them I'm identifiable, and I'm going to hazard a guess that those people in my neighbor's yard that is in view will be identifiable, and I'm not doing artistic or journalistic operations ...
Nor are going out of your way to record them in any way; and presumably you'll blur or edit them out before you post any video/stills online... so...?
I think it should not be illegal for me to fly my drone in my backyard just because the focal length of the lens on the camera it carries means it will take images of my backyard and a bit of someone else's.
It doesn't appear the law would make that illegal. It proposes to make filming people unawares from a drone illegal. Catching a "bit of someone elses back yard" while flying in your own hardly sounds like you are filming other people.
Certainly the law should not allow someone to damage my drone while I am flying it in my backyard just because they are paranoid that it might have a camera and that the camera might be catching them in its view.
I must have really missed something. Where did it say they may damage the drone in your own backyard based simply on a suspicion that it MIGHT have a camera?
If the goal is to make "doing X" illegal, then make that illegal and don't waste time adding "from a drone".
Your realize we don't actually have the draft proposal in front of us. Perhaps it merely calls out low altitude aerial photography and doesn't call out "from a drone". Perhaps "from a drone" was simply added to the news release because drone is a good keyword that gets hits, and "drone photography" is the root cause prompting this law. But perhaps, just perhaps, the proposed law doesn't specify it has to be "from a drone".
As for the rest, according to the news article:
"However, the proposal has many exceptions, which include permissible taping and photographing for mapping or artistic or journalistic purposes as long as the recording shows several residences and no individual is identifiable. The ordinance also would allow violators a defense if the person destroyed the photos or tapes upon learning of the law as long as he or she did not record or photograph children, sex or nudity or distribute the images or recordings."
So it seems pretty clear that unless you are being a douchebag, you won't run afoul of this law, and your fears about being harassed for flying a drone in your backyard where you might catch a bit of the neighbors yard are just hysterics.
Why should the platform matter, when the alleged goal is "privacy" and the taking of pictures?
The law reacts to a perceived problem, written by people who are primarily adept at things like fundraising and image management.
"residency" and "citizenship" are prerequisites for the job. "Writing good Legislation 101" isn't.
Should there be a law that makes it illegal to use a tripod with a camera to take pictures of people that violate their privacy? How about using a stedi-cam to do the same thing?
These don't generally allow different vantage points than just holding it. So the rules and norms for already in place for photography are reasonably adequate. A drone enables a heretofore generally inaccessible vantage point. It is the new "problem" in question.
Can I throw my camera up in the air to get over-the-fence shots?
If that actually becomes a widespread problem, then we can expect a new law to be passed.
Just as a law was recently passed in response to someone taking upskirts after it was found the existing laws didn't close off the loophole the photographer was using.
You are right, in the sense that the law outlawing the 'platform to take photos' is silly, that it should be a law defining what a "privacy invading photo" is and then outlawing that.
But that's ultimately a circular argument, since the definition is going to be one that includes "taking low altitude shots of people otherwise unaware, from vantage points a photographer could not normally stand, such as from a drone" anyway; and some smart ass is immediately going to ask... "what I drop my camera on the trampoline and it bounces up goes off and just happens to snap the neighbors back yard, am I a criminal now?"
The issue is not "should be", it is a matter of legality.
The law is an very imperfect expression of what society wants the rules to be, usually written re-actively to problems as they arise.
If your complaint is that its a pretty shitty system, then we agree. :)
If your complaint is that you should be able to take photos of your neighbors yard from a drone, then we don't.
C++ isn't strongly typed
Yeah it is.
Specifically reinterpret_cast. It's almost as unsafe, if not as unsafe, as good old C style casting.
Its exactly as unsafe. The difference is that it cannot happen by accident. You are telling the compiler, in very explicit terms that you WANT the reinterpret_cast behavior.
And strongly typed means you can't change the type.
Casting doesn't change the type of the thing being cast. It just lets you treat the thing being cast as if it were a different type. typeof(x) never changes.
So, roofers would regularly be violating privacy?
Only if they went up there to take pictures of the neighbors instead of fix the roof.
Did he violate her privacy (during the day, it wasn't obvious from the outside that the elevator walls were see though so if she was a visitor, she might not have known).
First she was sunbathing on the roof of a smaller building adjacent to a taller one. Even if she didn't know the elevator was see through it would have been pretty obvious to her that there was would be all kinds of windows and such on the building overlooking her.
Second, like a lot of law, intent comes into play.
She wasn't really in a private place (given the building next to her that you were in was taller; and second, all you did was happen to see her in your normal course of doing what you were doing.
Now, if you'd rented a room on the top floor, brought your telescope and camera, and spent the day looking for undressed women to photograph and post onto your blog --- then that's an ENTIRELY different class of behaviour, and I really shouldn't even have to explain that to someone.
Even a child can tell the difference between the happenstance of seeing someone naked, and going out of their way to see (and photograph) someone naked. I find it amusing (disappointing!) that so many on /. try to pretend one is the same as the other.
How much of the high price of smartphones when purchased up front comes from an expectation that hardware will be subsidized by an inflated monthly bill for voice and data service?
I actually think you are right here, that a considerable amount of the price is inflated due to the cost rarely being directly paid, preventing competitive pricing to take effect.
We can however, use wifi tablets as a proxy for the pricing. A basic ipad Mini wifi runs $400, a galaxy tab pro 8.4 runs $329; the cheaper galaxy tab 4 runs $250. These are all for devices with ~8" screens give or take.
If we assume (and I concede its significant assumption) that the "savings" by shrinking the screen to ~5" is offset by higher costs making it that small... and then add a $100 cellular radio markup on it.
Then premium phones in a properly competitive market would run $350-$500. Instead of $500-$700.
So it MAY be inflated pricing due to carrier subsidy arrangements; or it may be the assumption that shrinking to 5" actually costs quite a bit more than we allowed for.
If I had to guess its probably a bit of both.
Doesn't add as much as you think.
Bestbuy charges $100 between an LTE tablet and the wifi only one.
Apple charges $129 between an LTE tablet and the wifi only one.
Much of THAT is just profit.
So your $600 to $700 phone? Less than $100 goes towards the "cellular radio" capabilities.
well, I can see my neighbors back yard from my deck.
Then that has nothing to do with the post you were replying to.
You see in the post you replied to it was stipulated that they had taken steps to secure their privacy, by blocking your normal view.
If you can see it from your deck, then it should be obvious to you that have NOT taken steps to make their backyard private from you.
Now if you had to climb onto your roof and hang off the chimney to get a view that would be different.
Are you seriously saying I can't take a picture from my back deck?
Out of curiosity, even if it were legal, do you honestly think you should be taking pictures of the neighbors in their backyard?
Do you honestly not think that this would be the height of rudeness, even if it were legal?