> Close behind it in priority we'll want APIs to read/modify some key > preferences, such as hardware acceleration. I'd prefer open ended > getPref(pref) setPref(pref, value) APIs (so the trusted content can roll > out new detections and self-healing features without waiting for the > browser to implement an API tailored for a single pref). But if we have > to limit things, we have to limit things.
Looking through http://www.mozilla.org/en-US/firefox/releases/ I see several minor release fixes that involve flipping a pref (like 18.0.1). How much easier would our lives be if we didn't have to chemspill for preference changes? Given that many users accept updates very slowly, if at all (http://en.wikipedia.org/wiki/Template:Firefox_usage_share) it makes sense to have a generic preference API and eliminate as many of these minor releases, some of which could be security related, as possible. Having a browser support API for preferences probably makes Firefox more secure, rather than less secure. To Kevin's point about hardcoding known badd addons, I don't think that works given the length of the release cycle (up to 4 months to get from Nightly to stable), and that would be much less responsive than the blocklist ping already offers. Looking at bugzilla, input.mozilla.org I see many instances of pain caused by misbehaving addons. I support any APIs that make it easier to avoid chemspills, and and APIs that make it easier to disable misbehaving addons. Monica https://bugzilla.mozilla.org/buglist.cgi?v4=squeaky&o5=substring&f1=OP&o3=substring&v6=squeaky&o7=substring&list_id=7821139&f0=OP&f8=CP&v3=squeaky&o2=substring&o6=substring&v7=squeaky&f9=CP&status_whiteboard_type=allwordssubstr&f4=alias&v5=squeaky&query_format=advanced&j1=OR&f3=component&f2=product&o4=substring&status_whiteboard=squeaky&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f5=short_desc&f6=status_whiteboard&v2=squeaky&f7=cf_crash_signature https://input.mozilla.org/en-US/?q=avg&date_end=2013-09-04&date_start=2013-08-28 https://input.mozilla.org/en-US/?q=ask.com&date_end=2013-09-04&date_start=2013-08-28 https://input.mozilla.org/en-US/?q=babylon&date_end=2013-09-04&date_start=2013-08-28 _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
