"Potentially could", it doesn't mean that they do it.

Reading these data is one thing, but transferring it somewhere is something different.

I realize Mozilla can read login and password info

Mozilla as an organization or as a sync server owner doesn't know your passwords, everything is encrypted.

I am not familiar with the Firefox source code, but since Firefox gets installed on your computer (or phone) as a native app, any such is capable of key-logging and reading any data entered into it PRIOR to that same application (Firefox, in this case) subsequently encrypting your data to send over the wire.

This said, again, I'm not worried about Mozilla or Firefox.

As my post mentions, my concern is that Firefox extensions with "Access your data for all websites" permission - there are tons of those - according to Mozilla's own documentation, can,

"...read the content of any web page you visit as well as data you enter into those web pages, such as USERNAMES and PASSWORDS."

Not cool, and should not be possible!

Note: The wording above does NOT apply to encrypted data.

Encrypted data is not "read," it is simply sent across the wire.

"Reading" involves unencrypted data.

I have never created a Firefox extension so I don't know what's involved, but here's the bottom line -

Either for an ad blocker or feed reader - the only 2 extensions I have installed - NO DATA entered and sent by the client via the FORM POST method should be readable in unencrypted form.

This means is that -

a) Either the wording above by Mozilla re: the "Access your data for all websites" permission should be revised to say this permission does not allow reading any unencrypted FORM INPUT POST method data, or;

b) The developers kit and APIs used to develop Firefox extensions needs to be restructured to isolate the ability to read FORM POST INPUT from other "read data" privileges that actually make sense, like data sent from the server to the client and data sent from the client to server via the URL-DNS string.

jdw-dbc, there may be legitimate reasons for some add-ons to interact with passwords. Password managers say.

I do not know why some sort of two tier permission system has not been implemented. One where all data is accessible at one level, and another for all data except login fields.

Perhaps it is not always possible to identify such fields. And they want to avoid 'but I didn't give that add-on login-read permission' complaints, when Firefox allows access to a field that it could not identify as sensitive?

Or maybe it would introduce slowdown if Firefox had to analyse and make judgments on each form field on a page?

Or perhaps there isn't that much demand. People tend to either trust an add-on or they don't, and someone has judged that the offered levels of permissions provide enough nuance for most users, without increasing the complexity of the system / coding any further?

Just some of my thoughts, but of course only someone at Firefox development could really answer this.

TechHorse,

Thanks for your reply, but the punchline is, per your comments, "I do not know why some sort of two tier permission system has not been implemented," and...

"... of course only someone at Firefox development could really answer this."

Yup, and doubtful we'll classify any such answer - unlikely one will be forthcoming, since I posted the issue 3 days ago - as "Good."

It's BEYOND INSANE to think the Mozilla-Firefox team has everyone scrambling for the latest update - security fixes almost always involved, "security fixes" a huge focus of development past many years - YET...the Keys to the Kingdom are being handed to any idiot who wants to develop an extension!

Per Mozilla's own wording of the Firefox "Access your data for all websites" permission, that looks to be the case.

While there's a snowballs chance it's not - ie: "Oops! We just fired the guy who wrote Firefox Support articles!" - sounds like Mozilla has been (intentionally?) giving Team Bad Boy a barn door size security hole for a long time.

Sure, most extension developers won't take advantage of the ability to steal huge sums the easy way - vs waiting for nickel-and-dime donations - eg: by hijacking your retirement account.

But, some will.

Here's the deal...

"Software Engineering" is the most sophisticated and malleable of all the engineering disciplines.

So yes, Virginia, you can segregate the ability to read login and password info from other relevant data.

More broadly -

a) Again, NO "ad blocker" nor "feed reader" HAS THE LEGIT NEED to read ANY DATA flowing from client to server (other than URL-DNS data)!

b) Mozilla should not approve "permissions" for any Firefox extensions that clearly are NOT OF THE TYPE REQUIRED for the extension involved!

c) For any extensions that do need to read a cross-section of client -> server data, any such destined for encryption per being within a FORM element should be excluded from read privileges.

Is additional Firefox functionality needed that would involve the kind of data per C) above?

If so, that should be INCLUDED in the next Firefox "update" (as native functionality).

Yes, I realize there are likely more egregious similar issues re: phone apps and perhaps other browsers.

We have no choice but to "trust" the major corporations we depend upon for NATIVE applications - eg: Microsoft and Apple operating systems, Google, Mozilla and Apple per Chrome, Firefox and Safari.

But, let's not extend the Web of Vulnerability beyond what's absolutely required!

I'm hoping a Firefox dev engineer will read this thread and reply indicating either that -

a) The "Access your data for all websites" permission has just been renamed as its description was wildly incorrect.

b) The issues mentioned on this thread are now being rectified and "soon" will be retroactively addressed.

jdw-dbc, Just some thoughts.

