Recent Comments


Note: new comments may take a few minutes to appear on this page.

April 24, 2014 11:23 PM

Joe on Dan Geer on Heartbleed and Software Monocultures:

"The router situation is as touchy as a gasoline spill in an enclosed shopping mall."

Why is this guy, or anyone, concerned about their or any internet router? So long as it routes, who cares?

Use end to end encryption, assume everything in between is compromised. Any other course of action is illogical, always has been.

April 24, 2014 10:39 PM

Nick P on The Security of Various Programming Languages:

@ Mr Pragma

re C

I meant about what you meant, despite using only one sentence. It's quite useful for what it was designed to do even to this day & has a ton of tool support + expertise. The need for such things is why I like developments such as Cyclone, Typed Assembler, LLVM, etc. Gives us alternatives to C to solve this problem. For instance, ignoring syntax risks, C forces a certain structure on your program that might pose risks upon integration with a safer HLL (e.g. infamous Ada-C linking vulnerability). Coding directly in assembler or something else ultra low level + efficient might avoid this.

I've even considered coding in LLVM assembler, compiling that to whatever ASM I'm using, & integrating it inline in a safe language for performance critical part. That's cross-platform, low level, easily optimized code without C's structural decisions. C & an FFI is certainly an easier option, yet I figured I could throw a tool together that automates hard parts of the LLVM option. Also, high level assemblers such as Hyde's HLA & Linoleum have promise if further developed.

While your at it, check out PL/S. It's a PL/I variant without a runtime that IBM uses for mainframe OS development. They've improved on it for years and consider it a trade secret of sorts. Here's one paper describing it. The cool thing about it is it's still quite high level, yet it lets programmer specify per function how compiler handles certain things. So, it can be extremely efficient, safe, or some combo between. Also supports two different kinds of inline assembler according to one source.

"But frankly, I feel that D doesn't get widely accepted and used for a reason. Looking closer I found the very core, the "C mindset" again in D."

That's the point. The safer languages didn't replace C/C++. The one's that did have takeup are too inefficient. So, it's kind of a compromise where C/C++ people create a language they hope C/C++ people will like that's quite efficient. This is case for D, Cyclone, and Ironclad C++. I'm not advocating these over better options. But, I do give them credit for taking initiative to win C/C++ crowds over & getting rid of some big problems in C/C++.

"Frankly, I'm afraid, no matter how much one works around that approach one might create an indeed better C++ but one will not achieve to create anything really comparable to the Pascal ... Ada ... Eiffel line."

I agree with that. Plus, I hate people reinventing the wheel. If they want to exceed those safe languages, go right ahead. DECA and Habit come to mind. If they want to bring their C++ garbage in feature parity, it's a waste of effort. They're better off being clever bringing the safe languages into performance, tool, and library parity. *That* would be quite beneficial. I also like your "pimped up assert" comparison. Haha.

re Americans invented first

The point was less on absolute first and more to just show Americans have been pulling their weight on the issue for a while with many great contributions. That's all I was saying. Over here (and in general), quality and security are still minority players in software market. So, much of America's best work goes unused and, worse, unremembered by industry as a whole.

One example. I love listening to aspiring secure coders talk about canaries and other clever methods of dealing with stack overflow issues. Then, I point out MULTICS beat all the stuff by simply making stack flow *away* from control flow pointer. The "Holy S***" moment on their faces is priceless. Yet, it's also sad as not one has ever heard that stacks can be made immune to overflow or even figured out the obvious themselves. "Why do we make attacker data flow toward the critical location?" The question never asked. Many, many, many things like this over here. World-wide, too, far as I know.

"Yes, I agree, from what I see, in the usa the marketing push is stronger than across the ocean. French or German developers can be pushed only so far to produce sth. lousy but shiny and (why are they almost always overlooked?)"

Interesting. At least I give them credit as often promote both TU Dresden (TUDOS projects) and INRIA's work. Great work at both.

"the Russian are very favorably influenced by a very strong academic system and tradition. Actually, I think Russia is among the stronger supporters and users of Modula and Oberon (and probably would use more Ada if it hadn't the ugly american dod smell...). I'd bet anytime that the quality of Russian code is considerably better than american code (on average)."

I didn't know they used Modula and Oberon much over there. Matter of fact, now that you said it, I recall some Russian forums on the use of Blackbox Component Builder for Component Pascal (Oberon successor). So, they're using it and on the cutting edge of it.

It's known that Russian programmers are skilled. The clever malware writers are often Russian & continually invent clever tricks. The reason, though, might not just be education or culture. One Russian programmer said people often get only limited access to computers. (Cafes? Colleges?) There's only so much time to type in the code, test it, and so on. So, he said Russians put much more effort into getting the code right the first time. Reminds me of the old batch processing systems here in the States where a single mistake might throw a whole, expensive batch. They started inventing language constructs and strategies to make them less likely. The Russians seem to be doing the same, yet with modern hardware and tools. Quite a powerful combination.

"Generally speaking (and knowing perfectly well that there are exceptions) I tend to trust European software way more and I tend to consider american developers to be "hackers" (that's *their* term for themselves, not mine!)."

Ouch. We do have shops that focus on quality, even warranting code. That is *not* the majority by far. :( Most are what Clive Robinson calls "code cutters" that just throw stuff together, hope it works, fix what they could that didn't, and ship it. Industry focuses on shipping because customers demand it. Bugs get fixed over time. Note that I've seen the same thing over in Europe. Example is Windev in France: great tool at boosting productivity, yet has crapload of bugs that each take years to get fixed per users on their forums.

So, American software is only trustworthy if it's from a shop that focuses on quality. That's rare as it costs more & takes longer to make. I appreciate your opinion on the Europeans and I plan to get more data on it in the future. I was even considering specific countries over there for subversion-resistant development due to culture maybe having a positive influence on the process.

re Ada, elegance

I understand the feeling, yet disagree. Elegance is usually a sign of good design. Yet, the real world often forces tough tradeoffs for optimal behavior. Scheme was elegant, but Common LISP was more useful in practice. Haskell was more elegant, yet Ocaml provided many of it's benefits with faster execution & easier training. So, I'll trade away elegant if it's practical to not be elegant.

Funny you mention tagged because the first time I saw that I said "wth is wrong with these people? why don't they just call it what everyone does!?" I thought about rewriting some of that stuff just to make it use the real thing. Then, I looked at the complexity of an Ada compiler and changed my mind.

re Dewar lecture

I'll try to check it out.

re expectations of OS, developer and user

Good points. These bad assumptions keep recurring.

"To put it bluntly: No matter how many new security regimes we invent, create (probably in C/C++/java ...), and deploy, we can and will not stop the security bleeding using the very tools and paradigms that created them in the first place. Stop using C/C++/java - or be hacked. Simple as that."

Nice. I add "unsafe architectures" while we're at it.

@ name.withheld

"The two of you represent what I would considered the "most" useful deliberation on programming and security."

Why thank you! :)

"I said, "Go to your computer, locate the cable that is approximately a 1/4" wide (6mm) that is either black, white, or a light tan. Follow it to the termination point, typically a wall, and immediately pull it out!"

Haha. There was this old method.

"I noticed that Smalltalk is absent in the broad scope of tools for systems programming..."

I left it off on purpose. I wasn't sure if it was useful for low-level, efficient, systems programming. I did go back and consider it for web applications, yet the web frameworks weren't so impressive compared to others on the list. So, I just dropped it.

"But, just as I see Java as problematic, (sorry Nick P, I see the whole java eco-system as problematic--even with a JVP--it has created the same bad habits that C was known to do). "

No need to apologize. I'm not a Java fan. I do like the work on Java processors as they might allow efficient, type-safe system code with object support at instruction level. And half a dozen exist *right now* unlike both of our projects. I also noted that there's secure kernels and OS architectures, plus great static checkers for it. Seemed promising as an interim solution.

My plan was to make a core runtime in pure assembler language behind an interface, then map Modula/Oberon to the Java processor bytecode. Oberon to Java & a JVM on Oberon were both already done so this should be easy. Juice also did a Java applet alternative that sent Oberon abstract source tree's, which were typechecked & compiled locally. That in a capability architecture on a Java processor might be ridiculously robust compared to mainstream alternatives. The result would be a Wirth-like language used to program a relatively safe machine for low level, high level and web programming.

(Note: Ada to JVM has also been done. That would be the next step. Then, I could use an architecture like JX, SPIN, etc with Ada's or SPARK's type checking and no VM with huge attack surface.)

"I don't mean VM in the hardware sense, but in the sense of runtime cores that support some language/application environment."

It's fine if it's easy to analyze. Those language's VM/runtimes aren't. They're too big with designs that allow native code, esp in libraries, to end run the type system. So, I don't like them either. One exception is Lua as they kept theirs as simple as possible. So simple and consistent it might work without 100+ security holes.

"In engineering there is always the compromise--I don't care what technology or platform is selected, defined, utilized, or embraced--the architectural decisions that are visible at the "customer" level are always a compromise."

It sucks. The legacy problem is the biggest of all. I have no easy solution there except to secure what I can and have intrusion analysts carefully watch the rest.

"Don't get me wrong, I'm a big fan of masturbation, I just have a hard time getting my mind out of my trousers."

LOL. Most presenters & audience members at DEFCON, Black Hat and RSA are big fans of mental masturbation. So, no worry about standing out too much long as you keep it mental.

April 24, 2014 9:51 PM

cinnamonb on Conversnitch:

I'm not amused either, Callmelateforsupper. I guess they've been brought up with no respect for others' privacy. Sad. And sad anyone would even visit their twitter feed.

April 24, 2014 8:53 PM

Our Source on Airport Security:

I am genuinely keen of seeing funny video clips at youtube, and this video clip is in fact so humorous, hehehhe.

April 24, 2014 8:47 PM

montblanc füller on Eben Moglen and I Talk about the NSA:

I precisely wanted to say thanks again. I am not sure the things I would've followed without the actual hints discussed by you directly on such subject matter. It was actually a real frustrating matter for me personally, nevertheless being able to see this specialized avenue you dealt with the issue took me to jump for gladness. I'm happier for the advice and in addition expect you recognize what a great job you were getting into instructing the mediocre ones by way of your web blog. More than likely you haven't got to know all of us.
montblanc füller http://www.ssreuta.com/montblanc.html

April 24, 2014 8:35 PM

led stripes on Smuggling Liquids Through Airport Security:

Cheers to get discussing the following with people you probably realize what you are speaking somewhere around! Saved as a favorite. Remember to as well check with the web site Implies). You can easliy use a web page link buy and sell agreement between all of us

April 24, 2014 8:08 PM

DB on Friday Squid Blogging: Squid Jigging:

@ Figureitout

