Web Beacons ou Web Bugs o que é, para que serve?

Web Beacons ou Web Bugs são umas séries de técnicas utilizadas para monitorar quem está lendo uma página na web, e-mail e/ou dados do computador.

Também pode ser usado para verificar se um determinado e-mail foi lido ou se uma determinada matéria foi copiada indevidamente para outro site.

Os primeiros Web Beacon eram imagens de 1×1.

Adicionalmente, um Web Beacon é utilizado para medir padrões de tráfego dos usuários de uma página a outra com objetivo de maximizar o fluxo de tráfego através da Web.

Por exemplo, o usuário e o visitante do site Mercado Livre manifestam conhecer e aceitar que Mercado Livre poderá utilizar um sistema de monitoramento mediante a utilização dos mesmos.

Embora Web Beacons seja utilizada da mesma forma nas páginas da Web ou e-mails, as finalidades são diferentes:

  1. Se está embutido em um e-mail, a imagem é carregada pelo browser quando o usuário lê o e-mail pela primeira vez, assim podemos saber se um determinado e-mail foi lido ou não;
  2. Sempre que é feito o download de uma página da Web (com ou sem erros), o servidor que retém a página sabe e pode armazenar o endereço IP do computador que solicita a página, linguagem do browser ...

Abaixo segue um exemplo simples, onde eu vou pegar o IP do usuário que acessa uma determinada página.

Criaremos um arquivo chamado webbug.php.

<?php
// crio um arquivo aonde vou armazenar o ip do usuário
f = fopen('teste.txt','a');
fwrite(f,_SERVER['REMOTE_ADDR']."\\n");
fclose(f);// aqui eu retorno o cabeçalho informando que esse arquivo é uma imagem, isso evita erros do browser
header('Content-type: image/gif');?>

Agora vamos incluir o Web Beacon, para isso vamos criar uma tag IMG com as dimensões 1x1.
<imgsrc="webbug.php"alt=""width="1"height="1"/>


Dessa forma quando o browser carregar a imagem, ele também está executando o arquivo webbug.php, desta forma criamos um Web Beacon.

Hoje os Web Bugs também utilizam IFrame, link , script e outras tags para monitorar uso.

Web Beacons  podem ser utilizados em combinação com cookies HTTP como qualquer outro objeto transferido usando o protocolo HTTP.
Fonte: Imasters

Curso de Web Design com w3c e php, clique aqui.
Anúncios

A importância crucial dos padrões Web do W3C.

Novo Blog já no Ar.

Com o intuito de melhorar o acesso aos serviços da CSS TI, após um tempo de manutenção, hospedamos nosso Blog em nosso servidor, para um melhor controle.

Faça-nos uma visita:

Por enquanto este permanece no ar, mas o novo já está a todo vapor.

Acesse: http://www.wordpress.cssti.eti.br/

Atenciosamente,

Equipe CSS TI

Obs: Iniciamos há algumas semanas uma campanha para uma maior divulgação das normas do W3C e seus padrões para uma Web mais segura e acessível.
Intitulada 5w2h do W3C, a campanha tem por objetivo uma maior divulgação dos padrões, para que mais pessoas possam ter conhecimento de tais padrões e assim valorizar empresas que se preocupam em se atualizar para melhorar o conteúdo a ser oferecido a seus clientes e alunos.

Confira: 5w2h do W3C

Atualmente ouve-se falar muito em padrões web e acessibilidade entre os desenvolvedores de sites.

Entretanto, o entendimento que cada um traz desses conceitos é diverso e muitas vezes indefinido.

Os Padrões web sempre estão associados ao código da página web e às recomendações do W3C especificadas para ele.

Para podermos desenvolver um site genuinamente de boa qualidade e preparado para receber o extra de acessibilidade, os padrões desenvolvidos em seu código devem abranger os seguintes itens:

  1. Código html/xhtml e CSS válidos
  2. Separação em camadas: conteúdo, apresentação e comportamento
  3. Código (X)HTML semântico.

Para demonstrar a importância desses itens dos padrões web para a acessibilidade de sites, temos de especificar para quem seja acessibilidade web, conceito culturalmente só associado ao acesso de pessoas com deficiência visual.

