Fernik en Geeks·ms : Testing, Beta

Testing Windows 7: PC SafeGuard

Fernik — Sun, 01 Mar 2009 16:03:00 GMT

Si bien me parece un excelente movimiento que Microsoft haya hecho pública y masiva la Beta 1 de Windows 7 hay ciertos aspectos que no se tuvieron en cuenta y que pueden agregar mucho valor al momento de testear Windows 7. Por ejemplo si bien los bits pueden ser descargados todavía desde Microsoft Connect en https://connect.microsoft.com/Downloads/Downloads.aspx?SiteID=704, no hay una manera de retroalimentación, agrupación ni votación como lo hay en la beta del Service Pack 2 de Vista/Server 2008 en donde hay una beta pública y otra privada. Sólo los suscriptores de MSDN y Technet tienen acceso a un mini sitio en Connect que permite votar y proporcionar feedback acerca de los bugs. Lo mejor está en la beta privada en donde hay muchos más recursos y todos podemos compartir los casos de prueba y experiencias de desarrollo con las nuevas APIs. Como me han permitido postear siempre y cuando lo que escriba contribuya a un mejor Testing por parte del público en general, pues aprovecharé esta ocasión para hablar de PC SafeGuard el cual parece que nadie sabe de su existencia y que está necesitando feedback urgentemente.

Windows 7 incorpora nativamente la funcionalidad que se encuentra en Windows SteadyState pero se la ha rebautizado PC SafeGuard. Cabe destacar que SafeGuard no es SteadyState al 100% pero lo importante es que es una característica que está destinada a quedarse, y en versiones posteriores de Windows se alineará por completo con la visión de SteadyState.

Esencialmente PC SafeGuard es como la característica InPrivate Mode + Protected Mode de Internet Explorer 8, pero con un alcance más amplio ya que abarca todo el sistema operativo Windows. SafeGuard tiene como target o como audiencias primarias al comprador de su primer PC, a la PC de familia y a la PC pública. El comprador de su primer PC siempre se enfrenta con la resistencia a interactuar con el sistema por miedo a romper algo, la PC de familia siempre está expuesta al uso por partes de terceros ya sean invitados, niños, personas mayores, etc. Finalmente la PC pública que se encuentra en cualquier escuela o biblioteca, o en un Internet Café es la más promiscua de todas. SafeGuard apunta a que el usuario principiante desarrolle la confianza necesaria y se sienta cómodo para aprender a utilizar Windows en un ambiente temporal con la trnaquilidad de que no se producirán cambios destructivos o escrituras a disco no autorizadas y que los usuarios más avanzados tengan la garantía de que pueden utilizar Windows en un ambiente transitorio sin exponer su información de manera casual.

Para utilizar SafeGuard, debemos estar loguados con un usuario con privilegios administrativos proceder de la siguiente manera:

Crear una cuenta de usuario Standard.

Seleccionar la cuenta de usuario Standard creada para habilitar SafeGuard.

Para usar la cuenta SafeGuard realizar los siguientes pasos:

Cerrar la sesión actual e iniciar sesión con la cuenta SafeGuard.

Luego de iniciar sesión con la cuenta SafeGuard el perfil de usuario es reseteado y cargado. Windows se encarga de informar al usuario sobre SafeGuard.

Finalmente, el usuario está en condiciones de intractuar con Windows cambiando las fuentes, el background, el protector de pantalla, instalando software y escribiendo datos en el directorios ajenos al del perfil del usuario. Windows 7 notificará al usuario constantemente de los posibles riesgos de almacenar datos en cualquier unidad bloqueada por SafeGuard pero en forma no intrusiva.

Si posteriormente se cierra la sesión, toda la información almacenada en los directorios del perfil de usuario se perderá y el sistema volverá a un estado inicial intacto, por eso al usar SafeGuard siempre utilizar almacenamiento externo para trabajar con documentos.

El concepto de diseño de SafeGuard es proveer un entorno Windows que no se dañe cuando se comparte con terceros, por eso:

