Monday, November 19, 2018

How to repair a Electrolux canister vacuum with a dead head





I was generously given a Electrolux Ultra Flex canister vacuum bringing the total owned by my extended family to three.  Electrolux has since released a new model after mine was purchased.  

It sucks well, it cleans very well, it's decently quiet, fantastic on pet hair, it's great on stairs, and the vacuum itself is easy to clean.  

Overall, it's probably the best vacuum I've ever used, except one has had a few issues.  The clip for holding the wand upright broke, the retractable cord doesn't stop recoiling forcing me to use a clip on the cord when vacuuming, and worst of all the the head stopped working after a few months.  No lights, no roller.  The first two issues aren't a deal breaker, but a dead roller is a show stopper. 

I troubleshooted to an electrical issue where the detachable hose meets the canister.  The electrical collar had a bad connection.  I attempted to clean it of any debris but that didn't seem to help. 

I called Electrolux and they sent out another hose assemble with no problems.  After a few weeks the new hose died as well.  Since two hoses had died and Electrolux just released a new model I figured there was a design problem with the older model I owned.  At this point I decided to fix it myself. 

A few warnings:
  1. This is an electrical modification and you should know what you are doing.  
  2. The canister collar will no longer be able to spin.  This is a hard wire fix.  If this isn't suitable for your vacuuming style, you will need to find another solution.  This isn't really a concern for me.  
  3. Make sure this is the issue.  It was easy for me because I could interchange parts with other vacuums.  Also by wiggling the hose or holding it down it was obvious there was an issue with the base of the hose.  
Materials:
  • Wire cutter
  • Wire stripper
  • Phillips screw driver
  • Three 1/2 stainless steal screws
  • Small gauge electrical wire insulator, like shrink tube or electrical tape/paint
  • Drill with a small drill bit.  
Instructions:
Open the collar port.  There's a single black screw to do this.  Then gently slip the outer collar from the inner.  An o-ring might slip out.  Be sure not to damage it or loose it. 



Slipping off the outer collar reveals two copper rings.  Removing the copper rings reveal the wires connected to the hose.  Cut the wire off the copper ring (and be sure not to cut the wire off from the hose!). The wires under the copper ring are bare and you will need to be insulated.  Put the o-ring back and slip on the outer collar feeding out the two wires attached to the hose.  

Now you're ready to hard wire.  The collar port contains two wires that attach to the main canister body.  Wire the black to black and white to white.  Use an insulator to make sure there's no bare wire that could short circuit.  

Now that it's hard wired, the collar _must not_ spin.  I drilled three small holes from the outside and used 1/2 inch stainless steal screws.  This will stop the base of the hose from spinning so that the new hard wired solution won't be ripped out. 



Finally, slip the collar port back on and attach the black screw.  That's it!  If you've had this problem like I've had with two of mine, that should fix the issue. 

Click here for an Amazon link to this vacuum. 

Happy vacuuming! 

Friday, September 21, 2018

Gravity Wells are Sombreros


You've probably seen an illustration of a gravity well, something like this:
Or maybe you've seen one with Earth like this image:


These illustrations work fine for distances far away from massive bodies, but close this is an inaccurate picture of how gravity works. Xkcd's well known depiction relates planet radius to gravity, but this doesn't show how gravity works in the region of a massive body.

What do gravity wells look like near massive bodies? To illustrate, let's envision an empty area of space with a one light year radius and a single celestial body, something like Earth, in the center.


In this miniverse where is the least gravity and where is the most?

Based on the traditional depiction, the edge of this miniverse would have the least gravity and the center the most.

Now let's consider Earth. Where is the most gravity in Earth? Could it be the Dead Sea, the North Pole, the Mariana Trench, or Mt. Everest?

No, the most gravity experienced is almost 3,000 km below Earth's surface about halfway to the core. The least gravity would be the center of the planet. Consider this graph of Earth's gravity according to the Preliminary Reference Earth Model (PREM).




The points of both the most and least gravity are below the planet's surface.

The answer to our previous hypothetical miniverse was wrong. A miniverse with an Earth like mass would have the point of least gravity at the center of that mass and the area of most gravity would be below the body's surface.