Being killed for my beliefs won't deter me from them. I can't do much, but where I can, I try. That's all we can do, right? We each have our tiny little part to play. And while the overall struggle of mankind might seem hopeless, I don't see my own individual struggle as hopeless, it's what keeps me sane.

April 24, 2014 8:05 PM

AlanS on Is Google Too Big to Trust?:

@Randalf

Paul Buchheit (Google employee #23): Coming Up With “Don’t Be Evil”

"I believe that it was sometime in early 2000, and there was a meeting to decide on the company’s values. They invited a collection of people who had been there for a while. I had just come from Intel, so the whole thing with corporate values seemed a little bit funny to me. I was sitting there trying to think of something that would be really different and not one of these usual “strive for excellence" type of statements. I also wanted something that, once you put it in there, would be hard to take out. It just sort of occurred to me that “Don’t be evil” is kind of funny. It’s also a bit of a jab at a lot of the other companies, especially our competitors, who at the time, in our opinion, were kind of exploiting the users to some extent....But the real fun of it was that people get a little uncomfortable with anything different, so throughout the meeting, the person running it kept trying to push “Don’t be evil” to the bottom of the list. But this other guy, Amit Patel, and I kept kind of forcing them to put it up there. And because we wouldn’t let it fall off the list, it made it onto the final set and took on a life of its own from there. Amit started writing it down all over the building, on whiteboards everywhere. It’s the only value that anyone is aware of, right?"

April 24, 2014 6:18 PM

name.withheld.for.obvious.reasons on Info on Russian Bulk Surveillance:

@ Skeptical

Thanks. You made my point, and, the subjugation of deliberation comes in many forms--including psychologically. An intellectually "honest" conversation requires more than one participant. Not to discourage you Skeptical, arguments made outside the narrow or collective thinking (we all come here with our own biases) is necessary--group think will kill the herd irrespective of their philosophical sense of the world. Just know that your comments do more to malign you than make it possible for you to be heard.

By the way, you should read another CRS report recently published on the FAS site. It is the definition of "belligerent" as it relates to domestic combatants.

April 24, 2014 5:58 PM

HEMORROIDE on Our Data, Ourselves:

Many thanks for a further helpful web-site. Where by more may perhaps I purchase that will type of facts designed in this suitable solution? I've a task that we are just at this moment focusing on, and I've been on the structure out and about to get like information.

April 24, 2014 5:54 PM

Arclight on Is Google Too Big to Trust?:

Another trend I have noticed lately is that Google ads allows banners that look like legit download links. I was trying ro download the latest build of Heidi Eraser at heidi.ie the other day, and I had to cancel 2 different snoopware downloads(which looked like mirror site links) before I found the less-obvious legit link.

April 24, 2014 5:25 PM

Mr. Pragma on The Security of Various Programming Languages:

I'd like to add a point.

It's about barriers and about them being mis-designed and misplaced.

Security - at least from one perspective - can be described as denying an attacker the means to attack (which again can be broken down into extending the time needed for attack, lowering the probability of success etc. but let's stay simple here).
So, a vulnerability is a means of (illegitimate) access and so is, say, (in a way) a properly secured and locked door with a window next to it that is made from soft wood and that lacks any security measures.

Accordingly, one way to "create" security is to *not* create weaknesses that offer means of illegitimate access.

Who is the foe and what is an attack? An attack can be described as an improper way of gaining access and a foe is anyone who employs methods to improperly gain access.
But what if improper access is gained without malice intent? What if, stupid example, my trousers have a hole and I'm losing money while walking? What if a woman undresses for bed and doesn't properly block any means of sight into the room?

Now, we're pretty close to programmers - unintentionally - creating weaknesses which sooner or later will be used as means for improper access (or operations, or ...).

Obviously, the woman should close the curtain properly and fully and so should the programmer. So why does neither of them always, reliably and fully? Is it the womans kink to be observed while undressing? Is it the programmers rational decision to create backdoors? Quite probably not - yet they do exactly that.

Or, to put it more bluntly, there is a trust problem namely, the problem to trust programmers that they are willing and capable to really fully understand each and every of their lines of code and to invest no matter what energy and means to code perfectly. Are they willing to do that? Quite possibly usually, yes. Are they capable to do that? Quite obviously frighteningly often, no.

To cut it short, an OS expecting the user (or program) to behave correctly, reliably and responsibly, got something very wrong. Maybe that approach would on another planet (like the one where those C/C++ developers who think they can and do create good code live *g).

Similarly, a language designer expecting the user, the developer, to behave correctly, reliably and responsibly, got something very wrong.
Realistically - and having profoundly understood some human properties - a language designer has to assume that his "users" can - and will - engage in improper use of his language.

Finally (ignoring more steps in between) a developer expecting his users to behave correctly, reliably and responsibly, got something very wrong.
Realistically - and having profoundly understood some human properties - a developer has to assume that his "users" can - and will - engage in improper use or even abuse of his program - not rarely even with malice intent.

Accordingly, developers have to base their work on the assumption that, be it with malice intention or just incompetence or due to other factors (and there are many with humans ...), their users (and often even the users/clients of their users; just think -> server) can - and *will* misuse or even abuse their software.
And so do Operating Systems. To achieve any not insignificant level of safety, reliability and security, their creators have to base their work on the assumption ... can - and *will* misuse or even abuse their software.
And finally, so do language designers - and the wiser ones did. They have to base their work on the assumption ... can - and *will* misuse or even abuse their language.

Last but not least we should considerably extend our understanding by recognizing and acting accordingly. Usually we still think of a security problem in term of evil, dark dressed attackers. Actually though, a very considerable part of security problems do not arise out of malicious attacks but are based on negligence, easy going, opportunity; accordingly they can not be avoided by building ever stronger vault doors or, in computer terms, by ever stricter security regimes, by adding CAP facilities on top on MAC, etc. - but by *additionally* avoiding the unintentional creation of, in effect, back doors.

To put it bluntly: No matter how many new security regimes we invent, create (probably in C/C++/java ...), and deploy, we can and will not stop the security bleeding using the very tools and paradigms that created them in the first place.

Stop using C/C++/java - or be hacked. Simple as that.

April 24, 2014 4:36 PM

Skeptical on Info on Russian Bulk Surveillance:

@name.withheld: Here's a very recent report from the Congressional Research Service on that very topic (Declarations of War and Authorizations of Military Force), via the FAS: https://www.fas.org/sgp/crs/natsec/RL31133.pdf

It looks like the first authorization of military force (without a declaration of war) was in 1798, in connection with France.

I haven't read the report, but I suspect Congress became more careful about using the word "war" because of the many other statutes that use would trigger. So when Congress wished to authorize the use of military force, but not trigger all the statutes that would accompany a declaration of war, they avoided using that word, essentially leaving it to the courts to determine the precise extent of the legal implications.

As to "important" and "designated", OED (which I'm hoping means Oxford English Dictionary and not some government organization!).

April 24, 2014 4:03 PM

Andrew Wallace on Is Google Too Big to Trust?:

@Will

Joe Sixpack buys into that strategy though.

NSA aren't interested in the view of the technical community.

As long as Joe Sixpack buys into Google being this independent corporation seperate from government then continue they do and mission accomplished.

When the Snowden leaks started to wake up the Joe Sixpack crowd, that is when there began to be ripples within the NSA.

April 24, 2014 3:52 PM

name.withheld.for.obvious.reasons on Info on Russian Bulk Surveillance:

@ Skeptical
Can you please frame the statement you made with the words 'designated' and 'important' in it...two issues are expressed based on the use of these words. I need to know the interpretation to understand what you are saying here...are we talking about OED or DoD definitions? And what in law, affirms the term AUMF with "War Powers"? The Korean war was the first divergence from explicit language to what could be termed 'literary license'.

"You mean persons designated as important members of al Qaeda affiliated organizations or persons actively aiding hostile operations against US forces? What does this have to do with your claim that the US is heading in an authoritarian direction?"

April 24, 2014 3:42 PM

Skeptical on Is Google Too Big to Trust?:


Obviously there'd be no way for a user to tell if Google started slipping sponsored links into its regular search results, but, with an exception, they'd have to sell the option to advertisers to make money from it, which would essentially make the fact public. According to Google, [i]f any element on a search result page is influenced by payment to us, we will make this fact clear to our users.

However, Google could put its own products and services on top of search results, and not distinguish this deliberate placement from regular search results. But this would be rather obvious.

I have to say that I'm a little skeptical of the idea that it's profitable for Google to attempt to capture and store every detail about a user. Based upon a glance at how Google sells advertising space to businesses, it doesn't appear that their ad service relies upon a sophisticated personality profile of each user.

April 24, 2014 3:39 PM

Will on Is Google Too Big to Trust?:

Actually it does not matter if they do it "openly" (Google's idea of "open" is I guess that they wrote about it in their privacy policy) or not.

Doing something "wrong" openly does not make it "right".


April 24, 2014 3:37 PM

name.withheld.for.obvious.reasons on Is Google Too Big to Trust?:

@ Bruce Schneier

I was happy to see you clarify the duckduckgo relationship with Microsoft. When you first recommended duckduckgo I was skeptical...looked at the underlying host scripts and was dismayed to find Microsoft sitting underneath the service.

What concerns me is what Microsoft considers evil to be--and do they or don't don't they share their non-evilness with others?

What is "tracking" in the parlance of duckduckgo--I'll get back to you after another go round with the source.

Don't get me wrong, you are appreciated many and your work help us and at least there is an advocate that is both informed and practical instead of shill for x,y, or z. Although you might be with w, at least from a basis vector perspective.

April 24, 2014 3:37 PM

Leigh V. Malone on Is Google Too Big to Trust?:

Identification of the user enables personalization of search results.

That's good if it serves the purposes of the user, but it's bad if it serves the purposes of someone who wants to harm the user.

In a political environment where the government targets their own population, users should aim to avoid being identified with respect to search engines for their own protection.

I know from first hand experience that Google is being used as a military weapon. That might be a good thing in a country that protects individual rights, but not under fascism.

The NSA's policy of intrusive surveillance, or "active defense", is just a euphemism for unprovoked aggression. It rationalizes the abusive shaping of search results for zersetzung purposes.

April 24, 2014 3:28 PM

Andrew Wallace on Is Google Too Big to Trust?:

It is best to operate in plain sight.

That was the thinking behind Google in the beginning anyway, while sat round the boardroom table.

With the introduction of Snowden leaks, its less of an open secret anymore.

April 24, 2014 3:09 PM

Ben R on Is Google Too Big to Trust?:

I'm echoing Mike here, but where does the claim of "unmarked ads in search results" come from? Can anyone show an example? I searched the Web for "google unmarked ads" (using Bing to satisfy the paranoid) and only found a picture showing ads against a blue background with web site names in green. These don't have the words "Ads" or "Sponsored links" above them but I've always understood that they were ads.

Google has never mixed ads with the so-called organic results or accepted money in exchange for higher ranking in the organic results. If they ever change that policy it will be a huge story, but I don't think they ever will because they would probably lose half their web search customers to Bing in a week.

April 24, 2014 3:00 PM

Joseph Roser on Is Google Too Big to Trust?:

Despite the amount of data it collects, Google ad targeting is still very poor. To give you an example, often there are inappropriate ads posted around articles that describe real tragedies. They get the context wrong in most cases.

April 24, 2014 2:49 PM

RG on Is Google Too Big to Trust?:

Its even worse than you think.

Now its Google Shopping (which they have in Silicon Valley). You sign up and they do your shopping for you.

So they know where you shop (you tell them the stores), what products you buy (you tell them that), how often you purchase, how much you spend, (credit card info?) and where you live or work (they deliver to you).

All this from the company that created the Google glasses and sent their minions out to record everyone everywhere....

April 24, 2014 2:26 PM

bazzz on Is Google Too Big to Trust?:

On a corporate scale it's too big to be trusted. So much data, so many individuals with access to it.

I have a bet going on that Google will be split up by the DoJ by 2018 just like AT&T corp, one entity for mobile devices, one for the core search engine, one (or multiple) for the remainders.

April 24, 2014 1:49 PM

name.withheld.for.obvious.reasons on The Security of Various Programming Languages:

@ Nick P, Pragma

The two of you represent what I would considered the "most" useful deliberation on programming and security. Notice, I didn't phrase it as secure programming--that's an oxymoron. Secure programming is not necessarily a centrality of any "secure" system. Recently a friend asked me if he was a risk for subjugation via a form on some web site...

I said, "Go to your computer, locate the cable that is approximately a 1/4" wide (6mm) that is either black, white, or a light tan. Follow it to the termination point, typically a wall, and immediately pull it out!"

There--now you've secured your system. (And still, there is a, albeit highly unlikely, risk of subversion.)

I noticed that Smalltalk is absent in the broad scope of tools for systems programming...there was an effort over a decade ago to get Smalltalk on embedded computing platform. But, just as I see Java as problematic, (sorry Nick P, I see the whole java eco-system as problematic--even with a JVP--it has created the same bad habits that C was known to do). Smalltalk shares what I see as problematic with VM cores. I don't mean VM in the hardware sense, but in the sense of runtime cores that support some language/application environment.

In engineering there is always the compromise--I don't care what technology or platform is selected, defined, utilized, or embraced--the architectural decisions that are visible at the "customer" level are always a compromise. Why, just as Bruce has said and is his mantra--there is no absolute security.
Expectations almost never match reality--I call it "Engineering Relativity".

I don't have a "solution" for a problem that I and most of my colleagues didn't create--or even know about. This kind of architectural hijacking by entities that represent "institutional" trust is a beast I didn't envision battling as a young child embracing the religion of science as the the only true path. What a fool was I? What I do know, we are getting nowhere--the amount of progress that represents are "re-balancing" is nothing more than intellectual masturbation. Don't get me wrong, I'm a big fan of masturbation, I just have a hard time getting my mind out of my trousers.

A year later and the broad scope of security issues that we KNOW about are still at issue...I need to go and read a EULA to remind me of the source of the problem. My rant for the week...

April 24, 2014 1:37 PM

Curious on Is Google Too Big to Trust?:

Isn't Google behind the so called "super cookies"? I don't like that. I don't want companies to dog me around so that it makes sense for them to push ads onto me in particular.

I don't know if super cookies are a current thing or something that is supposed to be used in the future.

April 24, 2014 1:01 PM

Andrew on Conversnitch:

Well, in some countries a common government surveillance practice is to bury tiny cameras inside walls leaving only a small hole for the lens with like 0.01 inches diameter. You need to be quite close and very careful to notice them with naked eyes...even harder to detect if they are connected to electrical system and don't send wireless data.
(PS The detection gear is quite expensive and not always efficient.)

April 24, 2014 12:59 PM

MIke on Is Google Too Big to Trust?:

I've seen the claim about "unmarked ads in search results" from google for a while now. I've never seen such ads. I do see ads at the top (or bottom) of the search results, but they are always marked as such. Here's a typical example: the ad is clearly marked with a different background color and the words "Sponsored Links" in the upper right. Yeah, I can see that some people might be confused by these, but still - they are marked. Google does play with them - today, the colored background is restricted to the word "Ad" next to the link, and there's a subtle frame around them.

And yes, there are links to or into that site in the search results. Personally, I always click on the sponsored links, so the company has to pay for my eyes.

April 24, 2014 12:49 PM

Johannes Rexx on Conversnitch:

So what equipment have people used to scan for and locate these bugs? Those of us who are paranoid enough and have enough money might want to expand their skill set.

April 24, 2014 12:46 PM

Mbck on Heartbleed:

@Nick P

Sorry about the dead link -- I just tried this one -- http://jack.hoa.org/hoajaa/BurrMain.html -- which, from here, is live.

Some quick notes, and more thanks...

- Yes, MCP-on-Intel is emulated. From what I remember, and which is somewhat confirmed in Allweiss's notes, this is the result of an effort to formally document the instruction set for Large Systems - "e-Mode" for "emulated mode". Up to the B6900, each machine model was slightly different from the others, because of the changes in the type of logic being used - that world was changing fast then.

It did not matter too much, since the Burroughs compilers were very fast and everything was available as source code: you got a new iron, brought up a minimal MCP that ran on the intersection of all instruction sets (...), compiled the compiler for that specific box, then compiled the MCP, the libraries, ... and eventually the application programs. Still if an installation had several boxes, it was a nuisance.

I would put e-Mode in the same class as p-code. Java tries to be much more, emulates much more than just an instruction set, and gets immensely complicated because of that.

But I agree: what we need is not toe revive the B5500 product line with all its warts and limitations, but to sresume learning about NUMA, block-structured languages, and proper encapsulation as close to the hardware as possible.


- Cactus stacks and Tandem. I quickly looked at the article; while the need for a "cactus stack" exists both in any complex MCP program and in the environment thewy describe, they apparently serve different purposes. The Tandem article does not even reference Large Systems. Interesting other anecdotes: at Burroughs, I heard the tale that one of the Tandem architects was one of Burroughs' own hardware developers - never could verify, and now I do not remember his name. Wikipedia pays tribute to the B5500/6800, but traces Trandem back only to the HP3000.

- C, HLLs and Assemblers. For what I remember, the main push for C in early UNIX was to write as much as possible in a portable language. There were a few parts of the OS that were written in PDP-11 machine language, but I would say about 2%. The emphasis was on extensibility, portability and reasonable efficiency.

C delivered on most counts. For extensibility, it forgot about adding language constructs for addressing new domains, relying on libraries instead. Portability was actually limited to 8-bit-byte addressable machines -- I remember an attempt to port UNIX to a VARIAN620, word addressable, no good. But the industry eventually went to byte-addressability and the problem went away.

Secure programming was not a big concern; space was, since the design was for a machine that could only address 64Kbytes per process space. Hence things like zero-terminated strings and the presence of strcpy in the libraries.

We should learn from the car industry. They also started competing on speed (and luxury) with little attention to reliability and safety; they came a long way. Hopefully Computer practice will, too.

Just like thirty years ago the slogan was "quality is free", we should say that "security is free" as well. Will take twenty years.

...

Cheers!


Cheers!

April 24, 2014 12:40 PM

squarooticus on Is Google Too Big to Trust?:

Google is not as bad as the government, because they cannot imprison me. Period. Say what you will about Google's abuses, the consequences are simply not as dire, and unlike government you can opt out of Google, as difficult as that might be from a practical standpoint.

April 24, 2014 12:33 PM

Jones on Is Google Too Big to Trust?:

@Bob S
Maybe slavery is the natural state of mankind

I would say it is more like a 'natural tendency'. Actually the ultimate power in a capitalistic system comes from capital, commonly known as cash (as opposed to other forms of money, e.g. that what has been borrowed, etc).

Those with capital then of course 'rule'...they have what others desire (or need, in order to feed themselves).

And those who rule, who have authority for others, have for a long time not been particularly benevolent with that authority. Some thousands of years ago the following was written in Ecclesiastes 8:9:

"All of this I have seen, and I applied my heart to every work that has been done under the sun, during the time that man has dominated man to his harm."

April 24, 2014 11:48 AM

Bob S. on Is Google Too Big to Trust?:

Google Chairman Eric Schmidt:

"Well, it was invented by Larry [Page] and Sergey [Brin]," said Schmidt. "And the idea was that we don't quite know what evil is, but if we have a rule that says don't be evil, then employees can say, I think that's evil.

Now, when I showed up, I thought this was the stupidest rule ever, because there's no book about evil except maybe, you know, the Bible or something."

http://www.dailytech.com/Googles+Eric+Schmidt+Dont+Be+Evil+was+Stupid/article31544.htm

So, get over it, Google is evil as the rest, maybe more sometimes, maybe less.

Evil is evil.

Also, please recall the promise of paid content on cable TV with "no ads". That's was a lie of course, and so we pay for content and watch tons of ads, too. The point is, the corporation will do anything it can to maximize profit.

That's where government regulation is supposed to come in, but our government has become totally incompetent, useless, corrupt and dare I say....evil.

There is no good ending to this story as it stands now. We are free falling into pluto-corporate fascist police state making us all electronic slaves.

Maybe slavery is the natural state of mankind, master and slave while the brief spasm of egalitarinism in the USA was an aberration.

April 24, 2014 11:46 AM

Randalf on Is Google Too Big to Trust?:

@Anony
You all take for granted that when you search on Google, the links that pop up are legit, legal, useful, free of malware, etc.

Maybe that is the problem. Because they are not all useful nor free of malware. Or even legal for that matter.

On another note, Bruce should make another article titled "Is Google Too Big to be Criticized?"

Once the user-base of a company grows past a certain threshold, any criticism against the company can be stiffled by someone from within that user-base.

April 24, 2014 11:44 AM

bcs on Is Google Too Big to Trust?:

The most effective ad will always be an ad the customer *wants* to see. Google knows this.

Also re: data collection, it works best when people *want* to make there data avalable. Google also knows this.

April 24, 2014 11:21 AM

Sandi on DEITYBOUNCE: NSA Exploit of the Day:

Deitybounce has evolved since 2008. I found it on one of my desktops. It told my Sony that it was a DellPowerEdge 2850 and proceeded to repartition my hard drive. A single partition became five partitions with two called unallocated space. It replaced the MBR and loaded it from the 9th sector. The bios was patched. Several of my Linux computers now have a Swap that I didn't create. All three of my laptops and the three desktops are all infected. I have a wired router only and my computers are not networked. The Sony runs Windows Vista Home Edition. It appears my computers now belong to a domain. There is a Group Policy on the Windows computers that I can't access. Using various tools that only work for a few minutes I found Active Directory. I disconnected all from the Internet but they are still connected via P2P. I'd like to know what changing the quality of my life and trashing over $15,000 worth of equipment has to do with terrorism. These people are are bigger criminals than Russian gangsters.
I found Deitybounce while searching for the unknown gpu rootkit. To all the people who told me in 2008 that I was crazy for believing that the government was tracking us via our computers and that there were firmware exploits, I accept your apology.
I've been working with computers since CP/M was the operating system but this is the first time that I've seen anything as bad as this. Now that we know more about these exploits, maybe someone will be able to develop a tool for removal.

April 24, 2014 11:20 AM

Anony on Is Google Too Big to Trust?:

You all take for granted that when you search on Google, the links that pop up are legit, legal, useful, free of malware, etc. Google puts forth a lot of effort to make that so. I've seen some of it firsthand. When you search for an item to buy, if you go off-Google for the search, you find folks selling it for less than they could possibly have bought it for. Digging deeper (checked with original manufacturer) you realize it's part of a credit-card theft ring. That sort of stuff is common as hell. Google goes through great efforts to keep the web clean. And you want to knock them for what they "could" do?

April 24, 2014 11:19 AM

qwertyuiop on Is Google Too Big to Trust?:

@Michiel - What, there exists no free Internet search?

Actually free Internet search does exist - duckduckgo.com. Doesn't track you, doesn't filter bubble.

(I have no association with duckduckgo.com other than as a very satisfied user.)

April 24, 2014 11:15 AM

&me on Is Google Too Big to Trust?:

@moof
So while they sell your eyes to advertisers,they don't sell your online persona.

How do you know? Or do they give it away for free instead? (to use NSA word games)

April 24, 2014 11:11 AM

Randalf on Is Google Too Big to Trust?:

Let me just clarify my last paragraph:
Besides that, Google never promised to not be evil. That's just some interpretation peddled by who-knows, the Google Fan Club I guess.

The story is that Google's "motto" is or was "Don't do evil".

The fact that a company motto refers to not-being-something should not be interpreted as that the said company promises to not to-be-something. Especially when "evil" is a very subjective term and as such is subject to, if nothing else, change.

For example to see how subjective opinions can change, look at the history of such opinions as:
1. what is pornography?
2. is homosexuality wrong?
3. what is a proper skirt length for women?
4. should women be allowed to vote or work outside the house?
etc

Or for a concept of "is killing a disabled person evil?" we can look at the history of euthanasia, e.g. in Germany during years 1902, 1932, and 1982.

April 24, 2014 11:10 AM

IDoNotCareAboutMyName on Is Google Too Big to Trust?:

@WhyAmINotSurprised:

"They are now as bad as the government. Most parts of Google don't know what the other parts are doing."

I do not agree. Google is worse than the government. They steal our privacy and expose it to the rest of the world. Information stored by NSA is only available to a small set of government staff. Information stored by Google is available to anyone.

Google does NOT allow us to take control of our digital footprint either, violating our privacy and rights in unaceptable ways.

"An analysis of their workforce might be in order. Their impact on the environment should be revealed for all to see. What else does the StreetView camera vehicle capture?"

SSIDs? BSSIDs? Passwords?

To me NSA activities are unaceptable, but Google ones are by far worse.

April 24, 2014 11:06 AM

TheProduct on Is Google Too Big to Trust?:

How much is one well-tracked identity worth to Google? In US$. Is that an amount some would be willing to pay, in trade for being untracked? In very rough numbers, ignoring profit, trust, the wide range of identities, implementation details, etc.

Does anyone have a good sense?

April 24, 2014 10:55 AM

Randalf on Is Google Too Big to Trust?:

Now Google should in reality not have a need for any 'personas'...on G-Mail they (supposedly) use the contents of the email to determine what ads to show. Considering that their efforts to evaluate a persons CURRENT preferences are not really all that exact (people do change, etc) and since they do index (again, supposedly) billions of web pages, what would stop them from using the contents of the currently viewed web page to show 'relevant' ads?

This just means that collecting USER information is unnecessary, wasteful, and unjustified, when it can be all done anonymously with the help of the page contents. Just like supposedly is done with G-Mail, completely "anonymous" (believe it, you sheeple)...

Unless of course they have received orders/requests/wishes from 'elsewhere' to collect the user information.

Besides that, Google never promised to not be evil. That's just some binterpretation peddled by who-knows, the Google Fan Club I guess.

April 24, 2014 10:46 AM

Grazing on Info on Russian Bulk Surveillance:

@Autolykos @DB

Don't waste your time arguing with him. There'll be hardly any [positive] outcome.
(IMO it is likely he's involved in something like GCHQ's 'Infiltrate, manipulate, deceive, destroy')

April 24, 2014 10:27 AM

Arkh on Is Google Too Big to Trust?:

@Michiel There are at least 3 services which users did not ask for and which can track them. Those used by website owners: analytics, adsense and the g+ share buttons.

Those you just get shoved through your browser's throat and you gain nothing from it. And it is a lot worse than a google service as it tracks almost all your web usage.

April 24, 2014 10:22 AM

Mr. Pragma on The Security of Various Programming Languages:

Nick P (April 24, 2014 9:24 AM)

"Back in the day, it made plenty of sense to make something like C at least."

While this is only a small remark, seemingly not deserving further attention, I see more there.

First, of course, a cross architecture meta-assembler made lots of sense and was - and still is in certain areas - very useful.

Also, funnily, I find myself using C again when doing jobs close to hardware. Obviously Modula is perfectly capable to address that area, too, as has been proven by Wirths OS. Actually, however, I think it's some kind of "mindset" issue. I *do* value Modula, Oberon, and Ada highly but I can't help but associate those with Program development - and C with "close to the iron stuff". It just feels more natural for me to do in C. Speaking in Wirth terms were he has the "System" module I go C directly.
And while it always felt strange to trace, say, some client interface application in the debugger, I almost feel "Hell, why isn't the compiler and editor right in the debugger environment?" when, say, coding some low level stuff on a microcontroller; it's just natural there to think and work in bits and registers.


"Don't forget D. That project puts in solid work to make a better, safer C++. They deserve some credit. Like you said, though, almost no take up."

True. But frankly, I feel that D doesn't get widely accepted and used for a reason. Looking closer I found the very core, the "C mindset" again in D. And in a way they even day it openly. "We want a better C++". Frankly, I'm afraid, no matter how much one works around that approach one might create an indeed better C++ but one will not achieve to create anything really comparable to the Pascal ... Ada ... Eiffel line. If one *could* one would end with sth. like Modula or Ada but with C like notation (e.g. braces instead of begin ... end).
Just read their discussions. Yes, for instance, D offers DbC but you'll find that a (by heart) C++ programmer (and that's what most of them are) has a quite different approach to DbC than and Ada programmer. To put it losely, while DbC was a much welcomed and dearly missed (by many) in Ada (2012) it's hardly more than a "cheap insurance" concept or, worse, a pimped up assert() for most D guys.

But granted, using D I felt way better than when dealing with C++ and all it's, uhum, cousins (Have a look at Cyclone! Nice intention, typical C/C++ look approach).

"Americans invented the first ..."

Oh well, there could be lots of debate there (Germans, for instance, might deservedly bring up Mr. Zuse) but that wasn't my point anyway.

Yes, I agree, from what I see, in the usa the marketing push is stronger than across the ocean. French or German developers can be pushed only so far to produce sth. lousy but shiny and (why are they almost always overlooked?) the Russian are very favourably influenced by a very strong academic system and tradition. Actually, I think Russia is among the stronger supporters and users of Modula and Oberon (and probably would use more Ada if it hadn't the ugly american dod smell...). I'd bet anytime that the quality of Russian code is considerably better than american code (on average).
The French have some kind of "silicon valley" with INRIA and Germans probably have a more engineering like approach to code.

To put it in a funny looking way: One very often hears "it's fun!" in software developer circles. Well, you won't lose money placing bets that the ones saying that tend to be americans ...
Generally speaking (and knowing perfectly well that there are exceptions) I tend to trust European software way more and I tend to consider american developers to be "hackers" (that's *their* term for themselves, not mine!). To summarize it bluntly I would assume that code from the usa has either been hacked for fun or hacked under marketing pressure. Apologies if anyone feels offended.

""My personal preference is Modula/Oberon (although compiler support is thin and for few architectures only) and Ada 2005 (yes, I *love* 2012)."

Same here. They seem to make all the right design decisions & are quite versatile."

Maybe you'll laugh at me but the only reason I'm not purely Ada but am rather almost fighting to use Oberon or Modula is elegance. I consider elegance and beauty to be trustworthy indicators of quality (which might also explain my love for Python for scripting) and I feel that Ada unfortunately feels like considerably less elegant and kind of nailed and hammered together. One reason for that might be Adas tendency to invent new names like "tagged" for well understood paradigms and structures. otoh, Ichbiah had a strike of genius when he invented the tick features.

"Funny thing is, I could teach an average C++ programmer how to safely use Modula-like language faster than I could teach them how to write secure C++. I did this more than once. Each time, I pointed it out to them & enjoyed the look on their faces. One also commented that the safer language resembled the pseudocode he wrote and translated into C++. He said using the safer language eliminated most of that mental translation step. All of them also appreciated the near instant compile time as they could develop-compile-run without loosing mental flow. Ah, the joys of a very well-designed language. :)"

Yes, sir. That was well put.

I strongly suggest Mr. Dewar's "lecture" (actually it's more a casual style talk albeit with lots of depth and content) at MIT (http://www.youtube.com/watch?v=0yXwnk8Cr0c) to anyone seriously interested in solid software development.

April 24, 2014 10:18 AM

Jacob on Is Google Too Big to Trust?:

Since Google unified its Privacy Policy about a year ago or so, declaring that it is now treating user info across *all* its services in a holistic view, the writing has been on the wall.

I wonder how many people are aware of Google services that do not get much in-your-face info sharing attention but are still prevalent:

- Google Wallet
- Google analytics (seems that every person and his dog with a web site is using it)
- Re-Captcha
- Google free DNS servers
- 1e100.net (no use to end users, but still collecting in the background huge amount of info)
- Postini

The last one is really something:
About 3 years ago, being on a foreign land, I transferred a confidential file that I had prepared to a large non-US defence-oriented establishment. I sent it from a clean computer that I fully control, but I could not email the file nor encrypt it due to some admin issues on the receiving end.
I prepared a link to the file on my local server, emailed the guy the link, and started to monitor server logs to see when he finished downloading it so I can erase the file from my machine.
2 minutes after I emailed out the link, I saw 2 file pulls using that special link I had prepared, coming from the US. I told the guy he must have a virus on his machine. He called up the departmental IT guys - they could not find anything wrong.

It took me a while to discover that that establishment contracted Postini, owned by Google, to filter incoming spam and malware. Postini sucked up any file link arriving at that establishment, moved it to US servers for malware analysis and if OK approved the email to continue its route to destination. Nobody at the dept. was aware of that arrangement.

Two years later, I had the same episode happening with company-confidential design files going to a big US firm's foreign subsidiary.

"We may combine personal information from one service with information, including personal information, from other Google services"

April 24, 2014 10:09 AM

Damen Choy on Is Google Too Big to Trust?:

Google generally seems to label its paid placement ads and keeps them distinct from editorial content..

I do not see any strong evidence that Google is mixing its natural search results with the paid ones..

April 24, 2014 9:51 AM

Skeptical on Info on Russian Bulk Surveillance:

@Autolykos: National Security Letters? "Free Speech Zones"? OWS activists getting harassed in any legal (and probably a few illegal) ways for organizing or participating in protests? Police brutality against peaceful demonstrations (see: "Pepper Spraying Cop")?

Police brutality is just as illegal today as it was 10 years ago. We're better able to capture it on video when it occurs, which is a good thing.

NSLs are the equivalent of grand jury subpoenas, and have no more impact than the latter on freedom of speech, press, and assembly. They only way they've been found to impact free speech is via their confidentiality clause, which requires the recipient to keep silent about receiving a NSL. This does not prevent a recipient from challenging a NSL in court, and the confidentiality clause is not unlimited.

No doubt some OWS activists were harassed by some local police. The "pepper spraying cop" in California is certainly an example. It's just as wrong today when police step over the line as it was 10 years ago. And just like 10 years ago, in confrontations some percentage of police do so. I'm glad we have more video footage today to better hold police who do so accountable, and to better protect police from false accusations when they're levied as well.

Overall though OWS activists were protected, and their right of assembly and speech was not violated. They were eventually evicted from the public spaces they had occupied, but the right to protest doesn't confer a right to indefinitely occupy public parks and prevent others from using them. There are now, as there were 10 years and long before that, time, place, and manner restrictions on how one can protest which are legitimate and constitutional.

I must admit that I didn't read the Surpreme Court decision - but it doesn't matter that much what they wrote. Courts can not strike down laws for political reasons, only for formal reasons. So they have to find one.

At that level of constitutional law, the Supreme Court is choosing among different principled interpretations of concepts like equal protection, and so their decisions are not formally determined in advance. However, the Court is nonetheless choosing a principle, and in this case they've expanded the scope of equal protection of the law.

And if you don't read the decisions, then you don't understand what they chose, or how that choice will impact the law, or how that choice makes the "authoritarian direction" thesis less tenable.

April 24, 2014 9:47 AM

Michiel on Is Google Too Big to Trust?:

Google provides billions of users with "free" services like Search, Maps, Youtube, Gmail, Hangouts, etc. The crowd here may disagree but billions of people are obviously finding these pretty good services. So Google uses the data gathered from a user's usage of these services to show targeted ads, which they would like them to click. They're trying things to make us click those ads, why are we acting all surprised about that?
So now we're asking Google to only place the ads in the areas where we as users have been trained not to look? Honestly...

Don't like it? Use paid services. What, there exists no free Internet search? If we are all so upset about this and ready to put our money where our mouth is, why isn't there a paid alternative?

April 24, 2014 9:38 AM

Skeptical on Info on Russian Bulk Surveillance:

@DB: You have our government putting entire societies under surveillance, automatically fishing for crimes among the innocent.

Is this referring to Iraq? Something else?

You have them breaking and subverting our technology in this fishing expedition too.

Which technology, DB? How does this fit with your authoritarian direction thesis?

You have them setting up "border regions" that cover 2/3rds of the US population, where they can stop and search anyone for no reason at all.

No, that's not the way it works. Look up "extended border doctrine" when you have a chance. Don't take ACLU hyperventilations at face value (or anything else, for that matter).

You have them kidnapping and putting people in prison for decades without a trial or even a charge brought against them.

You're referring to the detainees captured, for the most part, in Afghanistan during a war? Most of whom have been released, and all of whom are being given due process? The detainees, many of whom had legal representation from the nation's best law firms, who have had many cases in federal court, including the Supreme Court?

Sounds much less dramatic than "kidnapping and putting people in prison for decades without a trial," which gives the impression that the US is disappearing anyone it chooses in the manner of a South American military government.

You have them killing people by remote control in all sorts of countries that we haven't even "declared war" against.

You mean persons designated as important members of al Qaeda affiliated organizations or persons actively aiding hostile operations against US forces? What does this have to do with your claim that the US is heading in an authoritarian direction?

You have important people committing felonies in front of the US Congress and nothing happens to them.

Total shocking. No one has EVER spoken a falsehood to Congress before and NOT been prosecuted for perjury. Definitely a sign of incipient authoritarianism. This type of thing never happens in free countries.

But no... according to you, NONE of this is an erosion of human rights or the Constitution or rule of law AT ALL..

You're having trouble with complexity. You have weigh things like an increase in surveillance powers granted after 9/11 against an increase in civil liberties in other areas. You have to look to see how those surveillance powers are regulated, and whether they have affected the independence of other institutions, such as the courts. You must additionally look to see if those surveillance powers are actually used to suppress civil liberties.

When you look at all those things, you find that the US has expanded equal protection of law in recent years, and has made, on balance, life in the US more fair, and essential rights more protected. You can stamp your feet all you want about air strikes in war zones and telephone metadata programs, but the latter in its current form has been tightly regulated and not abused, and the former is simply irrelevant to the discussion.

April 24, 2014 9:26 AM

Meldour du Esseaux on Is Google Too Big to Trust?:

> Putting unmarked sponsored ads in the "regular" search results section is misleading, because people have been trained by Google to see that section of the search results as neutral.

'That is not a bug, that's a feature.'

some guy:
> “I ACTUALLY think most people don’t want Google to answer their questions, they want Google to tell them what they should be doing next.

Wishful thinking?

April 24, 2014 9:24 AM

Nick P on The Security of Various Programming Languages:

@ Anura

"That said, .NET websites do have a tendency to be misconfigured to show the exception with the stack trace... combined with a debug build being deployed and I've seen cases where invalid input prints out the code that builds the SQL; very useful to an attacker."

I've seen that! It was on a major web site whose name I can't recall at the moment. I used a form of some type, then saw what looked like a debug dump. I was thinking "should the *user* be seeing all this crap? Or should it have been emailed to admin or developers?" Two options, one good & one bad for security, which will .NET choose? Result: "Doh!" (Homer Simpson)

@ Autolykos

" That argument, however, only translates to C++ if the guy writing the code still uses C++ as he would use C."

It's an interesting claim. Most empirical studies I've seen of C++ support my comparison to C in vulnerability. However, the way C++ was being used *was* like an enhanced C. I'd actually like to see a vulnerability analysis of your safer style of C++ to see what it's actual risk is.

@ Mr Pragma

"C (and consequently C++ by intention or not) was created as a system language; in fact, it was created for the purpose to create an OS (Unix) for a new architecture.
While some like to bash C/C++ for its very raison d'etre I do agree with K&R (and Stroustrup). Seen from the perspective of then, at that time, C was an elegant construct and a major progress."

I actually agree with you about that. I only criticize C/C++ for current use. Back in the day, it made plenty of sense to make something like C at least.

" I take it as a strong hint that during decades that camp came up with only 1 "major" attempt at safety, Cyclone, and that Cyclone is a pretty much ignored and little taken care of creation."

Don't forget D. That project puts in solid work to make a better, safer C++. They deserve some credit. Like you said, though, almost no take up.

"The mere fact of java being in Oracles hands (and the way they handled it) tells me loud enough to avoid java fervently."

Absolutely. What they tried to do with Android speaks of their character plenty: they have none.

"On a sidenote: I sometimes wonder whether that whole language thing also tels a lot about usa and europe. "

Americans invented the first safe machine (B5000), the first implemented HLL (Short Code), the compiler (Grace Hopper), BNF form (Backus), analysis of fundamental algorithms (Knuth), formal code reviews (Fagan), first implemented theorem prover (Logic Theorist), functional programming (Lambda Calculus), the field of computer security (Anderson Report), formal vulnerability assessment (MULTICS evaluation), covert channel analysis (Kemmerer), and formal security assurance process (Orange Book). Americans also coinvented ALGOL, which set the stage for languages you named. If anything, I'd say certain Americans laid the foundation for safe/secure computing much like certain Europeans (esp British) laid the foundation for computing.

So what of today? I'm the authorative source on all things security research having reviewed literally thousands of papers spanning decades. Early on, most of it was predominantly in America with us being most concerned & with lots of funding to solve the problems. Today, most of the research in security & better programming is spread across US and Europe, with some in Asia & Australia.

I can't see a definitive pattern. There's good work going on in both continents across the broad range of topics. My current European favorite is Xavier Leroy's Gallium team in France because their group combines theory and practice pretty well. They also produced useful stuff for rest of us: Coq, Ocaml, CompCert C compiler, and MiniML compiler on the way. Not sure of an American favorite although there's quite a few good ones. I'm not so biased in that I think international efforts are best for this field, esp when one considers the risk called subversion.

As for culture, there *does* seem to be a difference in culture. I wonder if it's the capitalist/individualist vs socialist mindset. I noticed that tools such as Modula had a decent amount of takeup in Europe, whereas in US it was mostly C/C++. I know over here the profit and time to market pressure make a quality development process a liability. Well, at least appear to be to management. There's also a ton of legacy code in C/C++ and people who can maintain it. So, these incentives seem to combine to prevent safer languages and platforms from taking off, while reinforcing unsafe practices. I'm not sure what it's like in various European software shops. I'm guessing you're European so maybe you could give me a perspective on that in whatever countries you've worked.

"My personal preference is Modula/Oberon (although compiler support is thin and for few architectures only) and Ada 2005 (yes, I *love* 2012)."

Same here. They seem to make all the right design decisions & are quite versatile. Both sets of languages have been used on hardware ranging from desktops to microcontrollers. Ada was also used in a mainframe-type system (BiiN) and several highly secure systems (ASOS, SAT). There's also empirical evidence backing Ada reducing vulnerabilities & being more productive than C. The support for C is a practical decision that made sense.

"As far as scripting is concerned I like Python (extremely well thought out, very productive, brilliant minds and deep zen behind it and lots of batteries included). "

We think alike twice. Check out Stackless Python and Cython, btw. The Python camp just keeps on getting better.

"So I thought you might be interested in some of my thoughts."

Very interesting post. :)

@ L

" doesn't make much sense, since memory management, length and a lot of other stuff are safe in c++. sure, other languages might be better. All i'm saying is that C and C++ are not the same."

They're surely not the same as I'd take C++ over C wherever possible. Yet, it's hard for me to believe C++ is as safe as you say when professional C++ developers and researchers are working their butts off to make it safe. The existence of MISRA C++, Ironclad C++, research into making it safe, and tons of vulnerability analysis tools make it hard for me to mentally connect "safe" and C++. Although, the newest standard might improve that situation. I havent' reviewed it as we already have safe, fast, readable languages with good IDE's so why bother.

Funny thing is, I could teach an average C++ programmer how to safely use Modula-like language faster than I could teach them how to write secure C++. I did this more than once. Each time, I pointed it out to them & enjoyed the look on their faces. One also commented that the safer language resembled the pseudocode he wrote and translated into C++. He said using the safer language eliminated most of that mental translation step. All of them also appreciated the near instant compile time as they could develop-compile-run without loosing mental flow. Ah, the joys of a very well-designed language. :)

April 24, 2014 9:22 AM

13 of Me on Voice Prints:

There is nothing more useless than a lock with a voice print --Tom Baker

April 24, 2014 9:05 AM

parser on Overreacting to Risk:

The pee would have been good for Portland's fighting spirit (ha!). Even UFC fighter Lyoto Machida stated that he drinks his own urine! More on the benefits of "urine therapy" for those for a taste of the wild side.

Disgusting behaviour, but an over-reaction for sure. Problem is, once the video made its way public, there's enough folks that would have demanded "something" be done that a drainage may have been forced by the public anyways. Nowadays there's so much pressure on public officials to "do something" in response to a risk that over-reaction is often scripted into the default response.

Think about those great camping trips where you can drink pure water straight from the lake. All around you there's animal & bird pee etc., dead and decaying creatures in the water, and still in a big volume lake, the water can be purer/cleaner than anything the city can filter.

April 24, 2014 9:05 AM

AOL II on Is Google Too Big to Trust?:

No not Reston, Dulles, VA, that made-up half-acre of Langley, www.mapquest.com/maps?city=Dulles&state=VA&address=22000+Aol+Way ,

April 24, 2014 8:53 AM

CallMeLateForSupper on Conversnitch:

I am neither amused nor favorably impressed. Art, indeed. These dudes could have accomplished their aledged goal of awareness raising (on perhaps a smaller scale) by planting inert devices clearly labeled "This innocuous thing is an evesdropping device".

I think it's sad that the venerable Raspberry Pi was, in a sense, sullied by this brain fart.

April 24, 2014 8:53 AM

Stephen285 on Is Google Too Big to Trust?:

What is "good", what is "evil"? Google is an advertising company, governed in top-down fashion by one single man with all power - no internal debate, no balance of power. History of Man for hundreds of years (millennia?) has shown that, when power is absolute, good and evil become very, very relative concepts. And trust becomes irrelevant, as is this discussion whether you can trust Larry Page. Googlers are much busier dealing with their quarterly personal objectives and saving their jobs, rather than dreaming about good and evil. Human nature doesn't change, and Google is a very ordinary company in many respects. Small people, protect thyselves.

April 24, 2014 8:52 AM

Peter Boughton on The Security of Various Programming Languages:

Joe wrote:

>Coldfusion is probably the most insecure web platform of all, hacking-wise.

I'm not an Adobe fan, but I'm pretty sure EVERY CF attack that has been reported in the past 24 months was due to an UNPATCHED server - that is, Adobe had already released the fix, but the server admins hadn't bothered to apply it.

(Which isn't to say some of the issues weren't ones that never should have existed in the first place, but it's unfair to entirely blame CF/Adobe.)


>not to mention all the SQL injection issues

PEBKAC

The CFML language provides the tools necessary to prevent SQL injection.

The issue is primarily bad programmers, bad programming practices, and perhaps a touch of Adobe's reluctance/inability to properly educate developers.

April 24, 2014 8:34 AM

AOL II on Is Google Too Big to Trust?:

Competent investors will tell you there's no barrier to entry in google's core business. Handling big sparse matrices is cheap and getting cheaper all the time. Already there are plenty of alternatives that respect your legal privacy rights. The problem of google is not its bigness but its favored government position as a technology of surveillance and repression. It's the new and improved AOL (our secret police had the sense not to base it in Reston this time), and it will meet AOL's fate when global markets get fed up with its spying.

April 24, 2014 8:20 AM

yesme on Dan Geer on Heartbleed and Software Monocultures:

@Garrett

"Now that we have experience with SSL/TLS implementations, has there been any consideration of doing audits at the spec level? Going and officially deprecating a number of the options which are least likely to be used, least beneficial, and which add substantial complexity? If we attack part of this at the specification level, we would drastically reduce the amount of worry and work at the implementation level."

To be honest, I don't have high hopes that we can expect serious changes in the IETF. There are too many islands and they all are improving their own OSI model thing. What's lacking is the big picture. We have __way__ too many protocols doing roughly the same. That needs to change. For example, there is NFS, WebDAV, FTP, CIFS/SMB, SFTP, FTPS and simply put, they all provide remote access of files (HTTP too). So the level of NIH is high. The same with H.264/265 and Googles VP8/9. There are just too many forces playing there.

That's why I don't expect real and thorough changes at the IETF. It shouldn't be a committee, it should have good and powerful architects. And it also shouldn't play the devastating patent games.

In short, they should change their agendas and the end user should be paramount.

But I don't expect that to happen any time soon.

April 24, 2014 8:18 AM

Nick P on Metaphors of Surveillance:

@ Figureitout

"Pretty interesting life. Seemed obsessed w/ finding a new form of energy dealing w/ sex (and seemed to enjoy it a bit much lol)."

Well put. Pseudoscience or not, it's hard to say a lifetime of sex & attempting to turn it into world-changing power was a life wasted. Made for a good story to me, albeit with a bad ending.

April 24, 2014 8:03 AM

kronos on Is Google Too Big to Trust?:

@bickerdyke: ...that vulcan-like neutrality

Oh, I am so stealing that phrase!

April 24, 2014 8:03 AM

some guy on Is Google Too Big to Trust?:

Beyond the sheer breadth of data they collect on everyone and everything, is the crazy shit Eric Schmidt says like, which led me to leave all of their services:

“If you have something that you don’t want anyone to know maybe you shouldn’t be doing it in the first place”

“Every young person one day will be entitled automatically to change his or her name on reaching adulthood in order to disown youthful hijinks stored on their friends’ social media sites.”

“It was a joke, it just wasn’t very good” regarding his comment above...

“Just remember when you post something, the computers remember forever”

“You can trust us with your data”

“We know where you are. We know where you’ve been. We can more or less know what you’re thinking about.”

“I ACTUALLY think most people don’t want Google to answer their questions, they want Google to tell them what they should be doing next.

April 24, 2014 7:59 AM

kronos on Conversnitch:

@Anura, I had a similar idea after watching the second Terminator movie. My idea for the next in the franchise was small liquid metal robots that would easily squeeze under doors and maybe through keyholes. That way almost anywhere you go you would be vulnerable. Later I read "Micro" by Michael Crighton and of course his treatment of tiny weapons was far more advanced than what I came up with.

But the female terminator in the third movie was far more attractive than my idea. ;)

April 24, 2014 7:59 AM

bickerdyke on Is Google Too Big to Trust?:

people have been trained by Google to see that section of the search results as neutral.

The noteable thing is, that it never was neutral to begin with.

Googles long gone anchestors like Altavista used to serve neutral results, based on neutral metrics like how often the search expression turned up on a page.

Googles key to success was to remove that vulcan-like neutrality and fudge the result based on factors not related to the actual search. (PageRank being the first and page loading speed is one of the newest ones)

April 24, 2014 7:51 AM

moof on Is Google Too Big to Trust?:

@nonono

Larry Page holding a large majority of the voting rights in terms of stock shares for Google is what would prevent them fun caving in to shareholder demands for a quick profit.

That said, Google won't always be led by Larry Page. And Larry might change his world view in the future while he's still leading Google. That they have so much info is cause for concern in that they can't realistically promise that they will never, ever do evil.

April 24, 2014 7:50 AM

simpson on Is Google Too Big to Trust?:

Yahoo is the absolute worst with quality lower than the National Enquirer. Their "NEWS" articles are useless garbage just to host ad pages. Their search is horrible. And it's all designed to trick and fool.

April 24, 2014 7:42 AM

Nonono on Is Google Too Big to Trust?:

The very fact of them collecting and storing personal data is evil, especially since they conceal the price that users pay for "voluntarily" surrendering their personal information.

@moof: What you write is like saying the burglar did not do evil because at least he did not kill the victim.

Also, Google HAS the data. They don't sell personality profiles NOW, but what if at some point in the future, sales momentum slows down and shareholders demand more profits. There is exactly nothing that will stop Google from doing it then.

April 24, 2014 7:34 AM

L on The Security of Various Programming Languages:

Calm down, I never said that you can't write bad things in C++, and I never put it against ada, erlang or any other language.
I simply said that IMHO C and C++ are structurally different languages. Even more if you consider pre-C99 and post-C++11.

Your argument is: today a lot of software is written in pre-C99, therefore C++ sucks. doesn't make much sense, since memory management, length and a lot of other stuff are safe in c++. sure, other languages might be better. All i'm saying is that C and C++ are not the same.

Sure you can write C and C++ code with the same assembly, but I still think a correct c++ is way safer than a correct c. Of course having bad programmers will mean non-maintainable code and bugs in any language. New tools *do* help. But people need to use them. otherwise it's like writing perfectly safe code with a (known) buggy compiler...

Still, for any (opensouce) big project today C/C++ is the only choice, since that's what people know the most.

Purely functional languages are great and extremely safe, but you reach a fraction of developers. You must also take that into account: opensource works because lots of people can edit the code. Write in ada if you want. It will be great code. But with one or two contributors. Your project will take longer to develop, fix, will be harder to find contributors and maintainers.

It's all about tradeoffs, IMHO c++ with a good maintainer is a good tradeoff. That's all I'm saying. I never compared C++ to anything else than C, btw.

April 24, 2014 7:31 AM

Garrett on Dan Geer on Heartbleed and Software Monocultures:

@ yesme

Now that we have experience with SSL/TLS implementations, has there been any consideration of doing audits at the spec level? Going and officially deprecating a number of the options which are least likely to be used, least beneficial, and which add substantial complexity? If we attack part of this at the specification level, we would drastically reduce the amount of worry and work at the implementation level.

April 24, 2014 7:28 AM

Locum Fardle on Is Google Too Big to Trust?:

@moof
But isn't google investing heavily in robotics and drones? I'd hate to draw a negative conclusion from that but ...

April 24, 2014 7:18 AM

moof on Is Google Too Big to Trust?:

For clarification about them trying to do good, I don't mean that they always succeed or that they never do evil, but their evil actions have been paltry compared to what the information they hold would allow them to do.

Remember, Google doesn't sell your info to third parties. They sell the promise of putting an advertisement in front of a person that they think would click on it.

So while they sell your eyes to advertisers,they don't sell your online persona.

April 24, 2014 7:13 AM

moof on Is Google Too Big to Trust?:

Google is the main force behind making the Internet a more accommodating place for those that grew up in the Internet. While I'm also concerned about Google's size and of the possibly they might go full blown evil in the future (they obviously try to do good currently), they're the only hope of stopping Hollywood from destroying the Internet.

April 24, 2014 7:11 AM

Locum Fardle on Is Google Too Big to Trust?:

Does the data returned by search engines that piggyback on google also include these "hidden" sponsored links?

April 24, 2014 7:07 AM

WhyAmINotSurprised on Is Google Too Big to Trust?:

In a nutshell, YES!

They are now as bad as the government. Most parts of Google don't know what the other parts are doing. An analysis of their workforce might be in order. Their impact on the environment should be revealed for all to see. What else does the StreetView camera vehicle capture? And Google Earth brings it all together, making them an object of suspicion (or takeover) by the U.N. Is Google inspiration for the NSA (or vice versa?) What next...now that they are into broadband supply, are we going to get (invasive) Google routers (note that they tried earlier with Google Desktop)?

They are just big enough to fail.

April 24, 2014 6:01 AM

Paul Edwards on New Book on Data and Power:

I also like the feudal analogy that you bring. How about:

"The Feudal Internet: Data, Power, and the new Lords of the Manor"

(My original thought was: "The Feudal Internet: Data, Power, Serfs, and the new Lords of the Manor", but on re-reading the first paragraph of your article thought the Serfs took away from the many roles you identified there).

or

"The Feudal Internet: Power, Serfs, and the Lords of the Data"

(perhaps implying a causality there that you may not want implied)

Good luck with the manuscript, and I'm looking forward to putting up my hand to help review when the call comes out.

April 24, 2014 5:44 AM

Mr. Pragma on The Security of Various Programming Languages:

Oh, and btw:

Would you kindly stop to insult us with the C11 and similar arguments?

Fact is that gazillions of lines of - often security relevant code (-> openssl) - are written in not even C99 but, in fact, old K&R (plus some funny compiler dialects (-> pragmas)).

Similarly the argument of tools, discipline and whatnot are missing the point. C had decades to become more safe, in design as well as in practical use. Unfortunately, for some weird out of this world reason (because, listening to the C/C++ faction, each one of them seems to produce close to perfect, unit tested, statically analyzed and whatnot code) the sad fact is that very much - if not the vast majority - of C and C++ code is full of crap.

So, sorry, using C/C++ [current standard plus bla] is *not* the answer.

(Oh, and yes, offer me your other approach, too, namely kindly dare to tell me that I simply don't know what I'm talking about. As a matter of fact I did teach C and C++. I didn't throw away tens of years of language proficiency and more than 10.000 $ worth of tools for the fun of it but because I *had* to.)

April 24, 2014 5:30 AM

Mr. Pragma on The Security of Various Programming Languages:

That "report" starts by mentioning which languages are the most used.
Which basically comes down to saying that these languages don't have security or safety in their mind in the first place (and yes, as if to shout out "we do not really know what we're talking about" that company mixes up languages and frameworks on top of it).

But let's look at it because actually the raison d'etre of a language *does* provide valuable hints at, among others, safety and security.

Nota bene: I'll put C and C++ into one box and so I will do with Pascal and Modula, too. In both cases the languages are quite closely related and in fact the latter was inspired (or even guided) theoretically as well as practically by the former.

C (and consequently C++ by intention or not) was created as a system language; in fact, it was created for the purpose to create an OS (Unix) for a new architecture.
While some like to bash C/C++ for its very raison d'etre I do agree with K&R (and Stroustrup). Seen from the perspective of then, at that time, C was an elegant construct and a major progress. But there's a but: That does include that C was meant to be an elegant super- and meta-assembler.
I think that C still is a language of choice for low level routines close to hardware. Sure enough, though, C has not been designed for nor is it adequate for general programming, particularly when considering safety and security (which wasn't a big issue for K&R. At that time pretty everything was filled with trust and differentiating between different users and root was almost more than was considered needed).

Funnily Pascal which was developed at roughly the same time and for quite similar purposes, albeit more implicitly, took a very different approach. Where "power" was paramount - and natural - for K&R, "safety" (in todays lingo) was paramount for Wirth. While some say that Wirths main reason was simplicity (with safety just a consequence), based on what his later work tells about Wirth, safety *was* important to Wirth, too; maybe not expressly but sure enough, safety (well, what we call safety today) *was* important to Wirth. And Wirth *did* know that his approach carried a hefty price tag concerning Pascals usability for low level systems programming ... and he went on to create Modula which was way better suited without giving up Pascals advantages.

And like that it still is today. Pascal, Modula, Oberon ... up to Ada and, to a degree, the strange cousin Eiffel do value safety highly but implemented different approaches to low-level close the the iron programming.
And C/C++ and their many offspring still don't care too much about safety. I take it as a strong hint that during decades that camp came up with only 1 "major" attempt at safety, Cyclone, and that Cyclone is a pretty much ignored and little taken care of creation.

*If* this world were full of professional and professionally trained developers, C/C++ might be good solutions. Millions of bugs and eruptions like heartbleed, or openssl in general, however, very strongly suggest that this world has to do with a very considerable part of less capable developers.
And btw: openssl is what the C/C++ developers that we happen to have around create when they expressly work on security sensitive stuff ...

Java was created to run on anything that holds still long enough to inject a vm. If java had security and safety in mind (frankly, I doubt it, no matter what they tell me) then they relied mainly on bureaucracy to achieve it (Yes, I'm somewhat biased but then, who could seriously demand - and based on what? - to consider java anything but a funny experiment gone awry?) The mere fact of java being in Oracles hands (and the way they handled it) tells me loud enough to avoid java fervently.

On a sidenote: I sometimes wonder whether that whole language thing also tels a lot about usa and europe. In Europe the Wirth languages were created, OCaml, Erlang, and Ada (yes, right, Ada. It was ordered by the us dod but designed by a frenchman) while the usa has C and a bunch of commercial thingies like java, [whatever]script, etc. And no, I do not mean to imply any judgement; it merely strikes me as different cultures (or culture at all *g) like in France, Germany, Suisse, or in Russia vs. in usa, canada using rather different approaches following rather different criteria and wightings. I personally rest very strongly in the European camp although I profoundly respect K&R and praise Tucker Taft et al. for what they have done with and for Ada (and for respecting some basic "holy credos" of J. Ichbiah in the first place).

My personal preference is Modula/Oberon (although compiler support is thin and for few architectures only) and Ada 2005 (yes, I *love* 2012). I have to (and want) to "confess", though that I really like Adas very hands down practical approach and support for C.

Is language a decisive criteria for safety and security in the world we live in (as opposed to a heaven with professional C developers): You bet!
When developing in Ada or Oberon a bug is a strange creature and a security flaw is bad design and rare. When developing in C I spent eternities with a debugger. Not because I'm a lousy coder but because safety and reliability meant a lot even when developing in C (and unit tests were not yet standard procedure).

I am, btw, not a yota less productive or fast in Ada or Modula or Oberon than in C or C++, quite the contrary. As far as scripting is concerned I like Python (extremely well thought out, very productive, brilliant minds and deep zen behind it and lots of batteries included). I wouldn't think in terms of security of Python or, more generally, scripting, but one can create quite reliable utilities. And it needn't be expressly secure (for that there is Ada or Modula etc.) but it mustn't be a trouble ticket generator like Perl neither ...

I hope I didn't bore you but I'm concerned with those questions since more than a decade and I was and am under pressure to be productive yet deliver reliable and secure products. So I thought you might be interested in some of my thoughts.

April 24, 2014 5:23 AM

Autolykos on The Security of Various Programming Languages:

I agree that C makes it unnecessarily hard to write safe code. That argument, however, only translates to C++ if the guy writing the code still uses C++ as he would use C. But there's no sane reason to. Classes in C++ increase safety a lot (especially if you are consequent about getters/setters and RAII) and hardly cost any performance at all (unless you go heavy on the virtual or write poor C'tors, D'tors and assignment operators). Most stuff in the STL is safe and convenient to use, while still being at least as fast as you could expect it to be if you write it yourself (unless you're a true ASM whiz). If you ever have a raw pointer/array in any but the innermost and best encapsulated C++ code, you're doing it wrong.

So the main argument against C++ is that it doesn't *prevent* you from writing bad code if you really want to. But I don't think a language should - compilers that think they are smarter than the programmer are a serious pain in the lower backside and will inevitably result in programmers trying to outwit the compiler once they feel the need to use the "unsafe" parts (you can see that a lot with PASCAL and Java).

April 24, 2014 4:51 AM

Autolykos on Info on Russian Bulk Surveillance:

@Skeptical: I don't see any decline in freedom of speech or assembly or press. Those are as strong as ever.
National Security Letters? "Free Speech Zones"? OWS activists getting harassed in any legal (and probably a few illegal) ways for organizing or participating in protests? Police brutality against peaceful demonstrations (see: "Pepper Spraying Cop")?
That's just to name a few examples off the top of my head - this list is nowhere near comprehensive. And what we see is just the tip of the iceberg. You'll never know how much the government exactly leans on news programs and papers - you can only see them getting less and less bold compared to foreign press.

I must admit that I didn't read the Surpreme Court decision - but it doesn't matter that much what they wrote. Courts can not strike down laws for political reasons, only for formal reasons. So they have to find one. And constitutions are usually elastic enough that most (well-written) laws can easily be argued to violate it or agree with it, depending on the current political climate.

April 24, 2014 3:48 AM

herman on Conversnitch:

The problem is still planting the bug at the scene of the crime. It is better to bounce a laser pointer off a window pane or a picture/painting or even the leaves of a plant next to the targets and demodulate the audio from the reflection. This way, the bug can be in a more secure position across the street.

April 24, 2014 3:11 AM

Anura on The Security of Various Programming Languages:

@Nick P

I agree mostly. Although, naturally I'm also inclined to blame languages that make mistakes easier. We all had this discussion re system programming recently. Many of same points apply to secure web programming.

Naturally the same things apply, however in this case I think the frameworks and tools available are fairly even across the languages; .NET has pretty good tools available and there are good frameworks for Java and PHP as well. This is why I say that most of the differences you see between these languages in this particular test is going to be more about the developers than the languages themselves.

That said, .NET websites do have a tendency to be misconfigured to show the exception with the stack trace... combined with a debug build being deployed and I've seen cases where invalid input prints out the code that builds the SQL; very useful to an attacker.

April 24, 2014 1:25 AM

Figureitout on Friday Squid Blogging: Squid Jigging:

DB
I refuse to just "give up" and "give in"
--Prepare yourself now for physical break-ins. Then you will see what I've been dealing w/ for years now; I can have a secure computer but not w/ the break ins. Before the break-ins happen you need a really good way to store data many places. After they happen, they are looking at your methods and they're broken the second you implement them.

Seriously those kinds of statements attract the brainwashed gov't drones (they kill any leaders trying to start any kind of movement to implement real change); and I'm saying yet again, some of these groups behave exactly like a mafia. I believe they have stolen many funds from US taxpayers and they'll kill anyone exposing their racket. All it takes is a single break in and sprinkling some chemicals in your house or taking a cup of liquid around faucets you drink from (that's when I noticed the lumps in my body, immediately after a known break-in).

April 24, 2014 1:11 AM

Figureitout on Metaphors of Surveillance:

Nick P
--Pretty interesting life. Seemed obsessed w/ finding a new form of energy dealing w/ sex (and seemed to enjoy it a bit much lol). My experiments there were "physical" "when I get the chance to run tests" and I'm done after my hilarious theory. Too silly and OT to get into, but I could predict timing for orgasms and some other well documented "trigger points". He was just delving deep into psychology, I always thought it was odd the shape of the hypothalamus from a cross section of the brain, it looked oddly familiar to a female anatomy part...Interesting for a while but then it's a lot of patterns.

My "slight" obsession is w/ waves and rotations. Entire galaxies rotate, obviously our planet and solar system. What if the universe rotates, where does it end?! Feels like we're always spinning... If the universe is actually expanding, then from the right perspective, all movements are 2D waves. Even standing still, your mass is rotating on the earth, around the sun, around the galaxy; w/ some weird wave.

And an even worse obsession has taken hold of my mind...digital security. And w/ a police state gov't attacking its own citizens and their own economy by breaking into homes and backdooring all products and protocols; looks like at least I will be challenged for life.

April 24, 2014 12:32 AM

DB on Friday Squid Blogging: Squid Jigging:

@ Wesley Parish

At this point, I refuse to just "give up" and "give in"... that's like welcoming our authoritarian overlords to power because we're too lazy to fix things. Of course if a moderator tells me to pipe down I will, this is their site after all :)

@ Skeptical

Any company could be compelled by our government to subvert their own products via some sort of legal means. Some means are more directly "legal" like CALEA, NSL, etc, others are more indirect like blackmail (catch someone in an unrelated crime, then make him violate human rights of all his customers to avoid prison, for example). The word "could" subdues the superlatives since obviously not all companies have been subverted. But any could be, therefore it's not safe to truly fully 100% trust any, since we can't necessarily tell which have and which haven't. Of course there can still be degrees of trust, since some are actually more likely to have been subverted than others (and certainly the degrees of likelyhood could be argued), but the likelihood is still not a perfect zero amount for all of them. You can argue more details beyond this all day and pick apart words, and claim a special meaning for "legal" before "compel" that supposedly means a different thing than "legal" after the word "compel", but it doesn't change the facts. You can also outright disagree with me too, since truth doesn't depend on people knowing it, agreeing to it, nor admitting it.

April 23, 2014 11:24 PM

Nick P on Metaphors of Surveillance:

@ Figureitout

Look up Wilhelm Reich. His ideas pissed of a lot of people. End result was FDA ordered his books to be burned. I remember feeling uneasy reading one commentary saying something like "it wasn't the first time Reich had seen a book burning." It was a reference to Reich's time in Germany. So, his books got burned and equipment destroyed destroyed because he said things that weren't acceptable to the government. The US government. Oh life's ironies.

April 23, 2014 10:01 PM

Nick P on Dan Geer on Heartbleed and Software Monocultures:

@ yesme

"You are forgetting that the SSL/TLS protocol, with all the options and revisions, is hard to implement and will probably take up to 100.000 lines of C code. In reference, a microkernel, the most basic part of it, is usually less than 10.000 lines of code."

I can't imagine what the size of it matters if it's implemented via a language or architecture largely immune to code injection that also allows easier code review. If anything, my recommendation makes things easier as the code gets bigger.

That said, the way to implement that on a mainstream architecture is to model it with interacting state machines. You break it into many functions that are each small and easy to verify. You use state machines to allow easier formal analysis for errors & control flow issues. You consider various types of problems at each component or layer, along with their interactions. The largest part you keep in your head at once will be *far* less than 100,000 lines of code. And you can do most of it in a safe language that catches common sources of code injections.

Of course, we're seeing a very different approach taken by the OpenSSL developers. It's paying off too. For the attackers. ;)

@ Jacob

Thanks for the clarification. I see what you're saying now. It makes sense. It is odd that my field is one of the few where people worry about these things. I think the reason is that what's being engineered, the computer, is an extremely versatile technology that's trusted in many endeavors. That's plenty opportunities + plenty misplaced trust. Typically = intense efforts by rather unscrupulous people.

April 23, 2014 9:44 PM

Figureitout on Conversnitch:

Bruce
--Software-Defined Radio scares me more than just capturing human audible signals; it also happens to be very cool and fun. Think about all the RF one uses in a typical day; those signals can be captured easier and easier, I'm so amazed at some of these tiny dongles and of course the sound cards. It's going to be fun for a while until something is done about RF security.

Slightly on-topic:
--I'm not sure (though I suspect it's not RF) what's happening to a local DJ's computer. It's so funny, multiple times now the computer has changed songs randomly and one time complete shutdown. Then an awkward moment live on air, "Bro I don't know what's up w/ my computer". "I didn't do that bro!" I suspect it's just malware that's dug a nice hole or some more benign explanation like crap hardware and not an active attack; but it's a good laugh on the way home.

April 23, 2014 9:41 PM

Nick P on Info on Russian Bulk Surveillance:

@ DB

Damn. I've never seen it said better than first paragraph. And it could be reused against so many DOD/NSA apologists. Just save it in your bookmarks to make for easy copy and paste. I fear you'll have opportunities. ;)

