Open Bug 1746822 Opened 4 years ago Updated 3 years ago

Dropping an URL on the Firefox content area defeats the purpose of the kiosk mode

Categories

(Firefox :: Enterprise Policies, defect, P3)

Product:
Firefox
Component:
Enterprise Policies
Version:
Firefox 95
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: tomjokiel, Unassigned)

Details

(Keywords: sec-other)

Attachments

(1 file)

screen.png
205.73 KB, image/png
Details
Attached image screen.png —

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

  1. start Firefox with the '--kiosk' flag ('-kiosk' under Windows) in order to enter the locked kiosk mode
  2. press 'ctrl+f', 'F3' or other keyboard shortcut in order to open the search field, quick search filed
  3. type an URL in the input field
  4. drag that URL and drop it on the Firefox's content area

Actual results:

URL gets immediately opened by the Firefox

Expected results:

Firefox should never open a dropped URL when working in the kiosk mode.

The input fields work effectively as an address bar defeating the purpose of the kiosk mode.

Is there any preference/policy/source code modification which we could use to disable 'opening of the dropped URLs' feature entirely in Firefox?

I have attached a screenshot which demonstrates the problem.

This isn't a Firefox security issue per se, so I'll mark it sec-other and move it to the release-track security group so it will still be hidden, but hopefully more people who might be able to help with this issue can see it.

Group: firefox-core-security → core-security-release
Keywords: sec-other

Mike, is there a separate policy people are meant to use to prevent loading via drag/drop? Do we have documentation for this kind of stuff? And is there any point keeping this confidential?

Group: core-security-release → mozilla-employee-confidential
Component: Untriaged → Enterprise Policies
Flags: needinfo?(mozilla)

This doesn't need to be confidential.

Generally the expectation is that the kiosk will have other software that takes care of a lot of these issues. We don't block keyboard or anything like that.

This is the same behavior as other browsers.

Flags: needinfo?(mozilla)

Search field can be helpful in the kiosk mode, we dont want to disable it.
We want to disable URL loading from the drag/drop event.
(this feature is disabled in Google Chrome by default - you cant drop an URL from the search field).

Any tweaks we could do to the omni.ja file in order to disable it?

