Class Breaks

There’s a concept from computer security known as a class break. It’s a particular security vulnerability that breaks not just one system, but an entire class of systems. Examples might be a vulnerability in a particular operating system that allows an attacker to take remote control of every computer that runs on that system’s software. Or a vulnerability in Internet-enabled digital video recorders and webcams that allow an attacker to recruit those devices into a massive botnet.

It’s a particular way computer systems can fail, exacerbated by the characteristics of computers and software. It only takes one smart person to figure out how to attack the system. Once he does that, he can write software that automates his attack. He can do it over the Internet, so he doesn’t have to be near his victim. He can automate his attack so it works while he sleeps. And then he can pass the ability to someone­—or to lots of people—­without the skill. This changes the nature of security failures, and completely upends how we need to defend against them.

An example: Picking a mechanical door lock requires both skill and time. Each lock is a new job, and success at one lock doesn’t guarantee success with another of the same design. Electronic door locks, like the ones you now find in hotel rooms, have different vulnerabilities. An attacker can find a flaw in the design that allows him to create a key card that opens every door. If he publishes his attack software, not just the attacker, but anyone can now open every lock. And if those locks are connected to the Internet, attackers could potentially open door locks remotely—­they could open every door lock remotely at the same time. That’s a class break.

It’s how computer systems fail, but it’s not how we think about failures. We still think about automobile security in terms of individual car thieves manually stealing cars. We don’t think of hackers remotely taking control of cars over the Internet. Or, remotely disabling every car over the Internet. We think about voting fraud as unauthorized individuals trying to vote. We don’t think about a single person or organization remotely manipulating thousands of Internet-connected voting machines.

In a sense, class breaks are not a new concept in risk management. It’s the difference between home burglaries and fires, which happen occasionally to different houses in a neighborhood over the course of the year, and floods and earthquakes, which either happen to everyone in the neighborhood or no one. Insurance companies can handle both types of risk, but they are inherently different. The increasing computerization of everything is moving us from a burglary/fire risk model to a flood/earthquake model, which a given threat either affects everyone in town or doesn’t happen at all.

But there’s a key difference between floods/earthquakes and class breaks in computer systems: the former are random natural phenomena, while the latter is human-directed. Floods don’t change their behavior to maximize their damage based on the types of defenses we build. Attackers do that to computer systems. Attackers examine our systems, looking for class breaks. And once one of them finds one, they’ll exploit it again and again until the vulnerability is fixed.

As we move into the world of the Internet of Things, where computers permeate our lives at every level, class breaks will become increasingly important. The combination of automation and action at a distance will give attackers more power and leverage than they have ever had before. Security notions like the precautionary principle­—where the potential of harm is so great that we err on the side of not deploying a new technology without proofs of security—will become more important in a world where an attacker can open all of the door locks or hack all of the power plants. It’s not an inherently less secure world, but it’s a differently secure world. It’s a world where driverless cars are much safer than people-driven cars, until suddenly they’re not. We need to build systems that assume the possibility of class breaks—and maintain security despite them.

This essay originally appeared on Edge.org as part of their annual question. This year it was: “What scientific term or concept ought to be more widely known?

Posted on January 3, 2017 at 6:50 AM47 Comments

Comments

Till Hänisch January 3, 2017 7:02 AM

Avoiding monocultures reduces the impact of class breaks ….

So, in my opinion the solution to this problem is to have as much diversity as possible, for example by using unikernels.

cphinx January 3, 2017 7:24 AM

I had an interesting discussion about this recently. Though it was primarily on the topic of IoT in general, it relates quite well.

I think the moral of the discussion was “most IoT devices use Linux”. Some may be Ubuntu, some may be Debian, some may be another distribution not mentioned. All of them have a somewhat easily-enabled firewall, whether it be IPTables or UFW. A default deny incoming rule set would greatly reduce the number vulnerabilities. On top of that, incorporating the use of a certificate or authentication system, via a key-fob (your car key) is another method of adding a second layer of security.

There are a list of 100 other things that are simple security features which are virtually untouched in the deployment of IoT devices.

I support the idea of minimal security checks being regulated in IoT in order to get the ball rolling, although I recognize, in the long run, it won’t be enough.

Gerard van Vooren January 3, 2017 8:15 AM

