Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

Présentation de la sécurité de Firefox OS

Ce document donne un aperçu du cadre de la sécurité de Mozilla Firefox OS, qui est conçu pour protéger les appareils mobiles contre les menaces de la plateforme, des applications et des données. Dans le Firefox OS, Mozilla a mis en place un modèle de sécurité globale, intégrée et multicouche qui offre une protection best-of-breed contre les risques de sécurité pour les téléphones mobiles.

Sécurité de la plate-forme

La plate-forme Firefox OS utilise un modèle de sécurité multi-couches qui est conçu pour atténuer les risques d'exploitation à tous les niveaux. Une première ligne de contre-mesures combinée avec une stratégie de sécurité en profondeur offrent une protection complète contre les menaces.

L'architecture sécurisée

Le système d'exploitation Firefox OS connecte des applications Web au matériel sous-jacent. C'est une technologie de pile intégrée, composée des niveaux suivants:

  • Gaia: La suite d'applications Web qui composent l'expérience utilisateur (les applications se composent de HTML5, CSS, JavaScript, les images, les médias, et ainsi de suite).
  • Gecko: La couche d'exécution d'application qui fournit le cadre pour l'exécution de l'application, et met en œuvre les API Web utilisées pour accéder à des fonctions dans l'appareil mobile.
  • Gonk: Le noyau Linux sous-jacent, les bibliothèques du système, le micrologiciel et les pilotes de périphériques que tout ce qui fonctionne au-dessus.
  • Le dispositif mobile: Le téléphone mobile fonctionnant avec Firefox OS.

Gecko est le contrôleur d'accès qui applique les politiques de sécurité destinées à protéger l'appareil mobile d'une mauvaise utilisation. La couche Gecko agit comme intermédiaire entre les applications web (à la couche Gaia) et le téléphone. Gonk offre des caractéristiques du matériel du téléphone mobile sous-jacent directement à la couche Gecko. Les applications Web accèdent à des fonctionnalités du téléphone mobile uniquement via les API Web, et seulement si Gecko permet la demande d'accès il n'y a pas d'accès direct, pas de «porte arrière» dans le téléphone. Gecko applique des autorisations et empêche l'accès aux demandes non autorisées.

le déploiement du système

Firefox OS est livré installé sur un téléphone intelligent. L'image du système d'origine est créée par une source de confiance connuehabituellement le OEM (Original Equipment Manufacturer) de l'appareil qui est responsable de l'assemblage, la construction, les tests et la signature numérique de l'emballage de distribution.

Les mesures de sécurité sont utilisées dans la pile de technologie. Les privilèges du système de fichiers sont appliqués par les listes de contrôle d'accès de Linux (les ACL). Les applications du système sont installées sur un support de stockage qui est en lecture seule (sauf pendant les mises à jour, quand il est temporairement en lecture-écriture); généralement il n'y a que les zones contenant le contenu de l'utilisateur qui peuvent être en lecture-écriture. Divers composants dans le matériel de l'appareil sont équipés de protections qui sont mises en œuvre par défaut en tant que pratique standard de l'industrie - les fabricants de puces, par exemple, employent des techniques de durcissement pour réduire les vulnérabilités. La plate-forme de base (Gecko et Gonk) est durcie pour renforcer sa défense contre les menaces potentielles, et les caractéristiques de durcissement du compilateur sont utilisées le cas échéant. Pour plus de détails, voir Runtime security.

Mises à jour de Système Sécurisé

Les mises à jour ultérieures et les correctifs de la plate-forme Firefox OS sont déployés en utilisant un processus Mozilla sécurisé qui garantit l'intégrité continue de l'image du système sur le téléphone mobile. La mise à jour est créée par une entité connue, une source de confiance - habituellement le OEM de l'appareil - qui est responsable de l'assemblage, la construction, les tests et la signature numérique du paquet de mise à jour.

Les mises à jour du système peuvent concerner tout ou une partie de la pile Firefox OS. Si des changements à Gonk sont inclus dans la mise à jour, cependant FOTA (Firmware Over The Air) est le processus d'installation utilisé. Les mises à jour FOTA peuvent également inclure toute autre partie de la pile de Firefox OS, y compris la gestion de l'appareil (FOTA, firmware / drivers), la gestion des paramètres (paramètres de Firefox OS), les mises à jour de sécurité, Gaia, Gecko, et d'autres correctifs.