“Para quem serve a acessibilidade?”

W3C

W3C

É uma pergunta que nos leva a várias questões e que nos ajudará a entender a relação entre web standards e acessibilidade.

Podemos dividi-la em:

  1. Acessibilidade web para pessoas cegas;
  2. Acessibilidade web para pessoas com deficiência;
  3. Acessibilidade web universal, uma web para todos.

01- Acessibilidade web para pessoas cegas

Com certeza o foco principal do desenvolvimento de sites acessíveis é o acesso de pessoas com deficiência ao conteúdo de informação e serviços prestados em um site.

Entretanto, criamos no Brasil uma cultura de que acessibilidade web seria somente para pessoas com deficiência visual e, mais ainda, especificamente para pessoas cegas.

Dessa forma, para alguns desenvolvedores, testar acessibilidade de um site significava quase que exclusivamente pedir a uma pessoa cega que navegasse com seu software de fala pela página e desse o seu ok nela.

Este é, sem dúvida, um dos itens, entre inúmeros outros, da metodologia proposta pelo W3C/WCAG para testarmos a acessibilidade de uma página.

No entanto, este item, isoladamente, acaba por incorrer em inúmeros erros: nem todo o leitor de tela tem a mesma qualidade e funciona da mesma forma, fazendo com que o teste de uma pessoa cega não especializada possa ser somente válido para o leitor de tela ou tecnologia assistiva que essa pessoa utiliza.

Uma pessoa cega e usuária de leitores de tela não consegue, apenas com uma navegação momentânea, perceber alguma falta de informação sem comparar o que seu leitor de tela informou e o conteúdo presente na tela.

Essa pessoa precisa ir ao código confirmar as informações ou ter uma pessoa que enxergue para comparar sua navegação com a da pessoa cega.

A cultura de se fazer acessibilidade web para pessoas cegas acabou por ser legalizada através do decreto 5296 e pela má interpretação das pessoas responsáveis pelos portais que se enquadravam nele.

O significado de deficiência visual não era pensado como abrangendo as pessoas de baixa visão, restringindo essa deficiência à cegueira.

É importante destacar que a cegueira, segundo o censo 2000 do IBGE, está presente em torno de 300 mil pessoas da população, enquanto que o decreto, ao referir-se à deficiência visual, definida no início do decreto como sendo a cegueira e mais a baixa visão, destinava a acessibilidade a mais de 16 milhões de pessoas:

Decreto Nº 5296 – Art. 47.No prazo de até doze meses a contar da data de publicação deste Decreto, será obrigatória a acessibilidade nos portais e sítios eletrônicos da administração pública na rede mundial de computadores (internet), para o uso das pessoas portadoras de deficiência visual, garantindo-lhes o pleno acesso às informações disponíveis.”

No mesmo decreto, artigo 5º: 1.3 deficiência visual: cegueira, na qual a acuidade visual é igual ou menor que 0,05 no melhor olho, com a melhor correção óptica; a baixa visão, que significa acuidade visual entre 0,3 e 0,05 no melhor olho, com a melhor correção óptica; os casos nos quais a somatória da medida do campo visual em ambos os olhos for igual ou menor que 60o; ou a ocorrência simultânea de quaisquer das condições anteriores;

Além disso, o WCAG não define que seja uma pessoa com deficiência visual, muito menos cega, a realizar o teste.

Como sabemos, inúmeras outras deficiências precisam de acessibilidade na web.

02- Acessibilidade para pessoas com deficiência

Ao conhecermos as Diretrizes de Acessibilidade de Conteúdos Web em suas duas versões, 1.0 e 2.0, percebemos a ênfase que os itens de acessibilidade desses documentos dão aos acessos não padronizados de pessoas que, em sua maioria, possuem deficiência, como a deficiência visual, auditiva, cognitiva e motora.

Nota-se, de pronto, que as recomendações não se restringiram à deficiência visual e nem mesmo a alguma tecnologia assistiva específica, apesar de citá-las ao longo desses documentos.

