From 95aca4b4d8fa62815d4bd412fff1a364f842814a Mon Sep 17 00:00:00 2001 From: Ryan Johnson Date: Thu, 29 Apr 2021 16:16:42 -0700 Subject: remove retired locales (#699) --- files/pt-pt/web/security/index.html | 17 -- .../web/security/insecure_passwords/index.html | 158 ------------ .../index.html | 31 --- files/pt-pt/web/security/mixed_content/index.html | 81 ------- .../web/security/same-origin_policy/index.html | 264 --------------------- .../pt-pt/web/security/secure_contexts/index.html | 202 ---------------- 6 files changed, 753 deletions(-) delete mode 100644 files/pt-pt/web/security/index.html delete mode 100644 files/pt-pt/web/security/insecure_passwords/index.html delete mode 100644 files/pt-pt/web/security/mixed_content/how_to_fix_website_with_mixed_content/index.html delete mode 100644 files/pt-pt/web/security/mixed_content/index.html delete mode 100644 files/pt-pt/web/security/same-origin_policy/index.html delete mode 100644 files/pt-pt/web/security/secure_contexts/index.html (limited to 'files/pt-pt/web/security') diff --git a/files/pt-pt/web/security/index.html b/files/pt-pt/web/security/index.html deleted file mode 100644 index e3af6fd55a..0000000000 --- a/files/pt-pt/web/security/index.html +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Segurança da Web -slug: Web/Security -tags: - - Landing - - Segurança - - Web -translation_of: Web/Security -original_slug: Web/Seguranca ---- -
-

É crítico assegurar que o seu site da Web ou aplicação da Web aberta é segura. Até erros simples no seu código podem resultar na divulgação de informação privada, e as pessoas más estão por aí a tentar encontrar meios para roubar dados. Estes articgos proporcionam informação que poderá ajudá-lo a proteger o seu código code.

-
- -

{{LandingPageListSubpages}}

- -

{{QuickLinksWithSubpages}}

diff --git a/files/pt-pt/web/security/insecure_passwords/index.html b/files/pt-pt/web/security/insecure_passwords/index.html deleted file mode 100644 index 31344bf0ac..0000000000 --- a/files/pt-pt/web/security/insecure_passwords/index.html +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: Palavras-passe inseguras -slug: Web/Security/Insecure_passwords -tags: - - Insegura - - Intermediária - - Segurança - - Web - - palavra-passe - - palavras-passe -translation_of: Web/Security/Insecure_passwords -original_slug: Web/Seguranca/Palavras-passe_inseguras ---- -

Apresentar formulários de sessão usando protocolo HTTP é especialmente perigoso por causa da grande variedade de ataques que podem ser utilizados ​​contra os mesmos para extrair a palavra-passe de um utilizador. As escutas ocultas de rede podem roubar a palavra-passe de um utilizador ao "farejar" a rede ou modificar a página servida no tráfego. Esta página detalha os mecanismos de segurança que o Firefox criou para alertar os utilizadores e programadores dos riscos que envolvem as palavras-passe inseguras e o roubo da mesma.

- -

O protocolo HTTPS foi desenhado para proteger os dados dos utilizadores de escutas (confidencialidade) e modificação (integridade) na rede. As páginas que lidam com dados de utilizador, deveriam idealmente usar HTTPS para proteger os utilizadores de ataques. Caso uma página use HTTP em vez de HTTPS, roubar informação acerca do utilizador (como os dados de autenticação) é um processo trivial. Esta técnica ficou famosamente demonstrada por Firesheep.

- -

Para resolver este problema, é necessário instalar e configurar um certificado SSL/TLS no servidor onde está alojada a página. Existem vários emissores deste tipo de certificados sendo que uns são grátis e outros pagos. Se está a usar uma plataforma cloud, é possível que a mesma tenha as suas próprias maneiras de ativar o protocolo HTTPS.

- -

Indicadores de segurança de palavra-passe do Firefox

- -

Para o informar do perigo descrito acima, o Firefox implementa vários mecanismos de aviso:

- -
    -
  1. -

    Firefox 51+ mostrará o símbolo de um cadeado com um traço vermelho na barra de endereços sempre que uma página de autenticação não tenha uma ligação segura, como demonstrado abaixo.

    - -

    Lock Icon

    -
    2. -
  2. -

    Firefox 52+ mostrará um aviso claro na barra de endereço e mais abaixo, focará o campo de introdução da password em qualquer formulário inseguro:

    - -

    Warning

    -
    3. -
  3. -

    Firefox 52+ também desabilita o preenchimento automático em formulários inseguros. No entanto, a partir da caixa de seleção, os utilizadores continuam a poder utilizar o preenchimento automático caso tenham os seus dados de autenticação gravados.

    -
    4. -
  4. -

    Avisos acerca de formulários inseguros também podem ser encontrados no separador "Segurança" da consola de programador em todas as versões distribuídas de Firefox, como demonstrado na próxima secção.

    -
    5. -
- -

Mensagens da Consola da Web

- -

Esta secção descreve as mensagens de segurança mostradas pela consola de programador das Firefox DevTools (ferramentas de desenvolvimento), acerca de passwords inseguras.

- -

Apresentando o formulário de sessão usando protocolo HTTP

- -

Mesmo que a acção do formulário seja um endereço HTTPS, a informação introduzida no formulário pelo utilizador não está protegida porque um possível atacante pode modificar a própria página que o utilizador consulta (por exemplo, os atacantes podem mudar o destino do formulário de forma a que os dados sensíveis sejam enviados para um servidor por eles controlados, ou inserir um script de leitura de teclas que desenha a password enquanto o utilizador a escreve). O separador de segurança da consola de programador web avisará os programadores e utilizadores acerca desta preocupação de segurança:

- -

Insecure login form shown with the Web Console and contextual warning on the password field.

- -
-

Nota: Também não é seguro incluir uma página de autenticação recorrendo a HTTPS numa página HTTP - um atacante pode alterar a frame e respetivo endereço para apontar para um outro endereço, possivelmente malicioso.

-
- -

Utilizar um URL HTTP na acção do formulário

- -

Neste caso, quaisquer dados que o utilizador introduza é enviado pela rede como sendo apenas texto básico. A password do utilizador é claramente visível para qualquer pessoa que "fareje" a rede desde o momento em que deixa o computador do utilizador até ao momento em que chega ao servidor onde se encontra alojado o website de destino.

- -

Insecure login form action shown with the Web Console and contextual warning on the password field.

- -

Nota sobre a reutilização de palavra-passe

- -

Por vezes, as páginas requerem nomes de utilizador e palavras-passe, mas não guardam dados que sejam particularmente sensíveis. Por exemplo, uma página de notícias pode gravar quais os anúncios que um utilizador queira voltar a rever e ler, sem guardar quaisquer dados acerca deste utilizador. Os programadores web deste tipo de páginas poderão estar menos preocupados a promover a segurança desta página e dos dados dos seus utilizadores.

- -

Infelizmente, a reutilização de palavras-passe é um grande problema. Os utilizadores tendem a utilizar a mesma palavra-passe para aceder a múltiplas páginas (seja de notícias, redes sociais, serviços de email, bancos, etc.). Por essa razão, mesmo que o acesso ao utilizador e palavra-passe do seu site não lhe pareça um enorme risco, é um grande risco para utilizadores que usem esse mesmo nome de utilizador e palavra-passe para aceder, por exemplo, às suas contas bancárias. Os atacantes estão a tornar-se cada vez mais espertos; roubam pares de nomes de utilizador/palavra-passe de um site, e tentam reusá-los em sites mais lucrativos.

- -

Consulte também

- - - -

{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}

- -
- - - - - -
diff --git a/files/pt-pt/web/security/mixed_content/how_to_fix_website_with_mixed_content/index.html b/files/pt-pt/web/security/mixed_content/how_to_fix_website_with_mixed_content/index.html deleted file mode 100644 index e5694cc79a..0000000000 --- a/files/pt-pt/web/security/mixed_content/how_to_fix_website_with_mixed_content/index.html +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Como corrigir um site da Web com conteúdo misto bloqueado -slug: Web/Security/Mixed_content/How_to_fix_website_with_mixed_content -tags: - - HTTPS - - Segurança -translation_of: Web/Security/Mixed_content/How_to_fix_website_with_mixed_content -original_slug: >- - Web/Security/Mixed_content/Como_corrigir_um_site_da_Web_com_conteudo_misto_bloqueado ---- -

A partir do Firefox 23, o Firefox bloqueia o conteúdo misto ativo por predefinição. Isto segue uma prática adotada pelo Internet Explorer (A partir da versão 9) e Chrome.

- -

Esta página explica a que deverá prestar atenção, como um programador da Web.

- -

O seu site da Web poderá crachar

- -

If your website delivers HTTPS pages, all active mixed content delivered via HTTP on this pages will be blocked by default. Consequently, your website may appear broken to users (if iframes or plugins don't load, etc.). Passive mixed content is displayed by default, but users can set a preference to block this type of content, as well.

- -

Note that since mixed content blocking already happens in Chrome and Internet Explorer, it is very likely that if your website works in both of these browsers, it will work equally well in Firefox with mixed content blocking.

- -

In any case, the best way to know if something is broken in Firefox is to download the latest Firefox Edition, open different pages on your website with the web console open (enable the "Security" messages) and see if anything related to mixed content is reported. Or use an online crawler like SSL-check, a desktop crawler like HTTPSChecker that will check your website recursively and find links to insecure content, or a CLI tool like mcdetect. If nothing is said about mixed content, your website is in good shape: Keep making excellent websites!

- -

Como corrigir um site da Web

- -

The best strategy to avoid mixed content blocking is to serve all the content as HTTPS instead of HTTP.

- -

Para o seu próprio domínio, serve all content as HTTPS and fix your links.  Often, the HTTPS version of the content already exists and this just requires adding an "s" to links - http:// to https://.

- -

However, in some cases, the path may just be incorrect to the media in question. There are online as well as offline tools (depending on your operating system) such as linkchecker to help resolve this.

- -

Para outros domínios, use the site's HTTPS version if available. If HTTPS is not available, you can try contacting the domain and asking them if they can make the content available via HTTPS.

diff --git a/files/pt-pt/web/security/mixed_content/index.html b/files/pt-pt/web/security/mixed_content/index.html deleted file mode 100644 index 07b4bcd3f9..0000000000 --- a/files/pt-pt/web/security/mixed_content/index.html +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: Conteúdo misto -slug: Web/Security/Mixed_content -tags: - - Consola - - HTTP - - HTTPS - - Segurança - - Web -translation_of: Web/Security/Mixed_content -original_slug: Web/Security/Conteudo_misto ---- -

Quando um utilizador visita uma página servida sobre {{Glossary("HTTPS")}}, a sua ligação com o servidor da Web é encriptada com {{Glossary("TLS")}} e é, portanto, salvaguardada da maioria dos sniffers e ataques man-in-the-middle. Uma página HTTPS que inclui conteúdo obtido utilizando texto simples HTTP é chamada de de página de conteúdo misto. As páginas como esta são apenas parcialmente encriptadas, deixando o conteúdo não encriptado acessível aos sniffers e atacantes man-in-the-middle. Isso deixa as páginas inseguras.

- -

Tipos de conteúdo misto

- -

There are two categories for mixed content: mixed passive/display content and mixed active content. The difference lies in the threat level of the worst case scenario if content is rewritten as part of a man-in-the-middle attack. In the case of passive content, the threat is lower (the page may contain misleading content, or the user's cookies may be stolen). In the case of active content, the threat can lead to phishing, sensitive data disclosure, redirection to malicious sites, etc.

- -

Conteúdo misto passivo/de exibição

- -

Mixed passive/display content is content served over HTTP that is included in an HTTPS webpage, but that cannot alter other portions of the webpage. For example, an attacker could replace an image served over HTTP with an inappropriate image or message to the user. The attacker could also infer information about the user's activities by watching which images are served to the user; often images are only served on a specific page within a website. If the attacker observes HTTP requests to certain images, they could determine which webpage the user is visiting.

- -

Lista de conteúdo passivo

- -

This section lists all types of HTTP requests which are considered passive content:

- - - -

Conteúdo ativo misto

- -

Mixed active content is content that has access to all or parts of the Document Object Model of the HTTPS page. This type of mixed content can alter the behavior of the HTTPS page and potentially steal sensitive data from the user. Hence, in addition to the risks described for mixed display content above, mixed active content is vulnerable to a few other attack vectors.

- -

In the mixed active content case, a man-in-the-middle attacker can intercept the request for the HTTP content. The attacker can also rewrite the response to include malicious JavaScript code. Malicious active content can steal the user's credentials, acquire sensitive data about the user, or attempt to install malware on the user's system (by leveraging vulnerabilities in the browser or its plugins, for example).

- -

The risk involved with mixed content does depend on the type of website the user is visiting and how sensitive the data exposed to that site may be. The webpage may have public data visible to the world or private data visible only when authenticated. If the webpage is public and has no sensitive data about the user, using mixed active content still provides the attacker with the opportunity to redirect the user to other HTTP pages and steal HTTP cookies from those sites.

- -

Exemplos de conteúdo ativo

- -

This section lists some types of HTTP requests which are considered active content:

- - - -

Other resource types like web fonts and workers may be considered active mixed content, as they are in Chromium.

- -

Avisos na Consola da Web

- -

The Firefox Web Console displays a mixed content warning message in the Net pane when a page on your website has this issue. The mixed content resource that was loaded via HTTP will show up in red, along with the text "mixed content", which links to this page.

- -

Screen shot of the web console displaying a mixed content warning.

- -

As well as finding these warnings in the Web Console, you could use Content Security Policy (CSP) to report issues or a website crawler to find issues across your site, such as HTTPS Checker or Mixed Content Scan.

- -

Starting in Firefox 23, mixed active content is blocked by default (and mixed display content can be blocked by setting a preference). To make it easier for web developers to find mixed content errors, all blocked mixed content requests are logged to the Security pane of the Web Console, as seen below:

- -

A screenshot of blocked mixed content errors in the Security Pane of the Web Console

- -

To fix this type of error, all requests to HTTP content should be removed and replaced with content served over HTTPS. Some common examples of mixed content include JavaScript files, stylesheets, images, videos, and other media.

- -
-

Nota: a partir do Firefox 55, o carregamento de conteúdo misto é permitido em http://127.0.0.1/ (see {{bug(903966)}}).  O Chrome permite conteúdo misto em http://127.0.0.1/ e http://localhost/. O Safari não permite conteúdo misto.

-
- -

Consultar também

- - diff --git a/files/pt-pt/web/security/same-origin_policy/index.html b/files/pt-pt/web/security/same-origin_policy/index.html deleted file mode 100644 index a96af69ecb..0000000000 --- a/files/pt-pt/web/security/same-origin_policy/index.html +++ /dev/null @@ -1,264 +0,0 @@ ---- -title: Same-origin policy -slug: Web/Security/Same-origin_policy -translation_of: Web/Security/Same-origin_policy -original_slug: Web/Seguranca/Same-origin_policy ---- -
{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}
- -

The same-origin policy is a critical security mechanism that restricts how a document or script loaded from one {{Glossary("origin")}} can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors.

- -

Definição de uma Origem

- -

Duas URL tem a  mesma origem se o {{Glossary("protocol")}}, {{Glossary("port")}} (if specified), and {{Glossary("host")}} are the same for both. You may see this referenced as the "scheme/host/port tuple", or just "tuple". (A "tuple" is a set of items that together comprise a whole — a generic form for double/triple/quadruple/quintuple/etc.)

- -

The following table gives examples of origin comparisons with the URL http://store.company.com/dir/page.html:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
URLOutcomeReason
http://store.company.com/dir2/other.htmlSame originOnly the path differs
http://store.company.com/dir/inner/another.htmlSame originOnly the path differs
https://store.company.com/page.htmlFailureDifferent protocol
http://store.company.com:81/dir/page.htmlFailureDifferent port (http:// is port 80 by default)
http://news.company.com/dir/page.htmlFailureDifferent host
- -

Inherited origins

- -

Scripts executed from pages with an about:blank or javascript: URL inherit the origin of the document containing that URL, since these types of URLs do not contain information about an origin server.

- -
-

For example, about:blank is often used as a URL of new, empty popup windows into which the parent script writes content (e.g. via the {{domxref("Window.open()")}} mechanism). If this popup also contains JavaScript, that script would inherit the same origin as the script that created it.

-
- -
-

data: URLs get a new, empty, security context.

-
- -

Exceptions in Internet Explorer

- -

Internet Explorer has two major exceptions to the same-origin policy:

- -
-
Trust Zones
-
If both domains are in the highly trusted zone (e.g. corporate intranet domains), then the same-origin limitations are not applied.
-
Port
-
IE doesn't include port into same-origin checks. Therefore, https://company.com:81/index.html and https://company.com/index.html are considered the same origin and no restrictions are applied.
-
- -

These exceptions are nonstandard and unsupported in any other browser.

- -

Changing origin

- -

A page may change its own origin, with some limitations. A script can set the value of {{domxref("document.domain")}} to its current domain or a superdomain of its current domain. If set to a superdomain of the current domain, the shorter superdomain is used for same-origin checks.

- -

For example, assume a script from the document at http://store.company.com/dir/other.html executes the following:

- -
document.domain = "company.com";
-
- -

Afterward, the page can pass the same-origin check with http://company.com/dir/page.html (assuming http://company.com/dir/page.html sets its document.domain to "company.com" to indicate that it wishes to allow that - see {{domxref("document.domain")}} for more). However, company.com could not set document.domain to othercompany.com, since that is not a superdomain of company.com.

- -

The port number is checked separately by the browser. Any call to document.domain, including document.domain = document.domain, causes the port number to be overwritten with null. Therefore, one cannot make company.com:8080 talk to company.com by only setting document.domain = "company.com" in the first. It has to be set in both so their port numbers are both null.

- -
-

Note: When using document.domain to allow a subdomain to access its parent securely, you need to set document.domain to the same value in both the parent domain and the subdomain. This is necessary even if doing so is simply setting the parent domain back to its original value. Failure to do this may result in permission errors.

-
- -

Cross-origin network access

- -

The same-origin policy controls interactions between two different origins, such as when you use {{domxref("XMLHttpRequest")}} or an {{htmlelement("img")}} element. These interactions are typically placed into three categories:

- - - -

Here are some examples of resources which may be embedded cross-origin:

- - - -

How to allow cross-origin access

- -

Use CORS to allow cross-origin access. CORS is a part of {{Glossary("HTTP")}} that lets servers specify what hosts are permitted to load content from that server.

- -

How to block cross-origin access

- - - -

Cross-origin script API access

- -

JavaScript APIs like {{domxref("HTMLIFrameElement.contentWindow", "iframe.contentWindow")}}, {{domxref("window.parent")}}, {{domxref("window.open")}}, and {{domxref("window.opener")}} allow documents to directly reference each other. When two documents do not have the same origin, these references provide very limited access to {{domxref("Window")}} and {{domxref("Location")}} objects, as described in the next two sections.

- -

To communicate between documents from different origins, use {{domxref("window.postMessage")}}.

- -

Specification: HTML Living Standard § Cross-origin objects.

- -

Window

- -

The following cross-origin access to these Window properties is allowed:

- - - - - - - - - - - - - - - - - - - - - -
Methods
{{domxref("window.blur")}}
{{domxref("window.close")}}
{{domxref("window.focus")}}
{{domxref("window.postMessage")}}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Attributes
{{domxref("window.closed")}}Read only.
{{domxref("window.frames")}}Read only.
{{domxref("window.length")}}Read only.
{{domxref("window.location")}}Read/Write.
{{domxref("window.opener")}}Read only.
{{domxref("window.parent")}}Read only.
{{domxref("window.self")}}Read only.
{{domxref("window.top")}}Read only.
{{domxref("window.window")}}Read only.
- -

Some browsers allow access to more properties than the above.

- -

Location

- -

The following cross-origin access to Location properties is allowed:

- - - - - - - - - - - - -
Methods
{{domxref("location.replace")}}
- - - - - - - - - - - - - - -
Attributes
{{domxref("URLUtils.href")}}Write-only.
- -

Some browsers allow access to more properties than the above.

- -

Cross-origin data storage access

- -

Access to data stored in the browser such as Web Storage and IndexedDB are separated by origin. Each origin gets its own separate storage, and JavaScript in one origin cannot read from or write to the storage belonging to another origin.

- -

{{glossary("Cookie", "Cookies")}} use a separate definition of origins. A page can set a cookie for its own domain or any parent domain, as long as the parent domain is not a public suffix. Firefox and Chrome use the Public Suffix List to determine if a domain is a public suffix. Internet Explorer uses its own internal method to determine if a domain is a public suffix. The browser will make a cookie available to the given domain including any sub-domains, no matter which protocol (HTTP/HTTPS) or port is used. When you set a cookie, you can limit its availability using the Domain, Path, Secure, and HttpOnly flags. When you read a cookie, you cannot see from where it was set. Even if you use only secure https connections, any cookie you see may have been set using an insecure connection.

- -

See also

- - - -
-

Original Document Information

- - -
diff --git a/files/pt-pt/web/security/secure_contexts/index.html b/files/pt-pt/web/security/secure_contexts/index.html deleted file mode 100644 index 23ad21540d..0000000000 --- a/files/pt-pt/web/security/secure_contexts/index.html +++ /dev/null @@ -1,202 +0,0 @@ ---- -title: Contextos seguros -slug: Web/Security/Secure_Contexts -tags: - - Contextos seguros - - Segurança -translation_of: Web/Security/Secure_Contexts ---- -

Um contexto de segurança é uma Window ou Worker para o qual há confiança razoável de que o conteúdo foi entregue com segurança (via HTTPS/TLS), e para o qual o potencial para a comunicação com contextos que não são seguros é limitado. Muitas APIs da Web e funcionalidades só são acessíveis num contexto seguro. O principal objetivo de contextos seguros é prevenir {{interwiki("wikipedia", "man-in-the-middle attack", "man-in-the-middle attackers")}} de aceder as APis poderosas que poderiam comprometer ainda mais a vítima de um ataque .

- -

Porque é que algumas funcionalidades deveriam ser restritas? 

- -

Algumas APIs na Web são muito poderosas, dando a um atacante a capacidade para fazer o seguinte e muito mais:

- - - -

Quando é que um contexto é considerado seguro?

- -

Um contexto será considerado seguro quando este for entregue com segurança (ou localmente), e quando ele não pode ser utilizado para fornecer acesso às APIs seguras para um contexto que não é seguro. Na prática, isto significa que, para que uma página tenha um contexto seguro, esta e todas as páginas a par dos seus originais e o abridor da cadeia devem ter sido entregues de uma forma segura .

- -

Por exemplo, uma página entregue de forma segura em TLS não é considerada um contexto seguro se tiver um documento original ou antigo que não tenha sido entregue de forma segura, pois, de outra forma, a página poderá expor APIs sensíveis para um antigo não entregue de forma segura via mensagens postMessage. Da mesma forma, se um documento TLS entregue for aberto numa nova janela por um contexto inseguro sem ser especificado noopener, depois a janela aberta não é considerada um contexto seguro (uma vez que o abridor e a janela aberta poderão comunicar via PostMessage). .

- -

Os ficheiros entregues localmente, tais como os caminhos http://localhost e ficheiro:// são considerados como sendo entregues de forma segura.

- -

Os contextos que não são locais devem ser servidos sobre https:// ou wss:// e onde os protocolos utilizados não deverão ser considerados obsoletos. 

- -

Deteção de funcionalidade

- -

As páginas podem utilizar a deteção de funcionalidade para verificar se elas estão num contexto seguro ou não, utilizando o booleano {{domxref("WindowOrWorkerGlobalScope.isSecureContext", "isSecureContext")}}, que é exposto num âmbito global.

- -
if (window.isSecureContext) {
-  // Page is a secure context so service workers are now available
-  navigator.serviceWorker.register("/offline-worker.js").then(function () {
-    ...
-  });
-}
- -

Especificações

- - - - - - - - - - - - - - -
EspecificaçãoEstadoComentário
{{SpecName('Contextos seguros')}}{{Spec2('Contextos seguros')}}Editor’s Draft
- -

Compatibilidade de navegador

- -

{{CompatibilityTable}}

- -
- - - - - - - - - - - - - - - - - - - - - -
FuncionalidadeChromeFirefox (Gecko)Internet ExplorerMicrosoft EdgeOperaSafari (WebKit)
Suporte básico{{CompatVersionUnknown}}[1]{{CompatVersionUnknown}}{{CompatNo}}{{CompatUnknown}}{{CompatVersionUnknown}}[1]{{CompatVersionUnknown}}[1]
-
- -
- - - - - - - - - - - - - - - - - - - - - - - -
FuncionalidadeAndroidAndroid WebviewFirefox Mobile (Gecko)IE PhoneOpera MobileSafari MobileChrome for Android
Suporte básico{{CompatNo}}{{CompatVersionUnknown}}[1]{{CompatVersionUnknown}}{{CompatNo}}{{CompatVersionUnknown}}[1]{{CompatVersionUnknown}}[1]{{CompatVersionUnknown}}[1]
-
- -

[1] A implementação ainda não está completa.

- -

Consulte também

- - - -
- - - - -
-
-
 
- -
-
G
- -
M
- -
T
-
- -
-
 
- -
 
-
- -
- - - - - - - - - - - - -
-
 
- 		-
 
- 		-
 
- 		-
 
- -
 
- 		-
 
- 		-
 
-
-
-
- -
 
- -
 
- -
 
- -
A função de fala é limitada a 200 caracteres
- -
-
 
- - - - - - - - -
-
 
- 		Opções : Histórico : Comentários : DonateEncerrar
-
-
-
-- cgit v1.2.3-54-g00ecf