Les mises à jour qui ne comportent pas Gonk peuvent être effectuées en utilisant la mise à jour de l'utilitaire système Mozilla. Firefox OS utilise le même framework de mise à jour, les mêmes processus et le même format Mozilla ARCHIVE (MAR) (utilisé pour les packages de mise à jour) que le produit Firefox Desktop.

Un service intégré dans la mise à jour — lequel peut être fourni par le fabricant  sur le téléphone mobile vérifie périodiquement les mises à jour système. Une fois un paquet système devient disponible et est détecté par le service de mise à jour, l'utilisateur est invité à confirmer l'installation. Avant que les mises à jour soient installées sur l'appareil mobile, le stockage de l'appareil est vérifié pour un espace suffisant pour appliquer la mise à jour, et la distribution est vérifiée pour:

  • Update origin (vérifier le protocole de localisation de la source: domaine: port de la mise à jour du système et manifeste)
  • File integrity (SHA-256 vérifie de hachage)
  • Code signature (vérification de cetificat)

Les mesures de sécurité suivantes sont utilisées au cours du processus de mise à jour:

  • Mozilla recommande et espère que les mises à jour sont récupérées via une connexion SSL.
  • Une vérification cryptographique forte est nécessaire avant d'installer un paquet de firmware.
  • La mise à jour complète doit être téléchargée dans un emplacement spécifique et sécurisé avant le début du processus de mise à jour.
  • Le système doit être dans un état sécurisé lorsque le processus de mise à jour démarre, sans les applications en marche.
  • Les clés doivent être stockées dans un emplacement sécurisé sur le dispositif.

Des contrôles rigoureux sont en mis place pour veiller à ce que la mise à jour est appliquée correctement sur le téléphone mobile.

Note: Pour plus d'informations sur la façon dont les mises à jour fonctionnent et comment créer et distribuer des mises à jour, lire Création et application des paquets de mise à jour de Firefox OS.

Securité des applications

Firefox OS utilise une stratégie de sécurité de défense en profondeur pour protéger le téléphone mobile des applications intrusives ou malveillantes. Cette stratégie utilise une variété de mécanismes, y compris les niveaux d'autorisation implicites basés sur un modèle de confiance de l'application, l'exécution en sandbox au moment de l'exécution, d'un accès au matériel sous-jacent du téléphone mobile uniquement par API, un modèle d'autorisation robuste, et les processus d'installation et de mise à jour sécurisé. Pour les détails techniques, faire référence à Application security.

Dans Firefox OS, toutes les applications sont des applications Web - programmes écrits en utilisant HTML5, JavaScript, CSS, les médias, et d'autres technologies Web ouvertes (les pages en cours d'exécution dans le navigateur ne sont pas visées; que les applications Web dans ce contexte). Parce qu'il n'y a d'application binaires  («natives») installées par l'utilisateur, tous les accès au système sont strictement effectués via les API Web. Même l'accès au système de fichiers ne se produit que par le biais des API Web et une base de données SQLite back-end - il n'y a pas d'accès direct entre les applications et les fichiers stockés sur la carte SD.

Firefox OS limite et fait respecter la portée des ressources qui peuvent être consultées ou utilisées par une application, tout en soutenant un large éventail d'applications avec différents niveaux d'autorisationMozilla a mis en place un contrôle serré sur ce type d'applications qui peuvent accéder aux API. Par exemple, seules les applications certifiées (livrées avec le téléphone) peuvent avoir accès à l'API de téléphonie.

Cela empêche une situation, par exemple, dans laquelle une application arbitraire tiers est installée, compose un numéro de téléphone pay-per-use (900 et 910), et engrange une grosse facture de téléphone cellulaire.

D'autres applications OEM pourraient cependant être sélectionnées pour avoir accès à l'API de téléphonie. Par exemple, un opérateur pourrait fournir une application de systèmes de gestion qui permet à un client de gérer sont compte, y compris la possibilité de téléphoner au service client ou le service d'aide de l'opérateur directement.

 