No se permiten cambios de configuracion en el sistema.
No se permiten instalaciones de software.
No se permite la escritura fuera de los directorios del perfil de usuario.
Los datos en el perfil de usuario son limpiados.
Es compatible con Windows Parental Control.
PC SafeGuard User = Windows Standard User Account + Atribución SafeZone. SafeGuard se manifiesta en el sistema a través de la atribución de cuenta de usuario SafeZone. La atribución SafeZone, permite a los usuarios utilizar el ordenador en modo exploratorio, el cual automáticamente descartará cambios y acciones al cerrar la sesión o desloguearse. La atribución SafeZone sólo se puede activar para la cuenta de usuario standard en Windows 7. Al activarse esta atribución, la cuenta de usuario es añadida a un grupo local de usuarios llamado "SafeZone". Para evitar cambios a nivel de sistema, SafeGuard bloquea todas las unidades de disco locales y carpetas aplicando un ACL de negacion de escritura. Es importante destacar que el hecho de agregar una cuenta de usuario Windows al grupo SafeZone no garantiza que esa cuenta posea la atribución SafeZone. La atribución SafeZone involucra otras cosas aparte de agregar un usuario a un grupo específico con diferentes permisos, por eso siempre activar SafeGuard desde el panel de control.
El volúmen de sistema siempre se bloquea. Otros volúmenes NTFS son bloqueados por defecto y pueden ser desbloqueados mediante la configuracion avanzada "Lock Disk Drives".

Para cerrar les dejo una tabla comparativa de las funcionalidades soportadas por las cuentas SafeGuard y por las cuentas Guest. Analizándola se deduce que una cuenta SafeGuard es más flexible y permisiva(color verde), lo que la hace ideal para ser la nueva cuenta de invitados en Windows para PCs de hogar. Mientras que una cuenta Guest es más restrictiva(color rojo), lo que la hace ideal para ser la cuenta de invitados en un ambiente empresarial.

A continuación les proporcionaré algunos escenarios de prueba para que se entretengan con esta nueva característica, miren que es importante encontrar bugs, sobre todo si son bugs que demuestran que SafeGuard no elimina los rastros de los usuarios que interactuaron con Windows, como aplicaciones instaladas, controles ActiveX, documentos, archivos varios, etc.

Escenario 1: Crear y usar una cuenta de usuario Standard con Safeguard

Comenzar en el escritorio de Windows 7 con un usuario que posea privilegios administrativos.
Visualizar las cuentas de usuario Standard definidas en nuestro ordenador.
Crear una nueva cuenta de usuario Standard.
Activar PC Safeguard en la nueva cuenta de usuario.
Cerrar la sesión actual e iniciar sesión nuevamente pero con la cuenta con PC Safeguard.
Ejecutar cualquier aplicación instalada previamente y almacenar datos en el escritorio de Windows 7.

Escenario 2: Navegar por la Web utilizando una cuenta SafeGuard

