13brane

GSF is required to extend battery life, and other lies we're told while our data is slurped

Mon, 09 May 2022 12:00:00 -0400

The path to complete digital sovereignty is lonely, long and difficult. Sometimes, it is also fraught with improper signage.

Exhibit A, shown above, is a screenshot. It was taken on my recently degoogled 2017 Samsung A5. A decent device at a decent price, acquired from a refurbisher to replace my old and worn S5 Mini Duos. The only shortcoming that cannot be overlooked on the A5 is the lack of a user removable battery. Otherwise, it fits my current needs, and it runs well with LOS 18.1.

In fact, it runs so well that I see no need for setting the performance profile to anything other than “Power save”. In this setting, as seen above, it is possible to obtain up to a week of standby with this device (though 5-6 days is more common).

You’ll be forgiven for thinking that I have published a rant for the sole and explicit purpose of bragging about battery life on a used Android phone. Impressive as it is without resorting to Samsung’s Ultra Power Saving, the reality is that I don’t use my smartphone very much these days. When I said standby, I really meant standby. The thing mostly just sits there waiting for calls and Signal messages. For a mobile phone, it is quite fixed. For a smartphone, it feels quite dumb.

Back on topic. The real purpose of this rant is to alert the readers to the fact that they are being lied to.

This phone has no GSF installed on it. It cannot run anything from the Google Play Store. It cannot use the Push Notification APIs. Both instant messaging apps, and both email apps which run on this device run in the background constantly. You would think, judging by Google and Samsung’s propaganda, that battery life on this device, in it’s present configuration, would be miserable. Far from it. I’m fetching a chair so I can wait comfortably for a screenshot of a similar device with better battery life running GSF. Or more specifically, a screenshot of another A5 2017 with stock ROM or LOS+Gapps, in any power profile other than Ultra Power Saving, which lasts >6 days standing by without any special tomfoolery beyond selecting which apps run in the background and which apps don’t.

You have been bamboozled. Requiring apps to go through GSF rather than allowing them to occasionally run in the background is not about energy efficiency. It’s about money. It’s about having all your apps funnel that cherry sweet unique device identifier through someone’s servers so that your personal profile can be more effectively sold to advertisers. It is about having GSF on the phone so that it can call back home to it’s masters with data points which are exceedingly hard to harvest otherwise. The hilarious part is as follows: spyware needs energy to call back home.

You have three choices right now. Accept that your smartphone will never be yours and that it will always serve another master first, compromising your privacy at every chance it gets; put in absurd amounts of work to obtain a device that’s only close enough to the ideal of a machine which serves you and only you; or forego this sociopathic hellscape and ditch the monitoring device altogether.

I have no intention of repeating the process required to bring a smartphone in line with my privacy and general usage tastes. As such, I have decided that this device will not have a replacement. When this A5 dies (or I decide to decommission it, whichever comes first), I will not have another smartphone. These devices are currently built under the assumption that information about your life is fuel for the ad machine. My interest in being an active participant of this contraption dwindles.

A suggestion to the readers is to consider the trade-offs that come with owning a smartphone (or not) and make a decision right now, as you may not be able to decide for yourself past a certain point. For my current situation, the optimal spot seems to gravitate around the concept of a “Landline++”, where I am reachable in more than one way through the same device, and I can definitely make full use of the smartphone’s capabilities if I so choose, including the ability to temporarily take it somewhere else or use it as a small computer, but it’s been a long time since I was under the illusion that I need to carry this thing all the time or be within two arm lengths of the rectangle to stave off the impromptu visits from the void.¹

In a slightly unrelated note, keep in mind that if Google, Apple and Microsoft have their way, you will not be able to log in to anything, even through your web browser, without having your tracker next to you. When the time comes, we’ll need enough people saying “I don’t own a smartphone” to justify the pushback against this “more secure” standard of authentication and prevent this type of nonsense from becoming the new normal. Remember when telephones were optional? Yeah, good luck going back to that if you don’t want to be bothered about it.

Your devices should serve you, not the other way around. And they certainly shouldn’t serve anyone else. Refuse mediocre solutions for problems which did not need to be solved in the first place.

try this: remove all purely for-entertainment apps (games, tubes/streaming, and any other time-killers) from your smartphone, and you’ll be amazed both at how addicted you are to the thing, and how little you’ll automatically reach for it a few days after the removal. ^[return]

On the matter of libera.chat

Sun, 30 May 2021 17:52:01 -0400

Or, how healthy and sane distributed organisms reject the transplantation of stupid.

You’ve heard of EEE: “embrace, extend, extinguish”. Today we’re going to look at some of its lesser known variations, starting with “embrace, smother, repurpose”.

This is what happened to CentOS. RedHat takes it under its wing, and all goes well for a while. More resources for CentOS, all pumped to deliver version 8 with support until the second coming. Except, that doesn’t actually help acquire new RedHat subscriptions, at least not directly.

Along comes CentOS Stream, which nobody needed or wanted, as the main selling point of CentOS/RHEL is its extremely long support cycle. No other free (both as in freedom and cost) distro has a support cycle of that length. A rolling release version of CentOS is as useful as wings on an elephant. Flap all you want, no takeoff will occur.

RedHat eventually pulled the plug on regular old LTS CentOS, in favor of keeping the new, RHEL-beta under a different but very well known, FOSSy brand. Which we can only suppose to be much more useful for business. One less distro to maintain, the remaining one possibly funneling stability prioritizing admins towards a cushy yearly subscription.

However, the organism rejected the stupid. Distributed organisms do this by disassembly and reassembly. CentOS is but an empty shell, something with the same name but no other resemblance to its former self. Its personality though, lives on, under other names but with the same substance.

Up next: “embrace, inject, override”.

Lee’s embrace of freenode occurred a long time ago. As for the injection, I’m not entirely sure. I avoid reading drama these days. This rant is not about the drama, but the effect.

Libera.chat is an interesting situation because the rejection of the stupid happened not at the end of the third phase but at the beginning. At the faintest smell of override, freenode (the substance, not the name), immediately disassembled. And, as any distributed organism of stature does, quickly reassembled under a different shell almost unscathed, with barely any change to its substance. The (unpaid) admins left, and one by one the channels, and thus the users, followed.

Another interesting difference between this case and the former is that unlike ex-CentOS, which is a prime example of higher level Darwinism in the sense that the new generation of spawn is inoculated against the ills that caused its parent’s untimely demise, libera.chat is more an example of a type of osmotic skin shedding, one where the skin is left behind, intact and unbroken, and most of the substance leaves the shell through the pores rather than any other large opening, eventually forming another shell for itself.

After this process is complete, all the injector can do is to keep the empty shell. To what purpose, we will see.

I would now like to draw your attention to the fact that these EEE attempts, or variations thereof, are going on all the time. The main goal of these attempts is usually consumption, and transplanted parts are almost invariably less healthy than the target organism (otherwise, there would be no upside). The corporate is hungry and these distributed organisms have juicy, healthy livers.

Or, as is the case with the FSF, they’re also in the way and being pesky. The FSF’s situation is rather curious because RMS’s ideological (and bodily, it seems) aroma makes this organism unfit for corporate consumption as is. But it has the healthiest, juiciest liver. So the main purpose of an injection here is first and foremost not to transplant, but to amputate.

There is much talk these days about RMS, the founder of FSF returning to the board of FSF and IBM refusing to have him, popular demand, vote, or otherwise.

I could list countless articles here as a detailed research on the matter, but the plethora of them TOTALLY MISS THE ISSUE.

Who decides and how is a decision made? Is it influence by rational arguments or is it a choke-hold maneuver that even his (RMS’s) dearest of friends can’t escape?

The rational argument by IBM, and their fellow mutually interested global giant corporations, is “YOU DO AS WE SAY, OR NO MONEY COMING TO YOU“.

This is what every democracy in the planet has been reduced to, every democratic process that “tolerated” money/funding to be part of the decision making process.

(from sysdfree.wordpress.com)

The corporate overplayed its injection in this case.

The FSF does not depend on large single sources of funding. It accepts and appreciates support from corporations who want to give back by contributing to the development and advocacy for free software, but direct corporate support accounted for less than 3% of FSF revenue in its most recently audited fiscal year.

(from the FSF itself)

In addition to having the healthiest liver, this organization’s immune system ended up reversing the amputation, hinting at the presence of a stellar spleen. A reversal not without consequence, but still impressive.

The issue with corporate is that it is always centralized. As such, it doesn’t quite get the nature and world of the distributed organism it seeks to consume.

It puzzles and wonders how it functions with multiple bodies, sometimes without a head, sometimes with many, and is able to appear in multiple places at a time.

It scratches its head, bewildered, wondering why the organism doesn’t readily amputate its many members which are flailing about uncontrollably, bereft of acceptance of central authority.

It gasps in awe and shock when half of the body of a recently consumed distributed organism suddenly leaves its stomach to form yet another distributed organism with an uncanny resemblance to the one which was just consumed, but with an unrecognizable name.

Nowhere is corporate’s true lack of understanding of the distributed organism more apparent than in its treatment of names. To corporate, its name is everything. All the value of a corporate is in its name.

It exerts its influence and impact in the world through its name. When the name dies, corporate almost always dies with it. So, when attempting to consume a distributed organism, it will always start with the name, assuming that is the location of the juicy innards.

But for a distributed organism, a name is but a tether point around which its parts gravitate. It will ditch its name for survival, for preference, for compliance, for shits and giggles or because it’s Tuesday.

Corporate consumes the name, and stays hungry. Please, continue. We are very much enjoying this season of Organizational Geographic: Distributed Darwinian Mechanics.

Increasing entropy

Sat, 05 Sep 2020 17:00:00 -0400

Hello again, braneswalkers. It’s been a while, hasn’t it?

I’m sorry to have kept you all deprived of large braned rantiness for such a long time. I know how absolutely crucial this is for your general well being.¹