Dutch investigative journalist Brenno de Winter held a presentation about security breaches and how they could be treated. It’s in Dutch so I won’t share the link but it’s on youtube. In short he said that the breaches could also be treated like airplane crash investigations, fully open and with clear recommendations and demands. He also asked why data breaches like those of Sony Pictures and OPM are all kept secret.

Jason Garman January 3, 2017 8:16 AM

I would also add that the centralization and move to the “cloud” (a.k.a. other people’s computers) is another under-appreciated risk as we move to more “smart” IoT devices.

On one hand, cloud providers have the advantage of centralizing and specializing in security. On the other hand, we’ve already seen the care that IoT vendors (operating their own clouds) have placed in securing the individual devices they manufacture.

In the rush to market, how much care is placed in making sure these cloud-based IoT services are secure? Once your door lock is connected to the “cloud” so you can easily lock & unlock your door from your cell phone, you are inherently trusting a whole wide array of systems, people, and processes – none of which you have direct control over – to keep your home secure.

So while it’s not a “class break” by the strict definition, a determined attacker could unlock all doors from a given manufacturer by attacking one system (the IoT cloud) rather than thousands or millions of individual IoT devices directly. There’s no need to repeat your attack on every door lock once you have control over the cloud C&C system…

PJ January 3, 2017 8:19 AM

Class breaks are not unique to computers: Masterlocks are vulnerable to a certain well-documented way of picking them. Padlocks in general, due to their design, are vulnerable to a dewar of liquid nitrogen and a hammer. Any communication system handled by humans is vulnerable to a DDoS (think: mailrooms and mass-automated-online catalog requests, or operators and mass-automated-online telemarketer/salesperson call requests).

The real difference is in the automation of exploitation, not that there’s a class of exploitable systems. All padlocks are vulnerable to liquid nitrogen and a hammer… the entire ‘class’ of padlocks is ‘broken’…but they have to be hacked one by one. If applying the break was automatable, it would be much more worrisome than it is.

wrt IoT gear: Lots of the actual real IoT gear doesn’t run an OS at all, just a glimmer of microcontroller-level code that ships its data off to be processed/handled elsewhere, usually via something like MQTT. That elsewhere, though… that usually runs linux (because linux won on servers a long time ago). See the talk on MQTT at Defcon 24.

Tammi January 3, 2017 8:52 AM

Your writing suggests smart persons are necessarily male. I don’t think that’s what you meant. So why did you write it?

Not Again January 3, 2017 9:03 AM

“thousands of Internet-connected voting machines”

I’m not aware of any voting system in the US that’s Internet connected. Do you really want to stir up that hornet’s nest of fake news again?

hawk January 3, 2017 9:03 AM

Hillary! Is that you??

“Sorry to waste your time gentlemen but I don’t work for the government.”

Mark Johnson January 3, 2017 9:14 AM

“I know lots of smart women, a few are probably smarter than me. You just ain’t one of them.”

mrprogressive January 3, 2017 10:06 AM

@Tammi

Your writing suggests smart persons are necessarily male. I don’t think that’s what you meant. So why did you write it?

No, his writing doesn’t. Bruce’s writing suggests that one randomly chosen smart person happens to be male and says nothing about others. If you had said something like “Bruce, in your writing you use male pronouns too often, I find that discouraging, please could you use female or genderless pronouns a bit more to help suggest females can be smart too” then you might have a point. You also would not be rude to our host.

But as it is, Tammi, your writing causes Donald Trump*. Please stop.

  • Didactic hypocrisy.

Wael January 3, 2017 10:20 AM

@Bruce,

but it’s not how we think about failures.

Some of us do and that topic was covered several times in the C-v-P discussions, among others.

@Tammi,

The masculine pronoun in the thread refers to a male villain. A smart one, but a scumbag, nonetheless. Not worth fighting over. Besides, this is language clumsiness that came about from olden days, when men were men and women were ribs 🙂

Dirk Praet January 3, 2017 10:31 AM

@ Gerard

It’s in Dutch so I won’t share the link but it’s on youtube.

Please do. You and I are not the only native Dutch speakers here. Everyone benefits from exposure to other languages. I’ve recently taken up Kurdish, learning from a shopkeeper around the corner. Not only do I have a great sympathy for these people, the language also has quite some Hindi influences which makes it a bit easier for me too.

He also asked why data breaches like those of Sony Pictures and OPM are all kept secret.

Simple. Whereas the official reason is always national or company security, it’s mostly to avoid embarrassment over horrible incompetence and mismanagement, as well as the associated accountability and risk of litigation by regulatory bodies and other stakeholders. Not to mention the possibility of attribution games for political reasons.

@ Tammi

Your writing suggests smart persons are necessarily male. I don’t think that’s what you meant.

Is that you, Simone Peter?

@ Wael

Some of us do and that topic was covered several times in the C-v-P discussions

Exactly. Those were the days 😎

Wael January 3, 2017 10:50 AM

@Dirk Praet,

Exactly. Those were the days 😎

Until @Nick_P had a cow (three or four of them) and changed his mind 🙂 He loooooves compilers these days. Yuck…

Did you give up on Japanese? It’s a pretty difficult language with unusual grammar constructs. I forgot 90% of what little I learned there (all 20 words of them.) itchy knee sun … that’s how I remember to count 🙂

Dirk Praet January 3, 2017 11:10 AM

@ Wael

Did you give up on Japanese?

I kinda let it slip when I broke up with my then love interest (who had Japanese roots), but intend to take it back up at some point. I’m more into gun-wielding Peshmerga women hunting Daesh fighters these days 😎

Jonathan Barnes January 3, 2017 11:31 AM

Hey Bruce,

Great read, with class breaks coming to things like thermostats, electronic door locks (for homes), and our refrigerators do you think there is a big enough threat to warrant government mandated fail safes and network disablements? For example if a researcher were to discover a critical hack in a particular brand of electronic door lock there could be a feature that allows a user to turn off the electronic/networked portions of the lock and use a purely manually lock and key until a fix could be deployed.

thanks love the blog

An January 3, 2017 12:22 PM

Class Breaks also applies to DRM. The Movie studios, the RIAA, they come up with all these ways to implement DRM. But if there is sufficient demand to break the DRM, somebody out there will be able to take the system apart, right down to chemically taking the chips apart, looking at them under a microscope, and running image processing on the silicon. It might be different people, doing different parts of the job, but thanks to the internet these folks will be able to find each other. And once it’s broken, like with libdecss, everyone can use it quite trivially.

“Class Breaks” is an interesting term to describe why DRM is constantly being broken.

Gerard van Vooren January 3, 2017 1:45 PM

@ Dirk Praet,

It’s quite funny, I searched but can’t find the specific presentation anymore. It’s probably removed. But this presentation of the same Brenno de Winter comes pretty close. You will love it.

Danel January 3, 2017 3:18 PM

@Bruce writes, “Floods don’t change their behavior to maximize their damage based on the types of defenses we build.”

This is true but it misses the point. There have been attempts to change weather in order to change the outcomes of military engagements, the notorious Operation Popeye during the Vietnam war is an example. Just like the fact that attribution in cyberspace is difficult one can imagine future worlds where determining the difference between a “natural” and man-made disaster is equally difficult.

Ted January 3, 2017 3:24 PM

Electronic door locks, like the ones you now find in hotel rooms, have different vulnerabilities. An attacker can find a flaw in the design that allows him to create a key card that opens every door. If he publishes his attack software, not just the attacker, but anyone can now open every lock.

US-CERT provided some detailed recommendations for responding to the Cisco ASA exploits released by the Shadow Brokers in August 2016.

“The Increasing Threat to Network Infrastructure Devices and Recommended Mitigations”
https://www.us-cert.gov/ncas/alerts/TA16-250A

Documented CVE’s unearthed from the released code in this alert pertain to Cisco, Fortinet, and WatchGuard network infrastructure.

Great article. Thanks for sharing.

Bren January 3, 2017 3:32 PM

@ Gerard van Vooren
This is off-topic, but are there some good Dutch information Security focused websites or sources you would recommend? I’m currently learning Dutch and I wanted to find good articles and videos where I could improve both my Dutch listening/reading and infosec knowledge.

WhiskersInMenlo January 3, 2017 5:07 PM

“An example: Picking a mechanical door lock requires both skill and time. Each lock is a new job, and success at one lock doesn’t guarantee success with another of the same design. ”

One should add master key systems of a physical lock as an example of a class break.
Picking or stealing one physical lock allows the exposure of the
master key system. A glance at the key ring of a guard or other master key
holder can make it obvious what the master of master keys is. Eyeballing
a key cut for a locksmith is a lot like a mechanic eyeballing a bolt and selecting
the correct wrench from the wall. Trained eyeballs can even eliminate the need
for a valid key.

