Google trabaja en una función para conectar Android 12 y Chrome OS similar al Handoff de Apple: espejar apps y contestar llamadas

Google trabaja en una función para conectar Android 12 y Chrome OS similar al Handoff de Apple: espejar apps y contestar llamadas

Las versiones beta de las apps son una gran fuente de información pues los desarrolladores, en este caso el equipo de Google, no dudan a la hora de introducir código de prueba aunque no se encuentre aún activo. Así es cómo se ha detectado que desde Google trabajan en una función parecida al Handoff de Apple pero para Android y Chrome OS.

Desde hace tiempo, Google está enfrascado en mejorar la interacción entre sus dos principales sistemas operativos, Android y Chrome OS. Ahora parece que habrá un nuevo avance en ese ‘Better Together’ y llegará en forma de función ‘Push’. Y esta función Push, según se atisba en el código extraído por 9to5Google, permitirá espejar nuestro teléfono Android en un Chromebook.


Continue reading →

HTC A100: la primera tablet de HTC es de gama media, con pantalla de 10,1 pulgadas y procesador Unisoc

HTC A100: la primera tablet de HTC es de gama media, con pantalla de 10,1 pulgadas y procesador Unisoc

HTC acaba de anunciar su primera tablet desde hace muchos años, la nueva HTC A100. Se trata de una tablet sencilla y de diseño algo sobrio, que por el momento es oficial es Rusia, sin que sepamos si se venderá en otras regiones.

La HTC A100 es una tablet de gama media que incluye el virtualmente desconocido procesador Unisoc T610, con una buena cantidad de RAM y almacenamiento, pantalla Full HD+ de 10,1 pulgadas y batería de 7.000 mAh.


Continue reading →

Android 12 estable será oficial a principios de octubre, según XDA

Android 12 estable será oficial a principios de octubre, según XDA

Con la última beta 5 de Android 12 ya disponible, Google nos avisó que era “cuestión de semanas” que se produjera el lanzamiento oficial de Android 12, aunque sin una fecha concreta. Ahora tenemos una posible fecha concreta del lanzamiento de Android 12, gracias a unos documentos obtenidos por XDA.

El documento en cuestión muestra las fechas en las que dejarán de aprobar versiones de software basadas en distintas versiones de Android. De su información se desprende la posible fecha del 4 de octubre para el lanzamiento de Android 12.


Continue reading →

Android 12 estable será oficial a principios de octubre, según XDA

Android 12 estable será oficial a principios de octubre, según XDA

Con la última beta 5 de Android 12 ya disponible, Google nos avisó que era “cuestión de semanas” que se produjera el lanzamiento oficial de Android 12, aunque sin una fecha concreta. Ahora tenemos una posible fecha concreta del lanzamiento de Android 12, gracias a unos documentos obtenidos por XDA.

El documento en cuestión muestra las fechas en las que dejarán de aprobar versiones de software basadas en distintas versiones de Android. De su información se desprende la posible fecha del 4 de octubre para el lanzamiento de Android 12.


Continue reading →

Para qué sirve liberar memoria RAM en el móvil y cómo se hace

Para qué sirve liberar memoria RAM en el móvil y cómo se hace

La memoria RAM es uno de los elementos clave en nuestro teléfono móvil. La falta de la misma es una de las peores noticias, ya que notaremos cómo cae el rendimiento y la experiencia de usuario. Es por ello que vamos a explicarte para qué sirve liberar memoria RAM y cómo se hace.

Hay varias formas de controlar la memoria RAM en nuestro terminal, más allá de los métodos que seguramente conozcas. Vamos a comentarte en primer lugar por qué puede ser necesario liberar memoria RAM, para más adelante contarte cómo hacerlo.


Continue reading →

Pacstall pretende ser un AUR para Ubuntu. ¿Lo consigue?

Pacstall

En cualquier distribución Linux se puede instalar software por distintos medios. Uno es el de los repositorios oficiales, pero también podemos usar paquetes flatpak, snap y AppImage, entre otros. Además de todo esto, Arch Linux tiene AUR, un repositorio de la comunidad en el que encontramos prácticamente todo el software que existe para Linux y que, si no sabemos compilar, podemos gestionar con yay. Por ejemplo, en AUR encontramos extensiones para GIMP que de otra manera tendríamos que buscar, por lo que es la envidia de otras distribuciones. Para intentar suplir esta carencia en Ubuntu existe Pacstall.

Sobre el papel, Pacstall tiene muy buena pinta. Se supone que es una herramienta para automatizar instalaciones de software alojado en GitHub o GitLab en Ubuntu. Nació hace algo más de un año, por lo que podríamos decir que está dando sus primeros pasos, pero, por lo menos ahora mismo, a los usuarios de un sistema operativo basado en Arch sólo puede hacernos gracia por la enorme diferencia.

Pacstall tiene su propio repositorio y se pueden añadir más

El equipo de Pacstall está subiendo los paquetes al repositorio oficial del proyecto, y esta es la principal diferencia con respecto a AUR. El repositorio de la comunidad de Arch lleva años existiendo, y allí se encuentra de todo. En lo que pretende ser su equivalente para Ubuntu llevan subiendo paquetes muy poco tiempo, por lo que la lista de paquetes disponibles es corta.

La duda que tengo al haberlo probado y leído por encima su documentación es cómo será en el futuro. Esta especie de gestor de paquetes permite añadir repositorios, pero en estos momentos la instalación falla porque falta el archivo pacscript necesario para instalar los paquetes. Si en el futuro corrigen esto (o si estoy haciendo algo mal y alguien sabe lo que es, que me lo diga), quizá no sea AUR, pero sí una herramienta muy interesante.

¿Y cómo funciona?

Lo primero que hay que hacer es instalarlo, algo que conseguiremos abriendo un terminal y escribiendo estos comandos:

sudo apt install curl
sudo bash -c "$(curl -fsSL https://git.io/JsADh || wget -q https://git.io/JsADh -O -)"

A partir de ahí, el resto es como apt, pacman, dnf, etc, pero a su manera:

  • pacstall seguido de:
    • -I: instalará el paquete.
    • -R: eliminará el paquete.
    • -S: buscará en los repositorios.
    • -A: añadirá un repositorio de GitHub o GitLab.
    • -U: actualizará los scripts de pacstall.
    • -Up: actualizará los paquetes.
    • -h: ayuda.

Si queremos desinstalarlo, lo que tenemos que escribir es lo siguiente:

bash -c "$(curl -fsSL https://git.io/JEZbi || wget -q https://git.io/JEZbi -O -)"

Estaría bien que Ubuntu tuviera su propio AUR, y no sé si Pacstall llegará algún día a parecerse aunque sea mínimamente. De momento sí hay paquetes como Android Studio o Google Chrome. Si la comunidad se va apuntando a colaborar, veremos hasta dónde llega este proyecto.

from Linux Adictos https://ift.tt/3yZVJ41
via IFTTT

Actualizaciones de Android: cuántos años promete cada fabricante de móviles

Actualizaciones de Android: cuántos años promete cada fabricante de móviles

Las actualizaciones de Android llegan cuando llegan, y eso si llegan. La buena noticia es que en los últimos meses varias marcas han anunciado que extienden el soporte para actualizaciones de Android y de seguridad de, al menos, algunos de sus móviles.

Si has perdido la cuenta de quién ofrece qué, aquí recopilamos la información más actual sobre cuántos años de actualizaciones promete cada fabricante y la letra pequeña detrás de cada de estas afirmaciones.


Continue reading →

Microsoft contra el SVR. Por qué el código abierto debería ser la norma

Microsoft contra el SVR

Podría haber sido una novela de Tom Clancy de la serie NetForce, pero es un libro escrito por el presidente de Microsoft Brad Smith en homenaje a si mismo y a su empresa. De todas formas, si uno lee entre líneas (al menos en el extracto al que tuvo acceso un portal) y separa las auto palmadas en la espalda y los palos a los competidores, lo que queda es muy interesante e instructivo. Y, en mi humilde opinión, una muestra de las ventajas del modelo de software libre y de código abierto.

Los personajes

Toda novela de espionaje, necesita un «malo» y, en este caso tenemos nada menos que al SVR, una de las organizaciones que sucedieron al KGB después del colapso de la URSS. El SVR se ocupa de todas las tareas de inteligencia desarrolladas fuera de la frontera de la Federación Rusa. La «víctima inocente» fue SolarWinds, empresa que desarrolla un software para administración de redes utilizado por grandes empresas, administradores de infraestructuras críticas y agencias del gobierno estadounidense. Por supuesto, necesitamos un héroe. En este caso, según ellos mismos, es el Departamento de Inteligencia de Amenazas de Microsoft.

Como no podía ser de otra manera, en una historia de hackers, el «malo» y el «bueno» tienen un alias. El SVR es Yttrium (Itrio). En Microsoft utilizan los elementos menos comunes de la tabla periódica como nombre clave para los posibles orígenes de amenazas. El Departamento de Inteligencia de Amenazas es MSTIC por sus siglas en inglés, aunque internamente lo pronuncian mystic (místico) por la similitud fonética. En adelante, por comodidad voy a usar estos términos.

Microsoft contra SVR. Los hechos

