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

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

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.