I promise more brany nastiness in the very near future, but this one rant will be shorter than usual. It’s only purpose is to draw attention to the fact that the branes are now accessible via good old RSS 2.0.

I only know of two things which are inherently anti-entropic: the world’s money supply, and internet social media. These also happen to share two other characteristics: they are man-made and quite dysfunctional in their current state.

In the interest of simplicity and accessibility, I’m extremely reluctant to add features to this site. Yet, I’m even more reluctant to be part of the unnatural, depressing morass of corporate-vetted groupthink that gets passed around for world and democracy enhancing² discourse these days.

As the grip of big tech and governments alike around what we can find and express online tightens, and my usage of the common platforms decreases to a point near non-existence as a result, it becomes imperative to allow for other, more cosmologically aligned methods of information distribution.

Freedom of speech online isn’t dead yet, but if we’re not careful, it might need to be rushed to the ICU soon.³

The problem is simple: when you rent, you need to ask permission to drill holes in the walls. When you own, you don’t. This is a pretty sensible arrangement, and it’s motivations are very easily understood. Yet, what makes up most of the tubes today is neither renters nor owners, but couchsurfers. And in this condition, complaining is not just futile, it’s downright stupid. Don’t complain about not being able to hang stuff on the walls if the arrangement is that you sleep, for free, on the couch or the floor.⁴

There is a pill for this ailment, and it is made solely of natural ingredients. We must allow the entropy of the Internet to increase.

The real reason freedom of speech is being threatened online is the same as the reason privacy is gone: we took all our traffic, all our info, and now even close to all our lives to about two handfuls of sites or apps, which provide their services for free on the condition that we are the product. The hosts can’t have the products deciding to change their features all willy-nilly, so we must conform to the specifications provided by the host’s costumers. Specifications which will be dully enforced, even if it means “negligible” sacrifices on the part of the product.

There are many ways to stave off online censorship, but I happen to think the best ones are to decentralize and own (or at very least, rent) as much of the internet as possible. To that effect, this will be the last rant which will be tweeted (or shared by the author on any social network), and the search for a paid hosting solution which does not engage arbitrary censorship will continue.⁵

So what is this to you, dear reader? For now, nothing more than a friendly invitation to continue thinking for yourself, and reading and searching for the things that matter to you, hopefully a bit freer from monitoring and censorship. To that effect, consider subscribing to the RSS feed, optionally setting the auto-refresh to the vicinity of “every week” (13brane.net doesn’t spam). Oh, and log the fuck out, while you still can.

That’s it for today. We’ll keep in touch.

tempted to take this paragraph seriously? Please remember the part that ends with “shot of tequilla.” ^[return]
or “kind”, or “compassionate”. The most vocal people peddling this crock are also some of the most rage and hate filled bunch you’ll ever meet. ^[return]
recall that Freedom of Speech’s more reclusive sibling, Privacy, is still in a coma. ^[return]
and don’t forget to check for hidden cameras. ^[return]
while decentralization is a low hanging fruit, ownership isn’t. It’s a particularly hard problem to tackle, especially if you are aware of all the operational, jurisdictional, privacy and monetary aspects. This is readily apparent should you try to find a freedom and privacy respecting hosting provider which is also inexpensive and run by people who aren’t complete wackaloons. ^[return]

13brane's holidazed cavalcade of code shenanigans: the flavors of FizzBuzz - Days 17-24

Sun, 23 Dec 2018 12:00:00 -0500

(Full source code for the entire series will be progressively published here, and the other days of the cavalcade are here: day 0, 1-8, 9-16)

Welcome back to the last instalment of the cavalcade. This week we are going to do something evil. Something forbidden. Something so egregiously deranged it might cause uproar with religious leaders.

Lo and behold, object oriented fizzbuzzing.

Day 17

New tech lead is hired. Asks junior dev to convert the previous implementation of Fizzbuzz to OOP. Junior dev, puzzled by this request, asks as politely as possible, why the hell would someone do that. Tech lead answers with some badly strung together argument about DI and logging. Junior dev does not understand why FizzBuzz needs DI (or logging, for that matter) and continues to ask questions. Conversation abruptly ends with “Just put it in an object.”

package day17

import "fmt"

// default implementation, for acceptance test
var FizzBuzz func(int) string = NewFizzBuzzer().FizzBuzz

type FizzBuzzer struct{}

func NewFizzBuzzer() *FizzBuzzer {
	return &FizzBuzzer{}
}

func (fb *FizzBuzzer) FizzBuzz(n int) string {
	if n%3 == 0 && n%5 == 0 {
		return "fizzbuzz"
	} else if n%3 == 0 {
		return "fizz"
	} else if n%5 == 0 {
		return "buzz"
	} else {
		return fmt.Sprint(n)
	}
}

Junior dev obliges. Goes home that night, starts reading Lambda The Ultimate.

This is how we create anti-OOP fundamentalists. Tech leads, take note.

Day 18

A hip new web startup decides to create an entirely new segment of the market: FBaaS, FizzBuzz as a Service.

An MVP is launched. Seed and Series A rounds are a massive success due to the disruptive potential to the FizzBuzzing industry. We are not entirely sure how much disruption can occur to a market segment that doesn’t exist, or if it’s actually good or necessary, but it’s in the business plan, so it must be true.

In order to future proof the solution and prepare for the “exponential” growth that is expected, the core of the service is implemented as a sort of routing engine library, but for integers.

A new Silicon Valley unicorn is clearly in the making here. They have issued only 3 API keys so far, and one of those is for the CI server, but hey, who am I to give investment advice.

Hustle to your heart’s content.

package day18

import "fmt"

var FizzBuzz func(int) string = InitFizzBuzz()

func InitFizzBuzz() func(int) string {
	c := NewNumberConverter()

	c.AddRule(15, "fizzbuzz")
	c.AddRule(3, "fizz")
	c.AddRule(5, "buzz")

	c.SetDefaultRule(func(n int) string {
		return fmt.Sprint(n)
	})

	return c.ApplyRules
}

// Implementation of NumberConverter Engine

type rule struct {
	i int
	s string
}

type NumberConverter struct {
	rules       []rule
	defaultRule func(int) string
}

func NewNumberConverter() *NumberConverter {
	return &NumberConverter{}
}

func (c *NumberConverter) AddRule(i int, s string) {
	c.rules = append(c.rules, rule{i, s})
}

func (c *NumberConverter) SetDefaultRule(f func(int) string) {
	c.defaultRule = f
}

func (c *NumberConverter) ApplyRules(n int) string {
	for _, r := range c.rules {
		if n%r.i == 0 {
			return r.s
		}
	}

	return c.defaultRule(n)
}

Day 19

Established FBaaS solution. As the company grew, the scarcity of Go programmers led them to hire expats from other environments. Slowly but surely, the codebase begins to OOssify with Javaisms, and *er classes, factories, interfaces and implementations start to appear. All the things, encapsulate.

Thank you Griesemer, Pike and Thompson, for leaving inheritance out. At least that bullet was dodged.

// day19/buzzer.go
package day19

type BuzzerImpl struct{}

func (f *BuzzerImpl) Buzz(fb FBState) {
	if fb.Number()%5 == 0 {
		fb.SetState(fb.Number(), fb.String()+"buzz")
	}
}

// ----------------------------------------------
// day19/factories.go
package day19

func NewFBState(n int) *FBStateImpl {
	return &FBStateImpl{n, ""}
}

func NewFormater() *FormaterImpl {
	return &FormaterImpl{}
}

func NewFizzer() *FizzerImpl {
	return &FizzerImpl{}
}

func NewBuzzer() *BuzzerImpl {
	return &BuzzerImpl{}
}

func NewFizzBuzzManager() *FizzBuzzManagerImpl {
	return &FizzBuzzManagerImpl{
		NewFizzer(),
		NewBuzzer(),
		NewFormater(),
	}
}

// ----------------------------------------------
// day19/fbstate.go
package day19

type FBStateImpl struct {
	i int
	s string
}

func (f *FBStateImpl) SetState(i int, s string) {
	f.i = i
	f.s = s
}

func (f *FBStateImpl) Number() int {
	return f.i
}

func (f *FBStateImpl) String() string {
	return f.s
}

// ----------------------------------------------
// day19/fizzer.go
package day19

type FizzerImpl struct{}

func (f *FizzerImpl) Fizz(fb FBState) {
	if fb.Number()%3 == 0 {
		fb.SetState(fb.Number(), fb.String()+"fizz")
	}
}

// ----------------------------------------------
// day19/formatter.go
package day19

import "fmt"

type FormaterImpl struct{}

func (_ *FormaterImpl) Format(f FBState) string {
	if len(f.String()) == 0 {
		return fmt.Sprint(f.Number())
	} else {
		return f.String()
	}
}

// ----------------------------------------------
// day19/interfaces.go
package day19

// adapter for test harness
var FizzBuzz func(int) string = NewFizzBuzzManager().Manage

type FBState interface {
	SetState(int, string)
	Number() int
	String() string
}

type Fizzer interface {
	Fizz(FBState)
}

type Buzzer interface {
	Buzz(FBState)
}

type Formater interface {
	Format(FBState) string
}

// ----------------------------------------------
// day19/manager.go
package day19

type FizzBuzzManagerImpl struct {
	f Fizzer
	b Buzzer
	m Formater
}

func (i *FizzBuzzManagerImpl) Manage(n int) string {
	s := NewFBState(n)
	i.f.Fizz(s)
	i.b.Buzz(s)
	return i.m.Format(s)
}

Day 20

This one is special. Code will not be pasted inline: I’d need a new rant just for it. See it here instead.

After 12 years of operation in the FBaaS market, many developers that came and went and the realization that “exponential” means different things for mathematicians than it does for the rest of the world, the company’s codebase is fully OOssified.

There are interfaces for everything, implementations for everything, factories for some things, a manager object that does pretty much all the business logic, a DI library refactoring that someone started but clearly couldn’t finish, and even stale code that is no longer used but people are afraid to delete because of Justin Case and their selective ignorance about source control. Glorious.

This codebase has clearly reached it’s maturity and enlightenment, the peak of it’s existence. From this point on maintenance efforts will continue to increase, adding new features will become next to impossible, and there will be louder and louder calls for a rewrite. Its light will slowly dim over time, waiting for the inevitable. The much sought rewrite, or the scrapping of the entire project.

The cycle of software life. Unstoppable, unending.

Day 21

Unless you do it correctly.

Here it is, the generalized ([a-y][a-y]zz){n} algorithm, as implemented by someone extremely competent in the arts and sciences of computer bending. The type of person that refactors relentlessly until that last unneeded line of code can be removed. The type of person that reads SICP for relaxation, Clean Code for fun, and 13brane.net for a laugh.

This started out as OO code. There was a Rules(...).Apply there. Seriously. There was even a type Rules and another type Rule, of all things. But the continuous massaging of the code eventually made it shed all the extra fat, culminating in the following masterpiece.

package day21

import "fmt"

var FizzBuzz func(n int) string = Apply(
	Rule{3, "fizz"},
	Rule{5, "buzz"},
)

// DSL implementation ---

func Apply(rules ...Rule) func(int) string {
	return func(n int) string {
		s := ""

		for _, r := range rules {
			if n%r.divisor == 0 {
				s = s + r.part
			}
		}

		if s == "" {
			return fmt.Sprint(n)
		}

		return s
	}
}

type Rule struct {
	divisor int
	part    string
}

Day 22

The company referred to in Day 20 was eventually acquired by a larger and older competitor. Mostly for the IP (which turned out to be next to worthless) and domain knowledge. It is decided that the FBaaS solution will finally be retired in favor of a more traditional software delivery method and a more familiar business model.

Since a rewrite is due, the OSS code from Day 21 is pilfered with no attribution whatsoever, to build the next product with optimal time-to-market.

So, without further ado, we present, SmarTazz: all-in-one, XML configurable, abstract enterprise rules engine for all your on-prem FizzBuzzBazzing needs.

Licensing starts at $5000/yr, per node. Optional round-the-clock support contract and mass discounts available (contact sales for a quote). And of course, it crashes with a cryptic error if you feed it bad configuration, like any respectable enterprise grade software.

The rules engine:

package day22

import (
	"encoding/xml"
	"fmt"
	"io/ioutil"
	"os"
)

const CONFIG_PATH_ENV_VAR = "DAY22_CONFIG_PATH"

// FizzBuzz needs to be lazily initialized due to the use of `os.Env`.
// See test harness.
// var FizzBuzz func(n int) string = MakeXMLRulesApplicator()

func MakeXMLRulesApplicator() func(int) string {

	path := os.Getenv(CONFIG_PATH_ENV_VAR)
	config := LoadConfig(LoadConfigFileBytes(path))
	rules := config.Rules

	return func(n int) string {
		s := ""

		for _, r := range rules {
			if n%r.Divisor == 0 {
				s = s + r.Part
			}
		}

		if s == "" {
			return fmt.Sprint(n)
		}

		return s
	}
}

func LoadConfig(configBytes []byte) Config {
	config := Config{}

	err := xml.Unmarshal(configBytes, &config)
	if err != nil {
		panic(err)
	}

	return config
}

func LoadConfigFileBytes(path string) []byte {
	configBytes, err := ioutil.ReadFile(path)
	if err != nil {
		panic(err)
	}

	return configBytes
}

type Config struct {
	XMLName xml.Name `xml:"config"`
	Rules   []Rule   `xml:"rules>rule"`
}

type Rule struct {
	Divisor int    `xml:"divisor,attr"`
	Part    string `xml:"part,attr"`
}

Standard FizzBuzz configuration:

<?xml version="1.0" encoding="UTF-8"?>
<config>
	<rules>
		<rule divisor="3" part="fizz" />
		<rule divisor="5" part="buzz" />
	</rules>
</config>

Day 23

@carlosdavidepto, trying to showoff Go prowess by one-upping the l33ts, using a purely declarative approach which exploits maps instead of slices. No helper functions or if statements needed.

package day23

import "fmt"

func FizzBuzz(n int) string {
	return map[bool]map[bool]string{
		true:  {true: "fizzbuzz", false: "fizz"},
		false: {true: "buzz", false: fmt.Sprint(n)},
	}[n%3 == 0][n%5 == 0]
}

Day 24

@carlosdavidepto, solving FizzBuzz in job interviews with recruiters who clearly did not read the resume, while trying to wrap up quickly to go home for the holidays.

package day24

import "fmt"

func FizzBuzz(n int) string {
	if n%3 == 0 {
		if n%5 == 0 {
			return "fizzbuzz"
		} else {
			return "fizz"
		}
	} else {
		if n%5 == 0 {
			return "buzz"
		} else {
			return fmt.Sprint(n)
		}
	}
}

This solution is probably the simplest and dumbest (and therefore maybe the easiest to understand), but it has the interesting properties of being purely functional (no internal state) and executing exactly two branches per function call for the core logic. Except maybe on Intel CPUs. We aren’t sure what executes on those anymore.

Final Reflections

I had way too much fun doing this series.
Sometimes, doing (close to) nothing is the best course of action. The simplest change is more often than not the correct change.
Things can ALWAYS be made more complicated.
Simplicity on the other hand, has at least one limit. Unlike rational numbers, however, code may have more than one irreducible form.
Unrefactoring can be as difficult as refactoring.
Making good use of Functional Programming doesn’t require a Math PhD.
FP has a vast array of tools in it’s belt, but there’s no need to use every single one of them every time. Belt grinders are not meant for tightening screws. Use a screwdriver instead.
You can build DSLs without access to macros, hygienic or not. An XML configuration file is, in a way, a DSL.
Not everything needs a DSL, though. And there is nothing that really needs XML.
encoding/xml is so good, it almost makes you think XML was a good idea. It might even be dangerous.
Automated acceptance tests cut development time in half. Use them.

13brane's holidazed cavalcade of code shenanigans: the flavors of FizzBuzz - Days 9-16

Sun, 16 Dec 2018 12:00:00 -0500

(Full source code for the entire series will be progressively published here, and the other days of the cavalcade are here: day 0, 1-8, 17-24)

FizzBuzz is a problem that maps rather well into functional programming (at least as long as you don’t try to overcomplicate things), so it is completely appropriate that we forego all state manipulations and refuse to do anything with variables that could not be mapped directly to a let ... in ... construct.

In other words: what would happen if you got a bunch of Haskell academics and force fed them Go with a large spoon?

Answer: Much wailing and gnashing of teeth.

Day 9

CompSci 232, Programming Paradigms. Data transformations only. Student is a bit puzzled about the hype around FP, but managed to come up with something which works and is not extra contrived.

package day09

import "fmt"

type IntString struct {
	i int
	s string
}

func FizzBuzz(i int) string {
	return stringOf(buzzOf(fizzOf(IntString{i, ""})))
}

func fizzOf(a IntString) IntString {
	if a.i%3 == 0 {
		return IntString{a.i, a.s + "fizz"}
	} else {
		return a
	}
}

func buzzOf(a IntString) IntString {
	if a.i%5 == 0 {
		return IntString{a.i, a.s + "buzz"}
	} else {
		return a
	}
}

func stringOf(a IntString) string {
	if len(a.s) == 0 {
		return fmt.Sprint(a.i)
	} else {
		return a.s
	}
}

Note: any similarities with Day 2 are purely coincidental.

Day 10

Finalist undergrad student. Already has a thing for Haskell. Clearly wants to pursue an academic career (the poor soul). Actually solved the problem in Haskell first, then transpiled the code by hand with minor modifications.

package day10

import "fmt"

// tuple, (int, string)
type IntString struct {
	i int
	s string
}

// FizzBuzz :: int -> string
func FizzBuzz(i int) string {
	return stringOf(buzzOf(fizzOf(IntString{i, ""})))
}

// fizzOf :: (int, string) -> (int, string)
func fizzOf(x IntString) IntString {
	return xof(divisibleBy(3), "fizz")(x)
}

// buzzOf :: (int, string) -> (int, string)
func buzzOf(x IntString) IntString {
	return xof(divisibleBy(5), "buzz")(x)
}

// xof :: (int -> bool) -> string -> ((int, string) -> (int, string))
func xof(check func(int) bool, rule string) func(IntString) IntString {
	return func(a IntString) IntString {
		if check(a.i) {
			return IntString{a.i, a.s + rule}
		} else {
			return a
		}
	}
}

// stringOf :: (int, string) -> string
func stringOf(a IntString) string {
	if len(a.s) == 0 {
		return fmt.Sprint(a.i)
	} else {
		return a.s
	}
}

// divisibleBy :: int -> (int -> bool)
func divisibleBy(n int) func(int) bool {
	return func(i int) bool {
		return i%n == 0
	}
}

Day 11

Master’s student. Totally at ease with FP. Desperately wants to curry. Is starting to question life choices.

package day11

import "fmt"

// Why aren't we doing this in Haskell, again?

// (int, string) tuple
type IntString struct {
	i int
	s string
}

// simulate deriving Show for IntString
func (x IntString) String() string {
	if len(x.s) == 0 {
		return fmt.Sprint(x.i)
	} else {
		return x.s
	}
}

// FizzBuzz :: int -> string
func FizzBuzz(n int) string {

	// looks rather stupid without `let`

	// divisibleBy :: int -> (int -> bool)
	divisibleBy := func(n int) func(int) bool {
		return func(i int) bool {
			return i%n == 0
		}
	}

	// xof :: (int -> bool) -> string -> ((int, string) -> (int, string))
	xof := func(check func(int) bool, rule string) func(IntString) IntString {
		return func(x IntString) IntString {
			if check(x.i) {
				return IntString{x.i, x.s + rule}
			} else {
				return x
			}
		}
	}

	// currying? Would if I could.

	// fizzOf :: (int, string) -> (int, string)
	fizzOf := xof(divisibleBy(3), "fizz")

	// buzzOf :: (int, string) -> (int, string)
	buzzOf := xof(divisibleBy(5), "buzz")

	return buzzOf(fizzOf(IntString{n, ""})).String()
}

