Hacker Newsnew | past | comments | ask | show | jobs | submit | intransigent's commentslogin

Political quagmires like this only get untangled by terrifying psychos, unfortunately.

People only shut their mouths when they get threatened into a fearful silence, and/or sometimes if they get bribed enough.

Otherwise, you'll always have a substantially sized group of complainers dragging down a project this big, and the complainers leech into operations and mysterious expensive mistakes erode the budget of an already expensive operation.

There's just enough shrug factor here for people to not care about how much gas they burn driving to places that might not be very exciting to begin with.

Many would just as soon not have to travel at all, and even more would prefer to not be taxed so as to pay for trips they personally don't want to take to begin with. Most people just want their actual lives to be generally easier.

Without confrontational intimidation, bribery is probably the only other political lever to press in the United States.


Yeah, in a way, this sort of thing is indicative of a turing tarpit.

It's not obvious which, among all the moving parts, is responsible for any of the outcomes, just by looking at the commands themselves in isolation.

If someone did a similar thing in Brainfuck it wouldn't be entirely surprising that such a thing is possible, but the practicality of being able to getting it right every time, extemporaneously, is low.

It's interesting to know that this is possible, in case of emergency, but just because it's possible doesn't make it desirable.

If someone wrote an article about how to do the same in MS DOS batch files, circa 1996, it'd be an interesting proof of robustness, but an undesirable standard operating procedure.


Because many developers don't honestly believe that SQL represents a code execution boundary. Much of the time, the tendency is to think of SQL as simple I/O with a disk. And one rarely needs to worry about escaping interpretted expressions when streaming into and out of an I/O pipe.

They don't think of it as "executable code" because of the limited and monotonous nature of CRUD operations typically associated with data persistence.

They just think of it as yet another inconvenient form of declaritive data already at rest. Perhaps akin to mark-up. Raw data, like XML.

With JSON, some developers innately clue themselves in, because JavaScript, but they don't honestly understand the root of the hazard. They're just thinking FIRE BAD! Then they hack some JSONP into place because it's fun to do that sort of thing.

Most novice developers (my younger self included, tisk tisk) strongly resist protections against even HTML injection, until they see a massacre play itself out in the real world, when someone drops the ball.


This is also why smart money in appsec is focused on langsec and framework-integrated security controls, such as by forcing security patterns (e.g. html-context output encoding) by default and by compelling developers to work harder or, should they decide to break the rules, to do so more visibly.


("work harder to be wrong" specifically)


Reading XML ain't secure against malicious data either.


I don't know why you're downvoted, because this is exactly correct.

https://www.vsecurity.com//download/publications/XMLDTDEntit...

Granted, most modern parsers disable the features that can trigger this by default. But there's still a lot of code out there compiled against libraries that did not, and some of that code is still updated and extended today.


Well, the idea of global doomsday for all, beyond mere tactical retaliation, is probably drawn from the media, with movies like Dr. Stangelove playing the part of the primary narrative.

As to how much any world power has actually strategized and mobilized resources toward such an end (deliberate global suicide that destroys both sides by design) is likely to never be fully revealed, since it's a slightly alarming idea.

Even so, some of the plans that have been revealed really are quite terrible. Bad enough, that the difference between deliberate and accidental nuclear winters could be considered an argument that splits hairs.


Since when is Social Media participation a compulsory activity?


Since they raised $16 billion, making it the third-largest in U.S. history.


Old people aren't quite as tuned-in to the technical realities of the internet and its in-groups and out-groups.

The premise that "there is no anonymous" escapes 4 out of 5 people I talk to. It takes very careful explaining, to bring people to the understanding that their are hacking teams with names, that get away with things, and the things that those named sub-groups manage pull off are perpetrated by "some unknown, anonymous group of people" until evidence demonstrates who done it.

Because of this, The Proles (people who aren't paying close attention) often confuse the premise being a simple anonymous tipster with being affiliated with the fictious premise of an organized, regimented imaginary hacking group that possesses a rightful claim to the mantle of "Anonymous" as if it were Batman.

Then media outlets exploit this cluelessness, to sell advertising, by drumming up exciting click-bait that perpetuates the false narrative that there is a movement called Anonymous, rather than the prank call it really is.


Be nice and play ball, or you'll be subjected to a set-top-box appliance again.

  (it puts the lotion on its skin
   or it gets the hose again.)


Consider the possibility that lead poisoning inflicts just the type of mental disabilities that would lead a person to vote in such a fashion to begin with. With that in mind, is this really how you feel?


They are supposed to be captured from a twitter feed.


Isn't the petition itself a kind of database, naming and identifying specific individuals?

What if the petition itself is abused as a source of information?


That's the point of the petition: to publicly name people who had committed to the pledge. If you're worried about being publicly identified as a signatory, don't sign it.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: