Conversations about life & privacy in the digital age

Privacy Roundup #7 of 2013

August is upon us and summer in the northern hemisphere is in full swing. And although it seems like yesterday, news of PRISM broke several months ago and Edward Snowden continues to be firmly in the conversation. Further, the US government has been under relentless pressure from foreign governments, congressmen, senators, and companies for what many consider a very intrusive information gathering policy.

For this roundup we did try to include some links to news other then the aforementioned but – as you can tell below – we still felt obligated to include several PRISM / NSA related coverage as the associated privacy issues are still significant.

Click away and catch up on some of what has been going on in the world of online privacy and security in the last month:

From our perspective, we are happy to see a national and international debate rising around privacy and its growing importance in the online world in which we live. This will be a significant issue of our time as we need to understand where lines should be drawn and who is responsible for drawing them. Finding a fitting quote to end this privacy roundup with was not a terribly difficult task in light of this recent news.

“Big Brother is Watching You.” ― George Orwell, 1984

Privacy Roundup #6 of 2013

Summer is officially in full swing in the northern hemisphere. For us Americans that means a celebration of fireworks and cookouts and freedom. This year in particular we are thinking a little more about what ‘freedom’ means in the backdrop of PRISM and its impacts on our society.

It is a complicated issue for sure as we all want to live in a safe place – away from harm and terror. However, we also need to be fully aware of the costs and what we are willing to give up to achieve this safety. It is a dialogue that is finally entering the public discourse and one that we hope will continue in the weeks and months ahead.

This edition of the Privacy Roundup serves up a collection of the most interesting, eye opening and informational news pieces and blog posts on the topic of privacy and of course focus on the late breaking news around the growing Snowden/PRISM scandal:

The weekly quote for this roundup may have to be from “Cosmo” the lovable blind hacker from the 1992 movie “Sneakers” – “There’s a war out there, old friend. A world war. And it’s not about who’s got the most bullets. It’s about who controls the information. What we see and hear, how we work, what we think… it’s all about the information!”

As always, we hope you have a productive and private month ahead! Until next time…

Privacy VS. Security in a PRISM: The Important Difference

The events of these last many days certainly raise awareness around the integrity of data and the companies we entrust with it. Many of the articles and posts have poured over the impacts: the good, the bad, the necessity, the importance, the invasive, the threat, the martyr and so on. Given this dearth of commentary, I would like to spend some time writing about a finally emerging concept – privacy. And further – how privacy is substantially differentiated from security.

To begin, let’s review the definitions of these two words (according to Google):

Security – The state of being free from danger or threat

Privacy – The state or condition of being free from being observed or disturbed by other people

Of all the conversations and dialogue about PRISM, none have concentrated on the security measures in place at companies like Google, Facebook, Amazon, Apple, Verizon, and others. Why you might ask? Because this was not a breach of security. No one hacked into their systems. No one confiscated passwords. Rather – according to reports – these companies willingly complied. [Note: It would be appropriate to draw attention to NSA's security breach in light of Eric Snowden's ability to access and confiscate these documents.]

If the world were oriented around privacy, the ability for a 3rd party provider of web-based services (such as Google or Facebook or Dropbox or SpiderOak) to access the plaintext data is removed. In other words, privacy takes away the ability to access the data in a meaningful way such that it cannot be supplied to government agencies or stolen under the threat of hackers.

We are not now nor have we ever suggested that there isn’t a need for security; in fact, security is absolutely critical. And for many implementations of  various services, privacy is not applicable. However – in the world of conversation and creation of personally owned content from photos to chat to calls to spreadsheets to documents – privacy is absolutely a critical component that can be achieved.

My hope is that we – as a society – will now start asking the question: Why? Why do companies have access to my photos and documents and chat conversations? Is it a necessary part of the service they are offering? A convenience for me?If yes, what are these companies doing to keep my data private? And are there alternatives if I do want real privacy? From the NSA? From the company? From anyone?

This dialogue is critical and I am very glad to see the word ‘privacy’ start to weave its way into conversations. Further, that the public is being educated on the important difference between privacy and security and – hopefully – we all can start making choices accordingly.

For more information on this topic, please visit ZeroKnowledgePrivacy.org and/or watch the explainers below on Privacy VS. Security and the important role of the Privacy Policy .

Privacy Roundup: PRISM Special Edition

May has rolled into June and summer is fast approaching. Originally I had planned for this privacy update to be another collection of somewhat random links regarding the world of security and privacy. And then… We had Thursday. And then PRISM. And it seemed only right to gather as much information, opinion and material as possible around PRISM and make it available to our readers.

But what is PRISM?

This far in, all anyone can tell for sure is that PRISM is the name of a data collection model and technology solution that improves speed and simplicity in allowing NSA and possibly other US agencies to access user data from a large number of the worlds most popular online services. (Including Google, Skype, Microsoft, Facebook etc.)

It seems the program in itself actually does not introduce any new laws, or even break any current ones. What it does however is enables a more effective way for the NSA to request and receive private user data. And of course, this makes it ripe for speculation as to what this ‘new’ stream lined procurement process is being used for and how.

One of the most informative posts as to the model, use, and participants ironically enough comes from the NSA themselves (via Washington Post) and can be found here:

NSA slides explain the PRISM data-collection program

If you desire to dig a bit deeper into PRISM, what people are saying / thinking, and what companies may or may not have been directly involved, here are a collection of what we found to be the most informative links on the subject from the last several days:

Though we will be elaborating on the PRISM program in relation to SpiderOak in a separate blog post,  I can say definitively that our users’ data is encrypted client-side, uploaded, and stored in its fully encrypted state which means we  are never able to view plaintext user content under any circumstances. In short, PRISM would be wholly and entirely useless in the SpiderOak context. 

To Note: We also have yet to even be contacted by any agency regarding the program – surely a result of our ‘Zero-Knowledge’ privacy environment. After all, encrypted data is rather useless for conducting data mining activity.

In light of recent news and the topic for this special roundup I think it’s only fitting we sign off with this quote of the week:

He who controls the past controls the future. He who controls the present controls the past.” – George Orwell in 1984

 

Millennials Care About Privacy After All

SpiderOak is passionate about privacy. If you are reading this, chances are you are passionate about privacy. But what about the Millennials? A Millennial is also defined as Generation Y for those generally born from the latter 1970s, or from the early 1980s to the early 2000s.

It’s been said that the Millennial Generation does not care about privacy. According to a recent survey by USC Annenberg, Millennials think differently and are smarter about making decisions when it comes to privacy.

This infographic explains:

  • 70% of Millennials would rather not give others access to their personal data or information.
  • Millennials use social media to keep in contact with friends and family.
  • 25% of Millennials do not mind sharing some information in exchange for relevant advertising.
  • 48% of Millennials use social media several times per day more than those 35 and older.
  • 56% of Millennials don’t mind sharing location with companies in order to receive coupons or deals for nearby businesses.
  • 51% of Millennials don’t mind sharing information with companies as long as they get something in return.

However, a good percentage of millennials, compared to those age 35 and older, are willing to give up some of their privacy only if they will benefit from giving up their personal information.

To read their full study, you can click here.

Are you a Millennial? What do you think about the survey? We’d love to hear your thoughts.

SpiderOak’s Analysis and Recommendations for the Crypto in Kim Dotcom’s Mega, Part One

Here at SpiderOak, we’re excited to see new peers in the privacy industry. Kim Dotcom’s Mega has brought attention to privacy in a way that we’ve sought for years. Mega has created a surge of awareness in the importance of online privacy, and it will undoubtedly result in a boom of privacy-aware cloud applications. This is a good day for the Internet.

Crypto is very hard to get right even under the best of circumstances. Producing a usable browser-side cryptosystem on a tight schedule is a minefield, and getting a product out the door is an accomplishment. And while we applaud them for their bravado, we must be honest to their users. Rushing to meet a symbolic launch date was not the best choice for protecting the privacy of end users. A private launch first inviting cryptographers to use and abuse the system and make recommendations would have been worth the wait.

Mega’s crypto has similar design goals to SpiderOak, so we have a long familiarity with these topics. Bear with us as we dive into some of the important parts of their code, after which we’ll make some recommendations for Mega and their users.

In our analysis of Mega’s crypto, we are so far just looking at design-level problems and recommending solutions. We have not done a full implementation-level security code audit, where we painstakingly inspect, test, verify, and occasionally shake our heads at every line of code to be sure that it’s doing exactly what it should be. Those are expensive and take time.