Day 12

PhD student. Wants to bring in the big Algebraic Data Type guns, and shoots himself in the foot doing so. Is really questioning some life choices. Can’t even find time to curry, much less anyone to do it with.

package day12

import "fmt"

// This is just silly. We could have used Rust.

// Let's pretend we have monads, destructuring, pattern matching
// and data constructors.

// data FB = AFizz a | ABuzz a | AFizzBuzz a | APlain a
type FB interface {
	Plain() int
	String() string
}

type APlain struct {
	p int
}

func (p APlain) Plain() int {
	return p.p
}
func (p APlain) String() string {
	return fmt.Sprint(p.p)
}

type AFizz struct {
	APlain
}

func (f AFizz) String() string {
	return "fizz"
}

type ABuzz struct {
	APlain
}

func (b ABuzz) String() string {
	return "buzz"
}

type AFizzBuzz struct {
	APlain
}

func (f AFizzBuzz) String() string {
	return "fizzbuzz"
}

func FizzBuzz(i int) string {
	return buzz(fizz(APlain{i})).String()
}

// really, I'm going to ask my advisor why he's an idiot.

func fizz(x FB) FB {
	mod3 := x.Plain()%3 == 0

	if mod3 {
		switch x.(type) {
		case APlain:
			return AFizz{APlain{x.Plain()}}
		case ABuzz:
			return AFizzBuzz{APlain{x.Plain()}}
		default:
			return x
		}
	} else {
		return x
	}
}

func buzz(x FB) FB {
	mod5 := x.Plain()%5 == 0

	if mod5 {
		switch x.(type) {
		case APlain:
			return ABuzz{APlain{x.Plain()}}
		case AFizz:
			return AFizzBuzz{APlain{x.Plain()}}
		default:
			return x
		}
	} else {
		return x
	}
}

// oh god, kill me now.

Day 13

PhD advisor. The kind that berates students for not knowing subjects he is paid to teach. Fervent believer of the “hair-shirt approach”. Is considering asking next year’s students to implement a purely functional virtual machine. Someone should tell him about this. And remind him that decrement is not a good primitive in terms of CPU cycle usage.

package day13

import "fmt"

// my master's and phd students are dense. It's just one of those batches. If
// they got off imgur I'm sure their output would improve, but cat pictures
// are a good use of student loans in 2018... The point of the exercise was
// to understand exactly how much effort is required to translate functional
// features to a non functional language. Translating Haskell to Haskell is
// not a good use of grants. Nimrods.

type (
	// data FB = Fizz FB | Buzz FB | Just a
	FB interface {
		Value() int
	}

	Just struct {
		i int
	}

	Buzz struct {
		fb FB
	}

	Fizz struct {
		fb FB
	}
)

// make constructors part of data class
func (j Just) Value() int { return j.i }
func (b Buzz) Value() int { return b.fb.Value() }
func (f Fizz) Value() int { return f.fb.Value() }

// buzz :: int -> FB
func buzz(n int) FB {
	if n%5 == 0 {
		return Buzz{Just{n}}
	} else {
		return Just{n}
	}
}

// fizz :: FB -> FB
func fizz(fb FB) FB {
	if fb.Value()%3 == 0 {
		return Fizz{fb}
	} else {
		return fb
	}
}

// show :: FB -> string -> string
func show(fb FB, prev string) string {
	switch v := fb.(type) {
	case Just:
		if len(prev) != 0 {
			return prev
		} else {
			return fmt.Sprint(v.i)
		}
	case Fizz:
		return show(v.fb, prev+"fizz")
	case Buzz:
		return show(v.fb, prev+"buzz")
	default:
		return "" // never happens, only makes compiler happy
	}
}

func FizzBuzz(n int) string {
	return show(fizz(buzz(n)), "")
}

Day 14

Tenured professor. The kind that berates other professors for berating students.

package day14

import "fmt"

// Note to Dr. Ethelbert:
// I am not sure the students are the problem.

func FizzBuzz(n int) string {
	return IfThenElse(
		Cond(n%3 == 0),
		IfThenElse(
			Cond(n%5 == 0),
			Value("fizzbuzz"),
			Value("fizz"),
		),
		IfThenElse(
			Cond(n%5 == 0),
			Value("buzz"),
			ToString(n),
		),
	).Solve()
}

// Haskell is for wimps. For a true hair-shirt experience, you should
// implement a (crude) lambda calculus interpreter instead.
type Calc struct {
	f func() string
}

func (c Calc) Solve() string {
	return c.f()
}

func True(x, _ Calc) Calc {
	return x
}

func False(_, y Calc) Calc {
	return y
}

func IfThenElse(c func(Calc, Calc) Calc, t, f Calc) Calc {
	return c(t, f)
}

// Go->Lambda and Lambda->Go transformations

func Cond(b bool) func(Calc, Calc) Calc {
	return map[bool]func(Calc, Calc) Calc{true: True, false: False}[b]
}

func Value(s string) Calc {
	return Calc{func() string {
		return s
	}}
}

func ToString(n int) Calc {
	return Calc{func() string {
		return fmt.Sprint(n)
	}}
}

// Oh, and we need to talk about grant allocations...

Day 15

Self taught l33t h4x0r. Is into cryptography and applied math. Noticed that the outputs of FizzBuzz(n) are cyclical with a period of 15 over the input integers, and proceeded to abuse Go arrays on that basis.

Also wants to remind us not to use (3,5) as the semiprimes for an RSA private key.

Got it.

Fun fact: at the time of this writing, there were at least 36 RSA Moduli all over the web with 3 as a prime factor. No need for anti-encryption laws, people.

package day15

import "fmt"

func FizzBuzz(n int) string {
	x := [15]string{
		"fizzbuzz", "", "", "fizz", "",
		"buzz", "fizz", "", "", "fizz",
		"buzz", "", "fizz", "", "",
	}[n%15]

	if x == "" {
		return fmt.Sprint(n)
	} else {
		return x
	}
}

Day 16

Another, more experient, uber-l33t h4x0r. Is into all sorts of things, including your home router. Thinks flow control is for sissies and prefers to abuse first class functions and arrays in order to avoid writing one if statement. Likes to code-golf in APL, swap variables without a tempvar and mine various cryptocurrencies via JS snippets distributed through your niche WordPress blog.

package day16

import "fmt"

func fb(_ int) string { return "fizzbuzz" }
func f(_ int) string  { return "fizz" }
func b(_ int) string  { return "buzz" }
func s(n int) string  { return fmt.Sprint(n) }

func FizzBuzz(n int) string {
	return [15]func(int) string{
		fb, s, s, f, s,
		b, f, s, s, f,
		b, s, f, s, s,
	}[n%15](n)
}

Tune in next week for the ultimate sacrilege: Object Oriented FizzBuzzes, and a couple of extras.

13brane's holidazed cavalcade of code shenanigans: the flavors of FizzBuzz - Days 1-8

Sat, 08 Dec 2018 12:00:00 -0500

(Full source code for the entire series will be progressively published here, and the other days of the cavalcade are here: day 0, 9-16, 17-24)

The FizzBuzz cavalcade started with eight procedural solutions to the problem. In none of these does the code make use of anything you wouldn’t be able to code with relative ease in C or even Assembly.

Simple, “straight out of college” level procedural code.

Day 1

The no BS, competent junior dev approach.

package day01

import "fmt"

func FizzBuzz(n int) string {
	if n%3 == 0 && n%5 == 0 {
		return "fizzbuzz"
	} else if n%3 == 0 {
		return "fizz"
	} else if n%5 == 0 {
		return "buzz"
	} else {
		return fmt.Sprint(n)
	}
}

This is what you would write on your first class about flow control. Nothing special about this, just honest, straightforward code. There are a couple of ways in which this can improve, but in college you’ll still get a good grade for it. In corporate, no one cares as long as the spec validates it (and the profiler says this code is not running 90% of the execution time).

It does translate the spec directly, though, so this is one of the more “understandable” versions.

Day 2

CompSci 101: Structured Programming (Good student version).

package day02

import "fmt"

func FizzBuzz(n int) string {
	var divBy3 bool = n%3 == 0
	var divBy5 bool = n%5 == 0
	var out string = ""

	if divBy3 {
		out = out + "fizz"
	}

	if divBy5 {
		out = out + "buzz"
	}

	if len(out) == 0 {
		out = fmt.Sprint(n)
	}

	return out
}

Single entry point: check.
Single exit point: check.
No use of goto: check.

Bonus points for setting up all variables and constraints right at the start. It’s still not optimal from an execution standpoint, as it uses 3 conditions (the problem can be solved “normally” with only two per execution path), but it’s still better than the previous version in that sense.

Spec translation is not as direct here, but it is still very easy to grok because the code path doesn’t branch in crazy ways. The state checking at the end is kind of lame, though (and it’s the extra, unneeded if).

Day 3

CompSci 101: (Un)Structured Programming (Bad student version).

package day03

import "fmt"

var divBy3 bool
var by5 bool
var out string
var flag bool

func FizzBuzz(n int) string {
	// clean variable
	divBy3 = false
	by5 = false
	out = ""
	flag = false

	divBy3 = n%3 == 0
	by5 = n%5 == 0

	if divBy3 {
		out = out + "fizz"
		flag = true
	}

	if by5 {
		out = out + "buzz"
		flag = true
	}

	if !flag {
		out = fmt.Sprint(n)
	}

	return out
}

This was clearly pilfered from the good student, with some things jumbled around and deliberately muffled for plausible deniability.