To match traditional gravity well depictions Earth's gravity graph can be flipped so that low gravity is up and high gravity is down. Mirroring the graph then shows a path down to the core and back up again. The result is a sombrero gravity well cross section of Earth's gravity. Note the highest point in our gravity well, the point of least gravity, is inside of the planet and not on the edges. The edges will approach zero gravity, but will not reach it.


This also means the least gravitational time dilation in close proximity to Earth would be at the center of the planet. As long as no other body interferes with the gravity well this holds true as far out into space as the body is old.

To match the traditional 3D depiction, Earth's gravity well would looks something like this.


Gravity wells are not just dips, they are shaped like sombreros.

Wednesday, March 21, 2018

It's JOSE, not JWT (A Pedantic Complaint)

You might have heard about JWT's, but the JWT specification is just about claims as a payload inside of a JWS, which is apart of the JOSE specification. 

In a small series of RFC's, 7515 to 7519, JOSE (JSON Object Signing and Encryption) is defined as a standard that uses cryptographic functions for communication across applications using JSON.  JOSE is an effort to modernize a hodgepodge of standards and provides a basic framework for future cryptographic applications all while using the popular and familiar JSON standard.  JOSE isn't alway concrete with its recommendations and instead sometimes prefers basic guidance for applications seeking a starting point.  JOSE is a needed and welcomed addition to a long history of web standards published using the Internet Engineering Task Force RFC process.  
JOSE is broken into two specifications.  JWS (JSON Web Signature) is for signing and integrity protection.  JWE (JSON Web Encryption) is for encryption.  For some undivined reason JOSE's introduction resulted in much of the web referring to the whole standard as "JWT" (JSON Web Token), a small section of the larger standard.  Perhaps it's because of the novel way JOSE was popularized on the web with cookies.  JWT claims used in cookies can free servers from remembering session information by trusting the cryptographic signature, originally signed by the server, provided by the client.  This novel usage is a small part of a much larger standard, and even this usage highlights the power of JWS.  There's nothing special about JWT in a generalized case, as it is simply just a payload.  
Perhaps the name "JWT" is popular because of the way JOSE introduced itself in its RFC's. The first RFC in the series concerns JWS and doesn't really explain what JOSE is.  Instead the reader is told a JWS header is called a "JOSE header" and that everything else, its payload and signature, is called a "JWS payload" and a "JWS signature" as one would expect.  Why would only the header be named "JOSE"? The reader using these clues is initially left to infer JWS is a subset of JOSE.  In later RFC's JOSE clearly becomes the given name for the standard as a whole.  For example RFC 7520 is titled "Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE)".  This is also made evident in drafts which include JOSE in the name as it is the name of the IETF working group.  This information is lost to readers new with the final publishing.  
Now back to JWT, a JWS or JWE encapsulates JWT.  The JWT specification notes that JWT's are just claims in a JWS.  
   JSON Web Token (JWT) is a compact, URL-safe means of representing
   claims to be transferred between two parties.  The claims in a JWT
   are encoded as a JSON object that is used as the payload of a JSON
   Web Signature (JWS) structure or as the plaintext of a JSON Web
   Encryption (JWE) structure
JWS is the real star of the show for most web applications, and all these pieces fit together under JOSE.  

Tuesday, March 20, 2018

Proof of Credit - Part 2 - The Future Economy of The Free Internet

Under construction!

Proof of Credit - Part 1 - Problems of ICO's

Problem: Cryptocurrency funding is backwards.

It's hard to fathom a future where cryptocurrencies are not foundational to advanced economies.  Cryptocurrency can excel humanity into a bright future, but initial coin offerings (ICO's), and other funding models that reward resources before establishing quantifiable market value, are inefficient.  ICO's are the wrong tools for efficiently advancing humanity.  
For starters, ICO's:
  • Reward speculation before proven utility.
  • Maintain mostly pyramid funding structures.
  • Prey on investor ignorance.
  • Provide poor means of recourse in event of poor performance or broken promises.  
  • Pollute value signaling infrastructure from efficiently allocating resources to truly valuable projects.  
  • Lack metrics which invariably results in inefficiency.  
