Domovská stránka Prehľadávať Pomoc
Prihlásiť sa
desktopd
/
zombie-navigator
Pridať medzi pozorované 2
Hviezda 0
Fork 0
Súbory Issues 1 Pull requesty 0 Wiki
Branch: master
Branche Tagy
zombie-navig...
/
Design.markdown

Design.markdown 4.8 KB
Permanentný odkaz História Raw

Zombie Navigator Design

TODO

  • Develop a postprocessor for jpm-built packages (PKZIP-based)
    • In what language?
    • Optimization and reproducibility "fixes"
    • With Google's Zopfli deflate compressor
    • Bundle Zopfli and postprocessor for bit-to-bit reproducible builds
  • Try not to bloat the codebase
  • Unified policy manager for scripts
  • Create a "Running Scripts" page?
  • Make sure the API is always reliable
    • Develop a complete testsuite
  • Per-script user controls??
  • 0.6: Remove JSDoc
    • We need a minimalistic approach to this (generated docs)
    • Write a script to generate the documentation to embed in the package
  • 0.6: Implement a generic downloader (No interaction permitted: just downloading to the default directory, unlike XHR) (only possible with non-SDK Downloads.jsm ?)
    • The functionalities of Downloads.jsm should be made available in SDK, really. Not because they want no more "downloaders" in AMO?
  • Reset preferences on uninstall (so that the next installation will be "fresh")?
  • Use NodeJS for build scripts? (but remember we hate npm and semver.org)
  • Find any problems related to e10s (should be fixed by SDK team)
  • Research: more sophisticated management of scripted browser session/tabs
    • Bind each script to the respective status window
    • Open a window before runnning script based on the policy
    • Close the window -> terminate the script
  • Zombie Navigator Studio -- A graphical frontend and script collection manager for Zombie Navigator
    • Develop GUI-oriented features in this project instead

Coding policy

  • Addon: No dependencies outside Firefox
  • Try to be as pure-SDK as feasible
  • No new features in Beta or Stable (branched out)
  • Make it unlikely to break in future Firefox
  • Tiny code base and minimum-sized build
  • Feel free to use ES6 as implemented in Firefox 38+ (let/const are OK but be careful)
  • Use only High-Level SDKs for web contents
  • Use wrappers for SDK access (Addon SDK Abstraction Wrapper in platform/)
    • Avoid duplicate codes and increase maintenability to produce more secure codes
    • Make it easier to port the addon to possible future platforms
    • Restrict what the addon code can do with the SDK
    • Isolate codes to make it substantially harder to exploit the addon
    • Clarify the privileges of each module
  • Plain SDK access should be forbidden throughout the addon (except wrappers)

Development policy

  • Localization is of a low priority
  • This addon is of the kind where backword/forward compatibility matters
  • Stable API

Firefox compatiblity

  • Support the latest ESR release and later (normal) release versions
  • No breaks in Beta
  • Fix problems in Nightly and Aurora
  • Support the previous ESR release until becoming obsolete
  • Support GNU/Linux i386 and x86_64
  • Support Debian Iceweasel (stable)
  • Support GNU Icecat
  • Try to fix issues with other distribution packages
  • Accommodate customized Firefox-based products
  • No support planned for Fennec
  • No official support for Microsoft Windows (may work)
  • No official support for Apple OS/X (may work)
  • Will NOT support the coming "Firefox for iOS," which is not much of Firefox
  • Try to support FreeBSD's Linux emulation
  • May support GNU/Hurd once it becomes possible in the future
  • Now e10s seems to work (depends on SDK's reliable e10s support)

Addon behavior

  • No action unless told to do something
  • No visible UI outside about:addons if not requested
  • No network access by default (required resources are all packed into the addon package)

Security

  • Zombie scripts cannot control the whole browser
  • Zombie scripts have no direct access to local file system
  • Zombie scripts can only control or otherwise access the tabs they opened
  • Zombie scripts cannot save persistent data to the browser (beside history, which is handled by user or Private Browsing)
  • Thus no chrome access is allowed for Zombie scripts
  • Also no unrestricted or raw access to Addon SDK
  • Security may partially break if the user messes up the automated browser manually

Coding styles

  • Care about consistency of coding styles
  • UTF-8 as the preferred text encoding whenever possible (ASCII is a UTF-8 subset)
  • Indentations use a single tab (U+0009) and each represents 4 spaces (Space matters)

Branding

We named this program "Zombie Navigator" because it effectively turns Firefox into an automated "zombie" web browser. "Zombie scripts", which run inside a secure sandbox navigate Firefox!

The icon says "Web Browser" in Arabic. Just that. Maybe too simple. But we do not invest much in visual design.

Firefox is a registered trademark of the Mozilla Foundation. The term "Firefox" in this product, however, may also mean rebranded products derived from the official Firefox.

Versioning