The TA wonders how this even compiles, then remembers that the tests were given as part of the statement of the assignment. The true ode to BDD. Wants to grade it a at zero, but plausible deniability is too strong. It even has typos in the only comment it got. No worries, this person will eventually switch majors to something more in line with their level of competence. Probably business administration or project management.

Day 4

Advanced student. Understands separation of concerns and subroutines. Wants to learn C++ one day, and will use every single fucking feature the language has to offer, making trivial code non trivial because “juniors need to be exposed to a wide variety of programming styles to become proficient”.

package day04

import "fmt"

func FizzBuzz(n int) string {
	var out string = ""

	if divBy3(n) {
		out = out + "fizz"
	}

	if divBy5(n) {
		out = out + "buzz"
	}

	if len(out) == 0 {
		out = fmt.Sprint(n)
	}

	return out
}

func divBy3(n int) bool {
	return n%3 == 0
}

func divBy5(n int) bool {
	return n%5 == 0
}

Could be worse.

Day 5

“Advanceder” student. Really understands subroutines and uses this knowledge to stay DRY. At the obvious cost of readability, of course.

package day05

import "fmt"

func FizzBuzz(n int) string {
	var out string = ""

	if divBy(n, 3) {
		out = out + "fizz"
	}

	if divBy(n, 5) {
		out = out + "buzz"
	}

	if len(out) == 0 {
		out = fmt.Sprint(n)
	}

	return out
}

func divBy(n, d int) bool {
	return n%d == 0
}

Day 6

Sophomore student. Basics of programming forever engraved in neocortex. Fully grasps SP, but has grown past that. Once read an article online called “Else considered harmful”. Only writes code in “early-exit” style since. Reads cat-v.org, uses VoidLinux and suckless tools as much as possible.

package day06

import "fmt"

func FizzBuzz(n int) string {
	if n%3 == 0 && n%5 == 0 {
		return "fizzbuzz"
	}

	if n%3 == 0 {
		return "fizz"
	}

	if n%5 == 0 {
		return "buzz"
	}

	return fmt.Sprint(n)
}

Day 7

Girlfriend of previous student. They study together, but she’s not been brainwashed yet. Cares more about code performance and good grades.

package day07

import "fmt"

func FizzBuzz(n int) string {
	if n%3 == 0 {

		if n%5 == 0 {
			return "fizzbuzz"
		}

		return "fizz"
	}

	if n%5 == 0 {
		return "buzz"
	}

	return fmt.Sprint(n)
}

Day 8

“I can’t go out, I have a test three weeks from now” student. Also friends with above couple, but a bit more reclusive. Really wants that A+. Strives to write code so perfectly commented that he ends up generating line noise. Diet consists of pizza, diet-coke, coffee and whatever energy drink is nearest.

Will have a meltdown if he ever leaves academia, especially if integrated into a “fast-paced, multitasking” environment with lots of legacy projects.

package day08

// import the "fmt" package, we'll need fmt.Sprint to convert integers to
// strings.
import "fmt"

// FizzBuzz takes a positive integer and returns a string. If the passed in
// integer is divisible by 3, the output is "fizz". If it is divisible by 5,
// the output is "buzz". If it is divisible by 3 and 5, the output is
// "FizzBuzz". Otherwise, the output is the number itself, converted to its
// decimal string representation.
func FizzBuzz(n int) string {

	// all numbers need to be tested for divisibility by both factors.
	// therefore, we optimize the program by performing these divisions only
	// once
	divisibleby3 := n%3 == 0
	divisibleby5 := n%5 == 0

	if divisibleby3 {
		// number is divisible by 3

		// each number must be tested for both factors
		if divisibleby5 {
			// number is divisible by 3 and 5.
			return "fizzbuzz"
		}

		// number is not divisible by 5, only by 3
		return "fizz"
	}

	// number is not divisible by 3 from this point on

	if divisibleby5 {
		// number is divisible by 5
		return "buzz"
	}

	// number does not have 3 or 5 as prime factors
	return fmt.Sprint(n)
}

Good luck kid. You’ll need a lot of it.

13brane's holidazed cavalcade of code shenanigans: the flavors of FizzBuzz - Day 0

Fri, 30 Nov 2018 09:42:16 -0500

(Full source code for the entire series will be progressively published here, and the other days of the cavalcade are here: 1-8, 9-16, 17-24)

Hello intertubes! It’s that time of the year again. The time of ugly sweaters, sun washed decorations you forgot to remove last year (after February 1st there is no excuse, really), and that awkward hibernation HR departments and LinkedIn recruiters alike go into because of some thing which relates to fiscal years and budgets or what is it.

Nothing fundamentally wrong with that, but then you don’t get to berate us unprofessionals for not being available to start a new position in say, July or August. Just sayin’.

The hibernation period will eventually, like all things periodical, come to an end and the hordes of talent seekers will come out of the dungeons, ready to ask you to complete a 40h+ coding assignment or worse, trying to assess your programming might with FizzBuzzian techniques.

So how do you prepare for this apocalypse?

In the case of the forty hour idiocy, best is to ignore or tell the recruiters to get some sense. Especially if you have a full time job already. If you are currently in between jobs, you may opt for a different approach: perform the coding assignment if you feel like it, but make the code available under the following license:

Copyright © YEAR AUTHOR. All rights reserved.

A non-transferable, non-exclusive license is hereby being granted to COMPANY, hereafter referred to as THE LICENSEE, to peruse and scrutinize the code but only for the porpoises (LOL) of assessing the viability of a potential work partnership opportunity, which is, at this point, pretty low, since you guys have no respect for anyone’s time. THE LICENSEE must not attempt run the code in any way, including, but not limited to, feeding the code into an interpreter, compiling into an executable or otherwise producing object or runnable machine code. This includes static and dynamic linking. In other words, you are going to read this, fuckers. Tests and everything.

For the twist after the stab, add:

For all other entities, the conditions of the MIT License apply.

IANAL, you do this at your own risk. This approach is totally untested, so don’t be surprised if you can’t reenter the industry after you hit send. You’ve been warned.

What about The Fizz? What do we do with that?

We double down. You ask for “an implementation of FizzBuzz” and I say “which variant”?

Of course, there is no point in solving the same problem over and over again. So my obviously flawless plan is as follows:

Implement as many versions of FizzBuzz as I can preemptively, for shits and giggles.
Receive request to implement FizzBuzz.
Deflect request Matrix style by directing requester to code repository.
Be a smug prick.

And this is the whole point of the cavalcade. Is it possible to do 24 versions of The Fizz and turn it into a sort of deranged advent calendar thing? Or will my meager software developing capacity falter before the third sunset?

Day 0: spec and test harness

The uninitiated to the software development practice would probably commit some or all of the following three unforgivable offenses:

Not having a clear spec before starting development;
Not having acceptance tests reflecting the spec;
Starting at 1. We do not allow heresy here.

So, without further ado, here they are. The common version of the spec:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

– C2Wiki

A revised, more formal, but functionally equivalent and test friendly spec:

The function FizzBuzz
takes in a positive integer n
and returns a string s
where s is

the string “FizzBuzz”, when n is both a multiple of 3 and a multiple of 5

the string “Fizz”, when n is a multiple of 3 but not a multiple of 5

the string “Buzz”, when n is a multiple of 5 but not a multiple of 3

the decimal representation of the number n in all other cases

Instead of doing the normal iterate and print in the main program, as that would be trivial anyway, we are going to test if our implementations produce correct outputs for all input values in the range 1-100 instead.

In this case, the acceptance test is the following:

package day00_test

import (
	"fmt"
	"testing"

	// we'll add the implementations here...
	"gitlab.com/carlosdavidepto/cavalcade-2018/day01"
)

func TestAllImplementations(t *testing.T) {
	implementations := []func(int) string{
		// ... and here.
		day01.FizzBuzz,
	}

	for _, FizzBuzzImpl := range implementations {
		testMultiplesOf3and5OutputFizzBuzz(t, FizzBuzzImpl)
		testMultiplesOf3OutputFizz(t, FizzBuzzImpl)
		testMultiplesOf5OutputBuzz(t, FizzBuzzImpl)
		testEveryOtherValueOutputsInputConvertedToString(t, FizzBuzzImpl)
	}
}

func testMultiplesOf3and5OutputFizzBuzz(t *testing.T, FizzBuzz func(int) string) {
	for i := 15; i <= 100; i = i + 15 {
		// 3 and 5 are the only prime factors of 15
		// therefore, all multiples of 3 and 5 are also multiples of 15
		if FizzBuzz(i) != "fizzbuzz" {
			t.Errorf("Expected %v, got %v in FizzBuzz(%v)", "fizzbuzz", FizzBuzz(i), i)
		}
	}
}

func testMultiplesOf3OutputFizz(t *testing.T, FizzBuzz func(int) string) {
	for i := 3; i <= 100; i = i + 3 {
		if i%5 != 0 {
			// ignore multiples of 3 which are also multiples of 5 here
			// they are tested in the first case
			if FizzBuzz(i) != "fizz" {
				t.Errorf("Expected %v, got %v in FizzBuzz(%v)", "fizz", FizzBuzz(i), i)
			}
		}
	}
}

func testMultiplesOf5OutputBuzz(t *testing.T, FizzBuzz func(int) string) {
	for i := 5; i <= 100; i = i + 5 {
		if i%3 != 0 {
			// ignore multiples of 5 which are also multiples of 3 here
			// they are tested in the first case
			if FizzBuzz(i) != "buzz" {
				t.Errorf("Expected %v, got %v in FizzBuzz(%v)", "buzz", FizzBuzz(i), i)
			}
		}
	}
}