We’re also ignoring entire categories of things that make this arrangement fragile, such as the untrustworthiness of the Javascript runtime as a secure environment for handling secrets, the lack of true random number source in many browsers, and the way the code is packaged and verified. Those have been discussed and debated in depth for a long time. Clipperz has some recommendations for code delivery which would at least make things easier for code auditors.

As of yesterday, the method used for verifying Javascript from untrusted mirrors was vulnerable although it’s likely fixed or will be fixed soon since that’s an easy change.

The reason we’re entertaining the idea of Javascript runtime cryptography at all is specifically because of the particular threat model involved. This approach may be effective at protecting the service provider from the perils of plaintext access to user data. We have the same goals here at SpiderOak and are sympathetic to them. Browser based crypto where the service provider is motivated to stay ignorant of your data is at least preferable to the Dropbox approach where no attempt at meaningful cryptography is made and everything is stored in plain text equivalent.

How Mega’s Key Generation and User Authentication Code Works

With Mega, as with SpiderOak, your passphrase has the double burden of supporting account authentication (without disclosing that password to the server) and outer level data encryption. An outer level key is derived from the text of your password using a key derivation function. With that derived outer level key, a “master key” for symmetric AES is encrypted. Everything else on down the hierarchy is encrypted to that master key, or another key that is itself directly or indirectly encrypted to that master key.

Here’s the master key creation function and the key derivation function:


function api_create_u_k()
{
    u_k = Array(4); // static master key, will be stored at
                    // the server side encrypted with the master pw
    for (var i = 4; i--; ) u_k[i] = rand(0x100000000);
}

// convert user-supplied password array
function prepare_key(a)
{
    var i, j, r;
    var pkey = [0x93C467E3,0x7DB0C7A4,0xD1BE3F81,0x0152CB56];

    for (r = 65536; r--; )
    {
        for (j = 0; j < a.length; j += 4)
        {
            key = [0,0,0,0];

            for (i = 0; i < 4; i++) if (i+j < a.length) key[i] = a[i+j];

            aes = new sjcl.cipher.aes(key);
            pkey = aes.encrypt(pkey);
        }
    }

    return pkey;
}

User Authentication starts in user0001.js with the u_login() function. It works by sending the server a calculated authentication value value called "userhash."

Here's the code for calculating userhash.


function stringhash(s,aes)
{
    var s32 = str_to_a32(s);
    var h32 = [0,0,0,0];

    for (i = 0; i < s32.length; i++) h32[i&3] ^= s32[i];

    for (i = 16384; i--; ) h32 = aes.encrypt(h32);

    return a32_to_base64([h32[0],h32[2]]);
}

It's a cute little hash with similarities to CBC-MAC. A 128-bit "message" is created by splitting up the string into 128-bit sections and xor-ing all of those together with 128 bits of zeroes. This message is then run through 16384 rounds of AES using a supplied key. In the case of the userhash, the key is the output of your password run through the Key Derivation Function.

Your email address and userhash are sent to Mega's servers, which presumably authenticate using the userhash, and your encrypted master key is returned along with a session identifier (sid). Getting the master key is therefore based on a simple token that can be replayed instead of a more secure challenge/response mechanism.

On the server side, auditors should look for a timing vulnerability that can be exploited when the server compares your userhash, which would allow an attacker to gradually learn the right hash over many attempts. If the server side implementation is competent, they're treating this stringhash output as a password (it effectively is one for auth purposes) and storing it server side using bcrypt or scrypt.

