Mensajes

Es lo que vengo aconsejando a muchos conocidos desde hace la tira de años, que tapen la cámara con un simple post-it, de esos semitranslúcidos.

...sin embargo es enormemente criticable que el propio hardware, no traiga una simple ventanita deslizante, giratoria, etc... que imposibilite que incluso aunque un intruso llegara a activar la cámara, pudiera enfocar al usuario. Y dado lo sencillo y barato dle sistema, cabe preguntarse por qué... por qué no lo hacen. Es simple y llanamente: negligencia.
Si un día utilizan tu cámara sin tu permiso, desde luego yo pondría una denuncia al fabricante, precisamente por negligencia, es algo tan simple y lógico de prever, que no ponerle remedio responde exclusivamente a negligencia.

...pero la gente se ha acostumbrado (YA) a tragar por el 4N0... 

Cuántas vueltas...
Bastaba decir que se basa en la arquitectura ARM Cortex-A53, que no se ve afectada por dichos problemas (exactamente la misma que mi tf. y otros muchos modelos), tal y como publicó ARM.

mmm... "nomofobia"?. Ese palabro parecería tener sentido para un significado tipo: "fobia a los gnomos de jardín". aunque al caso, mejor si fuera gnomofobia.

En cualquier caso, el sufijo 'fobia' es miedo... sería la antítesis a la adicción...

Quizás la palabra adecuada fuera mejor algo como: "fonoadicto".

Sin llegar a acusación, si no solo sospechas... Creo que Mediakarkt, realiza ofertas falsas con la única finalidad de captar clientes...

En dos ocasiones este año pasado, me ha sucedido ver una oferta que me pareció interesante y justo el mismo día de la oferta (o al día siguiente, pero en ofertas que duran entre 7 y 15 días)), intentar hacer la compra, con un subsiguiente mensaje de: "Stock agotado"... que sería la forma en que limitan la posibilidad de que alguien acceda a dicha oferta falsa, irreal...
...en esa línea es que creo que se encuentra este caso que se comenta en la noticia, solo que al poner la 'oferta falsa', han fallado  (olvidado desviar) en dirigir el pedido a la respuesta de: "stock agotado"... lo habrán procesado y solo cuando se han dado cuenta de que no frenaron para esa 'oferta', es cuando han decidido liquidar por las malas el asunto...

Mmmmm... se te ha olvidado una cuestión importante: ¿para qué quieres hacer eso?.

Y te señalo por qué es importante.
Supongamos que tu idea es intentar bloquear "programas maliciosos", en este caso, lo más probable es que no sea efectivo al 100%. y te lo razono.
Imagina un programa malicioso, supera cierto nivel de carga de CPU y lo matas, ok... 1 minuto después ahí está otra vez... entonces aunque sea con interrupciones, su tarea sigue adelante, solo que más demorado en el tiempo.