April 23, 2014 9:28 PM

Nick P on The Security of Various Programming Languages:

The Study

The choice of .NET, Java, PHP, and ASP.net are good as they'll represent most web applications. Coldfusion is OK as there's at least a lot of legacy systems running it. The fact that they chose Perl instead of Ruby (i.e. Rails) is confusing as I almost never hear of a web app being written in Perl, although Rails became a tiny industry. Although, the Movable Type system that powers Bruce's blog is Perl-based.

The overall vulnerability ratio along with their explanation (attack surface) seem accurate. It's unsurprising that there wasn't much difference between the major platforms because *they're about the same in terms of features and how they implement them.* I'd like to see a similar analysis of web apps in Erlang, Ocaml, Haskell, Ada, or LISP. They handle things quite different & have different levels of effort in safety/security. Of course, there are technologies designed specifically for secure web applications which are covered in above essay.

SQL injection, Cross-site scripting, and cross-site request forgery are still a big problem despite proven methods of dealing with them that aren't such a pain. Problem must be in language, platform, libraries and/or processes. These issues simply shouldn't be happening given what we know about preventing them.

Responses to individual commenters

@ Benni

That does look suspicious as heck. That it's a bunch of assembler would make a mistake both easier to hide & look like programmer error.

@ Weilinder