Risk isn't a penance endured ensuring ascension to wealth.  Risk is for suckers and should be avoided.
More grievously, It's immoral to justify greed with another's gambling problem.  Platitudes like "it's a free world" doesn't imbue individual action moral when preying on ignorant individuals.
Risk anywhere in the cryptocurrency ecosystem harms the ecosystem as a whole and inhibits future capital from entering the system.  Lowering risk is a sign of maturing and efficient ecosystems.   The cryptocurrency community's solution in raising funds cannot delegate risk to large, inexperienced communities while maintaining maximal benefit.
We also cannot defer investing advice to so-called experts and prophets who have always proven dubious in allocating resources.  We should never trust such mystics in corralling larger audiences into sound investments without empirical proof.  
In short, we must do better than the ICO funding model.  
The problem is simply said: We have a measuring problem.  It's nearly impossible to predict the utility of human action.  We don't know how valuable newly created services are, thus we don't know how to efficiently allocate sufficient resources to valuable services in large lump sums before proven utility.  The Enlightenment taught humanity that measuring is our objective friend and serves as the foundation for future progress.  
Excluding ICO's and considering the rest of cryptocurrencies' tools in our arsenal, can we better measure the value of services and efficiently allocate resources?  

The Human Solution: Exchange

The proven means humanity knows to solve generic value measuring problems is exchange.  The more knowledge garnered from exchange the more measurable value becomes.   The diverse voices of a market through exchange are our best known means of resource allocation and value discovery.  An open, honest, efficient, and transparent market is humanity's highest reflection of the realities of intricate economies.   If these systems work correctly and allocate reasonably, human labor becomes more efficient.  As human labor becomes more efficient the whole world becomes richer.  
The cryptocurrency community's first goal should be solving this measuring problem.  The century old tool we have to solve such problems is exchange.  
A market judges a business's value by understanding its quantifiable features.  Traditional institutions do this with metrics such as price to earnings and price to sales.  The cryptocurrency contribution to service value measurement is tokenizing services which provides higher resolution insights over Wall Street traditions.   As business functions are identified and tokenized, a market can judge objectively service value.  This enables investments to choose with greater precision.

Proof of Credit

Any future solution should follow a few principles:

  • -As a service's value is proven, its total value, its "market cap", should expand through the expansion of useful services.  
  • -An expansion of services should be accompanied with an increased issuance of tokens representing work done by services. The service's token's value should expand proportionally to the the increase of useful work.  
  • -An overvaluation of a token should directly result in the expansion of the service so that the service utility and token value reach proper market equilibrium.  Inversely, an undervaluation should result in the contraction of the service.  
  • Services must not raise extravagant sums of money before market proven service value.  
  • -A crypto token's value should not depend primarily on speculation.  
  • -A crypto token's value can be backed by services that consume the service tokens.  
  • -Value is relative.  Service tokens must be transferable and tradable.  Trade enables relative value discovery.  
The concept of creating tokens when completing a discrete service is what I'm calling "proof of credit" (PoC).  In PoC, service token value is not established before bootstrapping a service.  Instead, a service allows the market to price the value of tokens generated by the service.  The "credit" part refers to tokens issued by fulfilling services.  The agent completing a service, the worker, would receive a token as a credit. This credit can be used for future services that consume the token.  
For those familiar with Bitcoin's proof of work (PoW), proof of credit would aim to replace the issuance function of PoW with the action of service.  Unlike ICO's with PoW, where users horde tokens in hopes of future utility, a PoC ecosystem would motivate users who perceive a service as valuable to assist in fulfilling valuable service.  If a service can appropriately reward effective service fulfillers (aka "workers"), service fulfillers would be incentivized in expanding services.
Under the current system of ICO's, token are largely created before establishing that token's service, which leads to while speculations unrelated to real world utility.  Worse, under Proof of Work, tokens are created using indirect means, vast hashing farms in the case of Bitcoin, that have little to do with the function of the service itself.  
Why can't services issue tokens at the time of completing services?  Tokens created by the act of completing a service then would be backed by the utility of future functions by the service itself.  

Friday, March 16, 2018

Mormons, Polygamists, and Evangelicals: My Experience with the iWorks Scandal

Mormons, Polygamists, and Evangelicals: My Experience with the iWorks Scandal