Now that the client has your master key, it is decrypted using the password-derived key. It gets a little confusing with their unfortunate reuse of variable names, but aes winds up being your master key. It's also interesting to note that if you select "remember me" on login, your master key gets stored unencrypted in browser local storage, where it undoubtedly gets written to disk.


    if (typeof res == 'object')
    {
        var aes = new sjcl.cipher.aes(ctx.passwordkey);

        // decrypt master key
        if (typeof res[0].k == 'string')
        {
            k = base64_to_a32(res[0].k);

            if (k.length == 4)
            {
                k = decrypt_key(aes,k);

                aes = new sjcl.cipher.aes(k);

The sid is derived in one of two ways. Either you get a tsid with the encrypted master key, which seems to be for ephemeral and unconfirmed accounts, or you get a csid, which seems to be for confirmed accounts. If you get a csid, your RSA private key is unpacked from the response and decrypted with your master key. t will be used in a bit.


    var t = mpi2b(base64urldecode(res[0].csid));

    var privk = a32_to_str(decrypt_key(aes,base64_to_a32(res[0].privk)));

The RSA private key is then turned into more usable integer arrays and used to decrypt csid, which becomes your sid. You will have to squint to see what's going on here, it's the second element of r.


    r = [k,
         base64urlencode(
            b2s(
                RSAdecrypt(t, rsa_privk[2], rsa_privk[0],
                           rsa_privk[1], rsa_privk[3])
               ).substr(0,43)),
         rsa_privk];

The far more interesting path is when you get a tsid. The client checks it by encrypting the first 16 bytes with your master key and verifying it against the last 16 bytes.


    t = base64urldecode(res[0].tsid);
    if (a32_to_str(
            encrypt_key(aes,str_to_a32(t.substr(0,16)))
        ) == t.substr(-16)
       )
        r = [k,res[0].tsid];

It seems that in the case of a tsid, the server does have the unprotected master key. It's the only way the server could have calculated the last sixteen bytes that are verified here. Since this is probably only for ephemeral accounts, the master key won't be used again and this doesn't really matter. It does open the interesting possibility that data uploaded with ephemeral accounts could be less private than confirmed accounts.

Analysis and First Recommendations

Beyond our caveats above, Mega's first "hair on fire" problem is the implementation of their Key Derivation Function. This function's job is to take a (probably weak) passphrase and 1) turn it into a usable symmetric key that can encrypt secrets and 2) do so in a way that is not easily brute forced. The first part it does well; the second part it hardly does at all.

Mega's KDF is not one of the best practice recommendations such as PBKDF2 or Bcrypt, but rather a simple home grown implementation which runs the user's passphrase through 216 rounds of an AES cipher with a fixed key. That key is the same across all users — there is no added "salt".

A "salt" is a small random value used to vary KDF output with the same password input. No salt means that any two users with the same passphrase will have the same KDF output. Various research suggests that a large portion of end users will have passwords found on a list of the top 10,000 most common passwords. Calculating Mega keys from such a list would be simple. Having to account for a random salt in the KDF exponentially complicates this effort, offering some protection to a database of users who often make poor password choices.

The other problem with Mega's KDF is just that AES is too fast. It's implemented in hardware on commodity systems — you're probably reading this on a system with hardware AES. Fast AES makes each password attempt faster, making it easier to brute force the password. In contrast, Bcrypt intentionally uses Blowfish because it is expensive to compute.

With this easily computed KDF, huge databases of password keys can be built using the fixed key and every password combination out to some reasonable length. These tables will not only allow the recovery of data encrypted inside every account, but they will also recover all the passwords themselves. (A database with combinations of usernames and passwords is often considered more valuable than the accounts they protect, because they can be re-used at PayPal.com, etc. and many will succeed.) It's been revealed that href="http://arstechnica.com/security/2013/01/cracking-tool-milks-weakness-to-reveal-some-mega-passwords/">Mega confirmation emails contain the encrypted master key, making it that much easier to brute force the password offline. Oh, and someone already created a crack tool to help you.

I suspect that the implementers of the system were reasoning to the effect of: "So what? This derived key is only held in memory and is only used for encrypting another key, and only that encrypted output is saved to the server. That next key is acting like a salt." To be effective, the salt must go at the beginning of this process rather than the end, so that every attack attempt has to restart calculations from the beginning. Whatever those next level of keys decrypt will be plaintext and look like plaintext so checking for success only adds a couple of cheap steps to an attack, if they're necessary at all.

Recommendation: Use PBKDF2, Scrypt, or Bcrypt instead of AES. There are JavaScript implementations available (we use jsBCrypt for web signups). If you must stick with AES for some reason, make the input to the KDF not be the raw password, but a SHA256 HMAC of the password with the salt as the HMAC key. Save the salt (plaintext) along with the output. Use at least 32 bytes of true random data for the salt. Turn up the rounds as high as you can stand (and use web workers to avoid stalling the browser).

While you're working on that section of the code, you can also improve the authentication process. When creating an account, run the KDF twice with the same password, but with two different salts. One salt is for deriving a outer layer key like usual, and the other is for creating and storing a challenge key. Then you can use a real challenge/response approach to auth instead of a static token, challenging a user to decrypt something using their challenge key. This makes it cheap for the server to do 'Zero-Knowledge' password proof auth (no CPU intensive bcrypt comparisons), avoids an attacker authenticating through just replaying a previous login session, and keeps you out of the business of storing a database of password equivalents.

In the short term, those of you using Mega should set a very long random password that you never use elsewhere and avoid storing sensitive data. Then as soon as these flaws are resolved, close your old Mega account and create a new one with a different password (and thus a whole new set of keys). Expect everything from the old account to be compromised.

We will continue in additional parts to discuss metadata encryption, data encryption, MACs, convergent encryption / encrypted data de-duplication, and exchanging messages with others.

Announcing: SpiderOak Blue OpenLicense

Yesterday, we announced the world’s first truly private cloud storage system designed for institutional use – SpiderOak Blue OpenLicense (OL). Our enterprise customers are growing and one exciting trend is the increasing number of colleges and universities needing to fully manage the data of their faculty, staff and students. Now, University IT departments can easily deploy a cloud-based backup – sync – share product, centrally manage accounts, and keep ‘Zero-Knowledge’ privacy intact.

Validating this need is Richard Stiennon, Chief Research Analyst at IT-Harvest. “Universities are a major adopter of cloud-based technologies because they have an inherent need to store a tremendous amount of data,” said Stiennon. “Because of the high value of the intellectual property being stored on their private clouds — as well as the potential for this data to be subpoenaed under federal law — universities need to consider a cloud provider which can off-set that responsibility and assure their students complete privacy and transparency. This can only be assured within a ‘Zero-Knowledge’ environment.”

In addition to the functional benefits SpiderOak Blue OL provides, we can extend learning institutions a significant labor-saving solution. Rather than procuring and allocating additional storage hardware, colleges and universities can seamlessly create and remove storage space on an as-needed basis. This allows for an easy transition for outgoing seniors whereby they graduate into a standalone SpiderOak account and are able to manage their own storage needs.

No matter what phase of learning or degree of pursuit, it’s always satisfying to hear from happy students such as Ross Mounce, PhD Student & Panton Fellow at the University of Bath, United Kingdom. “SpiderOak is great for research data management. The ‘Zero-Knowledge’ privacy client-side data encryption provides far better security than Dropbox, whilst maintaining excellent ease of use and cross-platform syncing.”

Reddit, World Backup Day, SpiderOak, March 31st and the power of Social Media

It started as a single thread from the user adamjeff on the well known forum/news site reddit.com (here). Over the next few days through reddit’s messaging system, email, twitter, facebook and word of mouth, the ‘idea’ behind World Backup Day was born.

The thread received over 2,500 ‘up-votes’ and over 1,000 comments. Users wanted to discuss the idea as a group – wondering what date should be ‘the day’ and what it should be called. The following day a few users – lead by user zoomacrymosby – were hard at work. User norunomu was designing both the website and logo, the domain worldbackupday.net was registered, and everybody was scrambling to get the information site up.

As an avid redditor and with a vested interest in online backup, I reached out to Ismail (the person behind username zoomacrymosby) asking what I could do to help worldbackupday.net go live as soon as possible and/or if we at SpiderOak could offer the users some specials to further draw attention to the site and reinforce the importance of backing up / syncing / sharing / accessing pictures, music, movies, documents.

Over one weekend everything came together. With the website designed, content created, and hosting established, the site was live. The word was already starting to spread through Facebook, Twitter, Reddit etc…

On the morning of Monday the 28th, 100s of tweets were being sent out about #worldbackupday, the Facebook page and website were receiving 1.000s of visitors and mainstream media had picked up on the ‘news’ that there was to be a day for backup awareness, and that day was to be March 31st.

With 3-days left until the actual event I can of course only speculate on the final effect and reach of the World Backup Day initiative; however and if the early reactions are any indication, I think that a few seemingly random community members with virtually no budget* may through the help of social media, ingenuity, and drive have created one of the first spontaneous ‘yearly events’ I have ever witnessed.

And that’s pretty damn cool!

*Disclosure. SpiderOak provided the funds needed to host the world backup day website and provides increased data storage to visitors of worldbackupday.net free of charge. World Backup Day remains an impartial website aimed at spreading awareness and information regarding data backup.

To right a wrong…

There is so much to say in the early hours of this day – November 5th, 2008.
And so much has already been said about what it means to elect this new
President of the United States of America. Regardless of political affiliation,
what tendency your policies lean, or racial makeup, no American can minimize
this significance. What an amazing country – to pass peacefully from one leader
to the next – a tradition dating back to the beginning of our existence as a
collective group of people seeking change.

The founders of these United States were brilliant men. They knew – beyond
their years – that they could not speak of the slavery issue at the formation
despite understanding its importance. Correctly they assumed that it would have
been too much – dividing the country beyond reconciliation. Instead,
smartly, quietly, succinctly, they added words in our governing document to
include all men and created them equal. It was to be another 70 years before
the issue of slavery would be dealt with head on and ultimately defeated. It
would then be another 100 years of hard fought battles, struggles, bus rides,
marches, and leaders before the promises made on that day in 1865 were to be
visible nationwide.

And now, just a generation from those days in the 1960′s, five generations from
the 1860′s, many more generations from the 1780′s, the country has achieved
another milestone. Using the foundation laid long ago, proving to the founders
of the country that we could in fact be forward thinking and flexible, proving
to all those who fought and bled in our Civil War that their sacrifice was not
in vein, proving to the millions of brave souls of the Civil Rights Era that
standing up in what you believe in will always bear fruit.

We Americans now have a black President-elect. We Americans never cease to
grow. We Americans never cease to find hope in the future. We Americans proved
to ourselves and the world that we – against all odds – striving for more
than two hundred years – can right a wrong.

Baiting the Rebate

While watching the news this morning, I couldn’t help but notice the larger
retail companies getting frustrated and somewhat whiney about the slowing
economy. I suppose operating at such tight margins, subtle downturns in
spending can have a dramatic effect on their bottom line. In the quick snippet
I was watching, the larger retailers were offering incentives for people to
cash their rebate checks at their stores – ensuring this economy continue a
forward momentum.

As a child, my friends and I used to ride our bikes downtown. Not downtown
like you might imagine in a city but a little downtown that defined our
existence and freedom. There were many little stores bearing various names of
either the people who owned them (Mike’s Ice Cream), a fruit (Cherry Pit Cafe),
or a playing card (Fredrickson’s Ace Hardware). And in the mornings when we
were lucky enough to catch an episode of Mr. Wizard, we would head to the
hardware store in search of various items to complete our task for the day. It
was quaint, safe, and unique in every way.

I go back there often as my parents still live close by. However, it doesn’t
look anything like the downtown I remember. A new mall was erected on top of
the old buildings with newer stores – chain stores. Most of the places of my
youth are no longer there although a few remain and remind me of the downtown I
knew as a bike-riding child.

So what do these two seemingly disparate thoughts have in common? These
larger companies that have spread themselves throughout the country, raised
rents, squeezed mom & pop stores toward bankruptcy by offering more product
at cheaper prices through bulk buying are now upset, sad, and looking for
consumer assistance due to the presently tough economic times. So much so that
they are incentivizing consumers to spend their rebate checks (which should
probably remain unspent and saved as more difficult times are looming ahead) in
their stores.

But this, of course, should not fool us into thinking these organizations have
a new found consciousness or care about the state of our union. In fact, many
of these organizations continue to ship jobs and functions overseas. It appears
in the end, as in the beginning, it is only ever about one thing – the bottom
line. And I cannot help but think it incredibly embarrassing and unethical for
these companies to claim some sort of national interest in baiting consumers to
spend rebate checks at their stores.

As a believer in America, capitalism as a whole, and the free market economy, I
realize that squeezing out smaller players over time is prone to happen and a
natural – in unfortunate – course of events. Darwin knew from whence he spoke.
However, I can’t help but muster very little sympathy toward these big
chain-based companies as why shouldn’t they also feel the pain of hardship as
their smaller mom & pop based predecessors did before them. In this case, the
pain should even be healthy, forcing them to streamline their operations, and
perhaps some good will even come of it.

And as a small business owner – albeit of a virtual based software company – it
is tough not to root for the little guy. It is tougher, however, to imagine
that the world of my youth will be in such stark contrast to that of my
children. And thus, as if holding tightly onto hope, I continue to seek out and
shop at the mom & pop stores that remain. For sure, the purpose of distributing
these rebate checks is to stimulate economy and it flows just as well through
the registers of small shops as it does for big ones. In the end, let’s all do
some good by doing well!