There is a classic paper where a valid single user key was leveraged
to discover the master. One pin at a time was cut multiple times to
discover the additional pin breaks. It might take eight blanks on an
eight pin lock to test each pin but since the single user key turns the lock
it is easy to test each possible cut.

Ratio January 3, 2017 6:09 PM

@Dirk Praet,

I’ve recently taken up Kurdish, learning from a shopkeeper around the corner. Not only do I have a great sympathy for these people, the language also has quite some Hindi influences which makes it a bit easier for me too.

Kurdish and Hindi are both Indo-Iranian languages, so similarities are to be expected. I doubt there’s been any noticeable Hindi influence on Kurdish; that’d probably be Persian influence on both Kurdish and Hindi.

By the way, did you learn to read and write Devanagari? That looks like loads of fun.

Clive Robinson January 3, 2017 6:44 PM

@ PJ,

Lots of the actual real IoT gear doesn’t run an OS at all, just a glimmer of microcontroller-level code that ships its data off to be processed/handled elsewhere, usually via something like MQTT

Like many other light weight communications protocols MQTT lacks the basics of what is required for security. As can be seen from their own FAQ,

    Does MQTT support security?
    You can pass a user name and password with an MQTT packet in V3.1 of the protocol. Encryption across the network can be handled with SSL, independently of the MQTT protocol itself (it is worth noting that SSL is not the lightest of protocols, and does add significant network overhead). Additional security can be added by an application encrypting data that it sends and receives, but this is not something built-in to the protocol, in order to keep it simple and lightweight.

Whilst this “insecure” effective “plaintext” design is not of necessity a problem if mitigated correctly, in practice it is.

The likes of SSL are very far from being lightweight protocols, and often require the support of a significant OS, all of which are bad news in IoT devices at the best of times. However as has been found out SSL it’s self has significant problems as do most other secure communications protocols.

This problem as I’ve pointed out before is a failing of NIST –amongst others– to come up with a suitably robust but flexible framework protocol to deal with communications security in anything approaching a timely fashion.

It is all very well to run basic algorithm contests, but as our host has pointed out repeatedly secure algorithms do not of necessity become secure systems. In fact the opposite is more likely in that even the algorithm will be implemented in an insecure way.

This is not just an IoT issue but an issue that covers all non consumer grade devices such as “Smart Meters” for utilities and “Medical Implant devices” both of which have expected “in service life” times of rather more than a quater of a century, with a half century or more being considered the likely norm in the near future.

Importantly non of the security algorithms so far have had anything like a quater of a century as a stable life time. Thus any secure communications protocol framework looking at in service life expectancy of half a century or more needs to take the implications of this lack of longevity of base security algorithms into account. Whilst also avoiding the now well known pit falls of “fall back attacks”.

Whilst it is not an easy ask, it’s something that really needed to have been done and dusted a decade ago, not ignored / kicked into the long grass by NIST and other significant non trade standards bodies.

Nick P January 3, 2017 7:16 PM

@ Bruce

Don’t forgot to tell people about the other side of the coin I’ve been preaching for years: mechanisms and techniques exist that provably eliminate entire classes of error or vulnerability. They started with Burroughs in 1961 immune to out-of-bounds, stack/buffer overflow, invalid arguments at type level, and so on. All down to the OS. I don’t remember a break in their model until return-oriented programming was invented. Similarly, there are language subsets used in embedded that can be statically proven immune to code injection. There’s default guides, libraries, and daemons to handle reporting or configuration secure-by-default. And so on and so forth.

Just apathy. Yet, people should still be told that there’s vulnerabilities opening up whole classes of systems to attack but even more schemes to knock out whole classes of vulnerabilities. Tons of languages, libraries, and techniques.

@ Wael

Or I just took the discussion to several new levels of real systems instead of the old metaphor. It informed my thinking but now I’m on hardware/software combos w/ considerations down to analogue or RF [done by other people]. Interestingly, the CPU modifications have proved to be where both the low-hanging fruit and perfectionist stuff are best achieved.

Wael January 3, 2017 11:55 PM

Seems @Clive Robinson addressed the concept of classes of attacks before I became active on this blog,

Known unknowns, are new varients within a “class” of attacks. That is if you identify a basic class of attack (say a timing attack based on adding jitter to the data TX sequence) then finding a generic solution to that attack (clock the outputs) solves the problem for the whole class within known bounds.

I guess I picked it up later. Memory lapse… my turn 🙁