In late 2008 I moved to Ephraim, Utah in the Sanpete valley for a few months one year after graduating from high school.  
I lived in the second story of a coffee shop caddy-corner from Snow College in what was once an old polygamist house. To quell any doubt of its history, the owner loved showing guests a false wall in a bedroom revealing a secret space, furnished with a small wire bed, where a polygamist hide wives during US marshal inspection.
“It’s Mormon forbidden but good!” the owner would jest pitching a cup of coffee. The shop was run by a determined group of evangelical Christians aiming to provide diversity in the homogeneous Mormon environment to the young student population attending Snow. There were Mormon church buildings every few blocks in the Mormon grid-planned city and the coffee shop was one of the few non-Mormon religious groups in the region. I was personally ex-Mormon having determined Mormonism wasn't for me at a young age.  I had become acquainted with the coffee shop years previous by chance on a MySpace page.  I moved to Utah with the hope to learn more about Christian ministry targeting Mormons as I had hoped to eventually to enter ministry.  My Mormon childhood had exposed me to enough religion to think ministry was my best chance at having a positive impact.  I planned on finding work and being apart of the coffee shop efforts.  This "internship" would be apart of my schooling.

Polygamists

Ephraim sits an hour south of Provo with large stretches of open valley and farms between. During my first trip to Provo. A few large white buildings caught my attention.
“Why are there hotels out here in the middle of nowhere?”
“Those aren’t hotels,” a friend replied. “Those are polygamist homes.”
Once a friend whispered at the Walmart in Ephraim while pointing their nose inconspicuously at the checkers, “They’re all married to the same man”. I later confirmed that indeed all the checkers there that night had been married to the same man.

Gays, Google AdWords, and an Illegal Alien: The iWorks Whirlwind

As a broke 19 year old, a call center selling Internet products was the most appealing employer in the Sanpete valley.  After a short interview I was hired.  They noted my Coloradoan accent was perfect for the job.  My calls were related to Google educational products.  
My first shock came shortly after being assigned a desk. I was at the end of a row and only had one person next to me.  
“Next week is my last week”. The young woman who sat next to me said. “They found me.”
I raised my eyebrow with obvious confusion. “They found you?”
“I get deported next week. I have no family in Mexico, I don’t know Spanish, and I’ve lived here my whole life. All I’ve ever known is Sanpete. I don’t know what I’m going to do.”
I never would have guessed.  She was a perfect, respectful, hard working American.  She told me she was brought to America when she was only a few months old.  She was gone the next week and was perhaps 20 years old.  
Many of the managers were apart of a relatively liberal polygamist group in Manti with some managers even married to the same men. Many of the workers were a part of another polygamist group in the valley. There were also a few Mormons and a handful of non-Mormon Christians.  
The first week on the job my supervisor told me, “Management likes you Zach. I overheard one of the managers saying, ‘His voice is as smooth as butter.’” Before the end of my first week, my metrics were outstanding.  I was a young kid who had loved everything computers and spent most of my free time playing with Linux.  I was able to manage their workflow intuitively and my metrics showed it.  
Later, in a private closed door review, that same manager said with a thick Sanpete accent, "Your voice is as smooth as butter.  If I wasn't married I'd snatch you right up."  She was at least a decade or two older than her sister wives and perhaps double my age.  I was 19 at the time.  "Was she just horney?" I wondered.
The overseas call center was on a Filipino island and we were told that not only were all male Filipino employees gay, but in fact, the whole island was gay.  Was this the biased perception of the polygamist management or a poor retelling of a poem by Sappho of Lesbos?  The truth stayed hidden as I never dared to ask our Filipino coworkers directly, but they were very friendly and overjoyed to talk with Americans.  
“Hi sir Zach! It’s so good to hear you, sir Zach!” I would hear ecstatically many times a day. We would laugh at their cheerful insistence on always calling us "sir".  

Gabe

One of my roommates was Gabe, an ex-Mormon like me. We meet before during my previous summer visits to the Sanpete Valley and always enjoyed his cheerful company.