Assim, por exemplo, ao destacarem os equivalentes textuais, o fizeram não só como itens textuais alternativos para imagens (deficiência visual), como também para sons (deficiência auditiva).

Esses itens combinados podem mesmo auxiliar, e muito, o acesso de pessoas surdocegas, usuárias de display-braille.

Para as pessoas com deficiência intelectual que, ao perceberem uma informação visual e auditiva simultânea, conseguem elaborar informações com mais segurança, ainda disponibiliza itens como o da “linguagem clara e simples” que, além de auxiliarem essas pessoas especificamente, colaboram indistintamente com todas as pessoas por deixar o conteúdo mais inteligível.

Alguns itens de acessibilidade como os saltos ajudam o acesso de pessoas com deficiência motora com pouca destreza manual que, apesar de enxergarem, utilizam a navegação via teclado.

Não podemos deixar de mencionar, por sua importância e competência, a Errata ao WCAG 1.0, realizada por Joe Clark, uma das maiores autoridades em acessibilidade web do mundo, a conhecida WCAG Samurai.

Atualmente, a existência de três WCAG, a dos W3C (versões 1.0 e 2.0) e a WCAG Samurai, criaram uma certa insegurança nos desenvolvedores de sites acessíveis, pois a WCAG 2.0 ainda não está muito bem aceita e a WCAG Samurai, apesar de possuir ótimas soluções de acessibilidade web e ter como base a WCAG 1.0, bastante aceita e da qual é uma errata, não são recomendações do W3C e, portanto, não tem o reconhecimento internacional que o W3C possui.

Essa “crise por excesso” de diretrizes tem criado uma outra mais perigosa, que é a da mistura individual de soluções de acessibilidade web dos três WCAG, que cada desenvolvedor de conteúdos acaba criando.

A Convenção dos Direitos da Pessoa com Deficiência da ONU, assinada pelo Brasil e ratificada como emenda constitucional brasileira através do decreto legislativo Nº 186, autoaplicável desde junho de 2008, amplia a acessibilidade, restrita à pessoas com deficiência visual e à portais do governo pelo decreto 5296/04, à todas as deficiências e à empresas privadas.

Web Design com w3c só a CSS TI tem.

Web Design com w3c só a CSS TI tem.

Se desejar conhecer, procure os artigos 9, 21 e 30, que tratam do assunto.

Entretanto, apesar desse auxílio às boas práticas, ao acesso e bom uso da web que os documentos WCAG fazem inserindo diversas deficiências, ao incluírem os padrões web aos padrões de acessibilidade web, passaram a criar universalidade ao acesso, ou seja, sugerindo e orientando a acessibilidade para pessoas com e sem deficiência, a uma web para todos.

03- Acessibilidade Universal – uma web para todos

Ao juntarmos os itens de acessibilidade web aos itens dos padrões web já conhecidos, ampliamos o desenvolvimento de acessibilidade web e do conceito de desenho universal aplicado à internet.

Para entendermos como podemos utilizar o conceito de desenho universal na acessibilidade de sites, vamos voltar aos itens dos padrões web mencionados antes:

1- códigos corretos e validados

A primeira coisa que criadores web buscam quando falam em Web Standards é que o código do site deve ser válido.

Para a maioria das pessoas isto significa apenas validar o código HTML/XHTML, mas existem ferramentas que validam também as CSS.

Basicamente, ter um código (X)HTML válido significa que o código da página Web está escrito de acordo com o padrão, sem erros de sintax.

Como é o código da página que vai determinar como sua página será renderizada, em que tempo e maneira isso irá acontecer nos diferentes navegadores e com que qualidade, estando seu código válido, você não precisa se preocupar com os diferentes erros de interpretação dos diferentes navegadores e tecnologias assistivas, e assegurar uma maneira uniforme de utilização por todos eles.

Com relação ao código das CSS, apesar de haver diferenças de renderização entre navegadores e suas versões e sermos obrigados a testar para tentar conciliar as diferenças entre eles, estamos começando a passar por uma tendência à uma renderização bem aproximada após o fracasso do navegador Internet Explorer 6.0, que acabou por perder muito mercado para o concorrente Firefox, da Mozilla.