Dirk Praet January 4, 2017 4:03 AM

@ Ratio

By the way, did you learn to read and write Devanagari?

Nope, although it does look like a bit of a challenge. I mostly get into a specific language when for some reason or another it sparks my interest. And because I just happen to pick up languages rather easily. I got kinda intrigued by what the guys at the so-called Turkish shop around the corner were speaking to each other and which I knew definitely wasn’t Turkish at all. It sounded more like a weird Dari or Farsi derivative, and turned out to be Kurdish.

I’m not sure however if such Indo-European languages have influenced Hindi or that it’s actually the other way around. Or like my Former Sikh teacher used to say: “You racist Europeans always seem to forget that us over here are in fact the original Arians and that our language and culture are at the foundation of yours” 😎

Clive Robinson January 4, 2017 4:31 AM

@ Wael,

Seems @Clive Robinson addressed the concept of classes of attacks before I became active on this blog

Yup been saying it for years, one way or another.

Likewise I’ve also pointed out that the way we go about dealing with ICTsec attacks is generally wrong.

That is people tend to come up with a solution that is specific to an instance of an attack. Which whilst it works for that specific attack, it does not work for other attacks in that class which is why we have “Class Breaks”.

Worse often such a specific patch adds specialised code which adds complexity, which history tells us can also add new attack vectors or unpredictable behaviour in the code base. Thus addressing class attacks properly is an important step to solving existing class breaks. Further bringing in the knowledge into the design face should help prevent class breaks from forming in the first place.

To give an idea of what the difference is, and why going that extra inch in the mile to solve the general class attack rather than the specific instance of an attack is so worth while I have used the example of fire and other real world safety drills.

Most of us know that fire drills are an annoying but necessary part of being in a communal space with limited entrances and exits and are for our safety. The drills used to contain quite a bit of fire specific information like where hoses extinquishers and other equipment was located and how to tackle a fire etc. However in areas where earth tremors etc were common the training was more about refuge points etc.

With the advent of bomb threats in Europe such as from the IRA from the 1970s the notion changed from specific fire drills, earth quake drills etc to the evacuation drills they all had in common. Thus the essence of the drills is to get people away from the source of danger and not to get hung up on specific asspects of solving individual dangers inexpertly.

That is the common solution to a whole class of dangers was to get distance between those not involved with dealing with the danger and the danger (thus the danger gets left to the likes of the emergancy services who are better trained and qualified to deal with the danger).

There was however a flaw in many plans in that they were not just evacuation drills but evacuate and regroup drills. That is people were told to gather together at a specific point for a head count. This head count was supposadly to make the job of the emergency services more effective (though there is little evidence that this has ever worked).

However the regrouping in effect negated one asspect of evacuation which was dispersal. In fact it often ment that people became more susceptible to other dangers such as vehicles on roads etc due to the often crowded nature of older business districts and lack of safe regroup points.

Importantly there is a specific difference in class events between “design and chance” in the case of class attacks there is the “directing mind”.

Which we see in the case of actual bomb attacks, there is a directing mind and such minds will realise what the military did centuries ago about ambush and kill zones. If you aim is actually to kill people rather than send a message, then you can take advantage of the “regroup” location to form a kill zone. Thus a small bomb or just a warning will cause people to evacuate and regroup where a larger device in a vehicle etc will explode killing and injuring many more than would otherwise have been possible…

Thus when considering a protection against a class attack you need to be careful that you do not create a new potential attack vector for a directing mind to exploit.

Life is “as they say” never simple…

Richard K January 4, 2017 6:30 AM

At one place where I used to work, which had had a terrorist bomb go off outside a few years before, they had the concept of “Internal Shelter Area”. So in the case a of a bomb threat we didn’t go outside with the regroup danger as mentioned, we went to the ISA, which was a corridor area with no external windows or doors, so if a bomb did go off outside we’d be safer.

The only time I remember an alarm when we were actually sent to the ISA was when an unexploded WW2 bomb was uncovered on a nearby building site.

DavidH January 4, 2017 9:33 AM

@ Tammi [and those who responded to Tammi’s comments]