Un programa malicioso, en general si está medianamente bien programado, no opera sólo, siempre están al acecho, son otros ejecutables los que lo lanzan y que 'pasan' por 'buenos', nada raro ni sospechoso en ellos se detecta... es decir el programa que ejecuta la tarea maliciosa, es 'contratado' por otro programa que lo pone en marcha (algo así como cuando alguien contrata un asesino para matar. Él que quiere que muera alguien y la persona que lo mata, si no quiere (ensuciarse las manos y arriegarse a) ser descubierto, es otra, no la misma. Más aún ni siquiera 'habla' directamente, con el que hace el 'trabajo sucio', si no que busca un intermediario...

Así, resumiendo: un programa malvado (A), tendrá una apariencia limpia, y su única tarea será arrancar otro programa (B). Es B, quien de cuando en cuando revisa si el programa que hace el trabajo sucio (C), está en marcha o no, y si no lo está lo manda ejecutar... Así si ya resulta difícil asociar B con C, mucho más A con C.

Luego en efecto matar un proceso, no es todo lo efectivo que es deseable si el objetivo de tu programación, es librarte de procesos 'maliciosos' o solo 'indeseables'. Debes investigar el padre del (proceso) mismo y a su vez al padre de ése y así respectivamente. A veces no es fácil, porque resulta difícl rastrear sin meterse a fondo en el tema. Un programa puede arrancarse, realizar alguna ejecución y luego pararse... al caso, entonces resulta conveniente consultar las tareas programadas... A veces incluso un programa descomprime de un archivo cifrado, otro y lo ejecuta... más aún imagina por ejemplo que tengo dos ficheros, un ejecutbale maligno y un fichero comprimido en zip, rar, 7z, etc... le das una orden de extracción al mismo y a su vez tras ser extraído, es autoejecutado (caso típico de instaladores, que descomprimen y/o decodifican y se ejecutan), tras lanzar esto se desvincula de su marcha y s epara, así la autoría incluso parecerá proceder de winrar, winzip, sevenzip, etc... para todo ello, como te decía debes meterte a fondo y suscribirte a eventos de carga de procesos, peor incluso así, hay virus que se las apañan, para saltarse el control del sistema...

En definitiva, según para qué lo quieras, lo que tienes es suficiente o te quedas a medias. Si por ejemplo tu idea es matar procesos de programas que mina (criptomonedas) en tu equipo (tan de moda en los últimos meses), si es abusivo, puede ser efectivo, pero si no pone el procesador a un nivel muy elevado (digamos que lo deja en un 3-7%), seguirá ahí latente... y si pretendes matar procesos que sobrepasen un 5%, básicamente te vas a cargar a todos, porque en algún momento, todos los programas alcanzan ese valor y lo superan intentasamente.

Sería más sensato, hacer estadísticas, es decir descubrir procesos que sobrepasen ciertos umbrales y registrarlos (nombre de procesos, valores alcanzados y tiempo que permanecen por encima de cierto umbral y frecuencia con que esto sucede), al tiempo consultar dicha estadística y sacar conclusiones... después de eso se supone que lo que hagas tendrá una lógica más acorde que la simpleza de matar al que 'se rebela'...

Por otro lado hay programas legítimos, que en algún momento dado pueden tener picos de trabajo y en general tiene programado que si se para se ponga de nuevo en marcha... hasta x veces, luego ya no se vuelve a cargar hasta la próxima sesión... pero como decía si es legítimo, puede que al matarlo estés impidiendo alguna acción absolutamente necesaria que podría incluso colgar el sistema o generar un reinicio.

...hay más tela que cortar al respecto, pero tampoco es plan de que te sientas atosigado, con toda la panoplia de características...

Uhmmmm... el texto es insuficiente no da detalles precisos, resulta vago, veo de descargarme el vídeo para verlo en otro momento con tiempo... peor creo que no van en la 'buena dirección'...

La solución tiene que ser HARDWARE, de fábrica, nada de webs, ni correos ni leches. Todas las capas que se quiera encima, pero si al fondo no está basado en HARDWARE, siempre será penetrable.

Imagino que el "programo" siendo de La India, estará diseñado y programado íntegramente por hindús... esos que se rifan muchas empresas, por... ¿cómo era?... ah sí, sólo por ser de La India (como si por ello, todo hindú fuera a ser una encarnación del propio Ramanujan).

"Estamos trabajando para..."

En España, lo llamamos "bajada de pantalones" (para poner el culo y que te den por ahí)...

Pués no... Hoy día los motores de explosión se utilizan para los vehículos... si el día de mañana alguien encuentra una utilidad alternativa aunque no sea eficiente, los usará, al tiempo habrá (se crearán) equipos especializados al propósito nuevo, que se ajustan específicamente a ello, entonces que luego los fabricantes de motores de explosión, hagan un giro a sus diseños apra que valgan tanto para vehículos como para esa nueva iniciativa, es tetgiversar el diseño del mismo, para en efecto la demanda alcance a todos y el precio se eleve, pagando todos la demanda de otros... y que en efecto, jamás será igual que una solución dedicada al efecto.

Un ejemplo idéntico fue el caso cuando países como Brasil decidieron usar alcohól de cerales como combustible... ¿os acordais cual fue el resultado?????. Para los que no,... pués que el precio de los cereales para la alimentación se disparó...

No es tan difícil de entender jolín...

¿Qué opinaís?

No. No es suficiente, el problema es del procesador, no del navegador, el navegador a lo sumo puede complicarlo. Puedes eso sí desactivar javascript, pero es que es prácticamente imposible moverse por la red hoy día sin javascript, florece como los hongos... Pero al desactivarlo en el mejor de los caso, muchos scripts no podrán ejecutarse (por ejemplos ver vídeos), en el peor ni siquiera logras que aparezca la página si dicha página está basada de principio a fin en javascript...

Solución efectiva no ahí... de momento, lo que he leído que están haciendo parches (software), para separar el área de memoria restringida en el Kernel, en 2, dejando fuera el área del usuario... todo ello (según se realice) puede conllevar mucha sobrecarga al tener que estar cargando y descargando zonas concretas... puede haber pérdidas de rendimiento o no, ya veremos como lo resuelven a nivel S.O. Piensa que una solución a nivel del S.O. no puede aceptarse como una solución real, el S.O. no puede cubrir con igual eficacia, un asunto que realmente compete al procesador. Una intrusión en un equipo, podría explotar la vulnerabilidad 'deshaciendo' los cambios aplicados por el S.O.  por eso digo que no es una solución real, solo un parche... vamos como pegar un chicle bajo e depósito de gasolina de un vehículo en medio del desierto... un parche, valdrá para muchos, pero no para todos.

La solución definitiva, creo que jamás llegará, porque eso supone un remplazo del procesador... y ... ¿quién cree que Intel, AMD, etc... van a cambiar casi todos los procesadores del planeta???... en realidad deberían, son productos defectuosos de fábrica... pero tocará 'ajo y agua', y 'contentos' si el S.O. logra sacar algo eficaz para tu versión...