"As far as I know, no program written for a formal Turing machine has ever been implicated in any breach."

Far as I know, no formal Turing machine has ever been implemented and practical at the same time. I'm glad you mentioned it, though, as I found a bunch of interesting research leveraging Turing machines for security. All this time hearing about the concept I never knew how much better it was for real security vs common machines!

@ Ian Woollard

Good point. Pushing more worries on a programmer while assuming they'll do things right isn't a good way to do things.

@ Neal Lester

It was a good read and a sound argument. I looked at author's name after reading the article so it was a pleasant conclusion to see it was none other than the inventer of a good language. He doesn't just preach a theory, he put it into practice. :)

@ Douglas Knight

"These kinds of vulnerabilities might be the fault of the library, but how could XSS or SQL injection be the fault of the language?"

See my above post on how certain languages' design decisions make many errors easy to prevent.

@ Anura

"I don't think this really measures the security of the languages themselves, so much as it measures the developers themselves."

I agree mostly. Although, naturally I'm also inclined to blame languages that make mistakes easier. We all had this discussion re system programming recently. Many of same points apply to secure web programming.

@ Caleb

"I personally believe that the problem is neither language nor truly relative skill... it's that the learning materials don't teach in a secure by default manner. "

It's really the language/platform, Caleb. In some I posted above, you can practically throw a web application together while being sure it doesn't have all kinds of problems. That someone has to pause with concern for every function they write to accomplish the same thing says their tool is inferior. If it can be automated away, it should be.