Códigos válidos significam também rapidez de interpretação desses códigos para todos os agentes do usuário, sejam navegadores ou tecnologias assistivas.

Assim, conexões lentas, discadas ou conexões divididas por inúmeros usuários em rede, tecnologias assistivas, como ampliadores de tela, que navegam associados muitas vezes a leitores de tela e possuem um peso que acabam por aumentar o tempo de navegação, começam, através de códigos corretos, a possuírem um tempo de download das páginas web mais adequados.

2- Separação em camadas: conteúdo, apresentação e comportamento

O conteúdo de uma página e sua estrutura são determinados pelos textos, tabelas, formulários etc.

São criados através de marcações de html/xhtml, linguagens padrões para esse fim.

Apresentação é tudo que é visual, como posicionamento do conteúdo, coloração, tamanhos… é o CSS a linguagem, também conhecida por folhas de estilos quando reunida em arquivo.

O Comportamento é criado por scripts.

Nem o conteúdo determinado pelo (X)HTML e nem a apresentação determinada pelas folhas de estilo são dinâmicos. Scripts acrescentam movimento e comportamentos às páginas.

Quando construímos uma página com códigos válidos e com essas camadas independentes, estamos atendendo a diversos itens de acessibilidade em uma página web, além de estarmos cumprindo com mais um dos três itens dos padrões web.

Assim, testamos se o conteúdo, sem apresentação alguma de cor, posicionamento e sem scripts está funcionando bem.

Depois, em um arquivo à parte, colocamos o código das folhas de estilo de todas as páginas do site.

Ou seja, as cores dos textos dos links, das cores de plano de fundo, posicionamento de tabelas, colunas, de seções de todas as páginas do site no mesmo arquivo.

Deve-se evitar o estilo inline.

Ainda, de forma independente, criamos comportamentos extras e algumas funcionalidades através dos scripts, que devem ser não obstrutivos.

Cada uma dessas camadas se acrescentam entre si, tendo como base o conteúdo.

Assim, se precisarmos desativar a camada de apresentação deixando o conteúdo limpo e, ainda, se quisermos desativar comportamento e deixar a página com seus scripts desativados, isso não gerará perda de conteúdo e a página poderá ser navegada sem restrições.

Os leitores de tela para pessoas com deficiência visual lêem quase que exclusivamente o conteúdo, deixando de lado a apresentação da página.

Se o conteúdo está validado não existe erro em sua leitura e nem na execução de tarefas.

Se, além disso, o código está desenvolvido apenas para cada tipo de camada com sua respectiva marcação, que não está misturando conteúdo com cores e posicionamento de elementos e, portanto, a camada de conteúdo com a de apresentação, então o código de conteúdo estará proporcionando uma leitura facilitada aos leitores de tela, que não precisarão selecionar o que ler, pois o código a ser lido está “enxuto”.

Ou seja, os leitores de tela não terão de selecionar conteúdo entre conteúdo, apresentação e comportamento do código.

É bom lembrar que, mesmo desativando os scripts e a apresentação através do navegador que, misturadas, essas camadas não serão retiradas do código.

Assim, um código limpo, com cada camada separada e acessível, é o ideal não só para web standards, como especialmente para a acessibilidade web.

Quando desenvolvemos um site em camadas e carregamos uma de suas páginas pelo navegador, as camadas de apresentação e de comportamento ficam guardadas na memória e arquivos temporários, de forma que somente o conteúdo dessa página é renovado a cada entrada nas outras diversas páginas do site.

Isso significa uma velocidade tremendamente maior para a montagem e renderização dessas páginas.

Velocidade de acesso é acessibilidade web, independentemente de para qual usuário.

Conexões discadas ou banda larga compartilhada em rede se beneficiam com muita clareza das vantagens da rapidez do carregamento da página.

Além dos códigos corretos, a separação em camadas é um enorme auxílio dos itens dos padrões web para a acessibilidade de sites.

3- Códigos semanticamente corretos

Um código semântico significa que as marcações utilizadas foram usadas para os fins a que cada elemento do código se destina.