Gabe was in need of work, but had terrible seizures from neurosarcoidosis at night.  Sleep proved a difficult burden to overcome in holding a day job. He had been let go from various places around the Valley who saw Gabe as flaky and undependable.  As his roommate I knew the grimmer reality of his condition.
iWorks was in desperate need of help and I asked them to hire Gabe.  I explained his condition and they were willing to deal with the unexpected absences Gabe’s seizures caused. “Show up when you can and we’ll pay you for that."

Scandal Uncovered

One day a Filipino employee transferred a call to me. Normally there were no issues as we would issue refunds reasonably liberally, but this particular customer insisted on speaking with a supervisor despite a full refund. As English speaking Americans, most American positions were “supervisors” of the overseas staff.
“Here’s the link to the signup page”, I said to the customer.  
They responded, “No. this was not the link. I signed up on a different link.”
"This is the link I have sir."
“No, you are wrong. I read everything thoroughly. The page promised not to charge my credit card” They said stressing every syllable. “Please, find out what they are doing and stop them from hurting people.” They paused to convey their express intent.
“Get to the bottom of this and stop them from hurting more people.”
I was moved by the genuine plea for correctness so I started to search.
iWorks had given us a large list of links to all the company’s products. During training I had also seen a map of “target regions” which was the contiguous United States with the glaring exception of Utah itself. iWorks did not sell products to Utah, and appeared to exclude Utah from its AdWords campaigns. I had always thought this was strange, so I searched Google for terms related to our products over a VPN to outside the state. Google products, health, supplements, fitness and weightloss training, and “acai berry”. I quickly found an ad for one of our product pages.
He was right. The page iWorks showed to customers was totally different from the links given to employees.   The only way we would have discovered this was by using an Internet connection outside of the state.  
Nearly identical to the links given to employees the customer facing page explicitly promised to not charge after the trial period. The page the employees were given said exactly the opposite. The link the company provided in emails and to employees was purposely deceitful. Management had been purposely deceiving employees with false pages which we were then giving to complaining victims. Even more concerning, from my workstation I could not access the URL, but it worked fine over the VPN. They were purposely blocking links inside the building and perhaps from IP addresses in the state. Even if a customer had sent us a link, employees would never have a way to view it, and would assume the customers were wrong. No outside emails were allowed.  There was little chance an employee could ever see a screenshot and even then, how would they know it wasn't doctored?
I immediately reported this to my supervisor, wrote an email to management, and quietly spoke with the trusted friends I had in the office.
“I’ll issue refunds to everyone who calls in!” Gabe exclaimed when I told him my discovery and showed him the links.
“You'll probably lose your job, Gabe.”
“I don’t care, this is wrong. I’m giving everyone a refund that calls in. I won’t let them cheat old grandmas like this!”
I was happily stunned at Gabe’s fidelity. This was the only job Gabe could hold in the valley, and he didn’t give it a second thought. He refused to do anything wrong. He refused immoral compensation.  There were others in the call center that felt the same way.  
One of my other friends was not so gallant.  “I can’t lose this job. I have to provide for my wife. I’ll just do what I’m told and trust that it’s okay with God.”  I was disgusted with his appeal to God to bless  willing compliance. He was able bodied, mobile, and could find work elsewhere if it came to that.  It was a final blow to a strained friendship and was a stark contrast to Gabe’s intrepid commitment to justice.  This friend was one of the reasons I had been living in Utah hoping to learn more about ministry.  Without a strong sense of morality, I didn't desire to work with them on any future endeavor.

Coverup

I got a message from my supervisor the next day. “Management wants to see you.”
“It’s been fun.” I thought as I entered the manager's office.
“We’ve been impressed with your performance Zach. We are promoting you and giving you a raise, a bonus, and making you a supervisor trainer over one of our new programs.” My mouth dropped. I had only been there a few weeks and they were planning on promoting me?  Did they not notice the volume of refunds we were giving?  Our meeting was short, and as I was leaving, she remarked, “Oh and one more thing, about your email, we’ve fixed the problem, thank you for bringing it to our attention. It was a mistake from one of our old, out of commission sites. We’ve taken it down, and we'll be sure that we'll make it right with the few customers affected who signed on from that page.”  I checked that night at home, the secret pages I had found were removed. Just maybe it was a genuine mistake.  My new duties removed me from working with customers or product links directly and I wondered if this was the reason for my promotion.   Regardless, if they tried it again, I would stay vigilant.  
In a couple weeks iWorks release a new acai berry product. Again, I searched Google for terms related to our products over a VPN.  Again, I found landing pages purposely omitting charge information and promising customers that they would not be charged.  The copy distributed internally that had been given was the exact inverse with explicit information about credit card charges. Again, employees could not access customer URLs from inside the call center.  This was definitive. These pages were new for the new products. This was the final nail in the coffin. They knew exactly what they were doing. They were purposely lying to their customers and charging millions.  
I told everyone that would listen to me in the call center and showed them printouts of my proof.  I wrote another email to my previous supervisor and CC’d management and I turned in my resignation.  I felt like I had little reason to stay so I left Utah in the beginning of 2009, moving back to Pueblo, Colorado, my home.