(In reply to TomaszJ from comment #4)

We want to disable URL loading from the drag/drop event.

Mike, should we just morph this into a policy request for this? It looks to me like there isn't a pref or similar for it at the moment.

(this feature is disabled in Google Chrome by default - you cant drop an URL from the search field).

Uh, that's not what I'm seeing. I can drag/drop links from the search field to the content area just fine. They open new (background) tabs, though.

Either way, as soon as there's an <input> anywhere on the site you could do it there, even if we somehow disabled dragging/dropping text from the search field.

Any tweaks we could do to the omni.ja file in order to disable it?

No, messing with omni.ja will just cause busted upgrades...

Group: mozilla-employee-confidential
Flags: needinfo?(mozilla)

If I were going to do this in policy, I would remove keystrokes completely so it wouldn't solve their usecase per say.

I do wonder if it's possible to accidentally do this though (like dragging an image).

Chrome does have a command line to turn off pinch scrolling so they know that things can happen. Let's keep this and I'll see what I can come up with.

Flags: needinfo?(mozilla)

(In reply to Mike Kaply [:mkaply] from comment #6)

If I were going to do this in policy, I would remove keystrokes completely so it wouldn't solve their usecase per say.

I'm not sure I understand. Are you saying that drag-drop to load URL should continue to be supported in kiosk mode, but putting text into text fields shouldn't?

Flags: needinfo?(mozilla)

Sorry, I meant the keystroke should be disallowed to begin with, but I understand there are other ways to make this happen.

I'm going to investigate more what other browsers do.

We're getting more kiosk interest, so I'll spend some more time on it 1Q next year.

Flags: needinfo?(mozilla)

The severity field is not set for this bug.
:mkaply, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mozilla)

(I'm going to use find field to mean the field that shows up when you press F3 to distinguish from our search field)

I just verified that Chrome has the same behavior as well at least on macOS. I started the browser in kiosk mode, typed a URL in the find field, dragged it to the content area and it loaded the page.

I'm honestly not sure what to do here.

I find it odd that you can type a URL in the find dialog and drag it to the content area (on Chrome or Firefox).

Should we prevent dropping on the content area in general? Or just not convert URLS dragged from chrome areas of the UI?

Or should we not allow the find dialog to be displayed at all in kiosk mode?

Either way, as soon as there's an <input> anywhere on the site you could do it there, even if we somehow disabled dragging/dropping text from the search field.

This is not true (which surprised me). We only convert text typed in chrome entry fields to real draggable URLS when you drag. We don't do it with content entry fields. That's why it works for the find field.

Flags: needinfo?(mozilla)
Severity: -- → S4
Priority: -- → P3

Mike,

I believe we should define what is the purpose of the kiosk mode.

My understanding is that when the Firefox works in the kiosk mode then the browser is limited to displaying only a single webpage on the PC. Navigation bar is disabled so changing the browser options (through the menu) and changing the viewed webpages (through the address bar) is not possible unless the webpage contains a links to 3rd party websites.

If we assume this definition is correct then possibility of dropping the URLs from the input fields of the Firefox UI (e.g. search filed) and also an external applications (e.g. Word editor, PDF viewer, email client, etc) should be disabled entirely.

"Or should we not allow the find dialog to be displayed at all in kiosk mode?"
That would mean disabling an important browser function.
Besides: you would also need to block the print window which is invoked with the Ctrl+P keyboard shortcut (at least under Linux) as it allows to drag an URL from it's input fields as well.

Not sure if I'm allowed to post links here, if yes then please have a look here:
https://porteus-kiosk.org/public/files/Firefox-URL_dropping.webm

In my opinion it would be best to have a preference/flag/policy for enabling and disabling 'drag and drop' feature.
That should keep everyone happy.

I'm a little confused. If the user can press ctrl-f, presumably they can just press ctrl-l and put an address directly into the address bar?

My understanding was that kiosk mode didn't cater to situations with full keyboard access, as they could probably also access the windows start menu or task bar that way.

The support page for kiosk mode also says:

  • Configure accessible domains through policy as well as the homepage.

so I would expect that you use a solution such as those outlined at https://support.mozilla.org/en-US/questions/1291464 to enforce which sites should / should not be accessible.

I'm not convinced this bug as filed is valid. I think we should publish a recommended enterprise policy file / group policy config so people stop being surprised about the many (many, MANY) ways in which a web browser allows navigation. Playing whack-a-mole with those is not a winning strategy.

In our case we do block many keyboard shortcuts on the system level to keep the kiosk mode sane.

We dont want to block 'ctrl+f' or 'ctrl+p' shortcuts as they allow accessing important browser functions (searching, printing).

Thanks

I believe we should define what is the purpose of the kiosk mode.

We had this debate when first looking at kiosk mode and in the end we decided that kiosk mode is "full screen mode that you can't get out of"

This was based on looking at Chrome and other kiosk modes.

Based on what you are seeing, I agree the primary issue here is drag and drop from chrome entry fields and only that. It's a kiosk escape that exists in Chrome as well.

That being said, preventing all drags to the content area shouldn't be necessary. If you are in kiosk mode, you can't access other applications to start the drag.

(In reply to Mike Kaply [:mkaply] from comment #14)

Based on what you are seeing, I agree the primary issue here is drag and drop from chrome entry fields and only that. It's a kiosk escape that exists in Chrome as well.

I'm still confused why this is an issue - kiosk consumers can restrict the URLs already. Why the need to disable drag/drop while leaving other mechanisms for navigation (like ctrl-l, ctrl-k, F6, link clicks, ...) alone?

(In reply to :Gijs (he/him) from comment #15)

(In reply to Mike Kaply [:mkaply] from comment #14)

Based on what you are seeing, I agree the primary issue here is drag and drop from chrome entry fields and only that. It's a kiosk escape that exists in Chrome as well.

I'm still confused why this is an issue - kiosk consumers can restrict the URLs already. Why the need to disable drag/drop while leaving other mechanisms for navigation (like ctrl-l, ctrl-k, F6, link clicks, ...) alone?

Keystrokes can be easily blocked by third party apps (and usually are). And as far as restricting urls goes, that works, but we still load the URL as blocked, so if the kiosk had no way to navigate, it would be in a broken state.

But the bigger issue is we shouldn't have the kiosk person have to be aware of this behavior. Enabling printing on a Linux kiosk shouldn't be a route to loading arbitrary URLS.

I don't plan to disable drag drop, I only plan to provide a way to not convert URLs dragged from Chrome entry fields into droppable URLs. This is the specific behavior that's problematic for kiosks. Any other drag from other apps/other places isn't an issue because the kiosk is fullscreen (and dragging from content pages doesn't work like this).

(In reply to Mike Kaply [:mkaply] from comment #16)

we still load the URL as blocked, so if the kiosk had no way to navigate, it would be in a broken state.

That sounds like something that should be fixed separately then. Does the about:blocked (or w/e) page not have a "go back" link that just goes back to the previous page? If not we should add one. Perhaps we could even do it automatically after a delay, or avoid loading the "blocked" page altogether, or something.

But the bigger issue is we shouldn't have the kiosk person have to be aware of this behavior.

I don't think so? Our assumptions for kiosk mode are that admins blocklist/allowlist the URLs they care about. This was explicit in the user story in bug 158968 and in the conversation the two of us had when I reviewed the patch there. If the assumptions around kiosk mode are changing, please can we clarify what the new ones are.

I will repeat what I said earlier: having kiosk mode block "unexpected" forms of navigation is going to be a game of whack-a-mole, and result in sprinkling "if !kiosk mode" conditions everywhere, which is really bad for maintenance. I don't want to do that. The right solution is to only allow the kiosk instance to navigate to URLs that should be allowed, and blocking everything else.

For instance, right now when the user selects text anywhere that is a URL (but not a link in the DOM), they can right click and use the "open link" entry in the context menu. The context menu is disabled in kiosk mode. However, if someone contributed a patch that allowed you to (for instance) middle-click or keyboard-modifier-click such a selection to open it immediately, saving time vs. right click, mouse move, click, we would almost certainly forget to add another "if !kiosk mode" condition, and then someone else will learn of this the hard way, have to file another bug that we have to fix, that takes 4 months or w/e to make it into ESR, etc. etc.

This all added to the fact that on macOS and some Linux distros you can't even disable the menubar, so it's always possible to navigate to the open internet, if that isn't blocked via policy. Then there's devtools, the bookmarks sidebar and toolbar, the library window (for all of which there is a shortcut), all of which allow arbitrary navigation of the content area. There are way too many such entrypoints to consider (all of which, if we're not assuming admins block URLs, the "kiosk person [has] to be aware of" to block the shortcut!), and forcibly disabling all of them in kiosk mode is a non-goal, AIUI. I don't understand why drag/drop is different.

I definitely don't want to add kiosk mode if statements everywhere. In this particular case, I would like a preference that turns this behavior off (converting URLs from chrome entryfields to be draggable) and then just either set this pref via kiosk mode or expose it via policy. I don't want to play navigation whack a mole either, and I have no plans to do so. I'm only addressing this very specific case.

I don't plan to disable drag drop, I only plan to provide a way to not convert URLs dragged from Chrome entry fields into droppable URLs. This is the specific behavior that's problematic for kiosks. Any other drag from other apps/other places isn't an issue because the kiosk is fullscreen (and dragging from content pages doesn't work like this).

When 3rd party application is associated with certain file type then 'drag and drop' is still a problem, even when Firefox works in the fullscreen mode.

For example we use LibreOffice to open .docx files and result is the same:
https://porteus-kiosk.org/public/files/Firefox-URL_dropping2.mp4

For some reason dropping did not work from the Writer body, I had to use 'Save as' window to recreate the problem.

Any chance your preference/policy could cover this case as well?

If you're launching a fully functional LibreOffice, you're not a kiosk... Any number of things from LibreOffice could be dropped on to Firefox (including files from the open or save dialog)

Are the expected results known at this point? Do we have detailed steps to reproduce to use for confirmation? Does it need QA's attention?
Thanks!

Flags: needinfo?(mozilla)

Nothing for QA at this point. This fell off my radar. I've moved this up in priority.

Flags: needinfo?(mozilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: