Silk Road forums

The talk I gave last year on common crypto flaws still seems to generate comments. The majority of the discussion is by defenders of Javascript crypto. I made JS crypto a very minor part of the talk because I thought it would be obvious why it is a bad idea. Apparently, I was wrong to underestimate the grip it seems to have on web developers.

Rather than repeat the same rebuttals over and over, this is my final post on this subject. It ends with a challenge — if you have an application where Javascript crypto is more secure than traditional implementation approaches, post it in the comments. I’ll write a post citing you and explaining how you changed my mind. But since I expect this to be my last post on the matter, read this article carefully before posting.

To illustrate the problems with JS crypto, let’s use a simplified example application: a secure note-taker. The user writes notes to themselves that they can access from multiple computers. The notes will be encrypted by a random key, which is itself encrypted with a key derived from a passphrase. There are three implementation approaches we will consider: traditional client-side app, server-side app, and Javascript crypto. We will ignore attacks that are common to all three implementations (e.g., weak passphrase, client-side keylogger) and focus on their differences.

The traditional client-side approach offers the most security. For example, you could wrap PGP in a GUI with a notes field and store the encrypted files and key on the server. A client who is using the app is secure against future compromise of the server. However, they are still at risk of buggy or trojaned code each time they download the code. If they are concerned about this kind of attack, they can store a local copy and have a cryptographer audit it before using it.

The main advantage to this approach is that PGP has been around almost 20 years. It is well-tested and the GUI author is unlikely to make a mistake in interfacing with it (especially if using GPGME). The code is open-source and available for review.

If you don’t want to install client-side code, a less-secure approach is a server-side app accessed via a web browser. To take advantage of existing crypto code, we’ll use PGP again but the passphrase will be sent to it via HTTP and SSL. The server-side code en/decrypts the notes using GPGME and pipes the results to the user.

Compared to client-side code, there are a number of obvious weaknesses. The passphrase can be grabbed from the memory of the webserver process each time it is entered. The PGP code can be trojaned, possibly in a subtle way. The server’s /dev/urandom can be biased, weakening any keys generated there.

The most important difference from a client-side attack is that it takes effect immediately. An attacker who trojans a client app has to wait until users download and start using it. They can copy the ciphertext from the server, but it isn’t accessible until someone runs their trojan, exposing their passphrase or key. However, a server-side trojan takes effect immediately and all users who access their notes during this time period are compromised.

Another difference is that the password is exposed to a longer chain of software. With a client-side app, the passphrase is entered into the GUI app and passed over local IPC to PGP. It can be wiped from RAM after use, protected from being swapped to disk via mlock(), and generally remains under the user’s control. With the server-side app, it is entered into a web browser (which can cache it), sent over HTTPS (which involves trusting hundreds of CAs and a complex software stack), hits a webserver, and is finally passed over local IPC to PGP. A compromise of any component of that chain exposes the password.

The last difference is that the user cannot audit the server to see if an attack has occurred. With client-side code, the user can take charge of change management, refusing to update to new code until it can be audited. With a transport-level attack (e.g., sslstrip), there is nothing to audit after the fact.

The final implementation approach is Javascript crypto. The trust model is similar to server-side crypto except the code executes in the user’s browser instead of on the server. For our note-taker app, the browser would receive a JS crypto library over HTTPS. The first time it is used, it generates the user’s encryption key and encrypts it with the passphrase (say, derived via PBKDF2). This encrypted key is persisted on the server. The notes files are en/decrypted by the JS code before being sent to the server.

Javascript crypto has all the same disadvantages as server-side crypto, plus more. A slightly modified version of all the server-side attacks still works. Instead of trojaning the server app, an attacker can trojan the JS that is sent to the user. Any changes to the code immediately take effect for all active users. There’s the same long chain of software having access to critical data (JS code and the password processed by it).

So what additional problems make JS crypto worse than the server-side approach?

    Numerous libraries not maintained by cryptographers — With a little searching, I found: clipperz, etherhack, Titaniumcore, Dojo, crypto-js, jsSHA, jscryptolib, pidCrypt, van Everdingen’s library, and Movable Type’s AES. All not written or maintained by cryptographers. One exception is Stanford SJCL, although that was written by grad students 6 months ago so it’s too soon to tell how actively tested/maintained it will be.
    New code has not been properly reviewed and no clear “best practices” for implementers — oldest library I can find is 2 years old. Major platform-level questions still need to be resolved by even the better ones.
    Low-level primitives only — grab bag of AES, Serpent, RC4, and Caesar ciphers (yes, in same library). No high-level operations like GPGME. Now everyone can (and has to) be a crypto protocol designer.
    Browser is low-assurance environment — same-origin policy is not a replacement for ACLs, privilege separation, memory protection, mlock(), etc. JS DOM allows arbitrary eval on each element and language allows rebinding most operations (too much flexibility for crypto).
    Poor crypto support — JS has no secure PRNG such as /dev/urandom, side channel resistance is much more difficult if not impossible
    Too many platforms — IE, Firefox, Netscape, Opera, WebKit, Konqueror, and all versions of each. Crypto code tends to fail catastrophically in the face of platform bugs.
    Auditability — each user is served a potentially differing copy of the code. Old code may be running due to browser cache issues. Impossible for server maintainers to audit clients.

JS crypto is not even better for client-side auditability. Since JS is quite lenient in allowing page elements to rebind DOM nodes, even “View Source” does not reveal the actual code running in the browser. You’re only as secure as the worst script run from a given page or any other pages it allows via document.domain.

I have only heard of one application of JS crypto that made sense, but it wasn’t from a security perspective. A web firm processes credit card numbers. For cost reasons, they wanted to avoid PCI audits of their webservers, but PCI required any server that handled plaintext credit card numbers to be audited. So, their webservers send a JS crypto app to the browser client to encrypt the credit card number with an RSA public key. The corresponding private key is accessible only to the backend database. So based on the wording of PCI, only the database server requires an audit.

Of course, this is a ludicrous argument from a security perspective. The webserver is a critical part of the chain of trust in protecting the credit card numbers. There are many subtle ways to trojan RSA encryption code to disclose the plaintext. To detect trojans, the web firm has a client machine that repeatedly downloads and checksums the JS code from each webserver. But an attacker can serve the original JS to that machine while sending trojaned code to other users.

While I agree this is a clever way to avoid PCI audits, it does not increase actual security in any way. It is still subject to the above drawbacks of JS crypto.

If you’ve read this article and still think JS crypto has security advantages over server-side crypto for some particular application, describe it in a comment below. But the burden of proof is on you to explain why the above list of drawbacks is addressed or not relevant to your system. Until then, I am certain JS crypto does not make security sense.

Just because something can be done doesn’t mean it should be.
Epilogue
Auditability of client-side Javascript

I had overstated the auditability of JS in the browser environment by saying the code was accessible via “View Source”. It turns out the browser environment is even more malleable than I first thought. There is no user-accessible menu that tells what code is actually executing on a given page since DOM events can cause rebinding of page elements, including your crypto code. Thanks to Thomas Ptacek for pointing this out. I updated the corresponding paragraph above.

JS libraries such as jQuery, Prototype, and YUI all have APIs for loading additional page elements, which can be HTML or JS. These elements can rebind DOM nodes, meaning each AJAX query can result in the code of a page changing, not just the data displayed. The APIs don’t make a special effort to filter out page elements, and instead trust that you know what you’re doing.

The same origin policy is the only protection against this modification. However, this policy is applied at the page level, not script level. So if any script on a given page sets document.domain to a “safe” value like “example.net”, this would still allow JS code served from “ads.example.net” to override your crypto code on “www.example.net”. Your page is only as secure as the worst script loaded from it.

