Trump’s casino-like campaign app seems to be his own attempt to create a “one-way tool of propaganda.” Its deployment is part of a global trend, piggybacking on years of unresolved privacy and security issues within the app ecosystem. As researchers studying the intersection of technology and propaganda, we understand that political groups tend to lag behind the commercial ad industry. But when they catch up, the consequences to truth and civil discourse can be devastating. The array of data-gathering tools the Trump and Modi apps use are a legacy of a “freemium” social-media and app landscape that is manipulative, non-transparent, and purposefully addictive, with a mentality of “collect data first and ask question later.” For the last five to 10 years, the pervasiveness of these tools and their use in data scooping has been well documented. Sporadic, state-by-state data regulations have been the only response. In Europe, the GDPR was a big step toward meaningful consent and transparency, but the Official Trump 2020 App does not fall under its jurisdiction. A global perspective is now critical to understanding the implications of data-fueled political manipulation and preparing for the next wave of disinformation. Countries must work together to create effective regulation, and citizens must demand this of them. It took about five years for Modi’s strategies to jump from India to the US, and in the next few years we are on track to see the arrival of strategies used in the dark-money disinformation campaigns of Mexico and Latin America. The Mexican journalist we’d interviewed for our study put it this way: “I think what’s coming all around the world is going to be very chaotic, at least in [the US], I think you’re on the brink of a sort of civil war in one or two years … You’re going to have a lot of work to do.”
‘As per a press release, Springer will publish “A Deep Neural Network Model to Predict Criminality Using Image Processing.” Sign our letter to urge all publishers to refrain from feeding the #TechToPrisonPipeline with physiognomy 2.0.’ (via Niall Murphy)
Great doc from Clare Liguori about current AWS best practices around deployment. A fair bit of it is similar to what they were doing by the time I left; this “wave” concept is a good new approach though:
Each team needs to balance the safety of small-scoped deployments with the speed at which we can deliver changes to customers in all Regions. Deploying changes to 24 Regions or 76 Availability Zones through the pipeline one at a time has the lowest risk of causing broad impact, but it could take weeks for the pipeline to deliver a change to customers globally. We have found that grouping deployments into “waves” of increasing size, as seen in the previous sample prod pipeline, helps us achieve a good balance between deployment risk and speed. Each wave’s stage in the pipeline orchestrates deployments to a group of Regions, with changes being promoted from wave to wave. New changes can enter the production phase of the pipeline at any time. After a set of changes is promoted from the first step to the second step in wave 1, the next set of changes from gamma is promoted into the first step of wave 1, so we don’t end up with large bundles of changes waiting to be deployed to production. The first two waves in the pipeline build the most confidence in the change: The first wave deploys to a Region with a low number of requests to limit the possible impact of the first production deployment of the new change. The wave deploys to only one Availability Zone (or cell) at a time within that Region to cautiously deploy the change across the Region. The second wave then deploys to one Availability Zone (or cell) at a time in a Region with a high number of requests where it is highly likely that customers will exercise all the new code paths and where we get good validation of the changes. After we have higher confidence in the safety of the change from the initial pipeline waves’ deployments, we can deploy to more and more Regions in parallel in the same wave. For example, the previous sample prod pipeline deploys to three Regions in wave 3, then to up to 12 Regions in wave 4, then to the remaining Regions in wave 5. The exact number and choice of Regions in each of these waves and the number of waves in a service team’s pipeline depend on the individual service’s usage patterns and scale. The later waves in the pipeline still help us achieve our objective to prevent negative impact to multiple Availability Zones in the same Region. When a wave deploys to multiple Regions in parallel, it follows the same cautious rollout behavior for each Region that was used in the initial waves. Each step in the wave only deploys to a single Availability Zone or cell from each Region in the wave.