https://wiki.mozilla.org/api.php?action=feedcontributions&user=Sidstamm&feedformat=atomMozillaWiki - User contributions [en]2024-03-28T12:01:07ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=Modules/Core&diff=1108191Modules/Core2015-12-02T20:33:44Z<p>Sidstamm: Updating owner and peers of Content Security</p>
<hr />
<div><noinclude><br />
'''Do not edit this page''' unless either:<br />
<br />
# you are a module owner who is:<br />
#* altering the list of peers in your module<br />
#* adding or removing a sub-module<br />
#* changing the owner of one of your sub-modules; or<br />
# you have agreed a change of owner or module addition/deletion with the Module Ownership Module group, probably via [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:bolterbugz@gmail.com David Bolter], [mailto:ginn.chen@oracle.com Ginn Chen], [mailto:trev.saunders@gmail.com Trevor Saunders], [mailto:marco.zehe@googlemail.com Marco Zehe] <br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted)<br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI) and CORS.<br />
|owner=[mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|peers=[mailto:francois@mozilla.com François Marier], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:mozilla@sidstamm.com Sid Stamm] <br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=[mailto:mchew@mozilla.com Monica Chew]<br />
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:jst@mozilla.org Johnny Stenback], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-tech-layout<br />
|source_dirs=docshell/, uriloader/, webshell/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Device Storage<br />
|description=Support for the device storage API<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands], [mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:dougt@mozilla.com Doug Turner]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/devicestorage/, dom/interfaces/devicestorage/<br />
|url=https://developer.mozilla.org/en-US/docs/WebAPI/Device_Storage<br />
|components=Core::DOM: Device Interfaces<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:bent@mozilla.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri (still active, but slower to respond than previously)], [mailto:me@kylehuey.com Kyle Huey], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML<br />
}}<br />
<br />
{{Module<br />
|name=Event Handling<br />
|description=DOM Events and Event Handling <br />
|owner=[mailto:olli@pettay.fi Olli Pettay], [mailto:masayuki@d-toybox.com Masayuki Nakano]<br />
|group=dev-platform<br />
|source_dirs=dom/events and event handling related code elsewhere <br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM: Events, Core::Event Handling<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=<br />
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-embedding<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs, Core::Embedding: ActiveX Wrapper, Core::Embedding: GRE Core, Core::Embedding: GTK Widget, Core::Embedding: MFC Embed, Core::Embedding: Mac, Core::Embedding: Packaging<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:dougt@mozilla.com Doug Turner]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen], [gkeeley@mozilla.com Garvan Keeley]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=[mailto:aaronleventhal@moonset.net Aaron Leventhal]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other), [mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D, Skia), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord], [mailto:mstange@themasta.com Markus Stange](OS X)<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:clord@mozilla.com Christopher Lord]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@mozilla.com Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
<br />
{{Module<br />
|name=GTK Embedding Widget<br />
|description=Gtk Widget for embedding Mozilla into Gtk applications<br />
|owner=[mailto:marco@gnome.org Marco Pesenti Gritti]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:dougt@mozilla.com Doug Turner]<br />
|group=dev-embedding<br />
|source_dirs=<br />
|url=<br />
|components=Core::Embedding: GTK Widget<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|group=dev-tech-dom<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:seth@mozilla.com Seth Fowler]<br />
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:jlebar@mozilla.com Justin Lebar], [mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Message-passing between threads and processes<br />
|owner=[mailto:wmccloskey@mozilla.com Bill McCloskey]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner], [mailto:jld@mozilla.com Jed Davis]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:jwalden@mit.edu Jeff Walden], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], [mailto:efaust@mozilla.com Eric Faust], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:luke@mozilla.com Luke Wagner], [mailto:arai.unmht@gmail.com Tooru Fujisawa], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], [mailto:gal@mozilla.com Andreas Gal]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:bbouvier@mozilla.com Benjamin Bouvier], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), painting, etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:smontagu@smontagu.org Simon Montagu], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/macbuild/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:mwu@mozilla.com Michael Wu]<br />
|peers=[mailto:aklotz@mozilla.com Aaron Klotz]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:cpearce@mozilla.com Chris Pearce]<br />
|peers=[mailto:ajones@mozilla.com Anthony Jones], [mailto:kinetik@flim.org Matthew Gregan], [mailto:eflores@mozilla.com Edwin Flores], [mailto:jyavenard@mozilla.com Jean-Yves Avenard], [mailto:gsquelart@mozilla.com Gerald Squelart], [mailto:rgiles@mozilla.com Ralph Giles], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Audio/Video<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=mozApps API & UI<br />
|description=Implementation of the navigator.mozApps API<br />
|owner=[mailto:fabrice@mozilla.com Fabrice Desré], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:myk@mozilla.org Myk Melez], [mailto:mar.castelluccio@studenti.unina.it Marco Castelluccio], [mailto:ferjmoreno@gmail.com Fernando Jiménez]<br />
|group=dev-webapi<br />
|source_dirs=dom/apps/, dom/interfaces/apps, product specific files implementing UI hooks.<br />
|url=<br />
|components=Core::DOM: Apps<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd] (mozglue/linker), [mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:pmcmanus@mozilla.com Patrick McManus]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:sworkman@mozilla.com Steve Workman]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:nelson@bolyard.com Nelson Bolyard], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:cjones@mozilla.com Chris Jones], [mailto:gal@mozilla.com Andreas Gal]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peers=[mailto:jst@mozilla.org Johnny Stenback], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:jschoenick@mozilla.com John Schoenick]<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=vacant<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owner=[mailto:dougt@mozilla.com Doug Turner]<br />
|peers=[mailto:nsm.nikhil@gmail.com Nikhil Marathe], [mailto:kcambridge@mozilla.com Kit Cambridge], [mailto:martin.thomson@gmail.com Martin Thomson], [mailto:ddamjanovic@mozilla.com Dragana Damjanovic]<br />
|group=<br />
|source_dirs=dom/push, dom/simplepush<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=[mailto:toddw@activestate.com Todd Whiteman]<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Qt-based gfx and widget<br />
|description=Qt-based rendering and widget code<br />
|owner=[mailto:romaxa@gmail.com Oleg Romashin]<br />
|peers=[mailto:mozilla@rosenauer.org Wolfgang Rosenauer], [mailto:dougt@mozilla.com Doug Turner]<br />
|group=dev-tech-widget<br />
|source_dirs=widget/qt/<br />
|url=<br />
|components=Core::Widget: Qt<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com David Keeler]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM, Core::Security: UI<br />
}}<br />
<br />
{{Module<br />
|name=Static analysis & rewriting for C++<br />
|description=Tools for checking C++ code looking for problems at compile time, plus tools for automated rewriting of C++ code.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:sfink@mozilla.com Steve Fink], [mailto:michael@thelayzells.com Michael Layzell], [mailto:jrmuizel@mozilla.com Jeff Muizelaar], [mailto:birunthan@mohanathas.com Birunthan Mohanathas]<br />
|group=dev-platform<br />
|source_dirs=build/clang-plugin, tools/rewriting among other out of tree tools<br />
|url=<br />
|components=Core::Rewriting & Analysis<br />
}}<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:bent.mozillla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:cam@mcc.id.au Cameron McCormack]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=[mailto:edwsmith@adobe.com Edwin Smith], [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill and Marionette. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mozilla.com Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), [mailto:rcampbell@mozilla.com Rob Campbell] (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (mozmill), [mailto:ato@mozilla.com Andreas Tolfsen] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette) [mailto:dminor@mozilla.com Dan Minor]<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], [mailto:rcampbell@mozilla.com Rob Campbell], [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette<br />
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk><br />
|source_dirs=gaia/tests/jsmarionette<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=[mailto:morgamic@mozilla.com Mike Morgan]<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:padenot@mozilla.com Paul Adenot], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:ehugg@cisco.com Ethan Hugg], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|group=dev-media<br />
|source_dirs=N/A (see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:mstange@themasta.com Markus Stange]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl], [mailto:smichaud@pobox.com Steven Michaud]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:dougt@mozilla.com Doug Turner], [mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robarnold@cmu.edu Rob Arnold], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-xbl<br />
|source_dirs=dom/xbl/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[https://mozillians.org/en-US/u/dougt/ Doug Turner], [https://mozillians.org/en-US/u/bsmedberg/ Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:gal@uci.edu Andreas Gal], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peers=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@mozilla.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=xptcall<br />
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]<br />
|group=dev-xpcom<br />
|source_dirs=xpcom/reflect/xptcall/<br />
|url=http://www.mozilla.org/scriptable/xptcall-faq.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=dom/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=XTF<br />
|description=eXtensible Tag Framework<br />
|owner=<br />
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=content/xtf/, layout/xtf/<br />
|url=http://www.croczilla.com/bits_and_pieces/xtf/<br />
|components=Core::XTF<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing<br />
|description=Cross platform sandboxing<br />
|owner=[mailto:gcp@mozilla.com Gian-Carlo Pascutto]<br />
|peers=[mailto:bowen@mozilla.com Bob Owen], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes], [mailto:gDestuynder@mozilla.com Guillaume Destuynder], [mailto:bsmedberg@mozilla.com Benjamin Smedberg], [mailto:jld@mozilla.com Jed Davis]<br />
|group=dev-platform <br />
|source_dirs=security/sandbox<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bowen@mozilla.com Bob Owen]<br />
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=<br />
|peers=<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux & B2G<br />
|description=Sandboxing for the Linux & B2G platforms<br />
|owner=<br />
|peers=[mailto:jld@mozilla.com Jed Davis]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc]<br />
|peers=Same as Build Config plus [mailto:nalexander@mozilla.com Nicholas Alexander].<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ehugg@cisco.com Ethan Hugg], [mailto:pkerr@mozilla.com Paul Kerr] <br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=/media/peerconnection, /dom/media/peerconnection ''(note: file reorg underway)''<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Event Handling<br />
Core::File Handling<br />
Core::Find Backend<br />
Core::Gecko Profiler<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Identity<br />
Core::Image Blocking<br />
Core::JavaScript Debugging APIs<br />
Core::Localization<br />
Core::Nanojit<br />
Core::Networking: Domain Lists<br />
Core::Print Preview<br />
Core::Printing: Output<br />
Core::Printing: Setup<br />
Core::Profile: BackEnd<br />
Core::Profile: Migration<br />
Core::Profile: Roaming<br />
Core::QuickLaunch (AKA turbo mode)<br />
Core::Rewriting and Analysis<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::Tracking<br />
Core::Web Services<br />
Core::WebDAV<br />
Core::Widget: OS/2<br />
Core::Widget: Photon<br />
Core::X-remote<br />
Core::XForms<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Sidstammhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1086102Modules/Core2015-07-22T16:22:39Z<p>Sidstamm: Removed SafeBrowsing from Content Security and updated peers list (as per https://groups.google.com/d/msg/mozilla.governance/rE-GyTnBeV8/mg6TnRhGMuEJ )</p>
<hr />
<div><noinclude><br />
'''Do not edit this page''' unless either:<br />
<br />
# you are a module owner who is:<br />
#* altering the list of peers in your module<br />
#* adding or removing a sub-module<br />
#* changing the owner of one of your sub-modules; or<br />
# you have agreed a change of owner or module addition/deletion with the Module Ownership Module group, probably via [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:bolterbugz@gmail.com David Bolter], [mailto:ginn.chen@oracle.com Ginn Chen], [mailto:trev.saunders@gmail.com Trevor Saunders], [mailto:marco.zehe@googlemail.com Marco Zehe] <br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nthomas@mozilla.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:coop@mozilla.com Chris Cooper]<br />
|group=release-engineering<br />
|source_dirs=browser/config/mozconfigs/, mobile/android/config/mozconfigs/, xulrunner/config/mozconfigs/, b2g/config/, tools/update-packaging/<br />
|url=https://wiki.mozilla.org/ReleaseEngineering<br />
|components=Release Engineering::*<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:benjamin@smedbergs.us Benjamin Smedberg] (:bsmedberg) <br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), Subresource Integrity (SRI) and CORS.<br />
|owner=[mailto:mozilla@sidstamm.com Sid Stamm]<br />
|peers=[mailto:francois@mozilla.com François Marier], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=[mailto:mchew@mozilla.com Monica Chew]<br />
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:jst@mozilla.org Johnny Stenback], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-tech-layout<br />
|source_dirs=docshell/, uriloader/, webshell/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Device Storage<br />
|description=Support for the device storage API<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands], [mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:dougt@dougt.org Doug Turner]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/devicestorage/, dom/interfaces/devicestorage/<br />
|url=https://developer.mozilla.org/en-US/docs/WebAPI/Device_Storage<br />
|components=Core::DOM: Device Interfaces<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:bent@mozilla.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri (still active, but slower to respond than previously)], [mailto:me@kylehuey.com Kyle Huey], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML, Core::DOM: Events<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=<br />
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-embedding<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs, Core::Embedding: ActiveX Wrapper, Core::Embedding: GRE Core, Core::Embedding: GTK Widget, Core::Embedding: MFC Embed, Core::Embedding: Mac, Core::Embedding: Packaging<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:dougt@dougt.org Doug Turner]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen], [gkeeley@mozilla.com Garvan Keeley]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=[mailto:aaronleventhal@moonset.net Aaron Leventhal]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other), [mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D, Skia), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:clord@mozilla.com Christopher Lord]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@mozilla.com Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
<br />
{{Module<br />
|name=GTK Embedding Widget<br />
|description=Gtk Widget for embedding Mozilla into Gtk applications<br />
|owner=[mailto:marco@gnome.org Marco Pesenti Gritti]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:dougt@meer.net Doug Turner]<br />
|group=dev-embedding<br />
|source_dirs=<br />
|url=<br />
|components=Core::Embedding: GTK Widget<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|group=dev-tech-dom<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:seth@mozilla.com Seth Fowler]<br />
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:jlebar@mozilla.com Justin Lebar], [mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Message-passing between threads and processes<br />
|owner=[mailto:cjones@mozilla.com Chris Jones]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:jwalden@mit.edu Jeff Walden], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:till@tillschneidereit.net Till Schneidereit], [mailto:efaust@mozilla.com Eric Faust], [mailto:nfitzgerald@mozilla.com Nick Fitzgerald], [mailto:luke@mozilla.com Luke Wagner], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], [mailto:gal@mozilla.com Andreas Gal]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:mrosenberg@mozilla.com Marty Rosenberg], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), painting, etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:smontagu@smontagu.org Simon Montagu], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/macbuild/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:tglek@mozilla.com Taras Glek]<br />
|peers=[mailto:mwu@mozilla.com Michael Wu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Playback<br />
|description=HTML Media APIs, including Media Source Extensions and non-MSE video/audio element playback, and Encrypted Media Extensions. (WebRTC and WebAudio not included).<br />
|owner=[mailto:cpearce@mozilla.com Chris Pearce]<br />
|peers=[mailto:ajones@mozilla.com Anthony Jones], [mailto:kinetik@flim.org Matthew Gregan], [mailto:eflores@mozilla.com Edwin Flores], [mailto:jyavenard@mozilla.com Jean-Yves Avenard], [mailto:gsquelart@mozilla.com Gerald Squelart], [mailto:rgiles@mozilla.com Ralph Giles], [mailto:jwwang@mozilla.com JW Wang]<br />
|group=dev-media<br />
|source_dirs=dom/media, media/gmp-clearkey/, media/libcubeb/, media/libnestegg/, media/libogg/, media/libopus/, media/libstagefright/, media/libtheora/, media/libtremor/, media/libvorbis/, media/libvpx/, media/omx-plugin/, media/rlz/<br />
|url=<br />
|components=Core::Video/Audio<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=mozApps API & UI<br />
|description=Implementation of the navigator.mozApps API<br />
|owner=[mailto:fabrice@mozilla.com Fabrice Desré], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:myk@mozilla.org Myk Melez], [mailto:mar.castelluccio@studenti.unina.it Marco Castelluccio], [mailto:ferjmoreno@gmail.com Fernando Jiménez]<br />
|group=dev-webapi<br />
|source_dirs=dom/apps/, dom/interfaces/apps, product specific files implementing UI hooks.<br />
|url=<br />
|components=Core::DOM: Apps<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd] (mozglue/linker), [mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:pmcmanus@mozilla.com Patrick McManus]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:sworkman@mozilla.com Steve Workman]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:nelson@bolyard.com Nelson Bolyard], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:cjones@mozilla.com Chris Jones], [mailto:gal@mozilla.com Andreas Gal]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peers=[mailto:jst@mozilla.org Johnny Stenback], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:jschoenick@mozilla.com John Schoenick]<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=vacant<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Private Browsing<br />
|description=Implementation of the Private Browsing mode, and the integration of other modules with Private Browsing APIs.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews]<br />
|group=dev-platform<br />
|source_dirs=Implementation and consumers of Private Browsing APIs in nsILoadContext, nsIPrivateBrowsingChannel, PrivateBrowsingUtils.jsm and the related glue code. <br />
|url=https://wiki.mozilla.org/Private_Browsing<br />
|components=Firefox::Private Browsing<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dveditz@cruzio.com Dan Veditz], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owner=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:nsm.nikhil@gmail.com Nikhil Marathe], [mailto:kcambridge@mozilla.com Kit Cambridge], [mailto:martin.thomson@gmail.com Martin Thomson]<br />
|group=<br />
|source_dirs=dom/push, dom/simplepush<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=[mailto:toddw@activestate.com Todd Whiteman]<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Qt-based gfx and widget<br />
|description=Qt-based rendering and widget code<br />
|owner=[mailto:romaxa@gmail.com Oleg Romashin]<br />
|peers=[mailto:mozilla@rosenauer.org Wolfgang Rosenauer], [mailto:doug.turner@gmail.com Doug Turner]<br />
|group=dev-tech-widget<br />
|source_dirs=widget/qt/<br />
|url=<br />
|components=Core::Widget: Qt<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com David Keeler]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:cykesiopka.bmo@gmail.com Cykesiopka]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM, Core::Security: UI<br />
}}<br />
<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:bent.mozillla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:cam@mcc.id.au Cameron McCormack]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=[mailto:edwsmith@adobe.com Edwin Smith], [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill and Marionette. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mozilla.com Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), [mailto:rcampbell@mozilla.com Rob Campbell] (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (mozmill), [mailto:mdas@mozilla.com Malini Das] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette) [mailto:dminor@mozilla.com Dan Minor]<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], [mailto:rcampbell@mozilla.com Rob Campbell], [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette<br />
|description=NodeJS test harness, marionette client, and other utilities for running marionette tests (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk><br />
|source_dirs=gaia/tests/jsmarionette<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=[mailto:morgamic@mozilla.com Mike Morgan]<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:padenot@mozilla.com Paul Adenot], [mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:ehugg@cisco.com Ethan Hugg], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|group=dev-media<br />
|source_dirs=N/A (see submodules "WebRTC Media" and "WebRTC Signaling")<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:smichaud@pobox.com Steven Michaud]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:mstange@themasta.com Markus Stange], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:dougt@meer.net Doug Turner], [mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robarnold@cmu.edu Rob Arnold], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-xbl<br />
|source_dirs=dom/xbl/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:jag@tty.nl Peter Annema], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[https://mozillians.org/en-US/u/dougt/ Doug Turner], [https://mozillians.org/en-US/u/bsmedberg/ Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:gal@uci.edu Andreas Gal], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peers=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@cruzio.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=xptcall<br />
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]<br />
|group=dev-xpcom<br />
|source_dirs=xpcom/reflect/xptcall/<br />
|url=http://www.mozilla.org/scriptable/xptcall-faq.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:hyatt@mozilla.org Dave Hyatt], [mailto:jag@tty.nl Peter Annema], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=dom/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=XTF<br />
|description=eXtensible Tag Framework<br />
|owner=<br />
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=content/xtf/, layout/xtf/<br />
|url=http://www.croczilla.com/bits_and_pieces/xtf/<br />
|components=Core::XTF<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bowen@mozilla.com Bob Owen]<br />
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:smichaud@mozilla.com Steven Michaud]<br />
|peers=[mailto:areinald@mozilla.com Andre Reinald ]<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux & B2G<br />
|description=Sandboxing for the Linux & B2G platforms<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gDestuynder@mozilla.com Guillaume Destuynder]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc]<br />
|peers=Same as Build Config plus [mailto:nalexander@mozilla.com Nicholas Alexander].<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Media<br />
|description=Submodule of WebRTC responsible for access to media input devices (microphones, cameras, screen capture), as well as realtime audiovisual codecs and packetization.<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ehugg@cisco.com Ethan Hugg], [mailto:pkerr@mozilla.com Paul Kerr] <br />
|group=dev-media<br />
|source_dirs=/media/webrtc, /dom/media/webrtc<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Audio/Video)<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC Signaling<br />
|description=Submodule of WebRTC responsible for implementation of PeerConnection API, WebRTC identity, and SDP/JSEP handling<br />
|owner=[mailto:bcampen@mozilla.com Byron Campen]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:abr@mozilla.com Adam Roach], [mailto:rjesup@mozilla.com Randell Jesup], [mailto:nohlmeier@mozilla.com Nils Ohlmeier]<br />
|group=dev-media<br />
|source_dirs=/media/peerconnection, /dom/media/peerconnection ''(note: file reorg underway)''<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC (Signaling)<br />
}}<br />
<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Event Handling<br />
Core::File Handling<br />
Core::Find Backend<br />
Core::Gecko Profiler<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Identity<br />
Core::Image Blocking<br />
Core::JavaScript Debugging APIs<br />
Core::Localization<br />
Core::Nanojit<br />
Core::Networking: Domain Lists<br />
Core::Print Preview<br />
Core::Printing: Output<br />
Core::Printing: Setup<br />
Core::Profile: BackEnd<br />
Core::Profile: Migration<br />
Core::Profile: Roaming<br />
Core::QuickLaunch (AKA turbo mode)<br />
Core::Rewriting and Analysis<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::Tracking<br />
Core::Web Services<br />
Core::WebDAV<br />
Core::Widget: OS/2<br />
Core::Widget: Photon<br />
Core::X-remote<br />
Core::XForms<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Sidstammhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1059568Modules/Core2015-03-03T23:52:52Z<p>Sidstamm: remove "todo"</p>
<hr />
<div><noinclude><br />
'''Do not edit this page''' unless either:<br />
<br />
# you are a module owner who is:<br />
#* altering the list of peers in your module<br />
#* adding or removing a sub-module<br />
#* changing the owner of one of your sub-modules; or<br />
# you have agreed a change of owner or module addition/deletion with the Module Ownership Module group, probably via [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:bolterbugz@gmail.com David Bolter], [mailto:ginn.chen@oracle.com Ginn Chen], [mailto:trev.saunders@gmail.com Trevor Saunders], [mailto:marco.zehe@googlemail.com Marco Zehe] <br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nrthomas@gmail.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:cmp@mozilla.org Chase Phillips], [mailto:mozpreed@sigkill.com John Paul Reed], [mailto:robert@roberthelmer.com Robert Helmer]<br />
|group=dev-builds<br />
|source_dirs=tools/botrunner.py, tools/build-environment/, tools/build/, tools/buildbot-configs/, tools/buildbot/, tools/buildbotcustom/, tools/l10n/, tools/MozBuild/, tools/patcher-configs/, tools/patcher/, tools/release/, tools/tinderbox-configs/, tools/tinderbox/, tools/update-packaging/, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=<br />
|components=mozilla.org::Release Engineering, mozilla.org::Release Engineering: Custom Builds<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:benjamin@smedbergs.us Benjamin Smedberg] (:bsmedberg) <br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), and Safe Browsing.<br />
|owner=[mailto:sstamm@mozilla.com Sid Stamm], [mailto:gpascutto@mozilla.com Gian-Carlo Pascutto]<br />
|peers=[mailto:grobinson@mozilla.com Garrett Robinson], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|group=dev-security<br />
|source_dirs=dom/security<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=[mailto:mchew@mozilla.com Monica Chew]<br />
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[https://mozillians.org/en-US/u/mccr8/ Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:jst@mozilla.org Johnny Stenback], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-tech-layout<br />
|source_dirs=docshell/, uriloader/, webshell/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Device Storage<br />
|description=Support for the device storage API<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands], [mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:dougt@dougt.org Doug Turner]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/devicestorage/, dom/interfaces/devicestorage/<br />
|url=https://developer.mozilla.org/en-US/docs/WebAPI/Device_Storage<br />
|components=Core::DOM: Device Interfaces<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:bent@mozilla.com Ben Turner], [mailto:mounir@lamouri.fr Mounir Lamouri (still active, but slower to respond than previously)], [mailto:me@kylehuey.com Kyle Huey], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini],<br />
[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML, Core::DOM: Events<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=<br />
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-embedding<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs, Core::Embedding: ActiveX Wrapper, Core::Embedding: GRE Core, Core::Embedding: GTK Widget, Core::Embedding: MFC Embed, Core::Embedding: Mac, Core::Embedding: Packaging<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:dougt@dougt.org Doug Turner]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen], [gkeeley@mozilla.com Garvan Keeley]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=[mailto:aaronleventhal@moonset.net Aaron Leventhal]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=dom/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other), [mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D, Skia), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord]<br />
|group=dev-platform<br />
|source_dirs=gfx/, dom/canvas/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:clord@mozilla.com Christopher Lord]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@mozilla.com Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
<br />
{{Module<br />
|name=GTK Embedding Widget<br />
|description=Gtk Widget for embedding Mozilla into Gtk applications<br />
|owner=[mailto:marco@gnome.org Marco Pesenti Gritti]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:dougt@meer.net Doug Turner]<br />
|group=dev-embedding<br />
|source_dirs=<br />
|url=<br />
|components=Core::Embedding: GTK Widget<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|group=dev-tech-dom<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:seth@mozilla.com Seth Fowler]<br />
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:jlebar@mozilla.com Justin Lebar], [mailto:tnikkel@gmail.com Timothy Nikkel]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Message-passing between threads and processes<br />
|owner=[mailto:cjones@mozilla.com Chris Jones]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], [mailto:gal@mozilla.com Andreas Gal], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:luke@mozilla.com Luke Wagner], [mailto:jwalden@mit.edu Jeff Walden], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:till@tillschneidereit.net Till Schneidereit]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:mrosenberg@mozilla.com Marty Rosenberg], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=jsat<br />
|description=Javascript screen reader that is used in Android and B2G<br />
|owner=[mailto:eitan@monotonous.org Eitan Isaacson]<br />
|peers=[mailto:yzenevich@mozilla.com Yura Zenevich]<br />
|group=dev-accessibility<br />
|source_dirs=accessible/jsat/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), painting, etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:smontagu@smontagu.org Simon Montagu], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/macbuild/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:tglek@mozilla.com Taras Glek]<br />
|peers=[mailto:mwu@mozilla.com Michael Wu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=Media Transport<br />
|description=Pluggable transport for real-time media<br />
|owner=[mailto:ekr@rtfm.com Eric Rescorla]<br />
|peers=[mailto:bcampen@mozilla.com Byron Campen], [mailto:abr@mozilla.com Adam Roach]<br />
|group=dev-media<br />
|source_dirs=media/mtransport<br />
|url=<br />
|components=Core::WebRTC::Networking<br />
}}<br />
<br />
{{Module<br />
|name=Memory Allocator<br />
|description=Most things related to memory allocation in Gecko, including jemalloc, replace-malloc, DMD (dark matter detector), logalloc, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:n.nethercote@gmail.com Nicholas Nethercote]<br />
|group=dev-platform<br />
|source_dirs=memory/<br />
|components=Core::DMD, Core::jemalloc<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=mozApps API & UI<br />
|description=Implementation of the navigator.mozApps API<br />
|owner=[mailto:fabrice@mozilla.com Fabrice Desré], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:myk@mozilla.org Myk Melez], [mailto:mar.castelluccio@studenti.unina.it Marco Castelluccio], [mailto:ferjmoreno@gmail.com Fernando Jiménez]<br />
|group=dev-webapi<br />
|source_dirs=dom/apps/, dom/interfaces/apps, product specific files implementing UI hooks.<br />
|url=<br />
|components=Core::DOM: Apps<br />
}}<br />
<br />
{{Module<br />
|name=Mozglue<br />
|description=Glue library containing various low-level functionality, including a dynamic linker for Android, a DLL block list for Windows, etc.<br />
|owner=[mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd] (mozglue/linker), [mailto:kgupta@mozilla.com Kartikaya Gupta] (mozglue/android), [mailto:nchen@mozilla.com Jim Chen] (mozglue/android)<br />
|group=dev-platform<br />
|source_dirs=mozglue/<br />
|components=Core::mozglue<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:pmcmanus@mozilla.com Patrick McManus]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:sworkman@mozilla.com Steve Workman]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:nelson@bolyard.com Nelson Bolyard], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:cjones@mozilla.com Chris Jones], [mailto:gal@mozilla.com Andreas Gal]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peers=[mailto:jst@mozilla.org Johnny Stenback], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:jschoenick@mozilla.com John Schoenick]<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=vacant<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dveditz@cruzio.com Dan Veditz], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owner=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:nsm.nikhil@gmail.com Nikhil Marathe], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=https://wiki.mozilla.org/WebAPI/SimplePush<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=[mailto:toddw@activestate.com Todd Whiteman]<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Qt-based gfx and widget<br />
|description=Qt-based rendering and widget code<br />
|owner=[mailto:romaxa@gmail.com Oleg Romashin]<br />
|peers=[mailto:mozilla@rosenauer.org Wolfgang Rosenauer], [mailto:doug.turner@gmail.com Doug Turner]<br />
|group=dev-tech-widget<br />
|source_dirs=widget/qt/<br />
|url=<br />
|components=Core::Widget: Qt<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com David Keeler]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM, Core::Security: UI<br />
}}<br />
<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:bent.mozillla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:cam@mcc.id.au Cameron McCormack]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=dom/svg/, layout/svg/, dom/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=[mailto:edwsmith@adobe.com Edwin Smith], [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill and Marionette. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mozilla.com Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), [mailto:rcampbell@mozilla.com Rob Campbell] (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (mozmill), [mailto:mdas@mozilla.com Malini Das] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette) [mailto:dminor@mozilla.com Dan Minor]<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], [mailto:rcampbell@mozilla.com Rob Campbell], [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette Harness and Tools<br />
|description=Test harness and associated tools for running marionette tests on NodeJS (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk>, [mailto:mike@bocoup.com Mike Pennisi] <jugglinmike>, [mailto:evanxd@mozilla.com Evan Tseng] <evanxd><br />
|source_dirs=These are all mozilla-b2g github repos: [https://github.com/mozilla-b2g/marionette-js-runner Marionette JS Runner], [https://github.com/mozilla-b2g/mocha-json-proxy Mocha JSON Proxy], [https://github.com/mozilla-b2g/mocha-tbpl-reporter Mocha TBPL Reporter], [https://github.com/mozilla-b2g/marionette-js-client Marionette JS Client], [https://github.com/mozilla-b2g/sockit-to-me Sockit To Me], [https://github.com/mozilla-b2g/marionette-apps Marionette Apps], [https://github.com/mozilla-b2g/marionette-js-logger Marionette JS Logger], [https://github.com/mozilla-b2g/marionette-b2gdesktop-host Marionette B2G Desktop Host], [https://github.com/mozilla-b2g/marionette-firefox-host Marionette Firefox Host], [https://github.com/mozilla-b2g/marionette-profile-builder Marionette Profile Builder], [https://github.com/mozilla-b2g/mozilla-profile-builder Mozilla Profile Builder]<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=[mailto:morgamic@mozilla.com Mike Morgan]<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:padenot@mozilla.com Paul Adenot]<br />
|group=dev-platform<br />
|source_dirs=dom/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access (on desktop at least)<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:ehugg@cisco.com Ethan Hugg], [mailto:tterriberry@mozilla.com Tim Terriberry], [mailto:bcampen@mozilla.com Byron Campen] [mailto:abr@mozilla.com Adam Roach]<br />
|group=dev-media<br />
|source_dirs=media/webrtc, dom/media/webrtc<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC (Audio/Video), Core::WebRTC (Networking), Core::WebRTC (Signaling)<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:smichaud@pobox.com Steven Michaud]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:mstange@themasta.com Markus Stange], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:dougt@meer.net Doug Turner], [mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robarnold@cmu.edu Rob Arnold], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-xbl<br />
|source_dirs=dom/xbl/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=dom/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:jag@tty.nl Peter Annema], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[https://mozillians.org/en-US/u/froydnj/ Nathan Froyd]<br />
|peers=[https://mozillians.org/en-US/u/dougt/ Doug Turner], [https://mozillians.org/en-US/u/bsmedberg/ Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:gal@uci.edu Andreas Gal], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peers=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@cruzio.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=xptcall<br />
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]<br />
|group=dev-xpcom<br />
|source_dirs=xpcom/reflect/xptcall/<br />
|url=http://www.mozilla.org/scriptable/xptcall-faq.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:hyatt@mozilla.org Dave Hyatt], [mailto:jag@tty.nl Peter Annema], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=dom/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=dom/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=XTF<br />
|description=eXtensible Tag Framework<br />
|owner=<br />
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=content/xtf/, layout/xtf/<br />
|url=http://www.croczilla.com/bits_and_pieces/xtf/<br />
|components=Core::XTF<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[mailto:bowen@mozilla.com Bob Owen]<br />
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:aklotz@mozilla.com Aaron Klotz], [https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:smichaud@mozilla.com Steven Michaud]<br />
|peers=[mailto:areinald@mozilla.com Andre Reinald ]<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux & B2G<br />
|description=Sandboxing for the Linux & B2G platforms<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gDestuynder@mozilla.com Guillaume Destuynder]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security: Process Sandboxing<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc]<br />
|peers=Same as Build Config plus [mailto:nalexander@mozilla.com Nicholas Alexander].<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Event Handling<br />
Core::File Handling<br />
Core::Find Backend<br />
Core::Gecko Profiler<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Identity<br />
Core::Image Blocking<br />
Core::JavaScript Debugging APIs<br />
Core::Localization<br />
Core::Nanojit<br />
Core::Networking: Domain Lists<br />
Core::Print Preview<br />
Core::Printing: Output<br />
Core::Printing: Setup<br />
Core::Profile: BackEnd<br />
Core::Profile: Migration<br />
Core::Profile: Roaming<br />
Core::QuickLaunch (AKA turbo mode)<br />
Core::Rewriting and Analysis<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::Tracking<br />
Core::Video/Audio<br />
Core::Web Services<br />
Core::WebDAV<br />
Core::Widget: OS/2<br />
Core::Widget: Photon<br />
Core::X-remote<br />
Core::XForms<br />
Core::XUL<br />
</pre><br />
</noinclude></div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2015/Q1Goals&diff=1050561SecurityEngineering/2015/Q1Goals2015-01-26T22:32:07Z<p>Sidstamm: </p>
<hr />
<div>__NOTOC__<br />
<br />
'''DRAFT DRAFT DRAFT DRAFT DRAFT'''<br />
<br />
== Content Security ==<br />
* {{new|Warn users about insecure password fields in Dev Edition/Aurora.}} (dri=tanvi)<br />
** Figure out if we can display an in-your-face warning for passwords on HTTP pages in Aurora<br />
** Figure out if we can turn this preference on for Polaris (if not today, then someday in the future)<br />
** Get UX help to design the warning<br />
** Start implementing<br />
* {{new|REVAMP: Finalize LoadInfo patches for JS/C++ gecko channels .}} (dri=ckerschb)<br />
* {{new|REVAMP: Start implementing the LoadInfo shim for addons.}} (dri=ckerschb)<br />
* {{new|CSP: Prototype CSP devtool that provides suggested policy for page.}} (dri=ckerschb)<br />
* {{new|Land SRI with style support.}} (dri=francois)<br />
* {{new|Propose an approach for adding reporting to SRI.}} (dri=francois)<br />
<br />
== Tracking Protection ==<br />
* {{new|Get TP UI enabled in Nightly/Aurora to check webcompat, shake out bugs etc.}} (dri=mmc)<br />
* {{new|Review Referrer Policy.}} (dri=mmc/sid)<br />
* {{new|Start experimenting with Containers for Contextual Identity.}} (dri=mmc)<br />
* {{ok|Tor bugs.}} (dri=sid)<br />
* {{done|Blog post for meta referrer.}} (dri=Sid)<br />
<br />
== Addon Security ==<br />
* Mechanism for enforcing signed-by-AMO addons in 38. Whether enabled or not depends on readiness in other parts.<br />
<br />
== Communications Security ==<br />
* {{new|Name constraints on root CAs}} (dri=jones)<br />
* {{new|OneCRL based on (subject, public key)}} (dri=mgoodwin)<br />
* {{new|Automate pinging CAs for current audit statements}} (dri=wilson)<br />
* {{new|Finish removing / turning off 1024-bit roots}} (dri=wilson) -- Second Group in FF 36, Final group in FF 38.<br />
** Telemetry for verification success by root: http://mzl.la/1Kjn18h<br />
** Telemetry dashboard for verification success and pinning failures by root: https://people.mozilla.org/~dkeeler/ca-telemetry-dashboard/<br />
* {{new|Initial certificate/CA observatory}} (dri=keeler)<br />
** https://people.mozilla.org/~dkeeler/dashboard/<br />
<br />
== QE (tracking) ==<br />
* {{new|Monitor high risk telemetry security probes via the medusa alerting system in m-c}} (dri=kamil)<br />
* {{new|Use the Telemetry prototype to create graphs/monitor high risk security probes via Aurora and BETA.}} (dri=kamil)<br />
* {{new|Create a smoke-level Marionette test for SSL compatibility to be run on Mozmill-CI}} (dri=mwobensmith)<br />
* {{new|Create and stage a web-based SSL site compat tool}} (dri=mwobensmith)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=Privacy/Features/Shortened_HTTP_Referer_header&diff=1047884Privacy/Features/Shortened HTTP Referer header2015-01-14T18:23:42Z<p>Sidstamm: </p>
<hr />
<div>{{FeatureStatus<br />
|Feature name=Shortened HTTP Referer header<br />
|Feature stage=Development<br />
|Feature health=OK<br />
}}<br />
{{FeatureTeam<br />
|Feature product manager=Sid Stamm<br />
|Feature feature manager=Sid Stamm<br />
|Feature lead engineer=Sid Stamm<br />
|Feature security lead=Curtis Koenig<br />
|Feature privacy lead=Sid Stamm<br />
|Feature qa lead=Mihai Morar<br />
|Feature additional members=Owen Chu<br />
}}<br />
{{FeaturePageBody<br />
|Feature open issues and risks=* Site breakage (tolerable? need to quantify this)<br />
* User confusion (make it hidden pref?)<br />
|Feature overview=There is the desire to remove the Referer header outright, possibly in favor of the Origin header or something with less information. It can leak sensitive data accidentally and can be abused as a form of ambient authority. Unfortunately, we can't just stop sending it on requests because too many things on the web might break. [[Privacy/2010-10-27 Shorten-Referer Meeting Notes|Sites like Facebook have expressed a desire for a referer-shortening capability]], so this feature benefits both users and site developers.<br />
<br />
This feature adds a way to attenuate the information that's sent as the referrer. This is multiple phases:<br />
<br />
'''Phase 1:''' Plumbing for global and site-specific control. In the first phase, we will create a global pref so power users and addons can select at most how much of the URL is sent as referrer, globally. Additionally, on a site-by-site basis (probably via permission manager) a referrer policy can be applied to override the global setting.<br />
<br />
'''Phase 2:''' Site-based control via CSP header and tag attributes. In the second phase, we enable sites to reduce the amount of data transmitted in referrers generated on their site. This is done by the site sending a signal with Content Security Policy response header indicating that outgoing referrers should be reduced. Stripping options should include the same options mentioned in phase 1. Sites will be able to specify a default policy for their pages, but we will also implement some per-link control (One mechanism could be to support [http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/ the rel="noreferrer" attribute] to omit referers from link clicks, or similar).<br />
<br />
'''Phase 3:''' Site-based control via meta tag. Once the CSP HTTP response header can be used to set a site policy, we will extend CSP to be settable via the meta tag. This way sites can specify a referrer policy without having to send an HTTP header.<br />
<br />
Note: Site-based control could be accomplished using the meta referrer tag, but we are opting to implement the same functionality in CSP to combine the security/privacy features. [http://wiki.whatwg.org/wiki/Meta_referrer See whatwg wiki] and see also {{bug|704320}}.<br />
<br />
'''Phase 4:''' New Firefox defaults. Once sites have better control, we will decide how much to limit referrer sending by default (same-origin and cross-origin). Right now too much information is transmitted in referer headers, and we should reduce that to the extent possible. In this phase, we'll have an open discussion in [https://lists.mozilla.org/listinfo/dev-privacy dev-privacy] about what defaults to choose.<br />
<br />
'''Phase 5:''' Extra bonus phase - UI for users to control how much referrer is sent on a global basis, likely in the privacy settings for Firefox. Additionally, per-site control in the permissions and siteinfo UI. This may not be necessary if Phase 4 is successful and there's not much referrer sending by default.<br />
<br />
See also: {{bug|587523}}<br />
|Feature users and use cases=Nice document from Dan Aurbach:<br />
https://bug822869.bugzilla.mozilla.org/attachment.cgi?id=694472<br />
<br />
; Leaking search terms : From {{bug|587523#c0}}: "An example of this can be seen by searching for 'no knead bread' with Google, and clicking on the 4th search result, which takes you to www.breadtopia.com/basic-no-knead-method/, a page which "helpfully" lets you know that it is aware of the search terms that brought you to the site."<br />
; Outbound link anonymization : Many sites like gmail send outbound links through a common redirect to strip off any information that may be present in the URL. Supporting rel="noreferrer" reduces the need for extra HTTP traffic and redirects.<br />
|Feature requirements=* Test plan must be created and implemented<br />
* Use cases must be clearly outlined and it must be clear how the feature addresses each.<br />
* Initially, Phase 1 (user-set) should not change default behavior until user initiates change.<br />
* Default referer behavior for sites should not change until sites activate attenuation features.<br />
|Feature non-goals=* We are not removing the HTTP referer header<br />
* We are not replacing the HTTP referer header<br />
* This is not the Origin header<br />
|Feature functional spec=See also [http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer the noreferrer link type]<br />
|Feature implementation plan='''Phase 1:'''<br />
* {{done|global default referrer policy via pref}} ({{bug|822869}})<br />
* {{ok|site-specific setting via permission}} ({{bug|966505}})<br />
<br />
'''Phase 2:'''<br />
* {{done|CSP referrer directive support}} ({{bug|965727}})<br />
* {{done|noreferrer attribute for anchor tags}} ({{bug|530396}})<br />
* {{new|referrer (policy) attribute for anchor tags}}<br />
<br />
'''Phase 3:'''<br />
* {{done|meta tag support for CSP}} ({{bug|663570}})<br />
<br />
'''Phase 4:'''<br />
* {{new|discussion in [https://lists.mozilla.org/listinfo/dev-privacy dev-privacy] about measuring success of new referrer defaults}}<br />
* {{new|discussion in [https://lists.mozilla.org/listinfo/dev-privacy dev-privacy] to choose new policy (and measurement of its effects)}}<br />
* {{new|change global default policy for referrer}} {{bug|122453}}<br />
<br />
'''Phase 5:'''<br />
* {{new|decide if this phase should be dropped or completed}}<br />
* {{new|about:permissions and siteInfo UI for per-site referrer settings}}<br />
* {{new|privacy settings pane UI for global referrer settings}}<br />
|Feature implementation notes=See above in Planning section for progress. Just some links here.<br />
<br />
* [http://www.facebook.com/notes/facebook-engineering/protecting-privacy-with-referrers/392382738919 Facebook write-up on "HTTP-Referer" woes]<br />
* [http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/ the rel="noreferrer" attribute]<br />
* {{bug|587523}}: strip referrer in a future anonymous mode<br />
|Feature landing criteria=* Has tests<br />
* Tests pass on B2G, Android and Desktop<br />
}}<br />
{{FeatureInfo<br />
|Feature priority=P1<br />
|Feature rank=4<br />
|Feature theme=Tracking Control<br />
|Feature roadmap=Privacy<br />
|Feature list=Platform<br />
|Feature engineering team=Networking<br />
}}<br />
{{FeatureTeamStatus}}</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q4Goals&diff=1042208SecurityEngineering/2014/Q4Goals2014-12-17T18:55:56Z<p>Sidstamm: status updates</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
== Content Security ==<br />
;Outcome: More robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Sid, Francois, Steve<br />
* {{risk|Add LoadInfo to Gecko-owned JS callers}} (dri=ckerschb,tanvi)<br />
* {{done|Use LoadInfo to implement MCB for HTTP redirects}} (dri=tanvi)<br />
* {{done|Implement Next Block of CSP Level 2.0 features}} (dri=sstamm,ckerschb)<br />
** Work to fix spec to have child-src directive we want<br />
** Implement form-action directive<br />
** Implement referrer directive (depends on {{bug|704320}})<br />
** Fix frame-ancestors mapping<br />
** Work to fix spec about blob urls<br />
* {{ok|Initial Implementation of sub-resource integrity}} ({{bug|992096}}) (dri=francois)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Sid<br />
* {{done|Finish <meta> referrer}} (dri=sid)<br />
<br />
== Addon Security ==<br />
;Outcome: TBD<br />
;Who: Dan Veditz<br />
Goals: <br />
* {{ok|Require signed add-ons (backend)}} See {{bug|1047239}}(dri=dveditz)<br />
<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks. <br />
;Who: Richard, Kathleen, Keeler, Monica, JC, Mark<br />
<br />
* {{ok|Add more BR checking}} (some combination of giving errors during path building, wall of shame, console warnings -- tbd) (dri=dkeeler)<br />
* {{done|Identify what of Certificate Transparency we must/should deploy}} (dri=rbarnes)<br />
* {{done|Complete phase 1 of migration to CA database}} (dri=kwilson)<br />
* {{ok|[stretch] Import mozilla::pkix to a branch of NSS}} (dri=jcjones)<br />
* {{ok|[stretch] Add ability to name constrain more root CAs}} (dri=dkeeler)<br />
* {{done|[stretch] Add security warnings about SHA-1 to Web Console}} (dri=mgoodwin)<br />
* {{ok|OneCRL client implementation}} (dri=mgoodwin)<br />
<br />
== QE (tracking) ==<br />
We also track security related QE goals. (section owner=mwobensmith)<br />
;Official list : (link TBD)<br />
* Tool telemetry of SSL errors/over-rides to watch for outliers, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1058812#c42 (dri=matt)<br />
* https://lists.mozilla.org/listinfo/dev-telemetry-alerts<br />
* Setup SSL compatibility testing to be run at the beginning of Beta for each branch. (dri=matt)<br />
* Figure out how to take the cert caching into account when running SSL compatibility tests (dri=matt)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q4Goals&diff=1042207SecurityEngineering/2014/Q4Goals2014-12-17T18:53:25Z<p>Sidstamm: /* Communications Security */ update status</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
== Content Security ==<br />
;Outcome: More robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Sid, Francois, Steve<br />
* {{risk|Add LoadInfo to Gecko-owned JS callers}} (dri=ckerschb,tanvi)<br />
* {{done|Use LoadInfo to implement MCB for HTTP redirects}} (dri=tanvi)<br />
* {{done|Implement Next Block of CSP Level 2.0 features}} (dri=sstamm,ckerschb)<br />
** Work to fix spec to have child-src directive we want<br />
** Implement form-action directive<br />
** Implement referrer directive (depends on {{bug|704320}})<br />
** Fix frame-ancestors mapping<br />
** Work to fix spec about blob urls<br />
* {{ok|Initial Implementation of sub-resource integrity}} ({{bug|992096}}) (dri=francois)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Sid<br />
* {{done|Finish <meta> referrer}} (dri=sid)<br />
<br />
== Addon Security ==<br />
Desired Outcome: TBD<br />
<br />
Goals: <br />
* TBD (dri=dveditz)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks. <br />
;Who: Richard, Kathleen, Keeler, Monica, JC, Mark<br />
<br />
* {{ok|Add more BR checking}} (some combination of giving errors during path building, wall of shame, console warnings -- tbd) (dri=dkeeler)<br />
* {{done|Identify what of Certificate Transparency we must/should deploy}} (dri=rbarnes)<br />
* {{done|Complete phase 1 of migration to CA database}} (dri=kwilson)<br />
* {{ok|[stretch] Import mozilla::pkix to a branch of NSS}} (dri=jcjones)<br />
* {{ok|[stretch] Add ability to name constrain more root CAs}} (dri=dkeeler)<br />
* {{done|[stretch] Add security warnings about SHA-1 to Web Console}} (dri=mgoodwin)<br />
<br />
== QE (tracking) ==<br />
We also track security related QE goals. (section owner=mwobensmith)<br />
;Official list : (link TBD)<br />
* Tool telemetry of SSL errors/over-rides to watch for outliers, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1058812#c42 (dri=matt)<br />
* https://lists.mozilla.org/listinfo/dev-telemetry-alerts<br />
* Setup SSL compatibility testing to be run at the beginning of Beta for each branch. (dri=matt)<br />
* Figure out how to take the cert caching into account when running SSL compatibility tests (dri=matt)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q4Goals&diff=1042206SecurityEngineering/2014/Q4Goals2014-12-17T18:52:39Z<p>Sidstamm: /* Tracking Protection */ update status</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
== Content Security ==<br />
;Outcome: More robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Sid, Francois, Steve<br />
* {{risk|Add LoadInfo to Gecko-owned JS callers}} (dri=ckerschb,tanvi)<br />
* {{done|Use LoadInfo to implement MCB for HTTP redirects}} (dri=tanvi)<br />
* {{done|Implement Next Block of CSP Level 2.0 features}} (dri=sstamm,ckerschb)<br />
** Work to fix spec to have child-src directive we want<br />
** Implement form-action directive<br />
** Implement referrer directive (depends on {{bug|704320}})<br />
** Fix frame-ancestors mapping<br />
** Work to fix spec about blob urls<br />
* {{ok|Initial Implementation of sub-resource integrity}} ({{bug|992096}}) (dri=francois)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Sid<br />
* {{done|Finish <meta> referrer}} (dri=sid)<br />
<br />
== Addon Security ==<br />
Desired Outcome: TBD<br />
<br />
Goals: <br />
* TBD (dri=dveditz)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks. <br />
;Who: Richard, Kathleen, Keeler, Monica, JC, Mark<br />
<br />
* {{new|Add more BR checking}} (some combination of giving errors during path building, wall of shame, console warnings -- tbd) (dri=dkeeler)<br />
* {{new|Identify what of Certificate Transparency we must/should deploy}} (dri=rbarnes)<br />
* {{new|Complete phase 1 of migration to CA database}} (dri=kwilson)<br />
* {{new|[stretch] Import mozilla::pkix to a branch of NSS}} (dri=jcjones)<br />
* {{new|[stretch] Add ability to name constrain more root CAs}} (dri=dkeeler)<br />
* {{new|[stretch] Add security warnings about SHA-1 to Web Console}} (dri=mgoodwin)<br />
<br />
== QE (tracking) ==<br />
We also track security related QE goals. (section owner=mwobensmith)<br />
;Official list : (link TBD)<br />
* Tool telemetry of SSL errors/over-rides to watch for outliers, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1058812#c42 (dri=matt)<br />
* https://lists.mozilla.org/listinfo/dev-telemetry-alerts<br />
* Setup SSL compatibility testing to be run at the beginning of Beta for each branch. (dri=matt)<br />
* Figure out how to take the cert caching into account when running SSL compatibility tests (dri=matt)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q4Goals&diff=1042204SecurityEngineering/2014/Q4Goals2014-12-17T18:52:23Z<p>Sidstamm: /* Content Security */ update goals</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
== Content Security ==<br />
;Outcome: More robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Sid, Francois, Steve<br />
* {{risk|Add LoadInfo to Gecko-owned JS callers}} (dri=ckerschb,tanvi)<br />
* {{done|Use LoadInfo to implement MCB for HTTP redirects}} (dri=tanvi)<br />
* {{done|Implement Next Block of CSP Level 2.0 features}} (dri=sstamm,ckerschb)<br />
** Work to fix spec to have child-src directive we want<br />
** Implement form-action directive<br />
** Implement referrer directive (depends on {{bug|704320}})<br />
** Fix frame-ancestors mapping<br />
** Work to fix spec about blob urls<br />
* {{ok|Initial Implementation of sub-resource integrity}} ({{bug|992096}}) (dri=francois)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Sid<br />
* {{prev|Finish <meta> referrer}} (dri=sid)<br />
<br />
== Addon Security ==<br />
Desired Outcome: TBD<br />
<br />
Goals: <br />
* TBD (dri=dveditz)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks. <br />
;Who: Richard, Kathleen, Keeler, Monica, JC, Mark<br />
<br />
* {{new|Add more BR checking}} (some combination of giving errors during path building, wall of shame, console warnings -- tbd) (dri=dkeeler)<br />
* {{new|Identify what of Certificate Transparency we must/should deploy}} (dri=rbarnes)<br />
* {{new|Complete phase 1 of migration to CA database}} (dri=kwilson)<br />
* {{new|[stretch] Import mozilla::pkix to a branch of NSS}} (dri=jcjones)<br />
* {{new|[stretch] Add ability to name constrain more root CAs}} (dri=dkeeler)<br />
* {{new|[stretch] Add security warnings about SHA-1 to Web Console}} (dri=mgoodwin)<br />
<br />
== QE (tracking) ==<br />
We also track security related QE goals. (section owner=mwobensmith)<br />
;Official list : (link TBD)<br />
* Tool telemetry of SSL errors/over-rides to watch for outliers, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1058812#c42 (dri=matt)<br />
* https://lists.mozilla.org/listinfo/dev-telemetry-alerts<br />
* Setup SSL compatibility testing to be run at the beginning of Beta for each branch. (dri=matt)<br />
* Figure out how to take the cert caching into account when running SSL compatibility tests (dri=matt)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q4Goals&diff=1025932SecurityEngineering/2014/Q4Goals2014-10-16T18:46:26Z<p>Sidstamm: /* Content Security */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
== Content Security ==<br />
;Outcome: More robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid, Francois<br />
* {{new|Add LoadInfo to Gecko-owned JS callers}} (dri=ckerschb,tanvi)<br />
* {{new|Use LoadInfo to implement MCB for HTTP redirects}} (dri=tanvi)<br />
* {{new|Implement Next Block of CSP Level 2.0 features}} (dri=sstamm,ckerschb)<br />
** Work to fix spec to have child-src directive we want<br />
** Implement form-action directive<br />
** Implement referrer directive (depends on {{bug|704320}})<br />
** Fix frame-ancestors mapping<br />
** Work to fix spec about blob urls<br />
* {{new|Initial Implementation of sub-resource integrity}} ({{bug|992096}}) (dri=francois)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Sid<br />
* {{prev|Finish <meta> referrer}} (dri=sid)<br />
<br />
== Addon Security ==<br />
Desired Outcome: TBD<br />
<br />
Goals: <br />
* TBD (dri=dveditz)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks. <br />
;Who: Richard, Kathleen, Keeler, Monica, JC, Mark<br />
<br />
* {{new|Add more BR checking}} (some combination of giving errors during path building, wall of shame, console warnings -- tbd) (dri=dkeeler)<br />
* {{new|Identify what of Certificate Transparency we must/should deploy}} (dri=rbarnes)<br />
* {{new|Complete phase 1 of migration to CA database}} (dri=kwilson)<br />
* {{new|[stretch] Import mozilla::pkix to a branch of NSS}} (dri=jcjones)<br />
* {{new|[stretch] Add ability to name constrain more root CAs}} (dri=dkeeler)<br />
* {{new|[stretch] Add security warnings about SHA-1 to Web Console}} (dri=mgoodwin)<br />
<br />
== QE (tracking) ==<br />
We also track security related QE goals. (section owner=mwobensmith)<br />
;Official list : (link TBD)<br />
* Tool telemetry of SSL errors/over-rides to watch for outliers, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1058812#c42 (dri=matt)<br />
* https://lists.mozilla.org/listinfo/dev-telemetry-alerts<br />
* Setup SSL compatibility testing to be run at the beginning of Beta for each branch. (dri=matt)<br />
* Figure out how to take the cert caching into account when running SSL compatibility tests (dri=matt)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q4Goals&diff=1024560SecurityEngineering/2014/Q4Goals2014-10-13T17:12:33Z<p>Sidstamm: </p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
== Content Security ==<br />
;Outcome: More robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid, Francois<br />
* {{new|Add LoadInfo to Gecko-owned JS callers}} (dri=ckerschb,tanvi)<br />
* {{new|Use LoadInfo to implement MCB for HTTP redirects}} (dri=tanvi)<br />
* {{new|Implement Next Block of CSP Level 2.0 features}} (dri=sstamm,ckerschb)<br />
** (Will be more tightly scoped once Chris & Sid have time to nail down the subfeature list)<br />
* {{new|Initial Implementation of sub-resource integrity}} ({{bug|992096}}) (dri=francois)<br />
<br />
<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Sid<br />
* {{prev|Finish <meta> referrer}} (dri=sid)<br />
<br />
== Addon Security ==<br />
Desired Outcome: TBD<br />
<br />
Goals: <br />
* TBD (dri=dveditz)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks. <br />
;Who: Richard, Kathleen, Keeler, Monica, JC, Mark<br />
<br />
* {{new|Add more BR checking}} (some combination of giving errors during path building, wall of shame, console warnings -- tbd) (dri=dkeeler)<br />
* {{new|Identify what of Certificate Transparency we must/should deploy}} (dri=rbarnes)<br />
* {{new|Complete phase 1 of migration to CA database}} (dri=kwilson)<br />
* {{new|[stretch] Import mozilla::pkix to a branch of NSS}} (dri=jcjones)<br />
* {{new|[stretch] Add ability to name constrain more root CAs}} (dri=dkeeler)<br />
* {{new|[stretch] Add security warnings about SHA-1 to Web Console}} (dri=mgoodwin)<br />
<br />
== QE (tracking) ==<br />
We also track security related QE goals. (section owner=mwobensmith)<br />
;Official list : (link TBD)<br />
* Tool telemetry of SSL errors/over-rides to watch for outliers, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1058812#c42 (dri=matt)<br />
* https://lists.mozilla.org/listinfo/dev-telemetry-alerts<br />
* Setup SSL compatibility testing to be run at the beginning of Beta for each branch. (dri=matt)<br />
* Figure out how to take the cert caching into account when running SSL compatibility tests (dri=matt)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q4Goals&diff=1024557SecurityEngineering/2014/Q4Goals2014-10-13T17:08:28Z<p>Sidstamm: Created page with "__NOTOC__ This is a heavy-Implement quarter (as opposed to the other strategic actions in our SecurityEngineering/Strategy). (Also linked from Platform/2014-Q4-Goals#S..."</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
(Also linked from [[Platform/2014-Q4-Goals#Security_.26_Privacy_Engineering]]).<br />
<br />
== Content Security ==<br />
;Outcome: More robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid, Francois<br />
* {{new|Add LoadInfo to Gecko-owned JS callers}} (dri=ckerschb,tanvi)<br />
* {{new|Use LoadInfo to implement MCB for HTTP redirects}} (dri=tanvi)<br />
* {{new|Implement Next Block of CSP Level 2.0 features}} (dri=sstamm,ckerschb)<br />
** (Will be more tightly scoped once Chris & Sid have time to nail down the subfeature list)<br />
* {{new|Initial Implementation of sub-resource integrity}} ({{bug|992096}}) (dri=francois)<br />
<br />
<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Sid<br />
* {{prev|Finish <meta> referrer}} (dri=sid)<br />
<br />
== Addon Security ==<br />
Desired Outcome: TBD<br />
<br />
Goals: <br />
* TBD (dri=dveditz)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks. <br />
;Who: Richard, Kathleen, Keeler, Monica, JC, Mark<br />
<br />
* {{new|Add more BR checking}} (some combination of giving errors during path building, wall of shame, console warnings -- tbd) (dri=dkeeler)<br />
* {{new|Identify what of Certificate Transparency we must/should deploy}} (dri=rbarnes)<br />
* {{new|Complete phase 1 of migration to CA database}} (dri=kwilson)<br />
* {{new|[stretch] Import mozilla::pkix to a branch of NSS}} (dri=jcjones)<br />
* {{new|[stretch] Add ability to name constrain more root CAs}} (dri=dkeeler)<br />
* {{new|[stretch] Add security warnings about SHA-1 to Web Console}} (dri=mgoodwin)<br />
<br />
== QE (tracking) ==<br />
We also track security related QE goals. (section owner=mwobensmith)<br />
;Official list : (link TBD)<br />
* Tool telemetry of SSL errors/over-rides to watch for outliers, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1058812#c42 (dri=matt)<br />
* https://lists.mozilla.org/listinfo/dev-telemetry-alerts<br />
* Setup SSL compatibility testing to be run at the beginning of Beta for each branch. (dri=matt)<br />
* Figure out how to take the cert caching into account when running SSL compatibility tests (dri=matt)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=Platform/2014-Q3-Goals&diff=1021918Platform/2014-Q3-Goals2014-10-02T20:56:56Z<p>Sidstamm: /* Security & Privacy Engineering */</p>
<hr />
<div>=== Platform ===<br />
==== [[Platform/2014-Goals|2014 General Goals]] ====<br />
<br />
=== GFX ===<br />
Items marked [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AnKFEBp1-VyqdFNfRlZmV0ExM0VvZGMxNThWX0d6LWc&usp=drive_web#gid=0 here] with release 33 and 34 are part of the Q3 landings.<br />
<br />
=== Layout ===<br />
* Layout to Moz2D<br />
** {{ok|Migrate SVG to Moz2D (bug 703159) }}<br />
<br />
* Enable Vertical Text for major use cases for Chinese & Japanese<br />
** {{miss|{{bug|145503}}}} - Meta Bug. We've made lots of progress, but our big bug won't get closed until Q4<br />
** {{done|{{bug|789096}}}} - Layout with horizontal block flow and vertical text flow<br />
** {{miss|{{bug|902762}}}} - Vertical text run creation. Needs r+ and landed.<br />
** {{miss|{{bug|1062963}}}} - Make nsFloatManager use logical coordinates. Working through remaining test failures.<br />
<br />
* Text Performance<br />
** We'll get 1 of the 3 we wanted to hit.<br />
** {{done|{{bug|998869}}}} Streamline parsing of fontlists and improve efficiency of font matching code (note: unicode-range support will fall out of this work)<br />
** {{miss|{{bug|934770}}}} - slow at rendering large blocks of plain text<br />
** {{miss|{{bug|860492}}}} - Divide large text runs into smaller runs to avoid chrome hangs<br />
<br />
* Improve Restyling Performance<br />
** {{done|{{bug|977991}}}}<br />
** {{done|{{bug|931668}}}} - (not originally listed for this quarter, but carryover from previous)<br />
<br />
* {{drop|Font Inflation and Reflow-on-Zoom }}<br />
** We picked up scrolling features/fixes in Q3 and deferred this item<br />
** both implementation bug fixing and spec work<br />
** -moz-text-size-adjust <br />
<br />
* ImageLib<br />
** {{ok|RasterImage for multiple images}}<br />
*** {{done|prerequisite draw API refactoring}} {{bug|1043560}}<br />
*** {{done|store imgFrame objects in the imagelib SurfaceCache}} {{bug|1054079}}<br />
*** {{done|use #1: HQ scaled frames in the surface cache}} {{bug|1060200}}<br />
*** {{ok|use #2: store multiple decode options in surface cache for non-animated images}}<br />
*** {{risk|use #3: store multiple decode options in surface cache for animated images}}<br />
<br />
* CSS Projects with Adobe<br />
** {{done|CSS Filters}}<br />
<br />
* Animations & Transitions<br />
** {{risk|transitions/animations spec editing}}<br />
** {{risk|transitions refactoring to match new spec}} <br />
*** {{done|{{bug|996796}}}} landed, but work is ongoing for {{bug|960465}}<br />
** {{done|frame reconstruction (625289)}}<br />
** {{risk|Effective start of CSS animations and transitions {{bug|927349}}}}<br />
*** may spill into Q4<br />
<br />
* OMTA on non-B2G Platforms (980770)<br />
** {{risk|fix correctness bugs (cascading, etc.)}}<br />
*** partly done in {{bug|996796}}, but cascading fix likely miss<br />
** {{risk|turning on on other OMTC platforms (Mac/Android)}}<br />
<br />
* Web animations: <br />
** {{done|Get basic implementation of GetAnimationPlayers {{bug|1032573}}}}<br />
** {{risk|Implement PlaybackControl() {{bug|1033114}}}}<br />
*** may spill into Q4<br />
<br />
* CSS Scrolling<br />
** {{ok|CSS scroll snapping}}<br />
** {{ok|scroll-behavior:smooth}}<br />
<br />
* CSS Flexbox <br />
** {{ok|performance bugs}}<br />
*** significant improvement on {{bug|946167}}, though more to do<br />
** {{ok|spec changes}}<br />
*** completed {{bug|984711}}/{{bug|1037177}}/{{bug|1015474}} on min-width/height: auto<br />
*** completed {{bug|1032922}} and followups on flex-basis: main-size rename<br />
*** abs-pos handling at-risk (picked up object-fit/position instead)<br />
<br />
* CSS Ruby <br />
** Our intern got through a bunch of this, but we'll continue it next quarter; remaining work tracked in {{bug|css-ruby}} and {{bug|enable-css-ruby}}<br />
** {{done|style system support}}<br />
** {{done|frame construction}}<br />
** {{done|anonymous box handling}}<br />
** {{done|reflow architecture and horizontal positioning}}<br />
** {{miss|line breaking}}<br />
** {{miss|vertical positioning}}<br />
** {{miss|other dependencies on enabling the feature}}<br />
<br />
=== Media ===<br />
* {{miss|Enable YouTube MSE/VP9 for Firefox 33 in Nightly/Aurora {{bug|1000686}}}}<br />
* {{miss|Enable YouTube MSE/MP4 on Windows and Firefox OS for Firefox 34}}<br />
<br />
'''Detailed Breakdown'''<br />
* MSE Common<br />
** {{done|Rate adaption/buffer switching, reseting}}<br />
** {{miss|Seeking into unbuffered ranges {{bug|1056440}}}}<br />
** {{todo|Eviction/pinning}}<br />
* MSE WebM<br />
** {{done|WebM segment parser {{bug|881512}}{{bug|1044498}}}}<br />
* MSE MP4<br />
** {{done|MP4 segment parser {{bug|1027875}}{{bug|1057203}}}}<br />
** MP4 Demuxer<br />
*** {{done|Integrate stagefright MP4 demuxer {{bug|908503}}}}<br />
*** {{done|Accurate range reporting {{bug|1045909}}}}<br />
*** {{done|CENC support {{bug|1022434}}}}<br />
*** {{todo|DASHIF and other players aside from YouTube {{bug|1039149}}}}<br />
** H.264/AAC Decoder<br />
*** {{done|MP4/fMP4 platform decoder module for Mac OSX {{bug|941296}}}}<br />
*** {{miss|MP4 support on Firefox OS {{bug|1060900}}}}<br />
**** {{done|MP4 platform decoder module for Firefox OS {{bug|941302}}}}<br />
**** {{miss|Use a single shared decoder for MSE on b2g {{bug|1036849}}}}<br />
<br />
=== DOM ===<br />
* {{done|Mirror prototype of DOM objects through xray wrappers ({{bug|787070}}, peterv)}}<br />
* {{drop|Remove nsDOMClassInfo.cpp}}<br />
** Given the recent focus on e10s, we have not been pushing on this at this point.<br />
* {{done|Make less-privileged non-Xrayable unwaived opaque from privileged code (bholley, {{bug|856067}})}}<br />
* {{done|Route all JSContext pushing through AutoJSAPI and Implement GetEntryGlobal (bobowen, bholley, {{bug|951991}})}}<br />
* {{miss|Land <picture> preffed on on nightly ({{bug|1017875}}) (johns)}}<br />
** 99% done, but John got pulled into e10s plugin work ({{bug|874016}}) but made excellent progress here and was ''very'' close to preffing on by the end of Q3.<br />
* {{done|audit callsites of IsInDoc()/GetCurrentDoc to ensure correct Shadow DOM behaviour and fix Shadow DOM blockers for Gaia (smaug, wchen) ({{bug|1026047}})}}<br />
* {{miss|land Service Workers preffed off on nightly (nsm, bkelly, baku) ({{bug|903441}})}}<br />
** This is progressing well, but won't be *done* until the end of the quarter, so still on track.<br />
** Note that originally we thought things would be at the point where Gecko and Blink would be far enough along with a stable spec that this could be preffed on. That is not going to be the case but we are still aiming to have a usable implementation preffed off.<br />
** There remain spec questions about Cache which have impacted the design of our implementation.<br />
** We are focusing on [https://tbpl.mozilla.org/?tree=Maple Maple] being usable for getting feedback.<br />
<br />
=== WebAPI ===<br />
* {{done|create design plan for "share" activity (flow, what kind of objects are involved) (annevk)}}<br />
** https://wiki.whatwg.org/wiki/Sharing<br />
* {{miss|document existing activities usage in gaia (ehsan)}}<br />
** this work is underway but it's not yet complete<br />
* {{miss|get [https://w3c.github.io/screen-orientation/ screen orientation spec] to LC (marcosc)}}<br />
** all work was done here but a blocker was discovered late in the game<br />
** the blocker for this is now the animation task source which is currently underdefined and is being worked on as a part of the [https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen fullscreen API] (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=26440)<br />
* {{done|publish [http://www.w3.org/TR/wake-lock-use-cases/ use cases for wake locks] (marcosc)}}<br />
* {{miss|publish spec for [http://w3c.github.io/wake-lock/ "wakelock" API] (marcosc)}}<br />
** there is a spec but it got held up on making WebIDL attributes observable<br />
** current status is that others in the community make pick this up and drive it forward<br />
* {{done|24/12 hour format API (ehsan) {{bug|903683}}}}<br />
* {{miss|{{bug|942542}} new quota API on PBackground for Service Worker cache (janv)}}<br />
** this is up for review but won't land before the end of Q3<br />
* {{miss|{{bug|701634}} IndexedDB in workers (bent)}}<br />
** the majority of this work was done with {{bug|994190}} to get main thread IDB using PBackground but the remaining work to get IndexedDB available on workers did not make it<br />
<br />
=== JS ===<br />
* {{miss|ES6 classes: }}{{Bug|837314}} <br />
* {{jok|1020751}} Generational GC on Firefox OS<br />
* {{jok|650161}} Compacting GC to reduce memory usage<br />
* {{jok|856533}} Escape analysis JIT optimizations<br />
* {{done|Use Latin1 strings to reduce memory usage: }}{{Bug|998392}} <br />
* {{jok|903519}} Allocate strings in GC nursery (for performance)<br />
* {{miss|ARM64 JIT ''[stretch goal]'': }} {{Bug|972710}}<br />
<br />
=== Accessibility ===<br />
* {{miss|}}e10s: proxy the common a11y API stuff like name, role, and states.<br />
** Decent progress with unlanded patches including some event work.<br />
* {{done|}}GAIA: Fix [https://bugzilla.mozilla.org/buglist.cgi?priority=--&f1=blocked&list_id=10674217&o1=anyexact&resolution=---&query_based_on=b2ga11y%20p%3D1&o2=substring&query_format=advanced&f2=status_whiteboard&v1=893789&component=Disability%20Access%20APIs&component=Gaia&component=Gaia%3A%3ABluetooth%20File%20Transfer&component=Gaia%3A%3ABrowser&component=Gaia%3A%3ABuild&component=Gaia%3A%3ACalendar&component=Gaia%3A%3ACamera&component=Gaia%3A%3AClock&component=Gaia%3A%3AContacts&component=Gaia%3A%3ACost%20Control&component=Gaia%3A%3ADialer&component=Gaia%3A%3AE-Mail&component=Gaia%3A%3AEverything.me&component=Gaia%3A%3AFirst%20Time%20Experience&component=Gaia%3A%3AFMRadio&component=Gaia%3A%3AGallery&component=Gaia%3A%3AGithubBot&component=Gaia%3A%3AHomescreen&component=Gaia%3A%3AKeyboard&component=Gaia%3A%3AL10n&component=Gaia%3A%3ALoop&component=Gaia%3A%3AMusic&component=Gaia%3A%3ANotes&component=Gaia%3A%3APDF%20Viewer&component=Gaia%3A%3APerformanceTest&component=Gaia%3A%3ARingtones&component=Gaia%3A%3ASearch&component=Gaia%3A%3ASettings&component=Gaia%3A%3ASMS&component=Gaia%3A%3ASystem&component=Gaia%3A%3ASystem%3A%3ABrowser%20Chrome&component=Gaia%3A%3ASystem%3A%3AInput%20Mgmt&component=Gaia%3A%3ASystem%3A%3ALockscreen&component=Gaia%3A%3ASystem%3A%3AWindow%20Mgmt&component=Gaia%3A%3ATestAgent&component=Gaia%3A%3AUI%20Tests&component=Gaia%3A%3AVideo&component=Gaia%3A%3AWallpaper&component=Gaia%3A%3AWappush&v2=b2ga11y%20p%3D1&product=Core&product=Firefox%20OS all Gaia P1 a11y bugs] (~30 at this time).<br />
** 49 (all) are fixed.<br />
* {{done|}}FFOS: {{Bug|1030465}} - Volume change should update the screen reader volume.<br />
* {{done|}}FFOS: {{Bug|1030466}} - Headphones screen reader volume is too low.<br />
* {{done|}}FFOS: {{Bug|1030468}} - VC rectangle needs to work with scaled content.<br />
* {{done|}}FFOS: {{Bug|1030470}} - Localization needs to work when switching locales in FxOS.<br />
<br />
=== Perf ===<br />
<br />
Fix major source of browser jank:<br />
<br />
* {{done|(milestone reached, work continues in Q4) Initialize plugin instances asynchronously {{bug|998863}} }}<br />
* {{miss|('''Blocked on external dependencies + unplanned newtab page work took precedence''') Pause heavy main-thread activities while user is interacting with the browser: }}<br />
** {{miss|Determine when a user is actively interacting with the browser}}<br />
** {{miss|Detect when jank occurs during interactions and report to Telemetry {{bug|1017055}} }}<br />
** {{miss|Experiment with hinting to GC & CC that they should pause while the user is interacting with the browser}}<br />
* {{done|(refactoring work continues) Help Frontend team with Places refactoring, eliminate some of the [http://telemetry.mozilla.org/slowsql/ Places main-thread SQL] reported to Telemetry }}<br />
* {{done|Don't store UI customization in localstore.rdf, use off-main thread JSON instead {{bug|559505}} }}<br />
<br />
Improve Firefox startup (identified as a top issue in user research):<br />
<br />
* {{done|Reduce appearance of the "profile is in use" message on startup {{bug|286355}} }}<br />
* {{defer|Restore windows one by one during session-restore {{bug|1034534}} and/or load windows by descending z-order {{bug|1034036}} }}<br />
* {{done|C++ version of AsyncShutdown {{bug|918317}} }}<br />
<br />
Prevent performance regressions:<br />
<br />
* {{done|Implement automatic detection & alerting for Telemetry regressions {{bug|1031032}} }}<br />
* {{done|Help developers understand & diagnose Talos regressions}}, e.g. [https://bugzilla.mozilla.org/show_bug.cgi?id=1026550 Firefox 33 regression tracking], [https://bugzilla.mozilla.org/show_bug.cgi?id=1004427 Firefox 32 regressions], [https://bugzilla.mozilla.org/show_bug.cgi?id=990085 Firefox 31]<br />
<br />
Grow community:<br />
<br />
* {{done|Mentor at least 5 external contributors}}<br />
<br />
=== Networking ===<br />
<br />
* {{miss|Ship Network Predictor ("Seer") on nightly, using HTTP cache instead of SQLite ({{bug|1009122}}) (hurley)}}<br />
** Well-underway, but not done yet. Rolling over to Q4.<br />
* {{done|Ship current (hopefully final) IETF version of HTTP/2 preffed on in nightly (hurley)}}<br />
** HTTP/2 is done and we've shipped it. This is a big deal.<br />
* {{done|HTTP/2 "alt-svc" support ({{bug|1003448}}) (mcmanus)}}<br />
* {{drop|HTTP cache: determine if revalidation is needed w/o doing I/O ({{bug|983122}}) (sworkman) }}<br />
** We didn't have the cycles to even start on this: decided it wasn't mission-critical.<br />
* {{done|Network up/down link detection on all platforms ({{bug|939318}}) (bagder) }}<br />
* {{drop|Implement WebSocket compression extension ({{bug|792831}}) (michal) }}<br />
** Too much cache work remained for Michal to start on this. Also not mission-critical.<br />
<br />
=== Mobile ===<br />
<br />
=== A*Team ===<br />
<br />
For full list, see [[Auto-tools/Goals/2014Q3|A-Team Goals 2014Q3]]<br />
<br />
'''B2G'''<br />
* {{drop|}} (moved to B2G team) Run a set of performance and correctness tests per-commit to b2g-inbound on Flame devices<br />
* {{drop|}} (moved to B2G team) Get gaia-integration tests running on device<br />
* {{done|}} Expand the FxOS Certification Suite with 1.4 support, test automation to prevent regressions, and investigation of support for non-phone devices<br />
* {{done|}} Green up B2G tests on TaskCluster (joint with RelEng)<br />
<br />
'''Developer Productivity'''<br />
* {{miss|}} Deploy ReviewBoard for developers to start using (joint with RelEng)<br />
** Primary dev on medical leave for a month; will be finished early q4.<br />
<br />
'''Performance'''<br />
* {{done|}} Deploy new Talos tests for tp5o_scroll, webgl, webrtc, and mainthread I/O<br />
* {{done|}} Get Datazilla alerts to beta mode (full parity with graph server alerts) with reduced noise<br />
* {{done|}} Get Eideticker running against Android again with increased frequency<br />
* {{done|}} Run B2G Eideticker against same branch/build combinations as our other on-device perf tests<br />
* {{done|}} Stand up a Games Benchmarking system for webaudio tests running against Firefox and Chrome<br />
<br />
'''Treeherder'''<br />
* {{done|}} Deliver performance web service for ingesting and returning performance data <br />
* {{miss|}} Deliver a UI for viewing Talos data<br />
<br />
'''Sheriffing'''<br />
* {{done|}} Fully transition sheriffing from TBPL to Treeherder<br />
<br />
'''General Automation'''<br />
* {{done|}} Create weekly reports that describe how many tests have been added/disabled/enabled per suite and platform<br />
* {{done|}} Move reftest to mozbase<br />
* {{done|}} Add command executors for Marionette for Java and Python<br />
<br />
'''Bugzilla'''<br />
* {{done|}} Improve load time of related bugs; can decrease show_bug load times by up to 12%<br />
* {{done|}} Minify and concatenate JS files<br />
* {{done|}} Authoritative view for review history<br />
* {{done|}} Rewrite docs for REST API<br />
<br />
'''Community'''<br />
* {{done|}} Create good_next_bugs (name can be adjusted) so once contributors are comfortable they can do more serious coding/problem solving on a project they are familiar with<br />
* {{done|}} Monthly review of mentored bugs and projects<br />
<br />
=== Web Engineering ===<br />
'''Crash stats'''<br />
* {{done|}} Prototype service for identifying post-crash user actions<br />
* {{done|}} Hardware and performance tuning for new primary data store<br />
* {{done|}} Remove older, redundant crash storage format from database<br />
* {{drop|}} Improve search performance and features<br />
** API changes in the underlying tech made this much more complicated that originally estimated. Will be carried over to next Q.<br />
* {{done|}} Replace interfaces to deprecated external data sources<br />
* {{done|}} Remove barriers to community installations<br />
'''FHR'''<br />
* {{done|}} Support search diversion plan<br />
'''DXR'''<br />
* {{done|}} Improve infrastructure.<br />
** Switched back end to Elasticsearch, paving the way for [https://wiki.mozilla.org/DXR_Parallel_Tree_Indexing concurrent, independent tree indexing].<br />
** Freed codebase of C++ assumptions.<br />
** Completely [http://dxr.readthedocs.org/en/es/development.html#writing-plugins new plugin API] supporting multiple languages, multi-core indexing, request-time analysis, binary file handling, and plugins living outside the DXR source tree<br />
** Added an official DXR submodule, complete with 3 module peers.<br />
** Rewrite search controller, which was always complete spaghetti. We now have a genuine HTTP API!<br />
** Upgrade Vagrant VM to a LTS release of Ubuntu.<br />
** Render folder views at request time, a pilot for doing this with file view as well (which will save hundreds of GB of expensive NetApp space and, more importantly, speed indexing so we can do it more often).<br />
* {{done|}} Broaden our audience.<br />
** Added indexing for several releng trees.<br />
** Rewrote developer documentation ([https://dxr.readthedocs.org dxr.readthedocs.org]), bringing in about 2 new contributors per week.<br />
** Rewrite query machinery to do "and" searches as people expect rather than the weird and-or hybrid it used to do.<br />
** Added macro and typedef direct search.<br />
** Added Google Analytics so we can measure our use.<br />
** Rewrote highlighting support, fixing myriad UI bugs.<br />
** Basic JS analysis 75% done. Rust analysis in progress.<br />
'''l10n'''<br />
* {{done|}} Get l10n build logs into a searchable data store<br />
* {{miss|}} Replace some buildbot functionality with a10n automation<br />
** a10n work got pushed out because of firefighting to unblock other goals. Estimated 3 weeks away. Will carry over<br />
'''Air Mozilla'''<br />
* {{done|}} Prototype support for streaming media boxes<br />
* {{done|}} Improve desktop user experience<br />
<br />
[https://etherpad.mozilla.org/webeng-q32014 full list]<br />
<br />
=== SUMO and Input ===<br />
* {{done|}} SUMO: Launch new offline SUMO app [Get Firefox on a Growth Trajectory]<br />
* {{done|}} SUMO: Develop new Community Hub to a level where it can replace legacy Karma app [Enable Communities with Impact]<br />
* {{done|}} SUMO: Research and prototype new experimental features (e.g. geotargeting, Instant Search, Search Suggestions) [Get Firefox on a Growth Trajectory]<br />
<br />
* {{done|}} Input: Improve documentation and install to lower the bar for contribution ([[Firefox/Input/Reduce Contributor Pain]]) [Enable Communities with Impact]<br />
* {{done|}} Input: Support Heartbeat ([[Firefox/Input/Heartbeat]]) [Get Firefox on a Growth Trajectory]<br />
* {{risk|}} Input: Dashboards for Everyone ([[Firefox/Input/Dashboards for Everyone]]) [Get Firefox on a Growth Trajectory] (half-done, just needs finishing work, but that keeps getting bumped by high-priority must-be-done-now stuff; think I can finish by october 10th)<br />
<br />
=== Release Engineering - Laura ===<br />
* {{drop|}} Enable capacity expansion for bare-metal releng OS X build and test slaves via hardware provided by third-party datacenters (Get Firefox on a Trajectory of Growth) - dropped early on. Third parties are not "there yet" and cost more.<br />
* {{done|}} Simplify release engineering mobile hardware infrastructure (Get Firefox on a Trajectory of Growth)<br />
* {{miss|}} Automate developer access to continuous integration resources to expedite debugging and standing up new job variants. (Enable Communities With Impact) - Progressed a lot. Almost ready for releng to use internally.<br />
* {{done|}} Help enable video operability on the web by providing continuous integration for Cisco Open H.264 builds. (Get Firefox on a Trajectory of Growth)<br />
<br />
=== Release Engineering - Taras ===<br />
* {{done|}} Replace aging Firefox update service with a scalable, modern solution. (Get Firefox on a Trajectory of Growth) - Now on beta channel. release channel in early Q4<br />
* {{miss|}} Simplify developer workflow by automating patch landing and uplift. (Enable Communities With Impact) - Implementation done; needs secreview and final integration, deployment.<br />
* {{done|}} Optimize network transfers for build/test automation between datacenters. (Enable Communities With Impact)<br />
* {{miss|}} Continue AWS cost optimizations: EBS < 3% of AWS bill (vs 30% in Q2) (Enable Communities With Impact) - Missed primarily due to lost headcount. Reduced our EBS cost in September to 11% of total; more reductions to come in Q4.<br />
* {{drop|}} Improve developer workflow by migrating 80% of FirefoxOS build/test jobs to taskcluster (Enable Communities With Impact) - this goal is now with jlal in FirefoxOS<br />
* {{drop|}} Turn telemetry into a general purpose s3 ingester and analysis tool - this goal is now with mreid in Services<br />
<br />
=== Release Engineering Operations ===<br />
* Build/Test System Performance Enhancements<br />
** {{drop| Unify releng platform architecture, using common tools and best practices, to decrease complexity and enable smoother developer engagement {{bug|1026110}} [Get Firefox on a Trajectory of Growth, Enable Communities With Impact] - blocked on obtaining necessary resources from other groups }}<br />
** {{done| Improve communication and response time for releng network flow requests {{bug|1026112}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] }}<br />
** {{done| Improve security for all releng windows infrastructure {{bug|893716}} [Get Firefox on a Trajectory of Growth] }}<br />
** {{done| Update windows platform developer tools {{bug|1019165}} [Get Firefox on a Trajectory of Growth] }}<br />
* Build/Test System Self-Serve Re-architecture<br />
** {{done| Design a private cloud deployment architecture for bare metal and produce a POC that supports Ubuntu 12.04 test machines. {{bug|963165}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] - POC created, and openstack was deemed too buggy in its current unreleased state to be production ready }}<br />
** {{drop| Create self-service capability for releng hardware Firefox linux test slaves (build slaves as a stretch goal) {{bug|1026687}} (depends on completion of previous goal) [Get Firefox on a Trajectory of Growth, Scale Firefox OS] - bare metal openstack is proving to be too bleeding edge and buggy to use for production services. We will track changes made in the openstack code base and revist this in 9mo, but we will not move any services to production in FY2014 }}<br />
<br />
=== Developer Services ===<br />
* {{done|(with B-team) roll out phase 2 of new review tooling}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
* {{done|Upgrade existing Mercurial infrastructure to support more rapid, safe, and coordinated deployment of updates.}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
<br />
[https://etherpad.mozilla.org/devservices-Q32014 Full List]<br />
<br />
=== Security & Privacy Engineering ===<br />
More details here: [[SecurityEngineering/2014/Q3Goals]]<br />
<br />
'''Content Security'''<br />
* {{done|Gecko Security Hooks: Finish code and debugging for NS_NewChannel API, start getting reviews}} (dri=tanvi)<br />
* {{defer|Gecko Security Hooks: Create plan for addon compatibility -- doesn't make sense until New Channel API is done, deferring to next quarter when shimming the JS API for creating new channels}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central}} (dri=sstamm)<br />
* {{done|Evangelism: Security blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{miss|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs}}. Couldn't stretch. (dri=ckerschb)<br />
<br />
'''Tracking Protection'''<br />
* {{miss|Referer: Finish implementation of <meta> referrer control with volunteer help}}. Unexpected dependencies, will finish about two weeks late. (dri=sstamm)<br />
* {{done|Land first implementation of protection in Fx 33/34 off by default. BONUS: landed frontend code too}} (dri=mmc)<br />
<br />
'''Communications Security'''<br />
* {{done|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{done| HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{done| Update [[CA:RevocationPlan|roadmap for Cert Revocation improvements]]}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{done| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{done| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{risk| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{defer| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)<br />
* {{done| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
<br />
=== Firefox and Platform Security ===<br />
<br />
* {{done|[https://mana.mozilla.org/wiki/display/~gkwong@mozilla.com/Marifuzz Marifuzz ] fuzzer ported to and running on Flame devices.}}<br />
* {{done|Update ASan and LSan work for DOMFuzzer}}<br />
* Update "Bounty Stars" document with issues found by external reporters and updating DOMFuzzer to reflect these results.<br />
* {{done|Get Clang on RelEng ready for official OS X ASan builds.}} - Fuzzing team work is done. Waiting for Releng to update build system.<br />
* {{done|Initial work to move CoreFuzz towards running in cloud environments.}}<br />
* {{done|WebCrypto API fuzzing using Dharma fuzzer.}}<br />
* {{done|Port a portion of WebRTC fuzzing from Frambois fuzzer to Dharma fuzzer.}}<br />
* {{done|Peach: Improving and porting Peach 2 to Python 3.}}<br />
* {{done|Public Mozilla Security Github work: Moving of fuzzing tools from Fuzzing Hg to GitHub, including work to separate harnesses from testcase generation tools.}} - Only outlier is DOMFuzz because of Releng integration.<br />
<br />
=== Games Program ===<br />
* {{done| Reach out to 3rd party engines en masse (also for Q4)}}<br />
* {{ok| Select a 3D demo for mobile}}<br />
* {{done| Pick a partner demo to optimize for mobile}}<br />
* {{ok| Focus on supporting shipping games and maintaining platform stability }}<br />
* {{ok| Focus on Shared Array Buffer implementation }}<br />
* {{risk| WebGL Benchmarks}}<br />
* {{ok| Continue to work MDN documentation; get Emscripten documentation started }}<br />
* {{ok| GDC and MWC event support plan}}<br />
<br />
=== Release Management ===<br />
For full list, see [[Release_Management/Goals/2014Q3#Release_Management_General|Release Management 2014Q3 Goals]].<br />
* {{done|}} Create and document process for Desktop/Mobile feature fast tracking<br />
* {{done|}} Determine future of ESR and how to manage this channel<br />
** https://groups.google.com/forum/#!topic/mozilla.dev.planning/-IQWXs_zEp8<br />
* {{done|}} Continue desktop throttling experiment with intention of reducing throttled time while maintaining existing level of feedback<br />
** Throttling time currently reduced from 10 to 7 days. Experimenting with further reductions.<br />
* Improve release notes with revamped template for all products<br />
* {{done|}} Create B2G release model proposals and gather feedback for potential changes<br />
* {{miss|}} Figure out what to do with B2G Security Releases<br />
<br />
===Program Management===<br />
<br />
See this wiki page for a full list of [https://wiki.mozilla.org/Program_Management/Firefox/2014-Q3-Goals Program Management goals].<br />
<br />
* {{ok|Create a set of dashboards based on the ES database to track platform projects and surface bottlenecks.}}<br />
** Narrowed focus to a set of dashboards for review queues for individuals and teams. <br />
* {{risk|Brown bag presentation/restropective on the agile processes we are using on Desktop and FirefoxOS}}<br />
** With the reorg, revisiting the purpose/target. Might change this goal slightly. Still probably worthwhile planning a brown bag to talk about Desktop process and introduce Trello planning tool for Platform.<br />
* {{ok|Evaluate and produce a report on several tools for helping organize and visualize team backlogs and priority lists; wiki, spreadsheets, Trello, Kanbanize}}<br />
** Using a Trello board for Platform work. Jenn piloting Kanban board for Desktop/Android. Should have a summary, write-up ready by end of Sept.<br />
<br />
=== Quality Engineering ===<br />
See this wiki for the full list of [https://wiki.mozilla.org/QA/Goals/2014q3 Quality goals]. What follows are our brief summary of our internal improvement goals for each strategic team.<br />
* Firefox QA - Revitalize our Quality Engineering strategy by switching to a feature-based test strategy for all Firefox browser products so that there are test plans for each feature and testing is executed within two sprints of the feature's code landing<br />
* Firefox OS - Better metrics for quality analysis, provide opportunities for community contribution, and expanding the role of our on-device automation for reporting to Treeherder.<br />
* Services - Ensure new offerings have 98% uptime (FxA Sync, OAuth, FMD, Loop) and no more than 2 P1 bugs discovered post launch while building a core contributor base in services<br />
* Marketplace - Ensure Marketplace's new payments backend, in-app payments, and the Marketplace feed land with high quality releases.<br />
* Platform QA - Deploy into continuous integration a regression testing system for WebRTC along three areas of investigation: 1. "Smoke" tests, 2. Connection tests, and 3. Connection quality tests. These will be performed in a variety of environments, including various network topologies with various performance characteristics, connections between various versions of Firefox, and connections on multiple OS platforms. Test plans will be developed, and we will measure coverage of test plans. Results will be posted and available in Treeherder. We will also build backlog for next Platform Tiger Team tasks.<br />
* Community - Increase conversion of interested and casual contributors to help them become active contributors with strong ties to the QA community</div>Sidstammhttps://wiki.mozilla.org/index.php?title=Platform/2014-Q3-Goals&diff=1019439Platform/2014-Q3-Goals2014-09-29T21:21:41Z<p>Sidstamm: /* Security & Privacy Engineering */</p>
<hr />
<div>=== Platform ===<br />
==== [[Platform/2014-Goals|2014 General Goals]] ====<br />
<br />
=== GFX ===<br />
Items marked [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AnKFEBp1-VyqdFNfRlZmV0ExM0VvZGMxNThWX0d6LWc&usp=drive_web#gid=0 here] with release 33 and 34 are part of the Q3 landings.<br />
<br />
=== Layout ===<br />
* Layout to Moz2D<br />
** {{ok|Migrate SVG to Moz2D (bug 703159) }}<br />
<br />
* Enable Vertical Text for major use cases for Chinese & Japanese<br />
** {{miss|{{bug|145503}}}} - Meta Bug. We've made lots of progress, but our big bug won't get closed until Q4<br />
** {{done|{{bug|789096}}}} - Layout with horizontal block flow and vertical text flow<br />
** {{ok|{{bug|902762}}}} - Vertical text run creation<br />
** {{risk|{{bug|1062963}}}} - Make nsFloatManager use logical coordinates<br />
<br />
* Text Performance<br />
** We'll get 1 of the 3 we wanted to hit.<br />
** {{ok|{{bug|998869}}}} Streamline parsing of fontlists and improve efficiency of font matching code (note: unicode-range support will fall out of this work)<br />
** {{miss|{{bug|934770}}}} - slow at rendering large blocks of plain text<br />
** {{miss|{{bug|860492}}}} - Divide large text runs into smaller runs to avoid chrome hangs<br />
<br />
* Improve Restyling Performance<br />
** {{done|{{bug|977991}}}}<br />
** {{done|{{bug|931668}}}} - (not originally listed for this quarter, but carryover from previous)<br />
<br />
* {{drop|Font Inflation and Reflow-on-Zoom }}<br />
** We picked up scrolling features/fixes in Q3 and deferred this item<br />
** both implementation bug fixing and spec work<br />
** -moz-text-size-adjust <br />
<br />
* ImageLib<br />
** {{ok|RasterImage for multiple images}}<br />
*** {{done|prerequisite draw API refactoring}} {{bug|1043560}}<br />
*** {{done|store imgFrame objects in the imagelib SurfaceCache}} {{bug|1054079}}<br />
*** {{done|use #1: HQ scaled frames in the surface cache}} {{bug|1060200}}<br />
*** {{ok|use #2: store multiple decode options in surface cache for non-animated images}}<br />
*** {{risk|use #3: store multiple decode options in surface cache for animated images}}<br />
<br />
* CSS Projects with Adobe<br />
** {{done|CSS Filters}}<br />
<br />
* Animations & Transitions<br />
** {{risk|transitions/animations spec editing}}<br />
** {{risk|transitions refactoring to match new spec}} <br />
*** {{done|{{bug|996796}}}} landed, but work is ongoing for {{bug|960465}}<br />
** {{done|frame reconstruction (625289)}}<br />
** {{risk|Effective start of CSS animations and transitions {{bug|927349}}}}<br />
*** may spill into Q4<br />
<br />
* OMTA on non-B2G Platforms (980770)<br />
** {{risk|fix correctness bugs (cascading, etc.)}}<br />
*** partly done in {{bug|996796}}, but cascading fix likely miss<br />
** {{risk|turning on on other OMTC platforms (Mac/Android)}}<br />
<br />
* Web animations: <br />
** {{done|Get basic implementation of GetAnimationPlayers {{bug|1032573}}}}<br />
** {{risk|Implement PlaybackControl() {{bug|1033114}}}}<br />
*** may spill into Q4<br />
<br />
* CSS Scrolling<br />
** {{ok|CSS scroll snapping}}<br />
** {{ok|scroll-behavior:smooth}}<br />
<br />
* CSS Flexbox <br />
** {{ok|performance bugs}}<br />
*** significant improvement on {{bug|946167}}, though more to do<br />
** {{ok|spec changes}}<br />
*** completed {{bug|984711}}/{{bug|1037177}}/{{bug|1015474}} on min-width/height: auto<br />
*** completed {{bug|1032922}} and followups on flex-basis: main-size rename<br />
*** abs-pos handling at-risk (picked up object-fit/position instead)<br />
<br />
* CSS Ruby <br />
** Our intern got through a bunch of this, but we'll continue it next quarter; remaining work tracked in {{bug|css-ruby}} and {{bug|enable-css-ruby}}<br />
** {{done|style system support}}<br />
** {{done|frame construction}}<br />
** {{done|anonymous box handling}}<br />
** {{done|reflow architecture and horizontal positioning}}<br />
** {{miss|line breaking}}<br />
** {{miss|vertical positioning}}<br />
** {{miss|other dependencies on enabling the feature}}<br />
<br />
=== Media ===<br />
* {{miss|Enable YouTube MSE/VP9 for Firefox 33 in Nightly/Aurora {{bug|1000686}}}}<br />
* {{miss|Enable YouTube MSE/MP4 on Windows and Firefox OS for Firefox 34}}<br />
<br />
'''Detailed Breakdown'''<br />
* MSE Common<br />
** {{done|Rate adaption/buffer switching, reseting}}<br />
** {{miss|Seeking into unbuffered ranges {{bug|1056440}}}}<br />
** {{todo|Eviction/pinning}}<br />
* MSE WebM<br />
** {{done|WebM segment parser {{bug|881512}}{{bug|1044498}}}}<br />
* MSE MP4<br />
** {{done|MP4 segment parser {{bug|1027875}}{{bug|1057203}}}}<br />
** MP4 Demuxer<br />
*** {{done|Integrate stagefright MP4 demuxer {{bug|908503}}}}<br />
*** {{done|Accurate range reporting {{bug|1045909}}}}<br />
*** {{done|CENC support {{bug|1022434}}}}<br />
*** {{todo|DASHIF and other players aside from YouTube {{bug|1039149}}}}<br />
** H.264/AAC Decoder<br />
*** {{done|MP4/fMP4 platform decoder module for Mac OSX {{bug|941296}}}}<br />
*** {{miss|MP4 support on Firefox OS {{bug|1060900}}}}<br />
**** {{done|MP4 platform decoder module for Firefox OS {{bug|941302}}}}<br />
**** {{miss|Use a single shared decoder for MSE on b2g {{bug|1036849}}}}<br />
<br />
=== DOM ===<br />
* {{done|Mirror prototype of DOM objects through xray wrappers ({{bug|787070}}, peterv)}}<br />
* {{drop|Remove nsDOMClassInfo.cpp}}<br />
** Given the recent focus on e10s, we have not been pushing on this at this point.<br />
* {{done|Make less-privileged non-Xrayable unwaived opaque from privileged code (bholley, {{bug|856067}})}}<br />
* {{done|Route all JSContext pushing through AutoJSAPI and Implement GetEntryGlobal (bobowen, bholley, {{bug|951991}})}}<br />
* {{miss|Land <picture> preffed on on nightly ({{bug|1017875}}) (johns)}}<br />
** John got pulled into e10s plugin work ({{bug|874016}}) but made excellent progress here and was ''very'' close to preffing on by the end of Q3.<br />
* {{done|audit callsites of IsInDoc()/GetCurrentDoc to ensure correct Shadow DOM behaviour and fix Shadow DOM blockers for Gaia (smaug, wchen) ({{bug|1026047}})}}<br />
* {{miss|land Service Workers preffed off on nightly (nsm, bkelly, baku) ({{bug|903441}})}}<br />
** This is progressing well, but won't be *done* until the end of the quarter, so still on track.<br />
** Note that originally we thought things would be at the point where Gecko and Blink would be far enough along with a stable spec that this could be preffed on. That is not going to be the case but we are still aiming to have a usable implementation preffed off.<br />
** There remain spec questions about Cache which have impacted the design of our implementation.<br />
** We are focusing on [https://tbpl.mozilla.org/?tree=Maple Maple] being usable for getting feedback.<br />
<br />
=== WebAPI ===<br />
* {{done|create design plan for "share" activity (flow, what kind of objects are involved) (annevk)}}<br />
** https://wiki.whatwg.org/wiki/Sharing<br />
* {{miss|document existing activities usage in gaia (ehsan)}}<br />
** this work is underway but it's not yet complete<br />
* {{ok|get [https://w3c.github.io/screen-orientation/ screen orientation spec] to LC (marcosc)}}<br />
* {{done|publish [http://www.w3.org/TR/wake-lock-use-cases/ use cases for wake locks] (marcosc)}}<br />
* {{ok|publish spec for [http://w3c.github.io/wake-lock/ "wakelock" API] (marcosc)}}<br />
* {{done|24/12 hour format API (ehsan) {{bug|903683}}}}<br />
* {{miss|{{bug|942542}} new quota API on PBackground for Service Worker cache (janv)}}<br />
** this is up for review but won't land before the end of Q3<br />
* {{miss|{{bug|701634}} IndexedDB in workers (bent)}}<br />
** the majority of this work was done with {{bug|994190}} to get main thread IDB using PBackground but the remaining work to get IndexedDB available on workers did not make it<br />
<br />
=== JS ===<br />
* {{miss|ES6 classes: }}{{Bug|837314}} <br />
* {{jok|1020751}} Generational GC on Firefox OS<br />
* {{jok|650161}} Compacting GC to reduce memory usage<br />
* {{jok|856533}} Escape analysis JIT optimizations<br />
* {{done|Use Latin1 strings to reduce memory usage: }}{{Bug|998392}} <br />
* {{jok|903519}} Allocate strings in GC nursery (for performance)<br />
* {{miss|ARM64 JIT ''[stretch goal]'': }} {{Bug|972710}}<br />
<br />
=== Accessibility ===<br />
* {{miss|}}e10s: proxy the common a11y API stuff like name, role, and states.<br />
** Decent progress with unlanded patches including some event work.<br />
* {{done|}}GAIA: Fix [https://bugzilla.mozilla.org/buglist.cgi?priority=--&f1=blocked&list_id=10674217&o1=anyexact&resolution=---&query_based_on=b2ga11y%20p%3D1&o2=substring&query_format=advanced&f2=status_whiteboard&v1=893789&component=Disability%20Access%20APIs&component=Gaia&component=Gaia%3A%3ABluetooth%20File%20Transfer&component=Gaia%3A%3ABrowser&component=Gaia%3A%3ABuild&component=Gaia%3A%3ACalendar&component=Gaia%3A%3ACamera&component=Gaia%3A%3AClock&component=Gaia%3A%3AContacts&component=Gaia%3A%3ACost%20Control&component=Gaia%3A%3ADialer&component=Gaia%3A%3AE-Mail&component=Gaia%3A%3AEverything.me&component=Gaia%3A%3AFirst%20Time%20Experience&component=Gaia%3A%3AFMRadio&component=Gaia%3A%3AGallery&component=Gaia%3A%3AGithubBot&component=Gaia%3A%3AHomescreen&component=Gaia%3A%3AKeyboard&component=Gaia%3A%3AL10n&component=Gaia%3A%3ALoop&component=Gaia%3A%3AMusic&component=Gaia%3A%3ANotes&component=Gaia%3A%3APDF%20Viewer&component=Gaia%3A%3APerformanceTest&component=Gaia%3A%3ARingtones&component=Gaia%3A%3ASearch&component=Gaia%3A%3ASettings&component=Gaia%3A%3ASMS&component=Gaia%3A%3ASystem&component=Gaia%3A%3ASystem%3A%3ABrowser%20Chrome&component=Gaia%3A%3ASystem%3A%3AInput%20Mgmt&component=Gaia%3A%3ASystem%3A%3ALockscreen&component=Gaia%3A%3ASystem%3A%3AWindow%20Mgmt&component=Gaia%3A%3ATestAgent&component=Gaia%3A%3AUI%20Tests&component=Gaia%3A%3AVideo&component=Gaia%3A%3AWallpaper&component=Gaia%3A%3AWappush&v2=b2ga11y%20p%3D1&product=Core&product=Firefox%20OS all Gaia P1 a11y bugs] (~30 at this time).<br />
** 49 (all) are fixed.<br />
* {{done|}}FFOS: {{Bug|1030465}} - Volume change should update the screen reader volume.<br />
* {{done|}}FFOS: {{Bug|1030466}} - Headphones screen reader volume is too low.<br />
* {{done|}}FFOS: {{Bug|1030468}} - VC rectangle needs to work with scaled content.<br />
* {{done|}}FFOS: {{Bug|1030470}} - Localization needs to work when switching locales in FxOS.<br />
<br />
=== Perf ===<br />
<br />
Fix major source of browser jank:<br />
<br />
* {{ok|Initialize plugin instances asynchronously {{bug|998863}} }}<br />
* {{ok|Pause heavy main-thread activities while user is interacting with the browser: }}<br />
** {{ok|Determine when a user is actively interacting with the browser}}<br />
** {{ok|Detect when jank occurs during interactions and report to Telemetry {{bug|1017055}} }}<br />
** {{ok|Experiment with hinting to GC & CC that they should pause while the user is interacting with the browser}}<br />
* {{ok|Help Frontend team with Places refactoring, eliminate some of the [http://telemetry.mozilla.org/slowsql/ Places main-thread SQL] reported to Telemetry }}<br />
* {{ok|Don't store UI customization in localstore.rdf, use off-main thread JSON instead {{bug|559505}} }}<br />
<br />
Improve Firefox startup (identified as a top issue in user research):<br />
<br />
* {{ok|Reduce appearance of the "profile is in use" message on startup {{bug|286355}} }}<br />
* {{ok|Restore windows one by one during session-restore {{bug|1034534}} and/or load windows by descending z-order {{bug|1034036}} }}<br />
* {{ok|C++ version of AsyncShutdown {{bug|918317}} }}<br />
<br />
Prevent performance regressions:<br />
<br />
* {{ok|Implement automatic detection & alerting for Telemetry regressions {{bug|1031032}} }}<br />
* {{ok|Help developers understand & diagnose Talos regressions}}, e.g. [https://bugzilla.mozilla.org/show_bug.cgi?id=1026550 Firefox 33 regression tracking], [https://bugzilla.mozilla.org/show_bug.cgi?id=1004427 Firefox 32 regressions], [https://bugzilla.mozilla.org/show_bug.cgi?id=990085 Firefox 31]<br />
<br />
Grow community:<br />
<br />
* {{ok|Mentor at least 5 external contributors}}<br />
<br />
=== Networking ===<br />
<br />
* {{ok|Ship Network Predictor ("Seer") on nightly, using HTTP cache instead of SQLite ({{bug|1009122}}) (hurley)}}<br />
* {{done|Ship current (hopefully final) IETF version of HTTP/2 preffed on in nightly (hurley)}}<br />
* {{ok|HTTP/2 "alt-svc" support ({{bug|1003448}}) (mcmanus)}}<br />
* {{drop|HTTP cache: determine if revalidation is needed w/o doing I/O ({{bug|983122}}) (sworkman) }}<br />
* {{ok|Network up/down link detection on all platforms ({{bug|939318}}) (bagder) }}<br />
* {{drop|Implement WebSocket compression extension ({{bug|792831}}) (michal) }}<br />
<br />
=== Mobile ===<br />
<br />
=== A*Team ===<br />
<br />
For full list, see [[Auto-tools/Goals/2014Q3|A-Team Goals 2014Q3]]<br />
<br />
'''B2G'''<br />
* {{ok|}} Run a set of performance and correctness tests per-commit to b2g-inbound on Flame devices<br />
* {{ok|}} Get gaia-integration tests running on device<br />
* {{ok|}} Expand the FxOS Certification Suite with 1.4 support, test automation to prevent regressions, and investigation of support for non-phone devices<br />
* {{ok|}} Green up B2G tests on TaskCluster (joint with RelEng)<br />
<br />
'''Developer Productivity'''<br />
* {{ok|}} Deploy ReviewBoard for developers to start using (joint with RelEng)<br />
<br />
'''Performance'''<br />
* {{ok|}} Deploy new Talos tests for tp5o_scroll, webgl, webrtc, and mainthread I/O<br />
* {{ok|}} Get Datazilla alerts to beta mode (full parity with graph server alerts) with reduced noise<br />
* {{ok|}} Get Eideticker running against Android again with increased frequency<br />
* {{ok|}} Run B2G Eideticker against same branch/build combinations as our other on-device perf tests<br />
* {{ok|}} Stand up a Games Benchmarking system for webaudio tests running against Firefox and Chrome<br />
<br />
'''Treeherder'''<br />
* {{ok|}} Deliver performance web service for ingesting and returning performance data <br />
* {{ok|}} Deliver a UI for viewing Talos data<br />
<br />
'''Sheriffing'''<br />
* {{ok|}} Fully transition sheriffing from TBPL to Treeherder<br />
<br />
'''General Automation'''<br />
* {{ok|}} Create weekly reports that describe how many tests have been added/disabled/enabled per suite and platform<br />
* {{ok|}} Move reftest to mozbase<br />
* {{ok|}} Add command executors for Marionette for Java and Python<br />
<br />
'''Bugzilla'''<br />
* {{done|}} Improve load time of related bugs; can decrease show_bug load times by up to 12%<br />
* {{ok|}} Minify and concatenate JS files<br />
* {{ok|}} Authoritative view for review history<br />
* {{ok|}} Rewrite docs for REST API<br />
<br />
'''Community'''<br />
* {{ok|}} Create good_next_bugs (name can be adjusted) so once contributors are comfortable they can do more serious coding/problem solving on a project they are familiar with<br />
* {{ok|}} Monthly review of mentored bugs and projects<br />
<br />
=== Web Engineering ===<br />
'''Crash stats'''<br />
* {{ok|}} Prototype service for identifying post-crash user actions<br />
* {{done|}} Hardware and performance tuning for new primary data store<br />
* {{ok|}} Remove older, redundant crash storage format from database<br />
* {{drop|}} Improve search performance and features<br />
** API changes in the underlying tech made this much more complicated that originally estimated. Will be carried over to next Q.<br />
* {{done|}} Replace interfaces to deprecated external data sources<br />
* {{done|}} Remove barriers to community installations<br />
'''FHR'''<br />
* {{done|}} Support search diversion plan<br />
'''DXR'''<br />
* {{ok|}} Improve infrastructure.<br />
** For example, switch to ES backend, which will enable us to build multi-language support and parallel tree indexing.<br />
* {{ok|}} Broaden our audience.<br />
** Pull users away from MXR so we can shut it off. For example, add support for Rust or JS, squash MXR migration blockers.<br />
'''l10n'''<br />
* {{done|}} Get l10n build logs into a searchable data store<br />
* {{at risk|}} Replace some buildbot functionality with a10n automation<br />
'''Air Mozilla'''<br />
* {{done|}} Prototype support for streaming media boxes<br />
* {{done|}} Improve desktop user experience<br />
<br />
[https://etherpad.mozilla.org/webeng-q32014 full list]<br />
<br />
=== SUMO and Input ===<br />
* {{done|}} SUMO: Launch new offline SUMO app [Get Firefox on a Growth Trajectory]<br />
* {{done|}} SUMO: Develop new Community Hub to a level where it can replace legacy Karma app [Enable Communities with Impact]<br />
* {{done|}} SUMO: Research and prototype new experimental features (e.g. geotargeting, Instant Search, Search Suggestions) [Get Firefox on a Growth Trajectory]<br />
<br />
* {{done|}} Input: Improve documentation and install to lower the bar for contribution ([[Firefox/Input/Reduce Contributor Pain]]) [Enable Communities with Impact]<br />
* {{done|}} Input: Support Heartbeat ([[Firefox/Input/Heartbeat]]) [Get Firefox on a Growth Trajectory]<br />
* {{risk|}} Input: Dashboards for Everyone ([[Firefox/Input/Dashboards for Everyone]]) [Get Firefox on a Growth Trajectory]<br />
<br />
=== Release Engineering - Laura ===<br />
* {{drop|}} Enable capacity expansion for bare-metal releng OS X build and test slaves via hardware provided by third-party datacenters (Get Firefox on a Trajectory of Growth) - dropped early on. Third parties are not "there yet" and cost more.<br />
* {{done|}} Simplify release engineering mobile hardware infrastructure (Get Firefox on a Trajectory of Growth)<br />
* {{miss|}} Automate developer access to continuous integration resources to expedite debugging and standing up new job variants. (Enable Communities With Impact) - Progressed a lot. Almost ready for releng to use internally.<br />
* {{done|}} Help enable video operability on the web by providing continuous integration for Cisco Open H.264 builds. (Get Firefox on a Trajectory of Growth)<br />
<br />
=== Release Engineering - Taras ===<br />
* {{ok|}} Replace aging Firefox update service with a scalable, modern solution. (Get Firefox on a Trajectory of Growth) - Now on beta channel. release channel in early Q4<br />
* {{ok|}} Simplify developer workflow by automating patch landing and uplift. (Enable Communities With Impact)<br />
* {{ok|}} Optimize network transfers for build/test automation between datacenters. (Enable Communities With Impact)<br />
* {{ok|}} Continue AWS cost optimizations: EBS < 3% of AWS bill(vs 30% in Q2) (Enable Communities With Impact)<br />
* {{drop|}} Improve developer workflow by migrating 80% of FirefoxOS build/test jobs to taskcluster (Enable Communities With Impact) - this goal is now with jlal in FirefoxOS<br />
* {{drop|}} Turn telemetry into a general purpose s3 ingester and analysis tool - this goal is now with mreid in Services<br />
<br />
=== Release Engineering Operations ===<br />
* Build/Test System Performance Enhancements<br />
** {{drop| Unify releng platform architecture, using common tools and best practices, to decrease complexity and enable smoother developer engagement {{bug|1026110}} [Get Firefox on a Trajectory of Growth, Enable Communities With Impact] - blocked on obtaining necessary resources from other groups }}<br />
** {{done| Improve communication and response time for releng network flow requests {{bug|1026112}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] }}<br />
** {{ok| Improve security for all releng windows infrastructure {{bug|893716}} [Get Firefox on a Trajectory of Growth] }}<br />
** {{done| Update windows platform developer tools {{bug|1019165}} [Get Firefox on a Trajectory of Growth] }}<br />
* Build/Test System Self-Serve Re-architecture<br />
** {{done| Design a private cloud deployment architecture for bare metal and produce a POC that supports Ubuntu 12.04 test machines. {{bug|963165}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] - POC created, and openstack was deemed too buggy in its current unreleased state to be production ready }}<br />
** {{drop| Create self-service capability for releng hardware Firefox linux test slaves (build slaves as a stretch goal) {{bug|1026687}} (depends on completion of previous goal) [Get Firefox on a Trajectory of Growth, Scale Firefox OS] - bare metal openstack is proving to be too bleeding edge and buggy to use for production services. We will continue to work on R&D for this project and track changes made in the openstack code base, but we will not move any services to production in FY2014 }}<br />
<br />
=== Developer Services ===<br />
* {{done|(with B-team) roll out phase 2 of new review tooling}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
* {{new|Upgrade existing Mercurial infrastructure to support more rapid, safe, and coordinated deployment of updates.}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
<br />
[https://etherpad.mozilla.org/devservices-Q32014 Full List]<br />
<br />
=== Security & Privacy Engineering ===<br />
More details here: [[SecurityEngineering/2014/Q3Goals]]<br />
<br />
'''Content Security'''<br />
* {{done|Gecko Security Hooks: Finish code and debugging for NS_NewChannel API, start getting reviews}} (dri=tanvi)<br />
* {{defer|Gecko Security Hooks: Create plan for addon compatibility -- doesn't make sense until New Channel API is done, deferring to next quarter when shimming the JS API for creating new channels}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central}} (dri=sstamm)<br />
* {{done|Evangelism: Security blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{miss|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs}}. Couldn't stretch. (dri=ckerschb)<br />
<br />
'''Tracking Protection'''<br />
* {{miss|Referer: Finish implementation of <meta> referrer control with volunteer help}}. Unexpected dependencies, will finish about two weeks late. (dri=sstamm)<br />
* {{done|Land first implementation of protection in Fx 33/34 off by default. BONUS: landed frontend code too}} (dri=mmc)<br />
<br />
'''Communications Security'''<br />
* {{done|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok| HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{done| Update [[CA:RevocationPlan|roadmap for Cert Revocation improvements]]}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{done| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{done| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{risk| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{defer| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)<br />
* {{done| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
<br />
=== Firefox and Platform Security ===<br />
<br />
* [https://mana.mozilla.org/wiki/display/~gkwong@mozilla.com/Marifuzz Marifuzz ] fuzzer ported to and running on Flame devices.<br />
* Update ASan and LSan work for DOMFuzzer<br />
* Update "Bounty Stars" document with issues found by external reporters and updating DOMFuzzer to reflect these results.<br />
* Get Clang on RelEng ready for official OS X ASan builds.<br />
* Initial work to move CoreFuzz towards running in cloud environments.<br />
* WebCrypto API fuzzing using Dharma fuzzer. <br />
* Port a portion of WebRTC fuzzing from Frambois fuzzer to Dharma fuzzer.<br />
* Peach: Improving and porting Peach 2 to Python 3.<br />
* Public Mozilla Security Github work: Moving of fuzzing tools from Fuzzing Hg to GitHub, including work to separate harnesses from testcase generation tools.<br />
<br />
=== Games Program ===<br />
* {{done| Reach out to 3rd party engines en masse (also for Q4)}}<br />
* {{ok| Select a 3D demo for mobile}}<br />
* {{done| Pick a partner demo to optimize for mobile}}<br />
* {{ok| Focus on supporting shipping games and maintaining platform stability }}<br />
* {{ok| Focus on Shared Array Buffer implementation }}<br />
* {{risk| WebGL Benchmarks}}<br />
* {{ok| Continue to work MDN documentation; get Emscripten documentation started }}<br />
* {{ok| GDC and MWC event support plan}}<br />
<br />
=== Release Management ===<br />
For full list, see [[Release_Management/Goals/2014Q3#Release_Management_General|Release Management 2014Q3 Goals]].<br />
* Create and document process for Desktop/Mobile feature fast tracking<br />
* {{done|}} Determine future of ESR and how to manage this channel<br />
** https://groups.google.com/forum/#!topic/mozilla.dev.planning/-IQWXs_zEp8<br />
* {{done|}} Continue desktop throttling experiment with intention of reducing throttled time while maintaining existing level of feedback<br />
** Throttling time currently reduced from 10 to 7 days. Experimenting with further reductions.<br />
* Improve release notes with revamped template for all products<br />
* Create B2G release model proposals and gather feedback for potential changes<br />
* Figure out what to do with B2G Security Releases<br />
<br />
===Program Management===<br />
<br />
See this wiki page for a full list of [https://wiki.mozilla.org/Program_Management/Firefox/2014-Q3-Goals Program Management goals].<br />
<br />
* {{ok|Create a set of dashboards based on the ES database to track platform projects and surface bottlenecks.}}<br />
** Narrowed focus to a set of dashboards for review queues for individuals and teams. <br />
* {{risk|Brown bag presentation/restropective on the agile processes we are using on Desktop and FirefoxOS}}<br />
** With the reorg, revisiting the purpose/target. Might change this goal slightly. Still probably worthwhile planning a brown bag to talk about Desktop process and introduce Trello planning tool for Platform.<br />
* {{ok|Evaluate and produce a report on several tools for helping organize and visualize team backlogs and priority lists; wiki, spreadsheets, Trello, Kanbanize}}<br />
** Using a Trello board for Platform work. Jenn piloting Kanban board for Desktop/Android. Should have a summary, write-up ready by end of Sept.<br />
<br />
=== Quality Engineering ===<br />
See this wiki for the full list of [https://wiki.mozilla.org/QA/Goals/2014q3 Quality goals]. What follows are our brief summary of our internal improvement goals for each strategic team.<br />
* Firefox QA - Revitalize our Quality Engineering strategy by switching to a feature-based test strategy for all Firefox browser products so that there are test plans for each feature and testing is executed within two sprints of the feature's code landing<br />
* Firefox OS - Better metrics for quality analysis, provide opportunities for community contribution, and expanding the role of our on-device automation for reporting to Treeherder.<br />
* Services - Ensure new offerings have 98% uptime (FxA Sync, OAuth, FMD, Loop) and no more than 2 P1 bugs discovered post launch while building a core contributor base in services<br />
* Marketplace - Ensure Marketplace's new payments backend, in-app payments, and the Marketplace feed land with high quality releases.<br />
* Platform QA - Deploy into continuous integration a regression testing system for WebRTC along three areas of investigation: 1. "Smoke" tests, 2. Connection tests, and 3. Connection quality tests. These will be performed in a variety of environments, including various network topologies with various performance characteristics, connections between various versions of Firefox, and connections on multiple OS platforms. Test plans will be developed, and we will measure coverage of test plans. Results will be posted and available in Treeherder. We will also build backlog for next Platform Tiger Team tasks.<br />
* Community - Increase conversion of interested and casual contributors to help them become active contributors with strong ties to the QA community</div>Sidstammhttps://wiki.mozilla.org/index.php?title=Platform/2014-Q3-Goals&diff=1019326Platform/2014-Q3-Goals2014-09-29T18:25:11Z<p>Sidstamm: /* Security & Privacy Engineering */</p>
<hr />
<div>=== Platform ===<br />
==== [[Platform/2014-Goals|2014 General Goals]] ====<br />
<br />
=== GFX ===<br />
Items marked [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AnKFEBp1-VyqdFNfRlZmV0ExM0VvZGMxNThWX0d6LWc&usp=drive_web#gid=0 here] with release 33 and 34 are part of the Q3 landings.<br />
<br />
=== Layout ===<br />
* Layout to Moz2D<br />
** {{ok|Migrate SVG to Moz2D (bug 703159) }}<br />
<br />
* Enable Vertical Text for major use cases for Chinese & Japanese<br />
** {{miss|{{bug|145503}}}} - Meta Bug. We've made lots of progress, but our big bug won't get closed until Q4<br />
** {{done|{{bug|789096}}}} - Layout with horizontal block flow and vertical text flow<br />
** {{ok|{{bug|902762}}}} - Vertical text run creation<br />
** {{risk|{{bug|1062963}}}} - Make nsFloatManager use logical coordinates<br />
<br />
* Text Performance<br />
** We'll get 1 of the 3 we wanted to hit.<br />
** {{ok|{{bug|998869}}}} Streamline parsing of fontlists and improve efficiency of font matching code (note: unicode-range support will fall out of this work)<br />
** {{miss|{{bug|934770}}}} - slow at rendering large blocks of plain text<br />
** {{miss|{{bug|860492}}}} - Divide large text runs into smaller runs to avoid chrome hangs<br />
<br />
* Improve Restyling Performance<br />
** {{done|{{bug|977991}}}}<br />
** {{done|{{bug|931668}}}} - (not originally listed for this quarter, but carryover from previous)<br />
<br />
* {{drop|Font Inflation and Reflow-on-Zoom }}<br />
** We picked up scrolling features/fixes in Q3 and deferred this item<br />
** both implementation bug fixing and spec work<br />
** -moz-text-size-adjust <br />
<br />
* ImageLib<br />
** {{ok|RasterImage for multiple images}}<br />
*** {{done|prerequisite draw API refactoring}} {{bug|1043560}}<br />
*** {{done|store imgFrame objects in the imagelib SurfaceCache}} {{bug|1054079}}<br />
*** {{done|use #1: HQ scaled frames in the surface cache}} {{bug|1060200}}<br />
*** {{ok|use #2: store multiple decode options in surface cache for non-animated images}}<br />
*** {{risk|use #3: store multiple decode options in surface cache for animated images}}<br />
<br />
* CSS Projects with Adobe<br />
** {{done|CSS Filters}}<br />
<br />
* Animations & Transitions<br />
** {{risk|transitions/animations spec editing}}<br />
** {{risk|transitions refactoring to match new spec}} <br />
*** {{done|{{bug|996796}}}} landed, but work is ongoing for {{bug|960465}}<br />
** {{done|frame reconstruction (625289)}}<br />
** {{risk|Effective start of CSS animations and transitions {{bug|927349}}}}<br />
*** may spill into Q4<br />
<br />
* OMTA on non-B2G Platforms (980770)<br />
** {{risk|fix correctness bugs (cascading, etc.)}}<br />
*** partly done in {{bug|996796}}, but cascading fix likely miss<br />
** {{risk|turning on on other OMTC platforms (Mac/Android)}}<br />
<br />
* Web animations: <br />
** {{done|Get basic implementation of GetAnimationPlayers {{bug|1032573}}}}<br />
** {{risk|Implement PlaybackControl() {{bug|1033114}}}}<br />
*** may spill into Q4<br />
<br />
* CSS Scrolling<br />
** {{ok|CSS scroll snapping}}<br />
** {{ok|scroll-behavior:smooth}}<br />
<br />
* CSS Flexbox <br />
** {{ok|performance bugs}}<br />
*** significant improvement on {{bug|946167}}, though more to do<br />
** {{ok|spec changes}}<br />
*** completed {{bug|984711}}/{{bug|1037177}}/{{bug|1015474}} on min-width/height: auto<br />
*** completed {{bug|1032922}} and followups on flex-basis: main-size rename<br />
*** abs-pos handling at-risk (picked up object-fit/position instead)<br />
<br />
* CSS Ruby <br />
** Our intern got through a bunch of this, but we'll continue it next quarter; remaining work tracked in {{bug|css-ruby}} and {{bug|enable-css-ruby}}<br />
** {{done|style system support}}<br />
** {{done|frame construction}}<br />
** {{done|anonymous box handling}}<br />
** {{done|reflow architecture and horizontal positioning}}<br />
** {{miss|line breaking}}<br />
** {{miss|vertical positioning}}<br />
** {{miss|other dependencies on enabling the feature}}<br />
<br />
=== Media ===<br />
* {{miss|Enable YouTube MSE/VP9 for Firefox 33 in Nightly/Aurora {{bug|1000686}}}}<br />
* {{miss|Enable YouTube MSE/MP4 on Windows and Firefox OS for Firefox 34}}<br />
<br />
'''Detailed Breakdown'''<br />
* MSE Common<br />
** {{done|Rate adaption/buffer switching, reseting}}<br />
** {{miss|Seeking into unbuffered ranges {{bug|1056440}}}}<br />
** {{todo|Eviction/pinning}}<br />
* MSE WebM<br />
** {{done|WebM segment parser {{bug|881512}}{{bug|1044498}}}}<br />
* MSE MP4<br />
** {{done|MP4 segment parser {{bug|1027875}}{{bug|1057203}}}}<br />
** MP4 Demuxer<br />
*** {{done|Integrate stagefright MP4 demuxer {{bug|908503}}}}<br />
*** {{done|Accurate range reporting {{bug|1045909}}}}<br />
*** {{done|CENC support {{bug|1022434}}}}<br />
*** {{todo|DASHIF and other players aside from YouTube {{bug|1039149}}}}<br />
** H.264/AAC Decoder<br />
*** {{done|MP4/fMP4 platform decoder module for Mac OSX {{bug|941296}}}}<br />
*** {{miss|MP4 support on Firefox OS {{bug|1060900}}}}<br />
**** {{done|MP4 platform decoder module for Firefox OS {{bug|941302}}}}<br />
**** {{miss|Use a single shared decoder for MSE on b2g {{bug|1036849}}}}<br />
<br />
=== DOM ===<br />
* {{ok|Mirror prototype of DOM objects through xray wrappers ({{bug|787070}}, peterv)}}<br />
* {{drop|Remove nsDOMClassInfo.cpp}}<br />
** Given the recent focus on e10s, we have not been pushing on this at this point.<br />
* {{done|Make less-privileged non-Xrayable unwaived opaque from privileged code (bholley, {{bug|856067}})}}<br />
* {{done|Route all JSContext pushing through AutoJSAPI and Implement GetEntryGlobal (bobowen, bholley, {{bug|951991}})}}<br />
* {{ok|Land <picture> preffed on on nightly ({{bug|1017875}}) (johns)}}<br />
* {{done|audit callsites of IsInDoc()/GetCurrentDoc to ensure correct Shadow DOM behaviour and fix Shadow DOM blockers for Gaia (smaug, wchen) ({{bug|1026047}})}}<br />
* {{risk|land Service Workers preffed off on nightly (nsm, bkelly, baku) ({{bug|903441}})}}<br />
** This is progressing well, but won't be *done* until the end of the quarter, so still on track.<br />
** Note that originally we thought things would be at the point where Gecko and Blink would be far enough along with a stable spec that this could be preffed on. That is not going to be the case but we are still aiming to have a usable implementation preffed off.<br />
** There remain spec questions about Cache which have impacted the design of our implementation.<br />
<br />
=== WebAPI ===<br />
* {{done|create design plan for "share" activity (flow, what kind of objects are involved) (annevk)}}<br />
** https://wiki.whatwg.org/wiki/Sharing<br />
* {{ok|document existing activities usage in gaia (ehsan)}}<br />
* {{ok|get [https://w3c.github.io/screen-orientation/ screen orientation spec] to LC (marcosc)}}<br />
* {{done|publish [http://www.w3.org/TR/wake-lock-use-cases/ use cases for wake locks] (marcosc)}}<br />
* {{ok|publish spec for [http://w3c.github.io/wake-lock/ "wakelock" API] (marcosc)}}<br />
* {{done|24/12 hour format API (ehsan) {{bug|903683}}}}<br />
* {{ok|{{bug|942542}} new quota API on PBackground for Service Worker cache (janv)}}<br />
* {{ok|{{bug|701634}} IndexedDB in workers (bent)}}<br />
<br />
=== JS ===<br />
* {{miss|ES6 classes: }}{{Bug|837314}} <br />
* {{jok|1020751}} Generational GC on Firefox OS<br />
* {{jok|650161}} Compacting GC to reduce memory usage<br />
* {{jok|856533}} Escape analysis JIT optimizations<br />
* {{done|Use Latin1 strings to reduce memory usage: }}{{Bug|998392}} <br />
* {{jok|903519}} Allocate strings in GC nursery (for performance)<br />
* {{miss|ARM64 JIT ''[stretch goal]'': }} {{Bug|972710}}<br />
<br />
=== Accessibility ===<br />
* {{risk|}}e10s: proxy the common a11y API stuff like name, role, and states.<br />
* {{done|}}GAIA: Fix [https://bugzilla.mozilla.org/buglist.cgi?priority=--&f1=blocked&list_id=10674217&o1=anyexact&resolution=---&query_based_on=b2ga11y%20p%3D1&o2=substring&query_format=advanced&f2=status_whiteboard&v1=893789&component=Disability%20Access%20APIs&component=Gaia&component=Gaia%3A%3ABluetooth%20File%20Transfer&component=Gaia%3A%3ABrowser&component=Gaia%3A%3ABuild&component=Gaia%3A%3ACalendar&component=Gaia%3A%3ACamera&component=Gaia%3A%3AClock&component=Gaia%3A%3AContacts&component=Gaia%3A%3ACost%20Control&component=Gaia%3A%3ADialer&component=Gaia%3A%3AE-Mail&component=Gaia%3A%3AEverything.me&component=Gaia%3A%3AFirst%20Time%20Experience&component=Gaia%3A%3AFMRadio&component=Gaia%3A%3AGallery&component=Gaia%3A%3AGithubBot&component=Gaia%3A%3AHomescreen&component=Gaia%3A%3AKeyboard&component=Gaia%3A%3AL10n&component=Gaia%3A%3ALoop&component=Gaia%3A%3AMusic&component=Gaia%3A%3ANotes&component=Gaia%3A%3APDF%20Viewer&component=Gaia%3A%3APerformanceTest&component=Gaia%3A%3ARingtones&component=Gaia%3A%3ASearch&component=Gaia%3A%3ASettings&component=Gaia%3A%3ASMS&component=Gaia%3A%3ASystem&component=Gaia%3A%3ASystem%3A%3ABrowser%20Chrome&component=Gaia%3A%3ASystem%3A%3AInput%20Mgmt&component=Gaia%3A%3ASystem%3A%3ALockscreen&component=Gaia%3A%3ASystem%3A%3AWindow%20Mgmt&component=Gaia%3A%3ATestAgent&component=Gaia%3A%3AUI%20Tests&component=Gaia%3A%3AVideo&component=Gaia%3A%3AWallpaper&component=Gaia%3A%3AWappush&v2=b2ga11y%20p%3D1&product=Core&product=Firefox%20OS all Gaia P1 a11y bugs] (~30 at this time).<br />
** 49 (all) are fixed.<br />
* {{done|}}FFOS: {{Bug|1030465}} - Volume change should update the screen reader volume.<br />
* {{done|}}FFOS: {{Bug|1030466}} - Headphones screen reader volume is too low.<br />
* {{done|}}FFOS: {{Bug|1030468}} - VC rectangle needs to work with scaled content.<br />
* {{done|}}FFOS: {{Bug|1030470}} - Localization needs to work when switching locales in FxOS.<br />
<br />
=== Perf ===<br />
<br />
Fix major source of browser jank:<br />
<br />
* {{ok|Initialize plugin instances asynchronously {{bug|998863}} }}<br />
* {{ok|Pause heavy main-thread activities while user is interacting with the browser: }}<br />
** {{ok|Determine when a user is actively interacting with the browser}}<br />
** {{ok|Detect when jank occurs during interactions and report to Telemetry {{bug|1017055}} }}<br />
** {{ok|Experiment with hinting to GC & CC that they should pause while the user is interacting with the browser}}<br />
* {{ok|Help Frontend team with Places refactoring, eliminate some of the [http://telemetry.mozilla.org/slowsql/ Places main-thread SQL] reported to Telemetry }}<br />
* {{ok|Don't store UI customization in localstore.rdf, use off-main thread JSON instead {{bug|559505}} }}<br />
<br />
Improve Firefox startup (identified as a top issue in user research):<br />
<br />
* {{ok|Reduce appearance of the "profile is in use" message on startup {{bug|286355}} }}<br />
* {{ok|Restore windows one by one during session-restore {{bug|1034534}} and/or load windows by descending z-order {{bug|1034036}} }}<br />
* {{ok|C++ version of AsyncShutdown {{bug|918317}} }}<br />
<br />
Prevent performance regressions:<br />
<br />
* {{ok|Implement automatic detection & alerting for Telemetry regressions {{bug|1031032}} }}<br />
* {{ok|Help developers understand & diagnose Talos regressions}}, e.g. [https://bugzilla.mozilla.org/show_bug.cgi?id=1026550 Firefox 33 regression tracking], [https://bugzilla.mozilla.org/show_bug.cgi?id=1004427 Firefox 32 regressions], [https://bugzilla.mozilla.org/show_bug.cgi?id=990085 Firefox 31]<br />
<br />
Grow community:<br />
<br />
* {{ok|Mentor at least 5 external contributors}}<br />
<br />
=== Networking ===<br />
<br />
* {{ok|Ship Network Predictor ("Seer") on nightly, using HTTP cache instead of SQLite ({{bug|1009122}}) (hurley)}}<br />
* {{done|Ship current (hopefully final) IETF version of HTTP/2 preffed on in nightly (hurley)}}<br />
* {{ok|HTTP/2 "alt-svc" support ({{bug|1003448}}) (mcmanus)}}<br />
* {{drop|HTTP cache: determine if revalidation is needed w/o doing I/O ({{bug|983122}}) (sworkman) }}<br />
* {{ok|Network up/down link detection on all platforms ({{bug|939318}}) (bagder) }}<br />
* {{drop|Implement WebSocket compression extension ({{bug|792831}}) (michal) }}<br />
<br />
=== Mobile ===<br />
<br />
=== A*Team ===<br />
<br />
For full list, see [[Auto-tools/Goals/2014Q3|A-Team Goals 2014Q3]]<br />
<br />
'''B2G'''<br />
* {{ok|}} Run a set of performance and correctness tests per-commit to b2g-inbound on Flame devices<br />
* {{ok|}} Get gaia-integration tests running on device<br />
* {{ok|}} Expand the FxOS Certification Suite with 1.4 support, test automation to prevent regressions, and investigation of support for non-phone devices<br />
* {{ok|}} Green up B2G tests on TaskCluster (joint with RelEng)<br />
<br />
'''Developer Productivity'''<br />
* {{ok|}} Deploy ReviewBoard for developers to start using (joint with RelEng)<br />
<br />
'''Performance'''<br />
* {{ok|}} Deploy new Talos tests for tp5o_scroll, webgl, webrtc, and mainthread I/O<br />
* {{ok|}} Get Datazilla alerts to beta mode (full parity with graph server alerts) with reduced noise<br />
* {{ok|}} Get Eideticker running against Android again with increased frequency<br />
* {{ok|}} Run B2G Eideticker against same branch/build combinations as our other on-device perf tests<br />
* {{ok|}} Stand up a Games Benchmarking system for webaudio tests running against Firefox and Chrome<br />
<br />
'''Treeherder'''<br />
* {{ok|}} Deliver performance web service for ingesting and returning performance data <br />
* {{ok|}} Deliver a UI for viewing Talos data<br />
<br />
'''Sheriffing'''<br />
* {{ok|}} Fully transition sheriffing from TBPL to Treeherder<br />
<br />
'''General Automation'''<br />
* {{ok|}} Create weekly reports that describe how many tests have been added/disabled/enabled per suite and platform<br />
* {{ok|}} Move reftest to mozbase<br />
* {{ok|}} Add command executors for Marionette for Java and Python<br />
<br />
'''Bugzilla'''<br />
* {{done|}} Improve load time of related bugs; can decrease show_bug load times by up to 12%<br />
* {{ok|}} Minify and concatenate JS files<br />
* {{ok|}} Authoritative view for review history<br />
* {{ok|}} Rewrite docs for REST API<br />
<br />
'''Community'''<br />
* {{ok|}} Create good_next_bugs (name can be adjusted) so once contributors are comfortable they can do more serious coding/problem solving on a project they are familiar with<br />
* {{ok|}} Monthly review of mentored bugs and projects<br />
<br />
=== Web Engineering ===<br />
'''Crash stats'''<br />
* {{ok|}} Prototype service for identifying post-crash user actions<br />
* {{done|}} Hardware and performance tuning for new primary data store<br />
* {{ok|}} Remove older, redundant crash storage format from database<br />
* {{drop|}} Improve search performance and features<br />
** API changes in the underlying tech made this much more complicated that originally estimated. Will be carried over to next Q.<br />
* {{done|}} Replace interfaces to deprecated external data sources<br />
* {{done|}} Remove barriers to community installations<br />
'''FHR'''<br />
* {{done|}} Support search diversion plan<br />
'''DXR'''<br />
* {{ok|}} Improve infrastructure.<br />
** For example, switch to ES backend, which will enable us to build multi-language support and parallel tree indexing.<br />
* {{ok|}} Broaden our audience.<br />
** Pull users away from MXR so we can shut it off. For example, add support for Rust or JS, squash MXR migration blockers.<br />
'''l10n'''<br />
* {{done|}} Get l10n build logs into a searchable data store<br />
* {{at risk|}} Replace some buildbot functionality with a10n automation<br />
'''Air Mozilla'''<br />
* {{done|}} Prototype support for streaming media boxes<br />
* {{done|}} Improve desktop user experience<br />
<br />
[https://etherpad.mozilla.org/webeng-q32014 full list]<br />
<br />
=== SUMO and Input ===<br />
* {{done|}} SUMO: Launch new offline SUMO app [Get Firefox on a Growth Trajectory]<br />
* {{done|}} SUMO: Develop new Community Hub to a level where it can replace legacy Karma app [Enable Communities with Impact]<br />
* {{done|}} SUMO: Research and prototype new experimental features (e.g. geotargeting, Instant Search, Search Suggestions) [Get Firefox on a Growth Trajectory]<br />
<br />
* {{done|}} Input: Improve documentation and install to lower the bar for contribution ([[Firefox/Input/Reduce Contributor Pain]]) [Enable Communities with Impact]<br />
* {{done|}} Input: Support Heartbeat ([[Firefox/Input/Heartbeat]]) [Get Firefox on a Growth Trajectory]<br />
* {{risk|}} Input: Dashboards for Everyone ([[Firefox/Input/Dashboards for Everyone]]) [Get Firefox on a Growth Trajectory]<br />
<br />
=== Release Engineering - Laura ===<br />
* {{drop|}} Enable capacity expansion for bare-metal releng OS X build and test slaves via hardware provided by third-party datacenters (Get Firefox on a Trajectory of Growth) - dropped early on. Third parties are not "there yet" and cost more.<br />
* {{done|}} Simplify release engineering mobile hardware infrastructure (Get Firefox on a Trajectory of Growth)<br />
* {{miss|}} Automate developer access to continuous integration resources to expedite debugging and standing up new job variants. (Enable Communities With Impact) - Progressed a lot. Almost ready for releng to use internally.<br />
* {{done|}} Help enable video operability on the web by providing continuous integration for Cisco Open H.264 builds. (Get Firefox on a Trajectory of Growth)<br />
<br />
=== Release Engineering - Taras ===<br />
* {{ok|}} Replace aging Firefox update service with a scalable, modern solution. (Get Firefox on a Trajectory of Growth) - Now on beta channel. release channel in early Q4<br />
* {{ok|}} Simplify developer workflow by automating patch landing and uplift. (Enable Communities With Impact)<br />
* {{ok|}} Optimize network transfers for build/test automation between datacenters. (Enable Communities With Impact)<br />
* {{ok|}} Continue AWS cost optimizations: EBS < 3% of AWS bill(vs 30% in Q2) (Enable Communities With Impact)<br />
* {{drop|}} Improve developer workflow by migrating 80% of FirefoxOS build/test jobs to taskcluster (Enable Communities With Impact) - this goal is now with jlal in FirefoxOS<br />
* {{drop|}} Turn telemetry into a general purpose s3 ingester and analysis tool - this goal is now with mreid in Services<br />
<br />
=== Release Engineering Operations ===<br />
* Build/Test System Performance Enhancements<br />
** {{drop| Unify releng platform architecture, using common tools and best practices, to decrease complexity and enable smoother developer engagement {{bug|1026110}} [Get Firefox on a Trajectory of Growth, Enable Communities With Impact] - blocked on obtaining necessary resources from other groups }}<br />
** {{done| Improve communication and response time for releng network flow requests {{bug|1026112}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] }}<br />
** {{ok| Improve security for all releng windows infrastructure {{bug|893716}} [Get Firefox on a Trajectory of Growth] }}<br />
** {{done| Update windows platform developer tools {{bug|1019165}} [Get Firefox on a Trajectory of Growth] }}<br />
* Build/Test System Self-Serve Re-architecture<br />
** {{done| Design a private cloud deployment architecture for bare metal and produce a POC that supports Ubuntu 12.04 test machines. {{bug|963165}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] - POC created, and openstack was deemed too buggy in its current unreleased state to be production ready }}<br />
** {{drop| Create self-service capability for releng hardware Firefox linux test slaves (build slaves as a stretch goal) {{bug|1026687}} (depends on completion of previous goal) [Get Firefox on a Trajectory of Growth, Scale Firefox OS] - bare metal openstack is proving to be too bleeding edge and buggy to use for production services. We will continue to work on R&D for this project and track changes made in the openstack code base, but we will not move any services to production in FY2014 }}<br />
<br />
=== Developer Services ===<br />
* {{done|(with B-team) roll out phase 2 of new review tooling}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
* {{new|Upgrade existing Mercurial infrastructure to support more rapid, safe, and coordinated deployment of updates.}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
<br />
[https://etherpad.mozilla.org/devservices-Q32014 Full List]<br />
<br />
=== Security & Privacy Engineering ===<br />
More details here: [[SecurityEngineering/2014/Q3Goals]]<br />
<br />
'''Content Security'''<br />
* {{done|Gecko Security Hooks: Finish code and debugging for NS_NewChannel API, start getting reviews}} (dri=tanvi)<br />
* {{defer|Gecko Security Hooks: Create plan for addon compatibility -- doesn't make sense until New Channel API is done, deferring to next quarter when shimming the JS API for creating new channels}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central}} (dri=sstamm)<br />
* {{done|Evangelism: Security blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{miss|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs}} (dri=ckerschb)<br />
<br />
'''Tracking Protection'''<br />
* {{risk|Referer: Finish implementation of <meta> referrer control with volunteer help}} (dri=sstamm)<br />
* {{done|Land first implementation of protection in Fx 33/34 off by default. BONUS: landed frontend code too}} (dri=mmc)<br />
<br />
'''Communications Security'''<br />
* {{done|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok| HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{done| Update [[CA:RevocationPlan|roadmap for Cert Revocation improvements]]}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{done| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{done| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{risk| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{defer| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)<br />
* {{done| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
<br />
=== Firefox and Platform Security ===<br />
<br />
* [https://mana.mozilla.org/wiki/display/~gkwong@mozilla.com/Marifuzz Marifuzz ] fuzzer ported to and running on Flame devices.<br />
* Update ASan and LSan work for DOMFuzzer<br />
* Update "Bounty Stars" document with issues found by external reporters and updating DOMFuzzer to reflect these results.<br />
* Get Clang on RelEng ready for official OS X ASan builds.<br />
* Initial work to move CoreFuzz towards running in cloud environments.<br />
* WebCrypto API fuzzing using Dharma fuzzer. <br />
* Port a portion of WebRTC fuzzing from Frambois fuzzer to Dharma fuzzer.<br />
* Peach: Improving and porting Peach 2 to Python 3.<br />
* Public Mozilla Security Github work: Moving of fuzzing tools from Fuzzing Hg to GitHub, including work to separate harnesses from testcase generation tools.<br />
<br />
=== Games Program ===<br />
* {{done| Reach out to 3rd party engines en masse (also for Q4)}}<br />
* {{ok| Select a 3D demo for mobile}}<br />
* {{done| Pick a partner demo to optimize for mobile}}<br />
* {{ok| Focus on supporting shipping games and maintaining platform stability }}<br />
* {{ok| Focus on Shared Array Buffer implementation }}<br />
* {{risk| WebGL Benchmarks}}<br />
* {{ok| Continue to work MDN documentation; get Emscripten documentation started }}<br />
* {{ok| GDC and MWC event support plan}}<br />
<br />
=== Release Management ===<br />
For full list, see [[Release_Management/Goals/2014Q3#Release_Management_General|Release Management 2014Q3 Goals]].<br />
* Create and document process for Desktop/Mobile feature fast tracking<br />
* {{done|}} Determine future of ESR and how to manage this channel<br />
** https://groups.google.com/forum/#!topic/mozilla.dev.planning/-IQWXs_zEp8<br />
* {{done|}} Continue desktop throttling experiment with intention of reducing throttled time while maintaining existing level of feedback<br />
** Throttling time currently reduced from 10 to 7 days. Experimenting with further reductions.<br />
* Improve release notes with revamped template for all products<br />
* Create B2G release model proposals and gather feedback for potential changes<br />
* Figure out what to do with B2G Security Releases<br />
<br />
===Program Management===<br />
<br />
See this wiki page for a full list of [https://wiki.mozilla.org/Program_Management/Firefox/2014-Q3-Goals Program Management goals].<br />
<br />
* {{ok|Create a set of dashboards based on the ES database to track platform projects and surface bottlenecks.}}<br />
** Narrowed focus to a set of dashboards for review queues for individuals and teams. <br />
* {{risk|Brown bag presentation/restropective on the agile processes we are using on Desktop and FirefoxOS}}<br />
** With the reorg, revisiting the purpose/target. Might change this goal slightly. Still probably worthwhile planning a brown bag to talk about Desktop process and introduce Trello planning tool for Platform.<br />
* {{ok|Evaluate and produce a report on several tools for helping organize and visualize team backlogs and priority lists; wiki, spreadsheets, Trello, Kanbanize}}<br />
** Using a Trello board for Platform work. Jenn piloting Kanban board for Desktop/Android. Should have a summary, write-up ready by end of Sept.<br />
<br />
=== Quality Engineering ===<br />
See this wiki for the full list of [https://wiki.mozilla.org/QA/Goals/2014q3 Quality goals]. What follows are our brief summary of our internal improvement goals for each strategic team.<br />
* Firefox QA - Revitalize our Quality Engineering strategy by switching to a feature-based test strategy for all Firefox browser products so that there are test plans for each feature and testing is executed within two sprints of the feature's code landing<br />
* Firefox OS - Better metrics for quality analysis, provide opportunities for community contribution, and expanding the role of our on-device automation for reporting to Treeherder.<br />
* Services - Ensure new offerings have 98% uptime (FxA Sync, OAuth, FMD, Loop) and no more than 2 P1 bugs discovered post launch while building a core contributor base in services<br />
* Marketplace - Ensure Marketplace's new payments backend, in-app payments, and the Marketplace feed land with high quality releases.<br />
* Platform QA - Deploy into continuous integration a regression testing system for WebRTC along three areas of investigation: 1. "Smoke" tests, 2. Connection tests, and 3. Connection quality tests. These will be performed in a variety of environments, including various network topologies with various performance characteristics, connections between various versions of Firefox, and connections on multiple OS platforms. Test plans will be developed, and we will measure coverage of test plans. Results will be posted and available in Treeherder. We will also build backlog for next Platform Tiger Team tasks.<br />
* Community - Increase conversion of interested and casual contributors to help them become active contributors with strong ties to the QA community</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q3Goals&diff=1019324SecurityEngineering/2014/Q3Goals2014-09-29T18:24:16Z<p>Sidstamm: </p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
(Also linked from [[Platform/2014-Q3-Goals#Security_.26_Privacy_Engineering]]).<br />
<br />
== Content Security ==<br />
;Outcome: Progress towards more robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid<br />
<br />
* {{done|Gecko Security Hooks: Finish code and debugging for NS_NewChannel API, start getting reviews.}} See {{bug|1038756}}, {{bug|1006881}} (dri=tanvi)<br />
* {{defer|Gecko Security Hooks: Create plan for addon compatibility - nothing to do until JS impl is done}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central. Target Fx34.}} See {{bug|994782}} (dri=sstamm)<br />
* {{done|Evangelism: Security blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs.}} See [https://etherpad.mozilla.org/CSP-1-1 planning etherpad] (dri=ckerschb)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Monica, Garrett, Sid, Georgios<br />
<br />
* {{risk|Referer: Finish implementation of <meta> referrer control with volunteer help.}} See {{bug|704320}}, very close. (dri=sstamm)<br />
* {{done|Land backend and bridge code for first implementation of protection in Fx 33/34 off by default. BONUS: landed frontend code too}} (dri=mmc)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks.<br />
;Who: Richard, Kathleen, Keeler, Camilo, Harsh, Garrett, Monica<br />
<br />
* {{done|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=mgoodwin)<br />
* {{ok|HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{done| Update [[CA:RevocationPlan|roadmap for Cert Revocation improvements]]}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{done| Add measurement/enforcement of compliance with CABF Baseline Requirements}}. See {{bug|1050546}} (dri=keeler)<br />
* {{done| Create a tool for testing CA certificate compliance and EV-readiness}}. See {{bug|926599}} and {{bug|1029095}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{defer| ''[stretch goal]'' Enable revocation of intermediate CAs through block list service}} (dri=mgoodwin, keeler)<br />
* {{done| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
* {{defer| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q3Goals&diff=1017074SecurityEngineering/2014/Q3Goals2014-09-22T19:51:11Z<p>Sidstamm: /* Content Security */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
(Also linked from [[Platform/2014-Q3-Goals#Security_.26_Privacy_Engineering]]).<br />
<br />
== Content Security ==<br />
;Outcome: Progress towards more robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid<br />
<br />
* {{done|Gecko Security Hooks: Finish code and debugging for NS_NewChannel API, start getting reviews.}} See {{bug|1038756}}, {{bug|1006881}} (dri=tanvi)<br />
* {{defer|Gecko Security Hooks: Create plan for addon compatibility - nothing to do yet}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central. Target Fx34.}} See {{bug|994782}} (dri=sstamm)<br />
* {{done|Evangelism: Security blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs.}} See [https://etherpad.mozilla.org/CSP-1-1 planning etherpad] (dri=ckerschb)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Monica, Garrett, Sid, Georgios<br />
<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help.}} See {{bug|704320}}. (dri=sstamm)<br />
* {{done|Land backend and bridge code for first implementation of protection in Fx 33/34 off by default. BONUS: landed frontend code too}} (dri=mmc)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks.<br />
;Who: Richard, Kathleen, Keeler, Camilo, Harsh, Garrett, Monica<br />
<br />
* {{ok|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok|HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{done| Update [[CA:RevocationPlan|roadmap for Cert Revocation improvements]]}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{done| Add measurement/enforcement of compliance with CABF Baseline Requirements}}. See {{bug|1050546}} (dri=keeler)<br />
* {{done| Create a tool for testing CA certificate compliance and EV-readiness}}. See {{bug|926599}} and {{bug|1029095}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{risk| ''[stretch goal]'' Enable revocation of intermediate CAs through block list service}} (dri=mgoodwin, keeler)<br />
* {{done| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
* {{ok| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=Platform/2014-Q3-Goals&diff=1017073Platform/2014-Q3-Goals2014-09-22T19:50:22Z<p>Sidstamm: /* Security & Privacy Engineering */</p>
<hr />
<div>=== Platform ===<br />
==== [[Platform/2014-Goals|2014 General Goals]] ====<br />
<br />
=== GFX ===<br />
Items marked [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AnKFEBp1-VyqdFNfRlZmV0ExM0VvZGMxNThWX0d6LWc&usp=drive_web#gid=0 here] with release 33 and 34 are part of the Q3 landings.<br />
<br />
=== Layout ===<br />
* Layout to Moz2D<br />
** {{ok|Migrate SVG to Moz2D (bug 703159) }}<br />
<br />
* Enable Vertical Text for major use cases for Chinese & Japanese<br />
** {{miss|{{bug|145503}}}} - Meta Bug. We've made lots of progress, but our big bug won't get closed until Q4<br />
** {{done|{{bug|789096}}}} - Layout with horizontal block flow and vertical text flow<br />
** {{ok|{{bug|902762}}}} - Vertical text run creation<br />
** {{risk|{{bug|1062963}}}} - Make nsFloatManager use logical coordinates<br />
<br />
* Text Performance<br />
** We'll get 1 of the 3 we wanted to hit.<br />
** {{ok|{{bug|998869}}}} Streamline parsing of fontlists and improve efficiency of font matching code (note: unicode-range support will fall out of this work)<br />
** {{miss|{{bug|934770}}}} - slow at rendering large blocks of plain text<br />
** {{miss|{{bug|860492}}}} - Divide large text runs into smaller runs to avoid chrome hangs<br />
<br />
* Improve Restyling Performance<br />
** {{done|{{bug|977991}}}}<br />
** {{done|{{bug|931668}}}} - (not originally listed for this quarter, but carryover from previous)<br />
<br />
* {{drop|Font Inflation and Reflow-on-Zoom }}<br />
** We picked up scrolling features/fixes in Q3 and deferred this item<br />
** both implementation bug fixing and spec work<br />
** -moz-text-size-adjust <br />
<br />
* ImageLib<br />
** {{ok|RasterImage for multiple images}}<br />
*** {{done|prerequisite draw API refactoring}} {{bug|1043560}}<br />
*** {{done|store imgFrame objects in the imagelib SurfaceCache}} {{bug|1054079}}<br />
*** {{done|use #1: HQ scaled frames in the surface cache}} {{bug|1060200}}<br />
*** {{ok|use #2: store multiple decode options in surface cache for non-animated images}}<br />
*** {{risk|use #3: store multiple decode options in surface cache for animated images}}<br />
<br />
* CSS Projects with Adobe<br />
** {{done|CSS Filters}}<br />
<br />
* Animations & Transitions<br />
** {{risk|transitions/animations spec editing}}<br />
** {{risk|transitions refactoring to match new spec}} <br />
*** {{done|{{bug|996796}}}} landed, but work is ongoing for {{bug|960465}}<br />
** {{done|frame reconstruction (625289)}}<br />
** {{risk|Effective start of CSS animations and transitions {{bug|927349}}}}<br />
*** may spill into Q4<br />
<br />
* OMTA on non-B2G Platforms (980770)<br />
** {{risk|fix correctness bugs (cascading, etc.)}}<br />
*** partly done in {{bug|996796}}, but cascading fix likely miss<br />
** {{risk|turning on on other OMTC platforms (Mac/Android)}}<br />
<br />
* Web animations: <br />
** {{done|Get basic implementation of GetAnimationPlayers {{bug|1032573}}}}<br />
** {{risk|Implement PlaybackControl() {{bug|1033114}}}}<br />
*** may spill into Q4<br />
<br />
* CSS Scrolling<br />
** {{ok|CSS scroll snapping}}<br />
** {{ok|scroll-behavior:smooth}}<br />
<br />
* CSS Flexbox <br />
** {{ok|performance bugs}}<br />
*** significant improvement on {{bug|946167}}, though more to do<br />
** {{ok|spec changes}}<br />
*** completed {{bug|984711}}/{{bug|1037177}}/{{bug|1015474}} on min-width/height: auto<br />
*** completed {{bug|1032922}} and followups on flex-basis: main-size rename<br />
*** abs-pos handling at-risk (picked up object-fit/position instead)<br />
<br />
* CSS Ruby <br />
** Our intern got through a bunch of this, but we'll continue it next quarter; remaining work tracked in {{bug|css-ruby}} and {{bug|enable-css-ruby}}<br />
** {{done|style system support}}<br />
** {{done|frame construction}}<br />
** {{done|anonymous box handling}}<br />
** {{done|reflow architecture and horizontal positioning}}<br />
** {{miss|line breaking}}<br />
** {{miss|vertical positioning}}<br />
** {{miss|other dependencies on enabling the feature}}<br />
<br />
=== Media ===<br />
* {{miss|Enable YouTube MSE/VP9 for Firefox 33 in Nightly/Aurora {{bug|1000686}}}}<br />
* {{miss|Enable YouTube MSE/MP4 on Windows and Firefox OS for Firefox 34}}<br />
<br />
'''Detailed Breakdown'''<br />
* MSE Common<br />
** {{done|Rate adaption/buffer switching, reseting}}<br />
** {{miss|Seeking into unbuffered ranges {{bug|1056440}}}}<br />
** {{todo|Eviction/pinning}}<br />
* MSE WebM<br />
** {{done|WebM segment parser {{bug|881512}}{{bug|1044498}}}}<br />
* MSE MP4<br />
** {{done|MP4 segment parser {{bug|1027875}}{{bug|1057203}}}}<br />
** MP4 Demuxer<br />
*** {{done|Integrate stagefright MP4 demuxer {{bug|908503}}}}<br />
*** {{done|Accurate range reporting {{bug|1045909}}}}<br />
*** {{done|CENC support {{bug|1022434}}}}<br />
*** {{todo|DASHIF and other players aside from YouTube {{bug|1039149}}}}<br />
** H.264/AAC Decoder<br />
*** {{done|MP4/fMP4 platform decoder module for Mac OSX {{bug|941296}}}}<br />
*** {{miss|MP4 support on Firefox OS {{bug|1060900}}}}<br />
**** {{done|MP4 platform decoder module for Firefox OS {{bug|941302}}}}<br />
**** {{miss|Use a single shared decoder for MSE on b2g {{bug|1036849}}}}<br />
<br />
=== DOM ===<br />
* {{ok|Mirror prototype of DOM objects through xray wrappers ({{bug|787070}}, peterv)}}<br />
* {{risk|Remove nsDOMClassInfo.cpp}}<br />
** Given the recent focus on e10s, we may not get through all of this work this quarter.<br />
* {{done|Make less-privileged non-Xrayable unwaived opaque from privileged code (bholley, {{bug|856067}})}}<br />
* {{done|Route all JSContext pushing through AutoJSAPI and Implement GetEntryGlobal (bobowen, bholley, {{bug|951991}})}}<br />
* {{ok|Land <picture> preffed on on nightly ({{bug|1017875}}) (johns)}}<br />
* {{done|audit callsites of IsInDoc()/GetCurrentDoc to ensure correct Shadow DOM behaviour and fix Shadow DOM blockers for Gaia (smaug, wchen) ({{bug|1026047}})}}<br />
* {{risk|land Service Workers preffed off on nightly (nsm, bkelly, baku) ({{bug|903441}})}}<br />
** This is progressing well, but won't be *done* until the end of the quarter, so still on track.<br />
** Note that originally we thought things would be at the point where Gecko and Blink would be far enough along with a stable spec that this could be preffed on. That is not going to be the case but we are still aiming to have a usable implementation preffed off.<br />
** There remain spec questions about Cache which have impacted the design of our implementation.<br />
<br />
=== WebAPI ===<br />
* {{ok|create design plan for "share" activity (flow, what kind of objects are involved) (annevk)}}<br />
* {{ok|document existing activities usage in gaia (ehsan)}}<br />
* {{ok|get [https://w3c.github.io/screen-orientation/ screen orientation spec] to LC (marcosc)}}<br />
* {{done|publish [http://www.w3.org/TR/wake-lock-use-cases/ use cases for wake locks] (marcosc)}}<br />
* {{ok|publish spec for [http://w3c.github.io/wake-lock/ "wakelock" API] (marcosc)}}<br />
* {{done|24/12 hour format API (ehsan) {{bug|903683}}}}<br />
* {{ok|{{bug|942542}} new quota API on PBackground for Service Worker cache (janv)}}<br />
* {{ok|{{bug|701634}} IndexedDB in workers (bent)}}<br />
<br />
=== JS ===<br />
* {{miss|ES6 classes: }}{{Bug|837314}} <br />
* {{jok|1020751}} Generational GC on Firefox OS<br />
* {{jok|650161}} Compacting GC to reduce memory usage<br />
* {{jok|856533}} Escape analysis JIT optimizations<br />
* {{done|Use Latin1 strings to reduce memory usage: }}{{Bug|998392}} <br />
* {{jok|903519}} Allocate strings in GC nursery (for performance)<br />
* {{miss|ARM64 JIT ''[stretch goal]'': }} {{Bug|972710}}<br />
<br />
=== Accessibility ===<br />
* {{risk|}}e10s: proxy the common a11y API stuff like name, role, and states.<br />
* {{done|}}GAIA: Fix [https://bugzilla.mozilla.org/buglist.cgi?priority=--&f1=blocked&list_id=10674217&o1=anyexact&resolution=---&query_based_on=b2ga11y%20p%3D1&o2=substring&query_format=advanced&f2=status_whiteboard&v1=893789&component=Disability%20Access%20APIs&component=Gaia&component=Gaia%3A%3ABluetooth%20File%20Transfer&component=Gaia%3A%3ABrowser&component=Gaia%3A%3ABuild&component=Gaia%3A%3ACalendar&component=Gaia%3A%3ACamera&component=Gaia%3A%3AClock&component=Gaia%3A%3AContacts&component=Gaia%3A%3ACost%20Control&component=Gaia%3A%3ADialer&component=Gaia%3A%3AE-Mail&component=Gaia%3A%3AEverything.me&component=Gaia%3A%3AFirst%20Time%20Experience&component=Gaia%3A%3AFMRadio&component=Gaia%3A%3AGallery&component=Gaia%3A%3AGithubBot&component=Gaia%3A%3AHomescreen&component=Gaia%3A%3AKeyboard&component=Gaia%3A%3AL10n&component=Gaia%3A%3ALoop&component=Gaia%3A%3AMusic&component=Gaia%3A%3ANotes&component=Gaia%3A%3APDF%20Viewer&component=Gaia%3A%3APerformanceTest&component=Gaia%3A%3ARingtones&component=Gaia%3A%3ASearch&component=Gaia%3A%3ASettings&component=Gaia%3A%3ASMS&component=Gaia%3A%3ASystem&component=Gaia%3A%3ASystem%3A%3ABrowser%20Chrome&component=Gaia%3A%3ASystem%3A%3AInput%20Mgmt&component=Gaia%3A%3ASystem%3A%3ALockscreen&component=Gaia%3A%3ASystem%3A%3AWindow%20Mgmt&component=Gaia%3A%3ATestAgent&component=Gaia%3A%3AUI%20Tests&component=Gaia%3A%3AVideo&component=Gaia%3A%3AWallpaper&component=Gaia%3A%3AWappush&v2=b2ga11y%20p%3D1&product=Core&product=Firefox%20OS all Gaia P1 a11y bugs] (~30 at this time).<br />
** 49 (all) are fixed.<br />
* {{done|}}FFOS: {{Bug|1030465}} - Volume change should update the screen reader volume.<br />
* {{done|}}FFOS: {{Bug|1030466}} - Headphones screen reader volume is too low.<br />
* {{done|}}FFOS: {{Bug|1030468}} - VC rectangle needs to work with scaled content.<br />
* {{done|}}FFOS: {{Bug|1030470}} - Localization needs to work when switching locales in FxOS.<br />
<br />
=== Perf ===<br />
<br />
Fix major source of browser jank:<br />
<br />
* {{ok|Initialize plugin instances asynchronously {{bug|998863}} }}<br />
* {{ok|Pause heavy main-thread activities while user is interacting with the browser: }}<br />
** {{ok|Determine when a user is actively interacting with the browser}}<br />
** {{ok|Detect when jank occurs during interactions and report to Telemetry {{bug|1017055}} }}<br />
** {{ok|Experiment with hinting to GC & CC that they should pause while the user is interacting with the browser}}<br />
* {{ok|Help Frontend team with Places refactoring, eliminate some of the [http://telemetry.mozilla.org/slowsql/ Places main-thread SQL] reported to Telemetry }}<br />
* {{ok|Don't store UI customization in localstore.rdf, use off-main thread JSON instead {{bug|559505}} }}<br />
<br />
Improve Firefox startup (identified as a top issue in user research):<br />
<br />
* {{ok|Reduce appearance of the "profile is in use" message on startup {{bug|286355}} }}<br />
* {{ok|Restore windows one by one during session-restore {{bug|1034534}} and/or load windows by descending z-order {{bug|1034036}} }}<br />
* {{ok|C++ version of AsyncShutdown {{bug|918317}} }}<br />
<br />
Prevent performance regressions:<br />
<br />
* {{ok|Implement automatic detection & alerting for Telemetry regressions {{bug|1031032}} }}<br />
* {{ok|Help developers understand & diagnose Talos regressions}}, e.g. [https://bugzilla.mozilla.org/show_bug.cgi?id=1026550 Firefox 33 regression tracking], [https://bugzilla.mozilla.org/show_bug.cgi?id=1004427 Firefox 32 regressions], [https://bugzilla.mozilla.org/show_bug.cgi?id=990085 Firefox 31]<br />
<br />
Grow community:<br />
<br />
* {{ok|Mentor at least 5 external contributors}}<br />
<br />
=== Networking ===<br />
<br />
* {{ok|Ship Network Predictor ("Seer") on nightly, using HTTP cache instead of SQLite ({{bug|1009122}}) (hurley)}}<br />
* {{done|Ship current (hopefully final) IETF version of HTTP/2 preffed on in nightly (hurley)}}<br />
* {{ok|HTTP/2 "alt-svc" support ({{bug|1003448}}) (mcmanus)}}<br />
* {{drop|HTTP cache: determine if revalidation is needed w/o doing I/O ({{bug|983122}}) (sworkman) }}<br />
* {{ok|Network up/down link detection on all platforms ({{bug|939318}}) (bagder) }}<br />
* {{drop|Implement WebSocket compression extension ({{bug|792831}}) (michal) }}<br />
<br />
=== Mobile ===<br />
<br />
=== A*Team ===<br />
<br />
For full list, see [[Auto-tools/Goals/2014Q3|A-Team Goals 2014Q3]]<br />
<br />
'''B2G'''<br />
* {{ok|}} Run a set of performance and correctness tests per-commit to b2g-inbound on Flame devices<br />
* {{ok|}} Get gaia-integration tests running on device<br />
* {{ok|}} Expand the FxOS Certification Suite with 1.4 support, test automation to prevent regressions, and investigation of support for non-phone devices<br />
* {{ok|}} Green up B2G tests on TaskCluster (joint with RelEng)<br />
<br />
'''Developer Productivity'''<br />
* {{ok|}} Deploy ReviewBoard for developers to start using (joint with RelEng)<br />
<br />
'''Performance'''<br />
* {{ok|}} Deploy new Talos tests for tp5o_scroll, webgl, webrtc, and mainthread I/O<br />
* {{ok|}} Get Datazilla alerts to beta mode (full parity with graph server alerts) with reduced noise<br />
* {{ok|}} Get Eideticker running against Android again with increased frequency<br />
* {{ok|}} Run B2G Eideticker against same branch/build combinations as our other on-device perf tests<br />
* {{ok|}} Stand up a Games Benchmarking system for webaudio tests running against Firefox and Chrome<br />
<br />
'''Treeherder'''<br />
* {{ok|}} Deliver performance web service for ingesting and returning performance data <br />
* {{ok|}} Deliver a UI for viewing Talos data<br />
<br />
'''Sheriffing'''<br />
* {{ok|}} Fully transition sheriffing from TBPL to Treeherder<br />
<br />
'''General Automation'''<br />
* {{ok|}} Create weekly reports that describe how many tests have been added/disabled/enabled per suite and platform<br />
* {{ok|}} Move reftest to mozbase<br />
* {{ok|}} Add command executors for Marionette for Java and Python<br />
<br />
'''Bugzilla'''<br />
* {{done|}} Improve load time of related bugs; can decrease show_bug load times by up to 12%<br />
* {{ok|}} Minify and concatenate JS files<br />
* {{ok|}} Authoritative view for review history<br />
* {{ok|}} Rewrite docs for REST API<br />
<br />
'''Community'''<br />
* {{ok|}} Create good_next_bugs (name can be adjusted) so once contributors are comfortable they can do more serious coding/problem solving on a project they are familiar with<br />
* {{ok|}} Monthly review of mentored bugs and projects<br />
<br />
=== Web Engineering ===<br />
'''Crash stats'''<br />
* {{ok|}} Prototype service for identifying post-crash user actions<br />
* {{done|}} Hardware and performance tuning for new primary data store<br />
* {{ok|}} Remove older, redundant crash storage format from database<br />
* {{drop|}} Improve search performance and features<br />
* {{done|}} Replace interfaces to deprecated external data sources<br />
* {{done|}} Remove barriers to community installations<br />
'''FHR'''<br />
* {{done|}} Support search diversion plan<br />
'''DXR'''<br />
* {{ok|}} Improve infrastructure.<br />
** For example, switch to ES backend, which will enable us to build multi-language support and parallel tree indexing.<br />
* {{ok|}} Broaden our audience.<br />
** Pull users away from MXR so we can shut it off. For example, add support for Rust or JS, squash MXR migration blockers.<br />
'''l10n'''<br />
* {{ok|}} Get l10n build logs into a searchable data store<br />
* {{ok|}} Replace some buildbot functionality with a10n automation<br />
'''Air Mozilla'''<br />
* {{done|}} Prototype support for streaming media boxes<br />
* {{done|}} Improve desktop user experience<br />
<br />
[https://etherpad.mozilla.org/webeng-q32014 full list]<br />
<br />
=== SUMO and Input ===<br />
* {{done|}} SUMO: Launch new offline SUMO app [Get Firefox on a Growth Trajectory]<br />
* {{ok|}} SUMO: Develop new Community Hub to a level where it can replace legacy Karma app [Enable Communities with Impact]<br />
* {{ok|}} SUMO: Research and prototype new experimental features (e.g. geotargeting, Instant Search, Search Suggestions) [Get Firefox on a Growth Trajectory]<br />
<br />
* {{done|}} Input: Improve documentation and install to lower the bar for contribution [Enable Communities with Impact]<br />
* {{ok|}} Input: Support Heartbeat [Get Firefox on a Growth Trajectory]<br />
* {{ok|}} Input: Dashboards for Everyone [Get Firefox on a Growth Trajectory]<br />
<br />
=== Release Engineering - Laura ===<br />
* {{drop|}} Enable capacity expansion for bare-metal releng OS X build and test slaves via hardware provided by third-party datacenters (Get Firefox on a Trajectory of Growth)<br />
* {{ok|}} Simplify release engineering mobile hardware infrastructure (Get Firefox on a Trajectory of Growth)<br />
* {{risk|}} Automate developer access to continuous integration resources to expedite debugging and standing up new job variants. (Enable Communities With Impact)<br />
* {{ok|}} Help enable video operability on the web by providing continuous integration for Cisco Open H.264 builds. (Get Firefox on a Trajectory of Growth)<br />
<br />
=== Release Engineering - Taras ===<br />
* {{ok|}} Replace aging Firefox update service with a scalable, modern solution. (Get Firefox on a Trajectory of Growth)<br />
* {{ok|}} Simplify developer workflow by automating patch landing and uplift. (Enable Communities With Impact)<br />
* {{ok|}} Optimize network transfers for build/test automation between datacenters. (Enable Communities With Impact)<br />
* {{ok|}} Continue AWS cost optimizations: EBS < 3% of AWS bill(vs 30% in Q2) (Enable Communities With Impact)<br />
* {{drop|}} Improve developer workflow by migrating 80% of FirefoxOS build/test jobs to taskcluster (Enable Communities With Impact) - this goal is now with jlal in FirefoxOS<br />
* {{drop|}} Turn telemetry into a general purpose s3 ingester and analysis tool - this goal is now with mreid in Services<br />
<br />
=== Release Engineering Operations ===<br />
* Build/Test System Performance Enhancements<br />
** {{drop| Unify releng platform architecture, using common tools and best practices, to decrease complexity and enable smoother developer engagement {{bug|1026110}} [Get Firefox on a Trajectory of Growth, Enable Communities With Impact] - blocked on obtaining necessary resources from other groups }}<br />
** {{ok| Improve communication and response time for releng network flow requests {{bug|1026112}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] }}<br />
** {{ok| Improve security for all releng windows infrastructure {{bug|893716}} [Get Firefox on a Trajectory of Growth] }}<br />
** {{done| Update windows platform developer tools {{bug|1019165}} [Get Firefox on a Trajectory of Growth] }}<br />
* Build/Test System Self-Serve Re-architecture<br />
** {{prev| Design a private cloud deployment architecture for bare metal and produce a POC that supports Ubuntu 12.04 test machines. {{bug|963165}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] }}<br />
** {{drop| Create self-service capability for releng hardware Firefox linux test slaves (build slaves as a stretch goal) {{bug|1026687}} (depends on completion of previous goal) [Get Firefox on a Trajectory of Growth, Scale Firefox OS] - bare metal openstack is proving to be too bleeding edge and buggy to use for production services. We will continue to work on R&D for this project and track changes made in the openstack code base, but we will not move any services to production in FY2014 }}<br />
** {{drop| Create self-service capability for releng hardware Firefox windows test slaves. {{bug|967064}} [Get Firefox on a Growth Trajectory] - Still pending completion of re-prioritized 2008R2 work }}<br />
<br />
=== Developer Services ===<br />
* {{done|(with B-team) roll out phase 2 of new review tooling}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
* {{new|Upgrade existing Mercurial infrastructure to support more rapid, safe, and coordinated deployment of updates.}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
<br />
[https://etherpad.mozilla.org/devservices-Q32014 Full List]<br />
<br />
=== Security & Privacy Engineering ===<br />
More details here: [[SecurityEngineering/2014/Q3Goals]]<br />
<br />
'''Content Security'''<br />
* {{done|Gecko Security Hooks: Finish code and debugging for NS_NewChannel API, start getting reviews}} (dri=tanvi)<br />
* {{defer|Gecko Security Hooks: Create plan for addon compatibility -- doesn't make sense until New Channel API is done, deferring to next quarter when shimming the JS API for creating new channels}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central}} (dri=sstamm)<br />
* {{done|Evangelism: Security blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs}} (dri=ckerschb)<br />
<br />
'''Tracking Protection'''<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help}} (dri=sstamm)<br />
* {{done|Land first implementation of protection in Fx 33/34 off by default. BONUS: landed frontend code too}} (dri=mmc)<br />
<br />
'''Communications Security'''<br />
* {{ok|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok| HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{done| Update [[CA:RevocationPlan|roadmap for Cert Revocation improvements]]}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{done| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{done| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{ok| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)<br />
* {{done| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
<br />
=== Firefox and Platform Security ===<br />
<br />
* [https://mana.mozilla.org/wiki/display/~gkwong@mozilla.com/Marifuzz Marifuzz ] fuzzer ported to and running on Flame devices.<br />
* Update ASan and LSan work for DOMFuzzer<br />
* Update "Bounty Stars" document with issues found by external reporters and updating DOMFuzzer to reflect these results.<br />
* Get Clang on RelEng ready for official OS X ASan builds.<br />
* Initial work to move CoreFuzz towards running in cloud environments.<br />
* WebCrypto API fuzzing using Dharma fuzzer. <br />
* Port a portion of WebRTC fuzzing from Frambois fuzzer to Dharma fuzzer.<br />
* Peach: Improving and porting Peach 2 to Python 3.<br />
* Public Mozilla Security Github work: Moving of fuzzing tools from Fuzzing Hg to GitHub, including work to separate harnesses from testcase generation tools.<br />
<br />
=== Games Program ===<br />
* {{done| Reach out to 3rd party engines en masse (also for Q4)}}<br />
* {{ok| Select a 3D demo for mobile}}<br />
* {{done| Pick a partner demo to optimize for mobile}}<br />
* {{ok| Focus on supporting shipping games and maintaining platform stability }}<br />
* {{ok| Focus on Shared Array Buffer implementation }}<br />
* {{risk| WebGL Benchmarks}}<br />
* {{ok| Continue to work MDN documentation; get Emscripten documentation started }}<br />
* {{ok| GDC and MWC event support plan}}<br />
<br />
=== Release Management ===<br />
For full list, see [[Release_Management/Goals/2014Q3#Release_Management_General|Release Management 2014Q3 Goals]].<br />
* Create and document process for Desktop/Mobile feature fast tracking<br />
* {{done|}} Determine future of ESR and how to manage this channel<br />
** https://groups.google.com/forum/#!topic/mozilla.dev.planning/-IQWXs_zEp8<br />
* {{done|}} Continue desktop throttling experiment with intention of reducing throttled time while maintaining existing level of feedback<br />
** Throttling time currently reduced from 10 to 7 days. Experimenting with further reductions.<br />
* Improve release notes with revamped template for all products<br />
* Create B2G release model proposals and gather feedback for potential changes<br />
* Figure out what to do with B2G Security Releases<br />
<br />
===Program Management===<br />
<br />
See this wiki page for a full list of [https://wiki.mozilla.org/Program_Management/Firefox/2014-Q3-Goals Program Management goals].<br />
<br />
* {{ok|Create a set of dashboards based on the ES database to track platform projects and surface bottlenecks.}}<br />
** Narrowed focus to a set of dashboards for review queues for individuals and teams. <br />
* {{risk|Brown bag presentation/restropective on the agile processes we are using on Desktop and FirefoxOS}}<br />
** With the reorg, revisiting the purpose/target. Might change this goal slightly. Still probably worthwhile planning a brown bag to talk about Desktop process and introduce Trello planning tool for Platform.<br />
* {{ok|Evaluate and produce a report on several tools for helping organize and visualize team backlogs and priority lists; wiki, spreadsheets, Trello, Kanbanize}}<br />
** Using a Trello board for Platform work. Jenn piloting Kanban board for Desktop/Android. Should have a summary, write-up ready by end of Sept.<br />
<br />
=== Quality Engineering ===<br />
See this wiki for the full list of [https://wiki.mozilla.org/QA/Goals/2014q3 Quality goals]. What follows are our brief summary of our internal improvement goals for each strategic team.<br />
* Firefox QA - Revitalize our Quality Engineering strategy by switching to a feature-based test strategy for all Firefox browser products so that there are test plans for each feature and testing is executed within two sprints of the feature's code landing<br />
* Firefox OS - Better metrics for quality analysis, provide opportunities for community contribution, and expanding the role of our on-device automation for reporting to Treeherder.<br />
* Services - Ensure new offerings have 98% uptime (FxA Sync, OAuth, FMD, Loop) and no more than 2 P1 bugs discovered post launch while building a core contributor base in services<br />
* Marketplace - Ensure Marketplace's new payments backend, in-app payments, and the Marketplace feed land with high quality releases.<br />
* Platform QA - Deploy into continuous integration a regression testing system for WebRTC along three areas of investigation: 1. "Smoke" tests, 2. Connection tests, and 3. Connection quality tests. These will be performed in a variety of environments, including various network topologies with various performance characteristics, connections between various versions of Firefox, and connections on multiple OS platforms. Test plans will be developed, and we will measure coverage of test plans. Results will be posted and available in Treeherder. We will also build backlog for next Platform Tiger Team tasks.<br />
* Community - Increase conversion of interested and casual contributors to help them become active contributors with strong ties to the QA community</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q3Goals&diff=1017069SecurityEngineering/2014/Q3Goals2014-09-22T19:44:46Z<p>Sidstamm: </p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
(Also linked from [[Platform/2014-Q3-Goals#Security_.26_Privacy_Engineering]]).<br />
<br />
== Content Security ==<br />
;Outcome: Progress towards more robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid<br />
<br />
* {{done|Gecko Security Hooks: Finish code and debugging for New Channel API, start getting reviews.}} See {{bug|1038756}}, {{bug|1006881}} (dri=tanvi)<br />
* {{defer|Gecko Security Hooks: Create plan for addon compatibility - nothing to do yet}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central. Target Fx34.}} See {{bug|994782}} (dri=sstamm)<br />
* {{done|Evangelism: Security blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs.}} See [https://etherpad.mozilla.org/CSP-1-1 planning etherpad] (dri=ckerschb)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Monica, Garrett, Sid, Georgios<br />
<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help.}} See {{bug|704320}}. (dri=sstamm)<br />
* {{done|Land backend and bridge code for first implementation of protection in Fx 33/34 off by default. BONUS: landed frontend code too}} (dri=mmc)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks.<br />
;Who: Richard, Kathleen, Keeler, Camilo, Harsh, Garrett, Monica<br />
<br />
* {{ok|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok|HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{done| Update [[CA:RevocationPlan|roadmap for Cert Revocation improvements]]}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{done| Add measurement/enforcement of compliance with CABF Baseline Requirements}}. See {{bug|1050546}} (dri=keeler)<br />
* {{done| Create a tool for testing CA certificate compliance and EV-readiness}}. See {{bug|926599}} and {{bug|1029095}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{risk| ''[stretch goal]'' Enable revocation of intermediate CAs through block list service}} (dri=mgoodwin, keeler)<br />
* {{done| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
* {{ok| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=Platform/2014-Q3-Goals&diff=1013203Platform/2014-Q3-Goals2014-09-08T21:50:53Z<p>Sidstamm: /* Security & Privacy Engineering */</p>
<hr />
<div>=== Platform ===<br />
==== [[Platform/2014-Goals|2014 General Goals]] ====<br />
<br />
=== GFX ===<br />
Items marked [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AnKFEBp1-VyqdFNfRlZmV0ExM0VvZGMxNThWX0d6LWc&usp=drive_web#gid=0 here] with release 33 and 34 are part of the Q3 landings.<br />
<br />
=== Layout ===<br />
* Layout to Moz2D<br />
** {{ok|Migrate SVG to Moz2D (bug 703159) }}<br />
<br />
* Enable Vertical Text for major use cases for Chinese & Japanese<br />
** {{miss|{{bug|145503}}}} - Meta Bug. We've made lots of progress, but our big bug won't get closed until Q4<br />
** {{done|{{bug|789096}}}} - Layout with horizontal block flow and vertical text flow<br />
** {{ok|{{bug|902762}}}} - Vertical text run creation<br />
** {{risk|{{bug|1062963}}}} - Make nsFloatManager use logical coordinates<br />
<br />
* Text Performance<br />
** We'll get 1 of the 3 we wanted to hit.<br />
** {{ok|{{bug|998869}}}} Streamline parsing of fontlists and improve efficiency of font matching code (note: unicode-range support will fall out of this work)<br />
** {{miss|{{bug|934770}}}} - slow at rendering large blocks of plain text<br />
** {{miss|{{bug|860492}}}} - Divide large text runs into smaller runs to avoid chrome hangs<br />
<br />
* Improve Restyling Performance<br />
** {{ok|bug 977991}}<br />
<br />
* {{drop|Font Inflation and Reflow-on-Zoom }}<br />
** We picked up scrolling features/fixes in Q3 and deferred this item<br />
** both implementation bug fixing and spec work<br />
** -moz-text-size-adjust <br />
<br />
* ImageLib<br />
** {{ok|RasterImage for multiple images}}<br />
<br />
* CSS Projects with Adobe<br />
** {{done|CSS Filters}}<br />
<br />
* Animations & Transitions<br />
** {{ok|transitions/animations spec editing}}<br />
** {{risk|transitions refactoring to match new spec}} <br />
*** {{done|{{bug|996796}}}} landed, but work is ongoing for {{bug|960465}}<br />
** {{done|frame reconstruction (625289)}}<br />
<br />
* OMTA on non-B2G Platforms (980770)<br />
** {{ok|fix correctness bugs (cascading, etc.)}}<br />
** {{ok|turning on on other OMTC platforms (Mac/Android)}}<br />
<br />
* Web animations: <br />
** {{ok|TBD}}<br />
<br />
* CSS Scrolling<br />
** {{ok|CSS scroll snapping}}<br />
** {{ok|scroll-behavior:smooth}}<br />
<br />
* CSS Flexbox <br />
** {{ok|performance bugs}}<br />
** {{ok|spec changes}}<br />
<br />
* CSS Ruby <br />
** Our intern got through a bunch of this, but we'll continue it next quarter<br />
** {{ok|implementation}}<br />
<br />
=== Media ===<br />
* {{miss|Enable YouTube MSE/VP9 for Firefox 33 in Nightly/Aurora {{bug|1000686}}}}<br />
* {{miss|Enable YouTube MSE/MP4 on Windows and Firefox OS for Firefox 34}}<br />
<br />
'''Detailed Breakdown'''<br />
* MSE Common<br />
** {{done|Rate adaption/buffer switching, reseting}}<br />
** {{miss|Seeking into unbuffered ranges {{bug|1056440}}}}<br />
** {{todo|Eviction/pinning}}<br />
* MSE WebM<br />
** {{done|WebM segment parser {{bug|881512}}{{bug|1044498}}}}<br />
* MSE MP4<br />
** {{done|MP4 segment parser {{bug|1027875}}{{bug|1057203}}}}<br />
** MP4 Demuxer<br />
*** {{done|Integrate stagefright MP4 demuxer {{bug|908503}}}}<br />
*** {{done|Accurate range reporting {{bug|1045909}}}}<br />
*** {{done|CENC support {{bug|1022434}}}}<br />
*** {{todo|DASHIF and other players aside from YouTube {{bug|1039149}}}}<br />
** H.264/AAC Decoder<br />
*** {{done|MP4/fMP4 platform decoder module for Mac OSX {{bug|941296}}}}<br />
*** {{miss|MP4 support on Firefox OS {{bug|1060900}}}}<br />
**** {{done|MP4 platform decoder module for Firefox OS {{bug|941302}}}}<br />
**** {{miss|Use a single shared decoder for MSE on b2g {{bug|1036849}}}}<br />
<br />
=== DOM ===<br />
* {{done|Mirror prototype of DOM objects through xray wrappers (peterv)}}<br />
* {{risk|Remove nsDOMClassInfo.cpp}}<br />
** Given the recent focus on e10s, we may not get through all of this work this quarter.<br />
* {{done|Make less-privileged non-Xrayable unwaived opaque from privileged code (bholley, {{bug|856067}})}}<br />
* {{done|Route all JSContext pushing through AutoJSAPI and Implement GetEntryGlobal (bobowen, bholley, {{bug|951991}})}}<br />
* {{ok|Land <picture> preffed on on nightly ({{bug|1017875}}) (johns)}}<br />
* {{done|audit callsites of IsInDoc()/GetCurrentDoc to ensure correct Shadow DOM behaviour and fix Shadow DOM blockers for Gaia (smaug, wchen) ({{bug|1026047}})}}<br />
* {{ok|land Service Workers preffed off on nightly (nsm, bkelly, baku) ({{bug|903441}})}}<br />
** This is progressing well, but won't be *done* until the end of the quarter, so still on track.<br />
** Note that originally we thought things would be at the point where Gecko and Blink would be far enough along with a stable spec that this could be preffed on. That is not going to be the case but we are still aiming to have a usable implementation preffed off.<br />
<br />
=== WebAPI ===<br />
* {{ok|create design plan for "share" activity (flow, what kind of objects are involved) (annevk)}}<br />
* {{ok|document existing activities usage in gaia (ehsan)}}<br />
* {{ok|get [https://w3c.github.io/screen-orientation/ screen orientation spec] to LC (marcosc)}}<br />
* {{done|publish [http://www.w3.org/TR/wake-lock-use-cases/ use cases for wake locks] (marcosc)}}<br />
* {{ok|publish spec for [http://w3c.github.io/wake-lock/ "wakelock" API] (marcosc)}}<br />
* {{done|24/12 hour format API (ehsan) {{bug|903683}}}}<br />
* {{ok|{{bug|942542}} new quota API on PBackground for Service Worker cache (janv)}}<br />
* {{ok|{{bug|701634}} IndexedDB in workers (bent)}}<br />
<br />
=== JS ===<br />
* {{miss|ES6 classes: }}{{Bug|837314}} <br />
* {{jok|1020751}} Generational GC on Firefox OS<br />
* {{jok|650161}} Compacting GC to reduce memory usage<br />
* {{jok|856533}} Escape analysis JIT optimizations<br />
* {{done|Use Latin1 strings to reduce memory usage: }}{{Bug|998392}} <br />
* {{jok|903519}} Allocate strings in GC nursery (for performance)<br />
* {{miss|ARM64 JIT ''[stretch goal]'': }} {{Bug|972710}}<br />
<br />
=== Accessibility ===<br />
* {{ok|}}e10s: proxy the common a11y API stuff like name, role, and states.<br />
* {{ok|}}GAIA: Fix [https://bugzilla.mozilla.org/buglist.cgi?priority=--&f1=blocked&list_id=10674217&o1=anyexact&resolution=---&query_based_on=b2ga11y%20p%3D1&o2=substring&query_format=advanced&f2=status_whiteboard&v1=893789&component=Disability%20Access%20APIs&component=Gaia&component=Gaia%3A%3ABluetooth%20File%20Transfer&component=Gaia%3A%3ABrowser&component=Gaia%3A%3ABuild&component=Gaia%3A%3ACalendar&component=Gaia%3A%3ACamera&component=Gaia%3A%3AClock&component=Gaia%3A%3AContacts&component=Gaia%3A%3ACost%20Control&component=Gaia%3A%3ADialer&component=Gaia%3A%3AE-Mail&component=Gaia%3A%3AEverything.me&component=Gaia%3A%3AFirst%20Time%20Experience&component=Gaia%3A%3AFMRadio&component=Gaia%3A%3AGallery&component=Gaia%3A%3AGithubBot&component=Gaia%3A%3AHomescreen&component=Gaia%3A%3AKeyboard&component=Gaia%3A%3AL10n&component=Gaia%3A%3ALoop&component=Gaia%3A%3AMusic&component=Gaia%3A%3ANotes&component=Gaia%3A%3APDF%20Viewer&component=Gaia%3A%3APerformanceTest&component=Gaia%3A%3ARingtones&component=Gaia%3A%3ASearch&component=Gaia%3A%3ASettings&component=Gaia%3A%3ASMS&component=Gaia%3A%3ASystem&component=Gaia%3A%3ASystem%3A%3ABrowser%20Chrome&component=Gaia%3A%3ASystem%3A%3AInput%20Mgmt&component=Gaia%3A%3ASystem%3A%3ALockscreen&component=Gaia%3A%3ASystem%3A%3AWindow%20Mgmt&component=Gaia%3A%3ATestAgent&component=Gaia%3A%3AUI%20Tests&component=Gaia%3A%3AVideo&component=Gaia%3A%3AWallpaper&component=Gaia%3A%3AWappush&v2=b2ga11y%20p%3D1&product=Core&product=Firefox%20OS all Gaia P1 a11y bugs] (~30 at this time).<br />
* {{done|}}FFOS: {{Bug|1030465}} - Volume change should update the screen reader volume.<br />
* {{done|}}FFOS: {{Bug|1030466}} - Headphones screen reader volume is too low.<br />
* {{done|}}FFOS: {{Bug|1030468}} - VC rectangle needs to work with scaled content.<br />
* {{done|}}FFOS: {{Bug|1030470}} - Localization needs to work when switching locales in FxOS.<br />
<br />
=== Perf ===<br />
<br />
Fix major source of browser jank:<br />
<br />
* {{ok|Initialize plugin instances asynchronously {{bug|998863}} }}<br />
* {{ok|Pause heavy main-thread activities while user is interacting with the browser: }}<br />
** {{ok|Determine when a user is actively interacting with the browser}}<br />
** {{ok|Detect when jank occurs during interactions and report to Telemetry {{bug|1017055}} }}<br />
** {{ok|Experiment with hinting to GC & CC that they should pause while the user is interacting with the browser}}<br />
* {{ok|Help Frontend team with Places refactoring, eliminate some of the [http://telemetry.mozilla.org/slowsql/ Places main-thread SQL] reported to Telemetry }}<br />
* {{ok|Don't store UI customization in localstore.rdf, use off-main thread JSON instead {{bug|559505}} }}<br />
<br />
Improve Firefox startup (identified as a top issue in user research):<br />
<br />
* {{ok|Reduce appearance of the "profile is in use" message on startup {{bug|286355}} }}<br />
* {{ok|Restore windows one by one during session-restore {{bug|1034534}} and/or load windows by descending z-order {{bug|1034036}} }}<br />
* {{ok|C++ version of AsyncShutdown {{bug|918317}} }}<br />
<br />
Prevent performance regressions:<br />
<br />
* {{ok|Implement automatic detection & alerting for Telemetry regressions {{bug|1031032}} }}<br />
* {{ok|Help developers understand & diagnose Talos regressions}}, e.g. [https://bugzilla.mozilla.org/show_bug.cgi?id=1026550 Firefox 33 regression tracking], [https://bugzilla.mozilla.org/show_bug.cgi?id=1004427 Firefox 32 regressions], [https://bugzilla.mozilla.org/show_bug.cgi?id=990085 Firefox 31]<br />
<br />
Grow community:<br />
<br />
* {{ok|Mentor at least 5 external contributors}}<br />
<br />
=== Networking ===<br />
<br />
* {{ok|Ship Network Predictor ("Seer") on nightly, using HTTP cache instead of SQLite ({{bug|1009122}}) (hurley)}}<br />
* {{ok|Ship current (hopefully final) IETF version of HTTP/2 preffed on in nightly (hurley)}}<br />
* {{ok|HTTP/2 "alt-svc" support ({{bug|1003448}}) (mcmanus)}}<br />
* {{ok|HTTP cache: determine if revalidation is needed w/o doing I/O ({{bug|983122}}) (sworkman) }}<br />
* {{ok|Network up/down link detection on all platforms ({{bug|939318}}) (bagder) }}<br />
* {{ok|Implement WebSocket compression extension ({{bug|792831}}) (michal) }}<br />
<br />
=== Mobile ===<br />
<br />
=== A*Team ===<br />
<br />
For full list, see [[Auto-tools/Goals/2014Q3|A-Team Goals 2014Q3]]<br />
<br />
'''B2G'''<br />
* {{ok|}} Run a set of performance and correctness tests per-commit to b2g-inbound on Flame devices<br />
* {{ok|}} Get gaia-integration tests running on device<br />
* {{ok|}} Expand the FxOS Certification Suite with 1.4 support, test automation to prevent regressions, and investigation of support for non-phone devices<br />
* {{ok|}} Green up B2G tests on TaskCluster (joint with RelEng)<br />
<br />
'''Developer Productivity'''<br />
* {{ok|}} Deploy ReviewBoard for developers to start using (joint with RelEng)<br />
<br />
'''Performance'''<br />
* {{ok|}} Deploy new Talos tests for tp5o_scroll, webgl, webrtc, and mainthread I/O<br />
* {{ok|}} Get Datazilla alerts to beta mode (full parity with graph server alerts) with reduced noise<br />
* {{ok|}} Get Eideticker running against Android again with increased frequency<br />
* {{ok|}} Run B2G Eideticker against same branch/build combinations as our other on-device perf tests<br />
* {{ok|}} Stand up a Games Benchmarking system for webaudio tests running against Firefox and Chrome<br />
<br />
'''Treeherder'''<br />
* {{ok|}} Deliver performance web service for ingesting and returning performance data <br />
* {{ok|}} Deliver a UI for viewing Talos data<br />
<br />
'''Sheriffing'''<br />
* {{ok|}} Fully transition sheriffing from TBPL to Treeherder<br />
<br />
'''General Automation'''<br />
* {{ok|}} Create weekly reports that describe how many tests have been added/disabled/enabled per suite and platform<br />
* {{ok|}} Move reftest to mozbase<br />
* {{ok|}} Add command executors for Marionette for Java and Python<br />
<br />
'''Bugzilla'''<br />
* {{done|}} Improve load time of related bugs; can decrease show_bug load times by up to 12%<br />
* {{ok|}} Minify and concatenate JS files<br />
* {{ok|}} Authoritative view for review history<br />
* {{ok|}} Rewrite docs for REST API<br />
<br />
'''Community'''<br />
* {{ok|}} Create good_next_bugs (name can be adjusted) so once contributors are comfortable they can do more serious coding/problem solving on a project they are familiar with<br />
* {{ok|}} Monthly review of mentored bugs and projects<br />
<br />
=== Web Engineering ===<br />
'''Crash stats'''<br />
* {{ok|}} Prototype service for identifying post-crash user actions<br />
* {{done|}} Hardware and performance tuning for new primary data store<br />
* {{ok|}} Remove older, redundant crash storage format from database<br />
* {{drop|}} Improve search performance and features<br />
* {{done|}} Replace interfaces to deprecated external data sources<br />
* {{ok|}} Remove barriers to community installations<br />
'''FHR'''<br />
* {{ok|}} Support search diversion plan<br />
'''DXR'''<br />
* {{ok|}} Improve infrastructure.<br />
** For example, switch to ES backend, which will enable us to build multi-language support and parallel tree indexing.<br />
* {{ok|}} Broaden our audience.<br />
** Pull users away from MXR so we can shut it off. For example, add support for Rust or JS, squash MXR migration blockers.<br />
'''l10n'''<br />
* {{ok|}} Get l10n build logs into a searchable data store<br />
* {{ok|}} Replace some buildbot functionality with a10n automation<br />
'''Air Mozilla'''<br />
* {{done|}} Prototype support for streaming media boxes<br />
* {{done|}} Improve desktop user experience<br />
<br />
[https://etherpad.mozilla.org/webeng-q32014 full list]<br />
<br />
=== SUMO and Input ===<br />
* {{done|}} SUMO: Launch new offline SUMO app [Get Firefox on a Growth Trajectory]<br />
* {{ok|}} SUMO: Develop new Community Hub to a level where it can replace legacy Karma app [Enable Communities with Impact]<br />
* {{ok|}} SUMO: Research and prototype new experimental features (e.g. geotargeting, Instant Search, Search Suggestions) [Get Firefox on a Growth Trajectory]<br />
<br />
* {{done|}} Input: Improve documentation and install to lower the bar for contribution [Enable Communities with Impact]<br />
* {{ok|}} Input: Support Heartbeat [Get Firefox on a Growth Trajectory]<br />
* {{ok|}} Input: Dashboards for Everyone [Get Firefox on a Growth Trajectory]<br />
<br />
=== Release Engineering - Laura ===<br />
* {{drop|}} Enable capacity expansion for bare-metal releng OS X build and test slaves via hardware provided by third-party datacenters (Get Firefox on a Trajectory of Growth)<br />
* {{ok|}} Simplify release engineering mobile hardware infrastructure (Get Firefox on a Trajectory of Growth)<br />
* {{ok|}} Automate developer access to continuous integration resources to expedite debugging and standing up new job variants. (Enable Communities With Impact)<br />
* {{ok|}} Help enable video operability on the web by providing continuous integration for Cisco Open H.264 builds. (Get Firefox on a Trajectory of Growth)<br />
<br />
=== Release Engineering - Taras ===<br />
* {{ok|}} Replace aging Firefox update service with a scalable, modern solution. (Get Firefox on a Trajectory of Growth)<br />
* {{ok|}} Simplify developer workflow by automating patch landing and uplift. (Enable Communities With Impact)<br />
* {{ok|}} Optimize network transfers for build/test automation between datacenters. (Enable Communities With Impact)<br />
* {{ok|}} Continue AWS cost optimizations: EBS < 3% of AWS bill(vs 30% in Q2) (Enable Communities With Impact)<br />
* {{ok|}} Improve developer workflow by migrating 80% of FirefoxOS build/test jobs to taskcluster (Enable Communities With Impact)<br />
* {{ok|}} Turn telemetry is into a general purpose s3 ingester and analysis tool<br />
<br />
=== Release Engineering Operations ===<br />
* Build/Test System Performance Enhancements<br />
** {{drop| Unify releng platform architecture, using common tools and best practices, to decrease complexity and enable smoother developer engagement {{bug|1026110}} [Get Firefox on a Trajectory of Growth, Enable Communities With Impact] - blocked on obtaining necessary resources from other groups }}<br />
** {{ok| Improve communication and response time for releng network flow requests {{bug|1026112}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] }}<br />
** {{ok| Improve security for all releng windows infrastructure {{bug|893716}} [Get Firefox on a Trajectory of Growth] }}<br />
** {{done| Update windows platform developer tools {{bug|1019165}} [Get Firefox on a Trajectory of Growth] }}<br />
* Build/Test System Self-Serve Re-architecture<br />
** {{prev| Design a private cloud deployment architecture for bare metal and produce a POC that supports Ubuntu 12.04 test machines. {{bug|963165}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] }}<br />
** {{drop| Create self-service capability for releng hardware Firefox linux test slaves (build slaves as a stretch goal) {{bug|1026687}} (depends on completion of previous goal) [Get Firefox on a Trajectory of Growth, Scale Firefox OS] - bare metal openstack is proving to be too bleeding edge and buggy to use for production services. We will continue to work on R&D for this project and track changes made in the openstack code base, but we will not move any services to production in FY2014 }}<br />
** {{drop| Create self-service capability for releng hardware Firefox windows test slaves. {{bug|967064}} [Get Firefox on a Growth Trajectory] - Still pending completion of re-prioritized 2008R2 work }}<br />
<br />
=== Developer Services ===<br />
* {{done|(with B-team) roll out phase 2 of new review tooling}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
* {{new|Upgrade existing Mercurial infrastructure to support more rapid, safe, and coordinated deployment of updates.}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
<br />
[https://etherpad.mozilla.org/devservices-Q32014 Full List]<br />
<br />
=== Security & Privacy Engineering ===<br />
More details here: [[SecurityEngineering/2014/Q3Goals]]<br />
<br />
'''Content Security'''<br />
* {{ok|Gecko Security Hooks: Finish code and debugging for New Channel API, start getting reviews}} (dri=tanvi)<br />
* {{hold|Gecko Security Hooks: Create plan for addon compatibility -- doesn't make sense until New Channel API is done}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central}} (dri=sstamm)<br />
* {{ok|Evangelism: Security Open Mic presentation + blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs}} (dri=ckerschb)<br />
<br />
'''Tracking Protection'''<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help}} (dri=sstamm)<br />
* {{done|Land first implementation of protection in Fx 33/34 off by default. BONUS: landed frontend code too}} (dri=mmc)<br />
<br />
'''Communications Security'''<br />
* {{ok|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok| HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{done| Update [[CA:RevocationPlan|roadmap for Cert Revocation improvements]]}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{done| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{ok| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{ok| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)<br />
* {{done| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
<br />
=== Firefox and Platform Security ===<br />
<br />
* [https://mana.mozilla.org/wiki/display/~gkwong@mozilla.com/Marifuzz Marifuzz ] fuzzer ported to and running on Flame devices.<br />
* Update ASan and LSan work for DOMFuzzer<br />
* Update "Bounty Stars" document with issues found by external reporters and updating DOMFuzzer to reflect these results.<br />
* Get Clang on RelEng ready for official OS X ASan builds.<br />
* Initial work to move CoreFuzz towards running in cloud environments.<br />
* WebCrypto API fuzzing using Dharma fuzzer. <br />
* Port a portion of WebRTC fuzzing from Frambois fuzzer to Dharma fuzzer.<br />
* Peach: Improving and porting Peach 2 to Python 3.<br />
* Public Mozilla Security Github work: Moving of fuzzing tools from Fuzzing Hg to GitHub, including work to separate harnesses from testcase generation tools.<br />
<br />
=== Games Program ===<br />
*Reach out to 3rd party engines en masse (also for Q4)<br />
*Select a 3D demo for mobile<br />
*Pick a partner demo to optimize for mobile<br />
*Focus on supporting shipping games and maintaining platform stability <br />
*Focus on Shared Array Buffer implementation<br />
*WebGL Benchmarks<br />
*Continue to work MDN documentation; get Emscripten documentation started<br />
*GDC and MWC event support plan<br />
<br />
=== Release Management ===<br />
For full list, see [[Release_Management/Goals/2014Q3#Release_Management_General|Release Management 2014Q3 Goals]].<br />
* Create and document process for Desktop/Mobile feature fast tracking<br />
* Determine future of ESR and how to manage this channel<br />
* Continue desktop throttling experiment with intention of reducing throttled time while maintaining existing level of feedback<br />
* Improve release notes with revamped template for all products<br />
* Create B2G release model proposals and gather feedback for potential changes<br />
* Figure out what to do with B2G Security Releases<br />
<br />
===Program Management===<br />
<br />
See this wiki page for a full list of [https://wiki.mozilla.org/Program_Management/Firefox/2014-Q3-Goals Program Management goals].<br />
<br />
* {{ok|Create a set of dashboards based on the ES database to track platform projects and surface bottlenecks.}}<br />
** Narrowed focus to a set of dashboards for review queues for individuals and teams. <br />
* {{risk|Brown bag presentation/restropective on the agile processes we are using on Desktop and FirefoxOS}}<br />
** With the reorg, revisiting the purpose/target. Might change this goal slightly. Still probably worthwhile planning a brown bag to talk about Desktop process and introduce Trello planning tool for Platform.<br />
* {{ok|Evaluate and produce a report on several tools for helping organize and visualize team backlogs and priority lists; wiki, spreadsheets, Trello, Kanbanize}}<br />
** Using a Trello board for Platform work. Jenn piloting Kanban board for Desktop/Android. Should have a summary, write-up ready by end of Sept.<br />
<br />
=== Quality Engineering ===<br />
See this wiki for the full list of [https://wiki.mozilla.org/QA/Goals/2014q3 Quality goals]. What follows are our brief summary of our internal improvement goals for each strategic team.<br />
* Firefox QA - Revitalize our Quality Engineering strategy by switching to a feature-based test strategy for all Firefox browser products so that there are test plans for each feature and testing is executed within two sprints of the feature's code landing<br />
* Firefox OS - Better metrics for quality analysis, provide opportunities for community contribution, and expanding the role of our on-device automation for reporting to Treeherder.<br />
* Services - Ensure new offerings have 98% uptime (FxA Sync, OAuth, FMD, Loop) and no more than 2 P1 bugs discovered post launch while building a core contributor base in services<br />
* Marketplace - Ensure Marketplace's new payments backend, in-app payments, and the Marketplace feed land with high quality releases.<br />
* Platform QA - Deploy into continuous integration a regression testing system for WebRTC along three areas of investigation: 1. "Smoke" tests, 2. Connection tests, and 3. Connection quality tests. These will be performed in a variety of environments, including various network topologies with various performance characteristics, connections between various versions of Firefox, and connections on multiple OS platforms. Test plans will be developed, and we will measure coverage of test plans. Results will be posted and available in Treeherder. We will also build backlog for next Platform Tiger Team tasks.<br />
* Community - Increase conversion of interested and casual contributors to help them become active contributors with strong ties to the QA community</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q3Goals&diff=1013202SecurityEngineering/2014/Q3Goals2014-09-08T21:49:42Z<p>Sidstamm: /* Communications Security */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
(Also linked from [[Platform/2014-Q3-Goals#Security_.26_Privacy_Engineering]]).<br />
<br />
== Content Security ==<br />
;Outcome: Progress towards more robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid<br />
<br />
* {{ok|Gecko Security Hooks: Finish code and debugging for New Channel API, start getting reviews.}} See {{bug|1038756}}, {{bug|1006881}} (dri=tanvi)<br />
* {{hold|Gecko Security Hooks: Create plan for addon compatibility - nothing to do yet}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central. Target Fx34.}} See {{bug|994782}} (dri=sstamm)<br />
* {{ok|Evangelism: Security Open Mic presentation + blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs.}} See [https://etherpad.mozilla.org/CSP-1-1 planning etherpad] (dri=ckerschb)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Monica, Garrett, Sid, Georgios<br />
<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help.}} See {{bug|704320}}. (dri=sstamm)<br />
* {{done|Land backend and bridge code for first implementation of protection in Fx 33/34 off by default. BONUS: landed frontend code too}} (dri=mmc)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks.<br />
;Who: Richard, Kathleen, Keeler, Camilo, Harsh, Garrett, Monica<br />
<br />
* {{ok|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok|HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{done| Update [[CA:RevocationPlan|roadmap for Cert Revocation improvements]]}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{done| Add measurement/enforcement of compliance with CABF Baseline Requirements}}. See {{bug|1050546}} (dri=keeler)<br />
* {{ok| Create a tool for testing CA certificate compliance and EV-readiness}}. See {{bug|926599}} and {{bug|1029095}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{risk| ''[stretch goal]'' Enable revocation of intermediate CAs through block list service}} (dri=mgoodwin, keeler)<br />
* {{done| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
* {{ok| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q3Goals&diff=1013199SecurityEngineering/2014/Q3Goals2014-09-08T21:46:06Z<p>Sidstamm: /* Content Security */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
(Also linked from [[Platform/2014-Q3-Goals#Security_.26_Privacy_Engineering]]).<br />
<br />
== Content Security ==<br />
;Outcome: Progress towards more robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid<br />
<br />
* {{ok|Gecko Security Hooks: Finish code and debugging for New Channel API, start getting reviews.}} See {{bug|1038756}}, {{bug|1006881}} (dri=tanvi)<br />
* {{hold|Gecko Security Hooks: Create plan for addon compatibility - nothing to do yet}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central. Target Fx34.}} See {{bug|994782}} (dri=sstamm)<br />
* {{ok|Evangelism: Security Open Mic presentation + blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs.}} See [https://etherpad.mozilla.org/CSP-1-1 planning etherpad] (dri=ckerschb)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Monica, Garrett, Sid, Georgios<br />
<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help.}} See {{bug|704320}}. (dri=sstamm)<br />
* {{done|Land backend and bridge code for first implementation of protection in Fx 33/34 off by default. BONUS: landed frontend code too}} (dri=mmc)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks.<br />
;Who: Richard, Kathleen, Keeler, Camilo, Harsh, Garrett, Monica<br />
<br />
* {{ok|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok|HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{done| Update roadmap for Cert Revocation improvements}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{ok| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{ok| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{risk| ''[stretch goal]'' Enable revocation of intermediate CAs through block list service}} (dri=harsh, keeler)<br />
* {{done| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
* {{ok| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=Platform/2014-09-09&diff=1013068Platform/2014-09-092014-09-08T17:20:51Z<p>Sidstamm: /* Seceng (ckerschb) */</p>
<hr />
<div><!-- Maybe don't screw with these links unless you've read this blog post:<br />
http://blog.johnath.com/2011/01/20/automatic-date-links-in-mediawiki/<br />
Just copy them to new pages and it should Just Work!<br />
--><br />
<br />
<small>[[Platform/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|&laquo; previous week]] | [[Platform|index]] | [[Platform/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week &raquo;]]</small><br />
<br />
<div class="h-event vevent"><br />
'''<span class="p-summary summary">Engineering Meeting</span> Details'''<br />
* <span class="dt-start dtstart">Tuesday <span class="value">{{#time: Y-m-d | {{SUBPAGENAME}} }}</span> - <span class="value">11:00</span> am <abbr class="value" title="-0800">Pacific Standard Time</abbr></span><br />
{{conf|98411}}<br />
* <span class="location">[https://v.mozilla.com/flex.html?roomdirect.html&key=T2v8Pi8WuTRc Engineering Vidyo Room] / [https://air.mozilla.org/ Air Mozilla] / MTV Alien Nation / TOR Finch / SFO Warfield / PDX Hair of the Dog</span><br />
* join irc.mozilla.org [irc://irc.mozilla.org/planning #planning] for back channel<br />
</div><br />
<br />
==Need To Know==<br />
<small>(Release and system issues that may impact engineering this week.)</small><br />
<br />
===Notices/Schedule (lsblakk/sylvestre)===<br />
{| class="wikitable" style="color:green; background-color:#ffffcc;" cellpadding="10" padding="5"<br />
|-<br />
|colspan="2"|<big>Next Merge:</big> '''{{FIREFOX_MERGE_DATE}}'''<br />
|colspan="2"|<big>Next Release:</big> '''{{FIREFOX_SHIP_DATE}}'''<br />
|-<br />
!colspan="4" style="color:black;"|Trains<br />
|-<br />
|Central: {{CENTRAL_VERSION}} <br />
|Aurora: {{AURORA_VERSION}} <br />
|Beta: {{BETA_VERSION}} <br />
|Release: {{RELEASE_VERSION}}<br />
|}<br />
<br />
<br />
===Build Changes (gps)===<br />
<small>(Build changes of which engineers should be aware.)</small><br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===RelEng (catlee)===<br />
<small>(Repo, test, and other information for engineers from the release engineering team.)</small><br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Upcoming Outages/Upgrades===<br />
<small>(System outages/upgrades and tree closures that impact engineering.)</small><br />
<br />
==Quality Programs==<br />
<small>(An opportunity to hear about status with the various quality programs that do not have a formal team structure.)</small><br />
<br />
===OrangeFactor (ryanvm)===<br />
<br />
===CritSmash (dbolter)===<br />
<br />
===MemShrink (njn)===<br />
<br />
===Stability (kairo/bsmedberg)===<br />
<br />
==Team Stand-ups==<br />
<small>(In <2 mins, what did your team accomplish last week, on what is your team working on this week, and on what, if anything, is your team blocked? No questions during the stand-ups. All questions should be asked during the roundtable.)</small><br />
<br />
===A*Team (jgriffin)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
{{readonly}}<br />
<br />
Blog and newsgroup posts:<br />
<br />
* [Byron Jones] [http://globau.wordpress.com/2014/09/02/happy-bmo-push-day-111/ bitly support] for search URLs<br />
* [Mark Cote] [https://mrcote.info/blog/2014/09/04/review-board-preview/ Review Board preview]<br />
* [Cameron Dawson] [http://dawsoncode.wordpress.com/2014/09/04/pycharm-on-a-django-app-with-vagrant/ PyCharm debugging the Treeherder service]<br />
* [Chris Manchester] [https://groups.google.com/forum/#!topic/mozilla.dev.platform/ATJMoIDvqFc Structured Logging update]<br />
* [James Graham] [https://groups.google.com/forum/#!topic/mozilla.dev.platform/qexSYp_rEYA web-platform-tests now running in automation]<br />
* [Geoff Brown] [http://gbrownmozilla.wordpress.com/2014/09/02/firefox-for-android-performance-measures-august-check-up-2/ Firefox for Android Performance Measures - August Check-up]<br />
<br />
===Accessibility (dbolter)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===App Tools (prouget)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===B2G Services (dougt)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Cloud Services (mmayo)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Developer Tools (robcee)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===DOM (jst/overholt)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Electrolysis (e10s) (blassey)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
* If you'd like to test e10s in Nightly, flip the "browser.tabs.remote.autostart" pref to true and restart Nightly.<br />
** Known issues likely to affect you: https://etherpad.mozilla.org/e10s-known-issues<br />
<br />
===Firefox Desktop (gavin)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox Mobile (snorp/blassey/mfinkle)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Communications (scravag)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Connectivity (vchang)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Devices/Porting (ericchou)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Media (slee)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Media Apps (hema)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Media Recording(pchang)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Productivity (doliver)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS RIL (htsai)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Systems - Front End (gwagner)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Systems - Platform (timdream)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===GFX (milan)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===JS (naveed)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Layout (jet/dbaron)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Media (mreavy)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Necko (dougt/jduell)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Performance (vladan)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Seceng (ckerschb)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
* New CSP backend (compiled code) is on average 15x faster than old one that we removed in Fx 34.<br />
<br />
===Shumway (tschneidereit)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===WebAPI (overholt)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
==Roundtable==<br />
<small>(Comments and questions that arise during the course of the meeting or otherwise do not have a section.)</small><br />
<br />
==<Read only beyond this point>==<br />
<br />
===Friends of the Tree===<br />
<br />
===Mailing List Threads===<br />
<small>(Threads that are likely to be of interest to engineering from various mailing lists.)</small><br />
<br />
===Good Reads===<br />
<small>(Links to blog posts, books, videos, etc. that you think will be of interest to others.)</small><br />
<br />
===irc #planning Log From This Meeting===<br />
<pre style="white-spaaace:pre-wrap;"><br />
</pre></div>Sidstammhttps://wiki.mozilla.org/index.php?title=Platform/2014-Q3-Goals&diff=1012311Platform/2014-Q3-Goals2014-09-04T17:39:05Z<p>Sidstamm: /* Security & Privacy Engineering */</p>
<hr />
<div>=== Platform ===<br />
==== [[Platform/2014-Goals|2014 General Goals]] ====<br />
<br />
=== GFX ===<br />
Items marked [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AnKFEBp1-VyqdFNfRlZmV0ExM0VvZGMxNThWX0d6LWc&usp=drive_web#gid=0 here] with release 33 and 34 are part of the Q3 landings.<br />
<br />
=== Layout ===<br />
* Layout to Moz2D<br />
** {{ok|Migrate SVG to Moz2D (bug 703159) }}<br />
<br />
* Enable Vertical Text for major use cases for Chinese & Japanese<br />
** {{ok|bug 145503}}<br />
<br />
* Text Performance<br />
** {{ok|{{bug|998869}}}} Streamline parsing of fontlists and improve efficiency of font matching code (note: unicode-range support will fall out of this work)<br />
** {{ok|{{bug|934770}}}} - slow at rendering large blocks of plain text<br />
** {{ok|{{bug|860492}}}} - Divide large text runs into smaller runs to avoid chrome hangs<br />
<br />
* Improve Restyling Performance<br />
** {{ok|bug 977991}}<br />
<br />
* {{ok|Font Inflation and Reflow-on-Zoom }}<br />
** both implementation bug fixing and spec work<br />
** -moz-text-size-adjust <br />
<br />
* ImageLib<br />
** {{ok|RasterImage for multiple images}}<br />
<br />
* CSS Projects with Adobe<br />
** {{ok|CSS Filters}}<br />
<br />
* Animations & Transitions<br />
** {{ok|transitions/animations spec editing}}<br />
** {{ok|transitions refactoring to match new spec (960465)}}<br />
** {{ok|frame reconstruction (625289)}}<br />
<br />
* OMTA on non-B2G Platforms (980770)<br />
** {{ok|fix correctness bugs (cascading, etc.)}}<br />
** {{ok|turning on on other OMTC platforms (Mac/Android)}}<br />
<br />
* Web animations: <br />
** {{ok|TBD}}<br />
<br />
* CSS Scrolling<br />
** {{ok|CSS scroll snapping}}<br />
** {{ok|scroll-behavior:smooth}}<br />
<br />
* CSS Flexbox <br />
** {{ok|performance bugs}}<br />
** {{ok|spec changes}}<br />
<br />
* CSS Ruby <br />
** {{ok|implementation}}<br />
<br />
=== Media ===<br />
* {{miss|Enable YouTube MSE/VP9 for Firefox 33 in Nightly/Aurora {{bug|1000686}}}}<br />
* {{miss|Enable YouTube MSE/MP4 on Windows and Firefox OS for Firefox 34}}<br />
<br />
'''Detailed Breakdown'''<br />
* MSE Common<br />
** {{done|Rate adaption/buffer switching, reseting}}<br />
** {{miss|Seeking into unbuffered ranges {{bug|1056440}}}}<br />
** {{todo|Eviction/pinning}}<br />
* MSE WebM<br />
** {{done|WebM segment parser {{bug|881512}}{{bug|1044498}}}}<br />
* MSE MP4<br />
** {{done|MP4 segment parser {{bug|1027875}}{{bug|1057203}}}}<br />
** MP4 Demuxer<br />
*** {{done|Integrate stagefright MP4 demuxer {{bug|908503}}}}<br />
*** {{done|Accurate range reporting {{bug|1045909}}}}<br />
*** {{done|CENC support {{bug|1022434}}}}<br />
*** {{todo|DASHIF and other players aside from YouTube {{bug|1039149}}}}<br />
** H.264/AAC Decoder<br />
*** {{done|MP4/fMP4 platform decoder module for Mac OSX {{bug|941296}}}}<br />
*** {{miss|MP4 support on Firefox OS {{bug|1060900}}}}<br />
**** {{done|MP4 platform decoder module for Firefox OS {{bug|941302}}}}<br />
**** {{miss|Use a single shared decoder for MSE on b2g {{bug|1036849}}}}<br />
<br />
=== DOM ===<br />
* {{done|Mirror prototype of DOM objects through xray wrappers (peterv)}}<br />
* {{risk|Remove nsDOMClassInfo.cpp}}<br />
** Given the recent focus on e10s, we may not get through all of this work this quarter.<br />
* {{done|Make less-privileged non-Xrayable unwaived opaque from privileged code (bholley, {{bug|856067}})}}<br />
* {{done|Route all JSContext pushing through AutoJSAPI and Implement GetEntryGlobal (bobowen, bholley, {{bug|951991}})}}<br />
* {{ok|Land <picture> preffed on on nightly ({{bug|1017875}}) (johns)}}<br />
* {{done|audit callsites of IsInDoc()/GetCurrentDoc to ensure correct Shadow DOM behaviour and fix Shadow DOM blockers for Gaia (smaug, wchen) ({{bug|1026047}})}}<br />
* {{ok|land Service Workers preffed on on nightly (nsm, bkelly, baku) ({{bug|903441}})}}<br />
** This is progressing well, but won't be *done* until the end of the quarter, so still on track.<br />
<br />
=== WebAPI ===<br />
* {{ok|create design plan for "share" activity (flow, what kind of objects are involved) (annevk)}}<br />
* {{ok|document existing activities usage in gaia (ehsan)}}<br />
* {{ok|get [https://w3c.github.io/screen-orientation/ screen orientation spec] to LC (marcosc)}}<br />
* {{done|publish [http://www.w3.org/TR/wake-lock-use-cases/ use cases for wake locks] (marcosc)}}<br />
* {{ok|publish spec for [http://w3c.github.io/wake-lock/ "wakelock" API] (marcosc)}}<br />
* {{done|24/12 hour format API (ehsan) {{bug|903683}}}}<br />
* {{ok|{{bug|942542}} new quota API on PBackground for Service Worker cache (janv)}}<br />
* {{ok|{{bug|701634}} IndexedDB in workers (bent)}}<br />
<br />
=== JS ===<br />
* {{jok|837314}} ES6 classes<br />
* {{jok|1020751}} Generational GC on Firefox OS<br />
* {{jok|650161}} Compacting GC to reduce memory usage<br />
* {{jok|856533}} Escape analysis JIT optimizations<br />
* {{jok|998392}} Use Latin1 strings to reduce memory usage<br />
* {{jok|903519}} Allocate strings in GC nursery (for performance)<br />
* {{jok|972710}} ARM64 JIT ''[stretch goal]''<br />
<br />
=== Accessibility ===<br />
* {{ok|}}e10s: proxy the common a11y API stuff like name, role, and states.<br />
* {{ok|}}GAIA: Fix [https://bugzilla.mozilla.org/buglist.cgi?priority=--&f1=blocked&list_id=10674217&o1=anyexact&resolution=---&query_based_on=b2ga11y%20p%3D1&o2=substring&query_format=advanced&f2=status_whiteboard&v1=893789&component=Disability%20Access%20APIs&component=Gaia&component=Gaia%3A%3ABluetooth%20File%20Transfer&component=Gaia%3A%3ABrowser&component=Gaia%3A%3ABuild&component=Gaia%3A%3ACalendar&component=Gaia%3A%3ACamera&component=Gaia%3A%3AClock&component=Gaia%3A%3AContacts&component=Gaia%3A%3ACost%20Control&component=Gaia%3A%3ADialer&component=Gaia%3A%3AE-Mail&component=Gaia%3A%3AEverything.me&component=Gaia%3A%3AFirst%20Time%20Experience&component=Gaia%3A%3AFMRadio&component=Gaia%3A%3AGallery&component=Gaia%3A%3AGithubBot&component=Gaia%3A%3AHomescreen&component=Gaia%3A%3AKeyboard&component=Gaia%3A%3AL10n&component=Gaia%3A%3ALoop&component=Gaia%3A%3AMusic&component=Gaia%3A%3ANotes&component=Gaia%3A%3APDF%20Viewer&component=Gaia%3A%3APerformanceTest&component=Gaia%3A%3ARingtones&component=Gaia%3A%3ASearch&component=Gaia%3A%3ASettings&component=Gaia%3A%3ASMS&component=Gaia%3A%3ASystem&component=Gaia%3A%3ASystem%3A%3ABrowser%20Chrome&component=Gaia%3A%3ASystem%3A%3AInput%20Mgmt&component=Gaia%3A%3ASystem%3A%3ALockscreen&component=Gaia%3A%3ASystem%3A%3AWindow%20Mgmt&component=Gaia%3A%3ATestAgent&component=Gaia%3A%3AUI%20Tests&component=Gaia%3A%3AVideo&component=Gaia%3A%3AWallpaper&component=Gaia%3A%3AWappush&v2=b2ga11y%20p%3D1&product=Core&product=Firefox%20OS all Gaia P1 a11y bugs] (~30 at this time).<br />
* {{done|}}FFOS: {{Bug|1030465}} - Volume change should update the screen reader volume.<br />
* {{done|}}FFOS: {{Bug|1030466}} - Headphones screen reader volume is too low.<br />
* {{done|}}FFOS: {{Bug|1030468}} - VC rectangle needs to work with scaled content.<br />
* {{done|}}FFOS: {{Bug|1030470}} - Localization needs to work when switching locales in FxOS.<br />
<br />
=== Perf ===<br />
<br />
Fix major source of browser jank:<br />
<br />
* {{ok|Initialize plugin instances asynchronously {{bug|998863}} }}<br />
* {{ok|Pause heavy main-thread activities while user is interacting with the browser: }}<br />
** {{ok|Determine when a user is actively interacting with the browser}}<br />
** {{ok|Detect when jank occurs during interactions and report to Telemetry {{bug|1017055}} }}<br />
** {{ok|Experiment with hinting to GC & CC that they should pause while the user is interacting with the browser}}<br />
* {{ok|Help Frontend team with Places refactoring, eliminate some of the [http://telemetry.mozilla.org/slowsql/ Places main-thread SQL] reported to Telemetry }}<br />
* {{ok|Don't store UI customization in localstore.rdf, use off-main thread JSON instead {{bug|559505}} }}<br />
<br />
Improve Firefox startup (identified as a top issue in user research):<br />
<br />
* {{ok|Reduce appearance of the "profile is in use" message on startup {{bug|286355}} }}<br />
* {{ok|Restore windows one by one during session-restore {{bug|1034534}} and/or load windows by descending z-order {{bug|1034036}} }}<br />
* {{ok|C++ version of AsyncShutdown {{bug|918317}} }}<br />
<br />
Prevent performance regressions:<br />
<br />
* {{ok|Implement automatic detection & alerting for Telemetry regressions {{bug|1031032}} }}<br />
* {{ok|Help developers understand & diagnose Talos regressions}}, e.g. [https://bugzilla.mozilla.org/show_bug.cgi?id=1026550 Firefox 33 regression tracking], [https://bugzilla.mozilla.org/show_bug.cgi?id=1004427 Firefox 32 regressions], [https://bugzilla.mozilla.org/show_bug.cgi?id=990085 Firefox 31]<br />
<br />
Grow community:<br />
<br />
* {{ok|Mentor at least 5 external contributors}}<br />
<br />
=== Networking ===<br />
<br />
* {{ok|Ship Network Predictor ("Seer") on nightly, using HTTP cache instead of SQLite ({{bug|1009122}}) (hurley)}}<br />
* {{ok|Ship current (hopefully final) IETF version of HTTP/2 preffed on in nightly (hurley)}}<br />
* {{ok|HTTP/2 "alt-svc" support ({{bug|1003448}}) (mcmanus)}}<br />
* {{ok|HTTP cache: determine if revalidation is needed w/o doing I/O ({{bug|983122}}) (sworkman) }}<br />
* {{ok|Network up/down link detection on all platforms ({{bug|939318}}) (bagder) }}<br />
* {{ok|Implement WebSocket compression extension ({{bug|792831}}) (michal) }}<br />
<br />
=== Mobile ===<br />
<br />
=== A*Team ===<br />
<br />
For full list, see [[Auto-tools/Goals/2014Q3|A-Team Goals 2014Q3]]<br />
<br />
'''B2G'''<br />
* {{ok|}} Run a set of performance and correctness tests per-commit to b2g-inbound on Flame devices<br />
* {{ok|}} Get gaia-integration tests running on device<br />
* {{ok|}} Expand the FxOS Certification Suite with 1.4 support, test automation to prevent regressions, and investigation of support for non-phone devices<br />
* {{ok|}} Green up B2G tests on TaskCluster (joint with RelEng)<br />
<br />
'''Developer Productivity'''<br />
* {{ok|}} Deploy ReviewBoard for developers to start using (joint with RelEng)<br />
<br />
'''Performance'''<br />
* {{ok|}} Deploy new Talos tests for tp5o_scroll, webgl, webrtc, and mainthread I/O<br />
* {{ok|}} Get Datazilla alerts to beta mode (full parity with graph server alerts) with reduced noise<br />
* {{ok|}} Get Eideticker running against Android again with increased frequency<br />
* {{ok|}} Run B2G Eideticker against same branch/build combinations as our other on-device perf tests<br />
* {{ok|}} Stand up a Games Benchmarking system for webaudio tests running against Firefox and Chrome<br />
<br />
'''Treeherder'''<br />
* {{ok|}} Deliver performance web service for ingesting and returning performance data <br />
* {{ok|}} Deliver a UI for viewing Talos data<br />
<br />
'''Sheriffing'''<br />
* {{ok|}} Fully transition sheriffing from TBPL to Treeherder<br />
<br />
'''General Automation'''<br />
* {{ok|}} Create weekly reports that describe how many tests have been added/disabled/enabled per suite and platform<br />
* {{ok|}} Move reftest to mozbase<br />
* {{ok|}} Add command executors for Marionette for Java and Python<br />
<br />
'''Bugzilla'''<br />
* {{done|}} Improve load time of related bugs; can decrease show_bug load times by up to 12%<br />
* {{ok|}} Minify and concatenate JS files<br />
* {{ok|}} Authoritative view for review history<br />
* {{ok|}} Rewrite docs for REST API<br />
<br />
'''Community'''<br />
* {{ok|}} Create good_next_bugs (name can be adjusted) so once contributors are comfortable they can do more serious coding/problem solving on a project they are familiar with<br />
* {{ok|}} Monthly review of mentored bugs and projects<br />
<br />
=== Web Engineering ===<br />
'''Crash stats'''<br />
* {{ok|}} Prototype service for identifying post-crash user actions<br />
* {{done|}} Hardware and performance tuning for new primary data store<br />
* {{ok|}} Remove older, redundant crash storage format from database<br />
* {{drop|}} Improve search performance and features<br />
* {{done|}} Replace interfaces to deprecated external data sources<br />
* {{ok|}} Remove barriers to community installations<br />
'''FHR'''<br />
* {{ok|}} Support search diversion plan<br />
'''DXR'''<br />
* {{ok|}} Improve infrastructure.<br />
** For example, switch to ES backend, which will enable us to build multi-language support and parallel tree indexing.<br />
* {{ok|}} Broaden our audience.<br />
** Pull users away from MXR so we can shut it off. For example, add support for Rust or JS, squash MXR migration blockers.<br />
'''l10n'''<br />
* {{ok|}} Get l10n build logs into a searchable data store<br />
* {{ok|}} Replace some buildbot functionality with a10n automation<br />
'''Air Mozilla'''<br />
* {{ok|}} Prototype support for streaming media boxes<br />
* {{done|}} Improve desktop user experience<br />
<br />
[https://etherpad.mozilla.org/webeng-q32014 full list]<br />
<br />
=== SUMO and Input ===<br />
* {{done|}} SUMO: Launch new offline SUMO app [Get Firefox on a Growth Trajectory]<br />
* {{ok|}} SUMO: Develop new Community Hub to a level where it can replace legacy Karma app [Enable Communities with Impact]<br />
* {{ok|}} SUMO: Research and prototype new experimental features (e.g. geotargeting, Instant Search, Search Suggestions) [Get Firefox on a Growth Trajectory]<br />
<br />
* {{done|}} Input: Improve documentation and install to lower the bar for contribution [Enable Communities with Impact]<br />
* {{ok|}} Input: Support Heartbeat [Get Firefox on a Growth Trajectory]<br />
* {{ok|}} Input: Dashboards for Everyone [Get Firefox on a Growth Trajectory]<br />
<br />
=== Release Engineering - Laura ===<br />
* {{drop|}} Enable capacity expansion for bare-metal releng OS X build and test slaves via hardware provided by third-party datacenters (Get Firefox on a Trajectory of Growth)<br />
* {{ok|}} Simplify release engineering mobile hardware infrastructure (Get Firefox on a Trajectory of Growth)<br />
* {{ok|}} Automate developer access to continuous integration resources to expedite debugging and standing up new job variants. (Enable Communities With Impact)<br />
* {{ok|}} Help enable video operability on the web by providing continuous integration for Cisco Open H.264 builds. (Get Firefox on a Trajectory of Growth)<br />
<br />
=== Release Engineering - Taras ===<br />
* {{ok|}} Replace aging Firefox update service with a scalable, modern solution. (Get Firefox on a Trajectory of Growth)<br />
* {{ok|}} Simplify developer workflow by automating patch landing and uplift. (Enable Communities With Impact)<br />
* {{ok|}} Optimize network transfers for build/test automation between datacenters. (Enable Communities With Impact)<br />
* {{ok|}} Continue AWS cost optimizations: EBS < 3% of AWS bill(vs 30% in Q2) (Enable Communities With Impact)<br />
* {{ok|}} Improve developer workflow by migrating 80% of FirefoxOS build/test jobs to taskcluster (Enable Communities With Impact)<br />
* {{ok|}} Turn telemetry is into a general purpose s3 ingester and analysis tool<br />
<br />
=== Release Engineering Operations ===<br />
* Build/Test System Performance Enhancements<br />
** {{drop| Unify releng platform architecture, using common tools and best practices, to decrease complexity and enable smoother developer engagement {{bug|1026110}} [Get Firefox on a Trajectory of Growth, Enable Communities With Impact] - blocked on obtaining necessary resources from other groups }}<br />
** {{ok| Improve communication and response time for releng network flow requests {{bug|1026112}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] }}<br />
** {{ok| Improve security for all releng windows infrastructure {{bug|893716}} [Get Firefox on a Trajectory of Growth] }}<br />
** {{done| Update windows platform developer tools {{bug|1019165}} [Get Firefox on a Trajectory of Growth] }}<br />
* Build/Test System Self-Serve Re-architecture<br />
** {{prev| Design a private cloud deployment architecture for bare metal and produce a POC that supports Ubuntu 12.04 test machines. {{bug|963165}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] }}<br />
** {{drop| Create self-service capability for releng hardware Firefox linux test slaves (build slaves as a stretch goal) {{bug|1026687}} (depends on completion of previous goal) [Get Firefox on a Trajectory of Growth, Scale Firefox OS] - bare metal openstack is proving to be too bleeding edge and buggy to use for production services. We will continue to work on R&D for this project and track changes made in the openstack code base, but we will not move any services to production in FY2014 }}<br />
** {{drop| Create self-service capability for releng hardware Firefox windows test slaves. {{bug|967064}} [Get Firefox on a Growth Trajectory] - Still pending completion of re-prioritized 2008R2 work }}<br />
<br />
=== Developer Services ===<br />
* {{done|(with B-team) roll out phase 2 of new review tooling}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
* {{new|Upgrade existing Mercurial infrastructure to support more rapid, safe, and coordinated deployment of updates.}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
<br />
[https://etherpad.mozilla.org/devservices-Q32014 Full List]<br />
<br />
=== Security & Privacy Engineering ===<br />
More details here: [[SecurityEngineering/2014/Q3Goals]]<br />
<br />
'''Content Security'''<br />
* {{ok|Gecko Security Hooks: Finish code and debugging for New Channel API, start getting reviews}} (dri=tanvi)<br />
* {{hold|Gecko Security Hooks: Create plan for addon compatibility -- doesn't make sense until New Channel API is done}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central}} (dri=sstamm)<br />
* {{ok|Evangelism: Security Open Mic presentation + blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs}} (dri=ckerschb)<br />
<br />
'''Tracking Protection'''<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help}} (dri=sstamm)<br />
* {{done|Land first implementation of protection in Fx 33/34 off by default. BONUS: landed frontend code too}} (dri=mmc)<br />
<br />
'''Communications Security'''<br />
* {{ok|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok| HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{done| Update [[CA:RevocationPlan|roadmap for Cert Revocation improvements]]}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{ok| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{ok| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{ok| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)<br />
* {{done| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
<br />
=== Firefox and Platform Security ===<br />
<br />
* [https://mana.mozilla.org/wiki/display/~gkwong@mozilla.com/Marifuzz Marifuzz ] fuzzer ported to and running on Flame devices.<br />
* Update ASan and LSan work for DOMFuzzer<br />
* Update "Bounty Stars" document with issues found by external reporters and updating DOMFuzzer to reflect these results.<br />
* Get Clang on RelEng ready for official OS X ASan builds.<br />
* Initial work to move CoreFuzz towards running in cloud environments.<br />
* WebCrypto API fuzzing using Dharma fuzzer. <br />
* Port a portion of WebRTC fuzzing from Frambois fuzzer to Dharma fuzzer.<br />
* Peach: Improving and porting Peach 2 to Python 3.<br />
* Public Mozilla Security Github work: Moving of fuzzing tools from Fuzzing Hg to GitHub, including work to separate harnesses from testcase generation tools.<br />
<br />
=== Games Program ===<br />
*Reach out to 3rd party engines en masse (also for Q4)<br />
*Select a 3D demo for mobile<br />
*Pick a partner demo to optimize for mobile<br />
*Focus on supporting shipping games and maintaining platform stability <br />
*Focus on Shared Array Buffer implementation<br />
*WebGL Benchmarks<br />
*Continue to work MDN documentation; get Emscripten documentation started<br />
*GDC and MWC event support plan<br />
<br />
=== Release Management ===<br />
For full list, see [[Release_Management/Goals/2014Q3#Release_Management_General|Release Management 2014Q3 Goals]].<br />
* Create and document process for Desktop/Mobile feature fast tracking<br />
* Determine future of ESR and how to manage this channel<br />
* Continue desktop throttling experiment with intention of reducing throttled time while maintaining existing level of feedback<br />
* Improve release notes with revamped template for all products<br />
* Create B2G release model proposals and gather feedback for potential changes<br />
* Figure out what to do with B2G Security Releases<br />
<br />
===Program Management===<br />
<br />
See this wiki page for a full list of [https://wiki.mozilla.org/Program_Management/Firefox/2014-Q3-Goals Program Management goals].<br />
<br />
* {{ok|Create a set of dashboards based on the ES database to track platform projects and surface bottlenecks.}}<br />
** Narrowed focus to a set of dashboards for review queues for individuals and teams. <br />
* {{risk|Brown bag presentation/restropective on the agile processes we are using on Desktop and FirefoxOS}}<br />
** With the reorg, revisiting the purpose/target. Might change this goal slightly. Still probably worthwhile planning a brown bag to talk about Desktop process and introduce Trello planning tool for Platform.<br />
* {{ok|Evaluate and produce a report on several tools for helping organize and visualize team backlogs and priority lists; wiki, spreadsheets, Trello, Kanbanize}}<br />
** Using a Trello board for Platform work. Jenn piloting Kanban board for Desktop/Android. Should have a summary, write-up ready by end of Sept.<br />
<br />
=== Quality Engineering ===<br />
See this wiki for the full list of [https://wiki.mozilla.org/QA/Goals/2014q3 Quality goals]. What follows are our brief summary of our internal improvement goals for each strategic team.<br />
* Firefox QA - Revitalize our Quality Engineering strategy by switching to a feature-based test strategy for all Firefox browser products so that there are test plans for each feature and testing is executed within two sprints of the feature's code landing<br />
* Firefox OS - Better metrics for quality analysis, provide opportunities for community contribution, and expanding the role of our on-device automation for reporting to Treeherder.<br />
* Services - Ensure new offerings have 98% uptime (FxA Sync, OAuth, FMD, Loop) and no more than 2 P1 bugs discovered post launch while building a core contributor base in services<br />
* Marketplace - Ensure Marketplace's new payments backend, in-app payments, and the Marketplace feed land with high quality releases.<br />
* Platform QA - Deploy into continuous integration a regression testing system for WebRTC along three areas of investigation: 1. "Smoke" tests, 2. Connection tests, and 3. Connection quality tests. These will be performed in a variety of environments, including various network topologies with various performance characteristics, connections between various versions of Firefox, and connections on multiple OS platforms. Test plans will be developed, and we will measure coverage of test plans. Results will be posted and available in Treeherder. We will also build backlog for next Platform Tiger Team tasks.<br />
* Community - Increase conversion of interested and casual contributors to help them become active contributors with strong ties to the QA community</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q3Goals&diff=1008967SecurityEngineering/2014/Q3Goals2014-08-25T17:01:46Z<p>Sidstamm: /* Tracking Protection */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
(Also linked from [[Platform/2014-Q3-Goals#Security_.26_Privacy_Engineering]]).<br />
<br />
== Content Security ==<br />
;Outcome: Progress towards more robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid<br />
<br />
* {{ok|Gecko Security Hooks: Finish code and debugging for New Channel API, start getting reviews.}} See {{bug|1038756}}, {{bug|1006881}} (dri=tanvi)<br />
* {{hold|Gecko Security Hooks: Create plan for addon compatibility}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central. Target Fx34.}} See {{bug|994782}} (dri=sstamm)<br />
* {{new|Evangelism: Security Open Mic presentation + blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs.}} See [https://etherpad.mozilla.org/CSP-1-1 planning etherpad] (dri=ckerschb)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Monica, Garrett, Sid, Georgios<br />
<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help.}} See {{bug|704320}}. (dri=sstamm)<br />
* {{done|Land backend and bridge code for first implementation of protection in Fx 33/34 off by default. BONUS: landed frontend code too}} (dri=mmc)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks.<br />
;Who: Richard, Kathleen, Keeler, Camilo, Harsh, Garrett, Monica<br />
<br />
* {{ok|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok|HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{ok| Update roadmap for Cert Revocation improvements}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{ok| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{ok| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{risk| ''[stretch goal]'' Enable revocation of intermediate CAs through block list service}} (dri=harsh, keeler)<br />
* {{ok| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
* {{ok| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q3Goals&diff=1008965SecurityEngineering/2014/Q3Goals2014-08-25T17:00:48Z<p>Sidstamm: /* Content Security */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
(Also linked from [[Platform/2014-Q3-Goals#Security_.26_Privacy_Engineering]]).<br />
<br />
== Content Security ==<br />
;Outcome: Progress towards more robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid<br />
<br />
* {{ok|Gecko Security Hooks: Finish code and debugging for New Channel API, start getting reviews.}} See {{bug|1038756}}, {{bug|1006881}} (dri=tanvi)<br />
* {{hold|Gecko Security Hooks: Create plan for addon compatibility}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central. Target Fx34.}} See {{bug|994782}} (dri=sstamm)<br />
* {{new|Evangelism: Security Open Mic presentation + blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs.}} See [https://etherpad.mozilla.org/CSP-1-1 planning etherpad] (dri=ckerschb)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Monica, Garrett, Sid, Georgios<br />
<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help}} (dri=sstamm)<br />
* {{done|Land backend and bridge code for first implementation of protection in Fx 33/34 off by default.}} (dri=mmc)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks.<br />
;Who: Richard, Kathleen, Keeler, Camilo, Harsh, Garrett, Monica<br />
<br />
* {{ok|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok|HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{ok| Update roadmap for Cert Revocation improvements}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{ok| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{ok| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{risk| ''[stretch goal]'' Enable revocation of intermediate CAs through block list service}} (dri=harsh, keeler)<br />
* {{ok| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
* {{ok| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=Modules/Core&diff=1008541Modules/Core2014-08-22T17:59:33Z<p>Sidstamm: </p>
<hr />
<div><noinclude><br />
'''Do not edit this page''' unless either:<br />
<br />
# you are a module owner who is:<br />
#* altering the list of peers in your module<br />
#* adding or removing a sub-module<br />
#* changing the owner of one of your sub-modules; or<br />
# you have agreed a change of owner or module addition/deletion with the Module Ownership Module group, probably via [https://www.mozilla.org/about/forums/#governance mozilla.governance].<br />
</noinclude><br />
{{Module<br />
|name=Accessibility<br />
|description=Support for platform accessibility APIs. Accessibility APIs are used by 3rd party software like screen readers, screen magnifiers, and voice dictation software, which need information about document content and UI controls, as well as important events like changes of focus.<br />
|owner=[mailto:surkov.alexander@gmail.com Alexander Surkov]<br />
|peers=[mailto:bolterbugz@gmail.com David Bolter], [mailto:ginn.chen@oracle.com Ginn Chen], [mailto:trev.saunders@gmail.com Trevor Saunders], [mailto:marco.zehe@googlemail.com Marco Zehe] <br />
|group=dev-accessibility<br />
|source_dirs=accessible/<br />
|url=http://www.mozilla.org/access/<br />
|components=Core::Disability Access APIs<br />
}}<br />
<br />
{{Module<br />
|name=Browser WebAPI<br />
|description=Web API for rendering apps, browser windows and widgets.<br />
|owner=[mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|peers=[mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:fabrice@mozilla.com Fabrice Desré]<br />
|group=dev-webapi<br />
|source_dirs=dom/browser-element/<br />
|url=<br />
|components=Core::DOM<br />
}}<br />
<br />
{{Module<br />
|name=Build and Release Tools<br />
|description=Tools related to build and release automation and configuration of release builds.<br />
|owner=[mailto:nrthomas@gmail.com Nick Thomas]<br />
|peers=[mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:cmp@mozilla.org Chase Phillips], [mailto:mozpreed@sigkill.com John Paul Reed], [mailto:robert@roberthelmer.com Robert Helmer]<br />
|group=dev-builds<br />
|source_dirs=tools/botrunner.py, tools/build-environment/, tools/build/, tools/buildbot-configs/, tools/buildbot/, tools/buildbotcustom/, tools/l10n/, tools/MozBuild/, tools/patcher-configs/, tools/patcher/, tools/release/, tools/tinderbox-configs/, tools/tinderbox/, tools/update-packaging/, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=<br />
|components=mozilla.org::Release Engineering, mozilla.org::Release Engineering: Custom Builds<br />
}}<br />
<br />
{{Module<br />
|name=Build Config<br />
|description=The build system for Gecko and several mozilla.org hosted Gecko-based applications.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc] (:gps)<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg] (:bsmedberg), [mailto:mh@glandium.org Mike Hommey] (:glandium), [mailto:ted@mielczarek.org Ted Mielczarek] (:ted), [mailto:mshal@mozilla.com Mike Shal] (:mshal), [mailto:me@kylehuey.com Kyle Huey] (:khuey) (less active - send reviews to others)<br />
|group=dev-builds<br />
|source_dirs=build/, config/, python/mozbuild, tools/cross-commit, tools/cvs2hg-import.py, tools/cvsmgmt/, tools/elf-dynstr-gc/, tools/trees.pl, browser/config/mozconfigs/, mobile/config/mozconfigs/, xulrunner/config/mozconfigs/<br />
|url=http://www.mozilla.org/build/<br />
|components=Core::Build Config<br />
}}<br />
<br />
{{Module<br />
|name=Code Analysis and Debugging Tools<br />
|description=Tools for debugging Mozilla code or for analyzing speed, memory use, and other characteristics of it.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=<br />
|group=dev-performance<br />
|source_dirs=tools/codesighs/, tools/debug/, tools/dreftool/, tools/dumpdeps/, tools/footprint/, tools/jprof/, tools/leaky/, tools/memory/, tools/module-deps/, tools/performance/, tools/post_compile/, tools/preloader/, tools/rb/, tools/reorder/, tools/trace-malloc/, tools/uuiddeps/, <br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Content HTTP Headers<br />
|description=HTTP headers related to content, e.g. User-Agent, Content-Type, Accept. (Transport-related headers are the responsibility of the Necko module owner.)<br />
|owner=[mailto:gerv@mozilla.org Gervase Markham]<br />
|peers=[mailto:lmandel@mozilla.com Lawrence Mandel]<br />
|group=dev-platform<br />
|source_dirs= <br />
|url=https://developer.mozilla.org/en/Gecko_user_agent_string_reference<br />
|components=Core::Networking: HTTP<br />
}}<br />
<br />
{{Module<br />
|name=Content Security<br />
|description=Native content-based security features, including: Content Security Policy (CSP), Mixed Content Blocker (MCB), and Safe Browsing.<br />
|owner=[mailto:sstamm@mozilla.com Sid Stamm], [mailto:gpascutto@mozilla.com Gian-Carlo Pascutto]<br />
|peers=[mailto:grobinson@mozilla.com Garrett Robinson], [mailto:tvyas@mozilla.com Tanvi Vyas], [mailto:dveditz@mozilla.com Dan Veditz], [mailto:ckerschbaumer@mozilla.com Christoph Kerschbaumer]<br />
|group=dev-security<br />
|source_dirs=dom/security (needs to be created)<br />
|components=Core::DOM: Security<br />
}}<br />
<br />
{{Module<br />
|name=Cookies and Permissions<br />
|description=<br />
|owner=[mailto:mchew@mozilla.com Monica Chew]<br />
|peers=[mailto:josh@joshmatthews.com Josh Matthews], [mailto:ehsan@mozilla.com Ehsan Akhgari], [mailto:mconnor@steelgryphon.com Mike Connor], [mailto:dwitte@gmail.com Dan Witte], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:sdwilsh@shawnwilsher.com Shawn Wilsher (ping on irc)]<br />
|group=dev-tech-network<br />
|source_dirs=extensions/cookie/, netwerk/cookie/<br />
|url=<br />
|components=Core::Networking: Cookies<br />
}}<br />
{{Module<br />
|name=Cycle Collector<br />
|description=Code to break and collect objects within reference cycles<br />
|owner=[mailto:continuation@gmail.com Andrew McCreight]<br />
|peers=Peter Van der Beken, Olli Pettay, David Baron<br />
|source_dirs=xpcom/base/nsCycleCollector.* and some support headers<br />
|components=Core::XPCOM<br />
|group=dev-platform<br />
}}<br />
{{Module<br />
|name=docshell<br />
|description=<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger],[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jst@mozilla.org Johnny Stenback], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=dev-tech-layout<br />
|source_dirs=docshell/, uriloader/, webshell/<br />
|url=<br />
|components=Core::Document Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Device Storage<br />
|description=Support for the device storage API<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands], [mailto:jvarga@mozilla.com Jan Varga]<br />
|peers=[mailto:dougt@dougt.org Doug Turner]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/devicestorage/, dom/interfaces/devicestorage/<br />
|url=https://developer.mozilla.org/en-US/docs/WebAPI/Device_Storage<br />
|components=Core::DOM: Device Interfaces<br />
}}<br />
<br />
{{Module<br />
|name=Document Object Model<br />
|description=<br />
|owner=[mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:Olli.Pettay@helsinki.fi Olli Pettay], [mailto:bent@mozilla.com Ben Turner], [mailto:mounir.lamouri@mozilla.com Mounir Lamouri], [mailto:me@kylehuey.com Kyle Huey], [mailto:justin.lebar@gmail.com Justin Lebar], [mailto:hsivonen@iki.fi Henri Sivonen], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:baku@mozilla.com Andrea Marchesini]<br />
|group=dev-tech-dom<br />
|source_dirs=content/*, dom/*, except directories covered by other modules<br />
|url=http://developer.mozilla.org/en/docs/DOM<br />
|components=Core::DOM, Core::DOM: CSS Object Model, Core::DOM: Core & HTML, Core::DOM: Events<br />
}}<br />
<br />
{{Module<br />
|name=Web Workers<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:mrbkap@mozilla.com Blake Kaplan], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey]<br />
|group=dev-platform<br />
|source_dirs=dom/workers/<br />
|url=https://developer.mozilla.org/En/Using_web_workers<br />
|components=Core::DOM: Workers<br />
}}<br />
<br />
{{Module<br />
|name=IndexedDB<br />
|description=<br />
|owner=[mailto:bent@mozilla.com Ben Turner]<br />
|peers=[mailto:jonas@sicking.cc Jonas Sicking], [mailto:me@kylehuey.com Kyle Huey], [mailto:jvarga@mozilla.com Jan Varga]<br />
|group=dev-platform<br />
|source_dirs=dom/indexedDB/<br />
|url=https://developer.mozilla.org/en/IndexedDB<br />
|components=Core::DOM: IndexedDB<br />
}}<br />
<br />
{{Module<br />
|name=Editor<br />
|description=<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=<br />
|group=dev-platform<br />
|source_dirs=editor/<br />
|url=http://www.mozilla.org/editor/<br />
|components=Core::Editor<br />
}}<br />
<br />
{{Module<br />
|name=Embedding<br />
|description=<br />
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-embedding<br />
|source_dirs=embedding/<br />
|url=<br />
|components=Core::Embedding: APIs, Core::Embedding: ActiveX Wrapper, Core::Embedding: GRE Core, Core::Embedding: GTK Widget, Core::Embedding: MFC Embed, Core::Embedding: Mac, Core::Embedding: Packaging<br />
}}<br />
<br />
{{Module<br />
|name=Find As You Type<br />
|description=Find As You Type (formerly called Type Ahead Find) is a feature that allows quick web page navigation when you type a succession of characters in the body of the displayed page (not in an edit box of or drop down list). Currently seeks new owner.<br />
|owner=<br />
|peers=<br />
|group=dev-accessibility<br />
|source_dirs=extensions/typeaheadfind/<br />
|url=http://www.mozilla.org/access/type-ahead/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Geolocation<br />
|description=Implementation of the Geolocation W3C Spec, location provider apis, and wifi scanning code.<br />
|owner=[mailto:dougt@dougt.org Doug Turner]<br />
|peers=[mailto:josh@joshmatthews.net Josh Matthews], [mailto:kchen@mozilla.com Kan-Ru Chen]<br />
|group=dev-tech-dom<br />
|source_dirs=dom/src/geolocation, dom/system/, netwerk/wifi<br />
|url=https://developer.mozilla.org/En/Using_geolocation<br />
|components=Core::Geolocation<br />
}}<br />
<br />
{{Module<br />
|name=Global Key Bindings<br />
|description=Global hot keys in Mozilla for the browser, editor, mail-news and widgets. Does not include underlined menu accelerators and the like, as those are part of i18n.<br />
|owner=[mailto:aaronleventhal@moonset.net Aaron Leventhal]<br />
|peers=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|group=dev-accessibility<br />
|source_dirs=content/xbl/builtin/<br />
|url=http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html<br />
|components=Core::Keyboard: Navigation<br />
}}<br />
<br />
{{Module<br />
|name=Graphics<br />
|description=Mozilla graphics API<br />
|owner=[mailto:jrmuizel@mozilla.com Jeff Muizelaar](Thebes, QCMS, YCbCr, Cairo/Pixman, Regions, OS X, Other), [mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:jdrew@mozilla.com Joe Drew], [mailto:vladimir@pobox.com Vladimir Vukicevic], [mailto:bas.schouten@live.nl Bas Schouten](Layers, Windows), [mailto:bjacob@mozilla.com Benoit Jacob](gfx/gl), [mailto:bgirard@mozilla.com Benoit Girard](Compositor, Performance), [mailto:ajuma.bugzilla@alijuma.com Ali Juma], [mailto:jgilbert@mozilla.com Jeff Gilbert](WebGL, ANGLE), [mailto:george@mozilla.com George Wright](Canvas2D, Skia), [mailto:mwoodrow@mozilla.com Matt Woodrow](Layers API), [mailto:jdaggett@mozilla.com John Daggett](text/fonts), [mailto:jfkthame@googlemail.com Jonathan Kew](text/fonts), [mailto:nsilva@mozilla.com Nicolas Silva](MozSurface), [mailto:ncameron@mozilla.com Nick Cameron], [mailto:sikeda@mozilla.com Sotaro Ikeda](B2G), [mailto:snorp@mozilla.com James Willcox](Android), [mailto:clord@mozilla.com Christopher Lord]<br />
|group=dev-platform<br />
|source_dirs=gfx/, content/canvas/src/<br />
|url=https://wiki.mozilla.org/Platform/GFX https://wiki.mozilla.org/Gecko:Layers https://wiki.mozilla.org/Gecko:2DGraphicsSketch<br />
|components=Core::Graphics, Core::Graphics: Layers, Core::Graphics: Text, Core::GFX: Color Management, Core::Canvas: 2D, Core::Canvas: WebGL<br />
}}<br />
<br />
{{Module<br />
|name=APZ (Graphics submodule)<br />
|description=Asynchronous panning and zooming<br />
|owner=[mailto:kgupta@mozilla.com Kartikaya Gupta]<br />
|peers=[mailto:bballo@mozilla.com Botond Ballo], [mailto:tnikkel@mozilla.com Timothy Nikkel], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:clord@mozilla.com Christopher Lord]<br />
|group=dev-platform<br />
|source=gfx/layers/apz<br />
|url=https://wiki.mozilla.org/Platform/GFX/APZ<br />
|components=Core::Panning and Zooming<br />
}}<br />
<br />
{{Module<br />
|name=Moz2D (Graphics submodule)<br />
|description=Platform independent 2D graphics API<br />
|owner=[mailto:bschouten@mozilla.com Bas Schouten]<br />
|peers=[mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:gwright@mozilla.com George Wright], [mailto:jwatt@mozilla.com Jonathan Watt]<br />
|group=dev-platform<br />
|source=gfx/2d<br />
|url=https://wiki.mozilla.org/Platform/GFX/Moz2D<br />
|components=Core::Graphics<br />
}}<br />
<br />
<br />
{{Module<br />
|name=GTK Embedding Widget<br />
|description=Gtk Widget for embedding Mozilla into Gtk applications<br />
|owner=[mailto:marco@gnome.org Marco Pesenti Gritti]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:dougt@meer.net Doug Turner]<br />
|group=dev-embedding<br />
|source_dirs=<br />
|url=<br />
|components=Core::Embedding: GTK Widget<br />
}}<br />
<br />
{{Module<br />
|name=Legacy HTML Parser<br />
|description=<br />
|owner=[mailto:mrbkap@gmail.com Blake Kaplan]<br />
|peers=[mailto:dbaron@dbaron.org David Baron], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:rbs@maths.uq.edu.au rbs@maths.uq.edu.au]<br />
|group=dev-tech-dom<br />
|source_dirs=parser/htmlparser<br />
|url=http://www.mozilla.org/newlayout/doc/parser.html<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=HAL<br />
|description=Hardware Abstraction Layer<br />
|owner=[https://mozillians.org/u/dhylands/ Dave Hylands]<br />
|peers=[mailto:gsvelto@mozilla.com Gabriele Svelto]<br />
|group=dev-platform<br />
|source_dirs=hal/<br />
|components=Core::Hardware Abstraction Layer (HAL)<br />
}}<br />
<br />
{{Module<br />
|name=HTML Parser<br />
|description=The HTML Parser transforms HTML source code into a DOM. It conforms to the HTML specification, and is mostly translated automatically from Java to C++.<br />
|owner=[mailto:hsivonen@iki.fi Henri Sivonen]<br />
|peers=<br />
|group=dev-tech-dom<br />
|source_dirs=parser/html<br />
|url=http://about.validator.nu/<br />
|components=Core::HTML: Parser<br />
}}<br />
<br />
{{Module<br />
|name=I18N Library<br />
|description=<br />
|owner=[mailto:jshin1987@gmail.com Jungshik Shin], [mailto:smontagu@smontagu.org Simon Montagu]<br />
|peers=[mailto:VYV03354@nifty.ne.jp Masatoshi Kimura]<br />
|group=dev-i18n<br />
|source_dirs=intl/<br />
|url=http://mozilla.org/projects/intl/index.html<br />
|components=Core::Internationalization<br />
}}<br />
<br />
{{Module<br />
|name=ImageLib<br />
|description=<br />
|owner=[mailto:joe@drew.ca Joe Drew]<br />
|peers=[mailto:netzen@gmail.com Brian Bondy], [mailto:jmuizelaar@mozilla.com Jeff Muizelaar], [mailto:jlebar@mozilla.com Justin Lebar], [mailto:seth@mozilla.com Seth Fowler]<br />
|group=dev-platform<br />
|source_dirs=media/libjpeg/, media/libpng/, image/, modules/zlib/<br />
|url=<br />
|components=Core::ImageLib<br />
}}<br />
<br />
{{Module<br />
|name=IPC<br />
|description=Message-passing between threads and processes<br />
|owner=[mailto:cjones@mozilla.com Chris Jones]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bent.mozilla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=ipc/glue/, ipc/ipdl/, ipc/chromium/<br />
|url=<br />
|components=Core::IPC}}<br />
<br />
{{Module<br />
|name=JavaScript<br />
|description=JavaScript engine (SpiderMonkey)<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:igor@mir2.org Igor Bukanov], [mailto:brendan@mozilla.org Brendan Eich], [mailto:gal@mozilla.com Andreas Gal], [mailto:wmccloskey@mozilla.com Bill McCloskey], [mailto:nnethercote@mozilla.com Nick Nethercote], [mailto:luke@mozilla.com Luke Wagner], [mailto:jwalden@mit.edu Jeff Walden], [mailto:ejpbruel@mozilla.com Eddy Bruel], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:jdemooij@mozilla.com Jan de Mooij], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:nmatsakis@mozilla.com Niko Matsakis], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:evilpies@gmail.com Tom Schuster], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:bobbyholley@gmail.com Bobby Holley], [mailto:till@tillschneidereit.net Till Schneidereit]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src<br />
|url=http://www.mozilla.org/js/spidermonkey,<br />
http://developer.mozilla.org/en/docs/About_JavaScript<br />
|components=Core::JavaScript Engine<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript JIT<br />
|description=JavaScript engine's JIT compilers (IonMonkey, Baseline)<br />
|owner=[mailto:jdemooij@mozilla.com Jan de Mooij]<br />
|peers=[mailto:danderson@mozilla.com David Anderson], [mailto:shu@mozilla.com Shu-yu Guo], [mailto:bhackett1024@gmail.com Brian Hackett], [mailto:nicolas.b.pierron@mozilla.com Nicolas Pierron], [mailto:mrosenberg@mozilla.com Marty Rosenberg], [mailto:evilpies@gmail.com Tom Schuster], [mailto:sstangl@mozilla.com Sean Stangl], [mailto:hv1989@gmail.com Hannes Verschore], [mailto:kvijayan@mozilla.com Kannan Vijayan], [mailto:luke@mozilla.com Luke Wagner]<br />
|group=dev-tech-js-engine-internals<br />
|source_dirs=js/src/jit<br />
|url=http://www.mozilla.org/js/spidermonkey<br />
|components=Core::JavaScript Engine: JIT<br />
}}<br />
<br />
{{Module<br />
|name=JavaScript Debugger Backend<br />
|description=JavaScript debugging hooks<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:rginda@hacksrus.com Rob Ginda]<br />
|group=dev-apps-js-debugger<br />
|source_dirs=js/jsd/<br />
|url=http://www.mozilla.org/js/jsd<br />
|components=Other Applications::Venkman JS Debugger<br />
}}<br />
<br />
{{Module<br />
|name=js-ctypes<br />
|description=A foreign function interface which allows privileged JS code to interact with binary code without using XPCOM/XPConnect.<br />
|owner=[mailto:jorendorff@mozilla.com Jason Orendorff]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/src/ctypes/<br />
|url=https://wiki.mozilla.org/JSctypes<br />
|components=Core::js-ctypes<br />
}}<br />
<br />
{{Module<br />
|name=js-tests<br />
|description=JavaScript test suite<br />
|owner=[mailto:bclary@bclary.com Bob Clary]<br />
|peers=<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tests/<br />
|url=http://www.mozilla.org/js/tests/library.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Layout Engine<br />
|description=rendering tree construction, layout (reflow), painting, etc.<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:smontagu@smontagu.org Simon Montagu], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:jfkthame@gmail.com Jonathan Kew], [mailto:tnikkel@gmail.com Timothy Nikkel], [mailto:matt.woodrow@gmail.com Matt Woodrow]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/%, layout/base/, layout/build/, layout/doc/, layout/forms/, layout/generic/, layout/html/, layout/macbuild/, layout/printing/, layout/tables/, layout/tools/<br />
|url=http://mozilla.org/newlayout/doc/ ,<br />
http://lxr.mozilla.org/mozilla/source/layout/doc/<br />
|components=Core::Layout, Core::Layout: Block and Inline, Core::Layout: Floats, Core::Layout: Form Controls, Core::Layout: HTML Frames, Core::Layout: Images, Core::Layout: Misc Code, Core::Layout: R & A Pos, Core::Layout: Tables, Core::Layout: Text, Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=libjar<br />
|description=The JAR handling code (protocol handler, stream implementation, and zipreader/zipwriter).<br />
|owner=[mailto:tglek@mozilla.com Taras Glek]<br />
|peers=[mailto:mwu@mozilla.com Michael Wu]<br />
|group=dev-platform<br />
|source_dirs=modules/libjar<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=MathML<br />
|description=MathML is a low-level specification for describing mathematics which provides a foundation for the inclusion of mathematical expressions in Web pages.<br />
|owner=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|group=dev-tech-mathml<br />
|source_dirs=layout/mathml/<br />
|url=http://www.mozilla.org/projects/mathml/<br />
|components=Core::MathML<br />
}}<br />
<br />
{{Module<br />
|name=mfbt<br />
|description=mfbt is a collection of headers, macros, data structures, methods, and other functionality available for use and reuse throughout all Mozilla code (including SpiderMonkey and Gecko more broadly).<br />
|owner=[mailto:jwalden@mit.edu Jeff Walden]<br />
|peers=[mailto:froydnj@mozilla.com Nathan Froyd], [mailto:Ms2ger@gmail.com Ms2ger], [mailto:mh+mozilla@glandium.org Mike Hommey]<br />
|group=dev-platform<br />
|source_dirs=mfbt/<br />
|url=<br />
|components=Core::MFBT<br />
}}<br />
<br />
{{Module<br />
|name=mozApps API & UI<br />
|description=Implementation of the navigator.mozApps API<br />
|owner=[mailto:fabrice@mozilla.com Fabrice Desré], [mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:myk@mozilla.org Myk Melez], [mailto:mar.castelluccio@studenti.unina.it Marco Castelluccio], [mailto:ferjmoreno@gmail.com Fernando Jiménez]<br />
|group=dev-webapi<br />
|source_dirs=dom/apps/, dom/interfaces/apps, product specific files implementing UI hooks.<br />
|url=<br />
|components=Core::DOM: Apps<br />
}}<br />
<br />
{{Module<br />
|name=mozilla-toplevel<br />
|description=The top level directory for the mozilla tree.<br />
|owner=[mailto:brendan@mozilla.org Brendan Eich]<br />
|peers=<br />
|group=<br />
|source_dirs=tools/README<br />
|url=<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Necko<br />
|description=The Mozilla Networking Library<br />
|owner=[mailto:pmcmanus@mozilla.com Patrick McManus]<br />
|peers=[mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:jduell.mcbugs@gmail.com Jason Duell], [mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:mnovotny@mozilla.com Michal Novotny], [mailto:hurley@mozilla.com Nick Hurley], [mailto:sworkman@mozilla.com Steve Workman]<br />
|group=dev-tech-network<br />
|source_dirs=netwerk/%, netwerk/base/, netwerk/build/, netwerk/cache/, netwerk/dns/, netwerk/locales/, netwerk/mime/, netwerk/protocol/, netwerk/resources/, netwerk/socket/, netwerk/streamconv/, netwerk/system/, netwerk/test/, netwerk/testserver/<br />
|url=http://www.mozilla.org/projects/netlib/, https://developer.mozilla.org/en/Necko<br />
|components=Core::Networking, Core::Networking: Cache, Core::Networking: Cookies, Core::Networking: FTP, Core::Networking: File, Core::Networking: HTTP, Core::Networking: JAR, Core::Networking: Websockets<br />
}}<br />
<br />
{{Module<br />
|name=NSPR<br />
|description=Netscape Portable Runtime<br />
|owner=[mailto:nelson@bolyard.com Nelson Bolyard], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|group=dev-tech-nspr<br />
|source_dirs=nsprpub/<br />
|url=http://www.mozilla.org/projects/nspr/<br />
http://www.mozilla.org/projects/nspr/reference/html/<br />
http://www.mozilla.org/projects/nspr/release-notes/<br />
|components=NSPR<br />
}}<br />
<br />
{{Module<br />
|name=PDF<br />
|description=Rendering code to display documents encoded in the ISO 32000-1 `PDF' format.<br />
|owner=[mailto:cjones@mozilla.com Chris Jones], [mailto:gal@mozilla.com Andreas Gal]<br />
|peers=[mailto:aadib@mozilla.com Artur Adib], [mailto:bdahl@mozilla.com Brendan Dahl], [mailto:vnicolas@mozilla.com Vivien Nicolas]<br />
|group=dev-platform<br />
|source_dirs=media/pdf/<br />
|url=https://github.com/mozilla/pdf.js<br />
|components=Core::PDF<br />
}}<br />
<br />
{{Module<br />
|name=Plugins<br />
|description= NPAPI Plugin support.<br />
|owner=[mailto:joshmoz@gmail.com Josh Aas]<br />
|peers=[mailto:jst@mozilla.org Johnny Stenback], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jmathies@mozilla.com Jim Mathies], [mailto:jschoenick@mozilla.com John Schoenick]<br />
|group=<br />
|source_dirs=dom/plugins/, modules/plugin/<br />
|url=https://wiki.mozilla.org/Plugins<br />
|components=Core::Java-Implemented Plugins, Core::Plug-ins<br />
}}<br />
<br />
{{Module<br />
|name=Preferences<br />
|description=Preference library<br />
|owner=vacant<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-platform<br />
|source_dirs=modules/libpref/<br />
|url=<br />
|components=Core::Preferences: Backend<br />
}}<br />
<br />
{{Module<br />
|name=Privilege Manager<br />
|description="caps"<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dveditz@cruzio.com Dan Veditz], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-dom<br />
|source_dirs=caps/<br />
|url=http://www.mozilla.org/projects/security/components/index.html<br />
|components=Core::Security: CAPS<br />
}}<br />
<br />
{{Module<br />
|name=Push Notifications<br />
|description=Push is a way for application developers to send messages to their web applications.<br />
|owner=[mailto:doug.turner@gmail.com Doug Turner]<br />
|peers=[mailto:nsm.nikhil@gmail.com Nikhil Marathe], [mailto:justin.lebar@gmail.com Justin Lebar]<br />
|group=<br />
|source_dirs=dom/push<br />
|url=https://wiki.mozilla.org/WebAPI/SimplePush<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=PyXPCOM<br />
|description=The Python to XPCOM bridge.<br />
|owner=[mailto:toddw@activestate.com Todd Whiteman]<br />
|peers=[mailto:mhammond@skippinet.com.au Mark Hammond]<br />
|group=<br />
|source_dirs=extension/python<br />
|url=https://developer.mozilla.org/en/PyXPCOM<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=Qt-based gfx and widget<br />
|description=Qt-based rendering and widget code<br />
|owner=[mailto:romaxa@gmail.com Oleg Romashin]<br />
|peers=[mailto:mozilla@rosenauer.org Wolfgang Rosenauer], [mailto:doug.turner@gmail.com Doug Turner]<br />
|group=dev-tech-widget<br />
|source_dirs=widget/qt/<br />
|url=<br />
|components=Core::Widget: Qt<br />
}}<br />
<br />
{{Module<br />
|name=RDF<br />
|description=<br />
|owner=[mailto:axel@pike.org Axel Hecht]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-rdf<br />
|source_dirs=rdf/<br />
|url=http://www.mozilla.org/rdf/doc/<br />
|components=Core::RDF<br />
}}<br />
<br />
{{Module<br />
|name=security<br />
|description=Crypto/PKI code, including NSS (Network Security Services) and JSS (NSS for Java)<br />
|owner=[mailto:rrelyea@redhat.com Bob Relyea], [mailto:wtc@google.com Wan-Teh Chang]<br />
|peers=[mailto:emaldona@redhat.com Elio Maldonado], [mailto:kaie@kuix.de Kai Engert], [mailto:ryan.sleevi@gmail.com Ryan Sleevi]<br />
|group=dev-tech-crypto<br />
|source_dirs=dbm/, security/coreconf/, security/dbm/, security/jss/, security/nss/, security/tinderbox/, security/tinderlight/<br />
|url=http://mozilla.org/projects/security/pki/<br />
|components=NSS, JSS, Core::Security, Core::Security: S/MIME<br />
}}<br />
<br />
{{Module<br />
|name=Security - Mozilla PSM Glue<br />
|description=Personal Security Manager<br />
|owner=[mailto:dkeeler@mozilla.com David Keeler]<br />
|peers=[mailto:honzab.moz@firemni.cz Honza Bambas], [mailto:wtc@google.com Wan-Teh Chang]<br />
|group=dev-tech-crypto<br />
|source_dirs=security/manager/<br />
|url=<br />
|components=Core::Security: PSM, Core::Security: UI<br />
}}<br />
<br />
{{Module<br />
|name=storage<br />
|description=Storage APIs with a SQLite backend<br />
|owner=[mailto:mak77@bonardo.net Marco Bonardo]<br />
|peers=[mailto:bugmail@asutherland.org Andrew Sutherland], [mailto:bent.mozillla@gmail.com Ben Turner]<br />
|group=dev-platform<br />
|source_dirs=db/sqlite3/, storage/<br />
|url=http://developer.mozilla.org/en/docs/Storage<br />
|components=Toolkit::Storage, Core::SQL<br />
}}<br />
<br />
{{Module<br />
|name=String<br />
|description=<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:jlebar@mozilla.com Justin Lebar]<br />
|group=dev-tech-xpcom<br />
|source_dirs=string/, xpcom/string/<br />
|url=https://developer.mozilla.org/En/Mozilla_internal_string_guide<br />
|components=Core::String<br />
}}<br />
<br />
{{Module<br />
|name=Style System<br />
|description=CSS style sheet handling; style data computation<br />
|owner=[mailto:dbaron@dbaron.org David Baron]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:cam@mcc.id.au Cameron McCormack]<br />
|group=dev-tech-layout<br />
|source_dirs=layout/style/<br />
|url=https://wiki.mozilla.org/Gecko:Overview#Style_System<br />
|components=Core::CSS Parsing and Computation<br />
}}<br />
<br />
{{Module<br />
|name=SVG<br />
|description=Scalable Vector Graphics<br />
|owner=[mailto:jwatt@jwatt.org Jonathan Watt]<br />
|peers=[mailto:longsonr@gmail.com Robert Longson], [mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:dholbert@mozilla.com Daniel Holbert], [mailto:birtles@gmail.com Brian Birtles]<br />
|group=dev-tech-svg<br />
|source_dirs=content/svg/, layout/svg/, content/smil/<br />
|url=https://developer.mozilla.org/en-US/docs/Web/SVG<br />
|components=Core::SVG<br />
}}<br />
<br />
{{Module<br />
|name=Tamarin<br />
|description=VM for ActionScript and JavaScript<br />
|owner=[mailto:edwsmith@adobe.com Edwin Smith], [mailto:jodyer@adobe.com Jeff Dyer]<br />
|peers=[mailto:brendan@mozilla.org Brendan Eich], [mailto:stejohns@adobe.com Steven Johnson], [mailto:tierney@adobe.com Erik Tierney], [mailto:treilly@adobe.com Tom Reilly]<br />
|group=dev-tech-js-engine<br />
|source_dirs=js/tamarin<br />
|url=http://www.mozilla.org/projects/tamarin/<br />
http://wiki.mozilla.org/tamarin/<br />
http://hg.mozilla.org/tamarin-central/<br />
http://hg.mozilla.org/tamarin-tracing/<br />
|components=Tamarin<br />
}}<br />
<br />
{{Module<br />
|name=Test Harness<br />
|description=In-tree test infrastructure and tools. Harnesses include, XPCShell, Mochitest (& Chrome), Reftest, JsREftest, Compiled Code Tests, Robocop, Mozmill and Marionette. Requests for new harnesses should go to Testing::General.<br />
|owner=[mailto:ted@mozilla.com Ted Mielczarek]<br />
|peers=[mailto:dbaron@dbaron.org David Baron] (reftest), [mailto:jwalden@mit.edu Jeff Walden] (httpd.js, jsreftest), [mailto:rcampbell@mozilla.com Rob Campbell] (mochitest, mochitest chrome, marionette), [mailto:jmaher@mozilla.com Joel Maher] (reftest, mochitest, jsreftest), [mailto:ctalbert@mozilla.com Clint Talbert] (reftest, compiled code, mozmill), [mailto:geoffbrown@mozilla.com Geoff Brown] (robocop), [mailto:hskupin@mozilla.com Henrik Skupin] (mozmill), [mailto:mdas@mozilla.com Malini Das] (marionette), [mailto:jgriffin Jonathan Griffin] (marionette), [mailto:dburns@mozilla.com David Burns] (marionette) [mailto:dminor@mozilla.com Dan Minor]<br />
|group=dev-quality<br />
|source_dirs=/testing<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::General, Testing::Mochitest, Testing::Mochitest Chrome, Testing::Marionette, Testing::Mozmill, Testing::Reftest, Testing::XPCShell Harness, Testing::httpd.js<br />
}}<br />
<br />
{{Module<br />
|name=Testing Infrastructure<br />
|description=Testing tools and infrastructure for Mozilla projects, harnesses for automated tests, stand-alone test tools. Talos, Graph Server, Mozbase, Pulse, WOO, Bughunter, SUTAgent, Eideticker<br />
|owner=[mailto:jmaher@mozilla.com Joel Maher]<br />
|peers=[mailto:bclary@bclary.com Bob Clary], [mailto:bhearsum@mozilla.com Ben Hearsum], [mailto:ccooper@deadsquid.com Chris Cooper], [mailto:ctalbert@mozilla.com Clint Talbert], [mailto:robert@roberthelmer.com Robert Helmer], [mailto:jmaher@mozilla.com Joel Maher], [mailto:rcampbell@mozilla.com Rob Campbell], [mailto:wlach@mozilla.com William Lachance], [mailto:jeads@mozilla.com Jonathan Eads], [mailto:jgriffin Jonathan Griffin], [mailto:bmoss@mozilla.com Bob Moss], [mailto:mcote@mozilla.com Mark Côté]<br />
|group=dev-quality<br />
|source_dirs=testing/, tools/httptester/, tools/page-loader/, tools/test-harness/, tools/tests/, tools/testserver/, tools/testy/<br />
|url=http://wiki.mozilla.org/SoftwareTesting<br />
|components=Testing::Infrastructure<br />
}}<br />
<br />
{{Module<br />
|name=JS Marionette Harness and Tools<br />
|description=Test harness and associated tools for running marionette tests on NodeJS (submodule of Test Infrastructure)<br />
|owner=[mailto:jlal@mozilla.com James Lal] <lightsofapollo>, [mailto:gaye@mozilla.com Gareth Aye] <gaye><br />
|peers=[mailto:aus@mozilla.com Ghislain "Aus" Lacroix] <auswerk>, [mailto:mike@bocoup.com Mike Pennisi] <jugglinmike>, [mailto:evanxd@mozilla.com Evan Tseng] <evanxd><br />
|source_dirs=These are all mozilla-b2g github repos: [https://github.com/mozilla-b2g/marionette-js-runner Marionette JS Runner], [https://github.com/mozilla-b2g/mocha-json-proxy Mocha JSON Proxy], [https://github.com/mozilla-b2g/mocha-tbpl-reporter Mocha TBPL Reporter], [https://github.com/mozilla-b2g/marionette-js-client Marionette JS Client], [https://github.com/mozilla-b2g/sockit-to-me Sockit To Me], [https://github.com/mozilla-b2g/marionette-apps Marionette Apps], [https://github.com/mozilla-b2g/marionette-js-logger Marionette JS Logger], [https://github.com/mozilla-b2g/marionette-b2gdesktop-host Marionette B2G Desktop Host], [https://github.com/mozilla-b2g/marionette-firefox-host Marionette Firefox Host], [https://github.com/mozilla-b2g/marionette-profile-builder Marionette Profile Builder], [https://github.com/mozilla-b2g/mozilla-profile-builder Mozilla Profile Builder]<br />
|components=Testing::JSMarionette<br />
|group=dev-gaia<br />
}}<br />
<br />
{{Module<br />
|name=XPCShell Test Harness<br />
|description=The XPCShell Harness<br />
|owner=[mailto:ted.mielczarek@gmail.com Ted Mielczarek]<br />
|peers=[mailto:jmaher@mozilla.com Joel Maher]<br />
|source_dirs=testing/xpcshell<br />
|components=Testing::XPCShell Harness<br />
}}<br />
<br />
{{Module<br />
|name=Update Service<br />
|description=server code for Mozilla Update services (aus, addons, pfs)<br />
|owner=[mailto:morgamic@mozilla.com Mike Morgan]<br />
|peers=[mailto:jscott@mozilla.com Justin Scott], [mailto:shaver@mozilla.org Mike Shaver], [mailto:wclouser@mozilla.com Will Clouser]<br />
|group=dev-amo<br />
|source_dirs=webtools/addons/, webtools/aus/, webtools/update/<br />
|url=http://wiki.mozilla.org/wiki/AMO<br />
|components=AUS::Administration, AUS::Systems<br />
}}<br />
<br />
{{Module<br />
|name=View System<br />
|description=The View Manager is responsible for handling "heavyweight" rendering (some clipping, compositing) and event handling tasks.<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:dbaron@dbaron.org David Baron]<br />
|group=dev-tech-layout<br />
|source_dirs=view/<br />
|url=<br />
|components=Core::Layout: View Rendering<br />
}}<br />
<br />
{{Module<br />
|name=Web Audio<br />
|description=Support for the W3C Web Audio API specification.<br />
|owner=[mailto:ehsan@mozilla.com Ehsan Akhgari]<br />
|peers=[mailto:roc+@cs.cmu.edu Robert O'Callahan], [mailto:padenot@mozilla.com Paul Adenot]<br />
|group=dev-platform<br />
|source_dirs=content/media/webaudio<br />
|url=https://wiki.mozilla.org/Web_Audio_API<br />
|components=Core::Web Audio<br />
}}<br />
<br />
{{Module<br />
|name=WebRTC<br />
|description=WebRTC is responsible for realtime audio and video communication, as well as related issues like low-level camera and microphone access (on desktop at least)<br />
|owner=[mailto:rjesup@mozilla.com Randell Jesup]<br />
|peers=[mailto:ekr@mozilla.com Eric Rescorla], [mailto:ehugg@cisco.com Ethan Hugg], [mailto:tterriberry@mozilla.com Tim Terriberry], [mailto:anant@mozilla.com Anant Narayanan]<br />
|group=dev-media<br />
|source_dirs=media/webrtc<br />
|url=https://wiki.mozilla.org/Media/webrtc<br />
|components=Core::WebRTC, Core::WebRTC (Audio/Video), Core::WebRTC (Networking), Core::WebRTC (Signaling)<br />
}}<br />
<br />
{{Module<br />
|name=Widget<br />
|description=<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:pavlov@pavlov.net Stuart Parmenter], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/%, widget/public/, widget/%, widget/xpwidgets/<br />
|url=<br />
|components=Core::Drag and Drop, Core::Widget<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Android<br />
|description=The Android Port<br />
|owner=[mailto:blassey.bugs@lassey.us Brad Lassey]<br />
|peers=[mailto:jwillcox@mozilla.com James Willcox]<br />
|group=dev-platforms-mobile<br />
|source_dirs=widget/android/, embedding/android<br />
|url=<br />
|components=Core::Widget: Android<br />
}}<br />
<br />
{{Module<br />
|name=Widget - GTK<br />
|description=supported X widgetry and gfx<br />
|owner=[mailto:roc+@cs.cmu.edu Robert O'Callahan]<br />
|peers=[mailto:karlt+@karlt.net Karl Tomlinson]<br />
|group=dev-platform<br />
|source_dirs=widget/gtk/, widget/gtk2/, widget/gtksuperwin/, widget/gtkxtbin/<br />
|url=http://www.mozilla.org/unix/, http://www.gtk.org, http://www.mozilla.org/ports/gtk/<br />
|components=Core::Widget: Gtk<br />
}}<br />
<br />
{{Module<br />
|name=Widget - OS X<br />
|description= Gecko's OS X compatibility layer.<br />
|owner=[mailto:smichaud@pobox.com Steven Michaud]<br />
|peers=[mailto:joshmoz@gmail.com Josh Aas], [mailto:mstange@themasta.com Markus Stange], [mailto:bgirard@mozilla.com Benoit Girard], [mailto:spohl@mozilla.com Stephen Pohl]<br />
|group=dev-platform<br />
|source_dirs=widget/cocoa/<br />
|url=<br />
|components=Core::Widget: Cocoa<br />
}}<br />
<br />
{{Module<br />
|name=Widget - Windows<br />
|description=Windows widgets and desktop integration<br />
|owner=[mailto:jmathies@mozilla.com Jim Mathies]<br />
|peers=[mailto:blassey@mozilla.com Brad Lassey], [mailto:netzen@gmail.com Brian Bondy], [mailto:cbiesinger@gmail.com Christian Biesinger], [mailto:dougt@meer.net Doug Turner], [mailto:neil@parkwaycc.co.uk Neil Rashbrook], [mailto:robarnold@cmu.edu Rob Arnold], [mailto:timeless@mozdev.org Josh 'timeless' Soref], [mailto:vladimir@pobox.com Vladimir Vukicevic]<br />
|group=dev-platform<br />
|source_dirs=widget/windows/<br />
|url=<br />
|components=Core::Widget: Win32<br />
}}<br />
<br />
{{Module<br />
|name=XBL<br />
|description=eXtensible Binding Language<br />
|owner=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|peers=[mailto:mrbkap@gmail.com Blake Kaplan], [mailto:bobbyholley@gmail.com Bobby Holley]<br />
|group=dev-tech-xbl<br />
|source_dirs=content/xbl/%, content/xbl/public/, content/xbl/src/<br />
|url=http://www.mozilla.org/projects/xbl/<br />
|components=Core::XBL<br />
}}<br />
<br />
{{Module<br />
|name=XML<br />
|description=XML in Mozilla, including XML, XHTML, Namespaces in XML, Associating Style Sheets with XML Documents, XML Linking and XML Extras. XML-related things that are not covered by more specific projects.<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking], [mailto:jst@mozilla.org Johnny Stenback]<br />
|group=dev-tech-xml<br />
|source_dirs=content/xml/, extensions/xmlextras/, parser/expat/<br />
|url=http://www.mozilla.org/newlayout/xml/<br />
|components=Core::XML<br />
}}<br />
<br />
{{Module<br />
|name=XPApps<br />
|description=Cross-Platform Applications, mostly Navigator front end and application shell.<br />
|owner=[mailto:neil@parkwaycc.co.uk Neil Rashbrook]<br />
|peers=[mailto:dean_tessman@hotmail.com Dean Tessman], [mailto:jag@tty.nl Peter Annema], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-apps-seamonkey<br />
|source_dirs=xpfe/<br />
|url=http://www.mozilla.org/xpapps/<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPCOM<br />
|description=The cross-platform object model and core data structures.<br />
|owner=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|peers=[mailto:dougt@meer.net Doug Turner], [mailto:froydnj@mozilla.com Nathan Froyd]<br />
|group=dev-platform<br />
|source_dirs=startupcache/, xpcom/%, xpcom/base/, xpcom/build/, xpcom/components/, xpcom/ds/, xpcom/glue/, xpcom/proxy/, xpcom/sample/, xpcom/stub/, xpcom/tests/, xpcom/threads/, xpcom/tools/, xpcom/windbgdlg/<br />
|url=http://developer.mozilla.org/en/XPCOM<br />
|components=Core::XPCOM<br />
}}<br />
<br />
{{Module<br />
|name=XPConnect<br />
|description=Deep Magic<br />
|owner=[mailto:bobbyholley@gmail.com Bobby Holley]<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:gal@uci.edu Andreas Gal], [mailto:jst@mozilla.org Johnny Stenback], [mailto:peterv@propagandism.org Peter Van der Beken], [mailto:mrbkap@gmail.com Blake Kaplan], [mailto:gkrizsanits@mozilla.com Gabor Krizsanits]<br />
|group=<br />
|source_dirs=js/xpconnect/<br />
|url=<br />
|components=Core::XPConnect<br />
}}<br />
<br />
{{Module<br />
|name=XPIDL<br />
|description=Cross-platform IDL compiler; produces .h C++ header files and .xpt runtime type description files from .idl interface description files.<br />
|owner=[mailto:me@kylehuey.com Kyle Huey]<br />
|peers=[mailto:shaver@mozilla.org Mike Shaver], [mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|group=dev-tech-xpcom<br />
|source_dirs=xpcom/typelib/<br />
|url=http://www.mozilla.org/scriptable/xpidl<br />
http://www.mozilla.org/scriptable<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPInstall<br />
|description=<br />
|owner=[mailto:dveditz@cruzio.com Dan Veditz]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg]<br />
|group=dev-tech-xpinstall<br />
|source_dirs=xpinstall/<br />
|url=<br />
|components=Core::Installer: XPInstall Engine<br />
}}<br />
<br />
{{Module<br />
|name=xptcall<br />
|description=XPTCall - platform-specific assembly for calling and implementing arbitrary XPCOM interfaces.<br />
|owner=[mailto:timeless@mozdev.org Josh 'timeless' Soref]<br />
|peers=[mailto:benjamin@smedbergs.us Benjamin Smedberg], [mailto:shaver@mozilla.org Mike Shaver]<br />
|group=dev-xpcom<br />
|source_dirs=xpcom/reflect/xptcall/<br />
|url=http://www.mozilla.org/scriptable/xptcall-faq.html<br />
|components=<br />
}}<br />
<br />
{{Module<br />
|name=XPToolkit<br />
|description=Cross-platform user interface toolkit<br />
|owner=<br />
|peers=[mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:hyatt@mozilla.org Dave Hyatt], [mailto:jag@tty.nl Peter Annema], [mailto:Jan.Varga@gmail.com Jan Varga]<br />
|group=dev-tech-xul<br />
|source_dirs=content/xul/, layout/xul/<br />
|url=http://www.mozilla.org/xpfe/<br />
|components=Core::XP Toolkit/Widgets: Menus, Core::XP Toolkit/Widgets: XUL<br />
}}<br />
<br />
{{Module<br />
|name=XSLT Processor<br />
|description=XSLT transformations processor<br />
|owner=[mailto:peterv@propagandism.org Peter Van der Beken]<br />
|peers=[mailto:axel@pike.org Axel Hecht], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xslt<br />
|source_dirs=content/xslt/<br />
|url=http://www.mozilla.org/projects/xslt/, http://www.w3.org/TR/xslt.html<br />
|components=Core::XSLT<br />
}}<br />
<br />
{{Module<br />
|name=XTF<br />
|description=eXtensible Tag Framework<br />
|owner=<br />
|peers=[mailto:alex@croczilla.com alex@croczilla.com], [mailto:bzbarsky@mit.edu Boris Zbarsky], [mailto:jonas@sicking.cc Jonas Sicking]<br />
|group=dev-tech-xbl<br />
|source_dirs=content/xtf/, layout/xtf/<br />
|url=http://www.croczilla.com/bits_and_pieces/xtf/<br />
|components=Core::XTF<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Windows <br />
|description=Sandboxing for the Windows platform <br />
|owner=[https://mozillians.org/en-US/u/TimAbraldes Tim Abraldes]<br />
|peers=[mailto:bowen@mozilla.com Bob Owen] [mailto:netzen@gmail.com Brian Bondy] [mailto:aklotz@mozilla.com Aaron Klotz]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/win <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - OSX <br />
|description=Sandboxing for the OSX platform <br />
|owner=[mailto:smichaud@mozilla.com Steven Michaud]<br />
|peers=[mailto:areinald@mozilla.com Andre Reinald ]<br />
|group=dev-platform <br />
|source_dirs=security/sandbox/mac <br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security<br />
}}<br />
<br />
{{Module<br />
|name=Sandboxing - Linux & B2G<br />
|description=Sandboxing for the Linux & B2G platforms<br />
|owner=[mailto:jld@mozilla.com Jed Davis]<br />
|peers=[mailto:gDestuynder@mozilla.com Guillaume Destuynder]<br />
|group=dev-platform<br />
|source_dirs=security/sandbox/linux<br />
|url=https://wiki.mozilla.org/Security/Sandbox <br />
|components=Core::Security<br />
}}<br />
<br />
===Submodules===<br />
{{Module<br />
|name=Build Config - Fennec<br />
|description=Submodule of the build config covering Fennec's build system in mobile/android.<br />
|owner=[mailto:gps@mozilla.com Gregory Szorc]<br />
|peers=Same as Build Config plus [mailto:nalexander@mozilla.com Nicholas Alexander].<br />
|group=dev-builds<br />
|components=Core::Build Config<br />
}}<br />
<br />
<noinclude><br />
<br />
===Unassigned Bugzilla Components===<br />
<br />
The following Bugzilla components in the Core project have not been assigned to a module (this list is not exhaustive):<br />
<br />
<pre><br />
Core::Event Handling<br />
Core::File Handling<br />
Core::Find Backend<br />
Core::Gecko Profiler<br />
Core::General<br />
Core::HTML: Form Submission<br />
Core::History: Global<br />
Core::Identity<br />
Core::Image Blocking<br />
Core::JavaScript Debugging APIs<br />
Core::Localization<br />
Core::Nanojit<br />
Core::Networking: Domain Lists<br />
Core::Print Preview<br />
Core::Printing: Output<br />
Core::Printing: Setup<br />
Core::Profile: BackEnd<br />
Core::Profile: Migration<br />
Core::Profile: Roaming<br />
Core::QuickLaunch (AKA turbo mode)<br />
Core::Rewriting and Analysis<br />
Core::Selection<br />
Core::Serializers<br />
Core::Spelling checker<br />
Core::Tracking<br />
Core::Video/Audio<br />
Core::Web Services<br />
Core::WebDAV<br />
Core::Widget: OS/2<br />
Core::Widget: Photon<br />
Core::X-remote<br />
Core::XForms<br />
Core::XUL<br />
Core::jemalloc<br />
</pre><br />
</noinclude></div>Sidstammhttps://wiki.mozilla.org/index.php?title=Platform/2014-Q3-Goals&diff=1002256Platform/2014-Q3-Goals2014-08-04T16:52:19Z<p>Sidstamm: /* Security & Privacy Engineering */</p>
<hr />
<div>=== Platform ===<br />
==== [[Platform/2014-Goals|2014 General Goals]] ====<br />
<br />
=== GFX ===<br />
Items marked [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AnKFEBp1-VyqdFNfRlZmV0ExM0VvZGMxNThWX0d6LWc&usp=drive_web#gid=0 here] with release 33 and 34 are part of the Q3 landings.<br />
<br />
=== Layout ===<br />
* Layout to Moz2D<br />
** {{ok|Migrate SVG to Moz2D (bug 703159) }}<br />
<br />
* Enable Vertical Text for major use cases for Chinese & Japanese<br />
** {{ok|bug 145503}}<br />
<br />
* Text Performance<br />
** {{ok|{{bug|998869}}}} Streamline parsing of fontlists and improve efficiency of font matching code (note: unicode-range support will fall out of this work)<br />
** {{ok|{{bug|934770}}}} - slow at rendering large blocks of plain text<br />
** {{ok|{{bug|860492}}}} - Divide large text runs into smaller runs to avoid chrome hangs<br />
<br />
* Improve Restyling Performance<br />
** {{ok|bug 977991}}<br />
<br />
* {{ok|Font Inflation and Reflow-on-Zoom }}<br />
** both implementation bug fixing and spec work<br />
** -moz-text-size-adjust <br />
<br />
* ImageLib<br />
** {{ok|RasterImage for multiple images}}<br />
<br />
* CSS Projects with Adobe<br />
** {{ok|CSS Filters}}<br />
<br />
* Animations & Transitions<br />
** {{ok|transitions/animations spec editing}}<br />
** {{ok|transitions refactoring to match new spec (960465)}}<br />
** {{ok|frame reconstruction (625289)}}<br />
<br />
* OMTA on non-B2G Platforms (980770)<br />
** {{ok|fix correctness bugs (cascading, etc.)}}<br />
** {{ok|turning on on other OMTC platforms (Mac/Android)}}<br />
<br />
* Web animations: <br />
** {{ok|TBD}}<br />
<br />
* CSS Scrolling<br />
** {{ok|CSS scroll snapping}}<br />
** {{ok|scroll-behavior:smooth}}<br />
<br />
* CSS Flexbox <br />
** {{ok|performance bugs}}<br />
** {{ok|spec changes}}<br />
<br />
* CSS Ruby <br />
** {{ok|implementation}}<br />
<br />
=== Media ===<br />
* {{ok|Enable MSE/VP9 for Firefox 33 in Nightly/Aurora}}<br />
* {{ok|Enable MSE/MP4 on Windows and Firefox OS for Firefox 34}}<br />
<br />
=== DOM ===<br />
* {{ok|Mirror prototype of DOM objects through xray wrappers (peterv)}}<br />
* {{ok|Remove nsDOMClassInfo.cpp}}<br />
* {{done|Make less-privileged non-Xrayable unwaived opaque from privileged code (bholley, {{bug|856067}})}}<br />
* {{ok|Route all JSContext pushing through AutoJSAPI and Implement GetEntryGlobal (bobowen, bholley, {{bug|951991}})}}<br />
* {{ok|Land <picture> preffed on on nightly ({{bug|1017875}}) (johns)}}<br />
* {{ok|audit callsites of IsInDoc()/GetCurrentDoc to ensure correct Shadow DOM behaviour and fix Shadow DOM blockers for Gaia (smaug, wchen) ({{bug|1026047}})}}<br />
* {{ok|land Service Workers preffed on on nightly (nsm, bkelly, baku) ({{bug|903441}})}}<br />
<br />
=== WebAPI ===<br />
* {{ok|create design plan for "share" activity (flow, what kind of objects are involved) (annevk)}}<br />
* {{ok|document existing activities usage in gaia (ehsan)}}<br />
* {{ok|get [https://w3c.github.io/screen-orientation/ screen orientation spec] to LC (marcosc)}}<br />
* {{ok|publish use cases and spec for [http://w3c.github.io/screen-wake/ "wakelock" API] (marcosc)}}<br />
* {{ok|24/12 hour format API (ehsan) {{bug|903683}}}}<br />
* {{ok|{{bug|942542}} new quota API on PBackground for Service Worker cache (janv)}}<br />
* {{ok|{{bug|701634}} IndexedDB in workers (bent)}}<br />
<br />
=== JS ===<br />
* {{jok|837314}} ES6 classes<br />
* {{jok|941796}} Generational GC on Firefox OS<br />
* {{jok|650161}} Compacting GC to reduce memory usage<br />
* {{jok|856533}} Escape analysis JIT optimizations<br />
* {{jok|998392}} Use Latin1 strings to reduce memory usage<br />
* {{jok|903519}} Allocate strings in GC nursery (for performance)<br />
* {{jok|972710}} ARM64 JIT ''[stretch goal]''<br />
<br />
=== Accessibility ===<br />
* {{ok|}}e10s: proxy the common a11y API stuff like name, role, and states.<br />
* {{ok|}}GAIA: Fix [https://bugzilla.mozilla.org/buglist.cgi?priority=--&f1=blocked&list_id=10674217&o1=anyexact&resolution=---&query_based_on=b2ga11y%20p%3D1&o2=substring&query_format=advanced&f2=status_whiteboard&v1=893789&component=Disability%20Access%20APIs&component=Gaia&component=Gaia%3A%3ABluetooth%20File%20Transfer&component=Gaia%3A%3ABrowser&component=Gaia%3A%3ABuild&component=Gaia%3A%3ACalendar&component=Gaia%3A%3ACamera&component=Gaia%3A%3AClock&component=Gaia%3A%3AContacts&component=Gaia%3A%3ACost%20Control&component=Gaia%3A%3ADialer&component=Gaia%3A%3AE-Mail&component=Gaia%3A%3AEverything.me&component=Gaia%3A%3AFirst%20Time%20Experience&component=Gaia%3A%3AFMRadio&component=Gaia%3A%3AGallery&component=Gaia%3A%3AGithubBot&component=Gaia%3A%3AHomescreen&component=Gaia%3A%3AKeyboard&component=Gaia%3A%3AL10n&component=Gaia%3A%3ALoop&component=Gaia%3A%3AMusic&component=Gaia%3A%3ANotes&component=Gaia%3A%3APDF%20Viewer&component=Gaia%3A%3APerformanceTest&component=Gaia%3A%3ARingtones&component=Gaia%3A%3ASearch&component=Gaia%3A%3ASettings&component=Gaia%3A%3ASMS&component=Gaia%3A%3ASystem&component=Gaia%3A%3ASystem%3A%3ABrowser%20Chrome&component=Gaia%3A%3ASystem%3A%3AInput%20Mgmt&component=Gaia%3A%3ASystem%3A%3ALockscreen&component=Gaia%3A%3ASystem%3A%3AWindow%20Mgmt&component=Gaia%3A%3ATestAgent&component=Gaia%3A%3AUI%20Tests&component=Gaia%3A%3AVideo&component=Gaia%3A%3AWallpaper&component=Gaia%3A%3AWappush&v2=b2ga11y%20p%3D1&product=Core&product=Firefox%20OS all Gaia P1 a11y bugs] (~30 at this time).<br />
* {{ok|}}FFOS: {{Bug|1030465}} - Volume change should update the screen reader volume.<br />
* {{ok|}}FFOS: {{Bug|1030466}} - Headphones screen reader volume is too low.<br />
* {{ok|}}FFOS: {{Bug|1030468}} - VC rectangle needs to work with scaled content.<br />
* {{ok|}}FFOS: {{Bug|1030470}} - Localization needs to work when switching locales in FxOS.<br />
<br />
=== Perf ===<br />
<br />
Fix major source of browser jank:<br />
<br />
* {{ok|Initialize plugin instances asynchronously {{bug|998863}} }}<br />
* {{ok|Pause heavy main-thread activities while user is interacting with the browser: }}<br />
** {{ok|Determine when a user is actively interacting with the browser}}<br />
** {{ok|Detect when jank occurs during interactions and report to Telemetry {{bug|1017055}} }}<br />
** {{ok|Experiment with hinting to GC & CC that they should pause while the user is interacting with the browser}}<br />
* {{ok|Take over refactoring of Places from Frontend team, eliminate some of the [http://telemetry.mozilla.org/slowsql/ Places main-thread SQL] reported to Telemetry }}<br />
* {{ok|Don't store UI customization in localstore.rdf, use off-main thread JSON instead {{bug|559505}} }}<br />
<br />
Improve Firefox startup (identified as a top issue in user research):<br />
<br />
* {{ok|Reduce appearance of the "profile is in use" message on startup {{bug|286355}} }}<br />
* {{ok|Restore windows one by one during session-restore {{bug|1034534}} and/or load windows by descending z-order {{bug|1034036}} }}<br />
* {{ok|C++ version of AsyncShutdown {{bug|918317}} }}<br />
<br />
Prevent performance regressions:<br />
<br />
* {{ok|Implement automatic detection & alerting for Telemetry regressions {{bug|1031032}} }}<br />
* {{ok|Help developers understand & diagnose Talos regressions}}, e.g. [https://bugzilla.mozilla.org/show_bug.cgi?id=1026550 Firefox 33 regression tracking], [https://bugzilla.mozilla.org/show_bug.cgi?id=1004427 Firefox 32 regressions], [https://bugzilla.mozilla.org/show_bug.cgi?id=990085 Firefox 31]<br />
<br />
Grow community:<br />
<br />
* {{ok|Mentor at least 5 external contributors}}<br />
<br />
=== Networking ===<br />
<br />
* {{ok|Ship Network Predictor ("Seer") on nightly, using HTTP cache instead of SQLite ({{bug|1009122}}) (hurley)}}<br />
* {{ok|Ship current (hopefully final) IETF version of HTTP/2 preffed on in nightly (hurley)}}<br />
* {{ok|HTTP/2 "alt-svc" support ({{bug|1003448}}) (mcmanus)}}<br />
* {{ok|HTTP cache: determine if revalidation is needed w/o doing I/O ({{bug|983122}}) (sworkman) }}<br />
* {{ok|Network up/down link detection on all platforms ({{bug|939318}}) (bagder) }}<br />
* {{ok|Implement WebSocket compression extension ({{bug|792831}}) (michal) }}<br />
<br />
=== Mobile ===<br />
<br />
=== A*Team ===<br />
<br />
For full list, see [[Auto-tools/Goals/2014Q3|A-Team Goals 2014Q3]]<br />
<br />
'''B2G'''<br />
* {{ok|}} Run a set of performance and correctness tests per-commit to b2g-inbound on Flame devices<br />
* {{ok|}} Get gaia-integration tests running on device<br />
* {{ok|}} Expand the FxOS Certification Suite with 1.4 support, test automation to prevent regressions, and investigation of support for non-phone devices<br />
* {{ok|}} Green up B2G tests on TaskCluster (joint with RelEng)<br />
<br />
'''Developer Productivity'''<br />
* {{ok|}} Deploy ReviewBoard for developers to start using (joint with RelEng)<br />
<br />
'''Performance'''<br />
* {{ok|}} Deploy new Talos tests for tp5o_scroll, webgl, webrtc, and mainthread I/O<br />
* {{ok|}} Get Datazilla alerts to beta mode (full parity with graph server alerts) with reduced noise<br />
* {{ok|}} Get Eideticker running against Android again with increased frequency<br />
* {{ok|}} Run B2G Eideticker against same branch/build combinations as our other on-device perf tests<br />
* {{ok|}} Stand up a Games Benchmarking system for webaudio tests running against Firefox and Chrome<br />
<br />
'''Treeherder'''<br />
* {{ok|}} Deliver performance web service for ingesting and returning performance data <br />
* {{ok|}} Deliver a UI for viewing Talos data<br />
<br />
'''Sheriffing'''<br />
* {{ok|}} Fully transition sheriffing from TBPL to Treeherder<br />
<br />
'''General Automation'''<br />
* {{ok|}} Create weekly reports that describe how many tests have been added/disabled/enabled per suite and platform<br />
* {{ok|}} Move reftest to mozbase<br />
* {{ok|}} Add command executors for Marionette for Java and Python<br />
<br />
'''Bugzilla'''<br />
* {{done|}} Improve load time of related bugs; can decrease show_bug load times by up to 12%<br />
* {{ok|}} Minify and concatenate JS files<br />
* {{ok|}} Authoritative view for review history<br />
* {{ok|}} Rewrite docs for REST API<br />
<br />
'''Community'''<br />
* {{ok|}} Create good_next_bugs (name can be adjusted) so once contributors are comfortable they can do more serious coding/problem solving on a project they are familiar with<br />
* {{ok|}} Monthly review of mentored bugs and projects<br />
<br />
=== Web Engineering ===<br />
'''Crash stats'''<br />
* {{ok|}} Prototype service for identifying post-crash user actions<br />
* {{ok|}} Hardware and performance tuning for new primary data store<br />
* {{ok|}} Remove older, redundant crash storage format from database<br />
* {{ok|}} Improve search performance and features<br />
* {{ok|}} Replace interfaces to deprecated external data sources<br />
* {{ok|}} Remove barriers to community installations<br />
'''FHR'''<br />
* {{ok|}} Support search diversion plan<br />
'''DXR'''<br />
* {{ok|}} Improve infrastructure.<br />
** For example, switch to ES backend, which will enable us to build multi-language support and parallel tree indexing.<br />
* {{ok|}} Broaden our audience.<br />
** Pull users away from MXR so we can shut it off. For example, add support for Rust or JS, squash MXR migration blockers.<br />
'''l10n'''<br />
* {{ok|}} Get l10n build logs into a searchable data store<br />
* {{ok|}} Replace some buildbot functionality with a10n automation<br />
'''Air Mozilla'''<br />
* {{ok|}} Prototype support for streaming media boxes<br />
* {{ok|}} Improve desktop user experience<br />
<br />
[https://etherpad.mozilla.org/webeng-q32014 full list]<br />
<br />
=== SUMO and Input ===<br />
* {{ok|}} SUMO: Launch new offline SUMO app [Get Firefox on a Growth Trajectory]<br />
* {{ok|}} SUMO: Develop new Community Hub to a level where it can replace legacy Karma app [Enable Communities with Impact]<br />
* {{ok|}} SUMO: Research and prototype new experimental features (e.g. geotargeting, Instant Search, Search Suggestions) [Get Firefox on a Growth Trajectory]<br />
<br />
* {{ok|}} Input: Improve documentation and install to lower the bar for contribution [Enable Communities with Impact]<br />
* {{ok|}} Input: Support Heartbeat [Get Firefox on a Growth Trajectory]<br />
* {{ok|}} Input: Dashboards for Everyone [Get Firefox on a Growth Trajectory]<br />
<br />
=== Release Engineering - Laura ===<br />
* {{ok|}} Enable capacity expansion for bare-metal releng OS X build and test slaves via hardware provided by third-party datacenters (Get Firefox on a Trajectory of Growth)<br />
* {{ok|}} Simplify release engineering mobile hardware infrastructure (Get Firefox on a Trajectory of Growth)<br />
* {{ok|}} Automate developer access to continuous integration resources to expedite debugging and standing up new job variants. (Enable Communities With Impact)<br />
* {{ok|}} Help enable video operability on the web by providing continuous integration for Cisco Open H.264 builds. (Get Firefox on a Trajectory of Growth)<br />
<br />
=== Release Engineering - Taras ===<br />
* {{ok|}} Replace aging Firefox update service with a scalable, modern solution. (Get Firefox on a Trajectory of Growth)<br />
* {{ok|}} Simplify developer workflow by automating patch landing and uplift. (Enable Communities With Impact)<br />
* {{ok|}} Optimize network transfers for build/test automation between datacenters. (Enable Communities With Impact)<br />
* {{ok|}} Continue AWS cost optimizations: EBS < 3% of AWS bill(vs 30% in Q2) (Enable Communities With Impact)<br />
* {{ok|}} Improve developer workflow by migrating 80% of FirefoxOS build/test jobs to taskcluster (Enable Communities With Impact)<br />
* {{ok|}} Turn telemetry is into a general purpose s3 ingester and analysis tool<br />
<br />
=== Release Engineering Operations ===<br />
* Build/Test System Performance Enhancements<br />
** {{ok| Unify releng platform architecture, using common tools and best practices, to decrease complexity and enable smoother developer engagement {{bug|1026110}} [Get Firefox on a Trajectory of Growth, Enable Communities With Impact] }}<br />
** {{ok| Improve communication and response time for releng network flow requests {{bug|1026112}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] }}<br />
** {{ok| Improve security for all releng windows infrastructure {{bug|893716}} [Get Firefox on a Trajectory of Growth] }}<br />
* Build/Test System Self-Serve Re-architecture<br />
** {{prev| Design a private cloud deployment architecture for bare metal and produce a POC that supports Ubuntu 12.04 test machines. {{bug|963165}} [Get Firefox on a Trajectory of Growth, Scale Firefox OS] }}<br />
** {{ok| Create self-service capability for releng hardware Firefox linux test slaves (build slaves as a stretch goal) {{bug|1026687}} (depends on completion of previous goal) [Get Firefox on a Trajectory of Growth, Scale Firefox OS] }}<br />
** {{ok| Create self-service capability for releng hardware Firefox windows test slaves. {{bug|967064}} [Get Firefox on a Growth Trajectory] }}<br />
<br />
=== Developer Services ===<br />
* {{new|(with B-team) roll out phase 2 of new review tooling}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
* {{new|Upgrade existing Mercurial infrastructure to support more rapid, safe, and coordinated deployment of updates.}} [Get Firefox on a Growth Trajectory / Enable communities with impact]<br />
<br />
[https://etherpad.mozilla.org/devservices-Q32014 Full List]<br />
<br />
=== Security & Privacy Engineering ===<br />
More details here: [[SecurityEngineering/2014/Q3Goals]]<br />
<br />
'''Content Security'''<br />
* {{ok|Gecko Security Hooks: Finish code and debugging for New Channel API, start getting reviews}} (dri=tanvi)<br />
* {{ok|Gecko Security Hooks: Create plan for addon compatibility}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central}} (dri=sstamm)<br />
* {{new|Evangelism: Security Open Mic presentation + blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs}} (dri=ckerschb)<br />
<br />
'''Tracking Protection'''<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help}} (dri=sstamm)<br />
* {{done|Land first implementation of protection in Fx 33/34 off by default.}} (dri=mmc)<br />
<br />
'''Communications Security'''<br />
* {{ok|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok| HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{new| Update roadmap for Cert Revocation improvements}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{ok| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{ok| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{ok| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)<br />
<br />
=== Firefox and Platform Security ===<br />
<br />
* [https://mana.mozilla.org/wiki/display/~gkwong@mozilla.com/Marifuzz Marifuzz ] fuzzer ported to and running on Flame devices.<br />
* Update ASan and LSan work for DOMFuzzer<br />
* Update "Bounty Stars" document with issues found by external reporters and updating DOMFuzzer to reflect these results.<br />
* Get Clang on RelEng ready for official OS X ASan builds.<br />
* Initial work to move CoreFuzz towards running in cloud environments.<br />
* WebCrypto API fuzzing using Dharma fuzzer. <br />
* Port a portion of WebRTC fuzzing from Frambois fuzzer to Dharma fuzzer.<br />
* Peach: Improving and porting Peach 2 to Python 3.<br />
* Public Mozilla Security Github work: Moving of fuzzing tools from Fuzzing Hg to GitHub, including work to separate harnesses from testcase generation tools.<br />
<br />
=== Games Program ===<br />
*Reach out to 3rd party engines en masse (also for Q4)<br />
*Select a 3D demo for mobile<br />
*Pick a partner demo to optimize for mobile<br />
*Focus on supporting shipping games and maintaining platform stability <br />
*Focus on Shared Array Buffer implementation<br />
*WebGL Benchmarks<br />
*Continue to work MDN documentation; get Emscripten documentation started<br />
*GDC and MWC event support plan<br />
<br />
=== Release Management ===<br />
For full list, see [[Release_Management/Goals/2014Q3#Release_Management_General|Release Management 2014Q3 Goals]].<br />
* Create and document process for Desktop/Mobile feature fast tracking<br />
* Determine future of ESR and how to manage this channel<br />
* Continue desktop throttling experiment with intention of reducing throttled time while maintaining existing level of feedback<br />
* Improve release notes with revamped template for all products<br />
* Create B2G release model proposals and gather feedback for potential changes<br />
* Figure out what to do with B2G Security Releases<br />
<br />
===Program Management===<br />
<br />
See this wiki page for a full list of [https://wiki.mozilla.org/Program_Management/Firefox/2014-Q3-Goals Program Management goals].<br />
<br />
* Create a set of dashboards based on the ES database to track platform projects and surface bottlenecks.<br />
* Brown bag presentation/restropective on the agile processes we are using on Desktop and FirefoxOS.<br />
* Evaluate and produce a report on several tools for helping organize and visualize team backlogs and priority lists; wiki, spreadsheets, Trello, Kanbanize.</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q3Goals&diff=1002253SecurityEngineering/2014/Q3Goals2014-08-04T16:50:06Z<p>Sidstamm: /* Tracking Protection */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
(Also linked from [[Platform/2014-Q3-Goals#Security_.26_Privacy_Engineering]]).<br />
<br />
== Content Security ==<br />
;Outcome: Progress towards more robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid<br />
<br />
* {{ok|Gecko Security Hooks: Finish code and debugging for New Channel API, start getting reviews}} (dri=tanvi)<br />
* {{ok|Gecko Security Hooks: Create plan for addon compatibility}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central}} (dri=sstamm)<br />
* {{new|Evangelism: Security Open Mic presentation + blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs}} ([https://etherpad.mozilla.org/CSP-1-1 planning etherpad])(dri=ckerschb)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Monica, Garrett, Sid, Georgios<br />
<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help}} (dri=sstamm)<br />
* {{done|Land backend and bridge code for first implementation of protection in Fx 33/34 off by default.}} (dri=mmc)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks.<br />
;Who: Richard, Kathleen, Keeler, Camilo, Harsh, Garrett, Monica<br />
<br />
* {{ok|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok|HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{ok| Update roadmap for Cert Revocation improvements}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{ok| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{ok| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{risk| ''[stretch goal]'' Enable revocation of intermediate CAs through block list service}} (dri=harsh, keeler)<br />
* {{ok| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
* {{ok| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=Platform/2014-08-05&diff=1002252Platform/2014-08-052014-08-04T16:49:30Z<p>Sidstamm: /* Seceng (grobinson) */</p>
<hr />
<div><!-- Maybe don't screw with these links unless you've read this blog post:<br />
http://blog.johnath.com/2011/01/20/automatic-date-links-in-mediawiki/<br />
Just copy them to new pages and it should Just Work!<br />
--><br />
<br />
<small>[[Platform/{{#time: Y-m-d | {{SUBPAGENAME}} -1 week}}|&laquo; previous week]] | [[Platform|index]] | [[Platform/{{#time: Y-m-d | {{SUBPAGENAME}} +1 week}}|next week &raquo;]]</small><br />
<br />
<div class="h-event vevent"><br />
'''<span class="p-summary summary">Engineering Meeting</span> Details'''<br />
* <span class="dt-start dtstart">Tuesday <span class="value">{{#time: Y-m-d | {{SUBPAGENAME}} }}</span> - <span class="value">11:00</span> am <abbr class="value" title="-0800">Pacific Standard Time</abbr></span><br />
{{conf|98411}}<br />
* <span class="location">[https://v.mozilla.com/flex.html?roomdirect.html&key=T2v8Pi8WuTRc Engineering Vidyo Room] / [https://air.mozilla.org/ Air Mozilla] / MTV Alien Nation / TOR Finch / SFO Warfield / PDX Hair of the Dog</span><br />
* join irc.mozilla.org [irc://irc.mozilla.org/planning #planning] for back channel<br />
</div><br />
<br />
==Need To Know==<br />
<small>(Release and system issues that may impact engineering this week.)</small><br />
<br />
===Notices/Schedule (lsblakk/sylvestre)===<br />
{| class="wikitable" style="color:green; background-color:#ffffcc;" cellpadding="10" padding="5"<br />
|-<br />
|colspan="2"|<big>Next Merge:</big> '''{{FIREFOX_MERGE_DATE}}'''<br />
|colspan="2"|<big>Next Release:</big> '''{{FIREFOX_SHIP_DATE}}'''<br />
|-<br />
!colspan="4" style="color:black;"|Trains<br />
|-<br />
|Central: {{CENTRAL_VERSION}} <br />
|Aurora: {{AURORA_VERSION}} <br />
|Beta: {{BETA_VERSION}} <br />
|Release: {{RELEASE_VERSION}}<br />
|}<br />
<br />
<br />
===Build Changes (gps)===<br />
<small>(Build changes of which engineers should be aware.)</small><br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===RelEng (catlee)===<br />
<small>(Repo, test, and other information for engineers from the release engineering team.)</small><br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Upcoming Outages/Upgrades===<br />
<small>(System outages/upgrades and tree closures that impact engineering.)</small><br />
<br />
==Quality Programs==<br />
<small>(An opportunity to hear about status with the various quality programs that do not have a formal team structure.)</small><br />
<br />
===OrangeFactor (ryanvm)===<br />
<br />
===CritSmash (dbolter)===<br />
<br />
===MemShrink (njn)===<br />
* B2G: Ghislain Aus Lacroix changed some backgrounds that used subtle radial gradients to instead use solid colour, saving around 2.5 MiB of memory.<br />
<br />
===Stability (kairo/bsmedberg)===<br />
<br />
==Team Stand-ups==<br />
<small>(In <2 mins, what did your team accomplish last week, on what is your team working on this week, and on what, if anything, is your team blocked? No questions during the stand-ups. All questions should be asked during the roundtable.)</small><br />
<br />
===A*Team (jgriffin)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Accessibility (dbolter)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===App Tools (prouget)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===B2G Services (dougt)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Cloud Services (mmayo)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Developer Tools (robcee)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===DOM (jst/overholt)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
* The DOM module now has a new peer! The new peer is Andrea Marchesini (baku) who's made a ton of amazing contributions to the DOM in the past couple of years!<br />
<br />
===Electrolysis (e10s) (blassey)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox Desktop (gavin)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox Mobile (mfinkle/blassey)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Communications (scravag)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Connectivity (vchang)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Devices/Porting (ericchou)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Media (slee)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Media Apps (hema)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Media Recording(pchang)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Performance (mlee)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Productivity (doliver)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS RIL (htsai)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Systems - Front End (gwagner)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Firefox OS Systems - Platform (timdream)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===GFX (milan)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===JS (naveed)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Layout (jet/dbaron)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Media (mreavy)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Necko (dougt/jduell)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Performance (vladan)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===Seceng (grobinson)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
{{readonly}}<br />
<br />
* Old JS implementation of CSP has been removed from mozilla-central ({{bug|994782}})<br />
** Should not affect anything (it was off by default), but it's gone now! woo!<br />
<br />
===Shumway (tschneidereit)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
===WebAPI (overholt)===<br />
<!-- Read only update this week? Uncomment the following line--><br />
<!-- {{readonly}} --><br />
<br />
==Roundtable==<br />
<small>(Comments and questions that arise during the course of the meeting or otherwise do not have a section.)</small><br />
<br />
==<Read only beyond this point>==<br />
<br />
===Friends of the Tree===<br />
<br />
===Mailing List Threads===<br />
<small>(Threads that are likely to be of interest to engineering from various mailing lists.)</small><br />
<br />
===Good Reads===<br />
<small>(Links to blog posts, books, videos, etc. that you think will be of interest to others.)</small><br />
<br />
===irc #planning Log From This Meeting===<br />
<pre style="white-space:pre-wrap;"><br />
</pre></div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q3Goals&diff=1002250SecurityEngineering/2014/Q3Goals2014-08-04T16:44:13Z<p>Sidstamm: /* Communications Security */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
(Also linked from [[Platform/2014-Q3-Goals#Security_.26_Privacy_Engineering]]).<br />
<br />
== Content Security ==<br />
;Outcome: Progress towards more robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid<br />
<br />
* {{ok|Gecko Security Hooks: Finish code and debugging for New Channel API, start getting reviews}} (dri=tanvi)<br />
* {{ok|Gecko Security Hooks: Create plan for addon compatibility}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central}} (dri=sstamm)<br />
* {{new|Evangelism: Security Open Mic presentation + blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs}} ([https://etherpad.mozilla.org/CSP-1-1 planning etherpad])(dri=ckerschb)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Monica, Garrett, Sid, Georgios<br />
<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help}} (dri=sstamm)<br />
* {{new|Land first implementation of protection in Fx 33/34 off by default.}} (dri=mmc)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks.<br />
;Who: Richard, Kathleen, Keeler, Camilo, Harsh, Garrett, Monica<br />
<br />
* {{ok|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{ok|HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{ok| Update roadmap for Cert Revocation improvements}} (dri=rbarnes)<br />
* {{done| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{ok| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{ok| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{ok| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{risk| ''[stretch goal]'' Enable revocation of intermediate CAs through block list service}} (dri=harsh, keeler)<br />
* {{ok| ''[stretch goal]'' Retire first batch of 1024-bit roots, working towards requiring 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
* {{ok| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q3Goals&diff=1002249SecurityEngineering/2014/Q3Goals2014-08-04T16:38:32Z<p>Sidstamm: /* Tracking Protection */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
(Also linked from [[Platform/2014-Q3-Goals#Security_.26_Privacy_Engineering]]).<br />
<br />
== Content Security ==<br />
;Outcome: Progress towards more robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid<br />
<br />
* {{ok|Gecko Security Hooks: Finish code and debugging for New Channel API, start getting reviews}} (dri=tanvi)<br />
* {{ok|Gecko Security Hooks: Create plan for addon compatibility}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central}} (dri=sstamm)<br />
* {{new|Evangelism: Security Open Mic presentation + blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs}} ([https://etherpad.mozilla.org/CSP-1-1 planning etherpad])(dri=ckerschb)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Monica, Garrett, Sid, Georgios<br />
<br />
* {{ok|Referer: Finish implementation of <meta> referrer control with volunteer help}} (dri=sstamm)<br />
* {{new|Land first implementation of protection in Fx 33/34 off by default.}} (dri=mmc)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks.<br />
;Who: Richard, Kathleen, Keeler, Camilo, Harsh, Garrett, Monica<br />
<br />
* {{prev|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{new|HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{new| Update roadmap for Cert Revocation improvements}} (dri=rbarnes)<br />
* {{new| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{new| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{new| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{new| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{new| ''[stretch goal]'' Enable revocation of intermediate CAs through block list service}} (dri=harsh, keeler)<br />
* {{new| ''[stretch goal]'' Require 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
* {{new| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=SecurityEngineering/2014/Q3Goals&diff=1002248SecurityEngineering/2014/Q3Goals2014-08-04T16:38:18Z<p>Sidstamm: /* Content Security */</p>
<hr />
<div>__NOTOC__<br />
<br />
This is a heavy-Implement quarter (as opposed to the other strategic actions in our [[SecurityEngineering/Strategy]]).<br />
<br />
(Also linked from [[Platform/2014-Q3-Goals#Security_.26_Privacy_Engineering]]).<br />
<br />
== Content Security ==<br />
;Outcome: Progress towards more robust security hooks for better correctness in content security features like CSP, adblock, etc.<br />
;Who: Tanvi, Christoph, Garrett, Sid<br />
<br />
* {{ok|Gecko Security Hooks: Finish code and debugging for New Channel API, start getting reviews}} (dri=tanvi)<br />
* {{ok|Gecko Security Hooks: Create plan for addon compatibility}} (dri=tanvi)<br />
* {{done|CSP: Remove old JS implementation from mozilla-central}} (dri=sstamm)<br />
* {{new|Evangelism: Security Open Mic presentation + blog post about new CSP implementation, maybe again as brown bag.}} (dri=sstamm)<br />
* {{ok|''[stretch goal]'' CSP: Fix majority of CSP 1.1 compatibility bugs}} ([https://etherpad.mozilla.org/CSP-1-1 planning etherpad])(dri=ckerschb)<br />
<br />
== Tracking Protection ==<br />
;Outcome: Better user control (and site control) over metadata on the wire and collected by third parties.<br />
;Who: Monica, Garrett, Sid, Georgios<br />
<br />
* {{new|Referer: Finish implementation of <meta> referrer control with volunteer help}} (dri=sstamm)<br />
* {{new|Land first implementation of protection in Fx 33/34 off by default.}} (dri=mmc)<br />
<br />
== Communications Security ==<br />
;Outcome: Fresher/more accurate revocation information and progress towards defeating certificate misissuance and Man-In-The-Middle attacks.<br />
;Who: Richard, Kathleen, Keeler, Camilo, Harsh, Garrett, Monica<br />
<br />
* {{prev|SSL Error Reporting finish first implementation of ssl error reporting feature.}} (dri=grobinson)<br />
* {{new|HPKP - implement pinning http header}} (dri=cviecco)<br />
* {{new| Update roadmap for Cert Revocation improvements}} (dri=rbarnes)<br />
* {{new| Create a mechanism to provision phones with an alternate cert}} (dri=mgoodwin)<br />
* {{new| Add measurement/enforcement of compliance with CABF Baseline Requirements}} (dri=keeler)<br />
* {{new| Create a tool for testing CA certificate compliance and EV-readiness}} (dri=keeler)<br />
* {{new| Add support for key wrap/unwrap and ECC in WebCrypto}} (dri=rbarnes)<br />
* {{new| ''[stretch goal]'' Enable revocation of intermediate CAs through block list service}} (dri=harsh, keeler)<br />
* {{new| ''[stretch goal]'' Require 2048-bit keys for built-in root certificates}} (dri=kathleen)<br />
* {{new| ''[stretch goal]'' Get CA Program data into one database}} (dri=kathleen)</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997906User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:56:26Z<p>Sidstamm: </p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
My high-level thoughts:<br />
* People can't agree on how to best segment users based on privacy needs/preferences/etc.<br />
* Social network privacy controls are hard to use<br />
* Psychologists are just starting to get into this space<br />
* Security and privacy are still not usable.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
"Whenever possible, secure system designers should find ways of keeping humans out of the loop" (Lorrie Cranor)<br />
<br />
Examples: Windows Update with default auto-updating (XP SP2 and later)<br />
<br />
The researchers did a survey then examined computer logs. They matched the log data with the survey and interview data.<br />
<br />
People misunderstand updates. 2/3 did not know that auto updates were on (or thought they were but were wrong). Many thought windows update was just advising them that updates were available, not that they were installed.<br />
<br />
When removing people from decision making, peoples' misunderstanding of what happens increases. This is because we tend to remove the easy decisions and leave the hard decisions (like "do you want to accept this cert?"). Thus, amateur security is harder and people end up either wrong or experts.<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
Are attention attractors subject to habituation? (Attention attractors help people identify and focus on the important bits of a warning/dialog, such as a pulsing arrow, forcing them to interact, etc.)<br />
<br />
There's lots of literature that observes habituation especially with security warnings.<br />
<br />
Goal: Good attractors are not subject to habituation and should not lose effectiveness after many exposures.<br />
<br />
They did a mechanical turk study.<br />
<br />
Results: Some attractors (the interactive ones like "type this" or "highlight this") were not subject to habituation.<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
They used statistical pattern recognition for touch-based authentication.<br />
<br />
This is more than circuits, passwords, pins, swipe, etc, they were looking for patterns of use during regular mobile device activity. Touch data comes from many operations and many apps. <br />
<br />
They did a 21 day study examining universiality, collectability, distinctness and permanence of touch biometrics.<br />
<br />
Permanence was low: not stable matching over time since people change their use patterns, have sore hands, moods change, etc. <br />
<br />
To get over permanence change, they continued training the model while it was in use and that was more stable.<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
Similar to the PPS workshop (day 1, see above).<br />
<br />
They downloaded 108,000 apps and reversed them to see what permissions they used (versus the ones they asked for in the store). They also identified *why* the permissions were used. Turns out most permissions are for third party libraries:<br />
* Targeted ads<br />
* Social networks<br />
* Mobile os analytics<br />
<br />
They asked for users' comfort with sets of (app name, permission, purpose). Users are generally fine when location is used for an app's central purpose, but not for those third-party libraries.<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
Shoulder Surfing!<br />
<br />
How, why, when do people use lock screens? Is Shoulder Surfing a problem?<br />
<br />
They did a survey and field study. The survey results are in the paper. Field study was discussed in the talk (is also in the paper).<br />
<br />
They logged data for 27 days. Monitored activation/unlock behaviors. (Activation is interaction without unlocking.)<br />
<br />
Asked a brief question after each unlock.<br />
<br />
Average session: 70s (activations) or 104s (unlocks)<br />
Average phone usage is 43 hours over 27 days.<br />
Spent 1.2 hours unlocking during the 27 days.<br />
<br />
Most unlocks happen in "private" contexts. Proportion of sensitive data is low for most users, their worry is low.<br />
<br />
Shoulder surfing:<br />
* Possible in 17% of scenarios<br />
* Likely in 41% and critical in 19% of cases <br />
* Mostly happens in private contexts and involving people the phone's owner knows.<br />
<br />
Takeaways:<br />
* We should use context info to decide if locking/unlocking is necessary.<br />
* Locks should be at the app level to reduce frequency of unlocking<br />
* Shoulder surfing risks are perceived low by users.<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
Psychometrics: ability, mood, etc.<br />
Reliability and validity of these measures is key.<br />
Want people to be comfortable constructing a good password.<br />
<br />
Not sure of the takeaways for this talk. Turns out Apple iOS is most "comfortable" for users.<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
People have coping strategies for so many passwords:<br />
* Password managers<br />
* Password reuse<br />
<br />
These authors interviewed 27 people. They did qualitative analysis using grounded theory. They found 66 patterns in peoples' responses such as "records passwords as backup strategy". They used GT to identify connections between patterns.<br />
<br />
* Some people used frequency-based passwords (PW_A for frequently used sites, PW_B for others)<br />
* Many people had a main password<br />
* People write their passwords down<br />
* People use passwords for a very long time.<br />
<br />
Rationing: common theme is that people spend more effort creating good passwords for important accounts and reduce their willingness to spend effort on other sites.<br />
<br />
Users do not differentiate easily between different scenarios that call for different passwords. (Surprise, they suck at threat modeling.)<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
Partition sharing into two groups:<br />
* Public (picture of a field of daffodils)<br />
* Private (beer hoarding picture)<br />
<br />
This work addresses only private sharing.<br />
<br />
Right now users are assumed to employ SACLs manually to control access. Other work on this proposes lots of things like automatic group detection.<br />
<br />
So far, there's no validation that people actually use the SACLs they create or if they do, how.<br />
<br />
Authors created an app called Friendlist Manager and got consent to access users' data. 67% of users used at least one SACL.<br />
<br />
But most SACLs don't correlate with the auto created groups they tried.<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==<br />
These authors want to limit large-scale infiltration attacks (getting into peoples' networks when you're not supposed to).<br />
<br />
First, they wanted to understand why people are willing to accept requests.<br />
* Mainly based on picture, name and knowing the person in real life.<br />
* This suggests UI changes for presenting friend requests to people. Emphasize the things that are most useful.<br />
<br />
= Final Panel =<br />
I didn't take notes on this but there are a few things I remember:<br />
* Software has trouble determining intent, so it gives up and has to ask a user. Can we determine intent so we don't need to ask?<br />
* According to a panelist, MS SmartScreen is collecting certs</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997905User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:54:16Z<p>Sidstamm: /* Final Panel */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
"Whenever possible, secure system designers should find ways of keeping humans out of the loop" (Lorrie Cranor)<br />
<br />
Examples: Windows Update with default auto-updating (XP SP2 and later)<br />
<br />
The researchers did a survey then examined computer logs. They matched the log data with the survey and interview data.<br />
<br />
People misunderstand updates. 2/3 did not know that auto updates were on (or thought they were but were wrong). Many thought windows update was just advising them that updates were available, not that they were installed.<br />
<br />
When removing people from decision making, peoples' misunderstanding of what happens increases. This is because we tend to remove the easy decisions and leave the hard decisions (like "do you want to accept this cert?"). Thus, amateur security is harder and people end up either wrong or experts.<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
Are attention attractors subject to habituation? (Attention attractors help people identify and focus on the important bits of a warning/dialog, such as a pulsing arrow, forcing them to interact, etc.)<br />
<br />
There's lots of literature that observes habituation especially with security warnings.<br />
<br />
Goal: Good attractors are not subject to habituation and should not lose effectiveness after many exposures.<br />
<br />
They did a mechanical turk study.<br />
<br />
Results: Some attractors (the interactive ones like "type this" or "highlight this") were not subject to habituation.<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
They used statistical pattern recognition for touch-based authentication.<br />
<br />
This is more than circuits, passwords, pins, swipe, etc, they were looking for patterns of use during regular mobile device activity. Touch data comes from many operations and many apps. <br />
<br />
They did a 21 day study examining universiality, collectability, distinctness and permanence of touch biometrics.<br />
<br />
Permanence was low: not stable matching over time since people change their use patterns, have sore hands, moods change, etc. <br />
<br />
To get over permanence change, they continued training the model while it was in use and that was more stable.<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
Similar to the PPS workshop (day 1, see above).<br />
<br />
They downloaded 108,000 apps and reversed them to see what permissions they used (versus the ones they asked for in the store). They also identified *why* the permissions were used. Turns out most permissions are for third party libraries:<br />
* Targeted ads<br />
* Social networks<br />
* Mobile os analytics<br />
<br />
They asked for users' comfort with sets of (app name, permission, purpose). Users are generally fine when location is used for an app's central purpose, but not for those third-party libraries.<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
Shoulder Surfing!<br />
<br />
How, why, when do people use lock screens? Is Shoulder Surfing a problem?<br />
<br />
They did a survey and field study. The survey results are in the paper. Field study was discussed in the talk (is also in the paper).<br />
<br />
They logged data for 27 days. Monitored activation/unlock behaviors. (Activation is interaction without unlocking.)<br />
<br />
Asked a brief question after each unlock.<br />
<br />
Average session: 70s (activations) or 104s (unlocks)<br />
Average phone usage is 43 hours over 27 days.<br />
Spent 1.2 hours unlocking during the 27 days.<br />
<br />
Most unlocks happen in "private" contexts. Proportion of sensitive data is low for most users, their worry is low.<br />
<br />
Shoulder surfing:<br />
* Possible in 17% of scenarios<br />
* Likely in 41% and critical in 19% of cases <br />
* Mostly happens in private contexts and involving people the phone's owner knows.<br />
<br />
Takeaways:<br />
* We should use context info to decide if locking/unlocking is necessary.<br />
* Locks should be at the app level to reduce frequency of unlocking<br />
* Shoulder surfing risks are perceived low by users.<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
Psychometrics: ability, mood, etc.<br />
Reliability and validity of these measures is key.<br />
Want people to be comfortable constructing a good password.<br />
<br />
Not sure of the takeaways for this talk. Turns out Apple iOS is most "comfortable" for users.<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
People have coping strategies for so many passwords:<br />
* Password managers<br />
* Password reuse<br />
<br />
These authors interviewed 27 people. They did qualitative analysis using grounded theory. They found 66 patterns in peoples' responses such as "records passwords as backup strategy". They used GT to identify connections between patterns.<br />
<br />
* Some people used frequency-based passwords (PW_A for frequently used sites, PW_B for others)<br />
* Many people had a main password<br />
* People write their passwords down<br />
* People use passwords for a very long time.<br />
<br />
Rationing: common theme is that people spend more effort creating good passwords for important accounts and reduce their willingness to spend effort on other sites.<br />
<br />
Users do not differentiate easily between different scenarios that call for different passwords. (Surprise, they suck at threat modeling.)<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
Partition sharing into two groups:<br />
* Public (picture of a field of daffodils)<br />
* Private (beer hoarding picture)<br />
<br />
This work addresses only private sharing.<br />
<br />
Right now users are assumed to employ SACLs manually to control access. Other work on this proposes lots of things like automatic group detection.<br />
<br />
So far, there's no validation that people actually use the SACLs they create or if they do, how.<br />
<br />
Authors created an app called Friendlist Manager and got consent to access users' data. 67% of users used at least one SACL.<br />
<br />
But most SACLs don't correlate with the auto created groups they tried.<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==<br />
These authors want to limit large-scale infiltration attacks (getting into peoples' networks when you're not supposed to).<br />
<br />
First, they wanted to understand why people are willing to accept requests.<br />
* Mainly based on picture, name and knowing the person in real life.<br />
* This suggests UI changes for presenting friend requests to people. Emphasize the things that are most useful.<br />
<br />
= Final Panel =<br />
I didn't take notes on this but there are a few things I remember:<br />
* Software has trouble determining intent, so it gives up and has to ask a user. Can we determine intent so we don't need to ask?<br />
* According to a panelist, MS SmartScreen is collecting certs</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997904User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:53:49Z<p>Sidstamm: /* Hootan Rashtian: To befriend or not? friend request acceptance model on facebook */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
"Whenever possible, secure system designers should find ways of keeping humans out of the loop" (Lorrie Cranor)<br />
<br />
Examples: Windows Update with default auto-updating (XP SP2 and later)<br />
<br />
The researchers did a survey then examined computer logs. They matched the log data with the survey and interview data.<br />
<br />
People misunderstand updates. 2/3 did not know that auto updates were on (or thought they were but were wrong). Many thought windows update was just advising them that updates were available, not that they were installed.<br />
<br />
When removing people from decision making, peoples' misunderstanding of what happens increases. This is because we tend to remove the easy decisions and leave the hard decisions (like "do you want to accept this cert?"). Thus, amateur security is harder and people end up either wrong or experts.<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
Are attention attractors subject to habituation? (Attention attractors help people identify and focus on the important bits of a warning/dialog, such as a pulsing arrow, forcing them to interact, etc.)<br />
<br />
There's lots of literature that observes habituation especially with security warnings.<br />
<br />
Goal: Good attractors are not subject to habituation and should not lose effectiveness after many exposures.<br />
<br />
They did a mechanical turk study.<br />
<br />
Results: Some attractors (the interactive ones like "type this" or "highlight this") were not subject to habituation.<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
They used statistical pattern recognition for touch-based authentication.<br />
<br />
This is more than circuits, passwords, pins, swipe, etc, they were looking for patterns of use during regular mobile device activity. Touch data comes from many operations and many apps. <br />
<br />
They did a 21 day study examining universiality, collectability, distinctness and permanence of touch biometrics.<br />
<br />
Permanence was low: not stable matching over time since people change their use patterns, have sore hands, moods change, etc. <br />
<br />
To get over permanence change, they continued training the model while it was in use and that was more stable.<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
Similar to the PPS workshop (day 1, see above).<br />
<br />
They downloaded 108,000 apps and reversed them to see what permissions they used (versus the ones they asked for in the store). They also identified *why* the permissions were used. Turns out most permissions are for third party libraries:<br />
* Targeted ads<br />
* Social networks<br />
* Mobile os analytics<br />
<br />
They asked for users' comfort with sets of (app name, permission, purpose). Users are generally fine when location is used for an app's central purpose, but not for those third-party libraries.<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
Shoulder Surfing!<br />
<br />
How, why, when do people use lock screens? Is Shoulder Surfing a problem?<br />
<br />
They did a survey and field study. The survey results are in the paper. Field study was discussed in the talk (is also in the paper).<br />
<br />
They logged data for 27 days. Monitored activation/unlock behaviors. (Activation is interaction without unlocking.)<br />
<br />
Asked a brief question after each unlock.<br />
<br />
Average session: 70s (activations) or 104s (unlocks)<br />
Average phone usage is 43 hours over 27 days.<br />
Spent 1.2 hours unlocking during the 27 days.<br />
<br />
Most unlocks happen in "private" contexts. Proportion of sensitive data is low for most users, their worry is low.<br />
<br />
Shoulder surfing:<br />
* Possible in 17% of scenarios<br />
* Likely in 41% and critical in 19% of cases <br />
* Mostly happens in private contexts and involving people the phone's owner knows.<br />
<br />
Takeaways:<br />
* We should use context info to decide if locking/unlocking is necessary.<br />
* Locks should be at the app level to reduce frequency of unlocking<br />
* Shoulder surfing risks are perceived low by users.<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
Psychometrics: ability, mood, etc.<br />
Reliability and validity of these measures is key.<br />
Want people to be comfortable constructing a good password.<br />
<br />
Not sure of the takeaways for this talk. Turns out Apple iOS is most "comfortable" for users.<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
People have coping strategies for so many passwords:<br />
* Password managers<br />
* Password reuse<br />
<br />
These authors interviewed 27 people. They did qualitative analysis using grounded theory. They found 66 patterns in peoples' responses such as "records passwords as backup strategy". They used GT to identify connections between patterns.<br />
<br />
* Some people used frequency-based passwords (PW_A for frequently used sites, PW_B for others)<br />
* Many people had a main password<br />
* People write their passwords down<br />
* People use passwords for a very long time.<br />
<br />
Rationing: common theme is that people spend more effort creating good passwords for important accounts and reduce their willingness to spend effort on other sites.<br />
<br />
Users do not differentiate easily between different scenarios that call for different passwords. (Surprise, they suck at threat modeling.)<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
Partition sharing into two groups:<br />
* Public (picture of a field of daffodils)<br />
* Private (beer hoarding picture)<br />
<br />
This work addresses only private sharing.<br />
<br />
Right now users are assumed to employ SACLs manually to control access. Other work on this proposes lots of things like automatic group detection.<br />
<br />
So far, there's no validation that people actually use the SACLs they create or if they do, how.<br />
<br />
Authors created an app called Friendlist Manager and got consent to access users' data. 67% of users used at least one SACL.<br />
<br />
But most SACLs don't correlate with the auto created groups they tried.<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==<br />
These authors want to limit large-scale infiltration attacks (getting into peoples' networks when you're not supposed to).<br />
<br />
First, they wanted to understand why people are willing to accept requests.<br />
* Mainly based on picture, name and knowing the person in real life.<br />
* This suggests UI changes for presenting friend requests to people. Emphasize the things that are most useful.<br />
<br />
== Final Panel ==<br />
I didn't take notes on this but there are a few things I remember:<br />
* Software has trouble determining intent, so it gives up and has to ask a user. Can we determine intent so we don't need to ask?<br />
* According to a panelist, MS SmartScreen is collecting certs</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997903User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:48:27Z<p>Sidstamm: /* Mainack Mondal: Social ACLs */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
"Whenever possible, secure system designers should find ways of keeping humans out of the loop" (Lorrie Cranor)<br />
<br />
Examples: Windows Update with default auto-updating (XP SP2 and later)<br />
<br />
The researchers did a survey then examined computer logs. They matched the log data with the survey and interview data.<br />
<br />
People misunderstand updates. 2/3 did not know that auto updates were on (or thought they were but were wrong). Many thought windows update was just advising them that updates were available, not that they were installed.<br />
<br />
When removing people from decision making, peoples' misunderstanding of what happens increases. This is because we tend to remove the easy decisions and leave the hard decisions (like "do you want to accept this cert?"). Thus, amateur security is harder and people end up either wrong or experts.<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
Are attention attractors subject to habituation? (Attention attractors help people identify and focus on the important bits of a warning/dialog, such as a pulsing arrow, forcing them to interact, etc.)<br />
<br />
There's lots of literature that observes habituation especially with security warnings.<br />
<br />
Goal: Good attractors are not subject to habituation and should not lose effectiveness after many exposures.<br />
<br />
They did a mechanical turk study.<br />
<br />
Results: Some attractors (the interactive ones like "type this" or "highlight this") were not subject to habituation.<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
They used statistical pattern recognition for touch-based authentication.<br />
<br />
This is more than circuits, passwords, pins, swipe, etc, they were looking for patterns of use during regular mobile device activity. Touch data comes from many operations and many apps. <br />
<br />
They did a 21 day study examining universiality, collectability, distinctness and permanence of touch biometrics.<br />
<br />
Permanence was low: not stable matching over time since people change their use patterns, have sore hands, moods change, etc. <br />
<br />
To get over permanence change, they continued training the model while it was in use and that was more stable.<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
Similar to the PPS workshop (day 1, see above).<br />
<br />
They downloaded 108,000 apps and reversed them to see what permissions they used (versus the ones they asked for in the store). They also identified *why* the permissions were used. Turns out most permissions are for third party libraries:<br />
* Targeted ads<br />
* Social networks<br />
* Mobile os analytics<br />
<br />
They asked for users' comfort with sets of (app name, permission, purpose). Users are generally fine when location is used for an app's central purpose, but not for those third-party libraries.<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
Shoulder Surfing!<br />
<br />
How, why, when do people use lock screens? Is Shoulder Surfing a problem?<br />
<br />
They did a survey and field study. The survey results are in the paper. Field study was discussed in the talk (is also in the paper).<br />
<br />
They logged data for 27 days. Monitored activation/unlock behaviors. (Activation is interaction without unlocking.)<br />
<br />
Asked a brief question after each unlock.<br />
<br />
Average session: 70s (activations) or 104s (unlocks)<br />
Average phone usage is 43 hours over 27 days.<br />
Spent 1.2 hours unlocking during the 27 days.<br />
<br />
Most unlocks happen in "private" contexts. Proportion of sensitive data is low for most users, their worry is low.<br />
<br />
Shoulder surfing:<br />
* Possible in 17% of scenarios<br />
* Likely in 41% and critical in 19% of cases <br />
* Mostly happens in private contexts and involving people the phone's owner knows.<br />
<br />
Takeaways:<br />
* We should use context info to decide if locking/unlocking is necessary.<br />
* Locks should be at the app level to reduce frequency of unlocking<br />
* Shoulder surfing risks are perceived low by users.<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
Psychometrics: ability, mood, etc.<br />
Reliability and validity of these measures is key.<br />
Want people to be comfortable constructing a good password.<br />
<br />
Not sure of the takeaways for this talk. Turns out Apple iOS is most "comfortable" for users.<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
People have coping strategies for so many passwords:<br />
* Password managers<br />
* Password reuse<br />
<br />
These authors interviewed 27 people. They did qualitative analysis using grounded theory. They found 66 patterns in peoples' responses such as "records passwords as backup strategy". They used GT to identify connections between patterns.<br />
<br />
* Some people used frequency-based passwords (PW_A for frequently used sites, PW_B for others)<br />
* Many people had a main password<br />
* People write their passwords down<br />
* People use passwords for a very long time.<br />
<br />
Rationing: common theme is that people spend more effort creating good passwords for important accounts and reduce their willingness to spend effort on other sites.<br />
<br />
Users do not differentiate easily between different scenarios that call for different passwords. (Surprise, they suck at threat modeling.)<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
Partition sharing into two groups:<br />
* Public (picture of a field of daffodils)<br />
* Private (beer hoarding picture)<br />
<br />
This work addresses only private sharing.<br />
<br />
Right now users are assumed to employ SACLs manually to control access. Other work on this proposes lots of things like automatic group detection.<br />
<br />
So far, there's no validation that people actually use the SACLs they create or if they do, how.<br />
<br />
Authors created an app called Friendlist Manager and got consent to access users' data. 67% of users used at least one SACL.<br />
<br />
But most SACLs don't correlate with the auto created groups they tried.<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997900User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:46:06Z<p>Sidstamm: /* Elizabeth Stobert: The password life cycle, user behavior in managing passwords */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
"Whenever possible, secure system designers should find ways of keeping humans out of the loop" (Lorrie Cranor)<br />
<br />
Examples: Windows Update with default auto-updating (XP SP2 and later)<br />
<br />
The researchers did a survey then examined computer logs. They matched the log data with the survey and interview data.<br />
<br />
People misunderstand updates. 2/3 did not know that auto updates were on (or thought they were but were wrong). Many thought windows update was just advising them that updates were available, not that they were installed.<br />
<br />
When removing people from decision making, peoples' misunderstanding of what happens increases. This is because we tend to remove the easy decisions and leave the hard decisions (like "do you want to accept this cert?"). Thus, amateur security is harder and people end up either wrong or experts.<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
Are attention attractors subject to habituation? (Attention attractors help people identify and focus on the important bits of a warning/dialog, such as a pulsing arrow, forcing them to interact, etc.)<br />
<br />
There's lots of literature that observes habituation especially with security warnings.<br />
<br />
Goal: Good attractors are not subject to habituation and should not lose effectiveness after many exposures.<br />
<br />
They did a mechanical turk study.<br />
<br />
Results: Some attractors (the interactive ones like "type this" or "highlight this") were not subject to habituation.<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
They used statistical pattern recognition for touch-based authentication.<br />
<br />
This is more than circuits, passwords, pins, swipe, etc, they were looking for patterns of use during regular mobile device activity. Touch data comes from many operations and many apps. <br />
<br />
They did a 21 day study examining universiality, collectability, distinctness and permanence of touch biometrics.<br />
<br />
Permanence was low: not stable matching over time since people change their use patterns, have sore hands, moods change, etc. <br />
<br />
To get over permanence change, they continued training the model while it was in use and that was more stable.<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
Similar to the PPS workshop (day 1, see above).<br />
<br />
They downloaded 108,000 apps and reversed them to see what permissions they used (versus the ones they asked for in the store). They also identified *why* the permissions were used. Turns out most permissions are for third party libraries:<br />
* Targeted ads<br />
* Social networks<br />
* Mobile os analytics<br />
<br />
They asked for users' comfort with sets of (app name, permission, purpose). Users are generally fine when location is used for an app's central purpose, but not for those third-party libraries.<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
Shoulder Surfing!<br />
<br />
How, why, when do people use lock screens? Is Shoulder Surfing a problem?<br />
<br />
They did a survey and field study. The survey results are in the paper. Field study was discussed in the talk (is also in the paper).<br />
<br />
They logged data for 27 days. Monitored activation/unlock behaviors. (Activation is interaction without unlocking.)<br />
<br />
Asked a brief question after each unlock.<br />
<br />
Average session: 70s (activations) or 104s (unlocks)<br />
Average phone usage is 43 hours over 27 days.<br />
Spent 1.2 hours unlocking during the 27 days.<br />
<br />
Most unlocks happen in "private" contexts. Proportion of sensitive data is low for most users, their worry is low.<br />
<br />
Shoulder surfing:<br />
* Possible in 17% of scenarios<br />
* Likely in 41% and critical in 19% of cases <br />
* Mostly happens in private contexts and involving people the phone's owner knows.<br />
<br />
Takeaways:<br />
* We should use context info to decide if locking/unlocking is necessary.<br />
* Locks should be at the app level to reduce frequency of unlocking<br />
* Shoulder surfing risks are perceived low by users.<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
Psychometrics: ability, mood, etc.<br />
Reliability and validity of these measures is key.<br />
Want people to be comfortable constructing a good password.<br />
<br />
Not sure of the takeaways for this talk. Turns out Apple iOS is most "comfortable" for users.<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
People have coping strategies for so many passwords:<br />
* Password managers<br />
* Password reuse<br />
<br />
These authors interviewed 27 people. They did qualitative analysis using grounded theory. They found 66 patterns in peoples' responses such as "records passwords as backup strategy". They used GT to identify connections between patterns.<br />
<br />
* Some people used frequency-based passwords (PW_A for frequently used sites, PW_B for others)<br />
* Many people had a main password<br />
* People write their passwords down<br />
* People use passwords for a very long time.<br />
<br />
Rationing: common theme is that people spend more effort creating good passwords for important accounts and reduce their willingness to spend effort on other sites.<br />
<br />
Users do not differentiate easily between different scenarios that call for different passwords. (Surprise, they suck at threat modeling.)<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997895User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:42:29Z<p>Sidstamm: /* Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
"Whenever possible, secure system designers should find ways of keeping humans out of the loop" (Lorrie Cranor)<br />
<br />
Examples: Windows Update with default auto-updating (XP SP2 and later)<br />
<br />
The researchers did a survey then examined computer logs. They matched the log data with the survey and interview data.<br />
<br />
People misunderstand updates. 2/3 did not know that auto updates were on (or thought they were but were wrong). Many thought windows update was just advising them that updates were available, not that they were installed.<br />
<br />
When removing people from decision making, peoples' misunderstanding of what happens increases. This is because we tend to remove the easy decisions and leave the hard decisions (like "do you want to accept this cert?"). Thus, amateur security is harder and people end up either wrong or experts.<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
Are attention attractors subject to habituation? (Attention attractors help people identify and focus on the important bits of a warning/dialog, such as a pulsing arrow, forcing them to interact, etc.)<br />
<br />
There's lots of literature that observes habituation especially with security warnings.<br />
<br />
Goal: Good attractors are not subject to habituation and should not lose effectiveness after many exposures.<br />
<br />
They did a mechanical turk study.<br />
<br />
Results: Some attractors (the interactive ones like "type this" or "highlight this") were not subject to habituation.<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
They used statistical pattern recognition for touch-based authentication.<br />
<br />
This is more than circuits, passwords, pins, swipe, etc, they were looking for patterns of use during regular mobile device activity. Touch data comes from many operations and many apps. <br />
<br />
They did a 21 day study examining universiality, collectability, distinctness and permanence of touch biometrics.<br />
<br />
Permanence was low: not stable matching over time since people change their use patterns, have sore hands, moods change, etc. <br />
<br />
To get over permanence change, they continued training the model while it was in use and that was more stable.<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
Similar to the PPS workshop (day 1, see above).<br />
<br />
They downloaded 108,000 apps and reversed them to see what permissions they used (versus the ones they asked for in the store). They also identified *why* the permissions were used. Turns out most permissions are for third party libraries:<br />
* Targeted ads<br />
* Social networks<br />
* Mobile os analytics<br />
<br />
They asked for users' comfort with sets of (app name, permission, purpose). Users are generally fine when location is used for an app's central purpose, but not for those third-party libraries.<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
Shoulder Surfing!<br />
<br />
How, why, when do people use lock screens? Is Shoulder Surfing a problem?<br />
<br />
They did a survey and field study. The survey results are in the paper. Field study was discussed in the talk (is also in the paper).<br />
<br />
They logged data for 27 days. Monitored activation/unlock behaviors. (Activation is interaction without unlocking.)<br />
<br />
Asked a brief question after each unlock.<br />
<br />
Average session: 70s (activations) or 104s (unlocks)<br />
Average phone usage is 43 hours over 27 days.<br />
Spent 1.2 hours unlocking during the 27 days.<br />
<br />
Most unlocks happen in "private" contexts. Proportion of sensitive data is low for most users, their worry is low.<br />
<br />
Shoulder surfing:<br />
* Possible in 17% of scenarios<br />
* Likely in 41% and critical in 19% of cases <br />
* Mostly happens in private contexts and involving people the phone's owner knows.<br />
<br />
Takeaways:<br />
* We should use context info to decide if locking/unlocking is necessary.<br />
* Locks should be at the app level to reduce frequency of unlocking<br />
* Shoulder surfing risks are perceived low by users.<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
Psychometrics: ability, mood, etc.<br />
Reliability and validity of these measures is key.<br />
Want people to be comfortable constructing a good password.<br />
<br />
Not sure of the takeaways for this talk. Turns out Apple iOS is most "comfortable" for users.<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997894User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:41:19Z<p>Sidstamm: /* Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
"Whenever possible, secure system designers should find ways of keeping humans out of the loop" (Lorrie Cranor)<br />
<br />
Examples: Windows Update with default auto-updating (XP SP2 and later)<br />
<br />
The researchers did a survey then examined computer logs. They matched the log data with the survey and interview data.<br />
<br />
People misunderstand updates. 2/3 did not know that auto updates were on (or thought they were but were wrong). Many thought windows update was just advising them that updates were available, not that they were installed.<br />
<br />
When removing people from decision making, peoples' misunderstanding of what happens increases. This is because we tend to remove the easy decisions and leave the hard decisions (like "do you want to accept this cert?"). Thus, amateur security is harder and people end up either wrong or experts.<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
Are attention attractors subject to habituation? (Attention attractors help people identify and focus on the important bits of a warning/dialog, such as a pulsing arrow, forcing them to interact, etc.)<br />
<br />
There's lots of literature that observes habituation especially with security warnings.<br />
<br />
Goal: Good attractors are not subject to habituation and should not lose effectiveness after many exposures.<br />
<br />
They did a mechanical turk study.<br />
<br />
Results: Some attractors (the interactive ones like "type this" or "highlight this") were not subject to habituation.<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
They used statistical pattern recognition for touch-based authentication.<br />
<br />
This is more than circuits, passwords, pins, swipe, etc, they were looking for patterns of use during regular mobile device activity. Touch data comes from many operations and many apps. <br />
<br />
They did a 21 day study examining universiality, collectability, distinctness and permanence of touch biometrics.<br />
<br />
Permanence was low: not stable matching over time since people change their use patterns, have sore hands, moods change, etc. <br />
<br />
To get over permanence change, they continued training the model while it was in use and that was more stable.<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
Similar to the PPS workshop (day 1, see above).<br />
<br />
They downloaded 108,000 apps and reversed them to see what permissions they used (versus the ones they asked for in the store). They also identified *why* the permissions were used. Turns out most permissions are for third party libraries:<br />
* Targeted ads<br />
* Social networks<br />
* Mobile os analytics<br />
<br />
They asked for users' comfort with sets of (app name, permission, purpose). Users are generally fine when location is used for an app's central purpose, but not for those third-party libraries.<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
Shoulder Surfing!<br />
<br />
How, why, when do people use lock screens? Is Shoulder Surfing a problem?<br />
<br />
They did a survey and field study. The survey results are in the paper. Field study was discussed in the talk (is also in the paper).<br />
<br />
They logged data for 27 days. Monitored activation/unlock behaviors. (Activation is interaction without unlocking.)<br />
<br />
Asked a brief question after each unlock.<br />
<br />
Average session: 70s (activations) or 104s (unlocks)<br />
Average phone usage is 43 hours over 27 days.<br />
Spent 1.2 hours unlocking during the 27 days.<br />
<br />
Most unlocks happen in "private" contexts. Proportion of sensitive data is low for most users, their worry is low.<br />
<br />
Shoulder surfing:<br />
* Possible in 17% of scenarios<br />
* Likely in 41% and critical in 19% of cases <br />
* Mostly happens in private contexts and involving people the phone's owner knows.<br />
<br />
Takeaways:<br />
* We should use context info to decide if locking/unlocking is necessary.<br />
* Locks should be at the app level to reduce frequency of unlocking<br />
* Shoulder surfing risks are perceived low by users.<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997893User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:37:32Z<p>Sidstamm: /* Jialu Liu: Modeling users' mobile app privacy preferences */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
"Whenever possible, secure system designers should find ways of keeping humans out of the loop" (Lorrie Cranor)<br />
<br />
Examples: Windows Update with default auto-updating (XP SP2 and later)<br />
<br />
The researchers did a survey then examined computer logs. They matched the log data with the survey and interview data.<br />
<br />
People misunderstand updates. 2/3 did not know that auto updates were on (or thought they were but were wrong). Many thought windows update was just advising them that updates were available, not that they were installed.<br />
<br />
When removing people from decision making, peoples' misunderstanding of what happens increases. This is because we tend to remove the easy decisions and leave the hard decisions (like "do you want to accept this cert?"). Thus, amateur security is harder and people end up either wrong or experts.<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
Are attention attractors subject to habituation? (Attention attractors help people identify and focus on the important bits of a warning/dialog, such as a pulsing arrow, forcing them to interact, etc.)<br />
<br />
There's lots of literature that observes habituation especially with security warnings.<br />
<br />
Goal: Good attractors are not subject to habituation and should not lose effectiveness after many exposures.<br />
<br />
They did a mechanical turk study.<br />
<br />
Results: Some attractors (the interactive ones like "type this" or "highlight this") were not subject to habituation.<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
They used statistical pattern recognition for touch-based authentication.<br />
<br />
This is more than circuits, passwords, pins, swipe, etc, they were looking for patterns of use during regular mobile device activity. Touch data comes from many operations and many apps. <br />
<br />
They did a 21 day study examining universiality, collectability, distinctness and permanence of touch biometrics.<br />
<br />
Permanence was low: not stable matching over time since people change their use patterns, have sore hands, moods change, etc. <br />
<br />
To get over permanence change, they continued training the model while it was in use and that was more stable.<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
Similar to the PPS workshop (day 1, see above).<br />
<br />
They downloaded 108,000 apps and reversed them to see what permissions they used (versus the ones they asked for in the store). They also identified *why* the permissions were used. Turns out most permissions are for third party libraries:<br />
* Targeted ads<br />
* Social networks<br />
* Mobile os analytics<br />
<br />
They asked for users' comfort with sets of (app name, permission, purpose). Users are generally fine when location is used for an app's central purpose, but not for those third-party libraries.<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997892User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:35:52Z<p>Sidstamm: /* Hui Xu: Towards continuous and passive authentication via touch biometrics */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
"Whenever possible, secure system designers should find ways of keeping humans out of the loop" (Lorrie Cranor)<br />
<br />
Examples: Windows Update with default auto-updating (XP SP2 and later)<br />
<br />
The researchers did a survey then examined computer logs. They matched the log data with the survey and interview data.<br />
<br />
People misunderstand updates. 2/3 did not know that auto updates were on (or thought they were but were wrong). Many thought windows update was just advising them that updates were available, not that they were installed.<br />
<br />
When removing people from decision making, peoples' misunderstanding of what happens increases. This is because we tend to remove the easy decisions and leave the hard decisions (like "do you want to accept this cert?"). Thus, amateur security is harder and people end up either wrong or experts.<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
Are attention attractors subject to habituation? (Attention attractors help people identify and focus on the important bits of a warning/dialog, such as a pulsing arrow, forcing them to interact, etc.)<br />
<br />
There's lots of literature that observes habituation especially with security warnings.<br />
<br />
Goal: Good attractors are not subject to habituation and should not lose effectiveness after many exposures.<br />
<br />
They did a mechanical turk study.<br />
<br />
Results: Some attractors (the interactive ones like "type this" or "highlight this") were not subject to habituation.<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
They used statistical pattern recognition for touch-based authentication.<br />
<br />
This is more than circuits, passwords, pins, swipe, etc, they were looking for patterns of use during regular mobile device activity. Touch data comes from many operations and many apps. <br />
<br />
They did a 21 day study examining universiality, collectability, distinctness and permanence of touch biometrics.<br />
<br />
Permanence was low: not stable matching over time since people change their use patterns, have sore hands, moods change, etc. <br />
<br />
To get over permanence change, they continued training the model while it was in use and that was more stable.<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997890User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:33:27Z<p>Sidstamm: /* Saranga Komanduri: Revisiting popup fatigue */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
"Whenever possible, secure system designers should find ways of keeping humans out of the loop" (Lorrie Cranor)<br />
<br />
Examples: Windows Update with default auto-updating (XP SP2 and later)<br />
<br />
The researchers did a survey then examined computer logs. They matched the log data with the survey and interview data.<br />
<br />
People misunderstand updates. 2/3 did not know that auto updates were on (or thought they were but were wrong). Many thought windows update was just advising them that updates were available, not that they were installed.<br />
<br />
When removing people from decision making, peoples' misunderstanding of what happens increases. This is because we tend to remove the easy decisions and leave the hard decisions (like "do you want to accept this cert?"). Thus, amateur security is harder and people end up either wrong or experts.<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
Are attention attractors subject to habituation? (Attention attractors help people identify and focus on the important bits of a warning/dialog, such as a pulsing arrow, forcing them to interact, etc.)<br />
<br />
There's lots of literature that observes habituation especially with security warnings.<br />
<br />
Goal: Good attractors are not subject to habituation and should not lose effectiveness after many exposures.<br />
<br />
They did a mechanical turk study.<br />
<br />
Results: Some attractors (the interactive ones like "type this" or "highlight this") were not subject to habituation.<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997889User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:31:35Z<p>Sidstamm: /* Rick Wash: How automatic software updates introduce security problems */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
"Whenever possible, secure system designers should find ways of keeping humans out of the loop" (Lorrie Cranor)<br />
<br />
Examples: Windows Update with default auto-updating (XP SP2 and later)<br />
<br />
The researchers did a survey then examined computer logs. They matched the log data with the survey and interview data.<br />
<br />
People misunderstand updates. 2/3 did not know that auto updates were on (or thought they were but were wrong). Many thought windows update was just advising them that updates were available, not that they were installed.<br />
<br />
When removing people from decision making, peoples' misunderstanding of what happens increases. This is because we tend to remove the easy decisions and leave the hard decisions (like "do you want to accept this cert?"). Thus, amateur security is harder and people end up either wrong or experts.<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997888User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:28:10Z<p>Sidstamm: </p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997887User:Sidstamm/Notes July 2014 SOUPS2014-07-18T00:22:30Z<p>Sidstamm: /* Warnings And Decisions */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Day 2: SOUPS main track =<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
Decision making: Assessment -> Planning -> Action -> Evaluation<br />
<br />
Question: how do people feel ''after'' disclosure? (Evaluation) Hypothesis is that people don't get that far when playing around in social nets.<br />
<br />
The authors study how the number and structure of options affect individuals' attitudes towards situations and how satisfied they are with their decisions.<br />
<br />
There's a point where people experience a "too much choice" effect and don't feel as comfortable with their choices because there were too many options.<br />
<br />
The authors:<br />
# made a list of types of info to share (picture, address, name, friend count, etc)<br />
# grouped them by sensitivity type.<br />
# studied differences with two variables:<br />
#* number of groups (size one groups and size n/2 groups)<br />
#* composition of groups (homogeneous/same type of data vs heterogeneous/mixed data types in groups)<br />
<br />
Hypothesis was that:<br />
# more options (more groups) would lead to less satisfaction<br />
# heterogeneous grouping (different types of things together) would lead to less satisfaction<br />
<br />
They conducted a survey to measure satisfaction after users were presented with these interfaces.<br />
<br />
Turns out hypothesis 1 was confirmed (more options = less satisfaction) but hypothesis 2 was disproved (homogeneous groups were no better than heterogeneous groups).<br />
<br />
According to Stefan: This suggests that clinical depression in industrialized society is linked to "too much choice".<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997871User:Sidstamm/Notes July 2014 SOUPS2014-07-17T20:33:30Z<p>Sidstamm: /* Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Day 2: SOUPS main track =<br />
= Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program =<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change<br />
<br />
= Warnings And Decisions =<br />
== Stefan Korff: Too much choice==<br />
<br />
== Rick Wash: How automatic software updates introduce security problems ==<br />
<br />
== Saranga Komanduri: Revisiting popup fatigue ==<br />
<br />
= Mobile Security and Privacy =<br />
== Hui Xu: Towards continuous and passive authentication via touch biometrics ==<br />
<br />
== Jialu Liu: Modeling users' mobile app privacy preferences ==<br />
<br />
== Emanuel von Zezschwitz: Smartphone unlocking behavior and risk perception ==<br />
<br />
= Authentication =<br />
<br />
== Taiabul Haque: Applying psychometrics to measure user comfort when constructing a strong password ==<br />
<br />
== Elizabeth Stobert: The password life cycle, user behavior in managing passwords ==<br />
<br />
= Social nets and access control =<br />
== Mainack Mondal: Social ACLs ==<br />
<br />
== Hootan Rashtian: To befriend or not? friend request acceptance model on facebook ==</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997611User:Sidstamm/Notes July 2014 SOUPS2014-07-16T22:19:37Z<p>Sidstamm: /* Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program */</p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Day 2: SOUPS main track =<br />
== Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program ==<br />
This talk was about government spying on people/suspects. People don't buy things or generally expect to be "attacked" (I don't buy a laptop based on thinking I'll be raided by the FBI in the future).<br />
<br />
''Phones.''<br />
<br />
Supreme court ruled recently that we have reasonable expectation to privacy on phones and other digital portable devices.<br />
<br />
At the US border, authorities can inspect and image any of your devices (but not make you enter your password).<br />
<br />
Mobile developers don't advertise security as a selling point. It's hard to weigh security benefits of various apps when the devs don't say things about how they secure things.<br />
<br />
Apple ''did'' decscribe how their security works on iOS; it says that with a pin, your device is encrypted -- strongly.<br />
<br />
Apple and google also have mechanisms to bypass any encryption with a warrant.<br />
<br />
''Desktop.''<br />
<br />
Windows limits which consumers (via home/pro/ultimate) versions get disk encryption. Windows 8.1 has it for all versions, but has not in the past packaged the option with home. Apple offers it to all Mac OS X users. Defaults and incentives are not there to benefit the majority of people. This is ''default security for the rich.''<br />
<br />
We know how to fix this, but security isn't reaching poorer users.<br />
<br />
Tech can protect us when the law can't. So we should have protection tech.<br />
<br />
''Mail.''<br />
<br />
GPG is not usable. Glen Greenwald couldn't use it when he needed to protect a source.<br />
<br />
Nothing has changed since "Why Johnny Can't Encrypt."<br />
<br />
What about email subjects and attachment names? PGP doesn't help obfuscate these.<br />
<br />
Existing tools do not suit the needs of non-technical users. The market forces are against default/easy-to-use crypto.<br />
* Data loss concerns<br />
* Business model (data mining companies)<br />
* government and law enforcement pressure<br />
* Lack of market power in the orgs that want to make change</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997608User:Sidstamm/Notes July 2014 SOUPS2014-07-16T22:04:06Z<p>Sidstamm: </p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
== Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.==<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
==Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.==<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
== Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors ==<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
== Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models==<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
== Lynn Covantry : Perceptions and Actions==<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
== Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.==<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
== Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.==<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
== Maija Pockela : Locate! When users expose location.==<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
== Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.==<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
== Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.==<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
== Janine Spears : I have nothing to hide, thus nothing to fear. ==<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Day 2: SOUPS main track =<br />
== Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program ==</div>Sidstammhttps://wiki.mozilla.org/index.php?title=User:Sidstamm/Notes_July_2014_SOUPS&diff=997607User:Sidstamm/Notes July 2014 SOUPS2014-07-16T21:59:03Z<p>Sidstamm: </p>
<hr />
<div>These are not the greatest notes, but the main takeaways are covered.<br />
<br />
I was unable to attend all sessions, so there are some papers presented at SOUPS I did not summarize below.<br />
<br />
Main conference site: http://cups.cs.cmu.edu/soups/2014/<br />
<br />
__TOC__<br />
<br />
= Day 1: Workshop (Privacy Personas and Segmentation) =<br />
<br />
''tl;dr: People can't agree on best ways to segment large populations by privacy posture or needs.''<br />
<br />
; Urban & Hoofnagle: The Privacy Pragmatic as Vunerable.<br />
This work critiqued Alan Westin's segmentation (Fundamentalists/Pragmatists/Unconcerned) and suggested peoples' concerns are related to how informed they are. "Perhaps underinformed individuals are vulnerable since many privacy prgamatics are underinformed."<br />
<br />
The authors claimed to find some logical flaws in Westin's segmentation. Pragmatists are simply not Fundamentalists or Unconcerned, they're really the catch-all segment. And there's a gap between what consumers understand about data flows and what they want (their preferences).<br />
<br />
The authors:<br />
# Tested how informed each of Westin's segmentation was and found Fundamentalists were significantly more informed about privacy risks<br />
# All groups reject information-intensive business models<br />
# Reduced the segmentation into two segments: resilient and vulnerable where Fundamentalists are resilient and everyone else is "vulnerable".<br />
<br />
See their short paper for 10 suggestions on how to improve the segmentation. But better segmentation may be hard. Is it too hard? When is it useful?<br />
<br />
They reccomend Jennifer King's paper on this subject as she did many statistical tests on the authors' data (also in this workshop.<br />
<br />
; Soren Preibusch : Managing Diversity in Privacy Preferences: How to construct a Privacy Topology.<br />
<br />
The author here wants to reduce the complexity of peoples' privacy preferences -- make it easier for them to choose by kick-starting with typing.<br />
<br />
Too often there are privacy/functionality trade-offs. People will often prefer functionality over privacy.<br />
<br />
A good typology has (1) reliability and (2) predictive power. It means that people are classified into a type correctly and the type strongly indicates the individual's preferences.<br />
<br />
The author clustered some survey respondents into a strangely arbitrary number of clusters. He also tried Factor Analysis to partition based on activities.<br />
<br />
Nothing was reliable and predictive. No solution presented. Suggested a typology would be useful but only if done right with strong, reproducible science.<br />
<br />
Author asserts that privacy preferences are strongly related to personality traits, which leads him to typing since personality typing is reliable and predictive.<br />
<br />
; Pam Wisnewski : Profiling Facebook Users' Privacy Behaviors<br />
<br />
Pam defines privacy as how we manage social interactions. There are lots of things you can do in Facebook to manage boundaries and interactions. Nobody has yet analyzed disclosure decisions (what you share and when) in relation to peoples' privacy settings.<br />
<br />
This author studied people's use and frequency of use for each privacy behavior (such as managing news feeds), then classified users based on their results. Did Confirmatory Factor Analysis of the results.<br />
<br />
Next, she ran a few MFAs, chose six classes based on stats. The largest group in this clustering was "Privacy Balancers" (much like the pragmatists in Westin's segments). http://usabart.nl/chart/<br />
<br />
Takeaways:<br />
* Privacy strategies extend beyond disclosure decisions<br />
* Studying feature awareness vs privacy behavior<br />
* Decisions depend on more than awareness level<br />
<br />
; Kovila Copamootoo : An approach to modeling privacy concerns and behavior via mental models<br />
<br />
Attitude is evaluation of something that changes your behavior. (lost the train of thought during slide flipping)<br />
<br />
Mental Models are maps of cognition made up of cognative associations. Time + Context dependent. Can help with prediction and facilitate interaction with computer systems.<br />
<br />
But mental models are not directly accessible. So the authors asked people questions (indirect ones) to extract peoples' attitudes towards social nets, things like IP addresses and bank accounts.<br />
<br />
Mental models could help validate or identify segments -- new way to segment the population.<br />
<br />
; Lynn Covantry : Perceptions and Actions<br />
<br />
This was a talk by a psychologist. Much of it went over my head.<br />
* theory: Behavior is based on rational choice<br />
* theory: behavior is planned<br />
* theory: perceived threats and behavior as a result is "coping"<br />
* theory: behavior is learned<br />
* theory: change is a process.<br />
<br />
Lynn wants to know what are the environmental, social and personal influencers on privacy decisions. Can we influence behavior based on product design?<br />
<br />
Paper had a survey to determine risk groups based on behaviors.<br />
<br />
Takeaway: While people ''say'' they intend to have cautious behavior, did not observe a difference in behavior.<br />
<br />
; Lydia Kraus : Privacy and Security Knowledge for influencing mobile protection behavior.<br />
<br />
Premise: People lack understanding of mobile device security.<br />
<br />
Two questions:<br />
# Is knowledge related to concerns?<br />
# Does knowledge lead to behavior change?<br />
<br />
The authors studied smartphone (android) users<br />
* 11 questions based on recommendations from various web sites<br />
* coded answers for correctness and calculated score by summing results<br />
* measured Global Info Privacy Concern by asking questions about privacy<br />
* measured behavior based on questions about behavior<br />
<br />
Takeaways:<br />
* Knowledge and Concern are not correlated<br />
* Behavior is influenced by both knowledge and concern.<br />
<br />
(Author described limits to their methods including biased sample and questions)<br />
<br />
; Bart Knijneburg : Information Disclosure Profiles for Segmentation and Recommendation.<br />
<br />
Transparency and control are intended to empower BUT:<br />
* Simple notices are useless and detailed ones are too complex<br />
* Informing users make them more wrong<br />
* People want control but eschew the hassle<br />
* Decision bias.<br />
<br />
Many people lack the ''resources'' to navigate the privacy space. Privacy nudges are promising, but what is the right direction? Need to move beyond one-size-fits-all.<br />
<br />
Idea: use recommendation system (like Neflix) to find out what determines user choices.<br />
<br />
Disclosure behaviors are multidimensional; profile users based on behavior, not attitude.<br />
<br />
The authors clustered users based on types of disclosures (actions). Used Mixed Factor Analysis.<br />
<br />
Idea: Privacy adaption procedure: (1) predict behaviors (2) provide tailored support when prediction is uncertain.<br />
<br />
; Maija Pockela : Locate! When users expose location.<br />
<br />
What influences location disclosure?<br />
* Who is requesting<br />
* What is the reason<br />
* Who I am<br />
<br />
Previous studies have been hypothetical, these authors wanted data. The authors developed an app called Locate!. Participants would receive messages requesting location and the user could allow, allow "blurred" location, deny or "cheat" with a fake location. User could also set context like work or home to describe where they were.<br />
<br />
Participants chose 6 names from their address books. Study spoofed requests from these people with reasons ("Where are you, need to see you ASAP at work", etc). Randomized the defaults (location, fuzz, etc) to identify deliberate actions in responses. Presented short questionnaire after each disclosure to identify why they disclosed what they did.<br />
<br />
Authors are working on a new questionnaire.<br />
<br />
Results: participants did not share more accurately with people they felt closer to. The ''opposite'' was true. Also asked if people used protection from threats for mobile. Those who said "yes" did not share precise location as often.<br />
<br />
Higher education of subjects did not affect willingness to disclose. "Who" has no affect, nor does reason for disclosure. Subject or context ''does'' have effect.<br />
<br />
Takeaway: This study indicates context of location disclosures has no effect, but they need more data.<br />
<br />
; Sebastian Schnorf : A Comparison of Six Sample Providers Regarding Online Privacy Benchmarks.<br />
<br />
UX research at google.<br />
<br />
Fielded set of questions to different survey platforms. Including mail and phone surveys.<br />
<br />
Takeaway: Hard to get secretive people in a privacy-focused survey. Random samplers are better quality because of this.<br />
<br />
; Marc Busch: Is This Information Too Personal? Relationship between privacy concerns and personality.<br />
<br />
Personality matters because it may influence design of a system. As in other talks, "one-size-fits-all" privacy fails.<br />
<br />
Recent studies are specific and narrow.<br />
<br />
Takeaway: Only 3.8% of privacy concerns are affected by various personality traits.<br />
<br />
; Janine Spears : I have nothing to hide, thus nothing to fear.<br />
<br />
What about the person who has no privacy concern?<br />
<br />
D. Solove makes a case for why privacy matters even if you have nothing to hide.<br />
This is a myopic view of privacy equals secrecy. They trust data collectors (blindly) and are unaware of the extents of tracking.<br />
<br />
Instead, shift discussions to implications of over-disclosure (when data is not suppressed). What are the long-term implications of inadvertent shares? How do you educate the user? How do nudges work?<br />
<br />
* How does this persona type affect others around him with different types?<br />
* How quickly do this person's views change, like when there ''is'' something to hide?<br />
<br />
To illustrate why privacy matters, start with a zip code and shopping list and then ask:<br />
# What inferences can be made from this info?<br />
# What are implications of these inferences?<br />
<br />
Also, "Do you wear clothes?"<br />
<br />
= Day 2: SOUPS main track =<br />
== Keynote: Chris Soghoian -- Sharing the blame for the NSA's dragnet surveillance program ==</div>Sidstamm