• Cory Doctorow +++ (pre-) FOSDEM +++ 36C3

  2020 is not just a new year, it is the dawn of a new decade. With more and more automated systems run by software, a political representation of freedom is more needed than ever. Read in our January Newsletter about why Cory Doctorow supports the FSFE financially and why you should do so too. Read about our upcoming FOSDEM activities including our pre-FOSDEM meeting and reflections on our presence at the Chaos Communication Congress. Also we have a new Software Freedom Podcast with Harald Welte and reports from our community.

• Report from the 36c3, about:freedom - about:fsfe

  At the end of December, FSFE was in Leipzig at the 36th Chaos Communication Congress. As in previous years, we were present at the congress with lots of information material, talks and workshops. FSFE was one of the main organisers of the cluster about:freedom, an association of 12 civil society organisations and groups. Together with the other organisations, we focused on digital rights and network policy issues.

  In about:freedom, a broad political spectrum of topics could be covered due to the many different focuses of the individual organisations and groups. At our booth we informed about Free Software and presented individual campaigns of us. Together with the cluster about:freedom, we organised 19 self-organised sessions during the 4 days. To only name a few, the hand-on workshop „Freedom to go“ for a Google Independent Android Smartphone by Erik Albers, the more general presentation "The Free Software 1x1: Clarifying the basics and typical misunderstandings", "Computer says no": Worüber sollen Algorithmen entscheiden dürfen by Chris Köver, Emergency VPN: Analyzing mobile network traffic to detect digital threats and the talk by Christian Busse regarding Free Software in Science: "Free Software for Open Science" were part of the sessions.

• The story of my first job in Tech Industry

  The other day I was thinking about my first ever job in this industry as a junior software engineer at the age of 20. I was doing okay with my studies at the Athens university of applied sciences but I was working outside of this industry. I had to gain some working experience in the field, so I made a decision to find part time work in a small software house. The experience and lessons learned in those couple weeks are still with me till this day … almost 20 years after!

• KubeInvaders - Gamified Chaos Engineering Tool for Kubernetes

  Some months ago, I released my latest project called KubeInvaders. The first time I shared it with the community was during an Openshift Commons Briefing session. Kubenvaders is a Gamified Chaos Engineering tool for Kubernetes and Openshift and helps test how resilient your Kubernetes cluster is, in a fun way.

• CSI Ephemeral Inline Volumes

  Typically, volumes provided by an external storage driver in Kubernetes are persistent, with a lifecycle that is completely independent of pods or (as a special case) loosely coupled to the first pod which uses a volume (late binding mode). The mechanism for requesting and defining such volumes in Kubernetes are Persistent Volume Claim (PVC) and Persistent Volume (PV) objects. Originally, volumes that are backed by a Container Storage Interface (CSI) driver could only be used via this PVC/PV mechanism.

  But there are also use cases for data volumes whose content and lifecycle is tied to a pod. For example, a driver might populate a volume with dynamically created secrets that are specific to the application running in the pod. Such volumes need to be created together with a pod and can be deleted as part of pod termination (ephemeral). They get defined as part of the pod spec (inline).

  Since Kubernetes 1.15, CSI drivers can also be used for such ephemeral inline volumes. The CSIInlineVolume feature gate had to be set to enable it in 1.15 because support was still in alpha state. In 1.16, the feature reached beta state, which typically means that it is enabled in clusters by default.

  CSI drivers have to be adapted to support this because although two existing CSI gRPC calls are used (NodePublishVolume and NodeUnpublishVolume), the way how they are used is different and not covered by the CSI spec: for ephemeral volumes, only NodePublishVolume is invoked by kubelet when asking the CSI driver for a volume. All other calls (like CreateVolume, NodeStageVolume, etc.) are skipped. The volume parameters are provided in the pod spec and from there copied into the NodePublishVolumeRequest.volume_context field. There are currently no standardized parameters; even common ones like size must be provided in a format that is defined by the CSI driver. Likewise, only NodeUnpublishVolume gets called after the pod has terminated and the volume needs to be removed.

• Reviewing 2019 in Docs

  Hi, folks! I’m one of the co-chairs for the Kubernetes documentation special interest group (SIG Docs). This blog post is a review of SIG Docs in 2019. Our contributors did amazing work last year, and I want to highlight their successes.

  Although I review 2019 in this post, my goal is to point forward to 2020. I observe some trends in SIG Docs–some good, others troubling. I want to raise visibility before those challenges increase in severity.

But can you trust your VPN service provider? On more than one occasion, the VPN providers have been caught logging, snooping or sharing data with third party. What to do in such cases?

I have shared a list of privacy focused VPNs for Linux in the past and ProtonVPN is one of them. The good news is that ProtonVPN has just open sourced all its apps and underwent an independent security audit.

In 2017, a German organisation, FSFE e.V, elected me as their community representative. They had this odd approach to membership, approximately 28 people had been registered as members of the assocation. Their 1500 volunteers and donors were invited to join but kept off the books. As the organization's contempt for membership became apparent, I started to feel Orwell's animals coming to life. As he wrote all those years ago, All animals are equal but some animals are more equal than others. In FSFE's case, we could say all Fellows are equal but some Fellows are more equal than others.

[...]

Animal Farm is only one side of the Orwellian coin, the other being his uncannily accurate tour-de-force of the modern surveillance state, Nineteen-Eighty-Four. All of the organizations mentioned above (Debian, FSFE) are secretly funded by Google. Would you be less surprised to find a bible in a church than to find Nineteen-Eighty-Four under the pillows of Google's founders? One of the most startling discoveries during my time as community representative was the extent to which all of these organizations had built their budgets around recurring annual contributions from Google. Their experiments in demotions arose at exactly the same time that women in Google's workforce who spoke up against harassment found themselves being publicly demoted and humiliated. It was revealed that one of the organizations, Debian, had secretly banked $300,000 from Google under the radar at the same time that attention was on an identical-sized donation from a non-profit, the Handshake Foundation. What a convenient cover. After Linux Foundation and FSFE had decided to eliminate their annual elections, Google's money had a community representative "demoted" to a lower status in Debian just days before the call for nominations in leadership elections.