aboutsummaryrefslogtreecommitdiff
path: root/files/pt-br/archive/b2g_os/security
diff options
context:
space:
mode:
authorPeter Bengtsson <mail@peterbe.com>2020-12-08 14:42:52 -0500
committerPeter Bengtsson <mail@peterbe.com>2020-12-08 14:42:52 -0500
commit074785cea106179cb3305637055ab0a009ca74f2 (patch)
treee6ae371cccd642aa2b67f39752a2cdf1fd4eb040 /files/pt-br/archive/b2g_os/security
parentda78a9e329e272dedb2400b79a3bdeebff387d47 (diff)
downloadtranslated-content-074785cea106179cb3305637055ab0a009ca74f2.tar.gz
translated-content-074785cea106179cb3305637055ab0a009ca74f2.tar.bz2
translated-content-074785cea106179cb3305637055ab0a009ca74f2.zip
initial commit
Diffstat (limited to 'files/pt-br/archive/b2g_os/security')
-rw-r--r--files/pt-br/archive/b2g_os/security/index.html67
-rw-r--r--files/pt-br/archive/b2g_os/security/installing_and_updating_applications/index.html94
-rw-r--r--files/pt-br/archive/b2g_os/security/modelo_de_seguranca/index.html275
-rw-r--r--files/pt-br/archive/b2g_os/security/seguranca_de_aplicacao/index.html138
4 files changed, 574 insertions, 0 deletions
diff --git a/files/pt-br/archive/b2g_os/security/index.html b/files/pt-br/archive/b2g_os/security/index.html
new file mode 100644
index 0000000000..381696bef1
--- /dev/null
+++ b/files/pt-br/archive/b2g_os/security/index.html
@@ -0,0 +1,67 @@
+---
+title: Segurança
+slug: Archive/B2G_OS/Security
+tags:
+ - B2G
+ - Firefox OS
+ - Mobile
+ - Security
+translation_of: Archive/B2G_OS/Security
+---
+<p>Os artigos a seguir cobrem tópicos relacionados com a segurança do Firefox OS. Isso inclui todos os recursos de segurança, bem como segurança da aplicação e como o processo de instalação é seguro.</p>
+<table class="topicpage-table">
+ <tbody>
+ <tr>
+ <td>
+ <h2 class="Documentation" id="Documentation" name="Documentation">Documentação sobre a segurança do Firefox OS</h2>
+ <dl>
+ <dt>
+ <a href="/pt-BR/docs/Mozilla/Firefox_OS/Security/Security_model" title="/en-US/docs/Mozilla/Firefox_OS/Security/Security_model">O modelo de segurança do Firefox OS</a></dt>
+ <dd>
+ Uma visão geral sobre o modelo de segurança do Firefox OS.</dd>
+ <dt>
+ <a href="/en-US/docs/Mozilla/Firefox_OS/Security/System_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Security_model">Segurança do sistema</a></dt>
+ <dd>
+ Detalha os controles de segurança criados no ambiente de execução do Firefox OS.</dd>
+ <dt>
+ <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security">Segurança das aplicações no Firefox OS</a></dt>
+ <dd>
+ Uma visão geral de como as aplicações são seguras no Firefox OS.</dd>
+ <dt>
+ <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Installing_and_updating_applications" title="/en-US/docs/Mozilla/Firefox_OS/Security/Installing_and_updating_applications">Segurança para instalar e atualizar aplicações</a></dt>
+ <dd>
+ Como funciona a segurança do Firefox OS para instalar e atualizar aplicações.</dd>
+ <dt>
+ <a href="/en-US/docs/Mozilla/Firefox_OS/Security/Software_permissions" title="/en-US/docs/Mozilla/Firefox_OS/Security/Software_permissions">Permissões de software no Firefox OS</a></dt>
+ <dd>
+ Um guia para saber que tipo de software tem permissão para executar várias tarefas no Firefox OS.</dd>
+ <dt>
+ <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Debugging_and_Security_Testing_with_Firefox_OS" title="https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Debugging_and_Security_Testing_with_Firefox_OS"><span style="display: none;"> </span>Depurando e testando a segurança com o Firefox OS</a></dt>
+ <dd>
+ Esse guia mostra os passos básicos de teste de segurança, abrindo um depurador remoto de JavaScript para configuração de um proxy de interceptação HTTP(S) através de uma versão desktop do Firefox OS.</dd>
+ </dl>
+ <p><span class="alllinks"><a href="/en-US/docs/tag/B2G" title="/en-US/docs/tag/B2G">Veja mais...</a></span></p>
+ </td>
+ <td>
+ <h2 class="Community" id="Community" name="Community"><span style="line-height: 1;">OBTENDO AJUDA DA COMUNIDADE</span></h2>
+ <p><span style="line-height: 21px;">Se você está trabalhando com Firefox OS, ou desenvolvendo aplicações que gostaria de rodar em dispositivos com Firefox OS, aqui estão alguns recursos da comunidade para te ajudar!</span></p>
+ <ul>
+ <li>Consultar o fórum do projeto Boot to Gecko: {{ DiscussionList("dev-b2g", "mozilla.dev.b2g") }}</li>
+ </ul>
+ <ul>
+ <li>Faça sua pergunta no canal IRC da Mozilla - Boot to Gecko: <a class="link-irc" href="irc://irc.mozilla.org/b2g" title="irc://irc.mozilla.org/b2g">#b2g</a></li>
+ </ul>
+ <p><span class="alllinks"><a class="external" href="http://www.catb.org/~esr/faqs/smart-questions.html" title="http://www.catb.org/~esr/faqs/smart-questions.html">Não esqueça do uso da <em>netiqueta</em>...</a></span></p>
+ <br>
+ <h2 class="Related_Topics" id="Related_Topics" name="Related_Topics"><span style="line-height: 1;">TÓPICOS RELACIONADOS</span></h2>
+ <ul>
+ <li><a href="/pt-BR/docs/Mobile" title="en-US/docs/Mobile">Móvel (mobile)</a></li>
+ <li><a href="/pt-BR/docs/Security" title="/en-US/docs/Security">Segurança</a></li>
+ </ul>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p> </p>
+<div id="cke_pastebin" style="position: absolute; top: 483px; width: 1px; height: 1px; overflow: hidden; left: -1000px;">
+  </div>
diff --git a/files/pt-br/archive/b2g_os/security/installing_and_updating_applications/index.html b/files/pt-br/archive/b2g_os/security/installing_and_updating_applications/index.html
new file mode 100644
index 0000000000..7c1102d699
--- /dev/null
+++ b/files/pt-br/archive/b2g_os/security/installing_and_updating_applications/index.html
@@ -0,0 +1,94 @@
+---
+title: Instalando e atualizando aplicativos
+slug: Archive/B2G_OS/Security/Installing_and_updating_applications
+tags:
+ - Apps
+ - Atualização
+ - B2G
+ - Experiência do usuário
+ - Firefox OS
+ - Guía
+ - Instalação
+ - Princípios de design
+ - UX
+ - User experience
+translation_of: Archive/B2G_OS/Security/Installing_and_updating_applications
+---
+<div class="summary">
+<p>Este artigo serve como um guia para o processo de atualização do aplicativo no Firefox OS.</p>
+</div>
+
+<h2 id="Visão_Geral_da_Implementação">Visão Geral da Implementação</h2>
+
+<h3 id="Categorias_de_App">Categorias de App</h3>
+
+<p>Existem três categorias básicas de aplicativos que são atualizadas utilizando esse mecanismo:</p>
+
+<dl>
+ <dt>Aplicativos principais</dt>
+ <dd>Os aplicativos básicos (aqueles que são enviados como parte da base do Firefox OS, como o Dialer) são empacotados, certificados, pré-instalados, e não removíveis. Estes só são atualizados durante uma atualização completa do sistema ou uma atualização dos níveis Gonk e Gaia.</dd>
+ <dt>Aplicativos instalados pelo usuário</dt>
+ <dd>Os aplicativos instalados pelo usuário são <span style="line-height: 19.0909080505371px;">hospedados ou </span>empacotados. A política de atualização deles é o tema principal deste artigo.</dd>
+ <dt>Aplicativos pré-instalados de terceiros</dt>
+ <dd>Aplicativos que são pré-instalados pelo transportador ou pelo fornecedor, mas não fazem parte da plataforma de núcleo do sistema operacional, são atualizados e estão sujeitos às mesmas regras e diretrizes dos aplicativos instalados pelo usuário.</dd>
+</dl>
+
+<h3 id="Suposições_sobre_os_usuários">Suposições sobre os usuários</h3>
+
+<p>Para pelo menos as versões iniciais do Firefox OS, as seguintes suposições são feitas sobre os usuários:</p>
+
+<ul>
+ <li>A transferência de dados é lenta, cara, e intencionalmente restrita; em outras palavras, assumimos que o usuário tenha uma conexão de dados lenta e uma quantidade limitada de tráfego permitida mensalmente.</li>
+ <li>Assumimos que o usuário tenha pouco ou nenhum acesso ao WiFi; a maioria das atualizações será realizada utilizando sua conexão de dados do celular.</li>
+ <li>Os dispositivos estão raramente em roaming.</li>
+ <li>Usuários mantêm seu serviço de dados desativado por padrão, permitindo-o apenas a concluir determinadas transações.</li>
+ <li><span class="short_text" id="result_box" lang="pt"><span class="hps">Usuários</span> possuem<span class="hps"> e usam</span> <span class="hps">múltiplos</span> <span class="hps">cartões SIM.</span></span></li>
+</ul>
+
+<p><span id="result_box" lang="pt"><span class="alt-edited">Estas são as condições de uso comuns em muitos países, por isso é importante considerar estas suposições. Nosso objetivo é tentar otimizar a experiência de atualização para as pessoas nas quais ela se aplica. Estes pressupostos em geral não irão impactar negativamente os usuários que têm acesso barato a um WiFi rápido.</span></span></p>
+
+<h3 id="Parâmetros_técnicos_de_design"><span class="short_text" id="result_box" lang="pt"><span class="alt-edited">Parâmetros técnicos de design</span></span></h3>
+
+<p><span id="result_box" lang="pt"><span class="hps">Esta seção aborda</span> <span class="hps">alguns princípios</span> <span class="hps">de design para</span> <span class="hps">a implementação de</span> <span class="hps">atualizações de aplicativos</span> <span class="hps">do Firefox</span> <span class="hps">OS</span><span>:</span></span></p>
+
+<ul>
+ <li>Por enquanto o dispositivo irá pesquisar periodicamente o mercado para atualizações; mais tarde iremos avaliar a possibilidade de atualizações automáticas.</li>
+ <li>O mercado vai saber a versão atual de cada app.</li>
+ <li>As atualizações podem ser baixadas e instaladas enquanto a versão atual do aplicativo é aberta com um risco baixo de que isto quebrará o aplicativo em execução no momento.</li>
+</ul>
+
+<h3 id="Considerações_aos_desenvolvedores">Considerações aos desenvolvedores</h3>
+
+<p>Existem algumas considerações importantes para os desenvolvedores, no que diz respeito ao modelo de atualização do aplicativo:</p>
+
+<ul>
+ <li>Os desenvolvedores da Web estão acostumados com usuários que estão sempre utilizando a última versão de seus sites; a manutenção de aplicativos atualizados emula este modelo.</li>
+ <li>A segurança também é melhorada quando o máximo possível de usuários são mantidos atualizados.</li>
+</ul>
+
+<h2 id="Experiência_do_usuário">Experiência do usuário</h2>
+
+<h3 id="Princípios_de_design">Princípios de design</h3>
+
+<p><span id="result_box" lang="pt"><span class="alt-edited">Afim de oferecer a melhor experiência de usuário possível durante a atualização do aplicativo, alguns princípios fundamentais serão mantidos em mente:</span></span></p>
+
+<ul>
+ <li>As atualizações devem minimizar o impacto para o usuário; não interrompa o usuário além do necessário, não afete negativamente a sua velocidade de conexão, e assim por diante.</li>
+ <li><span class="short_text" id="result_box" lang="pt"><span class="alt-edited">Não cobre nenhuma taxa do usuário para atualizar seus apps.</span></span></li>
+ <li><span id="result_box" lang="pt"><span class="alt-edited">Minimize as consequências de atualizações que falharam.</span></span></li>
+ <li><span id="result_box" lang="pt"><span class="alt-edited">Apoie a compatibilidade para os usuários que não podem atualizar seus apps, ou não são capazes de atualizá-los com freqüência.</span></span></li>
+ <li><span id="result_box" lang="pt"><span class="alt-edited">Evite apresentar detalhes técnicos desnecessários aos usuários.</span></span></li>
+</ul>
+
+<h3 id="Tipos_de_atualizações">Tipos de atualizações</h3>
+
+<p>Existem três tipos básicos de atualizações:</p>
+
+<dl>
+ <dt>Manual: individual</dt>
+ <dd> Uma única atualização de aplicativo iniciada pelo usuário.</dd>
+ <dt>Manual: batch</dt>
+ <dd>Múltiplas atualizações de aplicativos iniciadas pelo usuário de uma única vez. </dd>
+ <dt>Silent</dt>
+ <dd>Atualização automática de fundo.</dd>
+</dl>
diff --git a/files/pt-br/archive/b2g_os/security/modelo_de_seguranca/index.html b/files/pt-br/archive/b2g_os/security/modelo_de_seguranca/index.html
new file mode 100644
index 0000000000..a5ae858791
--- /dev/null
+++ b/files/pt-br/archive/b2g_os/security/modelo_de_seguranca/index.html
@@ -0,0 +1,275 @@
+---
+title: Visão geral sobre segurança
+slug: Archive/B2G_OS/Security/modelo_de_seguranca
+translation_of: Archive/B2G_OS/Security/Security_model
+---
+<h1 id="Introdução">Introdução</h1>
+<p><span class="seoSummary">Este documento apresenta uma visão geral sobre o framework de segurança do Mozilla Firefox OS, desenhado para proteger dispositivos móveis das ameaças para a plataforma, aplicativos e dados pessoais. No Firefox OS a fundação Mozilla implementou uma arquitetura de segurança abrangente, integrada, de várias camadas que traz maior segurança aos usuários dos dispositivos móveis.</span></p>
+<h1 id="Segurança_da_plataforma">Segurança da plataforma</h1>
+<p>A plataforma de segurança do Firefox OS é baseada num modelo multi-camada, desenhada para mitigar os riscos de exploração de falhas em todos os níveis. As medidas de combate da linha de frente é combinada com uma forte estratégia que provê uma proteção abrangente para qualquer ameaça.</p>
+<h2 id="Arquitetura_segura">Arquitetura segura</h2>
+<p>O Firefox OS conecta as aplicações web através ao hardware subjacente. É um conjunto de tecnologias integradas que consiste nos seguintes níveis:</p>
+<p><img alt="" src="https://mdn.mozillademos.org/files/5023/platform.png" style="width: 678px; height: 478px;"></p>
+<ul>
+ <li>Gaia: A suite de aplicações web que melhora a Experiência do Usuário (aplicações consiste-se de HTML5, CSS, JavaScript, imagens, mídias e etc.).</li>
+ <li>Gecko: A camada de aplicação que fornece o framework para a execução dos aplicativos e implementa as Web APIs utilizadas para acessar os recursos do dispositivo móvel.</li>
+ <li>Gonk: O camada do kernel do Linux, bibliotecas do sistema, firmware e drivers do dispositivo sobre o qual todo o resto é executado.</li>
+ <li>O dispositivo móvel: O celular executando o Firefox OS.</li>
+</ul>
+<p>Gecko é o guardião da plataforma que aplica políticas de segurança destinadas a proteger o dispositivo móvel do uso indevido. A camada do Gecko atua como um intermediário entre os aplicativos web (na camada Gaia) e o telefone.  Gonk oferece recursos de hardware do telefone celular diretamente para a camada Gecko. Os aplicativos Web acessam as funcionalidades do celular apenas através das Web APIs e somente se o Gecko permitir a requisição de acesso — não há acesso direto, nem “back door” no telefone. Gecko exige permissões e impede o acesso a solicitações não autorizadas.</p>
+<h3 id="Implantação_de_um_sistema_seguro">Implantação de um sistema seguro</h3>
+<p>Firefox OS vem instalado no smartphone. A imagem original do sistema é criada por uma fonte conhecida e confiável — normalmente um fabricante por OEM — que é responsável pela montagem, compilação, teste e assinar digitalmente o pacote de distribuição.</p>
+<p>As medidas de segurança são usadas através de um <em>stack</em> tecnológico. Privilégios de acesso ao sistema de arquivo são aplicadas por listas de controle de acesso do Linux (ACLs). Aplicativos do sistema são instalados em um volume com privilégio apenas de leitura (exceto durante as atualizações quando temporariamente é permitido a gravação), geralmente somente áreas com conteúdo do usuário podem ter privilégio de escrita. Vários componentes no hardware do dispositivo possui proteções internas que são implementadas com práticas padrão da indústria — fabricantes de chipset manufacturers, por exemplo, empregam técnicas de <em>hardening</em> para reduzir vulnerabilidades. e fortalecer a defesa contra ameaças potenciais na plataforma central (Gecko e Gonk) e recursos de hardening do compilador são usados quando aplicável. Para maiores detalhes veja <a href="https://developer.mozilla.org/pt-BR/Firefox_OS/Security/System_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Runtime_security">Segurança do sistema</a>.</p>
+<h3 id="Atualização_segura_do_sistema">Atualização segura do sistema</h3>
+<p>Atualizações e patches subsequentes da plataforma Firefox OS são instaladas usando um processo seguro da Mozilla que garante a integridade da imagem do sistema. A atualização é criada por uma fonte conhecida e confiável — normalmente o fabricante do dispositivo — que é responsável por montar, compilar, testar e assinar digitalmente o pacote de atualização.</p>
+<p>As atualizações do sistema envolve toda ou uma parte do <em>stack</em> do Firefox OS. Se alterações no Gonk são incluídas na atualização, é utilizado o processo de instalação FOTA (Firmware Over the Air). Atualizações FOTA também incluem qualquer outra parte do stack do Firefox OS, incluindo o gerenciamento do dispositivo (FOTA, firmware e drivers), gerencialmento das configurações (configuração Firefox OS), atualizações de segurança, Gaia, Gecko e outros <em>patches</em>.</p>
+<p>Atualizações que não envolvem o Gonk podem ser feitas utilizando o Utilitário de atualização do sistema da Mozilla. Firefox OS usa o mesmo framework de atualização, processos e o formato MAR (Mozilla ARchive) que o produto Firefox Desktop.</p>
+<p>Um serviço de atualização instalado no próprio dispositivo — que pode ser fornecido pelo OEM — verifica se há atualizações do sistema disponíveis. Uma vez disponível é solicitada uma confirmação do usuário para instalá-la. Antes, é verificado se há espaço suficiente além de alguns detalhes da distribuição:</p>
+<ul>
+ <li>Origem da atualização (verifica o protocolo de localização da origem:domínio:porta da atualização do sistema e manifesto)</li>
+ <li>Integridade do arquivo (SHA-256 hash check)</li>
+ <li>Assinatura do código (verificação do certificado contra uma raiz confiável)</li>
+</ul>
+<p>As seguintes medidas de segurança são usadas durante o processo de atualização:</p>
+<ul>
+ <li>A Mozilla recomenda e espera que as atualizações sejam baixadas através de uma conexão SSL.</li>
+ <li>Uma verificação criptográfica forte é necessária antes de instalar um pacote de firmware.</li>
+ <li>A atualização completa deve ser baixada de um site específico e seguro ante do processo ser iniciado.</li>
+ <li>O sistema deve estar em um estado seguro quando a atualização iniciar, sem nenum aplicativo sendo executado.</li>
+ <li>As chaves devem ser armazenadas em um local seguro do dispositivo.</li>
+</ul>
+<p>Controles rigorosos, estão presentes para garantir que a atualização seja aplicada corretamente no dispositivo.</p>
+<div class="note">
+ <p><strong>Nota</strong>: Para maiores informações sobre como as atualizações funcionam e como criar e distribuir as atualizações, leia <a href="https://developer.mozilla.org/pt-BR/Firefox_OS/Construindo_e_instalando_o_Firefox_OS/Criando_e_aplicando_pacotes_de_atualizacao_Firefox_OS">Criando e aplicando pacotes de atualização do Firefox OS.</a></p>
+</div>
+<h2 id="Segurança_do_Aplicativo">Segurança do Aplicativo</h2>
+<p>Firefox OS usa uma estratégia de defesa chamada <em>defense-in-depth</em> para proteger o dispositivo de aplicações intrusivas ou maliciosas. Essa estratégia emprega uma variedade de mecanismos, incluindo níveis de permissionamento implícito baseado em modelo de aplicativo do confiança, execução em sandbox em tempo de execução, acesso ao hardware apenas através de APIs, modelo robusto de permissionamento e um processo seguro de instalação e atualização. Para detalhes técnicos veja <a href="https://developer.mozilla.org/pt-BR/docs/Mozilla/Firefox_OS/Security/Application_security" title="/en-US/docs/Mozilla/Firefox_OS/Security/Application_security">Segurança da aplicação.</a></p>
+<p>No Firefox OS, todos os aplicativos são aplicativos web — programas escritos usando HTML5, JavaScript, CSS, mídias e outras tecnologias abertas (páginas que funcionam dentro do navegador não são referidos como aplicativos web neste contexto). Devido ao fato de não haver arquivos binários (nativos) instalados pelo usuário, todo o acesso ao sistema é mediado estritamente através de Web APIs. Mesmo o acesso ao sistema de arquivos é feito através das Web APIs e um banco de dados SQLite no back-end — não há acesso direto dos aplicativos aos arquivos armazenados no cartão de memória externo.</p>
+<p>O Firefox OS limita e reforça o escopo dos recursos que podem ser acessados e utilizados por um aplicativo, enquanto também suporta um grande número de aplicativos com diferentes níveis de permissões. A Mozilla implementou um rígido controle sobre quais aplicativos podem acessar quais APIs. Por exemplo, somente aplicativos certificados (fornecidos com o telefone) pode acessar a API de telefonia. O aplicativo discador tem privilégios para poder acessar a API de telefonia, mas nem todos os outros aplicativos certificados podem acessar essa API.</p>
+<p>Isso evita uma situação, por exemplo, no qual um aplicativo de terceiros possa acessar o discador e chamar indiscriminadamente um telefone qualquer.</p>
+<p>Outro aplicativo OEM pode ser selecionado para ter acesso à API de telefoina. Por exemplo, um operador pode fornecer uma aplicação de gerenciamento que permite ao usuário verificar sua conta, incluindo a possibilidade de realizar uma chamada telefônica diretamente.</p>
+<h3 id="Aplicativos_confiáveis_e_não_confiáveis">Aplicativos confiáveis e não confiáveis</h3>
+<p>Firefox OS categoriza os aplicativos de acordo com os seguintes tipos:</p>
+<table>
+ <thead>
+ <tr>
+ <th style="width: 82px;">
+ <p>Tipo</p>
+ </th>
+ <th style="width: 102px;">
+ <p>Nível de confiança</p>
+ </th>
+ <th style="width: 447px;">
+ <p>Descrição</p>
+ </th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td style="width: 82px;">
+ <p>Certificado</p>
+ </td>
+ <td style="width: 102px;">
+ <p>Altamente confiável</p>
+ </td>
+ <td style="width: 447px;">
+ <p>Aplicativos do sistema que devem ser aprovados pela Operadora ou OEM (devido ao risco de corromper o dispositivo ou causar um dano crítico de alguma funcionalidade). Somente para aplicativos ou serviços do sistema, não destinado a aplicações de terceiros.<br>
+ Essa classificação é reservada apenas para um pequeno número de aplicações críticas. Por exemplo: SMS, Bluetooth, câmera, relógio do sistema, telefonia e o discador padrão (para garantir que os serviços de emergência estejam sempre acessíveis).</p>
+ </td>
+ </tr>
+ <tr>
+ <td style="width: 82px;">
+ <p>Privilegiado</p>
+ </td>
+ <td style="width: 102px;">
+ <p>Confiável</p>
+ </td>
+ <td style="width: 447px;">
+ <p>Aplicativos de terceiros devem ser revisados, aprovados e digitalmente assinados para serem autorizados dentro do Marketplace.</p>
+ </td>
+ </tr>
+ <tr>
+ <td style="width: 82px;">
+ <p>Web (todo o resto)</p>
+ </td>
+ <td style="width: 102px;">
+ <p>Não confiável</p>
+ </td>
+ <td style="width: 447px;">
+ <p>Conteúdo normal da web. Inclui os aplicativos instalados (armazenados no telefone) e aplicativos hospedados (armazendos remotamente, com somente um manifesto armazenado no telefone). O manifesto para aplicativos hospedados pode ser obtido no Marketplace.</p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>O nível de confiança de um aplicativo determina, em parte, a sua habilidade de acessar as funcionalidades do telefone.</p>
+<ul>
+ <li>Aplicativos certificados tem permissões para a maioria das operações das Web APIs.</li>
+ <li>Aplicativos privilegiados tem permissões para um subconjunto de Web APIs acessíveis pelos aplicativos Certificados.</li>
+ <li>Aplicativos não confiáveis tem permissão para um subconjunto de Web APIs acessíveis pelos aplicativos privilegiados — apenas as Web APIs que contem medidas de mitigação de segurança podem ser acessíveis por um aplicativo não confiável.</li>
+</ul>
+<p>Algumas operações, como acesso à rede, possuem permissões implícitas para todos os aplicativos. Em geral, quanto mais sensível a operação (por exemplo, chamar um número de telefone ou acessar a lsta de contaos),  maior o nível de confiança exigido para executá-lo.</p>
+<div class="note">
+ <p><strong>Nota</strong>: para maiores informações sobre as APIs disponíveis e seus níveis de permissão, consulte <a href="https://developer.mozilla.org/pt-BR/docs/Web/Apps/Developing/permisoes_app">Permissões de aplicativos</a>.</p>
+</div>
+<h4 id="Princípio_do_privilégio_mínimo">Princípio do privilégio mínimo</h4>
+<p>Para aplicações web, o framework de segurança do Fireofox OS segue o <em>princípio do privilégio mínimo</em>: começa com o mínimo absoluto de permissões e seletivamente concede privilégios adicionais somente quando for requisitado e for razoável. Por padrão um aplicativo começa com um nível de permissão muito baixo, que é comparável a um conteúdo web não confiável. Se o aplicativo faz uma chamada a uma Web API que requisita permissões adicionais, ele deve enumerar essas permissões adicionais no manifesto (a ser descrito mais tarde nesse documento). O Gecko vai considerar a concessão do acesso somente se estiverem explicitamente requisitados no seu manifesto e se o tipo do aplicativo (certificado, privilegiado ou web) é suficientemente qualificado para o acesso solicitado.</p>
+<h4 id="Processo_de_revisão_para_aplicativos_privilegiados_no_Marketplace">Processo de revisão para aplicativos privilegiados no Marketplace</h4>
+<p>Para que um aplicativo torne-se privilegiado, o desenvolvedor do aplicativo deve submetê-lo a aprovação no Marketplace que sumete o aplicativo a um rigoroso processo de revisão de código: verificando sua autenticidade e integridade, garantindo que as permissões requisitadas são usadas para os propósitos declarados (no racional da permissão), verificando que o uso implícito da permissão é apropriado e validando que qualquer interface entre o conteúdo privilegiado e não privilegiado do aplicativo possui as mitigações apropriadas contra possíveis ataques. O Marketplate tem a responsabilidade de garantir que o aplicativo não possui um comportamento malicioso com as permissões que lhe são concedidas.</p>
+<p>Depois que o aplicativo passa nessa revisão, é aprovado para uso, o manifesto é assinado digitalmente pelo Marketplace e é disponibilizado para download para os usuários. A assinatura garante que caso a web store for atacada por hackers não há a possibilidade de instalar códigos maliciosos nos telefones dos usuários. Devido a esse processo, o Firefox OS fornece um elevado grau de confiança aos aplicativos baixados do Maketplace.</p>
+<div class="note">
+ <p><strong>Nota</strong>: para saber mais sobre os Marketplaces incluindo o <a href="https://marketplace.firefox.com/">Firefox Marketplace</a>, veja a <a href="https://developer.mozilla.org/pt-BR/docs/Mozilla/Marketplace">seção do Marketplace</a>.</p>
+</div>
+<h3 id="Aplicativos_hospedados_e_empacotados">Aplicativos hospedados e empacotados</h3>
+<p>Os aplicativos no Firefox OS podem ser empacotados (armazenado no dispositivo) ou hospedado (armazenado em um servidor web remoto, apenas com o manifesto armazenado no dispositivo). Existem algumas diferenças na forma de lidar com a segurança em cada uma das formas. No entanto, os aplicativos empacotados e hospedados estão sujeitos a aplicação do sandboxing, que é descrita mais adiante neste documento.</p>
+<div class="note">
+ <p><strong>Nota</strong>: Você pode saber mais sobre aplicativos hospedados e empacotados no artigo <a href="https://developer.mozilla.org/pt-BR/docs/Mozilla/Marketplace/Publishing/Opcoes_de_publicacao">opções de publicação de aplicativos</a>.</p>
+</div>
+<h4 id="Aplicativos_empacotados">Aplicativos empacotados</h4>
+<p>Um aplicativo empcotado consiste-se de um arquivo ZIP com os recursos (HTML5, CSS, JavaScript, imagens, mídias), bem como um manifesto que fornece uma lista explícita de ativos e seus hashes correspondentes. Aplicativos certificados e privilegiados devem ser empacotados porque o manifesto deve ser digitalmente assinado. Quando um usuário obtem um aplicativo empacotado, o arquivo ZIP é baixado no dispositivo e o manifesto é lido de um local conhecido dentro do arquivo ZIP. Durante o processo de instalação, os ativos do aplicativo são verificados e permanecem armazenados dentro do pacote. Todas as permissões explícitas são requisitadas em tempo de execução, mostrando ao usuário as intenções do aplicativo e persistido por padrão.</p>
+<p>Ao referir-se aos recursos de um aplicativo empacotado, a URL deve começar por app: usando o seguinte formato:</p>
+<p><code>app://<em>identifier</em>/<em>path_within_zipfile</em>/file.html</code></p>
+<p>onde <code>app://</code> representa o ponto de montagem do arquivo ZIP e <code>identifier</code> é uma UUID gerada quando o aplicativo é instalado no dispositivo. Esse mecanismo garante que os recursos são referenciados como aplicativo: URL estão contidos no arquivo ZIP. O caminha dentro de um aplicativo: é relativo, então links relativos para os recursos dentro do arquivo ZIP são permitidos.</p>
+<p>Aplicativos empacotados destinam-se principalmente a serm utilzados por aplicativos certificados ou privilegiados, mas aplicativos comuns também podem ser empacotados. Porém, não há nehum ganho ou aumento na confiança ou permissões de acesso simplesmente devido ao fato de ser empacotado.</p>
+<h4 id="Aplicativos_hospedados">Aplicativos hospedados</h4>
+<p>São armazenados em um servidor web e carregados via HTTP. Apenas o manifesto do aplicativo fica armazenado no dispositivo. Todo o restante é armazenado remotamente. Algumas APIs estão disponíveis somente para aplicativos certificados, que exigem que sejam empacotados devido a requisitos de assinatura digital. Assim, um aplicativo hospedado não possuirá acesso a nenhuma operação de API que exige que o aplicativo seja certificado ou privilegiado.</p>
+<p>Pelo ponto de vista da segurança, aplicativos hospedados funciona de forma similar a websites. Um aplicativo hospedado é carregado invocando uma URL descrita diretamente no código que aponta para uma página de início no diretório raiz do aplicativo armazenado em um servidor web. Uma vez que um aplicativo hospedado é carregado, o dispositivo conecta às páginas usando as mesmas URLs que são usadas ao navegar o website.</p>
+<h3 id="Manifesto_do_aplicativo">Manifesto do aplicativo</h3>
+<p>Um manifeseto de um aplicativo Open Web contém informações que um navegador Web necessita para interagir com um aplicativo. É um arquivo JSON que deve possuir pelo menos o nome e a descrição do aplicativo. Para maiores detalhes consulte <a href="https://developer.mozilla.org/pt-BR/docs/Apps/FAQs/About_app_manifests" title="/en-US/docs/Apps/FAQs/About_app_manifests">Perguntas frequentes sobre manifestos</a>.</p>
+<h4 id="Examplo_de_Manifesto">Examplo de Manifesto</h4>
+<p>O código a seguir mostra um exemplo de manifesto com apenas algumas configurações:</p>
+<pre class="brush:text language-html"><code class="language-html">{
+ "name": "My App",
+ "description": "My elevator pitch goes here",
+ "launch_path": "/",
+ "icons": {
+ "128": "/img/icon-128.png"
+ },
+ "developer": {
+ "name": "Your name or organization",
+ "url": "http://your-homepage-here.org"
+ },
+ "default_locale": "en"
+}</code></pre>
+<h3 id="Configurações_de_segurança_no_manifesto">Configurações de segurança no manifesto</h3>
+<p>O manifesto pode conter outras configurações, incluindo as de segurança:</p>
+<table>
+ <thead>
+ <tr>
+ <th style="width: 152px;">
+ <p>Campo</p>
+ </th>
+ <th style="width: 479px;">
+ <p>Descrição</p>
+ </th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td style="width: 152px;">
+ <p>permissions</p>
+ </td>
+ <td style="width: 479px;">
+ <p>Permissões solicitadas pelo aplicativo. Devem ser listadas todas as Web APIs que pretende usar e que necessitam permissão do usuário. A maioria das permissões fazem sentido para aplicativos certificados ou privilegiados, mas não para aplicativos hospedados. Propriedades por API:</p>
+ <ul>
+ <li><strong>description</strong>: Uma string especificando a intenção do uso da API. Campo obrigatório.</li>
+ <li><strong>access</strong>: Especifica o tipo de acesso para a permissão. Permissões implícitas são concedidas no momento da instalação. Exigidas apenas por algumas APIs. Valores aceitos: <strong>read</strong>, <strong>readwrite</strong>, <strong>readcreate</strong>, and <strong>createonly</strong>.</li>
+ </ul>
+ </td>
+ </tr>
+ <tr>
+ <td style="width: 152px;">
+ <p>installs_allowed_from</p>
+ </td>
+ <td style="width: 479px;">
+ <p>A origem do aplicativo, pode ser simples ou um conjunto de origens (esquema+hostname único) que podem disparar a instalação do aplicativo. Permite que fornecedores dos aplicativos permitam instalações somente de Marketplaces autorizados (como por exemplo <a href="https://marketplace.firefox.com/">https://marketplace.firefox.com/</a>).</p>
+ </td>
+ </tr>
+ <tr>
+ <td style="width: 152px;">
+ <p>csp</p>
+ </td>
+ <td style="width: 479px;">
+ <p>Content Security Policy (CSP). Aplicado a todas as páginas carregadas no aplicativo. Utlizado para fazer um <em>hardening</em> no aplicativo protegendo contra bugs que possam permitir um ataque que injete código no aplicativo. Se não for especificado, aplicativos certificaso e privilegiaods possuem padrões definidos pelo sistema. Sintaxe:<br>
+ <a href="https://developer.mozilla.org/en-US/docs/Apps/Manifest#csp">https://developer.mozilla.org/en-US/docs/Apps/Manifest#csp</a></p>
+ <p><em>Observe que essa diretiva somente pode acrescentar o CSP aplicado. Você não pode usar, por exemplo, para reduzir o nível de segurança de um aplicativo privilegiado.</em></p>
+ </td>
+ </tr>
+ <tr>
+ <td style="width: 152px;">
+ <p>type</p>
+ </td>
+ <td style="width: 479px;">
+ <p>Tipo do aplicativo (web, privilegiado ou certificado).</p>
+ </td>
+ </tr>
+ </tbody>
+</table>
+<p>Firefox OS exige que o manifesto seja hospedado com um <code>mime-type</code> específico (<code>application/x-web-app-manifest+json</code>) e do mesmo nome de servidor (origem) no qual o aplicativo está hospedado. Essa restrição é reduzida quando o manifesto está na mesma origem da página que requisitou o aplicativo a ser instalado. Esse mecanismo é utilizado para garantir que não é possivel burlar um website através de um manifesto.</p>
+<h3 id="Execução_no_Sandbox">Execução no Sandbox</h3>
+<h4 id="Applicação_Sandbox">Applicação Sandbox</h4>
+<p>O framework de segurança do Firefox OS usa a técnica de <em>sandboxing</em> como estratégia de defesa para mitigar riscos e proteger o dispositivo, plataforma e dados. Sandboxing é uma forma de impor limites e restrições em torno no aplicativo durante a sua execução. Cada aplicativo é executado no seu próprio espaço e tem acesso somente às Web APIs e dados permitidos, bem como aos recursos associados com o seu espaço de trabalho (banco de dados IndexedDB, cookies, armazenamento offline, etc.)</p>
+<p>A figura a seguir fornece uma visão geral do modelo de segurança.</p>
+<p><img alt="" src="https://mdn.mozillademos.org/files/5025/sandbox.png"></p>
+<p>Ao isolar cada aplicativo, suas tarefas ficam confinadas ao seus espaços de trabalho e não podem inteferir em nada (como outros aplicativos e seus dados) fora do seu limite.</p>
+<h4 id="Execução_do_Sandbox">Execução do Sandbox</h4>
+<p>B2G (Gecko) executa um processo com alto privilégio que tem acesso aos recursos de hardware no dispositivo. Em tempo de execução, cada aplicativo é executado dentro de um ambiente que é um processo filho do processo B2G. Cada processo filho tem um conjunto restrito de privilégios — por exemplo, um processo filho não pode ler ou escrever arbitrariamente no sistema de arquivos. Acessos privilegiados é fornecido através de Web APIs, que são mediadas pelo processo pai B2G, garantindo que quando um processo filho requisita uma API privilegiada, ela tem a permissão necessária para executar a ação.</p>
+<p>Os aplicativos se comunicam somente com o processo principal B2G, e não com outros processos ou aplicativos. Eles não são executados independentes do B2G, nem podem abrir outros aplicativos. A única comunicação possível entre os aplicativos é indireta (por exemplo, quando um aplicativo configura um alarme de sistema e outro aplicativo dispara uma notificação do sistema como resultado da configuração), e é mediada pelo processo B2G.</p>
+<h4 id="Hardware_é_acessado_somente_via_Web_API">Hardware é acessado somente via Web API</h4>
+<p>Os aplicativos somente tem um ponto de entrada para acessar as funcionalidades do telefone: as Web APIs do Firefox OS,  que são implementadas no Gecko. Que fornece o único gateway para o dispositivo e seus serviços. Não há uma API "nativa" e não há outras rotas que contornem esse mecanismo e interaja indiretamente com o hardware ou penetre na camada de baixo nível do software, ou seja: não há "back-doors".</p>
+<h2 id="Infraestrutura_de_Segurança">Infraestrutura de Segurança</h2>
+<p>A figura a seguir mostra os componentes do framework de segurança do Firefox OS:</p>
+<p><img alt="" src="https://mdn.mozillademos.org/files/5027/securityframework.png" style="width: 979px; height: 591px;"></p>
+<ul>
+ <li><strong>Permission Manager</strong>: Um gateway para acessar funcionalidades na Web API, que é o único acesso ao hardware.</li>
+ <li><strong>Access Control List</strong>: Matriz de regras e permissões necessárias para acessar as Web APIs.</li>
+ <li><strong>Credential Validation</strong>: Autenticação de aplicativos e usuários.</li>
+ <li><strong>Permissions Store</strong>: Conjunto de privilégios necessários para acessar as Web APIs.</li>
+</ul>
+<h3 id="Gestão_de_permissões_e_sua_aplicação">Gestão de permissões e sua aplicação</h3>
+<p>O sistema de segurança do Firefox OS é projetado para verificar e fazer cumprir as permissões concedidas às aplicações web..</p>
+<p>O sistema concede uma permissão particular a um aplicativo somente se o mesmo a requisita e se estiver descrita no manifesto do aplicativo. Algumas permissões exigem uma permissão adicional do usuário, normalmente através de uma mensagem na tela do dispositivo (como por exemplo no caso do aplicativo requisitar acesso à localização atual do usuário). Esse framework baseado no aplicativo fornece um controle mais granular sobre as abordagens de permissão baseada no perfil (no qual é atribuído um conjunto de permissões a cada perfis).</p>
+<p>Uma Web API possui um conjutno de ações e destinatários. Cada Web API possui um nível de permissão e cada vez que é chamada o Gecko verifica os requisitos de permissão baseado em:</p>
+<ul>
+ <li>Permissões associadas com o chamada do aplicativo (como especificado no manifesto e baseado no seu tipo).</li>
+ <li>Permissões requisitadas para executar uma determinada operação (chamada à Web API).</li>
+</ul>
+<p>Se a requisição não atender aos critérios de permissão o Gecko a rejeita. Por exemplo, aplicativos não confiáveis não podem executar APIs que são reservadas para aplicativos confiáveis.</p>
+<h3 id="Solicitando_permissão_do_usuário">Solicitando permissão do usuário</h3>
+<p>In addition to permissions that are implicitly associated with the web apps, certain operations require explicit permission from the user before they can be executed (for example, "can the web app access your camera?"). For these operations, web apps are required to specify, in their manifest, their justification for requiring this permission. This <em>data usage intention</em> informs users about what the web app intends to do with this data if permission is granted, as well as any risk involved. This allows users to make informed decisions and maintain control over their data.</p>
+<h3 id="Precesso_de_atualização_de_um_aplicativo_seguro">Precesso de atualização de um aplicativo seguro</h3>
+<p><img alt="" src="https://mdn.mozillademos.org/files/5029/updateprocess.png" style="width: 979px; height: 102px;"></p>
+<p>Para atualizar ou aplicar uma correção de um aplicativo privilegiado, os fornecedores submetem o pacote de atualização a um Marketplace autorizado onde é feita a revisão e se for aprovado é assinado e disponibilizado aos usuários. Nos dispositivos Firefox OS, um utilitário de atualização é executado periodicamente para verificar se há atualizações dos aplicativos. Caso exista, é perguntado ao usuário se deseja instalar a atualização. Antes da instalação é realizada a seguinte verificação no pacote:</p>
+<ul>
+ <li>Origem da atualização (é verificada a fonte protocolo:domínio:porta da atualização e do manifesto)</li>
+ <li>Integridade do arquivo (hash SHA-256)</li>
+ <li>Assinatura do código (verificação do certificado contra uma raiz confiável)</li>
+</ul>
+<p>Controles rigorosos são executados para garantir que a atualização é aplicada corretamente ao dispositivo. O pacote completo de atualização deve ser baixado numa localização específica e segura antes do processo iniciar. A instalação não sobrescreve nenhum dado do usuário.</p>
+<div class="note">
+ <p><strong>Nota</strong>: Para maiores informações sobre atualização de aplicativo verifique esse <a href="https://developer.mozilla.org/pt-BR/Apps/Developing/Updating_apps">artigo</a>.</p>
+</div>
+<h2 id="Segurança_do_Dispositivo_(Hardware)">Segurança do Dispositivo (Hardware)</h2>
+<p>Os mecanismos de segurança para o hardware do dispositivo são tipicamente de responsabiliade do fabricante. Por exemplo, um fabricante pode oferecer uma proteção para o SIM (Subscriber Identity Module) em conjunto com um código PUK (PIN Unlock Key) para desbloquear o cartão SIM travado por um número determinado de erros na senha do cartão. Contacte o fornecedor para maiores detalhes. Firefox OS possibilita aos usuários configurarem senhas e bloqueio de tela, que será tratado na próxima seção.</p>
+<h2 id="Segurança_dos_dados">Segurança dos dados</h2>
+<p>Usuários podem armazenar dados pessoais no seu dispositivo e mantê-los privados como contatos informações financeiras (detalhes de banco e cartões de crédito), senhas, calendários e etc. O Firefox é projetado com proteções contra aplicativos maliciosos que podem roubar, explorar ou destruir dados sensíveis.</p>
+<h3 id="Senha_e_bloqueio_de_tela_por_tempo">Senha e bloqueio de tela por tempo</h3>
+<p>O Firefox OS permite aos usuários definir uma senha para acessar e utilizar o telefone. Também permite bloqueio da tela após um período configurável de inatividade solicitando uma senha para desbloquear o telefone.</p>
+<h3 id="Dados_no_Sandboxe">Dados no Sandboxe</h3>
+<p>Como descrito anteriormente, os aplicativos são executados num <em>sandbox</em>. Isso evita que um aplicativo acesse os dados de outro a não ser que os dados sejam explicitamente compartilhados e o outro aplicativo possua permissões para acessá-los.</p>
+<h3 id="Serialização_de_dados">Serialização de dados</h3>
+<p>Os aplicativos web não possuem acesso direto de leitura ou escrita ao sistema de arquivos. Todo o acesso ao armazenamento é feito através de Web APIs. Que lêem e escrevem via um banco de dados SQLite. Não há um acesso direto de I/O. Cada aplicativo possue seu próprio local de armazenamento de dados que é serializado pelo banco de dados.</p>
+<h3 id="Destruição_dos_dados">Destruição dos dados</h3>
+<p>Quando um usuário desinstala um aplicativo, todos os dados relacionados ao aplicativo (cookies, localStorage, IndexedDB, etc.) são apagados.</p>
+<h3 id="Privacidade">Privacidade</h3>
+<p>A Mozilla está comprometida a proteger a privacidade dos usuários e de seus dados de acordo com seus princípios (<a href="https://www.mozilla.org/privacy/">https://www.mozilla.org/privacy/</a>), que sustenta o Manifesto Mozilla (<a href="http://www.mozilla.org/pt-BR/about/manifesto/">http://www.mozilla.org/pt-BR/about/manifesto/</a>). A política de privacidade Firefox Mozilla descreve como a Mozilla coleta e utiliza as informações dos usuários do navegador Firefox Mozilla, incluindo o que o Firefox envia para os websites, o que a Mozillar faz para proteger os dados, e etc. Para mais informações veja:</p>
+<ul>
+ <li><a href="http://www.mozilla.org/en-US/legal/privacy/firefox.html">http://www.mozilla.org/en-US/legal/privacy/firefox.html</a></li>
+ <li><a href="https://blog.mozilla.org/privacy/">https://blog.mozilla.org/privacy/</a></li>
+ <li><a href="http://support.mozilla.org/en-US/kb/privacy-and-security-settings-firefox-os-phones">http://support.mozilla.org/en-US/kb/privacy-and-security-settings-firefox-os-phones</a></li>
+</ul>
+<p>O Firefox OS implementa esses princípios colocando o controle dos dados dos usuários nas mãos ele, que é quem deve decidir para onde as informações pessoais devem ir. O Firefox OS provê os seguintes recursos:</p>
+<ul>
+ <li>Opção de não rastreamento</li>
+ <li>Possibilidade de desabilitar os cookies no navegador do Firefox OS</li>
+ <li>Possibilidade de apagar o histórico do navegador do Firefox OS</li>
+</ul>
diff --git a/files/pt-br/archive/b2g_os/security/seguranca_de_aplicacao/index.html b/files/pt-br/archive/b2g_os/security/seguranca_de_aplicacao/index.html
new file mode 100644
index 0000000000..335fb17562
--- /dev/null
+++ b/files/pt-br/archive/b2g_os/security/seguranca_de_aplicacao/index.html
@@ -0,0 +1,138 @@
+---
+title: Segurança de Aplicativos
+slug: Archive/B2G_OS/Security/Seguranca_de_aplicacao
+tags:
+ - Aplicativo
+ - Apps
+ - Firefox OS
+ - Guía
+ - Movel
+ - Segurança
+translation_of: Archive/B2G_OS/Security/Application_security
+---
+<div class="summary">
+ <p>Este artigo aborda detalhadamente o modelo de segurança de aplicativos no Firefox OS.</p>
+</div>
+<p>Os principais controles de segurança apresentados pelo Firefox OS são:</p>
+<ul>
+ <li>Aplicativos Web são instalados e executados explicitamente, ao invés de serem simplesmente abertos em um navegador. Os aplicativos precisam ser instalados antes de serem utilizados, a atualização e remoção de aplicativos são reguladas por controles de segurança para proteger o usuário.</li>
+ <li>Acesso a novas APIs Web são controladas por um sistema de permissões. O aplicativo precisa declarar as permissões que pretende usar antes da instalação. Para receber acesso a APIs mais poderosas, o aplicativo precisa atender certos requisitos, ser revisado, aprovado e assinado por um <em>Marketplace</em>.</li>
+ <li>Aplicativos Web são isolados (<em>sandboxed</em>) de maneira que somente tem acesso aos seus próprios recursos (<em>cookies</em>, <em>offline storage</em>, bases de dados IndexedDB, e etc.). Mesmo se dois aplicativos vierem a carregar a mesma URL, essas duas páginas não são consideradas sendo de mesma origem pois estão executando dentro de aplicativos separados.</li>
+</ul>
+<h3 id="Tipos_de_aplicativos">Tipos de aplicativos</h3>
+<p>O FirefoxOS suporta três tipos de aplicativos: "<em><strong>web</strong></em>", "<strong>privilegiado</strong>" e <strong>interno</strong> ("<strong><em>Certificado</em></strong>"). O tipo de um aplicativo é declarado no seu arquivo de <a href="/en-US/docs/Apps/Manifest" title="/en-US/docs/Apps/Manifest">manifesto</a> e determina a lista de permissões que o aplicativo pode solicitar.</p>
+<ul>
+ <li><strong>Aplicativos Web:</strong> A maioria dos aplicativos de terceiros serão "<em>web</em>", que é o tipo padrão, não concedendo o aplicativo nenhuma permissão extra além daquelas já expostas para Web. Aplicativos Web podem ser instalados de qualquer site, sem nenhuma verificação adicional. Eles também podem ser <a href="/en-US/docs/Web/Apps/Packaged_apps" title="/en-US/docs/Web/Apps/Packaged_apps">empacotados</a> (<em>packaged</em>) , empacotar não concede nenhuma permissão adicional.</li>
+ <li><strong>Aplicativos Privilegiados</strong>: Estes aplicativos podem solicitar permissões mais elevadas, por esse motivo eles precisam ser verificados e assinados por um <em>Marketplace</em>.</li>
+ <li><strong>Aplicativos Internos/Certificados:</strong> No momento este tipo de aplicativo somente pode vir pré-instalado no dispositivo, a escolha do fabricante.</li>
+</ul>
+<div class="note">
+ <p><strong>Nota</strong>: Para informações adicionais sobre os três tipos veja a documentação do <a href="/en-US/docs/Apps/Manifest#type" title="/en-US/docs/Apps/Manifest#type">Manifesto do Aplicativo</a>.</p>
+</div>
+<h3 id="Distribuição_dos_aplicativos">Distribuição dos aplicativos</h3>
+<p>No Firefox OS os aplicativos podem ser distribuídos de duas formas diferentes: Sendo Hospedados ou Empacotados. Aplicativos "<em>web</em>" podem ser distribuídos por qualquer dos meios, sendo que os privilegiados e certificados precisam necessariamente ser empacotados.</p>
+<h4 id="Aplicativos_hospedados"><span class="mw-headline" id="Hosted_apps">Aplicativos hospedados </span></h4>
+<p>Um aplicativo <strong>hospedado</strong> consiste basicamente de um arquivo <a class="external text" href="/en-US/docs/Apps/Manifest" rel="nofollow">manifesto do aplicativo</a> no servidor web do desenvolvedor, este contém um <a href="/en-US/Apps/Build/Manifest#launch_path">caminho de execução</a> indicando que pagina deve ser aberta quando o aplicativo é inicializado. De uma perspectiva de segurança aplicativos hospedados funcionam de forma muito parecida com paginas<em> </em>web normais. Quando um aplicativo hospedado é carregado as URLs das paginas carregadas são as URLs normais onde aquelas paginas são acessadas no servidor onde estão hospedadas, mas se elas já estiverem no <em>appcache</em> elas serão carregadas do dispositivo.</p>
+<h4 id="Aplicativos_empacotados"><span class="mw-headline" id="Packaged_apps">Aplicativos empacotados</span></h4>
+<p>Um aplicativo <strong>empacotado</strong> é simplesmente uma aplicação web aberta que tem todo o seu conteudo como arquivos HTML, CSS, JavaScript, manifesto, e etc; contidos em um arquivo zip ao invés de ter seus arquivos hospedados em um servidor web. Para mais detalhes desse formato, veja <a href="/en-US/docs/Apps/Packaged_apps" title="Apps/Packaged_apps">Aplicativos empacotados</a>. </p>
+<h3 id="Origem_dos_aplicativos">Origem dos aplicativos</h3>
+<p>Para aplicativos hospedados, a origem do aplicativo é a origem onde se localiza o <a class="external text" href="/en-US/docs/Apps/Manifest" rel="nofollow">manifesto do aplicativo</a>.</p>
+<p>Para aplicativos empacotados, a origem é o identificador único do aplicativo que é designado ao mesmo durante a instalação. <a href="/en-US/Apps/Publishing/Packaged_Apps#Types_of_packaged_apps">Aplicativos Privilegiados e Internos </a>também podem solicitar uma origem especifica ao informar o parâmetro <a href="/en-US/Apps/Build/Manifest#origin">origem</a> no manifesto da aplicação.</p>
+<h3 id="Instalação_de_aplicativos"><strong>Instalação de aplicativos</strong></h3>
+<p>Aplicações são instaladas através da <a href="/en-US/docs/JavaScript_API" title="/en-US/docs/JavaScript_API">API JavaScript de Aplicativos</a>:</p>
+<ul>
+ <li>Aplicativos hospedados são instalados chamando:<br>
+ <code>navigator.mozApps.<a href="/en-US/docs/Web/API/Apps.install" title="/en-US/docs/Web/API/Apps.install">install</a>(manifestURL)</code>, onde manifestURL é a URL que informa a localização do aplicativo. Para mais detalhes, veja <a href="/en-US/docs/DOM/Apps.install">Instalando Aplicativos</a>.</li>
+ <li>Aplicativos empacotados são instalados chamando:<br>
+ <code>navigator.mozApps.<a href="/en-US/docs/Web/API/Apps.installPackage" title="/en-US/docs/Web/API/Apps.installPackage">installPackage</a>(packageURL)</code>. Para aplicativos empacotados o manifesto principal é armazenado dentro do próprio pacote para que ele seja assinado. Existe um segundo "mini-manifesto" que é usado somente para iniciar o processo de instalação. Para mais informações veja <a href="/en-US/docs/DOM/Apps.installPackage">Instalando aplicativos empacotados</a> e<a href="/en-US/docs/Apps/Packaged_apps" title="Apps/Packaged_apps"> Aplicativos empacotados</a>.</li>
+</ul>
+<p>De modo a garantir que um aplicativo realmente solicitou ser instalado como uma aplicação web, nós temos que certificar não ser possível enganar um servidor a hospedar um manifesto de aplicação. Isto é feito obrigando o servidor a disponibilizar o arquivo manifesto com o seguinte <em>mime-type</em>, <code>application/x-web-app-manifest+json</code>. Essa validação não é feita quando o aplicativo e o arquivo manifesto tem a mesma origem da página que solicitou a instalação da aplicação.</p>
+<h3 id="Atualizações"><span class="mw-headline" id="Updates">Atualizações</span></h3>
+<p>O processo de atualização de aplicativos é descrito em <a href="/en-US/docs/Apps/Updating_apps" title="Apps/Updating_apps">Atualizando aplicativos</a>.</p>
+<h2 id="Permissões">Permissões</h2>
+<p>Privilégios adicionais podem ser concedidos para aplicativos além daqueles concedidos para websites normais. Por padrão um aplicativo tem as mesmas permissões que paginas web normais. Para conseguir permissões adicionais o primeiro passo é o aplicativo enumerar as permissões extras e solicitar as mesmas no manifesto do aplicativo.</p>
+<h3 id="Declaração_no_manifesto">Declaração no manifesto</h3>
+<p>Para cada permissão adicional que um aplicativo deseja utilizar, o aplicativo precisa enumerar a permissão no manifesto complementada com uma descrição significativa de porque o aplicativo precisa daquela permissão adicional. Por exemplo, se um aplicativo quer usar a API <a href="/en-US/docs/Web/API/window.navigator.geolocation" title="/en-US/docs/Web/API/window.navigator.geolocation">navigator.geolocation</a>, ele precisa incluir o texto abaixo no seu manifesto:</p>
+<pre class="brush: json">"permissions": {
+ "geolocation":{
+<code class="language-js"><span class="token string"> "description"</span><span class="token punctuation">:</span> <span class="token string">"Necessária para autocompletar o local na tela compartilhar"</span><span class="token punctuation">,</span></code>
+ }
+},
+</pre>
+<p>Isso irá permitir o aplicativo solicitar a permissão do usuário para utilizar a API de geolocalização da mesma forma que uma pagina web solicitaria. Para mais detalhes, veja <a href="/en-US/docs/Apps/Manifest" title="Apps/Manifest">Manifesto do aplicativo</a>.</p>
+<div class="note">
+ <p><strong>Nota</strong>: Existe um bug que causa a não apresentação ao usuário das permissões que o aplicativo pretende utilizar — veja o <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=823385" title="https://bugzilla.mozilla.org/show_bug.cgi?id=823385">bug 823385</a>.</p>
+</div>
+<h3 id="Concedendo_permissões">Concedendo permissões</h3>
+<p>Quando as permissões são solicitadas no manifesto, a permissão é configurada como <em>Permitidas </em>(<em>allow)</em> ou <em>Solicitadas (prompt)</em>, dependendo da permissão solicitada. Permissões <em>Permitidas </em>são concedidas ao se declarar a mesma no manifesto sem aprovação direta do usuário a cada uso. Para permissões <em>Solicitadas </em>o usuário é consultado no primeiro uso da API relacionada, e tem a escolha de permitir ou não antes da API ser concedida para uso pelo aplicativo, O Firefox OS somente pergunta ao usuário sobre a concessão de permissões que tem um impacto em sua privacidade, e além disso seja razoável para o usuário entender o que está sendo perguntado. Por exemplo, acesso aos contatos é <em>Solicitada</em>, mas acesso para realizar uma conexão TCP é concedido implicitamente, porque não é razoavel que um usuário commum entenda as implicações de segurança de conceder essa permissão. Uso de permissões <em>Permitidas </em>são revistas no processo de segurança do Marketplace para garantir que os aplicativos disponiveis sejam seguros para os usuários.</p>
+<h3 id="Revogando_Permissões">Revogando Permissões</h3>
+<p>Os usuários tem o direito de mudar de ideia sobre permissões <em>Solicitadas </em>a qualquer momento, e podem revogar essas permissões através do aplicativo de configurações do Firefox OS. Entretanto, permissões <em>Permitidas </em>não podem ser alteradas pelo usuário.</p>
+<h2 id="Isolamento_dos_aplicativos_web">Isolamento dos aplicativos web</h2>
+<h3 id="Dados_armazenados_por_aplicativo"><span class="mw-headline" id="Data_stored_per_app">Dados armazenados por aplicativo </span></h3>
+<p>Cada aplicativo é executado pelo Firefox OS em uma area isolada, isso significa que todos os dados armazenados por um aplicativo está separado de todos os dados armazenados por outros aplicativos. Incluindo dados de <em>cookies</em>, dados em <em>localStorage</em>,dados no <em>indexedDB</em>, e permissões locais.</p>
+<p><img alt="A diagram showing three Firefox OS apps all open is separate sandboxes, so none of them can affect each other." src="https://mdn.mozillademos.org/files/7091/sandbox.png" style="width: 1040px; height: 437px; display: block; margin: 0px auto;"></p>
+<p>Isso significa que se o usuário tem dois aplicativos instalados, aplicativos A e B, esses aplicativos terão um conjunto completamente diferente de <em>cookies</em>, dados locais e permissões diferentes. Isto se aplica mesmo se ambos os aplicativos abrirem um {{ htmlelement("iframe") }} que aponta para a mesma origem, ambos A e B abrirem um <code>&lt;iframe&gt;</code> apontando para "<a class="external free" href="http://www.mozilla.org" rel="nofollow">http://www.mozilla.org</a>", Ambos irão abrir o site porém, o mesmo será baixado e exibido utilizando <em>cookies </em>diferentes nos dois aplicativos.</p>
+<p>O resultado prático é que se o usuario acessar o Facebook enquanto utiliza o aplicativo A, isso não afeta como o aplicativo B manipula a pagina do Facebook. Se o <em>cookie </em>de acesso que o Facebook configurou quando o usuário acessou usando o aplicativo A só está disponivel para o aplicativo A. Se o aplicativo B abrir um <code>&lt;iframe&gt;</code> para o Facebook, o <em>cookie </em>não estará disponível e o Facebook irá exibir novamente a tela de acesso no aplicativo B ao invés da pagina que está aberta no aplicativo A.</p>
+<h3 id="Aplicativos_não_podem_abrir_uns_aos_outros"><span class="mw-headline" id="Apps_can.27t_open_each_other">Aplicativos não podem abrir uns aos outros </span></h3>
+<p>Aplicativos utilizando iframes não podem abrir outros aplicativos.  Se o aplicativo A cria um <code>&lt;iframe&gt;</code> com o <code>src</code> apontando para a URL do aplicativo B, este não irá abrir o aplicativo B no <code>&lt;iframe&gt;</code> e simplesmente abrirá a pagina web que se encontra naquela URL. Também não pode utilizar cookies do aplicativo B, portanto se comportando como se o aplicativo B não estivesse instalado no dispositivo do usuário.</p>
+<p>Isso se aplica mesmo para aplicativos empacotados (mais detalhes abaixo). Se o aplicativo A tenta, utilizando um <code>&lt;iframe&gt;</code>, abrir o aplicativo empacotado B apontando para <code>app://</code>URLdoAplicativoB, simplesmente ocorrerá um erro ao abrir a URL. Se será um erro 404 ou outro tipo de erro isso será determinado no futuro, mas definitivamente irá ocorrer um erro ao abrir a página. Da mesma forma também ocorrerá erro independente do aplicativo B estar instalado no dispositivo do usuário ou não, de maneira que o aplicativo A não possa determinar através do erro se o aplicativo B está instalado ou não no dispositivo.</p>
+<p>A mesma coisa acontece se o <em>frame </em>principal do aplicativo A, navegar para uma URL do aplicativo B. O sistema sempre sabe que aplicativo está aberto em que frame. Portanto existindo uma tentativa de abrir a URL do aplicativo B no frame do aplicativo A, irá ocorrer o mesmo erro citado acima. Isso também garante que os recursos do aplicativo B como <em>cookies </em>ou dados locais não poderão ser usados de forma alguma pelo aplicativo A.</p>
+<h3 id="Motivos"><span class="mw-headline" id="Motivation">Motivos</span></h3>
+<p>Existem vantagens e desvantagens da segurança ser implementada desta forma. A desvantagem é que se o usuário interage com um mesmo site a partir de aplicativos diferentes ele terá que conectar em cada um dos aplicativos separadamente. Da mesma forma, se um site quer guardar dados localmente e o usuário interage com esse site em aplicativos diferentes os dados serão duplicados em cada aplicativo, que pode ser um problema se for o volume de dados for grande.</p>
+<p>A principal vantagem dessa implementação é que esse modelo é mais estável. Não permitimos que os aplicativos interajam entre si através de um site de terceiros e por exemplo um aplicativo parar de funcionar ao se instalar outro. Quando um aplicativo é deinstalado não é possivel que haja perda de dados de outro aplicativo, ou que um aplicativo pare de funcionar porque dependia do aplicativo desinstalado.</p>
+<p>É um modelo mais seguro. Um usuário pode usar o seu "AppSocialSuperManeiro" para conectar no Facebook sem se preocupar que o seu "AppSuperSuspeito" possa realizar qualquer ataque para obter os dados do usuário no Facebook através de bugs ou falhas no site do Facebook.</p>
+<p>Também existem beneficios a privacidade. O usuário pode tranquilamente instalar o "AppProcurandoEmprego" sem se preocupar porque o "AppDoFuncionarioDaMegaCorporação" não pode detectar que aplicativos estão instalados ou que dados ele criou no dispositivo.</p>
+<h3 id="Sandboxed_Permissions_2"><span class="mw-headline" id="Sandboxed_Permissions">Sandboxed Permissions</span></h3>
+<p>In the same way that web site data is sandboxed per app, so is permission data. If App A loads a page from <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> and that page requests to use geolocation and the user says "yes, and remember this decision for all times", this only means that <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> has access to geolocation within App A. If App B then opens <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, that page won't have access to geolocation unless the user grants that permission again.</p>
+<p>And just like in the normal browser, permissions are separated by origin. If App A is granted permission to use Geolocation, this does not mean that all origins running in App A have the permission to use Geolocation. If App A opens an <code>&lt;iframe&gt;</code> to <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, then <a href="http://docs.google.com"><span class="external free">http://docs.google.com</span></a> still has to ask the user for permission before geolocation access is granted.</p>
+<h3 id="Browser_API_Sandbox">Browser API Sandbox</h3>
+<p>To additionally secure applications that open a large set of URLs, such as browsers, we have added a <em>browserContent flag</em>. The browserContent flag allows each app to have not one, but two sandboxes: one for the app itself, and one for any "web content" that it opens. For example:</p>
+<p>Say that the MyBrowser app is loaded from the <a class="external free" href="https://mybrowser.com" rel="nofollow">https://mybrowser.com</a> domain. This is the domain the scripts and resources are loaded within. The scripts and resources
+ <i>
+ belong</i>
+ to this domain.</p>
+<p>Now, if a page in this app creates an <code>&lt;iframe mozbrowser&gt;</code>, a different sandbox is created and used for this <code>&lt;iframe&gt;</code>, which is different from the sandbox used by the app. So for example if this <code>&lt;iframe&gt;</code> is navigated to <a class="external free" href="https://mybrowser.com" rel="nofollow">https://mybrowser.com</a>, it will result in different cookies being used inside the <code>&lt;iframe mozbrowser&gt;</code>. Likewise, the contents inside the <code>&lt;iframe mozbrowser&gt;</code> will see different IndexedDB and localStorage databases from the ones opened by the app.</p>
+<p>This also applies if the MyBrowser app wants to create integration with, for example, Google Maps to implement location-based browsing. If the app opens an <code>&lt;iframe&gt;</code> to <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, it will receive a set of cookies for the <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a> website. If the user then navigates inside the <code>&lt;iframe mozbrowser&gt;</code> containing <a class="external free" href="http://maps.google.com" rel="nofollow">http://maps.google.com</a>, this will use different cookies and different permissions to the top level app.</p>
+<p>Another example where this is useful is in a Yelp-like app. Yelp has the ability to visit a restaurant's website directly in the app. By using <code>&lt;iframe mozbrowser&gt;</code> to open the restaurant website, the Yelp app ensures that the restaurant website can't contain an <code>&lt;iframe&gt;</code> pointing back to Yelp's app (which points to <a class="external free" href="http://yelp.com" rel="nofollow">http://yelp.com</a>). If it does, the website will only receive the Yelp website, rather than the Yelp app. So there is no way that the restaurant website can mount an attack against the app since the contained Yelp website won't share any permissions or data with the Yelp app.</p>
+<h2 id="Resumo_da_segurança_de_aplicativos">Resumo da segurança de aplicativos</h2>
+<p>A tabela abaixo resume os diferentes tipos de aplicativos no Firefox OS, seus formatos,  e os processos de instalação e atualização para aplicativos web abertos rodando no Firefox OS.</p>
+<table>
+ <caption>
+ Tipos de aplicativos web</caption>
+ <thead>
+ <tr>
+ <th scope="col">Tipo</th>
+ <th scope="col">Distribuição</th>
+ <th scope="col">Modelo de permissões</th>
+ <th scope="col">Instalação</th>
+ <th scope="col">Atualização</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>Web</td>
+ <td>Hospedados ou empacotados</td>
+ <td>Permissões mais leves que não tenham perigo de exposição a conteúdo web não validado.</td>
+ <td>Instalados de qualquer local</td>
+ <td>Podem ser atualizadas de forma transparente ao usuário ou explicitamente através de um <em>marketplace</em>, dependendo de onde o aplicativo foi instalado e o metodo de distribuição.</td>
+ </tr>
+ <tr>
+ <td>Privilegiado</td>
+ <td>Empacotados e obrigatoriamente assinados</td>
+ <td>APIs privilegiadas requerem a validação e autenticação do aplicativo.</td>
+ <td>Instalados somente de um <em>marketplace</em> confiável</td>
+ <td>Atualizados através de um <em>marketplace</em> confiável, o usuário é solicitado a aprovar o download e instalação de atualizações manualmente.</td>
+ </tr>
+ <tr>
+ <td>Interno (Certificado)</td>
+ <td>Empacotados</td>
+ <td>APIs potencialmente perigosas e poderosas não disponíveis para aplicativos de terceiros.</td>
+ <td>Pre-Instalados no dispositivo</td>
+ <td>Atualizadas somente através de atualizações do sistema como um todo.</td>
+ </tr>
+ </tbody>
+</table>
+<div class="note">
+ <p><strong>Nota</strong>: Apezar de aplicativos web poderem ser instalados de qualquer site ou marketplace, Na versão 1.0 do Firefox OS os aplicativos privilegiados somente podem ser instalados do marketplace da Mozilla, isso se deve ao fato que o suporte para multiplos marketplaces confiáveis ainda não está terminado.</p>
+</div>
+<p> </p>