Applications approuvées et non approuvées

 

Firefox OS catégorise les applications selon les types suivants:

Type Niveau de confiance Description
Certifié Très fiable Les applications du système qui ont été approuvées par l'opérateur ou l'OEM (en raison de risques de corruption de l'appareil ou un risque pour la fonctionnalité critique). Les applications et services système uniquement; non destinées à des applications tierces.
Cette désignation est réservée à un petit nombre d'applications critiques. Exemples: SMS, Bluetooth, appareil photo, horloge système, la téléphonie et le numéroteur par défaut (pour que les services d'urgence soient toujours accessibles).
Privilégié Fiable Des applications tierces qui ont été examinées, approuvées et signées numériquement par un marché autorisé.
Web (tout le reste)applique Non fiable Contenu Web régulier. Comprend les applications installées (stockées sur le téléphone mobile) et des applications hébergées (stockées à distance, avec seulement une application manifeste stockée sur le téléphone mobile). Le manifeste pour les applications hébergées peut être obtenu grâce à un marché.

Le niveau de confiance d'une application détermine, en partie, sa capacité à accéder aux fonctionnalités de téléphone mobile.

  • Les applications certifiées ont des autorisations à la plupart des opérations de APIs Web.
  • Les applications privilégiées ont des autorisations à un sous-ensemble des opérations des APIs Web qui sont accessibles aux applications certifiées.
  • Les applications non fiables ont des autorisations à un sous-ensemble des opérations des API Web accessibles aux applications privilégiées - seules les API Web qui contiennent des mesures d'atténuation de sécurité suffisantes pour être exposées à du contenu Web non sécurisé.

Certaines opérations, telles que l'accès au réseau, sont supposées être une autorisation implicite pour toutes les applications. En général, plus l'opération est sensible (par exemple, composer un numéro de téléphone ou accéder à la liste de contacts), plus le niveau de confiance de l'application nécessaire pour l'exécuter est élevé.

Remarque: pour plus d'informations sur les API disponibles et leurs niveaux d'autorisation, consulter App permissions.

Principe de la Moindre partie de Permissions

Pour les applications Web, le framework de sécurité de Firefox OS suit le principe des moindres autorisations: commencer avec les autorisations minimales absolues, puis accorder sélectivement des privilèges supplémentaires que lorsque cela est nécessaire et raisonnable. Par défaut, une application commence avec de très faibles autorisations, ce qui est comparable au contenu Web non sécurisé. Si l'application effectue des appels API Web qui nécessitent des autorisations supplémentaires, il doit énumérer ces autorisations supplémentaires dans son manifeste (décrit plus loin dans ce document). Gecko envisagera d'accorder l'accès de l'API Web à une application que si les privilèges applicables sont priés explicitement dans son manifeste. Gecko accordera l'autorisation demandée uniquement si le type de l'application Web (certifiée, confiance, ou Web) est suffisamment qualifié pour l'accès.

Processus d'Examen pour Applications Privilégiés dans le Marché