You are quite correct… Bruce Schneier should have used the personal pronoun [singular] “They” instead of “he” in the article.
This works just as well and is gender neutral.
Unless you are referring to a specific person of a known gender there is no reason to use gendered pronouns, and to continue with the old-fashioned, out-of-date, and yes sexist, practice of using ‘he’ as a stand-in for an unknown person is no-longer tenable. Particularly so in fields that have a major problem [both in reality and with their image] with attracting and retaining female talent such as in the IT and security industry.
Now to be absolutely clear I am not accusing Bruce of being sexist, far from it, but unfortunately using gendered language like that DOES have an impact. It makes people subconsciously associate the jobs and tasks that you designate a ‘he’ to with men. It means that the default image of a hacker or an IT/security specialist [in this case] is a man. And that has a significant negative impact.
And it’s so trivial to fix, just use ‘they’, or ‘them’, or ‘their’… instead of he, or him, or his… when you are talking about a generic unspecified person. It’s easy to do and nobody notices when you do it which means it’s totally non-jarring…. Unlike every time I come across sentences like these ones…
“Once “he” does that, “he” can write software that automates “his” attack. “He” can do it over the Internet, so “he” doesn’t have to be near “his” victim. “He” can automate “his” attack so it works while “he” sleeps” ….
Because THAT is jarring.
Imagine for a moment being a female hacker reading that…
It should read like this.
“Once they do that, they can write software that automates their attack. They can do it over the Internet, so they don’t have to be near their victim. They can automate their attack so it works while they sleep”

Gender Neutral Pronouns: They’re Here, Get Used To Them
By Tom Scott
https://www.youtube.com/watch?v=46ehrFk-gLk

Gerard van Vooren January 4, 2017 12:09 PM

@ Bren,

This is off-topic, but are there some good Dutch information Security focused websites or sources you would recommend?

Why do you think I am here? 😉 But no, I am not aware of those (Dirk maybe?). There is the Bits of Freedom [1], which is the Dutch version of the EFF. Then there is tweakers [2], a site for all kinds of new technology, gadgets, games and also security and law. I mentioned Brenno de Winter earlier. You can read his books or watch presentations on youtube. Rop Gonggrijp has also done quite a bit of work in this area. About privacy, you can read the book ‘Je hebt wel iets te verbergen’ written by Maurits Martijn and Dimitri Tokmetzis from De Correspondent [3].

[1] https://bof.nl/
[2] https://tweakers.net/
[3] https://decorrespondent.nl/home (pay news site without ads)

Dirk Praet January 4, 2017 1:47 PM

@ Gerard, @ Bren,

This is off-topic, but are there some good Dutch information Security focused websites or sources you would recommend?

If the goal is to improve your Dutch, read normal books or newspapers. Or go all the way and hook up with a pretty native speaker. Your motivation will be off the scale and the results astounding. And don’t bother too much with the IT speak. Most of it is in English anyway, and those terms that have been translated to Dutch in general extremely weird neologisms no person in his right mind uses anyway.

If I had learned my German from a localized Windows copy, people would probably call the funny farm on me. Datenverarbeitungsanlage? Festplatte? Speichern Unter? You have to be on acid to make such stuff up.

Clive Robinson January 4, 2017 4:56 PM

@ DavidH,

And it’s so trivial to fix, just use ‘they’, or ‘them’, or ‘their’… instead of he, or him, or his… when you are talking about a generic unspecified person. It’s easy to do and nobody notices when you do it which means it’s totally non-jarring….

Where it goes wrong and why people tend to still use gender is when you have two people in a sentance…

    When Alice sends the request to Bob he sends an ack which when she receives it, she then sends a second ack back to him.

Works whilst the use of they, their, do not, and can be exceadingly ambiguous if tried or worse quite tortuous to read. You could use the names throughout but that has in the past be considered bad style as it tends to cause mental fatigue in the reader.

Thus I try to use they and their whilst dealing with an individual, but I try not to when dealing with two people. Obviously with three or more people you have to start torturing the reader or find some other situational differentiation such as “the driver” and a male and female passenger, or captin, pilot, chief, engineer and helmsman etc.

Ratio January 4, 2017 8:33 PM

@Dirk Praet,

I got kinda intrigued by what the guys at the so-called Turkish shop around the corner were speaking to each other and which I knew definitely wasn’t Turkish at all. It sounded more like a weird Dari or Farsi derivative, and turned out to be Kurdish.

Well, yeah, all of those are Western Iranian languages.

I’m not sure however if such Indo-European languages have influenced Hindi or that it’s actually the other way around.

Again, similarities are to be expected as these languages are fairly closely related (they are all part of the Indo-Iranian branch of the Indo-European language family).

