1. 4

    I can’t look at this teardown without hearing AvE in my head.

    1. 3

      I’ve just sent him the link. Let’s hope he decides to do a review of this magnificent example of overengineering.

      1. 4

        Don’t forget to put your ____ in a _____!

        1. 2

          Skookum as frig!

          1. 1

            Milled aluminum choochers!

            1. 1

              Same here! I can’t help but feel AvE would do a much better teardown, not only looking at what’s there right now, but considering what’s blatantly missing from this article; what can be improved in the future! If those are machined gears then there’s no reason they can’t cut cost by sintering. The article says it’s so expensive to apply “thousands of pounds of pressure” completely ignoring that any home-gamer clamp can do the same.

              It’s still an over engineered and expensive clamp, but I feel like the article is dishonest about where it is and where it can go.

              1. 3

                A lot of these “unnecessarily machined” parts look to me like they were designed for casting but the tooling wasn’t ready for the scheduled first run (typical). They would be a lot cheaper in mass production.

                The gears are OEM, they are not that expensive when you buy them by the thousand. You’d need to sell a lot of juicers to break even on sintering tooling for them (and machined gears are stronger), doesn’t make sense for a commodity part.

                Overall I refuse to believe that the engineers who had enough skill and experience to design this and get it working are so blissfully unaware of production process costs. Simply doesn’t happen IRL.

            1. 2

              I’m curious if a locked down CSP Header would help prevent sites from being exploited, although I guess it would depend on where the JS got loaded from. If the attacker was able to get malicious JS served from the site or an approved origin then this would still be exploitable.

              1. 1

                It would certainly reduce the attack surface. I think using something like uMatrix is also a good idea.

              1. 47

                When someone makes a typo there are 2 possible outcomes. Outcome 1: they are informed of their error and they can correct it or make an alias in their shell. Outcome 2: npm grows a new help option for every reported typo and eventually begins calculating the Levenshtein distance between the nearest valid option (an actual suggestion in the issue). Eventually typos make it into source code and scripts. Good luck grepping your codebase for usages of npm install.

                Introducing this “affordance” to the user results in a cascade of increased complexity. Furthermore it’s not “just” complexity in the toolset, but an increased cognitive load on the programmer. What’s next? I can only imagine how frightening using node would be if npm install package installed some other random package off the internet.

                Please keep “did you mean” functionality limited to search UIs.

                1. 13

                  I guess if the user has such a problem with accidentally typing “npm isntall”, “npm unisntall” or “npm verison”, they should just create aliases in their own shell config instead of bloating the software.

                  1. 3

                    Good luck grepping your codebase for usages of npm install.

                    This is easily fixed by making grep default to matching on small Levenshtein distances too! (Yes, this is sarcasm.)

                    1. 2

                      Well, it probably wouldn’t be so hard to extend regexes to compute a Levenshtein DFA during the compilation stage for fuzzy matching.

                      [Is it bad that I’m wondering how hard it would be to implement, as a fun regex hack?]

                  1. 17

                    This is a good complaint, but I think we need some suggestions on how we can convince programmers to be less stupid, because telling them to be less stupid just isn’t working.

                    1. 4

                      Use tools with less features and more interoperability. Fork complicated projects and rip out useless features and call it “Lite/Secure”.

                      1. 4

                        Alas, interoperability is often itself a problem.

                        1. 1

                          In what way? I thought do one thing well was all about delegating out tasks to programs which have devoted the time and energy into being secure. Could you please elaborate?

                          1. 7

                            The “delegation” is itself a potential vulnerability. That’s not to say it has to be, but once tools can interoperate, people expect them to interoperate, and that causes trouble. Consider the venerable less program, which can execute dozens of not entirely secure helpers. They are each individually vulnerable, but less, through the powers of delegation and interoperability, has found a way to become the sum of their vulnerabilities.

                            http://marc.info/?l=full-disclosure&m=141678420425808&w=2

                      2. 3

                        Well, the funny thing is that while we can create tools to enforce security with an application (that is, to make sure an application is doing what it wants to do correctly, without introducing security holes), it is harder to restrict ourselves as programmers to stop our tools from growing options outside of their original scope (that is, to make sure our applications do only what they should do, from a philosophical perspective).

                        Both of these are security problems, and it’s something people try to get at with the term “attack surface.” When you add options, or add semi-out-of-scope convenience features to applications, you also increase the complexity of verifying the application is free of security flaws, and you increase the likelihood that some interaction between the application’s components or between the application and other applications will introduce security flaws.

                        All of this is to say that I don’t know if there is a way to do this that’s any better than teaching people, through hard-learned examples from history, that there are right and wrong ways to do this. If we start to view security flaws like failures in civil engineering, covering them in education with case studies and discussions of what went wrong, and with real care for pre and post deployment review of correctness and failures, then we might start to see things improve. In this light, something like Heartbleed becomes the Tacoma Narrows Bridge collapse. Something we teach new developers about, not just for the specific lessons of the failure, but the learned wisdom of how to avoid the same mistakes in a systemic fashion.

                        1. 2

                          Thinking of a list of non goals (e.g. https://github.com/martanne/vis#non-goals) at the beginning of a project sure helps.

                        1. 11

                          I’m brazilian.

                          The first case I remember of this happening was in 2007, when a brazilian actress was filmed having sex in a beach in Europe and that video was posted to YouTube many times. She sued (in Brazil) and some judge took YouTube down for one or two days.

                          At the time (if I remember correctly) it was implemented as some sort of DNS change, and those of us that used custom DNS servers could visit the site. I was able to help a few of my friends.

                          This time the WhatsApp servers seem to have been blacklisted. I’m not sure about port blocking or packet inspection. It was most likely a small change just to block the majority of the population that doesn’t know how to circumvent.

                          It is also interesting to remember a few facts:

                          1) The cellphone service providers in Brazil (Oi, Vivo, Tim, Claro) are also the largest fixed internet providers for the country;

                          2) These companies have seen a lot of profits vanish due to the overwhelming use of WhatsApp by the users (titles were translated by me):

                          Why brazilian providers are in war with WhatsApp http://epocanegocios.globo.com/Informacao/Dilemas/noticia/2015/12/por-que-operadoras-brasileiras-entraram-em-guerra-contra-o-whatsapp.html

                          Brazil loses 10 million cell lines due to ‘WhatsApp Effect’ http://link.estadao.com.br/noticias/empresas,brasil-perde-10-milhoes-de-linhas-de-celular-por-culpa-do-efeito-whatsapp,10000028765

                          To stop WhatsApp, providers ask for conservative regulation http://www.tribunadabahia.com.br/2016/01/02/para-frear-whatsapp-operadoras-pedem-regulamentacao-conservadora

                          Providers have lost US$ 13.9 billion due to WhatsApp, Facebook Messenger and similar apps https://tecnoblog.net/91908/operadoras-whatsapp-facebook/

                          3) These same companies own the majority of market share for cable TV and were recently pushing HARD for data caps to prevent YouTube and Netflix from stealing more profits from them;

                          I wouldn’t be surprised if this judge turned out to be friends with some of those companies.

                          I’m not too familiar with the US market, but I think this corporativist agreement between large companies and the State is a problem we all we’ll have to deal with if we want the Internet to stay (relatively) free.

                          1. 8

                            Great time to announce, right after their recent twitter rampage. Inspires lots of confidence.

                            1. 2

                              Careful or you might get blocked.

                            1. 8

                              Guess I won’t be using grsec anymore.

                              # pacman -Rs linux-grsec linux-grsec-common linux-grsec-headers
                              
                              1. 2

                                Just because of some grumpyness on Twitter? Man, I hope for your own sake that whomever supplied the locks on your doors never gets grumpy.

                                1. 33

                                  If the company who made the locks on my door blocked a bunch of people who retweeted “hey, these locks open right up if you stick any old key in upside down” it’d sure as hell make me reevaluate my opinions of their approach to making secure locks.

                                1. 12

                                  Eldritch.

                                1. 5

                                  I’m going through CIS 194: Introduction to Haskell. Loving it so far.