Add ability to disable "Forget" button

NEW
Unassigned

Status

()

defect
3 years ago
3 years ago

People

(Reporter: yuki, Unassigned)

Tracking

(Blocks 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox49 affected)

Details

Reporter

Description

3 years ago
For enterprise use, the system administrator wants to disable/hide the "Panic" toolbar button to prevent users to clear their history. Currently we can do it by userChrome.css or something addon, but after XUL is ended we need something to alter it.
Reporter

Updated

3 years ago
This is called the "Forget" button in US builds.
Reporter

Updated

3 years ago
Summary: Add ability to disable "Panic" button → Add ability to disable "Forget" button

Updated

3 years ago
Whiteboard: [design-decision-needed]triaged

Comment 2

3 years ago
I don't believe it should be part of the WebExtensions API to be able to hide parts of the user interface and would like to move this and similar bugs to a more suitable component, or won't fix. We've spoken a bit about this in the advisory group and I think there's a similar feeling there.

Is there any recommendation for a component where this could be moved to where it might suitably be addressed?
Component: WebExtensions: Untriaged → WebExtensions: Frontend
Flags: needinfo?(mozilla)
Flags: needinfo?(adam)
Whiteboard: [design-decision-needed]triaged → [design-decision-denied][triaged][intent-to-close]

Comment 3

3 years ago
(In reply to Andy McKay [:andym] from comment #2)
> Is there any recommendation for a component where this could be moved to
> where it might suitably be addressed?

If we are going to pursue this kind of lock-down, it should really be part of a new "enterprise policy" effort. I know Kev has some thoughts here, and Mike has a lot of experience with the kinds of things that would fall into that effort. I agree that this is separate from WebExtensions.

As far as I know, we don't have any current plans for taking on enterprise policy in the current initiatives, but dcamp seemed to be open to the idea of pursuing it eventually. I would propose that we speculatively create a "enterprise policy" component to stage bugs in anticipation of such an effort in the future.
Flags: needinfo?(adam)

Comment 4

3 years ago
A new component would work, but if there's no one looking at that component it probably won't help the reporter. The main bug that this is blocking on is bug 720362 and that's in Firefox: General so I'm tempted to move it to there.
Component: WebExtensions: Frontend → General
Product: Toolkit → Firefox

Comment 5

3 years ago
I would expect that this would go together with disabling private browsing, 'clear recent history' and other "hide my history on my local machine" features.

TBH, I don't see the point. As a user, I can just delete my Firefox profile - if I'm writing to it, I also have the ability to just delete all of it.

Suggest WONTFIX.
Component: General → Private Browsing
Whiteboard: [design-decision-denied][triaged][intent-to-close]
> TBH, I don't see the point. As a user, I can just delete my Firefox profile - if I'm writing to it, I also have the ability to just delete all of it.

Not if a user doesn't have access to the file system.

In a locked down scenario, users wouldn't be able to do this.
Flags: needinfo?(mozilla)

Comment 7

3 years ago
(In reply to Mike Kaply [:mkaply] from comment #6)
> > TBH, I don't see the point. As a user, I can just delete my Firefox profile - if I'm writing to it, I also have the ability to just delete all of it.
> 
> Not if a user doesn't have access to the file system.

This isn't possible. The browser writes (which is kind of the point of not being able to delete history - the browser first has to write said history), the user has access to the browser, so the user has access to the file system. They could do it by opening devtools on about:preferences or other chrome-privileged pages, use an add-on, ... there's a lot of ways for them to basically run arbitrary code in the browser.

In fact, if it's purely about file access, you could just open the [browse...] button on any old file input on a webpage, navigate to the local profile folder and delete the files in question.

I just don't think a "locked down" version of the product is something we should cater for with in-product code, because we'd have to restrict probably upwards of 50% of useful functionality (no more add-ons, no functional file input / upload, no more options, no devtools, no self-xss flaws (for which we don't look, because why would we), no custom search engines, ...). I think that's crazy. We don't have the marketshare to waste the several fulltime developers that it would take to actually implement that correctly, and maintain it against changing features / code, for the ~0 people who need that kind of thing.
You need to log in before you can comment on or make changes to this bug.