The influence of Persian on Hind(ustan)i is obvious. The Wikipedia page on Indo-Persian culture is a starting point if you want to know more. (For example: Persian was the official language of the Delhi Sultanate, the Mughal Empire, and their successor states, as well as the cultured language of poetry and literature.)

Or like my Former Sikh teacher used to say: “You racist Europeans always seem to forget that us over here are in fact the original Arians and that our language and culture are at the foundation of yours” 😎

I’m sorry but that’s decidedly “meh” on multiple levels.

pete January 4, 2017 9:04 PM

re voting hacks,

I don’t know about many places, but everywhere I talk about voting hacks, we are clear that voting fraud is practically useless to steal an election, while election fraud (hacking the machines and/or the system) is a viable path to governmental theft

Clive Robinson January 5, 2017 3:27 AM

@ Moderator,

Will those ‘loonie faux locksmiths’ ever stop blighting this blog?

The above from “Caroline James” is just one more attempt at link spam. From what is in all probablity a con-artist with a big drill, huge bills and the mental attitude that everything in life is a nail so all you need is a bigger hammer…

Dirk Praet January 5, 2017 4:53 AM

@ Ratio

Again, similarities are to be expected as these languages are fairly closely related (they are all part of the Indo-Iranian branch of the Indo-European language family).

The origins of Hindi are Indo-Aryan, not Indo-Iranian, and it’s a direct descendant of an early form of Sanskrit. Which is of course not to say that over time it indeed hasn’t been heavily influenced by lots of other languages, among which Persian, Turkic and English, to name just a few. Both Hindi and Urdu are, as you say, Hindustani dialects, the latter of which was the one favoured by the Mughal (muslim) elites, whereas Hindi was eventually standardised as a separate language more commonly spoken by the masses in the north of the country.

I’m sorry but that’s decidedly “meh” on multiple levels.

My good friend Kamal Singh is a bit of a militant character and no stranger to hyperbole. I owe him quite some gratitude for introducing me to Sikh culture and history, and I know of no better language than Punjabi to totally intimidate the cr*p out of people. I once used it on a really annoying (French) manager who had no clue what my rant was about, but almost turned green with fear just by the sound of it and after that pretty much didn’t dare to speak to me again. I also never had to pay for drinks at after-hours office parties anymore because suddenly all of my then co-workers wanted to be my friend.

Jennifer Gold Stockholm January 5, 2017 6:54 PM

@ Dirk

If I had learned my German from a localized Windows copy, people would probably > call the funny farm on me. Datenverarbeitungsanlage? Festplatte? Speichern > Unter? You have to be on acid to make such stuff up.

hilarious! love it! the idea of learning german from a windows version…oh my hahah

@ Bren @ Gerard van @ Dirk

fluent-forever.com

it’s a methodology for learning languages. It’s easily the most ingenious, sophisticated, fastest and clearest system for aqcuring a language, in existence. The author taught himself 5 languages between the age of 20 and 30. It’s’ a book, heaps of free resources and support and explaination on the website. it uses research to cut through all the highly inefficient ways people learn languages (including the ways we learnt in school)
This method starts with training the ears ONLY first. Then pronunication and spelling. Then vocab. Then grammar.
It also is designed to dump the learning into long term memory so you don’t forget what you learn.

@ Bren there is a program for Dutch available at the above website.
The methodology can be used for any language however the author has spent a couple of years creating trainers for about 12 languages, to work with the free software.

https://fluent-forever.com/pronunciation-trainers/

The actual book is Fluent Forever by Gabriel Wyner

Ratio January 5, 2017 8:59 PM

@Dirk Praet,

The origins of Hindi are Indo-Aryan, not Indo-Iranian, […]

Hindi ∈ Indo-Aryan ⊂ Indo-Iranian.

By the way, I stumbled on some info on Kurmanji (the Kurdish I assume you’re learning) you may find useful.

Dirk Praet January 6, 2017 3:51 AM

@ Ratio

By the way, I stumbled on some info on Kurmanji (the Kurdish I assume you’re learning) you may find useful.

Thanks for the link. Looks like some interesting reading for the weekend.

Bren January 11, 2017 2:37 PM

@Gerard can Vooren
@Jennifer Gold Stockholm

Thanks for the input. I will be checking all of these out.

@Dirk Praet
Sadly, I have already used the pretty native speaker tactic to learn Spanish, and it looks like I am such with that.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.