func testEveryOtherValueOutputsInputConvertedToString(t *testing.T, FizzBuzz func(int) string) {
	for i := 1; i <= 100; i++ {
		if i%3 != 0 && i%5 != 0 {
			// ignore multiples of 5 and multiples of 3 here
			// they are tested in the other cases
			if FizzBuzz(i) != fmt.Sprint(i) {
				t.Errorf("Expected %v, got %v in FizzBuzz(%v)", fmt.Sprint(i), FizzBuzz(i), i)
			}
		}
	}
}

Tune in in a few days for more Fizz, this time with actual working Buzzes. Tomorrow is day 1.

De-facto closed source: the case for understandable software

Wed, 28 Nov 2018 11:44:36 -0500

For someone who has been a strong supporter of FOSS for a very long time, watching what has been happening to the various FOSS communities over the past half decade or so is kind of depressing (with some exceptions, of course).

Let us consider one of the latest episodes in the saga of the industry that has no idea what it is doing as a whole:

Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn’t create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I’ve since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I’ve written way better modules than this, the internet just hasn’t fully caught up.

– @dominictarr, in statement on event-stream compromise

TL;DR: Tarr is no longer maintaining a node.js package that everyone and their dog uses. No legitimate users step up to maintain said package, even though they depend on it. Tarr hands over said package to a “helpful” stranger, who immediately decides to monetize it via cryptocurrency pilfering. Internet polarization ensues.

Boy, that must have been a good day for this “helpful” person. Not so much for Tarr, though, who got the crap end of the Internet for handing over the package without properly vetting the stranger. How Tarr would have been able to do so in a way that is 100% safe is not clear to me at this stage, but lets roll for a bit with the assumption that a small amount of extra care on Tarr’s part could have avoided this mess.

This would mean that the original author of any FOSS package or application, by publishing it, would have to accept as fact that any misuse of said software would forever be their responsibility, or at least until that responsibility is, diligently and ceremoniously, transferred to someone else, hot potato style.

You know, like we do in the corporate world.

This line of reasoning quickly leads us to a dead end where there is no possible positive cost-benefit analysis on the matter of ownership of a part, however small, of the FOSS ecosystem.

Here’s a thought experiment: suppose it was Tarr himself who decided to add a new crypto miner “feature” to his own package. Hell, it’s just one of the many ways of monetizing FOSS, after all. Though I will concede that it would not look good in his rap sheet, the most interesting thing about this possibility is that it is entirely legal. It is also possible that, if done correctly, no one would have noticed for a long time.

So what does this mean? It means that at any point in time any one FOSS maintainer may entirely replace their code with anything they fancy, be it crypto miners or console.log("ur mom, lol"), make it unavailable permanently or only on Tuesdays and full moons, and also, as with any property, transfer it to anyone, without asking for your opinion.

You on the other hand, the avid FOSS user, bestowed with the powers of binary copying and the four essential freedoms of the GPL, get to say “yeah, maybe not today”, and pull out your own, well behaved copy of the offended/offending software, make the modifications you need, and proceed from there, optionally publishing your own modified version of the codebase in question.

But no one has time for that, right? We got some hip new webapps to ship. No time to read all the code for the 40k dependencies they have, when we don’t even have time to write unit tests. FOSS maintainers should be held to higher standards so that we can better trust them! How dare they pull the carpet on us like that?!

Here’s the thing:

FOSS was never about trust in software owners.

It was about not needing to trust them to begin with.

Code is the only thing you can trust when you want to know what the software is doing, when the company goes belly up, or when your system isn’t the same system that the original authors were developing on.

Code is the only thing you can trust, and by not reading it, you’ve forfeited the most important benefit provided by this ecosystem: the choice of not having to trust the authors regarding behavior or continuity.

You want to download thousands of lines of useful, but random, code from the internet, for free, run it in a production web server, or worse, your user’s machine, trust it with your paying users’ data and reap that sweet dough. We all do. But then you can’t be bothered to check the license, understand the software you are running and still want to blame the people who make your business a possibility when mistakes happen, while giving them nothing for it? This is both incompetence and entitlement.

Plus how is this any different from using proprietary software? If you’re not going to take full advantage of FOSS, maybe you’re better off spending your money on support contracts anyway. At least then, you are entitled to complain until you’re blue in the mouth. Maybe you can even take someone to court!

Your system is your responsibility and you owe your users that, especially when they pay. This responsibility does not change when you choose to take someone’s code so that you don’t have to write it yourself, especially since you didn’t pay for that. This is not to say that the FOSS ecosystem doesn’t benefit from a high degree of trust (it does), however it can, and did, function without this new concept of trust by proxy, because we used to do it the hard way: trust by check-modify-then-compile.

I may be wrong, but in the millions of downloads of event-stream and it’s 1.5k dependent packages, there should be at least 5 companies involved which, had they spared 1 dev-hour per week each, should be more than enough to keep event-stream kosher.

De-facto proprietary software

Here’s the part that’s a bit depressing, at least for me.

We may have reached a stage where FOSS doesn’t represent everything it used to anymore, simply because there is too much of it. Too many lines of code, too many competing solutions, too fast a rate of change. We want to keep those security updates coming in straight from upstream, but how are we going to do audits every week on our current constraints?

The fact that some of the focus is being shifted to trust is no surprise in this kind of environment. A FOSS ecosystem benefits tremendously from having a solid trust base because it allows for more distributed work to happen.

But it isn’t really trust. As it currently stands, it’s actually hope and wishful thinking.

I use many Linux distros here in this haus. Of course I can’t audit the entire kernel alone, much less all the code, patches and build scripts for all the packages for all these distributions. What I do is I audit the parts that I’m more interested in, and I hope that 1) the distro maintainers aren’t malevolent, 2) that if they are, some one else will study the parts I haven’t seen and 3) that someone else is also interested in the same parts I am, so that they might catch things that slipped through my eye-comb.

This paints a bleak picture of the future in the case where the growth of the number of lines of code or number of patches per time period far outpaces the growth of the number of developers and maintainers.

So how do we avoid this?

The case for understandable software

We must make software simpler. Much much simpler. And companies who base their service offering on open source software must become more involved in keeping this ecosystem alive in whichever capacity they can.

Here is another thought experiment: is it possible for a new (but experienced) developer to understand 80% of the part of the codebase they’ll be responsible for within their first 2 weeks (80 hours)?

If not, this person is overworked from day 1, because they will be, by definition, unable to transfer their responsibilities within the standard North-American notice period. If they are fired or leave, no amount of jiggling can prepare a replacement within the notice period, as guaranteed by fourth grade arithmetic. As a consequence, no smooth transition can occur, and some domain knowledge will inevitably be lost.

You may want to adjust the above figures to your particular jurisdiction, but the basic premise remains intact. In no other industry is it considered normal for people to work with, let alone develop on, things they don’t understand at least to a certain degree of confidence.

Software must be made understandable. The essence of FOSS for me can be reduced to one fundamental computing right: the right to refuse to run, on my machines, code that I do not have the option to understand. That is it.

Sure, there are cybersecurity benefits, and economical benefits, and some others I can’t recall right now. But when you try to argue with me that it is normal for my government’s online tax submission system to require Adobe Flash and the delivery of that overprivileged opaque blob to my browser, that’s when you get the “public money, public source code” response, liberally drizzled with the “holy fuck, how do you breathe” stare.

I’m not fundamentally opposed to closed source software, so as long as it runs on someone else’s computer.

However, as we’ve seen, having the source code is not enough to guarantee understandability. It is therefore imperative that the software industry also calms down a bit with this churning out of features, and more emphasis is given to stability, cybersecurity, user privacy, and the understanding of one’s own systems which underpins all of these. Because that’s the bare minimum that any responsible entity can do, especially when they happily take money from the masses for their “service”.

And if said service is based on FOSS from individual contributors, consider supporting them. After all, they are supporting you. They don’t get to complain when you don’t support them, but you don’t get to complain when things go wrong either.

Darker

Fri, 16 Nov 2018 20:51:21 -0500

The branes have worm-holled to a new hosting environment, to benefit from Let’s Encrypt’s cybersecurity powers.

But that’s not all. They have also received a bit of CSS makeup, so that the site does not hurt anyone’s retinae, especially at night. Plus, it helps to conserve energy, and we’ll need as much of it as we can find for the 2020 cryptocurrency rush. /s

Battle lost: EME is a W3C recommendation

Sat, 23 Sep 2017 15:04:01 -0400

A few months ago I wrote about this subject. It turns out I was very, very wrong. Not because EME is a good idea. It is not. It is in the same stupidity class as putting a hornet’s nest inside your car as you are about to start a 2h summer drive.

Bryan Lunduke brilliantly explains why.

No, I was wrong because I thought nobody would care enough to support Encrypted Media Extensions as a standard feature in browsers (since it’s already available in FF and Chrome as an option anyway), and because all the techs and privacy orgs were against it. I honestly thought this would have been enough to kill the proposal.

Yet, 6 months later, money and lobbying have proven to speak louder than reason and common sense. Against all odds, EME not only lives, but is here to stay.

I applaud the balls on the EFF to do the only right thing to do in this regard, which was to abandon the deaf clusterfuck of interests that plague the W3C. If you are not there to be heard, best not to be there at all.

The people who claim to defend the interests of the open web have demonstrated that such openness is no longer a priority.

Browsers are now recommended to include a closed piece of code that nobody can verify, experiment with or otherwise validate from a cybersecurity perspective. DRM laws make it illegal to do so. And history shows these things always work as intended. Just ask Intel. They know.

The world at large does not want to listen to the technical arguments, and corporate interests just want them eliminated altogether. All because “users”, all too eager to consume content, while trusted to pay for things with their plastic, cannot possibly be trusted to watch a movie without copying it. Or so we’re told.

In any case, you can’t say we didn’t warn you. We, the ones who give a shit about your machine being actually yours and acting as your attorney rather than your parole officer, we actually warned everybody. We warned that all boundaries would eventually be at risk.

