Make AutoConfig ESR only starting with Firefox 60 and add a deprecation message for ESR

RESOLVED DUPLICATE of bug 1455601

Status

()

enhancement
RESOLVED DUPLICATE of bug 1455601
2 years ago
Last year

People

(Reporter: mkaply, Assigned: mkaply)

Tracking

60 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox60 affected)

Details

Attachments

(1 obsolete attachment)

The AutoConfig functionality is being actively used for hijacking and for subverting add-on signing. We've found cases in bug 1292444 and bug 1431934 and I also have had other reports.

With the policy engine coming (bug 1419102), it's time to deprecate AutoConfig (best idea) or at least sandbox it so only the documented API can be used (versus having full access to Components).

We will leave it active on the ESR for now for enterprise users that need it.

I'd also like to remove it on ESR eventually (or again, sandbox it like it was originally intended).
Attachment #8947161 - Attachment is obsolete: true
See Also: → 1292444
See Also: → 1431934
How much work would it be to sandbox AutoConfig to stop this abuse vector in 59?  I think we should both sandbox it AND deprecate it, with removal for ESR-after-60.
Most use of AutoConfig (including CCK2) isn't using the standard API anyway, so sandboxing would still result in major breakage for folks not on ESR. And based on the number of CCK2 issues I've received on Firefox 58, there are quite a few users.

I think we will need to keep AutoConfig on ESR to cover cases that our policy engine won't address at first, possibly looking at completely removal in the next ESR.

My only thought around sandboxing was if we wanted to keep legacy AutoConfig on release and limit it to the original API it was designed for. I don't think we should sandbox on ESR.
(In reply to Mike Kaply [:mkaply] from comment #3)
> Most use of AutoConfig (including CCK2) isn't using the standard API anyway,
> so sandboxing would still result in major breakage for folks not on ESR. And
> based on the number of CCK2 issues I've received on Firefox 58, there are
> quite a few users.
> 
> I think we will need to keep AutoConfig on ESR to cover cases that our
> policy engine won't address at first, possibly looking at completely removal
> in the next ESR.
> 
> My only thought around sandboxing was if we wanted to keep legacy AutoConfig
> on release and limit it to the original API it was designed for. I don't
> think we should sandbox on ESR.

Mike, do you see the main set of users affected here as people deploying non-esr builds with cck2? Do we have a sense on what that number looks like?
> Mike, do you see the main set of users affected here as people deploying non-esr builds with cck2?

Yes. And some just Autoconfig users as well.

> Do we have a sense on what that number looks like?

I do not, but I don't think it's incredibly large. Firefox 58 broke CCK2 so I got a sense of how many people would have a problem and it wasn't as bad as I thought.

I think we're really going to have to get the message out that anyone that wants to do anything "enterprisey" with Firefox will need to move over to ESR 60 or whatever we build for them.
Duplicate of this bug: 1439087
See Also: → 1439160
Apologize for more duping, but the official bug is going to be bug 1455601.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → DUPLICATE
Duplicate of bug: 1455601
You need to log in before you can comment on or make changes to this bug.