#appsecurity — Public Fediverse posts on home.social

Boston Security Meetup @[email protected] · 2026-05-14 · 16:01 UTC

Thank you to 7AI for making our May meetup possible!

This month's meetup we have Anshumaan Mishra who will talk about securing FastAPI Email WebApp while Will Lefevers will show us How the internet enables organized cyber-crime

RSVP at - https://buff.ly/ydemfjY

#security #appsecurity #aisecurity

infosertecla.com @[email protected] · 2026-03-06 · 14:00 UTC

Google comienza a señalar a las «apps vampiro» – La Play Store ya muestra advertencias de alto consumo de batería

Se acabó el anonimato para las aplicaciones mal optimizadas. Tal como se anunció a finales de 2025, Google ha comenzado a implementar este 5 de marzo de 2026 una de las funciones más esperadas por los usuarios: avisos visuales directos en la Play Store que alertan si una aplicación consume más batería de lo normal debido a una actividad excesiva en segundo plano (Fuente Google).

Esta medida, busca presionar a los desarrolladores para que optimicen sus creaciones y ofrecer transparencia total a los usuarios antes de que pulsen el botón de instalar.

¿Cómo funciona la advertencia?

La alerta aparece en un cuadro destacado justo debajo de la calificación por estrellas y los datos de descarga de la aplicación. El mensaje es claro: “Esta aplicación puede usar más batería de lo esperado debido a una alta actividad en segundo plano”.

Este aviso no es aleatorio, sino que se basa en métricas técnicas estrictas recogidas por Android Vitals:

El umbral del «Wake Lock»: Google penaliza a las apps que mantienen el procesador encendido (mediante partial wake locks) durante más de dos horas acumuladas en un periodo de 24 horas mientras la pantalla está apagada.
Consistencia en el mal comportamiento: La advertencia solo aparece si el 5% de las sesiones de usuario de esa app superan dicho límite de consumo en los últimos 28 días.

Castigo doble: Menos visibilidad y advertencias rojas

Las aplicaciones que superen estos umbrales de «mala conducta» no solo recibirán el distintivo de advertencia, sino que también sufrirán en su posicionamiento:

Exclusión de recomendaciones: Las apps identificadas como «vampiras de batería» dejarán de aparecer en las listas de recomendaciones y sugerencias de la Play Store.
Impacto en búsquedas: Google reducirá su visibilidad en los resultados de búsqueda, priorizando alternativas que demuestren ser más eficientes energéticamente.

Colaboración con Samsung

Un dato relevante es que este nuevo sistema de medición ha sido desarrollado en conjunto con Samsung. El gigante coreano aportó datos del mundo real sobre la experiencia de sus usuarios con el drenaje de batería, ayudando a Google a ajustar los algoritmos para que la advertencia sea lo más precisa posible y no castigue injustamente a apps que necesitan procesos de fondo legítimos (como reproductores de música o navegadores GPS).

¿Qué deben hacer los desarrolladores?

Para eliminar este «sello de la vergüenza», los desarrolladores deberán auditar sus procesos de fondo y reducir el uso innecesario de energía. Google ha proporcionado nuevas herramientas de depuración para que puedan identificar exactamente qué proceso está impidiendo que el teléfono entre en modo de suspensión (deep sleep).

Con esta actualización, Google da un paso definitivo para resolver una de las quejas históricas de Android: la variabilidad en la duración de la batería causada por aplicaciones de terceros que «secuestran» los recursos del sistema sin que el usuario se dé cuenta.

#android #AndroidVitals #AppSecurity #arielmcorg #Batería #google #infosertec #innovación #PlayStore #PORTADA #Samsung #TechNews2026 #tecnología

#android #androidvitals #appsecurity #arielmcorg #bateria #google

xoron :verified: @[email protected] · 2025-06-28 · 18:58 UTC

Are Web Components & Cybersecurity A Better Combo?

I'm not trying to dunk on popular #UI #frameworks – I'm sure they're totally fine for #cybersecurity stuff, probably get loads of reviews and #audits.

But from my angle: Web Components are *native* to the #browser. Doesn't that just inherently reduce the risk of **#SupplyChainAttacks** (you know, like a rogue `npm install` on a bad network) for your #AppSecurity?

Or am I overthinking it, and the #framework choice is less important than the #browser, #OS, or #device running it? What are your thoughts, #DevCommunity?

---

Quick context: I've got a #ReactJS #messagingApp (repo here: https://github.com/positive-intentions/chat) and a separate #UIFramework (repo here: https://github.com/positive-intentions/dim) built with #Lit (which uses Web Components). I'm genuinely wondering if there's a compelling #cybersecurity reason to refactor the chat app to use my #WebComponent UI framework. Might be a whole new level of #SecurityByDesign for #FrontEndDev.