Comenzar en el escritorio de Windows 7, luego dehaber iniciado sesión con una cuenta SafeGuard.
Navegar por la WWW con cualquier navegador.
Instalar múltiples add-ons en el navegador (como Silverlight, Adobe Reader, Adobe Flash, etc.).
Tratar de utilizar los add-ons instalados(como ejecutar una aplicación Silverlight application en http://www.silverlight.net/Showcase/, ver un archivo PDF desde la Web con Adobe Reader, etc.) y verificar que funcionen como se espera.

Escenario 3: Instalar una nueva aplicación utilizando una cuenta SafeGuard

Comenzar en el escritorio de Windows 7, luego dehaber iniciado sesión con una cuenta SafeGuard.
Instalar una nueva aplicación, como por ejemplo un juego de MSN Game(http://zone.msn.com).
Ejecutar la aplicación para verificar que funciona como se espera.

A BetaTestear!!!

Fernik

Reportando Bugs en Windows Vista: Internet Explorer

Fernik — Sun, 08 Feb 2009 16:14:00 GMT

Este es el último post del conjunto de artículos dedicados al testing del Service Pack 2 de Windows Vista y Windows Server 2008. En esta ocasión voy a hablar sobre Internet Explorer. El navegador es la llave para abrir la Web, si el mismo presenta fallas y la experiencia de usuario es frustrante, los usuarios/sesarrolladores se alejarán e incluso peor, no desarrollarán aplicaciones que se ejecuten en forma optimizada. Internet Explorer no es una aplicación más, es en sí una platafoma ya que es el navegador que más APIs expone para el uso de terceras partes y esto hace que cada vez la simbiosis que tiene con Windows sea más profunda y que los chicos malos(Unión Europea y Opera) se enojen cada vez más. De heccho es asombrosa la cantidad de aplicaciones de escritorio que como requerimiento necestian una versión determinada de Internet Explorer previa a su instalación.

Pero antes de tratar a Internet Explorer, quiero hablar un momento sobre la importancia de reportar bugs. Es realmente fácil y cómodo sentarse usar un programa descubrir un bug y pensar "Es Microsoft, no lo van a arreglar" o "Esto no sucede en....". Lo importante es hacer llegar este bug, ya que si hay mucha gente que reporta un problema en escenarios semejantes, este escenario toma protagonismo, los bugs son agrupados y es priorizado por Microsoft. Por ello es necesario nuestra participaión activa para ayudar a cubrir cosas que no se saben o desconocen.

Volviendo al tema que nos convoca, una de las nuevas características tanto de de IE7 e IE8 son las extensiones TLS. TLS es el sucesor de SSL, y como se imaginan es de vital importancia en transacciones comerciales en la Web por eso es necesario que opere efectivamente. Las extensiones TLS son una manera de comunicar informacion adicional en el handshake SSL, y hay algunos servidores dando vueltas por ahí que no manejan esto correctamente. Si este es el caso Microsoft trata de contactar a estos sitios para que actualicen su software de servidor y manejen bien las extensiones TLS. De todos modos es importante reportar todos aquellos sitios que no funcionen con la opción TLS. Si se deshabilita TLS y el sitio funciona correctamente, es necesario reportarlo a Microsoft y al mismo sitio.

Otro problema que aparece frecuentemente es que muchos sitios explícitamente bloquean la cadena de User Agent de IE7, es el caso en el que un sitio reporta que no soporta su navegador y que se actualice a IE 5 o IE6. Esto se arregla contactando a Microsoft y al propietario del sitio solicitando que soporte IE7. Adicionalmente podemos modificar el registro de manera que IE7 impersone en el sitio como IE6, para ello hay un script en http://www.fiddlertool.com/useragent.aspx que automáticamente setea eso por nosotros y podremos navegar ese sitio sin problemas. Ahora si luego de impersonar como IE6 el sitio no funciona correctamente, reportar un bug.

Respecto de CSS, muchos sitios usan CSS hacks para lograr la apariencia deseada, sin embargo a veces esto no alcanza en IE7, y se reporta el bug como un screenshot y la dirección de la pagina a revisar. Siempre es importante resaltar qué parte del screenshot no se renderiza como se espera, esto es fácil ya que con cualquier editor de imágenes podemos destacar el área desprolija lo cual ayuda mucho a focalizarse en la parte de la página a examinar para corregir el bug.

También es importante disponer de información sobre la configuración de IE7, ya que hay clases de bugs que suceden cuando hay ciertos Add-ons intalados y no suceden cuando estos no están. Los Add-ons impactan profundamente en el estado de IE(especialmente las toolbars de Google, Yahoo y MSN), por eso también es útil enviar una captura de la ventana "Manage Add-ons" con las siguientes columnas de datos como muestra la imagen:

Internet Explorer 7 en Windows Vista ofrece una característica conocida como "Potected Mode", que incluso cuando ejecutamos IE7 como administradores, IE7 no se ejecuta con priviliegios de administrador, sino con el menor privilegio posible. Lo bueno es que cualquier vulnerabilidad de seguridad que surja y trate de ser explotada, está contenida, o sea el daño que puede hacer es minimizado o nulo. La parte desagradable es que hay muchos sitios, Add-ons y escenarios de uso que asumen que tienen privilegios totales(sí como en MS-DOS) en nuestro ordenador, aunque no sean sitios maliciosos están diseñados con otro criterio de seguridad. Por eso es necesario que siempre ejecuten IE7 en modo protegido y reporten bugs sobre problemas que surjan en ese modo.

Internet Explorer 7 soporta OpenSearch(desarrollado por el equipo A9 de Amazon), que permite agregar proveedores de búsqueda al combo de búsqueda de la esquina superior derecha, sin tener que ejecutar ni instalar código externo en nuestro ordenador. La idea es desarrollar proveedores de búsquedas, escribiendo descriptores OpenSearch de nuestros sitios favoritos utilizando la documentación disponible en http://www.opensearch.org/Specifications/OpenSearch/1.1. Aparentemente esta nueva forma de proporcionar Add-ons para navegadores basándose en descriptores o manifiestos en XML en vez de código compilado que tiene que ser descargado está teniendo mucha aceptación. Sin embargo no significa que esté excenta de bugs ya que todo lo que usa XML tiene sus problemas del encoding/overflow/parsing, etc y es necesario considerar eso al momento de testear. Finalmente la búsqueda en un navegador es sobre los usuarios y sobre cómo los usuarios quieren buscar en Internet y no sólamente para un par de grandes motores de búsquedas. Por eso he desarrollado un Search Provider para Geeks.ms el cual es descubierto automáticamente por IE7/IE8 cuando ingresan a este blog, ya que el combo de búsqueda cambia a color naranja como lo muestra la siguiente imagen:

Luego, al hacer click en el combo, pueden observar el nuevo proveedor de búsqueda destacado, para agregarlo simplemente hacemos click en "Geeks.ms" desde el submenú "Add Search Providers", luego click en "Add Provider" y estamos listos para buscar en Geeks.ms desde Internet Explorer.

Hoy por hoy todos los navegadores detectan feeds RSS y proporcionan una representación para la misma. Al testear RSS, es importante filtrar por categorías, fechas, tags, etc y ver como funciona y se adapta a la representación elegida. Por ejemplo una buena prueba sería hacer una búsquedda en Ebay, obtener el RSS correspondiente y probar todas las posibles maneras de filtrar, ordenar y buscar ese feed RSS. La otra parte de RSS en Internet Explorer es Windows RSS Platform, es una API que que permite que nos suscribamos y manipulemos una feed RSS con Internet Explorer. Al ser una API pública que agrega valor a Windows, cualquier otra apicación puede hacer uso de esta API sin recurrir a librerías de terceros o a una implementación propia. Empleando esta API, hay oportunidad para escenarios de sincronizacion en la nube, etc. Es desafío es ver qué programas podemos escribir contra esa API que hagan cosas asombrosas como así reportar cualquier bug en la misma.

Espero que estos 4 posts sobre testing hayan abierto la cabeza o desarrollado un criterio adicional sobre la naturaleza del software(concretamente un sistema operativo) y sobre cómo el mismo está conectado en un ecosistema del cual se nutre y debe nutrirlo para que exista un equilibrio aceptable y todos ganemos.

Fernik

Reportando Bugs en Windows Vista: Networking

Fernik — Thu, 29 Jan 2009 05:20:00 GMT

Continuando con los posts sobre el testing del Service Pack 2 de Windows Vista y Windows Server 2008, ahora voy a hablar un poco sobre cómo Microsoft administra una característica o feature que agrega a sus sistemas operativos. La calidad es el objetivo primario cuando se agrega una nueva característica en Windows. Una cosa es tener muchos e interesantes escenarios por soportar al momento de agregar una característica, pero es peor si se agrega algo que no trabaja bien a que no se agregue. Por eso siempre menos es más, porque si se proporciona una nueva característica o tecnología y no funciona total o parcialmente, el usuario se alejará con la impresión de que no funcionó. En cambio si la característica funciona aunque no cumpla con todas las expectativas esperadas, el usuario va a quedarse con la impresión de que sabe que funciona pero le gustaría que además pudiera hacer X, pero X tal vez venga en el próximo release del sistema. Por eso es importante concentrarse en esto al momento de testear Networking y las tecnologías de transición de IPv4 a IPv6.

Como Windows es una plataforma realmente amplia y hay tanta gente que desarrolla, lo extiende y lo usa de infinidad de maneras diferentes lo que hace imposible para Microsoft conocer cada situación y ser capaz de testear de la manera que trabaja cada uno. Precisamente es aquí donde todos entramos en juego para ayudar y validar que lo que hace Microsoft funciona en todos los escenarios y en la infinidad de maneras en que Windows puede ser utilizado. Es importante siempre reportar qué parte de la experiencia no funcionó o qué se esperaba versus qué es lo que se obtuvo. Para reportar bugs en Networking lo primero que se necesita es el Mapa de Red, al cual se llega haciengo click en el "Network and Sharing Center" en el Panel de control.

Luego clickear en el link que dice "View Full Map".

Este mapa es una representación de la red a la que pertenecemos, el cual es nuevo en Windows Vista. Así que utilizar el Mapa de Red para describir nuestro esquema de red incluyendo el tipo de conexión. En algunos escenarios, es posible que el mapa de red no muestre toda la información relevante sobre nuestra red, de ser así por favor hacer saber sobre las computadoras o dispositivos faltantes siguiendo las instrucciones detalladas que aparecen al clickear en el área resaltada en la siguiente figura:

Un verdadero reporte de bug de Networking necesita contener toda información relevante incluyendo fabricante de hardware y versión del driver como así también la versión del firmware para cualquier hardware de red como placas de red, access points y routers. Para ello necesitamos la información provista por ipconfig, Desde la consola y con privilegios administrativos ejecutamos "ipconfig /all":

Información como direcciones IP, direcciones MAC, fabricantes de NIC y mucho más aparecerán en la consola. Toda esta información es necesaria incluirla en el reporte de bugs de Microsoft Connect como un archivo adjunto junto con cualquier screenshot. Esta información es necesaria para cualquier tipo de conexión incluyendo pero no limitado a conexiones wired, wireless, VPN y dial-up.

En Windows Vista se ha agregado soporte para la próxima generación de protocolos de Internet, conocidos como IPv6. Esta información se incluye como parte del reporte de "ipconfig /all" si IPv6 está habilitado en nuestra red. Cabe destacar que en Windows Vista IPv6 está hablitado por defecto, sin embargo no todo el hardware de red soporta IPv6 todavía. Durante 1970, IPv4 fue inventado pero pasó mucho tiempo antes que la red Internet que conocemos actualmente fuera concebida y creada. Si bien IPv4 ha sobrevivido todo este tiempo hay ciertas cuestiones que necesitan ser corregidas. Entre ellas la escasez de direcciones IP, esto es particularmente muy visible en Asia y Europa, que entraron tarde al juego de Internet y como resultado no recibieron la asignación de direcciones IP que USA obtuvo. Actualmente USA tiene el 8% de la población mundial mientras que posee el 75% de las direcciones IPv4.

Por lo tanto, esencialmente, IPv6 apunta a la visión de que todos los dispositivos que se conecten(inalámbricamente o no), ya sean celulares, cámaras, etc. permitirles participar en Internet como ciudadanos de primera clase. IPv6 apunta a satisfacer esa necesidad y es por eso que en Windows Vista está habilitado por defecto. Esto significa que los desarrolladores ahora tienen que escribir sus aplicaciones para que sean agnósticas de protocolo de red y las empresas necesitan empezar a crear un plan de cómo van a implementar IPv6 en el tiempo. En Windows Vista hay muchas tecnologías que permiten que esta transición suceda sin tener que actualizar toda la red, entre ellas Toredo, ISATAP, PortProxy para más información les recomiendo leer el excelente paper sobre tecnologías de transición de Networking en http://technet.microsoft.com/en-us/library/bb726951.aspx. Por eso se recomienda empezar con las aplicaciones y las tecnologías de transición y posteriormente a medida que los patrones de tráfico cambien evaluar como actualizar la red a IPv6.

Para reportar bugs de Networking es necesario lograr reproducir el bug en un contexto de tracing. Esto realmente consiste en 3 pasos básicos:

Tener habilitado tracing antes de testear.
Ejecutar los pasos necesarios para reproducir el bug.
Deshabilitar tracing.

Por ejemplo , para el caso de una conexión cableada en una LAN:

Habilito tracing desde la consola en como Administrador: netsh lan set tracing mode=yes
Luego voy paso a paso para reproducir el problema. Supongamos que estoy testeando conectividad IPv6 en la LAN.
Finalmente, una vez reproducido el bug de forma exitosa deshabilitar tracing con: netsh lan set tracing mode=no

En "C:\Windows\tracing\wired" encontraremos un archivo llamado wired.cab con todo el reporte de tracing. Este archivo habrá que adjuntarlo al reporte de bugs en Microsoft Connect. Los logs generados por tracing son críticos para debugear el bug por parte del Windows Beta Team, es por ello que siempre que sea posible reproducir un bug de Networking hay que enviar toda la información de contexto de tracing.

Si probamos IPv6 sobre VPN, los logs generados encuentran en "C:\Windows\tracing", son varios archivos con la extensión .log. Los comandos para habilitar y deshabilitar tracing son:

netsh ras set tracing * enabled
netsh ras set tracing * disabled

Para una conexión wireless, los logs se almacenan en "C:\Windows\tracing\wireless" y concretamente habrá un archivo wireless.cab que contiene todo el reporte de tracing a adjuntar. Los comandos para habilitar y deshabilitar tracing son:

netsh wlan set tracing yes
netsh wlan set tracing no

Finalmente adjuntar todos las trazas sobre cualquier tipo de conexión que reportemos un bug, como cualquier otro bit de información que ayude debugear la conectividad de la red.

Fernik