Pour qu'une application devienne privilégée, le fournisseur de l'application doit la soumettre pour examen sur le Marketplace. Le Marketplace soumet l'application dans un processus de révision du code rigoureux: vérification de son authenticité et de l'intégrité, veiller à ce que les autorisations demandées sont utilisées aux fins indiquées (dans la justification de l'autorisation), vérifier que l'utilisation des autorisations implicites est appropriée, et de valider que toutes les interfaces entre le contenu de l'application privilégiée et contenu externe non privilégié ont les mesures d'atténuation appropriées pour prévenir des attaques d'élévation de privilèges. Le Marketplace a la responsabilité de veiller à ce que l'application web ne se comportera pas malicieusement avec les autorisations qu'il est accordée.

Après q'une application est passé cet examen, elle est approuvée pour utilisation, le manifeste de l'application est signé numériquement par le Marketplace, et il est disponible pour les utilisateurs mobiles. La signature garantit que, si la boutique en ligne a été en quelque sorte piratée, le pirate ne pouvait pas sortir avec l'installation de contenu arbitraire ou du code malveillant sur les téléphones des utilisateurs. En raison de ce processus de vérification, Firefox OS donne des applications privilégiées obtenues à partir du Marketplace un plus haut degré de confiance tous les jours que de contenu Web.

 

Remarque: pour en savoir plus à propos de Marketplace, y compris le marché de Firefox, aller à la zone du Marketplace.

 

Applications empaquetées et hébergées

Les applications pour Firefox OS peuvent être soit empaquetées (stockées sur le téléphone mobile) ou hébergées (stockées sur un serveur web distant, avec juste un manifeste stocké sur le téléphone mobile). Il ya quelques différences dans la façon dont la sécurité est gérée pour chaque. Néanmoins, les applications empaquetées et hébergées sont toutes deux soumises à l'application sandboxing, qui est décrite plus loin dans ce document.

Note: Vous pouvez en savoir plus sur les applications hébergées et empaquetées à Auto-publication d'application

Applications empaquetées

Une application empaquetée se compose d'un fichier ZIP contenant des ressources d'application (HTML5, CSS, Javascript, images, médias), ainsi que d'un manifeste qui fournit une liste explicite des actifs et leurs valeurs de hachage correspondant. Applications certifiées et privilégiées doivent être empaquetées parce que le manifeste de l'application doit être signé numériquement. Quand un utilisateur obtient une application incluse dans le paquet, le fichier ZIP téléchargé sur le téléphone mobile, et le manifeste est lu à partir d'un emplacement connu à l'intérieur du fichier ZIP. Pendant le processus d'installation, les actifs d'applications sont dignes de confiance et restent stockés localement dans le paquet. Toutes les autorisations explicites sont demandées lors de l'exécution, montrant à l'utilisateur les intentions d'utilisation des données de l'application, et sont persistées par défaut.

Pour faire référence à des ressources d'applications dans une application empaquetée, l'URL commence par app: en utilisant le format suivant:

app://identifier/path_within_zipfile/file.html

où app:// représente le point de montage du fichier ZIP, et l'identifiant est un UUID qui est généré lorsque l'application est installée sur le téléphone mobile. Ce mécanisme garantit que les ressources appelées avec app:URL contenues dans le fichier ZIP. Le chemin au sein d'une app: est relative, donc des liens relatifs à des ressources dans le fichier ZIP sont autorisés.

Alors que les applications empaquetées sont principalement destinées à être utilisées pour les applications certifiées ou privilégiées, les applications web régulières peuvent aussi être empaquetées. Cependant, elles ne gagnent pas d'augmentation de l'accès en confiance ou autorisations simplement parce qu'elles sont empaquetées.

Applications hébergées

Les applications hébergées sont situées sur un serveur Web et chargées via HTTP. Seulement le manifeste de l'application est stocké sur le téléphone mobile. Tout le reste est stocké à distance. Certaines APIs sont disponibles uniquement aux applications privilégiées et certifiées, ce qui nécessite que l'application soit empaquetée en raison des exigences de signature. Par conséquent, une application hébergée n'aura pas accès à l'une des API Web qui nécessitent un statut d'application privilégiée ou certifiée.

Du point de vue de la sécurité, des applications hébergées fonctionnent très bien comme des sites Web normaux. Une application hébergée est chargée en invoquant un codage en dur, URL pleinement qualifiée qui pointe vers la page de démarrage dans le répertoire racine de l'application sur le serveur Web. Une fois une application hébergée est chargée, le téléphone mobile pointe vers des pages en utilisant les mêmes URL qui sont utilisées lors de la navigation sur le site web.

Manifeste d'une Application

Le manifeste d'une application Open Web contient des informations dont le navigateur Web a besoin pour interagir avec une application. Un manifeste est un fichier JSON avec (au moins) un nom et une description pour l'application. Pour plus de détails, reportez-vous à FAQs about app manifests.

Exemple de Manifeste

Les lignes de code suivantes montrent un exemple de manifeste avec les réglages de base seulement:

{
  "name": "My App",
  "description": "My elevator pitch goes here",
  "launch_path": "/",
  "icons": {
    "128": "/img/icon-128.png"
  },
  "developer": {
    "name": "Your name or organization",
    "url": "https://your-homepage-here.org"
  },
  "default_locale": "en"
}

Paramètres de sécurité dans le Manifeste de l'Application

Le manifeste peut également contenir d'autres paramètres, y compris les paramètres de sécurité suivants:

 

Champs

Description

permissions

Permissions requises par l'application. Une application doit énumérer toutes les API Web qu'elle entend utiliser qui nécessite l'autorisation de l'utilisateur. La plupart des autorisations ont du sens pour les applications privilégiées ou des applications certifiées, mais pas pour les applications hébergées. Propriétés par API:

  • Description: Une chaîne spécifiant l'intention derrière la demande d'utilisation de cette API. Requis
  • Accès: Une chaîne spécifiant le type d'accès requis pour l'autorisation. Les autorisations implicites sont accordées lors de l'installation. Requis pour seulement quelques API. Les valeurs acceptées: read, readwrite, readcreate, et createonly.

installs_allowed_from

L'origine de l'application; peut être au singulier ou un tableau des origines (scheme+unique hostname) qui sont autorisés à déclencher l'installation de cette application. Permet aux fournisseurs d'applications de restreindre les installations à partir de seulement l'autorisation du Marketplace (https://marketplace.firefox.com/).

csp

Content Security Policy (CSP). Appliquée à toutes les pages chargées dans l'application. Utilisé pour durcir l'application contre les bugs qui pourraient permettre à un attaquant d'injecter du code dans l'application. Si non spécifié, les applications privilégiées et certifiées ont des réglages système par défaut. Syntaxe:
https://developer.mozilla.org/en-US/docs/Apps/Manifest#csp

Notez que cette directive ne peut augmenter le CSP appliqué. Vous ne pouvez pas l'utiliser, par exemple, de réduire le CSP appliqué à une application privilégiée.

type

Type d'application (web, privilegiée, or certifiée).

 

Firefox OS exige que le manifeste soit servi avec un type mime spécifique (application / x-web-app-manifeste + JSON) et à partir du même nom d'hôte pleinement qualifié (origine) à partir de laquelle l'application est servie. Cette restriction est assouplie lorsque l'application manifeste (et donc l'application manifeste) est de la même origine avec la page qui a demandé l'application à installer. Ce mécanisme est utilisé pour assurer qu'il est impossible de tromper un site Web en accueillant un manifeste d'application.

 