Dessa forma, se existe um código próprio para criarmos cabeçalhos e títulos (h1/h6), ele deve ser utilizado para a criação de cabeçalhos e títulos.

Se existe um código para a criação de tabelas de dados (table), somente esse tipo de tabelas devem ser produzidas por ele.

Para exemplificar a necessidade dessa lógica dos padrões web para se fazer acessibilidade, podemos tomar essas duas situações acima:

Uma marcação existente para se fazer um cabeçalho deixa o texto ao qual será aplicado com letras mais escuras e em negrito, podendo-se alterar seu tamanho.

Muitas vezes desenvolvedores utilizam esse destaque que essa marcação produz no conteúdo com o objetivo de ser um cabeçalho, apenas para destacarem palavras soltas ou expressões no meio de um texto, ou para ressaltar um texto de link ao meio de outros links.

Os leitores de tela não têm como função somente lerem o conteúdo textual das páginas, mas também de descrevê-la para seus usuários.

Dessa forma, quando ele passa por uma marcação de um link, ele sintetiza a palavra link para que o usuário possa saber da existência desse elemento naquele texto.

Quando passa por uma marcação de tabela, ele diz da existência da tabela naquele espaço, quantas colunas e quantas linhas existem naquela tabela e, da mesma forma, quando ele passa por uma marcação de cabeçalho ele sonoriza a existência de um cabeçalho por ali e a que nível ele se encontra: h1 – cabeçalho de nível 1, h2cabeçalho de nível 2 e assim por diante.

Portanto, se marcações são feitas para codificarem elementos específicos, estas devem ser usadas para fazerem aquilo para o qual foram criadas.

Codificar uma palavra ou expressão com uma marcação de cabeçalho fora de um cabeçalho, significa dar a informação errada para um leitor de telas e, consequentemente, para seu ouvinte.

Além disso, leitores de tela gráficos e mais profissionais criam alguns recursos aproveitando-se justamente dos padrões web para facilitarem a navegação de seus usuários.

Dessa forma, para alguns, existe uma navegação chamada teclagem de navegação rápida, que pressionada leva o usuário, através de um salto, diretamente a cabeçalhos, tabelas, formulários, parágrafos …

Assim, se as marcações certas forem utilizadas para realizarem ao que se destinam fazer, a navegação por uma página ficará totalmente acessível para esses recursos.

4- Acessibilidade e Padrões, Padrões e Acessibilidade

A demonstração da importância crucial dos padrões web do W3C para a acessibilidade de tecnologias assistivas, para tecnologias não assistivas, para pessoas com deficiência e pessoas sem deficiência, passa pela experiência do uso desses padrões.

Não podemos pensar, no entanto, que desenvolvendo um site totalmente dentro dos padrões web (web standards) estaremos produzindo páginas totalmente acessíveis.

Os padrões web, com todos os seus itens, são o básico para uma página web acessível, mas não o todo.

Para uma acessibilidade web integral temos de acrescentar aos padrões web as técnicas de acessibilidade associadas ao WCAG e suas recomendações.

Não temos também como criar páginas acessíveis apenas com algumas recomendações dos WCAG em um código com semântica incorreta, sem separação de camadas e cheio de erros de sintax.

O casamento entre padrões web e diretrizes de acessibilidade tem de ser completo.

Por exemplo.

Alguns desenvolvedores radicais de tableless não admitem tabelas nem mesmo para a confecção de tabelas de dados genuínas.

Dessa forma, alguns desses colegas optam por criarem tabelas com listas (ul/li) horizontais e verticais, deixando-as visualmente iguais a uma tabela de dados.

No entanto, em um código semântico, tabelas devem ser criadas com o elemento <table>, o que proporcionaria à usuários de leitores de tela a idéia correta de que estão passando por uma tabela, por dados tabulares, pois ao navegar por uma lista de itens em forma de tabela, um leitor gráfico sintetizaria “lista de itens” e “item de nível 1”, e não “tabela com 10 colunas e 20 linhas, por exemplo.

Por outro lado, nesse caso, uma tabela semanticamente correta e dentro dos padrões, não necessitaria de ser criada com os elementos <TH>, nem de fazermos as associações destes através de <ID> com <headers> da célula de dados correspondente ao cabeçalho.

