- Home
- Sobre
- Arquivo
- Fórum
- Games
- Mobile
- Fotografia
- Games DB
- Colabore
- Anuncie
- Radar
- Minha conta
- Contato
- Feed completo
- Feed dos comentários
- Feed do Fórum
- Feed Canal Games
- Feed Canal Fotografia
- Feed Canal Mobile
- Receba o Meio Bit via e-mail
Fórum
Criar novo tópico no fórum Últimos tópicos no fórumÚltimas respostas no fórum
- Link - Faces Of Evil
- Speedy Telefonica Capado
- Wireless RTL 8187B e o Ubuntu
- Camisetas na Threadless por US$10.00
- Mapas raros
- Paris a 26 Gigapixels
- Critica: Meiobit seguindo demasiadamente os "hips"
- Vagalume Meiobit
- Hospedagem de Site em Portugal
- Dúvida sobre Nikon D5000
- Curso de fotografia a distância
- Universidade do Google e FIAP lançam parceria
Newsletter
Mantenha-se informado sobre as nossas novidades com nosso newsletter semanal, todas as segundas-feiras
Categorias
- Acessórios | Acessórios | Acessórios | Análise | Análises | Anúncios | Anúncios | Apple e Mac | Artigo | Artigo | Áudio Vídeo Fotografia | Blog | Celular | Celulares | Ciência | Computação móvel | Computadores | Comunicação Digital | Cultura Gamer | Destaque | Destaque | Dicas | Download | Ensaio | Entrevista | Entrevista | Equipamentos | Especial | Fotografia | Galeria | Games | Games | Google | Hardware | Indústria | Indústria | Internet | Jogos | Lentes | Linux | Linux | Manipulação digital | Meio Bit | Mercado | Microsoft | Miscelâneas | Miscelâneas | MMO | Mobile | Mundo Estranho | Museu | Nintendo | Notícias | Open-Source | Opinião | Periféricos | Planeta Sem Fio | Podcast | Portáteis | Preview | Produtividade | Propaganda & Marketing | Publicidade | Resenha | Rumores | Seguranca | Software | Software | Sony | Tutoriais | Tutorial | Tutorial | Unboxing | Vídeos | VoIP | Web 2.0 | Web Games | Wireless e Redes |
Há dias vi mensagens no fórum sobre o IE 8, falando que ele não passa no ACID 2, apesar de anteriormente ter sido anunciado o contrário.
Afinal, o que aconteceu ? Por que depois de um anúncio tão bom o beta sai sem esse recurso ? Por que o sujeito virou ciclope ?
Quando vi essas mensagens aqui no MeioBit imediatamente encaminhei, para poder saber o que realmente havia ocorrido. Hoje recebi a resposta.
O teste ACID 2 oficial encontra-se em http://www.webstandards.org/files/acid2/test.html e o IE 8 beta 1 passa neste teste perfeitamente.
Porém o teste ACID 2 possui inúmeras cópias espalhadas pela web, sendo uma das mais populares a que fica em http://acid2.acidtests.org/ . Porém esta cópia não é uma cópia exata do teste ACID 2, possui uma pequena diferença. Vejam esse trecho de código abaixo :
<object data="data:application/x-unknown,ERROR">
<object data="http://www.damowmow.com/404/" type="text/html">
<object data=”data:*the eyes DATAURI* …>
</object>
</object>
O endereço do teste é http://acid2.acidtests.org/ mas o atributo data da tag object aponta para http://www.damowmow.com/404/ . Isso é uma chamada cross-domain, ou seja, feita para um domínio diferente, a partir de uma tag object . Desenvolvedores sabem o quanto isso é perigoso, estamos falando de potenciais invasões usando cross-site scripting e coisas do gênero.
Não importa o fato do objetivo desta chamada ser testar a reação a um erro 404. Para saber que isso é um erro 404, o IE teria que fazer a chamada ao endereço e o IE, ao identificar tratar-se de uma chamada cross-domain, barrou.
No endereço oficial do teste ACID 2, o atributo data aponta para o mesmo domínio onde encontra-se a página de teste e, portanto, no endereço oficial o IE 8 passa no teste ACID 2.
A resposta oficial da Microsoft pode ser encontrada no blog do Internet Explorer, em http://blogs.msdn.com/ie/archive/2008/03/05/why-isn-t-ie8-passing-acid2.aspx
Alguém por ai andou dizendo que a Microsoft não ouve seus usuários ?? :-)
Agora, com o beta 1 do IE 8 passando no teste ACID 2, já podem sorrir mais contentes. Claro que nem tudo é perfeito, vi os comentários gerais, mas a Microsoft ainda está no Beta 1 e já consegue 17/100 no ACID 3
- Feed comentarios deste post
- Dennes's blog
- entre com seu usuário e senha ou registre-se no site para enviar comentários
Login
Mais comentados
- 10 razões pelas quais o Gimp é melhor que o Photoshop (142)
- Winamp lança loja digital. Breaking News: Winamp ainda existe (134)
- Computador não engorda, a culpa é da TV (97)
- CDs e download: diferenças entre Brasil e EUA (93)
- Google para China: Game Over (67)
- Critica: Meiobit seguindo demasiadamente os "hips" (60)
- Pink Floyd vence processo contra EMI (55)
- Concorrente do OnLive fecha parceria com AMD (54)
Desculpa.. mas "já consegue"?
Firefox 2.0 foi lançado anos atrás e passa em 51/100. O Acid2 é realmente uma vitória, mas a Microsoft vai ter bastante trabalho até passar no Acid3...
Oi, Caravana !
Sim, sei que o Firefox consegue 51/100, mas estamos falando de uma versão Beta 1. Além disso, leve em consideração que nenhum outro browser descobriu que havia uma brecha de cross-site scripting em cópias do teste ACID 2
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
O autor do teste acid2 colocou este comentário no blog do IE:
But if it's failing -- for whatever reason, cross-domain or not -- you should fallback. Hence the current behaviour is still a bug. :-)
(BTW why would it be a cross-domain problem? This should be exactly the same as an iframe, which can cross domains fine.)
No mais, o acid3 precisa de coisas como eventos DOM2 (addEventListener) e SVG. Até agora a MS não disse se vai introduzir esse recursos no IE. SVG seria uma ótima surpresa.
Oi !
Existe um debate no blog do IE sobre se o IE deveria ou não fazer o fallback, ou seja, ao identificar o problema, renderizar a alternativa, o que faria ele passar no teste.
A questão é : Qual problema ?
O problema que deveria ser identificado, segundo o padrão, é um erro 404. Porém para o IE identificar um erro 404 ele teria que seguir o link, criando uma falha de cross-domain scripting.
O IE identificou foi um problema de segurança. Ele deveria fazer o fallback no caso do problema de segurança ?
A equipe do IE parece que achou que não, pois não era o comportamento pretendido por quem escreveu o código. Os usuários acham que sim...
De qualquer forma, falta algo : Ou faz o fallback, ou realiza um alerta de que houve uma tentativa de cross-site scripting. Ficar no vazio creio não ser uma opção.
De qualquer forma : Passou no teste oficial do ACID 2 e devido a sua segurança descobriu brecha nas cópias do teste ACID 2.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Não entendo como uma tag object pode causar cross-domain scripting... Agradeço se puder apontar uma referência.
E esse argumento não bate com o blog do IE. Lá eles dizem que o problema é de implementação.
Eu poderia apostar meus tibs que no IE8b2 o acid2 já rodará em qualquer domínio que esteja hospedado.
Oi, Jr.!
Não entendo como uma tag object pode causar cross-domain scripting... Agradeço se puder apontar uma referência.
Junte o que você já sabe de cross-domain scripting com o fato de que a tag object pode disparar objetos dos mais diversos e não necessariamente seguros + o fato dos parâmetros virem de fonte externa...
E esse argumento não bate com o blog do IE. Lá eles dizem que o problema é de implementação.
Lá eles não dizem nem mesmo que seja um problema. Ou você está considerando os comentários como se fossem algo oficial ?
Eu poderia apostar meus tibs que no IE8b2 o acid2 já rodará em qualquer domínio que esteja hospedado.
É muito provável sim. Se a comunidade pede fallback, é muito provavel que seja atendida. De duas uma, ou o fallback será extendido para questões ligadas a segurança ou um aviso de segurança será implementado... Mas nada disso altera o fato de que ele passou no teste.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Não entendo como uma tag object pode causar cross-domain scripting... Agradeço se puder apontar uma referência.
Junte o que você já sabe de cross-domain scripting com o fato de que a tag object pode disparar objetos dos mais diversos e não necessariamente seguros + o fato dos parâmetros virem de fonte externa...
Continuo não entendendo. Um link com exemplo, por favor.
E esse argumento não bate com o blog do IE. Lá eles dizem que o problema é de implementação.
Lá eles não dizem nem mesmo que seja um problema. Ou você está considerando os comentários como se fossem algo oficial ?
O post no blog IE é claro em dizer que o problema está na implementação do IE. E isso será corrigido nas próximas versões.
Eu poderia apostar meus tibs que no IE8b2 o acid2 já rodará em qualquer domínio que esteja hospedado.
É muito provável sim. Se a comunidade pede fallback, é muito provavel que seja atendida.
a "comunidade" não está pedindo, é o autor do teste que disse que o comportamento do IE está errado (seja parte do acid2 ou não).
No mais, reitero o meu pedido sobre um exemplo de brecha "cross-domain scripting" com tag object. Um link já serve.
http://ha.ckers.org/xss.html
http://www.technicalinfo.net/papers/CSS.html
Legais as páginas.. agora o que cross-scripting tem com o problema do Acid2?
Nem a página que hospeda o Acid2, nem a página endereçada no OBJECT tem sequer uma linha de javascript...
O IE não interpretou por que tem problemas, não por causa de "questões de segurança".
Caravana,
Nem a página que hospeda o Acid2, nem a página endereçada no OBJECT tem sequer uma linha de javascript...
Você não entendeu mesmo a questão de cross-site scripting. Claro que não tem javascript lá, esperava que o ACID 2 fosse realmente uma invasão para sua máquina ?
Mas em uma aplicação real aquela tag Object poderia perfeitamente ser o resultado de script injection, que seria extremamente prejudicial.
Sugiro livros sobre segurança, vão ajudar.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Claro.. navegar também pode passar vírus, sabia?
É óbvio que pode haver código malicioso ali. Se realmente fosse questão de sergurança, uma página que tivesse códigos seria bloqueada, ou melhor ainda, somente os códigos não seriam executados.
Não é isso que acontece. O navegador simplesmente é incapaz de interpretar a tag OBJECT da forma correta. Tanto é que eles já anunciaram que esse comportamento vai ser alterado na próxima versão.
Será que você está sabendo de algo que os desenvolvedores não perceberam?
Caravana,
Que os desenvolvedores, não, mas que você, com certeza : ler inglês. Pois pelas conclusões que está tirando do blog do IE só posso imaginar que não conseguiu ler o texto, pois concluiu tudo errado.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Que bom que você interpretou tudo tão bem, pra me explicar que acabaram de descobrir uma falha de segurança seriíssima com o oBJECT. Daqui a dois dias a W3C anuncia que OBJECTs são um perigo para a segurança da internet, e que será removido dos padrões.
Eu só acho muito, muito estranho que nenhum outro navegador sequer citar a necessidade de se preocupar com cross scripting. Ahh sim.. a implementação deles não é via ActiveX, é nativa.. ;)
Acorda, Alice, bugs XSS acontecem em todos os browsers, independente de ActiveX.
Serve um bug marcado como CRÍTICO, consertado agora no Firefox 2.0.0.12?
http://www.mozilla.org/security/announce/2008/mfsa2008-03.html
Se procurar no bugzilla verá que toda hora surge um XSS por aí.
Serve o bug de XSS que afetou IE, FF e Opera?
http://www.techweb.com/showArticle.jhtml?articleID...
Que tal um bug de XSS consertado no FF e ainda presente no Opera e no IE?
http://www.heise-online.co.uk/security/Bug-fixed-i...
XSS não tem NADA a ver com ActiveX. Tem a ver com browsers aceitando includes de um script em uma página, vindos de servidores externos. Isso é uma falha de segurança SIM.
Eu não estou discutindo existência de XSS. Estou falando que a implementação do OBJECT em outros navegadores, não tem as implicações de segurança que tem no IE, como o Dennes deixou a entender, pois ele usa ActiveX para interpretar.
Nenhum outro navegador ficou preocupado com essa notícia, afinal a equipe do IE não descobriu nada que refletisse nos outros navegadores.
Volte e leia o que eu escrevi...
Se você LESSE os links que mandei veria que a implementação do XSS no Firefox é justamente na tag OBJECT de uma chamada do Flash.
Exatamente, e se você ao menos LESSE os meus comentários, ficaria mais fácil de debater.
O bug já foi corrigido. Não é isso que está sendo discutido. Como eu disse, não estou discutindo a existência de XSS nesse ou naquele navegador.
O que se está falando, é que foi descoberto que a implementação do IE, se fosse interpretar a tag OBJECT como devería, iria expor os usuários a problemas de segurança.
O que isso tem com os outros navegadores? É um problema único e exclusivamente do IE, causado por questões de implementação.
Editado: Bom.. já que o meu esforço de explicar não está gerando resultados, o comentário do fcima diz exatamente o que eu estou tentando dizer em 59 comentários:
O que ocorre é a tag object é implementada por um activex. Esse activex não permite o carregamento de outro domínio.
Correto.
Isso é um bug (restrição desnecessária) do IE.
Sim é um bug. Não é uma restrição desnecessária, é uma consequência da implementação do recurso ser feita usando um controle ActiveX.
E (aposto meus tibs) será removida numa próxima versão beta.
A ver. Depende do esforço necessário para implementar este recurso "nativamente" sem ActiveX.
Abraços,
Segunda vez que eu cito, pra ver se fica mais claro. Tá em português..
http://ha.ckers.org/xss.html
Estes são bugs que permitem xss em tags object devido a implementações bugosas. (Assim como uma implementação com bugs na tag img pode permitir xss)
http://www.technicalinfo.net/papers/CSS.html
um object pode carregar dados de outro domínio. Mas... e daí? Um iframe também pode. Tanto um iframe quanto um object serão bloqueados pelo navegador se tentarem acessar dados do documento pai. (graças a isso é seguro carregar qualquer iframe numa página)
Observo que o blog do IE não diz que é object cross-domain é inseguro (essa foi a interpretação do Dennes).
O que ocorre é a tag object é implementada por um activex. Esse activex não permite o carregamento de outro domínio. Isso é um bug (restrição desnecessária) do IE. E (aposto meus tibs) será removida numa próxima versão beta.
Jr,
um object pode carregar dados de outro domínio. Mas... e daí?
Já ouviu falar de script injection ?
Pois é, impedir cross-domain scripting é uma forma de evitar que o script injection tenha resultados demasiadamente prejudiciais.
Tanto um iframe quanto um object serão bloqueados pelo navegador se tentarem acessar dados do documento pai.
Um iframe é contém uma página web. Uma tag object pode estar chamando um objeto ActiveX cuja capacidade de destruição é considerável.
Observo que o blog do IE não diz que é object cross-domain é inseguro (essa foi a interpretação do Dennes).
Errado.
IE stops the OBJECT fallback process at the highlighted line above. The team and I involved in this work decided that this is the right thing to do because IE would have to allow navigation to this cross domain content in order to determine if the failed resource is a 404 HTTP error code or any of the other failed resource indicators that are part of the standard. To maintain compatibility and be secure by default we didn’t want to invoke fallback either, as original web authors might not have intended this behavior.
O que ocorre é a tag object é implementada por um activex. Esse activex não permite o carregamento de outro domínio. Isso é um bug (restrição desnecessária) do IE. E (aposto meus tibs) será removida numa próxima versão beta.
Primeiramente, inverteu muita coisa.
Por fim, irá acabar perdendo seus tibs, pois conforme o próprio trecho que copiei acima, trata-se sim de uma questão de segurança. O fallback possivelmente será implementado, ou um alerta de segurança, mas tirar a restrição não parece estar nos planos dos desenvolvedores do IE
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Um iframe é contém uma página web. Uma tag object pode estar chamando um objeto ActiveX cuja capacidade de destruição é considerável.
A capacidade de destruicao de um ActiveX e' consideravel por falha de projeto da MS. Soh funciona no IE no Windows, nem padrao Web e'.
Do mesmo modo que arquivo de Protecao de Tela e' perigiso, e' um executavel.
Find the MyScreenSaver.exe file in the bin folder of the MyScreenSaver Application folder, and then rename the .exe file name extension .scr. For example, rename MyScreenSaver.exe as MyScreenSaver.scr.
Fonte:
An ActiveX control can be an extremely insecure way to provide a feature. Because it is a Component Object Model (COM) object, it can do anything the user can do from that computer. It can read from and write to the registry, and it has access to the local file system. From the moment a user downloads an ActiveX control, the control may be vulnerable to attack because any Web application on the Internet can repurpose it, that is, use the control for its own ends whether sincere or malicious. But, you can take precautions when you write a control to help avert an attack.
O navegador (IE) lida com esse tipo de objeto, da para entender a paranoia por seguranca. Isso explica o pq do Vista perguntar diversas vezes se o ActiveX pode executar e no final ainda nao executa.
Por que dar algo tao perigoso na mao de desenvolvedores Web? Para vender seguranca depois? Faz algum sentido se por acaso tiver um pingo de verdade. O Vista deve vender um pouco por causa disso.
David,
A capacidade de destruicao de um ActiveX e' consideravel por falha de projeto da MS. Soh funciona no IE no Windows, nem padrao Web e'.
Windows, sim. O activeX é basicamente uma aplicação a parte executada junto com o browser. Exemplo de ActiveX : Flash.
Fiquei curioso agora sobre a execução do flash em outros ambientes/browsers... de qualquer forma, mesmo sem ser activeX seria uma aplicação a parte rodando dentro do browser...
it can do anything the user can do from that computer
UAC resolveu isso no windows vista
Por que dar algo tao perigoso na mao de desenvolvedores Web?
Flash ?
De qualquer forma, o activeX tem objetivos muito mais amplos do que apenas "desenvolvimento web" . Na época em que ele foi criado, controles e documentos ActiveX eram pensados como possivel solução RIA.
Veja uma típica chamada do flash :
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=' + versao + '" width=' + largura + ' height=' + altura + ' id=' + id + '>\n'<param name="movie" value="' + arqSWF + '" /><param name="allowScriptAccess" value="always" />\n');<param name="quality" value="' + qualidade + '" />\n');<param name="FlashVars" value="' + FlashVars + '" />\n');<param name="bgcolor" value="' + bgcolor + '" />\n');<param name="menu" value="false" />\n');<param name="wmode" value="' + wmode + '" />\n');<embed src="'+arqSWF+'" wmode="' + wmode + '" bgcolor="' + bgcolor + '" FlashVars="' + FlashVars + '" menu="false" allowScriptAccess="always" quality="' + qualidade + '" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" width="' + largura + '" height="' + altura + '" swLiveConnect="true" name="' + id + '"></embed></object>
O clsid é o código único do objeto activeX do flash mantido no registry. Codebase a indicação de onde deve ser instalado caso não seja encontrado no registry.
Os parâmetros são todos específicos do flash, como aplicação a parte rodando na máquina. Um script injection de um código assim pode ser bem arriscado.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Só para responder seu questionamento, outros sistemas simplesmente procurariam o "flash player" na pasta padrão de plugin do browser, e depois (se não estiver lá) na pasta padrão de plugin do sistema, assim ignoram o "clsid", só olham mesmo o "type" para saber o que procurar, pois a ideia é achar qualquer coisa que seja capaz de interpretar esse "tipo" de conteúdo, se for um .avi, vai procurar o plugin de um player com suporte a avi... e por ai vai.
Dai se não achar pula para o codebase, ou uma lista de codebase interna.
-----
Para aquele que controla o próprio pensamento, todo o resto se torna simples jogo de crianças...
Gandhi.
Oi, Wallacy,
Se parâmetros para um plug-in viessem de um site externo, tendo sido inseridos via script injection, não haveria um problema de segurança da mesma forma ?
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Sei lá. Você perguntou como seria a implementação em outras plataformas e eu falei... Agora se vai ter problemas com script injection eu não sei.. Só respondi sua pergunta...
Apesar que como ele só faz uma busca simples por um player baseado no mime type, acredito (não tenho certeza) que pode não ter esse tipo de problema, pois ele só ira redirecionar os dados para o player, dai no caso o player teria conseguir interpretar esse tipo de scrip, o que é meio complicado. De qualquer forma eu não sei...
-----
Para aquele que controla o próprio pensamento, todo o resto se torna simples jogo de crianças...
Gandhi.
Oi, Wallacy!
Acredito que sim, independentemente de qualquer activeX.
O arquivo fornecido ao flash poderia ser um arquivo do flash, mas poderia ser perfeitamente um vídeo pornô que apareceria na página principal de um site no qual o webMaster jamais sonharia em hospedar esse conteúdo.
Se o browser barrasse chamadas cross-domain, resolveria.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Ta, mais ai não é um problema do webmaster que referenciou errado o arquivo do flash?
Novamente eu não tenho certeza... Mais até onde entendi, o problema do que você citou é justamente referenciar um conteúdo contendo scripts ou outros códigos maliciosos, esse conteúdo redirecionado é enviado a algum player de vídeo (por exemplo) ele não vai conseguir rodar esse código malicioso. No caso, outras plataformas não tem controles semelhantes ao do "activeX", pessoalmente não conheço nada similar para outras plataformas, geralmente é como eu falei, lê o mime e passa para o player responsável do sistema... E no caso iria falhar direto na identificação do mime, o codebase estaria referenciando um arquivo de vídeo, e o mime da url estaria um conteúdo de outro tipo, só ai a conexão já seria interrompida, e mesmo que continuasse o player não saberia interpretar códigos....
Até onde percebi dessa falha, é algo exclusivo ao Windows + IE, pois é o único sistema que parece ter uma implementação nesse estilo, o grande lance é justamente o "activeX" que é capaz de interpretar códigos maliciosos, logo isso se tornaria uma falha dentro desse escopo.
-----
Para aquele que controla o próprio pensamento, todo o resto se torna simples jogo de crianças...
Gandhi.
Oi, Wallacy !
Joguei a resposta para o final, porque aqui já está ficando bem apertado...
[]'s
Dennes
Oi jr.,
O que ocorre é a tag object é implementada por um activex. Esse activex não permite o carregamento de outro domínio.
Correto.
Isso é um bug (restrição desnecessária) do IE.
Sim é um bug. Não é uma restrição desnecessária, é uma consequência da implementação do recurso ser feita usando um controle ActiveX.
E (aposto meus tibs) será removida numa próxima versão beta.
A ver. Depende do esforço necessário para implementar este recurso "nativamente" sem ActiveX.
Abraços,
Jr,
O post no blog IE é claro em dizer que o problema está na implementação do IE. E isso será corrigido nas próximas versões.
Eis o trecho mais perto do que você falou. Se observar bem, os desenvolvedores do IE afirmam que decidiram ser essa ação correta a ser realizada
IE stops the OBJECT fallback process at the highlighted line above. The team and I involved in this work decided that this is the right thing to do because IE would have to allow navigation to this cross domain content in order to determine if the failed resource is a 404 HTTP error code or any of the other failed resource indicators that are part of the standard. To maintain compatibility and be secure by default we didn’t want to invoke fallback either, as original web authors might not have intended this behavior.
É possível que você esteja se referindo a esta fras :
We started with the most secure solution and are now looking into whether we can safely loosen this restriction in a future beta.
Que significa : "Começamos com a solução mais segura e estamos verificando como podemos reduzir de forma segura esta restrição em um beta futuro."
Ou seja, em momento algum existe a afirmação de que existe um problema na implementação do IE.
a "comunidade" não está pedindo, é o autor do teste que disse que o comportamento do IE está errado (seja parte do acid2 ou não).
Primeiramente, deveria ler os comentários todos, então veria que a comunidade realmente está pedindo.
Quanto ao autor do teste, ele é apenas mais um membro da comunidade e expressou sua opinião pessoal. O ACID 2 não determina o que fazer no caso de cross-site scripting.
O próprio post da MS explica que a decisão de não fazer fallback foi porque "talvez essa não fosse a inteção do desenvolvedor" o que concordo plenamente. Um código tentando fazer cross-site scripting pode ter chegado ali via ataques de script-injection. Se fosse um "código planejado" o desenvolvedor teria visto o problema de cross-site durante o desenvolvimento.
No mais, reitero o meu pedido sobre um exemplo de brecha "cross-domain scripting" com tag object. Um link já serve.
Este livro tem o que precisa : http://www.bufaloinfo.com.br/lancamento/lancamento.asp
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Oi !
Esqueci de citar : O ACID 3 é um pré-teste, as tecnologias que ele testa ainda não são padrões e podem ser mudadas.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Dennes,
O acid3 foi lancado dias atras. Aqui ha uma lista dos padroes testados, e nao vejo uma unica tecnologia que nao seja um padrao.
Todas elas ja constam na W3C como recomendacoes, inclusive algumas delas sao bem antigas, como o DOM2, que foi recomendado em 2000, SVG em 2001...
Creio que voce fez uma confusao com o CSS3, que tem grande parte ainda sendo discutida, mas as duas partes do CSS3 que sao testadas, ja constam como recomendacoes atualmente.
O grupo responsavel pela criacao do W3C tem muito cuidado na elaboracao do mesmo e jamais testaria partes que fossem rascunhos e estivessem sendo discutidas. Portanto o navegador que falhar, nao suporta um padrao que ja consta como recomendacao da W3C.
Nao ha pre-teste, nem pre-tecnologia. Ha navegadores que nao suportam padroes.
Caravana,
Creio que voce fez uma confusao com o CSS3, que tem grande parte ainda sendo discutida, mas as duas partes do CSS3 que sao testadas, ja constam como recomendacoes atualmente.
Seu próprio texto e os links contradizem você. Nos dois links a tecnologia está com o título "Candidate Recomendation".
Pode virar um padrão ou não.
Ou seja : O ACID 3 está testando recomendações que ainda não são um padrão.
Na própria página das recomendações você encontra links para as versões do documento de recomendação (e não padrão).
Dois links para ajuda-lo :
http://blogs.msdn.com/ie/archive/2008/03/05/why-isn-t-ie8-passing-acid2.aspx#8064841
http://blogs.msdn.com/ie/archive/2008/03/05/why-isn-t-ie8-passing-acid2.aspx#8065163
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Dennes,
Voce nunca viu as especificacoes da W3C, acertei? :P
O consorcio trabalha com recomendacoes. Voce nao vai achar uma especificacao que esteja entitulado como standard. Tem duvida? Visite a especificacao do HTML 4.01 e CSS1, que sao recomendacoes de 1999.
Os que nao sao recommendation, sao marcados como draft.
Volto a dizer: eles jamais seriam levianos de testar padroes (ou recomendacoes, como preferir) que sejam rascunhos.
Caravana,
Entre os rascunhos e as recomendações você está se esquecendo de algo muito importante : As CRs, ou Candidate Recomendations.
Observe mais uma vez os links que você mesmo apontou : Eles são recomendations. Os links anteriores, ligados a padrões testados no ACID 3, não são recomendations, mas Candidate Recomendations, isso tem uma boa diferença.
Se observar os próprios comentários no documento, os "recomendation" são citados como sendo "stable documents" enquanto que os CR não.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Peco desculpas pela falta de atencao, mas agora entendi o que voce quis dizer. ;)
Candidate Recommendation != candidate standard, que por sua vez == Draft. Nao estamos tratando de pre-tecnologias, discuti isso abaixo...
Sem problema ;)
---------------------
CidadaoCarioca
BufaloInfo
O swiftfox (FF3b4pre) consegue 62/100 no Acid3.
67/100 no último nigtly build.
Oi
Adorei saber que mais uma vez a Microsoft está inovando e entendendo que primeiro devemos entender e compreender o produto concorrente para assim se poder desenvolver um produto melhor
Att
Juliana Prado Uchoa
Bom. Só uma correçãozinha, na boa: Esse "não houve seus usuários" é de doer os houvidos!
Passou pela correção... agora está certo. Obrigado, Danillo.
Podia tirar também os espaços antes da pontuação. Isso é meio caminho para o miguxês.
Oi, Danillo !
Fiz em uns 10 ou 15 minutos... um "h" fora de lugar é perdoavel, vai lá saber o que passou pela mente na hora... :?
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
No primeiro dia que lançaram o IE 8 B1, eu tentei a acessar a página oficial e não entrava.
Então o problema está resolvido. Hmm
Bola fora
WorldOrg
a microsoft tem se mostrado disposta a melhorar ou estou 'ludibriado'?
Ha varios sinais de que ela ja mudou, e isso anima bastante, ainda que seja possivel observar o quanto o IE precisa caminhar.
Dennes, uma pergunta:
A Microsoft disponibiliza (ou pode disponibilizar) as informações do IE6 e 7 em relação ao tratamento de paginas fora do padrão? Se não seria uma boa, assim outros navegadores se compatibilizariam mais rapidamente, afinal muito desses sites foram desenvolvidos pensando no IE....
-----
Para aquele que controla o próprio pensamento, todo o resto se torna simples jogo de crianças...
Gandhi.
Oi, Wallacy !
Já vi coisas sobre isso sim. Mas não lembro do link... acho que se colocar essa pergunta lá no blog do IE terá boas respostas...
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Agora é o Opera que não funciona direito.. :P
ZOMG Mensagem subliminar!
Daniel.
Deixe-me ver se entendi:
Ta rolando puta alvoroço porque a Microsoft finalmente resolveu seguir os padrões.
Se não me falha o senso para coisas simples, isso não era uma OBRIGAÇÃO por parte da Microsoft? Afinal os produtos dela não são nem um pouco baratos para "não funcionarem corretamente" (tá, sei que em teoria o IE é gratuito, mas você precisa do SO que não é).
Nós da informática nos tornamos "partidários" de um ou de outro e nos esquecemos de pensar como consumidores. Temos que sempre exigir qualidade, goste ou não da filosofia daquela empresa.
Uma dúvida:
Ficou acertado que o IE não permitirá cross-domains, e os demais permitirão?
Porque se novamente um dos navegadores ficar na contra-mão dos demais, os problemas dos desenvolvedores continuam.
A pura verdade:
Padrão é o que a microsoft quiser implementar.
Se ela não implementar algo no IE, por mais que ele exista a anos nos demais browsers, a feature não anda.
Que bom que a MS quer adotar os 'padrões web'. Porque se não quisesse, o desenvolvedor continuaria trabalhando com rowspan e colspan pelo resto da vida.
Oi, Zé !
isso não era uma OBRIGAÇÃO por parte da Microsoft?
Isso não é uma obrigação por parte de empresa alguma (o que não significa que a Microsoft não esteja comprometida com isso). A empresa faz seu produto seguir o padrão se desejar, e você usa o produto se desejar.
Existe diferença entre um padrão determinado (imposto, digamos) e um padrão de mercado. Veja o próprio exemplo do ACID 3 : várias tecnologias dele são CR, ou seja, Candidate Recomendation, não são padrões. Só vão virar padrões quando pelo menos dois browsers suportarem a tecnologia. Sendo que tais tecnologias estão em CR desde 2003/2004, se não me engano pelas datas dos documentos...
para "não funcionarem corretamente"
Seguir o padrão e funcionar corretamente são duas coisas completamente diferentes. Um software pode funcionar e não estar dentro de determinados padrões, assim como vários browsers/versões de várias diferentes origens não seguem totalmente o ACID 2, nem por isso signifca que não funcionam corretamente.
Uma dúvida: Ficou acertado que o IE não permitirá cross-domains, e os demais permitirão?
Eis ai a diferença entre padrão e funcionamento e a questão de não obrigação.
O padrão não determina nada com relação a segurança cross-domain, cabe a cada browser implementa-la da sua forma. O IE optou pela forma mais segura.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Sei que vou ser chato, mas dennis, por favor reveja a lista de padroes testados e volte na pagina da W3C.
Nenhuma tecnologia que esta sendo testada no acid3 'e candidata a alguma coisa. Todas ja constam como padroes da W3C, e se voce quiser realmente me dar trabalho eu ate' lhe aponto as especificacoes de cada um daquela lista que te passei.
E lembre-se que recomendacao (recommendation) nas especificacoes da W3C 'e equivalente a padrao (standard).
Caravana,
Este link : http://www.w3.org/TR/2003/CR-css3-color-20030514/
Foi fornecido por você, no seu comentário.
Está escrito bem grande no topo do documento "W3C Candidate Recomendation" - ou seja, é uma CR e não uma recomendation.
Portanto, observe com cuidado os links que você mesmo forneceu.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Acabei de ver o que voce estava tentando falar, falta de atencao. Vamos ao site da W3C:
A Candidate Recommendation is a document that W3C believes has been widely reviewed and satisfies the Working Group's technical requirements. W3C publishes a Candidate Recommendation to gather implementation experience.
Proposed Recommendation (PR)
A Proposed Recommendation is a mature technical report that, after wide review for technical soundness and implementability, W3C has sent to the W3C Advisory Committee for final endorsement.
W3C Recommendation (REC)
A W3C Recommendation is a specification or set of guidelines that, after extensive consensus-building, has received the endorsement of W3C Members and the Director. W3C recommends the wide deployment of its Recommendations. Note: W3C Recommendations are similar to the standards published by other organizations.
E aqui, no final da pagina voce le:
"A REC is what is normally referred to as a “standard.” W3C encourages everyday use starting from CR (estagio atual das duas tecnologias CSS3 testadas no acid3)."
Todas essas tecnologias ja foram discutidas amplamente (muitas com participacao da propria Microsoft). Em todos os navegadores normais (leia-se todos menos IE), tecnologias criticas como CSS3 comecaram a ser implementadas pra valer ainda em estagio de CR. Ate para ajudar a depurar a especificacao.
Eles possuem esse titulo, somente por uma questao de ajuste dos documentos, e o titulo se refere ao documento, e nao ao padrao discutido. Nenhuma dessas tecnologias vai sumir, ser abduzida ou sofrer uma mudanca radical que quebre todas as implementacoes que existem hoje.
De agora, ateh essas recomendacoes passarem ao dois seguintes estagios, somente serao feitos ajustes de implementabilidade e outras coisas que voce pode ler na citacao que fiz acima. Fica muito dificil a Microsoft participar dessas fase de discussoes de implementabilidade, sem implementar, nao acha?
Oi, Caravana,
Nas páginas das CRs você encontra o seguinte :
For this specification to exit the CR stage, the following conditions shall be met:
There must be at least two interoperable implementations for every feature in the Color Module.
Ou seja, não existem ainda 2 browsers que implementem os recursos testados pelo ACID 3, na verdade nem mesmo 1.
Sim, eles incentivam que seja implementado sim, para que saia de CR e se torne algo que eles chamam de recomendação e nós poderiamos chamar de padrão de mercado. Se ninguém implementar, nunca sai de CR.
Depois de CR existe ainda o PR, como você indicou. Quer dizer o seguinte : Quando dois browsers implementarem a recomendação, eles irão descobrir muitas questões que poderão alterar o padrão, transformando o CR em PR.
Resumindo : O ACID 3 testa padrões que ainda estão no nível de CR, o que significa que ainda estão longe de serem padrões de mercado (nem ao menos 2 browsers implementaram) e que quando forem se tornar padrão de mercado o processo de implementação deles fará com que passem por transformações, por isso o estágio de PR.
Por isso não existe nada de estranho, digamos, em não haver ainda a passagem pelo ACID 3 em uma versão beta 1.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Sim, eles incentivam que seja implementado sim, para que saia de CR e se torne algo que eles chamam de recomendação e nós poderiamos chamar de padrão de mercado. Se ninguém implementar, nunca sai de CR.
Versoes finais, nao. Tanto o Firefox, quanto Safari e o Opera estao trabalhando nisso. A Microsoft anda meio enrolada com CSS2 mesmo, e logo apos versoes finais dos outros navegadores serem lancadas, os documentos passarao de CR para PR, a Microsoft vai continuar sem implementar. Qual a diferenca?
Situacao ate bem contraditoria, pois a Microsoft ja discutiu e consentiu tecnologicamente com o padrao.
Nao exatamente. Quanto dois navegadores, principalmente de plataformas diferentes, implementam o padrao, eles veem que nao ha risco para interoperabilidade, discutem as dificuldades encontradas por aqueles que implementaram e ajustam os padroes (eu expliquei isso por alto, no meu comentário abaixo, em resposta ao Fabio).
A tecnologia como um todo fica intacta. Ela ja foi discutida, aceita, aprovada, consentida... o processo e longo demais. Volto a dizer que a questao agora 'e meramente burocratica. Querendo ou nao, CSS3 vai passar para os estagios seguintes contendo as mesmas funcionalidades que tem agora (nao existe a possibilidade de isso nao ocorrer).
Por isso não existe nada de estranho, digamos, em não haver ainda a passagem pelo ACID 3 em uma versão beta 1.
Por favor, nao tente resumir o Acid3. Ele testa varias coisas, o CSS3 eh uma parte muito, muito pequena do todo. DOM2, por exemplo, 'e esta no estagio que so voce considera valido, desde 2000...
E o HTML4 desde 1999.
E o XHTML desde 2000.
E o SVG desde 2003.
Todos sao testados no Acid3.
Como eu ja disse, a propria Microsoft implementou o CSS2.1 ainda em CR, portanto isso nao quer dizer nada. Agora, o Internet Explorer 8 passar em somente 17 testes, diz muita coisa.
Nem de longe dignifica que ele nao implementou CSS3 (tecnologia que voce tenta invalidar por nao ter chegado no ultimo estagio, em termos de documentacao). Significa que ele nao implementou corretamente quase nada do que foi testado. Nao ha motivos para se orgulhar aqui...
Caravana,
e logo apos versoes finais dos outros navegadores serem lancadas, os documentos passarao de CR para PR, a Microsoft vai continuar sem implementar. Qual a diferenca?
Você tem bola de cristal ?
ajustam os padroes
Qual parte de "ajustam os padrões" não significa que o "padrão" será modificado ?
Ela ja foi discutida, aceita, aprovada, consentida...
Foi tão discutida que ninguém previu um problema de cross-site scripting...
Internet Explorer 8 passar em somente 17 testes
Qual parte de beta 1 você não entendeu ?
tecnologia que voce tenta invalidar
Não atribua a mim algo que eu não disse... leia tudo novamente se necessário...
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Algumas das especificações apontadas no acid3 são padrão sim.
Pelo menos todas as de DOM2, por exemplo. Não são 'Candidate Recomendation', são 'Recomendation' mesmo.
O problema é saber quais são as 17 especificações que o IE8 atende.
Insistindo: 'e candidate recommendation, nao 'e candidate standard. A propria W3C incita em varios documentos que os padroes comecem a ser implementados pouco antes dele chegar a ser Candidate Recommendation, pois tecnicamente jah atingiu um estagio maduro.
Nao estamos tratando de pre-tecnologias, mas de documentacoes que precisam ser ajustadas.
Inclusive o IE8, sera lancado em conformidade com o CSS2.1, que estranhamente nao poderia ser implementado segundo a visao do Dennis, pois consta como CR. Ainda bem que a Microsoft nao tem essa visao, e nao so ja implementou a revisao mais atual do CSS2, como esta contribuindo com 700 testes licenciados sob a BSD, para que estes sejam modificados e inclusos nos documentos oficiais, antes que estes passem para o estagio seguinte.
Os criterios para que as duas partes do CSS3 que eu citei, por exemplo, passe de CR ao estagio seguinte sao:
* 6 meses de estagio CR.
* O periodo pode ser prolongado caso nenhuma implementacao apareca.
* Funcionalidades que sao consideradas de risco poderao ser retiradas (estao todas destacadas na documentacao), caso nao haja implementacoes que satisfacam a situacao abaixo, ou testes suficientes para essas funcionalidades nao aparecam antes do estagio de CR acabar.
* A ultima 'e ter pelo menos duas implementacoes em versoes finais de navegadores de amplo alcance.
(estao todas logo no comeco das especificacoes que eu citei, caso alguem queira confirmar)
Como pode-se ver, nao ha nenhum ponto tratando de revisao de tecnologia, mas de implementabilidade e documentacao. Inclusive para que a documentacao passe para o estagio seguinte, 'e preciso que dois navegadores tenham incluido a tecnologia no motor de desenho em uma versao final, estavel. Dificil sem a ajuda do IE8, nao?
A diferenca entre uma CR, PR e REC sao mais burocraticas que tecnologicas.
Insisti para o dennis tomar cuidado ao tratar desses padroes como pre-tecnologias, exatamente por isso. As tecnologias ja existe, nao serao mudadas radicalmente, pois ja foram amplamente discutidas, aprovadas e consentidas pelas partes que participam da W3C.
P.S.: ODEIO teclado desconfigurado.
Caravana,
que estranhamente nao poderia ser implementado segundo a visao do Dennis
Não foi isso que eu disse, que não poderia ser implementado. A implementação é necessária para que o documento saia do nível de CR. Apenas destaquei a questão do CR, uma implementar um padrão CR é muito menos importante do que um REC, afinal o CR vai mudar.
mas de documentacoes que precisam ser ajustadas.
Ou seja, alteradas, e
duas vítimasdois voluntários vão pagar o custo de ter que reimplementar depois das alterações.Como pode-se ver, nao ha nenhum ponto tratando de revisao de tecnologia, mas de implementabilidade e documentacao
No outro comentário, você colocou a definição do PR. A própria definição do PR, e também a do REC, citam que durante os testes de "implementabilidade" recursos podem ser alterados. Afinal é por isso que existe o PR
Dificil sem a ajuda do IE8, nao?
Eis a questão sobre padrão de mercado...
nao serao mudadas radicalmente
"radicalmente" é uma coisa tão relativa... além disso você não tem certeza disso. As tecnologias não foram implementadas, quando forem é que saberemos se irão virar padrões de mercado ou não.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Bom, aqui chegamos a um acordo. Eu realmente prefiro que a Microsoft implemente os documentos que já estão em fase de REC desde 1999, pra depois começar os CRs de 2003 para cá. A mudança eu discuto abaixo...
duas vítimasdois voluntários vão pagar o custo de ter que reimplementar depois das alterações.Não há vítimas. Toda a discussão maior é feita antes que o documento chegue nesse estágio, o processo como eu já falei é bem burocrático e longo, todas as partes têm que consentir com a proposição para que chegue ao estágio de CR, portanto quando eu digo que ele já é tecnologicamente maduro, significa que as grandes questões de implementabilidade já foram discutidas muito, muito antes.
Tanto que se você ver a documentação do CSS3, há 5 ou 6 pequenos trechos do padrão, que são colocadas como em risco, exatamente por ter sido levantada questões de interoperabilidade anteriormente. Se dois navegadores diferentes conseguirem implementar essas partes, ele parte para o próximo nível, caso contrário será levantada a questão do motivo de somente um único navegador ter conseguido implementar. Enfim, há uma seriedade imensa em não prejudicar quem já implementou (isso até mesmo antes da CR).
Questões de implementabilidade são diferentes de funcionalidade. Haverão ajustes em questões pequenas, que refletirão em ajustes na implementação. Nunca, nesse estágio, há um quebra ou qualquer outra coisa do tipo que possa prejudicar seriamente implementações existentes (sendo insistente, o padrão já foi amplamente discutido e consentido antes de chegar até o CR).
A tecnologia já existe, já foi discutida, e é exatamente essa que está no documento. Por isso eu disse que não há testes de pré-tecnologias no acid3 (até por que, somente o CSS3 está em CR).
Realmente é relativo, mas historicamente não houve nenhuma reclamação em relação aos ajustes propostos na mudança de CR para PR, pois são somente isso, ajustes. Caso você saiba da existência de alguma proposição que mudou de CR para PR, que quebrou as implementações existentes, e prejudicou os pioneiros, peço que cite, pois vai contra todo o protocolo da W3C.
Editado: Aliás, se fosse realmente arriscado, você acha que a Microsoft iria pular direto na revisão 1 do CSS2, ao invés de implementar somente o que está previsto na proposição antiga, de 1999? Revisões de padrão sim quebram funcionalidades, avanço de documentação (CR -> PR -> REC) não, e é exatamente por isso a Microsoft não perdeu tempo em implementar o CSS2, e foi direto ao CSS2.1, mesmo que ele se encontre em CR, e ela precise ajustar poucas coisas posteriormente.
Como já disse, nessa proposição em específico, ela está participando ativamente, enviando inclusive 700 testes para a W3C, licenciados pela BSD para que eles usem como bem quiser. O risco da Microsoft ter que realizar mudanças estruturais na implementação do CSS2.1, quando este passar para PR ou REC, é nulo, pois a tecnologia CSS2.1 já foi estabelecida muito antes.
Caravana,
Não há vítimas. Toda a discussão maior é feita antes que o documento chegue nesse estágio
Você jura que alguma vez já fez um sistema que não mudasse nada entre as duas discussões de análise e sua implementação ?
caso contrário será levantada a questão do motivo de somente um único navegador ter conseguido implementar
Haverão ajustes em questões pequenas
Ou seja, você considera que uma parte do padrão deixar de ser padrão porque vários browsers não conseguiram implementa-lo e consequentemente aquele que conseguiu e é usado por alguns milhares de usuários passa instantaneamente a estar implementando algo que não é padrão como sendo uma questão pequena....
sendo insistente, o padrão já foi amplamente discutido e consentido antes de chegar até o CR
Sendo insistente, me conte qual sistema seu não mudou entre a discussão com o usuário e a implantação final.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
É exatamente esse o ponto. Não se está discutindo a tecnologia, se está maturando documentações da mesma. São coisas completamente diferente, e a primeira, como eu disse, vai permanecer intacta.
Você não leu o que eu disse, ou entendeu a coisa um pouco diferente.
Primeiro que não sou eu quem considero, estou lhe falando sobre o processo adotado pela W3C. Segundo que estamos falando de uma parte realmente pequena de todo o padrão discutido, e ela é sinalizada na documentação (implementabilidade é recorrente em todo o processo). Terceiro que como eu disse, caso haja uma implementação válida, dificilmente essa parte será removida.
A exigência de duas implementações é para garantir interoperabilidade, e validar a primeira implementação.
Não existe nesse momento discussão com o usuário. Toda a discussão envolvendo a tecnologia já foi feita muito anteriormente.
Quando chega ao estágio de CR, a questão entra em um nível superior de discussão sobre implementabilidade, interoperabilidade e essas questõezinhas mais chatas, que até já foram discutidas antes "com o usuário", como você quis colocar. Até por que, sem haver implementação, a recomendação não passa para o nível seguinte.
Exatamente por isso todos os padrões da W3C permaneceram o mesmo, tecnologicamente falando, da mudança CR -> PR.
Volto a te perguntar: você acha que se realmente houvesse mudança estrutural nesse momento, a Microsoft ía arriscar implementar o CSS2.1 no IE8?
Caravana,
É exatamente esse o ponto. Não se está discutindo a tecnologia, se está maturando documentações da mesma. São coisas completamente diferente, e a primeira, como eu disse, vai permanecer intacta.
Quando você diz tecnologia, a que tecnologia se refere ?
Você percebeu que esta "tecnologia" só existe no papel, já que nenhum browser chegou a 100 no ACID 3 ?
Então você está afirmando que durante o processo de implementação do que está no papel dentro dos browsers, nada vai mudar....
Mais uma vez repito a pergunta : Alguma vez, ao implementar o que estava no papel após o levantamento com os usuários, você conseguiu que absolutamente nada mudasse no seu sistema ?
Primeiro que não sou eu quem considero
É você quem está falando que haverão apenas pequenas mudanças, o W3C não assume essa responsabilidade, não coloque a culpa nele.
Segundo que estamos falando de uma parte realmente pequena de todo o padrão discutido, e ela é sinalizada na documentação (implementabilidade é recorrente em todo o processo).
Você se refere a "implementabilidade", citada no documento ?
Por que você acha que "implementabilidade" é parte pequena ? Quantas vezes um usuário já pediu a você algo que você teve que mudar posteriormente ? Você estava na discussão, mas ainda assim teve que mudar posteriormente, não ?
dificilmente essa parte será removida.
Dificilmente não significa que não possa ser
Não existe nesse momento discussão com o usuário. Toda a discussão envolvendo a tecnologia já foi feita muito anteriormente.
Discussão envolvendo tecnologia=analise
Qualquer analista de sistemas sabe que o processo de análise dura durante todo o processo de criação do sistema, podendo-se descobrir no momento de implementação que algo pensado na análise precisa ser alterado.
essas questõezinhas mais chatas
Essas quetõezinhas chatas fazem parte da implementação do sistema e se será ou não implementado desta forma. Vide exemplo do cross-site scripting que foi pego pelo IE 8 e não estava previsto ....
Até por que, sem haver implementação, a recomendação não passa para o nível seguinte
Se houvesse essa certeza que você tem de que nada muda, então por que essa burocracia ?
Ocorre que essa certeza não existe, é um processo de criação de um sistema.
você acha que se realmente houvesse mudança estrutural nesse momento, a Microsoft ía arriscar implementar o CSS2.1 no IE8?
Alguém tem que fazer, certo ? Duas vítimas.
Como você pode saber algo sobre a estratégia que estão utilizando ?
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Dennes,
Entre na lista de discussão da W3C e envie sugestões de melhoria no processo, pois é assim que é feito desde muito tempo.
Volto a dizer que período de discussão sobre a fundação da tecnologia (por tencnologia, estou me referindo ao formato) é muito antes da CR.
O IE8 não é vítima nenhuma, nem foi acometido por altruísmo para beneficiar a comunidade. A verdade é que sendo pioneiro, ele ajuda a criar os processos de validação, e vai implementando de acordo com eles. Exatamente por isso ela tem segurança de que não irá precisar ajustar nada, durante o avanço do formato na W3C.
Volto a dizer que na história da W3C não conheço um exemplo de algum padrão que foi implementado e que teve que ser radicalmente reformulado após a CR.
Tanto Opera, quanto WebKit e o Firefox estão implementando os padrões testados pelo acid3. O WebKit aliás, está bem perto de passar totalmente no teste - 88 de pontuação, usando a última versão. A Microsoft tem bastante gente do lado ensinando como se faz, acho que vai ter condições de chegar lá...
Agora, a última preocupação dos três navegadores ao implementar CSS3 por exemplo, são as alterações no padrão em si, na mudança CR->PR, muito pelo contrário. Ao mesmo tempo em que se implementa padrões que estão em fase de CR, se criam testes para validar essas implementações, e além disso uma implementação acaba também servindo para validar as demais.
Quem desenvolver baseado nessas validações, mais ainda, quem ajudar a desenvolver essas validações (como a Microsoft faz com o CSS2.1), não precisa se preocupar em ajuste algum.
Não vejo onde estamos tratando de pré-tecnologia, afinal ela já existe e já está documentada, falta somente validadores e informações sobre como lidar em situações específicas que só vão aparecer durante a implementação. Também não vejo onde está vítima nenhuma. Os pioneiros simplesmente ajudam no processo de criação da validação das implementações e a formular essas demais questões na documentação.
Caravana,
Não vejo onde estamos tratando de pré-tecnologia, afinal ela já existe e já está documentada
Desde quando algo que está documentado é algo que existe ?
Uma afirmação assim demonstra pouca prática e conhecimento de análise e projeto de sistemas.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Claro.. e sua tentativa de limitar o Acid3 ao CSS3, demonstra pouco conhecimento técnico a respeito de um teste que está sendo amplamente discutido atualmente.
Oi, Fabio !
Pois é, só algumas já estão como recomendation...
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
So algumas nao, a grande maioria ja esta como recommendation. Basta pesquisar usando a lista que eu indiquei do Acid3.
A intencao do pessoal que criou o Acid3, ao incluir CSS3, 'e exatamente fazer com que os navegadores implementem essas partes que ja estao tecnologicamente amadurecidas. Mesmo que outras partes alem do pouco de CSS3 que o teste contem fosse CR, nao ia dizer nada...
Caravana,
tecnologicamente amadurecidas.
Seu conceito de tecnologicamente amadurecidas é extremamente relativo...
---------------------
CidadaoCarioca
BufaloInfo
Assim como o seu. Dizer que uma tecnologia é pré-tecnologia, somente por que o IE não suporta, é questionável.
Você diria que CSS2.1 é uma pré-tecnologia? Por que sim ou não? O IE estaria perdendo tempo implementando uma pré-tecnologia por qual motivo?
Agora qual o critério que diferencia o CSS2.1 do CSS3, se ambos estão no mesmo estágio de documentação?
Volto a dizer que o processo agora não é mais de modificar a tecnologia, mas de amadurecer a documentação, e não sou eu quem digo isso, é a própria W3C.
Caravana,
Dizer que uma tecnologia é pré-tecnologia, somente por que o IE não suporta, é questionável.
Questionável é a forma como atribui a mim uma afirmação que é toda sua.... não foi nada disso que eu disse.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Poderia responder as outras perguntas? Então CSS2.1 é uma pré-tecnologia, na sua visão?
Será que a maneira que o MS Excel calcula ano bissextos é um "padrão de mercado"?
Vamos ver;
Pelo calendário gregoriano o ano 1900 não é bissexto, já o MS Excel o considera como sendo. Isso foi feito para garantir compatibilidade com outras versões que continham esse erro.
Agora vamos analisar, se você considerar que o Excel é a planilha mais utilizada no mundo deve ser o "padrão de mercado", sendo assim como a Microsoft insiste em continuar com esse bug no software temos que o calendário gregoriano que é um "padrão de fato e oficial", foi aposentado pelo calendário microsoftiano, que é um "padrão de mercado". Isso implica que todos os calendários perpétuos existentes estão errados! :jawdrop:
Eu te apoiava até você escrever isso.
Que que o orifício do amor tem a ver com a calça ?
Isso é verdade, e a Microsoft queria que a ISO engolisse esse bug na especificação OOXML. Isso quer dizer, se isso acontecesse o bug do Excel seria um segundo padrão para definição de datas.
Pode parecer besteira, mas isso é muito sério. Indica que essa história de padrão de mercado é balela, já que um software que é um "padrão de mercado" calcula datas de maneira errada contrariando um padrão estabelecido muito antes de ele existir.
Agora se te magoei, ou feri, desculpe-me.
Não, não feriu não... eheheh...
Mas, a comparação que fez é esdrúxula.
Você, eu, e todo mundo sabemos que a microsoft não tem poderes para mudar o calendário. O que ela queria (segundo você diz, porque eu não fui querer saber sobre, estou confiando em suas palavras), era manter uma espécie de compatibilidade esquisita para as versões anteriores, suponho.
Não considero esdrúxula pois mostra que padrões são adotados por organismos internacionais e por isso são aceitos como tal.
Agora falar de padrão de mercado é uma bobagem já que um "padrão de mercado" pode estar indo contra um padrão internacional, e portanto não é padrão.
Concordo que o problema de 1900 é o caso extremo, mas ele existe no Excel (só na versão Windows, pois no Mac utiliza rotinas do SO que sabem calcular anos bissextos no padrão ISO), e a especificação OOXML outro pretenso "padrão de mercado" (falso, pois nem o Office 2007 o suporta), que a Microsoft através da ECMA quis forçar a ISO adotar em paraledo ao ODF, continha a fórmula errada de cálculo de anos bissextos, para garantir compatibilidade com versões anteriores.
Ubiratan,
Agora falar de padrão de mercado é uma bobagem já que um "padrão de mercado" pode estar indo contra um padrão internacional, e portanto não é padrão.
Não é minha especialidade, creio que outras pessoas aqui podem dar bons exemplos, mas vários padrões internacionais com certeza surgiram a partir de padrões do mercado.
Creio que o TCP/IP (ou pelo menos parte dele) está nesta lista.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Ubiratan,
Qual o padrão de mercado mais estabelecido, o calendário gregoriano ou o excel ?
Compare também o calendário gregoriano com o calendário (chama-se calendário judeu ? Qual o nome correto ?) e temos mais um exemplo de padrão - ou não - de mercado.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Estou falando de padrões internacionais, e vários calendários são padrões internacionais, o gregoriano, o sionista, o mulçumano, o chinês, etc. O que estou dizendo é que o Excel implementou o padrão gregoriano errado e queria que esse erro se reproduzisse em uma padrão ISO, para "garantir a compatibilidade com versões anteriores".
Entendeu porque eu disse que esse padrão de mercado é balela? A Microsoft queria que um BUG fosse oficializado, tanto que definiu sua própria fórmula para calcular anos bissextos em vez de remeter ao padrão ISO para isso.
Então não fale em padrão de mercado, um padrão deve ser estabelecido por um orgão competente para isso. E se a Microsoft quer fazer um browser deve seguir os padrões estabelecidos para tal, senão como fica a tal interoperabilidade?
Ubiratan,
Estou falando de padrões internacionais, e vários calendários são padrões internacionais, o gregoriano, o sionista, o mulçumano, o chinês, etc
Os chineses que vendem pastel na uruguaiana usam o calendário gregoriano ou o chinês ? Usam o padrão de mercado ou o padrão internacional ?
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Não tente desviar o assunto por favor.
Mais de padrão é adotado quando um não contradiz o outro, no caso dos calendários, as conversões entre eles estão documentadas e são válidas, sendo assim o chinês que vende pastel pode utilizar o calendário que ele quiser!
O que não pode é implementar um calendário de maneira errada e querer forçar sua adoção por um organismo internacional.
Entendeu?
Vamos lá, agora com o Acid3:
- Safari 3.0.4 = 39/100
- Opera 9.26 = 46/100
- Camino 1.5.1 = 52/100
- Firefox 3.0b3 = 59/100
Como foi o IE 8 no Acid3?
Só para nota, o site acid2.acidtests.org contém os acidtests oficiais, já que é um site mantido pela webstandards.org.
Tem no texto.. :P
Obrigado, agora notei ele "já alcança 17/100" sem dúvida um grande feito!
hehehehe! }:)
------
Vaca amarela, pulou a janela.
Precisam inventar 'acid tests' para os desenvolvedores também.
Aposto que a maioria absoluta deles vão tirar notas negativas.
Porque, encher o saco pelos padrões todo mundo enche (inclusive eu). Agora, implementar eles corretamente nos sites que desenvolvem, é raridade.
Mas, dá nada não... Tá tudo errado? Culpa a Microsoft.
O problema 'e que eles acham que ja inventaram.
Parece haver um consenso entre os estagiarios de dreamweaver que mesmo que a pagina esteja um lixo e o codigo esteja um samba do crioulo doido, se passou nas dezenas de validadores que existem por ai, esta "dentro da W3C".
Oi, Fábio !
Sem dúvida muito necessário.
O Visual Studio já possui, há algum tempo, o recurso de analisar seu HTML conforme os padrões que você determinar. Caso seu HTML esteja fora do padrão, ele pode gerar warnings ou erros, conforme sua configuração.
Até agora isso foi pouco usado/comentado pois o Visual Studio 2005 teve problemas com relação a design gráfico (particularmente, não acho uma boa opção deixar um ambiente tão poderoso, com tantos recursos, apenas por causa de alguns problemas de design...) mas o Visual Studio 2008 veio muito, muito bom com relação ao design gráfico.
Some-se a isso que com o Team System e Team Foundation Server um coordenador de equipe pode a qualquer momento, sem interromper o trabalho dos desenvolvedores, obter um relatório de qual o índice de compliance com os padrões cada desenvolvedor tem e assim poder se divertir dando bronca em todo mundo.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Oi, Ubiratan !
Como poderiam ser oficiais, se nem eles mesmos são padrões, ou seja, iguais um ao outro ?
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
E como você sabe qual é o padrão? Onde está escrito isso?
Sendo assim posso assumir que o IE8 cobre os padrões do Acid2 mas o Safari e o Firefox extrapolam os padrões?
Ubiratan,
http://www.webstandards.org/files/acid2/test.html
IE 8 cobre os padrões ACID 2 e possui implementações de segurança para impedir o risco de cross-site scripting, implementações estas que estão além do padrão ACID 2.
Safari e Firefox nem ao menos identificaram que as duas páginas de teste eram diferentes.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Ué o Explorer identificou que as duas páginas eram diferentes?
Absolutamente não. Ele falhou ao montar uma delas.
Agora, se ele "identificou" que as duas páginas eram diferentes, isso me leva a crer que os padrões só foram implementados para passar na página de testes.
Na verdade a única entidade que pode dizer qual o padrão correto é a webstandards.org, sendo assim, como as duas páginas são mantidas por ela mesma os dois são válidos, a menos que ela venha se retratar a público.
Essa do IE8 ter identificado a página não oficial foi muito boa.
Ubiratan,
Ué o Explorer identificou que as duas páginas eram diferentes? Absolutamente não. Ele falhou ao montar uma delas.
Ele não falhou. Ele deixou de montar propositalmente no momento em que esbarrou com uma tentativa de cross-site scripting. É algo completamente diferente.
Na verdade a única entidade que pode dizer qual o padrão correto é a webstandards.org
Os próprios documentos da webstandards.org tem o título de "recomendação", isso não é por acaso.
Além disso, existir um teste que provoca cross-site scripting no meio dos testes de padrões é meio embaraçoso...
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Esse ponto da "recomendação" é interessante.
É uma recomendação pois o a webstandars.org não tem poder para definir um padrão, a função deles é manter um padrão. Quem define o padrão é a ISO, a partir das recomendações do webstandards.org. Por isso é utilizada essa terminologia. Você pode dizer que uma recomendação da webstandards.org fatalmente irá se tornar um padrão ISO.
Outro exemplo é o OOXML, ele não é um padrão ISO, se for aceito tudo que a ECMA recomendar sobre o padrão será submetido à ISO e aceito.
Isso é interessante pois para um padrão ser aceito pela ISO ele NÃO PODE IR CONTRA OUTROS PADRÕES ISO. Voltamos ao cálculo do anos bissextos se o OOXML quer ser um padrao ISO ou modifica-se a regra de cálculo de anos bissextos da ISO ou se modifica o OOXML.
Entendeu?
Ubiratan,
Entendi que você mudou por completo de assunto, e o chinês da uruguaiana vai continuar usando o calendário gregoriano, porque é este que todo mundo em volta dele usa, não interessando a opinião de nenhuma organização internacional.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Não mudei de assunto, estamos falando de padrões e dei um exemplo de como eles são formados.
Agora, fique com seus pastéis e seu chinês de uruguaiana. Parece que para você eles são mais importantes que o cumprimento de padrões.
Por falar nisso você venceu!
O IE8 É O ÚNICO BROWSER QUE DESCOBRIU QUE O ACIDTEST.ORG É UMA FARSA!
Ás vezes é melhor de desistir de falar do que falar para as paredes.
Hahahah.. não desiste não campeão.. :P
Calma que já já alguém prova que o acid2 é uma ameaça a segurança dos navegadores.
O mais interessante é que o Acid2 foi criado pela Opera, e o browser Opera passou no teste. Lógico. Mas, no Opera 9 detetaram que o browser não estava reagindo como deveria ao teste, a própria Opera recolheceu os bugs do browser e os corrigiu. Ela podia ter dito que o teste "oficial" era o que ela tinha criado, mas não o fez.
Só uma correção: o acid2 foi criado pela WaSP.
Tem gente do Opera envolvido com eles, a cabeça deles trabalha para a Microsoft como consultora (Molly E. Holzschlag, blog dela aqui), mas nem por isso o teste foi desenvolvido por essa ou aquela empresa desenvolvedora de navegador.
A autoria é do The Web Standards Project.
Obrigado pelo esclarecimento.
Tá bom! Desisto! Todos os outros browsers falharam, o IE8 é o único browser que descobriu que a página acidtests.org é uma farsa!
Tu ainda nao entendeu, ne?
O IE8 é o unico q trata uma chamada cross-domain de uma maneira diferente, usando segurança mais rígida e chata.
e fazendo quote do dennes:
[vendo]Memória corsair 2x512 DDR2 667
g1.globo.com/tecnologia
Você que não entendeu mesmo, né?
Vou citar direto a fonte. Quem desenvolveu disse:
IE8 fails the copies of ACID2 due to the cross domain security checks IE performs for ActiveX controls. Since IE does not natively handle HTML content in the OBJECT tag, but rather uses IE’s rendering engine as an ActiveX to display this HTML content, the same cross domain security checks also apply.
O problema é da arquitetura do IE, que não trata nativamente OBJECT dentro do HTML. Ele na verdade chama o próprio motor de desenho, como um controle ActiveX dentro da página (saca aqueles programas de banco e antivírus que rodam direto do navegador? é assim que ele faz - não tem maior cara de gambiarra? :P ), e por isso acabou não passando.
Reforçando: é problema de arquitetura.
Traduzindo: Isso não quer dizer que quem interpreta corretamente o teste, tenha um navegador menos seguro, muito menos que o IE por ter bloqueado seja mais!
Você realmente acredita que há risco para segurança no código do acid2?
O autor também escreveu "We started with the most secure solution and are now looking into whether we can safely loosen this restriction in a future beta."
Isso quer dizer que não estamos seguros que isso represente um problema de segurança. :?
E também escreveu "It’s worth mentioning that although most sites allow navigation like http://webstandards.org (note: the no www) this is also considered a cross domain access as www.webstandards.org != webstandards.org. This will also cause us to fail the ACID2 test and render the picture that you see above. So please type www.webstandards.org!"
Isso quer dizer, se a página apareceu errada a culpa é sua por não digitar o endereço corretamente. :jawdrop:
Nahh.. significa que estão aplicando restrição onde não existe. Aliás, não tem nem cabimento falar em cross script, pois nenhuma das duas páginas tem sequer uma linha de código javascript (ou qualquer outra coisa que não seja HTML + CSS).
O IE simplesmente não interpreta como deveria...
Isso quer dizer, se a página apareceu errada a culpa é sua por não digitar o endereço corretamente. :jawdrop:
Aqui eu concordo contigo! ;)
Acho que concordamos também na primeira "tradução" o que acontece é que tentei ser ironico e você decidiu chutar a canela. }:)
Ubiratan,
Isso quer dizer que não estamos seguros que isso represente um problema de segurança.
Não, isso quer dizer exatamente o que está na frase : safely = de forma segura, ou seja reduzir a restrição quanto a renderização de forma segura.
Como assim reduzir ? Fazendo fallback, ora, o que todos estão pedindo.
Por que mesmo o fallback não foi visto pela MS como algo seguro ?
Se o desenvolvedor tivesse provocado aquele cross-site scripting propositalmente, ele identificaria o problema de segurança durante o desenvolvimento. Assim sendo a chance de que a presença daquela tag object ali seja originada por script injection é muito grande.
Em uma tag originada por script injection, mesmo o fallback é inesperado para o desenvolvedor e talvez até mesmo potencialmente perigoso.
Isso quer dizer, se a página apareceu errada a culpa é sua por não digitar o endereço corretamente.
Em uma versão beta 1 ... porém apesar do típico padrão de um site ser acessado com ou sem www, na verdade as possibilidades de DNS não garantem que seja o mesmo site... Imagino que deve ter bastante gente na MS quebrando a cabeça com isso no momento, mas é só suposição...
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Eles implementaram da forma mais segura de acordo com a arquitetura do motor de desenho, o que resultou em um comportamento errado por parte do navegador.
É exatamente isso que eles dizem, se você ler o texto inteiro.
O problema é que o IE foi reprovado nos testes, não por questões de segurança, mas por problemas de implementação. Não há questões de bloqueios de cross scripting, os desenvolvedores nem chegam a citar isso.
Eles já reconheceram que esse comportamento é errôneo, inesperado, não é assim que um navegador deve interpretar OBJECT, já falaram que isso será alterado na próxima versão, e você está querendo convencer que é uma questão de segurança do usuário?
Impressionante...
Mas aí o Dennes está com a razão, é uma questão de segurança mas somente para quem usa Windows, pois ActiveX só existe nessa plataforma! Acho que é melhor tornar o ActiveX mais seguro e parar de tentar por a culpa nos outros.
Caravana,
Eles implementaram da forma mais segura de acordo com a arquitetura do motor de desenho, o que resultou em um comportamento errado por parte do navegador.
Em momento algum foi dito que o comportamento é errado
Eles já reconheceram que esse comportamento é errôneo, inesperado, não é assim que um navegador deve interpretar OBJECT
IE stops the OBJECT fallback process at the highlighted line above. The team and I involved in this work decided that this is the right thing to do because IE would have to allow navigation to this cross domain content in order to determine if the failed resource is a 404 HTTP error code or any of the other failed resource indicators that are part of the standard. To maintain compatibility and be secure by default we didn’t want to invoke fallback either, as original web authors might not have intended this behavior.
Qual a parte de "this is the right thing to do" você não entendeu ?
Impressionante...
Quanto ao fallback, já expliquei em outro comentário por aqui que se a "tag cross-domain" está lá pode ter entrado por script injection e por isso o próprio fallback seria algo indesejado - "as original web authors might not have intended this behavior" - observe o "original"
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Não tire a frase do contexto. "this is the right thing to do" para o modo como funciona atualmente no Internet Explorer.
Definitivamente não é perigoso implementar OBJECT, afinal todo browser decente interpreta nativamente, e não precisa dar desculpas.
O que é perigoso, é implementar a interpretação via ActiveX sem restrição nenhuma. Isso é o "this is the right thing to do" que eles se referem, e que eles vão ter que contornar, pois se a interpretação for feita via ActiveX sem nenhuma segurança extra aí no meio, realmente abre um leque de possibilidades pra cross scripting e afins. O que não tem nada a ver com a tag OBJECT, tem a ver com o IE e ActiveX.
Se implementarem nativamente no navegador, não precisarão restringir da forma que fazem, e já que minha argumentação não conseguiu te convencer, leia o comentário do fcima, pra ver se você finalmente entende o que o texto em inglês quis dizer:
O que ocorre é a tag object é implementada por um activex. Esse activex não permite o carregamento de outro domínio.
Correto.
Isso é um bug (restrição desnecessária) do IE.
Sim é um bug. Não é uma restrição desnecessária, é uma consequência da implementação do recurso ser feita usando um controle ActiveX.
E (aposto meus tibs) será removida numa próxima versão beta.
A ver. Depende do esforço necessário para implementar este recurso "nativamente" sem ActiveX.
Abraços,
A explicação é bem simples de entender, vai... Não está nem em inglês..
Sugiro que leia alguns livros sobre segurança para descrobrir o que é script injection, como está relacionado ao cross-domain scripting e como pode ser perigoso para um site, independentemente do uso de ActiveX
Dennes
---------------------
CidadaoCarioca
BufaloInfo
E eu sugiro que você volte e leia a notícia direto do blog dos desenvolvedores do IE, pois só li sobre o bug universal XSS do Acid2 por aqui.
Vamos ver qual vai ser a justificativa do Dennes, a Microsoft podia contratar ele como porta-voz (falando serio, para falar em nome dela ele e' realmente bom, e ainda sabe de tudo que ta vindo nos proximos meses).
Agora, temos que torcer para a MS se esforcar, senao a Web vai continuar na mesma, um monte de site nem passando do seletor de linguas ou regiao pq deve usar alguma coisa que soh tem no IE.
fonte: http://www.tim.com.br/ (no firefox 2 que faz 52 no acid3, no mostra quase nada)
Eu pensei que ele trabalhava na MS.
Firefox 2.0.0.11 = 52/100
E o IE beta ainda no 17/100? Hehehe
Quero ver como vai ficar o SVG da MS...
OBS: Mozilla/5.0 (X11; U; Linux i686; pt-BR; rv:1.8.1.11) Gecko/20071221 Firefox/2.0.0.11
putz.... mas eu confio na m$ hehhehe
Meu Deus.
aHHNNnnnn
tá explicado!! valeu mesmo!
[vendo]Memória corsair 2x512 DDR2 667
g1.globo.com/tecnologia
Acid2 já é coisa do passado! O interessante agora é a corrida pelo acid3.
Acredito que o primeiro a ter pontuação máxima (e logo) será o webkit. O segundo lugar será disputado pelo opera e gecko (ainda esse ano?).
O IE é um mistério, já que muita coisa testada não está nem implementada (falta até o nosso velho conhecido addEventListener!).
Abaixo estão os bugs onde as equipes do webkit e gecko estão rastreando o que falta:
http://bugs.webkit.org/show_bug.cgi?id=17064
https://bugzilla.mozilla.org/show_bug.cgi?id=acid3
Oi, Wallacy!
Ta, mais ai não é um problema do webmaster que referenciou errado o arquivo do flash?
Não, estamos falando de script injection, o desenvolvedor web nem ao menos inseriu um arquivo do flash ali.
É claro que é um problema de programação não ter tratado as possíveis invasões de script injection, mas quando algo fica muito óbvio, como um cross-site scripting, o próprio browser pode barrar, é um favor que ele faz.
Mais até onde entendi, o problema do que você citou é justamente referenciar um conteúdo contendo scripts ou outros códigos maliciosos, esse conteúdo redirecionado é enviado a algum player de vídeo (por exemplo) ele não vai conseguir rodar esse código malicioso.
"código malicioso" quando se trata de segurança, é algo extremamente amplo. Nesse caso não se refere apenas a programação, as vezes o mais inocente dos plug-ins, quando recebe determinados parâmetros, pode gerar um resultado desagradável... só o fato de ter ali algo que veio de outro site já pode não ser legal (estamos falando de script injection, não foi o desenvolvedor que fez a referência).
No caso, outras plataformas não tem controles semelhantes ao do "activeX", pessoalmente não conheço nada similar para outras plataformas, geralmente é como eu falei, lê o mime e passa para o player responsável do sistema...
O que é exatamente a mesma coisa, o "player" pode ter sua parametrização explorada
e mesmo que continuasse o player não saberia interpretar códigos....
ActiveX também não. Além disso nem ao menos levantei a possibilidade de ser um mimetype diferente, apenas das parametrizações do player serem exploradas.
Até onde percebi dessa falha, é algo exclusivo ao Windows + IE
Não conforme estou descrevendo, a menos que os browsers protejam os players de alguma forma adicional.... mas como o firefox passa no acidtests, isso quer dizer que se fosse um flash pornô ia rodar, enquanto o IE 8 barraria.
pois é o único sistema que parece ter uma implementação nesse estilo
Não sei exatamente a qual estilo está se referindo, mas é algo diferente do que estou citando...
o grande lance é justamente o "activeX" que é capaz de interpretar códigos maliciosos
De forma alguma. ActiveX não "interpreta códigos maliciosos", isso seria lenda. ActiveX é um componente já instalado na máquina do usuário e cujas parametrizações podem ser exploradas, assim como um "player", que se não estiver instalado no client vai ser baixado e instalado.
[]'s
Dennes
---------------------
CidadaoCarioca
BufaloInfo
Bem, como eu disse eu não sei.. Qualquer coisa que eu fale a mais só vai ser especulação, mais certamente assim que der vou tentar ver como outras plataformas/browser se comporta com esses script injections. Só comentei aquilo pois já entrei tentei rodar alguns conteúdos similares e não rodaram simplesmente pela ausência de uma aplicação no estilo do activeX..
Em fim.. Se você disse, ta dito... Depois vou ler mais sobre esse asunto em particular.
-----
Para aquele que controla o próprio pensamento, todo o resto se torna simples jogo de crianças...
Gandhi.
Testei no firefox 3 beta 5 pre (sem gosto de fortes emoções) e passou tb no acid2.
[]'s
Jabá http://beernotfoundexception.blogspot.com/
Internet Explorer 5.5 vai melhor que o 6 e o 7 no Acid 3!!!
http://www.anomalousanomaly.com/2008/03/06/acid-3/
Esse site também mostra os outros navegadores, é bom para comparação.
KHTML ganhando? Ok... Foi até previsível essa hehe... Porém realmente achei interessante o IE 5.5 ter ganhado do 6 e 7.
-----
Para aquele que controla o próprio pensamento, todo o resto se torna simples jogo de crianças...
Gandhi.
O 5.5 tava muito nos padroes web para a MS, hehehe. O 6 e o 7 mostraram mesmo como a Web da MS deve ser.
Agora falando serio, o que sera que mudou tanto entre o 5.5 e ao 6/7 para diminuir o score do Acid3? Talvez mais Bugs de CSS... Ou mais seguranca, sempre essa é a desculpa. Ninguem mais sabe se o problema do teste do Acid2 é do IE/Windows/ActiveX ou um baita risco de seguranca que ninguem viu, soh a MS!!!
Deixando a mini-revolta de lado, vamos todos (torcer|rezar|blogar...) para desta vez com o IE 8 a coisa endireitar de vez. Eu quero ter a liberdade de usar o navegador que eu quiser no sistema que eu quiser sem ter navegabilidade de sites prejudicada!!!
Não se anime tanto.
Eu vejo todo mundo criticando os browsers por "não passarem no teste", mas, alguém chegou a ver o teste em sí ?
A parte do acid2 que dá pau no IE8 tem:
Uma tag Object, com enctype de um erro;
Dentro desta tag object, OUTRA tag object apontando para uma página inexistente;
Dentro desta segunda tag, uma tag object com um PNG dos olhos, mas codificado em base64;
O problema do cross side scripting é na tag do meio: O IE exibe um iframe de "not found", caso a chamada seja de outro domínio.
De boa... quem é que vai usar tais recursos num site de verdade ?
Estes testes hipotéticos parecem-se muito com aqueles benchmarks sintéticos pra jogos, que apontam placa de fulano melhor que a de sicrano, e, quando vai-se jogar mesmo pra valer, a situação não é nada igual a do teste.
Até onde eu sei, o teste serve para testar os padrões ou recomendações que deverão funcionar em qualquer navegador.
Agora se vai ser útil ou não, será que já foi discutido na W3C? Quando eu tiver tempo eu vou ler sobre essas recomendações e entender o porque do IE ter problemas com essa TAG OBJECT.
Sim, serve.
Agora, não entendo porque ninguém se questiona o motivo de, por padrão, um navegador ser obrigado a fazer funcionar algo como três tags object 'sanduichadas', sendo duas delas com erros propositais e a restante com um PNG criado via base64.
NINGUÉM vai usar isso em um site, JAMAIS.
Não alongarei a discussão técnica aqui, porém, há certos 'padrões' que a w3c propõe que só atrapalham a vida de quem desenvolve.
Voce tem um bom ponto, e ja ta bem tecnico e eu nao manjo quase nada de HTML/CSS e OBJECTs em geral.
[]s