Regarding a blanket prohibition on accessing login fields, is there some standard text box labelling or other mechanism that all sites use that can identify that the characters entered into this specific field will be used by the website as part of its authentication process?

Or considering instead a blanket prohibition on encrypted fields, password managers might need to read login data in order to add it to the user's stored list? Dictionaries or spell checkers or translators might need to analyse the words that you type, even if those words will be encrypted before being sent?

Regarding such functions being natively added instead, even if Mozilla had the unlimited resources to natively add in every conceivable function that relates to potentially sensitive page elements, no doubt people would still complain that they can't use the same 3rd-party add-on that works in Chrome, Edge, Safari et al, if they prefer that add-ons implementation of the functionality over the native one.

Regarding points A and B, How does Firefox judge what an add-on's purpose is and which tier of permissions that purpose requires?

Unless if a human checked each and every add-on's code, there would be no way to tell at Firefox's end whether "Spellchecker Expert Plus" actually is a spellchecker written by good people, or whether it is just an info-stealer? How does Firefox know what "Improve the website" is meant to do and whether it needs the permissions that it requests?

So even with a multi-tier system, people would still need to be wary. 'Team Bad Boy' would still be able to write an add-on and ask users / Firefox to approve the highest permission.

Note I am not saying that there is no value in such a multi-tier system. I am just pointing out that there is only so much that can be done at Firefox's end.

If one agrees that Firefox cannot deduce at a software level what an add-on's purpose is, and that it also cannot always know what a website intends to do with the data entered into a particular form field, then it either severely limits functionality with blanket prohibitions, or trusts users to only grant these permissions to safe add-ons.

But yes, all that said, a permission for "everything on the site except encrypted form fields" would at least help in some cases. Say a legitimate add-on author only requests up to this level because they know that they do not need higher permissions. Then some malware infects that add-on without the author realising. This malware that is now hitching a ride with that normally safe add-on might be thwarted by the lack of permissions that the add-on initially sought.

Or people would have the chance to become suspicious of an add-on if it claimed to only change the background colour of websites to green, but wanted form-field access.

TechHorse -

Thanks for the reply, but with all due respect, you're making this more complicated than it really is.

First, I didn't propose a "blanket prohibition on encrypted fields" re: add-ons read-write access, given that everything now goes over HTTPS.

I proposed that FORM data involving fields traditionally encrypted be excluded from add-on read or write access.

You probably could read for INPUT LABELs or text near suc fields with the word "password" or "login" to catch and exclude those from access.

I'm not adequately familiar with the Firefox API and dev kit to know how that might be restructured to accomplish what I'm requesting - assuming, that is, that extensions with "Access your data for all websites" permission currently have the WAY-CRAZY ability to read and-or write all of your account login data.

Assuming all or nearly all login data is passed via the FORM POST method, if the Firefox dev team simply excluded all extensions from being able to read or write such data - explaining that the reason is TO PREVENT extension developers from being ABLE TO ACCESS ALL YOUR LOGIN AND PASSWORD DATA - then, no reason to think there would be negative user or PR consequences.

To the contrary, that would be a positive since...when most install an extension - usually as something fun or nice-to-have vs required - it would never occur to them they are potentially giving all their financial, email and other login data to a 3rd party they know nothing about!

Again, it's inevitable that Mozilla - and Google, Microsoft and Apple - have such blanket login access capability, but that level of privilege should not be extended 3rd party browser extension developers.

If the feature really involves "must have" functionality then, again, simple solution.

The Mozilla - or Google, Apple, Microsoft - developers can add it to their browser update.

jdw-dbc, you suggest that there would be "no reason to think there would be negative user or PR consequences" to preventing login field access for add-ons.

I personally wouldn't underestimate people's capacity for complaint due to a loss of convenience and / or security in one direction, even if it is to protect them from security risks in another direction.

Maybe some people prefer to use dedicated 3rd-party password managers. They might consider them to be safer / have better protections than the native functionality for a particular browser. Or they might prefer the convenience of only having to maintain one set of passwords. For example, they might save their passwords inLast Pass, then have them autofilled on sites by the Last Pass extension that they have installed in several browsers?

Without these extensions they would have to start manually saving and maintaining a repeated list of passwords for dozens of the same sites, in several different sources. That too can carry its own security risks of course.

Either that or they would need to manually open up a separate app from the browser, find the login details in the app and switch back and forth as they copy usernames and passwords between the app and the browser (as well as being a lot less convenient, copying sensitive information to the clipboard is also considered risky by some).

Anyway, that would be one lost functionality that springs to mind that some people might not appreciate. Especially if it is to protect against a risk that they feel is not applicable to them. If say, they do not use other add-ons or only use reputable, trusted ones.

You might argue that the benefits of a blanket prohibition outweigh such grumblings, I am just addressing the suggestion that there would not be any.