Browsers were a nice common ground, because they provided this boundary: there were a ton of them and some of the relevant ones were open. For the longest time browsers provided a nice compromise for content delivery: open and trusted, yet found roughly everywhere. Millions of web applications were built, providing information, services and functionality to whoever wanted it, in a cross-platform, no-hassle way. We have now lost one side of this equation.

“But Firefox and Chrome already had this. What’s the big deal?”

The big deal is that FF and Chrome provided EME as an option. Other browsers had a reasonable expectation that 99.99% of sites out there did not need this, so EME was largely irrelevant except for a niche. Browsers will now be expected to implement EME, which means that browsers who want to remain 100% open will basically not be implementing web standards correctly.

A 100% open browser is essential for security on the open web, because once you give up trusting the user agent, the privacy boundary is dead. The clean separation between your computer and the untrusted code coming from the web is compromised.

But hey, why complain? Netflix is working well now.

#equifux

Sat, 23 Sep 2017 09:34:08 -0400

By now you probably heard about #Equifux. Err, I mean Equifax.

For those outside North America, that’s a consumer credit reporting agency. What’s that, you ask? It’s a private entity that collects, maintains and provides information about consumer credit to other entities (individuals, but also public and private institutions).

See, my European friends, here in the Great White North (and in the U. S. of A.) we have this retarded system where your ability to apply for a credit card or a loan does not depend on sensible things like how much you’ve been making over the last 12 months, how long your work contract is, what collateral you can provide in case of default, or what any of these elements are for your co-signer.

Naaah, that would make way too much sense.

So instead we have credit scores. Back in 2014 when I first arrived in Canada, I was introduced to the concept in the following manner (conversation abridged and paraphrased) while opening a bank account:

Bank: You’ll probably also want to have a credit card.

Me: No, thanks. I already have one.

Bank: Yes, but that is with a European bank. You’ll need one with a Canadian bank, otherwise you won’t have a credit score in Canada.

Me: What is that and why do I need it?

Bank: Well, you won’t be able to apply for loans without one.

Me: That’s ok. I never had a loan and I don’t intend to have one.

Bank: No, you don’t understand. You need a credit score, otherwise you won’t be able to have a mortgage or finance your car. You won’t be able to have any type of credit product, really, without building your credit score first.

At this point in the conversation, I am Jack’s puzzled neo-cortex. I thought to myself, “Wait, I need to borrow money to be able to borrow more money”?

A very sensible rationale, of course.

By now it should be evident that this rant is not, in fact, about Equifax. They’ve been beaten down enough already. They obviously have the ITSec capacity of a tadpole drowning in ethanol, which was made obvious when they made a separate site to handle the inquiries of people affected by the breach with a domain name straight from a Sakawa playbook, then proceeded to tweet out the URL for a spoof site that a security researcher set up to prove the point above. And there was that thing with the executives supposedly selling stock after the breach…

Just sigh and facepalm, people. Sigh and facepalm. The only competent department in this company seems to be Public Relations. Hell of a job cleaning a mess of these proportions the way they did it.

No, this rant is about why these things are even allowed to exist to begin with.

As stated above, I’m originally from Europe. Portugal to be exact. We do not have credit scores there. Hell, we barely have credit cards accepted anywhere except the major stores. Most merchants will only take debit or cash.

Asking for a loan over there is something more involved and arcane than checking a magic number on a sheet of paper provided by a company staffed by tadpoles, but it does have it’s own set of merits:

ability to pay for the loan is checked against current – not past – information;
there is no centralized source of credit information (read, no private entity to hack).

“But Davide”, say the FICO luddites, “that is worse than a credit score because some people just won’t have access to credit!”

Of course not, because they can’t pay it back. I have a magic number for you, too: 2008. Remember that?

“Well, you’re also forgetting that without credit scores you have to share your information with any institution that you inquire for credit. That’s actually more possibilities to hack.”

Cute argument, but that is not the way it works. Unlike here in North America, where the Social Security Number is sacred and must be kept safe and away from prying eyes (yet all past employers and possibly your mobile phone provider will ask for it, fuck logic…), in Portugal at least our ID numbers are just that: a number. They aren’t used for security anywhere relevant. You actually have to provide your ID card (not any card with a photo, the actual, only ID card) when your identity is to be verified. And usually you have to be at the bank or store in person when applying for financing of any type.

So, while in theory more institutions with my salary info and full name, address, etc. is not exactly the best scenario ever, the fact is that even if those data points were to be compromised, the identity thief’s options are quite narrow. Identity theft is not something Europeans lose their sleep over, because North America is the lowest hanging fruit in this case.

Here’s a fun fact, though. I ended up getting a credit card in Canada and canceling all others (for practical reasons). And, since I was told that using the card consistently builds credit score, I thought “why not, it can’t hurt, and I’m getting cashbacks anyway”. Fast forward 3 years, and our credit monitoring friends cannot calculate my credit score. The reason is very simple: I never borrowed money (I pay everything on the card immediately, so the balance is always 0). According to the rules, if you pay all your invoices within 30 days, you’ll have a top credit score. But pay them before, and the system cannot say that you have good credit.

This system is broken beyond repair. None of it’s premises make any sense.

Given recent events and the fact that credit scores aren’t actually needed, what I’d really like to know is:

why are credit reporting companies allowed to collect this much information without VERY explicit consent?
why aren’t credit reporting bureaus a public institution, rather than private?

And for fuck’s sake, find a way to make the SSN a normal identifier, instead of a magic-confidential-but-not-really predictable series of digits.

At least the OPC is launching a probe into the Equifax hack. Maybe something good will come out of this mess after all.

Though week for the tubes - What to know about CIA's leak (Vault 7).

Sat, 11 Mar 2017 12:01:00 -0500

(First part of this rant here.)

If there was ever a time to be skeptical about what software is doing in your machine, this would be it.

As referenced in our previous instalment, this happened.

Now, before anything else, it might be a good idea to untwist our panties. And prune the misinformation that has been circulating a little bit. Only after that can we try to really sort this mess out.

Here’s the gist of it.

First of all, the CIA is not able to crack the encryption algorithms of apps like WhatsApp, Telegram and Signal. Which is why they went for the easier route of cracking the phones’ OSes instead. This can be done remotely.

Second, CIA has the ability to crack computers (Windows, MacOS and Linux) and Samsung Smart TVs, although nothing I’ve read so far indicates that this can be done in a purely remote fashion. Apparently, physical access to the target device is required in one form or another (I’m still waiting to see more details though).

Third, it looks like these operations were not of the dragnet type (as the ones referenced in the Snowden leaks), rather they were more the kind of targeted operation.

Fourth, the large number of vulnerabilities that existed in CIA’s catalog is surprising, considering that the three letter folk are not supposed to hoard vulnerabilities and keep them hidden from US companies, as set forth by the Vulnerability Equities Process.

Fifth, a large number of IP addresses corresponding to US locations were under active CIA monitoring. This is surprising because, with few exceptions, the CIA has jurisdiction only over foreign territories.

What this means to the regular Joe.

If said Joe is American, it means that Joe can now “initiate the debate” about the possible overreach of the agency’s activities. He may also question the agency’s attitude towards VEP and the US tech industry. There are “laws” which these bodies are supposed to “follow”, and then the citizen, with the help of the courts is supposed to make them accountable.

If said Joe is not American… Tough shit. As an awesome band once said, “We’re all living in America”. But we are not all American, and there’s a big difference.

See Joe, if you are not American, the US of A has no responsibility to your particular individual. None. You are a data point. And in this case, the more interesting the data point is, the worse off the data point is likely to be.

In both cases, we can all see the pointlessness of this particular discussion.

First, because the American taxpayer is paying the CIA to do exactly what it is doing. Whether the taxes are well spent or not is a totally different discussion. The CIA is an intelligence agency, and as such, collects intelligence. They are, in essence, doing their job and doing it in a very successful fashion.

Second, for citizens of other nations: what are you complaining about? You bought the computer/phone/toaster knowing it was American. It can come with a backdoor from the factory itself, for all you care. Or maybe the device is Korean, but the OS most likely is not. Redmondites and Cupertinites cannot complain about this: you put your hand in the lion’s mouth, voluntarily.

It’s your rented, filthy kitchen, and you can’t blame the mice.

So just sit back, relax, enjoy your DRM’d content. If you are being spied on by the CIA (you probably aren’t – your bulk data is going to the NSA instead and there is no budget to do targeted surveillance on everyone), just rejoice in the fact that you are effectively not an interesting person, and the CIA will find nothing on you because there is nothing to find.

What this means to the intelligent (non-IT) Joe.

It means a couple of bad things. The first bad thing is that your devices, where you store your personal thoughts and private conversations can, under certain conditions, reveal those private bits of information to parties you do not necessarily trust.

You might personally trust the CIA or the NSA (or not), but most of us would agree that a stolen computer is, when stolen, in the hands of an untrusted party. If you’re a journalist, a physician, a therapist or an attorney, this is obviously a big problem. And the key facts about the list of vulnerabilities in the CIA menu are that they exist and they are exploitable.

Vulnerabilities are not particularly selective about who exploits them. The usual fallacy accompanying these debates is that “only the CIA knew about said holes”. Which is unprovable at best, and false if we are really unlucky.

The other bad thing is that you don’t really have anyone to fully trust right now. Your device is not giving you an adequate amount of privacy protections, and lets not talk about cloud services for brevity. Spy agencies broke their promises of sharing the holes with the tech industry so they can be fixed, and the tech industry continues to ship shitty software because “OMG quarterly statement! New Seed Round! YAS!”

Your options right now, are to refuse technology, which is extremely inconvenient, or live with the risks (which to be fair are not all that bad if your are already doing all the good practices, but are unnecessary and could be avoided). In particular, for nationals of countries other than the US, who have no good reason to trust the American spy agencies by default (due to the lack of a bond, be it legal, patriotic or otherwise), it raises the questions of “what is my own country doing to protect me in this case?” And we all no what the answer to that question is.

Finally, a word to my fellow members of the tech industry.