El 30 de noviembre de 2020 FireEye, una de las principales empresas de seguridad informática de EE.UU, descubre que había sufrido una brecha de seguridad en sus propios servidores. Como eran incapaces de solucionarlo por si mismos (Lo siento, pero no puedo dejar de decir lo de «en casa de herrero, cuchillo de palo») decidieron pedir ayuda a los especialistas de Microsoft. Como desde MSTIC venían siguiendo los pasos de Yttrium, enseguida sospecharon de los rusos, diagnóstico posteriormente confirmada por los servicios de inteligencia oficiales de USA.

Con el correr de los días, se comprobó que los ataques estaban dirigidos a redes informáticas sensibles en todo el mundo incluyendo a la propia Microsoft. De acuerdo a trascendidos periodísticos, el gobierno de Estados Unidos era claramente el principal objetivo del ataque, con el Departamento del Tesoro, el Departamento de Estado, el Departamento de Comercio, el Departamento de Energía y partes del Pentágono Por su parte, desde Redmond agregaron a la lista de víctimas docenas de organizaciones afectadas. Entre ellas se cuentan otras empresas tecnológicas, contratistas gubernamentales, grupos de reflexión y una universidad. Los ataques no solo se dirigieron contra Estados Unidos ya que hubo afectados en Canadá, el Reino Unido, Bélgica, España, Israel y los Emiratos Árabes Unidos. En algunos de los casos, las penetraciones en la red se prolongaron durante varios meses.

El origen

Todo comenzó con un software de manejo de redes llamado Orion y desarrollado por una empresa llamada SolarWinds. Con más de 38000 clientes corporativos de alto nivel, los atacantes solo tuvieron que insertar un malware en una actualización.

Una vez instalado, el malware se conectaba a lo que técnicamente se conoce como un servidor de comando y control (C2). El servidor C2 estaba programado para dar al ordenador conectado tareas como la capacidad de transferir archivos, ejecutar comandos, reiniciar una máquina y desactivar los servicios del sistema. En otras palabras los agentes de Yttrium conseguían un acceso total a la red de quienes habían instalado la actualización del programa Orion.

A continuación les voy a citar un párrafo textual del artículo de Smith

No tardamos en darnos cuenta de la importancia del trabajo técnico en equipo en toda la industria y con el gobierno de Estados Unidos. Los ingenieros de SolarWinds, FireEye y Microsoft empezaron a trabajar juntos inmediatamente. Los equipos de FireEye y Microsoft se conocían bien, pero SolarWinds era una empresa más pequeña que se enfrentaba a una gran crisis, y los equipos tenían que crear confianza rápidamente si querían ser eficaces. Los ingenieros de SolarWinds compartieron el código fuente de su actualización con los equipos de seguridad de las otras dos empresas, lo que reveló el código fuente del propio malware. Los equipos técnicos del gobierno estadounidense entraron rápidamente en acción, especialmente en la Agencia de Seguridad Nacional (NSA) y en la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) del Departamento de Seguridad Nacional.

Los resaltados son míos. Eso de trabajo en equipo y compartir el código fuente ¿No les suena de algo?

Después de abrir la puerta trasera, el malware permanecia inactivo durante dos semanas, para evitar crear entradas de registro de red que alertaran a los administradores. Pasado ese lapso, enviaba información sobre la red que había infectado a un servidor de mando y control que los atacantes habían con el proveedor de hosting GoDaddy.

Si el contenido resultaba interesante para Yttrium, los atacantes entraban a través de la puerta trasera e instalaban código adicional en el servidor atacado para conectarse a un segundo servidor de mando y control. Este segundo servidor, único para cada víctima para ayudar a evadir la detección, estaba registrado y alojado en un segundo centro de datos, a menudo en la nube de Amazon Web Services (AWS).

Microsoft contra el SVR. La moraleja

Si están interesados en saber como nuestros héroes dieron su merecido a los villanos, en los primeros párrafos tienen los enlaces a las fuentes. Voy a pasar directamente al motivo por el cuál escribo sobre esto en un blog sobre Linux. El enfrentamiento de Microsoft contra el SVR demuestra la importancia de que el código esté disponible para ser analizado, y que el conocimiento sea colectivo.

Es cierto, como me recordó esta mañana un prestigioso especialista en el tema seguridad informática, que de nada sirve que el código sea abierto si nadie se toma el trabajo de analizarlo. Está el caso Heartbleed para demostrarlo. Pero, recapitulemos. 38000 clientes de alto nivel contrataron un software privativo. Varios de ellos instalaron una actualización con malware que expuso información sensible y dio control a elementos hostiles de infraestructura crítica. La empresa responsable solo puso el código a disposición de los especialistas cuando estaba con el agua al cuello. Si se exigiera a los proveedores de software para infraestructura crítica y clientes sensibles liberar su software con licencias abiertas, y a estos tener un auditor de código residente (o una agencia externa que trabaje para varios) el riesgo de ataques como SolarWinds sería mucho menor.

from Linux Adictos https://ift.tt/3BXBwOe
via IFTTT