Brendan Eich made an informative comment on how document.domain is not the worst issue, separation of privileges for cross-site scripts is:

    Scripts can be sourced cross-site, so you could get jacked without document.domain entering the picture just by <script src=”evil.ads.com”>. This threat is real but it is independent of document.domain and it doesn’t make document.domain more hazardous. It does not matter where the scripts come from. They need not come from ads.example.net — if http://www.example.net HTML loads them, they’re #include’d into http://www.example.net’s origin (whether it has been modified by document.domain or not).

    In other words, if you have communicating pages that set document.domain to join a common superdomain, they have to be as careful with cross-site scripts as a single page loaded from that superdomain would. This suggests that document.domain is not the problem — cross-site scripts having full rights is the problem. See my W2SP 2009 slides.

“Proof of work” systems

Daniel Franke suggested one potentially-useful application for JS crypto: “proof of work” systems. These systems require the client to compute some difficult function to increase the effort required to send spam, cause denial of service, or bruteforce passwords. While I agree this application would not be subject to the security flaws listed in this article, it would have other problems.

Javascript is many times slower than native code and much worse for crypto functions than general computation. This means the advantage an attacker has in creating a native C plus GPU execution environment will likely far outstrip any slowness legitimate users will accept. If the performance ratio between attacker and legitimate users is too great, Javascript can’t be used for this purpose.

He recognized this problem and also suggested two ways to address it: increase the difficulty of the work function only when an attack is going on or only for guesses with weak passphrases. The problem with the first is that an attacker can scale up their guessing rate until the server slows down and then stay just below that threshold. Additionally, she can parallelize guesses for multiple users, depending on what the server uses for rate-limiting. One problem with the second is that it adds a round-trip where the server has to see the length of the attacker’s guess before selecting a difficulty for the proof-of-work function. In general, it’s better to select a one-size-fits-all parameter than to try to dynamically scale.
Browser plugin can checksum JS crypto code

This idea helps my argument, not hurts it. If you can deploy a custom plugin to clients, why not run the crypto there? If it can access the host environment, it has a real PRNG, crypto library (Mozilla NSS or Microsoft CryptoAPI), etc. Because of Javascript’s dynamism, no one knows a secure way to verify signatures on all page elements and DOM updates, so a checksumming plugin would not live up to its promise.

Imagine a system that involved your browser encrypting something, but filing away a copy of the plaintext and the key material with an unrelated third party on the Internet just for safekeeping. That's what this solution amounts to. You can't outsource random number generation in a cryptosystem; doing so outsources the security of the system.
What else is the Javascript runtime lacking for crypto implementors?