Exécution sandbox

 

Cette section décrit l'application et l'exécution sandboxes.

Application Sandbox

Le framework de sécurité de Firefox OS utilise sandboxing comme une stratégie de défense en profondeur pour atténuer les risques et protéger le téléphone mobile, la plate-forme, et les données. Sandboxing est une façon de mettre les frontières et les restrictions autour d'une application en cours d'exécution. Chaque application fonctionne dans son propre espace de travail et a uniquement accès aux API Web et les données dont elle a l'accès, ainsi que les ressources associées à cet espace de travail (bases de données IndexedDB, biscuits, stockage en mode déconnecté, et ainsi de suite).

La figure suivante donne un aperçu de ce modèle de sécurité.

 

 

 

En isolant chaque application, son impact est contenue dans son propre espace de travail et ne peut pas interférer avec quoi que ce soit (comme d'autres applications ou leurs données) en dehors de cet espace de travail.

Execution Sandbox

B2G (Gecko) s'exécute dans un processus de système hautement privilégiée qui a accès à des fonctionnalités matérielles dans le téléphone mobile. A l'exécution, chaque application fonctionne à l'intérieur d'un environnement d'exécution qui est un processus enfant du processus système de B2G. Chaque processus enfant a un ensemble restreint de privilège OS - par exemple, un processus enfant ne peut pas lire ou écrire des fichiers arbitraires sur le système de fichiers directement. Un accès privilégié est fourni via des API Web, qui sont médiées par le processus B2G mère. Le parent s'assure que, quand un processus enfant demande une API privilégiée, il dispose de l'autorisation nécessaire pour effectuer cette action.

Les applications communiquent uniquement avec le processus de base B2G, pas avec d'autres processus ou applications. Les applications ne fonctionnent pas indépendamment de B2G, ne peuvent ouvrir des applications de l'autre. La seule «communication» entre les applications est indirecte (par exemple, quand une application établit une alarme système et une autre application déclenche une notification du système à la suite de celui-ci), et est médiée par le processus B2G.

Hardware Access Only via the Web API

 

Les applications Web ont un seul point d'entrée pour accéder aux fonctionnalités de téléphonie mobile: les API Web de Firefox OS, qui sont mises en œuvre dans Gecko. Gecko fournit la seule porte d'entrée de l'appareil mobile et les services sous-jacents. La seule façon d'accéder à la fonctionnalité matérielle du périphérique est de faire un appel d'API Web. Il n'y a aucune API "native" et il n'y a pas d'autres façons (pas de «portes arrières") pour contourner ce mécanisme et d'interagir directement avec le matériel ou pénétrer dans la couche logicielle de bas niveau.

 

Infrastructure de sécurité

La figure suivante montre les composantes du framework de sécurité de Firefox OS:

  • Permission Manager: la passerelle à l'accès aux fonctionnalités de l'API Web, qui est le seul accès au matériel sous-jacent.
  • Access Control List: Matrice des rôles et des autorisations requises pour accéder à la fonctionnalité de l'API Web.
  • Credential Validation: l'authentification des applications / utilisateurs.
  • Permissions Store: Ensemble de privilèges requis pour accéder aux fonctionnalités de l'API Web.

Gestion des autorisations et mise en application

La sécurité de Firefox OS est conçue pour vérifier et appliquer les autorisations accordées à des applications web.

Le système accorde une autorisation particulière à une application que si le contenu lui demande, et seulement si elle a les autorisations appropriées demandées dans le manifeste de l'application. Certaines autorisations exigent en outre l'autorisation de l'utilisateur, qui est invité à accorder l'autorisation (comme dans le cas d'une application demandant l'accès à l'emplacement actuel de l'utilisateur). Ce framework app-centrique fournit un contrôle plus granulaire sur les autorisations que les approches de rôle centré traditionnelles (dont les rôles individuels sont affectés chacun un ensemble d'autorisations).

Une API Web a donné un ensemble d'actions et d'écouteurs. Chaque API Web a un niveau d'autorisation requis. Chaque fois une API Web est appelé, Gecko vérifie les exigences d'autorisation (rôle de consultation) basées sur:

  • Permissions associées pour appeler l'application (comme spécifié dans le manifeste et basé sur le type d'application.)
  • Autorisations requises pour exécuter l'opération demandée (appel API Web.)

Si la demande ne satisfait pas aux critères d'autorisation, alors Gecko rejette la demande. Par exemple, des applications non approuvées ne peuvent pas exécuter des API Web qui sont réservées pour des applications de confiance.

Inviter les utilisateurs pour Permissions

En plus des autorisations qui sont implicitement associées aux applications web, certaines opérations nécessitent l'autorisation explicite de l'utilisateur avant de pouvoir être exécutées (par exemple, "l'application web peut avoir accès à votre appareil photo?"). Pour ces opérations, les applications web sont tenues de spécifier, dans leur manifeste, leur justification pour exiger cette autorisation. Cette intention d'utilisation des données informe les utilisateurs sur ce que l'application Web a l'intention de faire avec ces données si l'autorisation est accordée, ainsi que tout risque impliqué. Cela permet aux utilisateurs de prendre des décisions éclairées et de garder le contrôle sur leurs données.

Processus de mise à jour sécurisé d'une Application

 

Pour les mises à niveau d'applications et des correctifs à une application privilégiée, les fournisseurs d'applications soumettent l'archive mis à jour pour l'autorisation du Marketplace, où elle est examinée et, si elle est approuvée, signée et mise à la disposition des utilisateurs. Sur les appareils OS Firefox, une application utilitaire de une mise à jour  vérifie périodiquement des mises à jour de l'application. Si une mise à jour est disponible, l'utilisateur est alors interroger s'ils veulent l'installer. Avant qu'une mise à jour soit installée sur l'appareil mobile, le paquet est vérifié:

  • Origine de la mise à jour (vérifier le protocole de localisation de la source: domaine: port de la mise à jour et manifeste)
  • Intégrité du fichier (SHA-256 vérification du hachage)
  • Signature de code (certificat de vérification contre une racine de confiance)

Des contrôles rigoureux sont mises en place pour veiller à ce que la mise à jour soit appliquée correctement sur le téléphone mobile. Le package de mise à jour complète doit être téléchargé dans un emplacement spécifique et sécurisé avant le début du processus de mise à jour. L'installation ne remplace pas les données des utilisateurs.

NotePour plus d'informations sur les mises à jour d'applications, lisez Updating apps.

Securité de l'appareil (Hardware)

Les mécanismes de sécurité pour le matériel de l'appareil mobile sont généralement traitées par l'OEM. Par exemple, un OEM peut offrir une SIM (Subscriber Identity Module) serrures à carte, avec PUK (PIN Unlock Key) codes pour débloquer les cartes SIM qui sont devenus verrouillé les entrées suivantes de code PIN erroné. Contactez votre OEM pour plus de détails. Firefox OS ne permettent aux utilisateurs de configurer des codes d'accès et les écrans de délai d'attente, qui sont décrits dans la section suivante.

Sécurité des données

Les utilisateurs peuvent stocker des données personnelles sur leur téléphone qu'ils veulent garder privées, y compris les contacts, les informations financières (bancaires et les détails de cartes de crédit), les mots de passe, des calendriers, et ainsi de suite. Firefox OS est conçu pour protéger contre les applications malveillantes qui peuvent voler, exploiter, ou de détruire des données sensibles.

Code d'accès et Ecran de temporisation

Firefox OS permet aux utilisateurs de définir un code d'accès à leur téléphone mobile afin que ceux qui fournissent le code d'accès puissent utiliser le téléphone. Firefox OS fournit également un écran de temporisation qui est affiché après une période d'inactivité configurable depuis le téléphone , nécessitant une authentification de mot de passe avant de reprendre l'utilisation du téléphone.

Données sandbox

Comme décrit précédemment, les applications sont sandbox à l'exécution. Cela empêche les applications d'accéder aux données qui appartient à d'autres applications à moins que les données soient explicitement partagées, et que l'application dispose des autorisations suffisantes pour y accéder.

Données sérialisées

Les applications Web n'ont pas un accès direct en lecture et écriture au système de fichiers. Au lieu de cela, tous les accès au stockage se produisent uniquement via les API Web. Les API Web lisent à partir, et écrivent sur, le stockage via une base de données SQLite intermédiaire. Il n'y a pas d'accès E / S directe. Chaque application possède son propre stockage de données, qui est sérialisé sur le disque par la base de données.

 

Destruction de données

Quand un utilisateur désinstalle une application, toutes les données (cookies, localStorage, IndexedDB, etc.) associées à cette application sont supprimées.

Privacy

Mozilla est engagé à protéger la vie privée de l'utilisateur et les données utilisateur en fonction de ses principes de confidentialité (https://www.mozilla.org/privacy/), qui découlent du Manifeste Mozilla (https://www.mozilla.org/about/manifesto.html). La politique de confidentialité Mozilla Firefox décrit comment Mozilla collecte et utilise des informations sur les utilisateurs du navigateur Web Mozilla Firefox, y compris ce que Firefox envoie aux sites Web, ce que Mozilla fait pour sécuriser les données, les pratiques de données de Mozilla, et ainsi de suite. Pour plus d'informations, voir:

Firefox OS met en œuvre ces principes en mettant le contrôle des données de l'utilisateur dans les mains de l'utilisateur, qui doit décider où cette information est personnelle va. Firefox OS offre les fonctionnalités suivantes:

  • option Ne pas suivre
  • possibilité de désactiver les cookies du navigateur Firefox
  • possibilité de supprimer l'historique de navigation Firefox OS

Étiquettes et contributeurs liés au document

 Contributeurs à cette page : jwhitlock, qwincy_p, MozLand, tbjac, Goofy
 Dernière mise à jour par : jwhitlock,