@ L

"Putting together C and C++, especially the newer C++11/14 shows that you do not know the language."

"Programming correctly in C++ is harder than in java, ok. Still, no language can be idiot-proof. Idiots are always smarter. C++ used correctly takes away all the bad things from C."

Most C++ code isn't the newest one so it's an unfair statement. That said, while there are many differences, C and C++ share many of the same risks from a security point of view. Particularly, many of the most common operations must be scrutinized to avoid code injections. A previous discussion on this blog covered many languages that are type and memory safe by default while allowing high performance code. Two were used to write operating systems, microcontrollers, etc. So, putting C & C++ into the same category, while labeling them bad for security, makes sense to me. Compared to a language like Ada or PL/I, C++ is just turd polishing of C.

@ snarki

"I can confidently predict that ZERO security holes will be found in APL."

I'm placing a bet on a code injection in the interpreter using a failed array bounds check. Just because it would be ironic and hilarious. ;)

@ otto

Check out Quercus's implementation of PHP in Java. Combines best of both world's. I kept it in my archives in case I was ever forced to use PHP I might avoid some of its security problems. "And trade them for Java's" you might say? Yeah, it's why decided against both but it's nice to have a safer implementation of PHP with access to Java libraries.

@ Richard Schwartz

"Is it just me, or does anyone else have a problem with research that appears not to understand the difference between a language and a framework?"

Yeah, they kind of go hand in hand in web app development. A language with one might have shoddy security, while another framework provides excellent security. It's why I mentioned both in my essay above. Analyzing one without the other makes little sense.

April 23, 2014 9:15 PM

Figureitout on Metaphors of Surveillance:

name.withheld.for.obvious.reasons
--I liked Fahrenheit 451 too. Got Animal Farm waiting on a desk but other technical reading took its place. The gov't already burned books BTW, literally. I'm sure it was all actual sensitive info and not just covering up crimes/leaving the populace ignorant.

http://digitaljournal.com/article/298172

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..