O <ID> e o <HEADERS> são marcações extras de acessibilidade web que, no entanto, sem elas os padrões web poderiam estar sendo perfeitamente seguidos, mas a acessibilidade de tabelas não estaria sendo realizada.

Dessa forma, podemos afirmar que não existe uma acessibilidade completa sem os padrões web conjugados aos padrões de acessibilidade web.

Um sem o outro ficam incompletos no que tange à acessibilidade de cunho universal.

O W3C tem incorporado através dos códigos strict alguns itens de acessibilidade web as web standards, ao juntar alguns itens das diretrizes do WCAG, como o atributo de imagem ALT em seu validador.

Caso o elemento <IMG> apareça sem o seu atributo ALT o código para aquela imagem não é dado como certo.

Já nos códigos transitional isso não acontece.

Percebe-se assim, já por iniciativa do W3C, uma junção dos dois padrões em um só que, aos poucos, esperamos muito que aconteça por completo.

Será esperar demais?

O HTML 5.0 vem aí…

Fonte: iMasters

Dicas para Twittar com segurança no Trabalho

Não fale no Twitter o que você não falaria pessoalmente

A regra é clara.

Se você acha que pegaria mal falar algo em alto e bom som para todos os seus colegas ouvirem, não fale no Twitter.

A menos que você tenha restringido seus updates apenas para contatos aprovados, seu chefe pode fazer uma busca rápida e encontrar aquela twittada de desabafo falando sobre a ressaca da segunda-feira ou sobre a preguiça da sexta.

Twittar no Trabalho

Twittar no Trabalho

Sem falar que fica tudo lá registrado para a posterioridade, e futuros empregadores.

Vai pegar mal.

Não banque a metralhadora de posts

Se você está participando de uma palestra interessante ou assistindo algum evento digno de menção na TV e acha que seus seguidores vão se interessar em acompanhar o conteúdo em tempo real, mande bala.

Do contrário, evite bancar a metralhadora de tweets.

Depois de ver a sua foto repetida na lista de feeds pela vigésima oitava vez, pode ser que seus seguidores parem de prestar atenção ao que você está dizendo.

Além disso, pode dar a impressão de que você tem tempo demais e trabalho de menos.

Não seja prolixo, afinal, a idéia é passar o recado em 140 caracteres, certo?

Não lave roupa suja em público

Essa é quase uma extensão da primeira regra, mas tem suas exceções.

No Twitter, quando você responde uma mensagem sem apelar ao modo “direct”, todos os seus seguidores, e não só o autor do post original,  saberão o que você tem a dizer.

“Estamos tão acostumados a conversar o tempo todo nos mensageiros instantâneos e deixar recados nas redes sociais de maneira privada, que é fácil esquecer que com o Twitter é diferente”, lembra Souza.

Aquilo que você diz para alguém bate imediatamente na tela de todos os seus seguidores.

Portanto, evite bate-bocas, ofensas, grosserias e até galanteios que possam ser mal-interpretados.

É claro que a troca saudável de ideias, links e referências faz parte do jogo e é sempre bem-vinda.

Faça relacionamento, mas com moderação

É comum entre os usuários do Twitter apelar para a sua rede de contatos para pedir dicas e recomendações – seja de restaurantes, prestadores de serviços ou mesmo de candidatos a vagas em aberto.

Para Souza, quem se destaca na rede publicando links interessantes e fazendo comentários pertinentes, tem mais chance de ser lembrado na hora de um trabalho freelancer ou oportunidade de emprego.

“É uma maneira de ser notado”, destaca ele.

Mas todo cuidado é pouco: o tiro pode sair pela culatra.

Se você abusar da boa vontade alheia e se tornar um pentelho, poderá ser bloqueado, sem choro nem vela.

Em boca fechada não entra mosquito

A tentação de dar uma palhinha sobre uma coisa muito bacana que está prestes a rolar na sua vida profissional, seja um novo emprego, um cliente prestes a conquistado ou uma ideia incrível que você acaba de ter, pode terminar mal.