This one is mostly to the software engineers, developers and programmers (sysadmins, you are in the clear, but only today).

Here is a simple fact of life for us: We are writing crap software. But not just any crap. Crap of the dangerously negligent persuasion. Don’t give me the usual “all software has bugs” discourse, because this is not entirely true. And worse than spreading a lie, is spreading one which creates in software users the belief that it is ok if software has bugs because that’s just the way things are. One software bug due to an honest programming mistake is not the same as three compounded bugs, which can be combined in order to get root on the machine, all of which can be traced back to errors your compiler should be able to catch by itself.

There are well known ways of writing software which does not break (or at least, breaks in a predictable, non destructive way). There are, for instance, languages which check array boundaries automatically to prevent buffer overflows (and hence, arbitrary code execution). Many of them. There are languages which, upon compilation, can prove, that a program or code unit is coherent with its own specification. Languages which have embedded continuous testing constructs. Languages which allow you to write a massively scaled web service that is sane, secure, and does not need to be restarted every 5 minutes (true story, google “ruby” and “Zed Shaw” to get started). Languages which allow you to, interactively, inspect everything the program is doing and why (and I was told there are machines that can do this too).

To top it all off there are methods of all sorts to avoid software development pain, but the teaching institutions are terrible at forwarding this knowledge because they lack real world experience and in general are too slow to pick up on the changes. The industrial institutions on the other hand, have the environment where this is needed and can be practiced, but because management is more interested in bottom lines than in the morale of their “warriors” (something I actually heard at one point) and they see software development as just another kind of brick-laying, you are left to your own devices to figure out what real software engineering is about.

You read about these hotshots that could swap two locations in memory without a temporary slot and can implement quicksort by heart (why?) and pretty soon you are indoctrinated to think “garbage collectors are for pussies”, that all that overhead will make your program slow and programming in C is the shit. If your program is more than 5K SLOC of C, it probably is the shit. Just not in the way you think. Same applies to C++. A turd with class is still a turd. There’s a reason the suckless crowd write software that small with such a limited feature set: using these types of tools to build software, particularly the ones which are hostile to modern testing practices due to their nature, requires that the entire spec of the program can fit in ones head while developing, lest the developer fall into a small distraction and create another Heartbleed or Cloudbleed. Sane design, as they define it, calls for a ruthless ability to refuse adding features.

I’ll pause here a moment to semi-exclude embedded developers and those who build real time systems from this, who obviously don’t have many choices in terms of their tools. For now. Available memory and resources tend to go up. So this will not be an excuse in the future. And obviously, the fact that you are using C or C++ by necessity does not mean you are excused from producing correct code which either works as intended, or not at all. It merely excuses you from the choice of a better platform, because currently there isn’t one. The IoT security mess is still there to be cleaned up. And the mop has your name on it.

For everyone else, there are no excuses at all. RAM is cheap, CPU is cheap, disk is cheap and bandwidth is cheaper. We have all the elements needed to build sane, humanly uncomplicated systems, which may be complicated for the computer to deal with, but that is why we build them anyway (to deal with complicated comptutations), and do what the user intended and nothing more. They would perhaps lack a couple of “features”, but they wouldn’t put the users’ privacy at risk.

But of course, in the “real world”, we can’t have that, because the user wants content (or marketing says they do anyway) and a red squiggly mark beneath their misspelled words. The content must be decrypted with a half tested blob and toy ciphers that can’t be audited. The squiggly (which is in fact a useful feature) must be implemented as a “temporary” hack because the previous “engineers” (who are now VPs of Sales, go figure) fucked up the graphics implementation, as they “were on a tight deadline”. As a result, the API is terrible and the implementation is worse. And of course, the lump has no testing framework whatsoever, so you’re afraid to do the much needed refactoring because you fear it will just break everything. You are now forced to write your own little lumps on top of this big lump because of “backwards compatibility” (which is usually backwards only, and not compatible in any way).

And before the holders of the status quo flagstaff come to ask “Well, what are you going to do? Come and fix all our security issues in our software then”, let me remind you of the fact that such a proposition makes no sense. A civil engineer pointing out a flaw in the development process of a couple hundred buildings would never be asked to go in and fix the flaws themselves. They would, probably, be asked for input, and thanked (or possibly paid) for it instead. Handling the flaws in the process is still the responsibility of someone else (whoever signed for the particular building). The security vulnerabilities introduced by your code are your responsibility. No one else’s.

The complete pill for this is, that we, as a profession, stop being spineless minions and learn to say no. I can’t account for how many times I’ve heard some sort of responsibility dismissing comment along the lines of “management wants it like that” or “I just write the code”. Well, as we’ve seen from the leaks, management does not know (or doesn’t care, which is worse) about the consequences and the code you “just wrote” is now putting millions of people at risk.

Next time refuse to write broken software from the start. That’s how messes like these eventually get cleaned up. Because doing it the other way around is how we got to the mess in the first place. Especially, when the code you write is used by millions of people every day.

Though week for the tubes - Ars tries to pull a Lazarus on browser EME standards.

Sat, 11 Mar 2017 12:00:00 -0500

I had planned a different type of rant for today, but a couple of pressing issues have taken precedence.

So long story short, this and this happened.

(For the second part of this rant, about Wikileaks being in the process of releasing Vault7, a massive leak detailing the power and scope of CIA’s computer hacking operations, see here.)

For those who have not yet taken the course on link clicking and/or live under a digital rock, ArsTechnica republished an old op-ed about enabling web browsers’ Encrypted Media Extensions, and this time around, highlighting the fact that the EME W3C work group’s charter is about to expire, and how important it is to keep this debate alive.

At this point, it should be beyond clear that nobody cares about DRM in web browsers. That an increasingly irrelevant body such as the W3C is about to see a proposal expire due to inactivity, especially one like this, is not surprising. Ars resurrecting the “supporting view” in the hopes of keeping the zombie from disintegrating is, though.

To quote from Ars’ article:

Last year, the working group asked for such an extension [to the EME group’s charter], but the Advisory Committee could not come to any consensus on whether to grant it. W3C director and inventor of the Web Tim Berners-Lee last week voiced his support for the EME plan, but the future of EME and the working group’s efforts are currently in limbo. Many of the arguments being made today mirror those made in 2013 when the working group first set about developing EME. And in light of this pending decision, we’re resurfacing the op-ed below (from May 2013) that outlines the supporting view.

Which is an elaborate way of saying: “We know no one cares, but can we keep this lobby alive? Pretty please?”

It is worth pointing out that what is being discussed is not the lack of browser support for EME. Firefox has DRM support via Widevine and Primetime. Chrome has recently made it’s EME extension mandatory. W3C’s effort is not about availability, but consensus (i.e. yet another standard).

DRM’d content in browsers is to the web’s relevance as an extra glass of water is to the Pacific: it makes no fucking difference whatsoever.

The web is relevant because it gelled. Even the “enlightened” announcing the end of the web and the dawn (which is more like noon now…) of mobile have to acknowledge the simple truth that mobile is built upon the web. Even if everybody stops using web browsers, the web will still be there as the pipe for the APIs that power everything, from your weekend binge of right swiping to your imported Japanese butane fueled smart toaster oven (now with more analytics and kawaii).

The possibility that content distributors might experiment with DRM-free content if the platform in question offers DRM’d playback capabilities is, at best, a laughable fallacy. Netflix did not succeed because of DRM on its app (or lack thereof). They succeeded, because they managed to provide a service that is good enough for people to prefer forking out the monthly fee rather than trying to find out which domain The Pirate Bay is using this week.

Like Torvalds once said, “the user doesn’t care”. Aunt Sally does not know what DRM is, and if her iPad doesn’t stream the last episode of Gilmore Girls, chances are “what is DRM” is not what she’s going to be googling (if anything at all; she’ll probably just call her niece to figure out the problem for her).

Even for technologically inclined folk such as yours truly, dealing with the hassle of misbehaving plugins when in reality I’m more in the mood for House of Cards does not have good chances of being a pleasant experience. On a personal note, the last time I tried to watch Netflix on an actual web browser the experiment failed miserably, which further confirmed my firm belief that, at the prices gadgets are sold these days, it’s actually better to relegate all the binary blob ridden activities to that one “impure” device that you keep specifically for this purpose.

DRM blobs do not matter for the web’s relevance, period. But they do matter from a security and legal perspective, as clearly pointed out by BoingBoing (in the link above, regarding Google Chrome):

Because of laws like section 1201 of the US Digital Millennium Copyright Act (and Canada’s Bill C11, and EU implementations of Article 6 of the EUCD), browsers that have DRM in them are risky for security researchers to audit. These laws provide both criminal and civil penalties for those who tamper with DRM, even for legal, legitimate purposes, and courts and companies have interpreted this to mean that companies can punish security researchers who reveal defects in their products. Dozens of W3C members – and hundreds of security professionals – have asked the W3C to amend its policies so that its members can’t use EME to silence security researchers and whistleblowers who want to warn web users that they are in danger from security vulnerabilities in browsers.

In other words, if you want to be a good consumer and binge on the latest offerings from your faithful content provider, you must install this opaque piece of code that you are not allowed to check for correct behavior.

Here’s a fun fact. All DRM is breakable, the old analog way. Because, you know, eyes are not digital. DRM is based on the assumption that, from the perspective of the content provider, your device is more trustworthy than you are. Which, if you think about it, is fundamentally idiotic at all levels.

So no. Thank you. Keep your blobs out of my browser. It’s fine. Especially, after knowing this.

Warming up hyperdrives. Unfolding branes.

Sat, 28 Jan 2017 16:40:41 -0500

The branes have been busy. Very busy.

They twisted, turned, collided, melded, unmelded, worm-holed, and folded in pretty much every possible combination.

The hyperdrives are nearly ready to activate.

And best of all: the rant canon is charged and armed, ready to fire rage quantum in all its 13-dimensional prowess.

Brace for impact.