Facebook is listening to you, what can you do to avoid this?

Nowadays, a lot of people is talking about a «conspiracy» that Facebook is denying constantly. Is Facebook listening to us? What can we do to avoid this? Let’s see what are the questions and the answers:

What is people saying?

People say that Facebook apps installed on our mobiles are recording our conversations, analyzing what we say and using this to target their ads.

What is the response from Facebook?

Facebook denies all of those accusations.

Is it technically possible?

Well, record all conversations and send them requires a lot of bandwidth. We are not talking about Echelon, neither recordings made by Google Now assistant. We are talking about all the conversations you maintain all the time, all the dialogues from the TV shows you are seeing and conversations from people near you.

What is the bandwidth you bought from your provider? 1Gb? 3Gb? 10Gb? It doesn’t matter. It is not enough to listen Spotify constantly, so it is not enough to send recordings with your full conversations.

Some people are saying that they record the conversations, analyze those using your mobile phone resources and get keywords that they can send to Facebook servers.

This theory is better but battery consumption… I don’t know.

Does it really matter?

Facebook has all your written conversations, it is the owner of Facebook, Messenger, WhatsApp, Instagram, … It also owns your photos, videos, relations, … Facebook knows who is the first person who you talk every day, also knows what websites you visit and also the visits from your mom or your grandpa.

Facebook is not the only one who knows. Did you visit the link about Google records above? It’s the tip of the iceberg.

So it doesn’t matter if Facebook is listening and recording you. They know everything about you. All great companies know everything about you, so it doesn’t matter.

The only way you can follow to avoid this is become offline, at least offline from their apps and services. Are you prepared to be disconnected from your friends and family? If not, you can’t be safe.

 

Roles en Scrum

Cuando se ofertan puestos etiquetándolos con roles de Scrum, implícitamente se están asignando unas responsabilidades y excluyendo otras. En muchos sitios, aunque digan que hacen Scrum, no lo hacen y mezclan las cosas. Veamos qué papel desempeña cada uno de los roles de Scrum, para poder identificar de un modo sencillo en qué sitios se aplica bien y en qué sitios no.

scrum photo
Photo by royskeane

Para que nadie se lleve a equívocos, aclararé que en mi opinión Scrum no es la panacea, que no es lo más adecuado en todos los casos, y cada equipo y cada empresa es un mundo. Sin embargo, sí que creo que para hacer Scrum hay que aplicarlo como mandan los cánones, y si no no pasa nada, pero no será Scrum. Será otra cosa.

 

  • Product Owner: el Product Owner puede verse como el bus de comunicaciones. Es la representación de los clientes, sponsors y otros stakeholders dentro del proceso de desarrollo. Es quien habla con todos ellos y transmite sus inquietudes al equipo que es quien ejecuta. Es el dueño del Backlog, se encarga de recoger las historias de usuario y establece sus prioridades. Es quien propone qué historias (al establecer su prioridad) deberían de atajarse en el siguiente Sprint. Es quien toma decisiones cuando surgen conflictos, ya sea por decisión propia o porque haya consultado a los stakeholders que corresponda.
  • Scrum Master: el Scrum Master es el amo del calabozo, ese hombre que aparece dando consejos. Su misión es ser el guardián del método, asegurarse de que se cumplen con las “normas” del Scrum. Es quien se garantiza la forma de  las ceremonias, de que no se excedan los tiempos, de que si el Product Owner intenta cambiar el Backlog del Sprint es quien le explica que así no se puede trabajar ni bien, ni rápido.
  • Equipo: son todas las personas productivas que participan en el proceso de desarrollo. Se auto organizan y autogestionan. Son quienes deciden sobre su proceso y tienen la última palabra sobre todo (al fin y al cabo lo van a hacer ellos), aunque atiendan los consejos del Scrum Master, y trabajen con las limitaciones y objetivos que marque la persona que sea Product Owner.

 

Hay quien a los stakeholders (clientes, sponsors, etc.) los incluye también, pero estos no participan del proceso de Scrum. En algunos casos participan en las demos, pero lo suyo es que sea el Product Owner el que actúe ahí como una voz única, para asegurarse de que al equipo se le dice una única cosa.

Así, pues, estos son los roles en Scrum. No son otros, son estos y estas son sus funciones, y tienen un motivo. No es bueno que una persona cubra dos roles porque entonces va a empezar a tener conflictos de intereses, y por flexible que sea, el estar cambiándose de sombrero continuamente le pasará factura y no podrá concentrarse en ninguna de las funciones que debe realizar.

Por tanto, si hacéis Scrum, mantendréis esta separación de roles, y si no no pasa nada, pero no estaréis haciendo Scrum, será otra cosa.

Gmail Add-ons: How-to be on all desktops and mobiles with a simple app

Some weeks ago, Google opened the possibility of create Gmail add-ons for all developers. Let’s see what are the possibilities and how to create and distribute our own Gmail add-on.

This is not a very hard and abstract post, add-ons are something easy, so I hope my explanation to be simple too. It is based on an add-on created by myself that allows any user adding an email to Google Tasks (probably it is more useful than the add-on for MSN Messenger that I created years ago which read received messages with «real» voice). It is a functionality that has been always present on Gmail web client but that is not available on mobile clients.

In order to create a Gmail add-on you need to create a new Google Apps Script project. After that you can add as much scripts as you want to create an interface using Cards and the functionality to interact with other services, APIs and so.

For instance, in our example the functionality is very basic:



function getContextualAddOn(e) {
  var message = getMessage(e);
  var subject = message.getSubject();
  var permaLink = message.getThread().getPermalink();
  
  var card = CardService.newCardBuilder();
  card.setHeader(CardService.newCardHeader()
                 .setTitle('Save as task'));
  var section = CardService.newCardSection();
  
  var button = prepareSend(permaLink);
  section.addWidget(button);
  
  section.addWidget(prepareList());
  
  section.addWidget(prepareTitle(subject));
  
  section.addWidget(prepareDueDate());
  
  section.addWidget(button);
  
  section.addWidget(prepareSign());
  
  card.addSection(section);
  console.log("Open");
  return [card.build()];
}

function getMessage(e){
  var accessToken = e.messageMetadata.accessToken;
  GmailApp.setCurrentMessageAccessToken(accessToken);
  
  var messageId = e.messageMetadata.messageId;
  return GmailApp.getMessageById(messageId);
}

function prepareSend(permaLink){
   var action = CardService.newAction()
  .setFunctionName("saveTask")
  .setParameters({permaLink: permaLink});
  return CardService.newTextButton()
                    .setText("Save")
                    .setOnClickAction(action);
}

function saveTask(e){
  var res = e['formInput'];
  var task = Tasks.newTask();
  task.title = res["title"];
  task.notes = e['parameters'].permaLink;
  
  if(res["due-date"] && res["due-date"] != "")
    task.due = res["due-date"] + "T00:00:00Z"
  
  task = Tasks.Tasks.insert(task, res["list"]);
  console.log("Saved");
}

function prepareList() {
  var response = Tasks.Tasklists.list();
  var taskLists = response.items;
  var dropdown = CardService.newSelectionInput()
     .setType(CardService.SelectionInputType.DROPDOWN)
     .setTitle("List")
     .setFieldName("list");

  if (taskLists && taskLists.length > 0) {
    Logger.log('Task lists:');
    for (var i = 0; i < taskLists.length; i++) {
      var taskList = taskLists[i];
      Logger.log('%s (%s)', taskList.title, taskList.id);
      dropdown.addItem(taskList.title, taskList.id, i==0);
    }
  } else {
    Logger.log('No task lists found.');
  }
  return dropdown;
}

function prepareTitle(subject){
  return CardService.newTextInput()
                    .setFieldName("title")
                    .setTitle("Title")
                    .setValue(subject)
}

function prepareDueDate(){
  var d = new Date();
  var dd = new Date(d.setDate(d.getDate() + ( 7 - d.getDay()) % 7));
  return CardService.newTextInput()
                    .setFieldName("due-date")
                    .setTitle("Due date")
                    .setValue(dd.getYear() + "-" + (dd.getMonth() + 1) + "-" + dd.getDate())
                    .setHint("YYYY-MM-DD");
}

function prepareSign(){
  var button = CardService.newTextButton()
     .setText("@JaviLopezG")
     .setOpenLink(CardService.newOpenLink()
         .setUrl("https://javilopezg.com/")
         .setOpenAs(CardService.OpenAs.OVERLAY)
         .setOnClose(CardService.OnClose.RELOAD_ADD_ON));
  return CardService.newKeyValue()
     .setContent("Developed and maintained by")
  .setButton(button);
}

You also have to change script’s manifest. To do this you need to access to the menu «View>Show manifest file». Now you can modify it as you want, following our example you have to replace the content with following lines:

{
  "timeZone": "GMT",
  "dependencies": {
    "enabledAdvancedServices": [{
      "userSymbol": "Tasks",
      "serviceId": "tasks",
      "version": "v1"
    }]
  },
  "oauthScopes": ["https://www.googleapis.com/auth/gmail.addons.execute", "https://www.googleapis.com/auth/gmail.addons.current.message.readonly", "https://www.googleapis.com/auth/tasks"],
  "gmail": {
    "name": "Save as task",
    "logoUrl": "https://i0.wp.com/javilopezg.com/wp-content/uploads/2017/11/save-as-tag-ico-24.png",
    "contextualTriggers": [{
      "unconditional": {
      },
      "onTriggerFunction": "getContextualAddOn"
    }],
    "primaryColor": "#000000",
    "secondaryColor": "#888888",
    "version": "TRUSTED_TESTER_V2",
    "openLinkUrlPrefixes": [
      "https://javilopezg.com/"
    ]
  }
}

As soon as you save all changes you are ready to publish your add-on. Unfortunately the Gmail add-ons store is not publicly available yet. However, you can get the ID of your add-on and distribute it to your company co-workers in order to allow them install your add on in their gmail accounts. See images below:

Gmail Add-on ID
Gmail Add-on ID
Add-ons in Gmail settings
Add-ons in Gmail settings

I know that it’s frustrating not being able to publish an add-on to all gmail users around the world yet. Anyway, I already have two cool ideas to implement as soon as I was able to distribute it at least to my friends. Something to draw an ordered tree of a conversation thread and an add-on to respond an e-mail with a video in an easy way. And you? What ideas are coming to your head?

PoW vs PoS

Cuando hablamos del Cryptojacking y de la minería, pasamos de puntillas un concepto que afecta a como se valida cada uno de los bloques de un blockchain. Es la «prueba«, y aunque en la mayoría de blockchains se usa Proof of Work, son muchos los expertos que apuntan a la necesidad de pasar a blockchains que usen Proof of Stake. Veamos en que se diferencian y el porqué de la necesidad de este cambio.

military byzantine photo
Photo by Internet Archive Book Images

Aunque inicialmente pueda parecer algo super técnico, como habéis ido viendo en otros posts relacionados con el tema, los blockchains son sistemas realmente básicos, aunque se tiene que enfrentar a los problemas típicos de los sistemas distribuidos que ya vimos cuando tratamos los patrones cloud.

En concreto, estas pruebas son soluciones al problema de consenso que normalmente se ejemplifica con el problema de los generales bizantinos. En este problema se busca la coordinación de varios jefes militares que intentan atacar o retirarse de un modo conjunto. Su aplicación mediante estas «pruebas» a los blockchains, sirve para la toma de decisiones en un entorno distribuido como este.

La prueba de trabajo (Proof of Work), se basa en el cálculo de un hash que «cierre» el bloque. Por tanto, el sistema que encuentra el hash valido es el que tiene la última palabra en cuanto a las operaciones registradas en dicho bloque.

Pongamos que hay un blockchain en el que participan Alberto, Braulio, Carlos, Diego y Esteban. Cada uno le manda al siguiente en la lista una moneda, pero Carlos no se ha enterado de que Esteban le ha mandado una moneda a Alberto. A la hora de minar, todos se ponen a buscar un hash de un bloque que almacenará 5 operaciones, menos Carlos que sólo ha recibido información de 4. Si el primero en lograr su trabajo es Diego, el hash que encuentre será de las 5 operaciones y por tanto las 5 quedarán confirmadas. Por el contrario, si quien logra dicha labor es Carlos, sólo 4 operaciones quedarán confirmadas y el envío de Esteban a Alberto deberá volver a realizarse.

En este tipo de pruebas toma la decisión el primero que consigue realizar un trabajo más o menos complejo como es el cálculo de ese hash.

La prueba de participación (Proof of Stake), se basa en la participación de los distintos componentes en el sistema. Depende del blockchain se tienen unas normas u otras (aunque podéis entrar en detalle en como será Ethereum cuando pase a PoS), pero en general se presupone que los elementos más partícipes (porque tengan más dinero, hagan más operaciones, etc.) son los principales interesados en que todo funcione correctamente y se haga del modo más limpio. Por tanto, estos se convierten en validadores que pueden recibir el «honor» de dar por bueno un bloque ya sea de manera aleatoria, rotativa, por votación…

De nuevo pensemos en un blockchain, pero en este participan Alba, Barbara, Carla, Diana y Ester. Cada una tiene el doble de monedas que la anterior en este blockchain, que está «gobernado» por un PoS en el que determina el bloque quien más dinero tenga. Si en cada transacción cada una le envía a la anterior la mitad de sus monedas, el primer bloque lo decidirá Ester, pero el segundo lo decidirá Diana por ser la nueva mayor participante. Por tanto, primero Ester y después Diana serán quienes decidan que operaciones quedan confirmadas, asumiéndose que al ser las mayores poseedoras de esta criptomoneda, son también las principales interesadas en que funcione bien y sea un sistema de fiar.

Aunque los dos tipos de prueba tienen sus cosas buenas y malas, hay una en la que PoS gana de calle a PoW y que nadie podrá rebatir. Es el consumo de electricidad gastado para realizar estos trabajos. Con cada bloque de la cadena todos los mineros se ponen a buscar el hash que toque, pero sólo uno lo consigue, por lo que todo el tiempo de cálculo anterior ha sido completamente inútil para todos menos uno. Por ejemplo, si atendemos a los Bitcoins, el consumo energético de este blockchain es similar al de Nigeria, o la electricidad que se emplea para una sola transacción de Bitcoin serviría para proveer a una casa durante un mes.

Espero haberos explicado de un modo suficientemente claro estos conceptos y el porqué de este debate, como para que podáis entrar en él. ¿Hay algún concepto que creáis que es importante aclarar?