Conclusion

I regret not whistle blowing, but as a 19 year old I didn’t understand the full depth of iWorks deceit. I didn't know whistleblowing was a thing. I didn't know what they were doing was illegal as they had the blessings of the banks and credit card companies.  I only knew what they were doing was morally wrong and I wouldn't be apart of it, just like Comcast's attacks on net neutrality.   Thankfully, Jeremy Johnson, the owner of iWorks, was rightfully sentence in a federal case in what is being called the “biggest political scandal in Utah history”.  I hope he's removed from doing any harm for a long time.  
My friend Gabe, 31, of Ephraim, Utah, passed away unexpectedly on October 15, 2014 from complications with neurosarcoidosis.  I will never forget Gabe's commitment to doing the right thing in face of the vacuous unknown.  

Friday, February 9, 2018

Do not use git's built in gpg signing until git uses something other than SHA-1

If you trust SHA-1 and think it's secure then this post isn't for you.

If you think SHA-1 has been weak for years, is not sufficient now, and is dangerous moving into the future, this post is for you.

Git's online documentation describes how to sign a git commit.
$ git commit -a -S -m 'signed commit'
The massive elephant in the tiny git security room is that SHA-1 is no longer considered secure, and has been considered weak for a long time (about 13 years).  Bruce Schneier warned in February 2005 that SHA-1 needed to be replaced.  Git development didn't start until April 2005.  Before git had started developed, SHA-1 was identified as needing to be deprecated.

When signing a git commit using the built in gpg function the project is not rehashed with a secure hash function, like SHA-256 or SHA3-256.  Instead, gpg signs the commit hash directly.

And yes, this commit hash is still a SHA-1 hash.   It's not signing the result of a secure hash algorithm.

A signing algorithm is only as good as its weakest point.  Just because something is signed doesn't make it magically secure if the underlying hash algorithm is insecure.  Worse, if a secure hash algorithm, like SHA-3, hashes the result of an insecure hash algorithm, like the git commit hash, the result is still insecure.

To make signing git code secure, you must rehash everything, the whole project, with a secure algorithm before signing.  This however is not yet standardized in the git world.  Anything you do securely will not be relevant for existing git infrastructure.  Go ahead and sign you code using something secure, your square peg won't fit into git's infrastructure yet.  Anything secure you do will need infrastructure over and above git to ensure your project is secure.

Git is moving to support secure hashes, but it's not adopted yet.  Even when it is, it will take time for the infrastructure to catch up.

So what's so bad about signing a SHA-1 hash?  If an attacker finds a collision they can have two copies of a repository, a good version and a bad version both with the signature's blessing. Google's security blog has better examples, but for simplicity:

              SHA-1 ( good code )     = hash123
              SHA-1( hacker code )   = hash123

If the hash "hash123" is signed with with git's built in gpg functionality, not only is the signature valid for "good" code, but it could be valid for "hacker" code.  Developers on the other side of the wire must have systems above and beyond git that prevent such attacks.

A malicious agent can commit a "good" version of a repo, wait until the commit is added to security sensitive repos, and then push the "bad" version.  Bingo.

With specific commit hashes you cannot verify the the version you are building in production is the exact same code as the one a security team audited prior to release without trusting systems external of git.

Alternatives?  Don't use git's built in gpg signing functionality.  Instead, compress your repo and sign the resulting file manually.  Anyone on the other side of the wire will need to familiarize themselves with this process, manually verify, or use a tool outside of git to verify.