Nos Estados Unidos, um candidato perdeu o emprego por se gabar antes da hora da suposta contratação.

Um comentário “inocente” feito na ansiedade pode acabar colocando areia em todo um projeto ou dar bandeira sobre planos estratégicos para a sua empresa.

Lembre-se: qualquer um pode ler o que você está escrevendo, até mesmo seus concorrentes.

Programa Espião do MSN, conheça seus truques aqui.

Novo Blog já no Ar.

Com o intuito de melhorar o acesso aos serviços da CSS TI, após um tempo de manutenção, hospedamos nosso Blog em nosso servidor.

Faça-nos uma visita:

Por enquanto este permanece no ar, mas o novo já está a todo vapor, com deatlhes sobre a morte de Michael Jackson.

Acesse: http://www.wordpress.cssti.eti.br/

Atenciosamente,

Equipe CSS TI

Para quer serve o MSN Spy:
O programa captura as conversas do msn messenger do micro que foi instalado e envia para seu e-mail os logs capturados.

O MSN Spy em conta restrita do windows:
O programa funciona normalmente em conta restrita, mas tem que ser instalado e configurado em conta de administrador e sua pasta tem que ser compartilhada.

Como faço para acessar o programa:
Para entrar no programa após instalação utilize a combinação de tecla padrão Ctrl-Alt-F9 ou outra configurada.

Configuração de e-mail:
O objetivo da configuração de e-mail é para que os logs capturadas seja enviado no e-mail do administrador do software. Não é obrigatória a configuração para que o programa capture as conversas.

Abaixo segue um exemplo passo a passo para configuração de e-mail:
Para que o programa consiga enviar um e-mail é necessário primeiro configurar o servidor SMTP.

O que é servidor SMTP:
Todos os provedores de e-mail tem um servidor de envio (SMTP), veja juntamente com seu provedor de e-mail qual o nome do servidor smtp.

Abaixo segue um exemplo de configuração de SMTP utilizando uma conta do Yahoo:
Nome do Servidor de e-mail SMTP: smtp.mail.yahoo.com.br

Porta do Servidor de e-mail SMTP: 25

E-mail (remetente): exemplo@yahoo.com.br

Deixe Marcado no MSN SPy (Meu servidor requer autenticação)

Complete o campo usuário/e-mail: exemplo@yahoo.com.br

No campo Senha, Digite a Senha do e-mail do Yahoo.

OBS: Para conta do yahoo, é necessario acessar o site do yahoo em email, e ativar dentro do site em ‘opções’, acesso pop e redirecionamento, deixe ativo o web pop.

Tenho uma conta do Hotmail é possível configurar o SMTP:
Infelizmente Não é possível configurar servidor SMTP do Hotmail, crie uma outra conta de outro provedor que aceite SMTP.

O que coloco no campo (enviar log para o seguinte e-mail):
Este campo é importante pois é onde será enviado os logs das capturas, informe qualquer e-mail onde tem acesso para receber as informações.

MSN Spy Monitor 2007

MSN Spy Monitor 2007

Como faço para apagar os logs:
Somente o administrador do programa poderá apagar os logs,

Para apagar os logs, entre no programa selecione o logs desejado e clique no botão apagar logs.

O MSN SPy é compatível com qual versão do Messenger:
É compatível com MSN Messenger e Live Messenger 8.5 acima.

Quanto tempo posso testar o programa MSN SPy, preciso pagar algo para testar:
O teste é totalmente gratuito não precisa pagar nada e terá 10 dias para testa-lo.

Como faço para desinstalar o MSN SPy:
Somente o administrador do programa poderá desinstala-lo,

Para desinstalar, entre no programa com o ctrl-alt-f9 informando a senha e clique no botão Desinstalar.

O MSN SPy captura conversas apenas do micro onde foi feita a instalação:
Corretamente, em micro que não tem o programa instalado não é possível a captura.

Fonte: http://twitter.com/elianeamaral

Mega batalha para saber que será o maior Sistemas Operacionais para netbooks: Google, Microsoft ou Linux?

A CSS TI agora é FOX, confira este post em nosso Blog.

http://www.blog.foxcursos.com.br/?p=588