Two big ones are secure erase (Javascript is usually garbage collected, so secrets are lurking in memory potentially long after they're needed) and functions with known timing characteristics. Real crypto libraries are carefully studied and vetted to eliminate data-dependant code paths --- ensuring that one similarly-sized bucket of bits takes as long to process as any other --- because without that vetting, attackers can extract crypto keys from timing.
But other languages have the same problem!

That's true. But what's your point? We're not saying Javascript is a bad language. We're saying it doesn't work for crypto inside a browser.
But people rely on crypto in languages like Ruby and Java today. Are they doomed, too?

Some of them are; crypto is perilous.

But many of them aren't, because they can deploy countermeasures that Javascript can't. For instance, a web app developer can hook up a real CSPRNG from the operating system with an extension library, or call out to constant-time compare functions.

If Python was the standard browser content programming language, browser Python crypto would also be doomed.
What else is Javascript missing?

A secure keystore.
What's that?

A way to generate and store private keys that doesn't depend on an external trust anchor.
External what now?

It means, there's no way to store a key securely in Javascript that couldn't be expressed with the same fundamental degree of security by storing the key on someone else's server.
Wait, can't I generate a key and use it to secure things in HTML5 local storage? What's wrong with that?

That scheme is, at best, only as secure as the server that fed you the code you used to secure the key. You might as well just store the key on that server and ask for it later. For that matter, store your documents there, and keep the moving parts out of the browser.
These don't seem like earth-shattering problems. We're so close to having what we need in browsers, why not get to work on it?

Check back in 10 years when the majority of people aren't running browsers from 2008.
That's the same thing people say about web standards.

Compare downsides: using Arial as your typeface when you really wanted FF Meta, or coughing up a private key for a crypto operation.

We're not being entirely glib. Web standards advocates care about graceful degradation, the idea that a page should at least be legible even if the browser doesn't understand some advanced tag or CSS declaration.

"Graceful degradation" in cryptography would imply that the server could reliably identify which clients it could safely communicate with, and fall back to some acceptable substitute in cases where it couldn't. The former problem is unsolved even in the academic literature. The latter recalls the chicken-egg problem of web crypto: if you have an acceptable lowest-common-denominator solution, use that instead.
This is what you meant when you referred to the "crushing burden of the installed base"?

Yes.
And when you said "view-source transparency was illusory"?

We meant that you can't just look at a Javascript file and know that it's secure, even in the vanishingly unlikely event that you were a skilled cryptographer, because of all the reasons we just cited.
Nobody verifies the software they download before they run it. How could this be worse?

Nobody installs hundreds of applications every day. Nobody re-installs each application every time they run it. But that's what people are doing, without even realizing it, with web apps.

This is a big deal: it means attackers have many hundreds of opportunities to break web app crypto, where they might only have one or two opportunities to break a native application.
But people give their credit cards to hundreds of random people insecurely.

An attacker can exploit a flaw in a web app across tens or hundreds of thousands of users at one stroke. They can't get a hundred thousand credit card numbers on the street.
You're just not going to give an inch on this, are you?

Nobody would accept any of the problems we're dredging up here in a real cryptosystem. If SSL/TLS or PGP had just a few of these problems, it would be front-page news in the trade press.
You said Javascript crypto isn't a serious research area.

It isn't.
How much research do we really need? We'll just use AES and SHA256. Nobody's talking about inventing new cryptosystems.

AES is to "secure cryptosystems" what uranium oxide pellets are to "a working nuclear reactor". Ever read the story of the radioactive boy scout? He bought an old clock with painted with radium and found a vial of radium paint inside. Using that and a strip of beryllium swiped from his high school chemistry lab, he built a radium gun that irradiated pitchblende. He was on his way to building a "working breeder reactor" before moon-suited EPA officials shut him down and turned his neighborhood into a Superfund site.

The risks in building cryptography directly out of AES and SHA routines are comparable. It is capital-H Hard to construct safe cryptosystems out of raw algorithms, which is why you generally want to use high-level constructs like PGP instead of low-level ones.
What about things like SJCL, the Stanford crypto library?

SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document.

SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young.

The authors of SJCL themselves say, "Unfortunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks." That last example is a killer: what they're really saying is, "we don't know enough about Javascript runtimes to know whether we can securely host cryptography on them". Again, that's painful-but-tolerable in a server-side application, where you can always call out to native code as a workaround. It's death to a browser.
Aren't you creating a self-fulfilling prophecy about Javascript crypto research?

People don't take Javascript crypto seriously because they can't get past things like "there's no secure way to key a cryptosystem" and "there's no reliably safe way to deliver the crypto code itself" and "there's practically no value to doing crypto in Javascript once you add SSL to the mix, which you have to do to deliver the code".
These may be real problems, but we're talking about making crypto available to everyone on the Internet. The rewards outweigh the risks!

DETROIT --- A man who became the subject of a book called "The Radioactive Boy Scout" after trying to build a nuclear reactor in a shed as a teenager has been charged with stealing 16 smoke detectors. Police say it was a possible effort to experiment with radioactive materials.

The world works the way it works, not the way we want it to work. It's one thing to point at the flaws that make it hard to do cryptography in Javascript and propose ways to solve them; it's quite a different thing to simply wish them away, which is exactly what you do when you deploy cryptography to end-users using their browser's Javascript runtime.

... did I do something to offend you? 

Perhaps if you read 2 messages down you'd notice that I looked again and decided I was wrong.  I'm not entirely sure what your tone is about, friend, but I made a statement; decided I needed to verify my statement because I couldn't quite remember what led me to the conclusion I came to; did so; decided I was wrong; and corrected it.  Perhaps you'd like to tell me what I should have done, other than leaving a question completely unanswered while we all waited for you or astor to show up?

Privnote actually was -- at least at the time that I looked at it -- just as safe as PGP.

I think privnote is just as safe as PGP

Quote from: tree on June 16, 2013, 06:22 pm

Quote from: Xennek on June 16, 2013, 05:59 pm

Why don't more people encrypt or at least privnote their addresses? Is there absolutely anything stopping LEAs/ "good" guys running a compromised exit node from reading your order list and adding all of the addresses to a watch list? Seems like an easy way to get nabbed to me.

Why would you think that privnote is safer than using the address field? Your address is automatically deleted from SR's servers too so why use a third party to do that for you? Privnote could keep a copy of all its messages for all we know.

Privnote actually was -- at least at the time that I looked at it -- just as safe as PGP.  Though I didn't go over it line by line or anything; still, the only real problem with it is that the code to encrypt stuff is downloaded on-the-fly from the server, and there's no guarantee that it hasn't changed since someone last looked at it.

By design, there will never be a guarantee that the code you download to encrypt the message wasn't changed the moment prior to you downloading it.  That's why it isn't secure, but to my knowledge it's the only reason.

Quote from: kmfkewm on June 16, 2013, 12:38 pm

Quote from: GoodShitExplorer on June 16, 2013, 10:57 am

Quote from: kmfkewm on June 16, 2013, 10:42 am

Quote from: varakann on June 16, 2013, 10:10 am

A thing is a unit of thought (hence it's called thinking), how do we get a thing out of the continuous world - we name it. Thinking without language is not possible by definition. Is there other ways of conscious being and understanding the world - of course.

So you don't think you can solve a navigational problem (how to get from point A to point B) without using words or language?

If you already have developed a language then the chances are that in your navigational exercise you would use lot of language based terms to refer to various entities to do the job. Our brain does it quite fast that you might think that you are not using language base terms at all.

As I mentioned in the OP, language based thinking is possible. Many people do that on a daily basis. May be certain types of activities/thinking are predominantly without any language; such as thoughts/actions needed to meet the biological needs, etc. Babies do think without any language and so did the human before developing any language.

Thinking that are around ideas or interactions with others (of course in our head only) require language. On the other hand it might be possible to have fantasies about someone where language may not be needed much; of course it depends on what you are fantasizing about

I do not think that thinking requires language. You can visually think complex things through without necessarily requiring any language at all. The simplest example is spatial navigation. However, even complex things like anonymity networks can be thought of in a purely visual sense.

I don't think you realize that in your thinking you use lot of language based terms and symbols. Our brain does it quite fast and can fool you about it.

by Saul McLeod email icon published 2008, updated 2012

Atkinson’s and Shiffrin’s (1968) multi-store model was extremely successful in terms of the amount of research it generated.

However, as a result of this research, it became apparent that there were a number of problems with their ideas concerning the characteristics of short-term memory.

Building on this research, Baddeley and Hitch (1974) developed an alternative model of short-term memory which they called working memory (see fig 1).

Baddeley and Hitch (1974) argue that the picture of short-term memory (STM) provided by the Multi-Store Model is far too simple.  According to the Multi-Store Model, STM holds limited amounts of information for short periods of time with relatively little processing.  It is a unitary system. This means it is a single system (or store) without any subsystems.  Working Memory is not a unitary store.

working memory

    Fig 1. The Working Memory Model (Baddeley and Hitch, 1974)

Working memory is STM. Instead of all information going into one single store, there are different systems for different types of information.  Working memory consists of a central executive which controls and co-ordinates the operation of two subsystems: the phonological loop and the visuo-spatial sketchpad.

Central Executive: Drives the whole system (e.g. the boss of working memory) and allocates data to the subsystems (VSS & PL). It also deals with cognitive tasks such as mental arithmetic and problem solving.

Visuo-Spatial Sketch Pad (inner eye): Stores and processes information in a visual or spatial form. The VSS is used for navigation.

The phonological loop is the part of working memory that deals with spoken and written material. It can be used to remember a phone number. It consists of two parts

    o Phonological Store (inner ear) – Linked to speech perception Holds information in speech-based form (i.e. spoken words) for 1-2 seconds.

    o Articulatory control process (inner voice) – Linked to speech production. Used to rehearse and store verbal information from the phonological store.

working memory diagram

    Fig 2. The Working Memory Model Components (Baddeley and Hitch, 1974)

The labels given to the components (see fig 2) of the working memory reflect their function and the type of information they process and manipulate. The phonological loop is assumed to be responsible for the manipulation of speech based information, whereas the visuo-spatial sketchpad is assumed to by responsible for manipulating visual images. The model proposes that every component of working memory has a limited capacity, and also that the components are relatively independent of each other.

The Central Executive

The central executive is the most important component of the model, although little is known about how it functions.  It is responsible for monitoring and coordinating the operation of the slave systems (i.e. visuo-spatial sketch pad and phonological loop) and relates them to long term memory (LTM). The central executive decides which information is attended to and which parts of the working memory to send that information to be dealt with.

The central executive decides what working memory pays attention to. For example, two activities sometimes come into conflict such as driving a car and talking. Rather than hitting a cyclist who is wobbling all over the road, it is preferable to stop talking and concentrate on driving. The central executive directs attention and gives priority to particular activities.

The central executive is the most versatile and important component of the working memory system. However, despite its importance in the working-memory model, we know considerably less about this component than the two subsystems it controls.

Baddeley suggests that the central executive acts more like a system which controls attentional processes rather than as a memory store.  This is unlike the phonological loop and the visuo-spatial sketchpad, which are specialized storage systems. The central executive enables the working memory system to selectively attend to some stimuli and ignore others.

Baddeley (1986) uses the metaphor of a company boss to describe the way in which the central executive operates.  The company boss makes decisions about which issues deserve attention and which should be ignored.  They also select strategies for dealing with problems, but like any person in the company, the boss can only do a limited number of things at the same time. The boss of a company will collect information from a number of different sources.

If we continue applying this metaphor, then we can see the central executive in working memory integrating (i.e. combining) information from two assistants (the phonological loop and the visuo-spatial sketchpad) and also drawing on information held in a large database (long-term memory).

The Phonological Loop

The phonological loop is the part of working memory that deals with spoken and written material. It consists of two parts (see Figure 3).

The phonological store (linked to speech perception) acts as an inner ear and holds information in speech-based form (i.e. spoken words) for 1-2 seconds. Spoken words enter the store directly. Written words must first be converted into an articulatory (spoken) code before they can enter the phonological store.

The articulatory control process (linked to speech production) acts like an inner voice rehearsing information from the phonological store. It circulates information round and round like a tape loop. This is how we remember a telephone number we have just heard. As long as we keep repeating it, we can retain the information in working memory.

The articulatory control process also converts written material into an articulatory code and transfers it to the phonological store.


The Visuo-Spatial Sketchpad

The visuo-spatial sketchpad (inner eye) deals with visual and spatial information. Visual information refers to what things look like. It is likely that the visuo-spatial sketchpad plays an important role in helping us keep track of where we are in relation to other objects as we move through our environment (Baddeley, 1997).

As we move around, our position in relation to objects is constantly changing and it is important that we can update this information.  For example, being aware of where we are in relation to desks, chairs and tables when we are walking around a classroom means that we don't bump into things too often!

The sketchpad also displays and manipulates visual and spatial information held in long-term memory. For example, the spatial layout of your house is held in LTM. Try answering this question: How many windows are there in the front of your house?  You probably find yourself picturing the front of your house and counting the windows. An image has been retrieved from LTM and pictured on the sketchpad.

Evidence suggests that working memory uses two different systems for dealing with visual and verbal information. A visual processing task and a verbal processing task can be performed at the same time. It is more difficult to perform two visual tasks at the same time because they interfere with each other and performance is reduced. The same applies to performing two verbal tasks at the same time. This supports the view that the phonological loop and the sketchpad are separate systems within working memory.

Empirical Evidence for the Working Memory Model

What evidence is there that working memory exists, that it is made up of a number of parts, that it performs a number of different tasks?

The working memory model makes the following two predictions:

    1. If two tasks make use of the same component (of working memory), they cannot be performed successfully together.

    2. If two tasks make use of different components, it should be possible to perform them as well as together as separately.

Key Study: Baddeley and Hitch (1976)

Aim: To investigate if participants can use different parts of working memory at the same time.

Method: Conducted an experiment in which participants were asked to perform two tasks at the same time (dual task technique) - a digit span task which required them to repeat a list of numbers, and a verbal reasoning task which required them to answer true or false to various questions (e.g. B is followed by A?).

Results: As the number of digits increased in the digit span tasks, participants took longer to answer the reasoning questions, but not much longer - only fractions of a second.  And, they didn't make any more errors in the verbal reasoning tasks as the number of digits increased.

Conclusion: The verbal reasoning task made use of the central executive and the digit span task made use of the phonological loop.

Update on the Working Memory Model - The Episodic Buffer

The original model was updated by Baddeley (2000) after the model failed to explain the results of various experiments. An additional component was added called the episodic buffer. The episodic buffer acts as a 'backup' store which communicates with both long term memory and the components of working memory.

episodic buffer
Fig 3.Updated Model to include the Episodic Buffer

Evaluation of Working Memory

Strengths

Researchers today generally agree that short-term memory is made up of a number of components or subsystems. The working memory model has replaced the idea of a unitary (one part) STM as suggested by the multistore model.

The working memory model explains a lot more than the multistore model. It makes sense of a range of tasks - verbal reasoning, comprehension, reading, problem solving and visual and spatial processing. And the model is supported by considerable experimental evidence.

The working memory applies to real life tasks:

    - reading (phonological loop)

    - problem solving (central executive)

    - navigation (visual and spatial processing)

The KF Case Study supports the Working Memory Model. KF suffered brain damage from a motorcycle accident that damaged his short-term memory. KF's impairment was mainly for verbal information - his memory for visual information was largely unaffected. This shows that there are separate STM components for visual information (VSS) and verbal information (phonological loop).

Working memory is supported by dual task studies (Baddeley and Hitch, 1976).

The working memory model does not over emphasize the importance of rehearsal for STM retention, in contrast to the multi-store model.

Weaknesses

Lieberman criticizes the working memory model as the visuo-spatial sketchpad (VSS) implies that all spatial information was first visual (they are linked). However, Lieberman points out that blind people have excellent spatial awareness although they have never had any visual information. Lieberman argues that the VSS should be separated into two different components: one for visual information and one for spatial.

There is little direct evidence for how the central executive works and what it does. The capacity of the central executive has never been measured.

Working memory only involves STM so it is not a comprehensive model of memory (as it does not include SM or LTM).

The working memory model does not explain changes in processing ability that occur as the result of practice or time.

While thoughts without language certainly occurs, it follows the same inherent system from which language originates. Our mind uses images for placeholders instead of names; space may follow different rules in our brain, but ultimately it perpetuates from the same physical frame work (neural network) from which language originates. The distinction is trivial at best.

but ultimately it perpetuates from the same physical frame work (neural network) from which language originates

Quote from: kmfkewm on June 16, 2013, 10:42 am

Quote from: varakann on June 16, 2013, 10:10 am

A thing is a unit of thought (hence it's called thinking), how do we get a thing out of the continuous world - we name it. Thinking without language is not possible by definition. Is there other ways of conscious being and understanding the world - of course.

So you don't think you can solve a navigational problem (how to get from point A to point B) without using words or language?

If you already have developed a language then the chances are that in your navigational exercise you would use lot of language based terms to refer to various entities to do the job. Our brain does it quite fast that you might think that you are not using language base terms at all.

As I mentioned in the OP, language based thinking is possible. Many people do that on a daily basis. May be certain types of activities/thinking are predominantly without any language; such as thoughts/actions needed to meet the biological needs, etc. Babies do think without any language and so did the human before developing any language.

Thinking that are around ideas or interactions with others (of course in our head only) require language. On the other hand it might be possible to have fantasies about someone where language may not be needed much; of course it depends on what you are fantasizing about