Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
The problem in short: The last release of Firefox doesn't allow the user to install add-ons which are not signed by Mozilla by default, in the next version, you won't even be able to disable this behavior. This means that a couple of add-ons that are packaged by Fedora won't work.
In my opinion, this problem has an impact on a relatively small number of users while suggested solutions will have an impact on majority of Workstation users. The author of the original ticket recommends Firefox is removed altogether if Mozilla doesn't change their plan, another suggestion is to switch to ESR which would mean that Fedora would have as conservative approach to Firefox updates as RHEL.
Firefox is probably the most important desktop app in Fedora, so I wonder whether the Workstation working group should voice its opinion in this before any decision is made.
Jiri
ESR will only delay the problem.
Can the Fedora build add a secodary key to accept signed extensions?
AFAIK the long term plan is todeprecate the current method of extensions in favour of a more browser agnostic approach.
On 7 January 2016 at 13:26, Jiri Eischmann eischmann@redhat.com wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
The problem in short: The last release of Firefox doesn't allow the user to install add-ons which are not signed by Mozilla by default, in the next version, you won't even be able to disable this behavior. This means that a couple of add-ons that are packaged by Fedora won't work.
In my opinion, this problem has an impact on a relatively small number of users while suggested solutions will have an impact on majority of Workstation users. The author of the original ticket recommends Firefox is removed altogether if Mozilla doesn't change their plan, another suggestion is to switch to ESR which would mean that Fedora would have as conservative approach to Firefox updates as RHEL.
Firefox is probably the most important desktop app in Fedora, so I wonder whether the Workstation working group should voice its opinion in this before any decision is made.
Jiri
desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
Hi,
IMHO I say that Firefox lately gets problems, and we have better browsers in the repository already. We have Web, and pretty much usable.
Zoltan
2016-01-07 14:29 GMT+01:00 Naheem Zaffar naheemzaffar@gmail.com:
ESR will only delay the problem.
Can the Fedora build add a secodary key to accept signed extensions?
AFAIK the long term plan is todeprecate the current method of extensions in favour of a more browser agnostic approach.
On 7 January 2016 at 13:26, Jiri Eischmann eischmann@redhat.com wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
The problem in short: The last release of Firefox doesn't allow the user to install add-ons which are not signed by Mozilla by default, in the next version, you won't even be able to disable this behavior. This means that a couple of add-ons that are packaged by Fedora won't work.
In my opinion, this problem has an impact on a relatively small number of users while suggested solutions will have an impact on majority of Workstation users. The author of the original ticket recommends Firefox is removed altogether if Mozilla doesn't change their plan, another suggestion is to switch to ESR which would mean that Fedora would have as conservative approach to Firefox updates as RHEL.
Firefox is probably the most important desktop app in Fedora, so I wonder whether the Workstation working group should voice its opinion in this before any decision is made.
Jiri
desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 08:32 AM, Zoltan Hoppar wrote:
Hi,
IMHO I say that Firefox lately gets problems, and we have better browsers in the repository already. We have Web, and pretty much usable.
With respect, "Web" is lacking many features that a workstation user would rely on. It's not ready to be a default browser for Fedora IMHO.
I was just running it now to try to get a list of some of its missing features, such as a JavaScript debugging console, but it quite literally was crashing on almost any operation except clicking on a URL link. This is a Wayland Workstation on Rawhide.
So yeah, really not feeling that this is ready.
----- Original Message -----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 08:32 AM, Zoltan Hoppar wrote:
Hi,
IMHO I say that Firefox lately gets problems, and we have better browsers in the repository already. We have Web, and pretty much usable.
With respect, "Web" is lacking many features that a workstation user would rely on.
What specific features is it missing?
It's not ready to be a default browser for Fedora IMHO.
It is my daily browser.
I was just running it now to try to get a list of some of its missing features, such as a JavaScript debugging console,
It does, it's available via the inspector ("inspect element"), and you'll see Javascript errors right there, along with a console, etc.
but it quite literally was crashing on almost any operation except clicking on a URL link. This is a Wayland Workstation on Rawhide.
There were problems with older versions of WebKitGTK+ in F23, but those have been resolved in updates. The number one crash I see right now is the OOM killed kicking in, and choosing the Web containers to kill instead of what's really eating RAM...
So yeah, really not feeling that this is ready.
YMMV, but I'm very happy using it, along with Web Apps for my NAS' admin interface, Zimbra's work webmail, my Web RSS reader, etc.
How do I install Web? I don't see it in dnf for Rawhide.
On 01/07/2016 08:53 AM, Bastien Nocera wrote:
----- Original Message -----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 08:32 AM, Zoltan Hoppar wrote:
Hi,
IMHO I say that Firefox lately gets problems, and we have better browsers in the repository already. We have Web, and pretty much usable.
With respect, "Web" is lacking many features that a workstation user would rely on.
What specific features is it missing?
It's not ready to be a default browser for Fedora IMHO.
It is my daily browser.
I was just running it now to try to get a list of some of its missing features, such as a JavaScript debugging console,
It does, it's available via the inspector ("inspect element"), and you'll see Javascript errors right there, along with a console, etc.
but it quite literally was crashing on almost any operation except clicking on a URL link. This is a Wayland Workstation on Rawhide.
There were problems with older versions of WebKitGTK+ in F23, but those have been resolved in updates. The number one crash I see right now is the OOM killed kicking in, and choosing the Web containers to kill instead of what's really eating RAM...
So yeah, really not feeling that this is ready.
YMMV, but I'm very happy using it, along with Web Apps for my NAS' admin interface, Zimbra's work webmail, my Web RSS reader, etc. -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Jan 7, 2016 09:30, "Daniel J Walsh" dwalsh@redhat.com wrote:
How do I install Web? I don't see it in dnf for Rawhide.
Look for gnome-web, or search for "ephiphany", I don't remember how its packaged since the rename.
On Thu, Jan 7, 2016 at 3:30 PM Daniel J Walsh dwalsh@redhat.com wrote:
How do I install Web? I don't see it in dnf for Rawhide.
The package/executable name is "epiphany".
On Thu, 2016-01-07 at 09:30 -0500, Daniel J Walsh wrote:
How do I install Web? I don't see it in dnf for Rawhide.
sudo dnf install epiphany
This package provides only the desktop file and search provider. The epiphany-runtime package (which is installed by default) provides the actual /usr/bin/epiphany, which is needed for GNOME web apps.
Dan, maybe we could work together on getting an SELinux policy set up for WebKitGTK+ (and maybe also Epiphany)? I don't know much about SELinux, but I gather that Firefox users currently have more SELinux protections.
Michael
On 01/07/2016 01:01 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 09:30 -0500, Daniel J Walsh wrote:
How do I install Web? I don't see it in dnf for Rawhide.
sudo dnf install epiphany
This package provides only the desktop file and search provider. The epiphany-runtime package (which is installed by default) provides the actual /usr/bin/epiphany, which is needed for GNOME web apps.
Dan, maybe we could work together on getting an SELinux policy set up for WebKitGTK+ (and maybe also Epiphany)? I don't know much about SELinux, but I gather that Firefox users currently have more SELinux protections.
Michael
desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
The only confinement for firefox/chrome right now is around their plugins. If epiphany uses a separate processes to try to sandbox them, we could wrap it with SELInux.
On Thu, 2016-01-07 at 15:57 -0500, Daniel J Walsh wrote:
The only confinement for firefox/chrome right now is around their plugins. If epiphany uses a separate processes to try to sandbox them, we could wrap it with SELInux.
Yes, we have /usr/libexec/webkit2gtk-4.0/WebKitPluginProcess and /usr/libexec/webkit2gtk-4.0/WebKitPluginProcess2 (alternative version, linked to GTK+ 2 to make Flash work).
Maybe the same policy you use for Chrome and Firefox would apply well to WebKit?
Michael
On 01/07/2016 04:57 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 15:57 -0500, Daniel J Walsh wrote:
The only confinement for firefox/chrome right now is around their plugins. If epiphany uses a separate processes to try to sandbox them, we could wrap it with SELInux.
Yes, we have /usr/libexec/webkit2gtk-4.0/WebKitPluginProcess and /usr/libexec/webkit2gtk-4.0/WebKitPluginProcess2 (alternative version, linked to GTK+ 2 to make Flash work).
Maybe the same policy you use for Chrome and Firefox would apply well to WebKit?
Michael
desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
Yes it probably would with a few minor tweeks. Open a bugzilla on SELinux policy to handle it.
Currently we have differerent policies for chrome and firefox, but we really should consolodate them into a single webplugin.te file.
On Thu, 2016-01-07 at 17:22 -0500, Daniel J Walsh wrote:
Yes it probably would with a few minor tweeks. Open a bugzilla on SELinux policy to handle it.
Currently we have differerent policies for chrome and firefox, but we really should consolodate them into a single webplugin.te file.
On 01/07/2016 09:23 AM, Bastien Nocera wrote:
----- Original Message -----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 08:32 AM, Zoltan Hoppar wrote:
Hi,
IMHO I say that Firefox lately gets problems, and we have better browsers in the repository already. We have Web, and pretty much usable.
With respect, "Web" is lacking many features that a workstation user would rely on.
As someone who wrote the original certificate manager implementation [1] when Epiphany was Gecko powered, It never was enabled. And apparently never ported to webkit.
If Web authors still think it is a seldom used feature, They never had a business bank account where you need to be able to manage the certificates. Sometimes only for backing it up or installing it on another machine.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=119090
What specific features is it missing?
It's not ready to be a default browser for Fedora IMHO.
It is my daily browser.
I was just running it now to try to get a list of some of its missing features, such as a JavaScript debugging console,
It does, it's available via the inspector ("inspect element"), and you'll see Javascript errors right there, along with a console, etc.
but it quite literally was crashing on almost any operation except clicking on a URL link. This is a Wayland Workstation on Rawhide.
There were problems with older versions of WebKitGTK+ in F23, but those have been resolved in updates. The number one crash I see right now is the OOM killed kicking in, and choosing the Web containers to kill instead of what's really eating RAM...
So yeah, really not feeling that this is ready.
YMMV, but I'm very happy using it, along with Web Apps for my NAS' admin interface, Zimbra's work webmail, my Web RSS reader, etc. -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
----- Original Message -----
On 01/07/2016 09:23 AM, Bastien Nocera wrote:
----- Original Message -----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 08:32 AM, Zoltan Hoppar wrote:
Hi,
IMHO I say that Firefox lately gets problems, and we have better browsers in the repository already. We have Web, and pretty much usable.
With respect, "Web" is lacking many features that a workstation user would rely on.
As someone who wrote the original certificate manager implementation [1] when Epiphany was Gecko powered, It never was enabled. And apparently never ported to webkit.
If Web authors still think it is a seldom used feature, They never had a business bank account where you need to be able to manage the certificates. Sometimes only for backing it up or installing it on another machine.
To be fair, this isn't something I'd consider a "workstation" feature. Maybe it's needed for particular users, but I can hardly see designers, or developers having to use that feature for business banking.
Now that epiphany/Web isn't using the certificate storage in Gecko (I'm guessing separate from the system-wide NSS store), then you could use a system-wide certificate manager. In fact, I'm pretty sure that Seahorse already does that, no?
Cheers
On Thu, 2016-01-07 at 10:04 -0430, Robert Marcano wrote:
As someone who wrote the original certificate manager implementation [1] when Epiphany was Gecko powered, It never was enabled. And apparently never ported to webkit.
If Web authors still think it is a seldom used feature, They never had a business bank account where you need to be able to manage the certificates. Sometimes only for backing it up or installing it on another machine.
Hi Robert,
We've had several bugs about this, but at the end of the day I think Epiphany is the wrong place for a certificate manager, because Epiphany does not have its own trust store like Firefox/NSS does -- it instead uses the system trust. Like Bastien mentions, we have a separate application, Seahorse, which exists to manage certificates systemwide. I think we should focus on improving Seahorse instead. Daiki Ueno from Red Hat has been working on this.
Seahorse has a certificate import feature, but I believe it's currently broken; in the meantime, you have to open a terminal and use the 'trust' command.
I'm not opposed to adding a certificate manager in Epiphany if someone else wants to work on it, but we should meet with the GNOME designers and the safety team to figure out the proper division of responsibility between Epiphany and Seahorse. Maybe a compromise solution would be a Certificate Manager menu item that just launches Seahorse. We're certainly open to brainstorming about this.
On a somewhat unrelated note, I think Epiphany current certificate dialog (which does not allow management, but displays the certificate used on the current page) could stand to be improved. Currently it is excellent at showing the server's certificate, but it ought to be able to show the entire chain. This is not something most users care about, so I think it's not a big problem, but I get tired of switching to the command line to investigate certificate issues.
Michael
P.S. Thanks for your contributions to Epiphany!
On 01/07/2016 01:54 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 10:04 -0430, Robert Marcano wrote:
As someone who wrote the original certificate manager implementation [1] when Epiphany was Gecko powered, It never was enabled. And apparently never ported to webkit.
If Web authors still think it is a seldom used feature, They never had a business bank account where you need to be able to manage the certificates. Sometimes only for backing it up or installing it on another machine.
Hi Robert,
We've had several bugs about this, but at the end of the day I think Epiphany is the wrong place for a certificate manager, because Epiphany does not have its own trust store like Firefox/NSS does -- it instead uses the system trust. Like Bastien mentions, we have a separate application, Seahorse, which exists to manage certificates systemwide. I think we should focus on improving Seahorse instead. Daiki Ueno from Red Hat has been working on this.
For discussions about if Web is ready or not to replace Firefox, it doesn't matter to much if the implementation is on Web or a lower layer, only if the user can do it. The question if this is a needed feature is another thing to discuss.
Another features missing that I remember from using it for testing:
- No UI (yet) to add new search engines. - UI option for not automatically restore previous open tabs, this default is annoying for me - (Desired) Import bookmarks from Firefox. There is an import menu option but it should be able to detect the Firefox profile by default, with no need to install Firefox, export and then import. Migration should be easy
Seahorse has a certificate import feature, but I believe it's currently broken; in the meantime, you have to open a terminal and use the 'trust' command.
I'm not opposed to adding a certificate manager in Epiphany if someone else wants to work on it, but we should meet with the GNOME designers and the safety team to figure out the proper division of responsibility between Epiphany and Seahorse. Maybe a compromise solution would be a Certificate Manager menu item that just launches Seahorse. We're certainly open to brainstorming about this.
On a somewhat unrelated note, I think Epiphany current certificate dialog (which does not allow management, but displays the certificate used on the current page) could stand to be improved. Currently it is excellent at showing the server's certificate, but it ought to be able to show the entire chain. This is not something most users care about, so I think it's not a big problem, but I get tired of switching to the command line to investigate certificate issues.
Michael
P.S. Thanks for your contributions to Epiphany!
desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Thu, 2016-01-07 at 14:17 -0430, Robert Marcano wrote:
For discussions about if Web is ready or not to replace Firefox, it doesn't matter to much if the implementation is on Web or a lower layer, only if the user can do it. The question if this is a needed feature is another thing to discuss.
Right, so currently you can do it, but only from the command line with the 'trust', which is certainly not ideal. But I think this will only be a problem for a small minority of users.
Another features missing that I remember from using it for testing:
- No UI (yet) to add new search engines.
Yeah, nobody has complained about this is several years, but this would be good to have indeed. I think the vast majority of users are satisfied with the current options (DuckDuckGo, Google, and Bing) though. The problem with adding arbitrary search engines is that we don't want to expose users to format strings, so we have to think a bit about how the UI should work. Perhaps we should just expand the list of search engine options to match what Firefox offers.
- UI option for not automatically restore previous open tabs, this
default is annoying for me
It's a hidden option, org.gnome.Epiphany restore-session-policy. I'm in favor of exposing it in the UI, but I believe some of the other developers are opposed.
You can also close the browser with Ctrl+W (close tab; closing the last tab signals you don't want to see it again) instead of using Ctrl+Q or the close button.
- (Desired) Import bookmarks from Firefox. There is an import menu
option but it should be able to detect the Firefox profile by default, with no need to install Firefox, export and then import. Migration should be easy
This is already implemented. Trying it out now, I see the option to import from Firefox is missing for me; I get a combo box with just one option, which is pretty bad. I don't know why; it's probably a bug. You can of course do the export->import dance, but it's supposed to work automatically, like you requested.
Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 02:57 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 14:17 -0430, Robert Marcano wrote:
Another features missing that I remember from using it for testing:
- No UI (yet) to add new search engines.
Yeah, nobody has complained about this is several years, but this would be good to have indeed. I think the vast majority of users are satisfied with the current options (DuckDuckGo, Google, and Bing) though. The problem with adding arbitrary search engines is that we don't want to expose users to format strings, so we have to think a bit about how the UI should work. Perhaps we should just expand the list of search engine options to match what Firefox offers.
For what it's worth, I'm a *huge* user of arbitrary search engines. In Firefox and Chrome, I have them saved as keyword searches so I can do things like `man gcc` and `bz 1296670` and `koji sssd`
and those will immediately take me to the appropriate pages on those sites. That to me is a killer feature that would prevent me from switching (but don't let that affect the default discussion; I will still install whichever browser works best for me).
On Thu, 2016-01-07 at 15:01 -0500, Stephen Gallagher wrote:
For what it's worth, I'm a *huge* user of arbitrary search engines. In Firefox and Chrome, I have them saved as keyword searches so I can do things like `man gcc` and `bz 1296670` and `koji sssd`
and those will immediately take me to the appropriate pages on those sites. That to me is a killer feature that would prevent me from switching (but don't let that affect the default discussion; I will still install whichever browser works best for me).
Well you can use arbitrary search engines that show up in the address bar, but the UI for it is poor, and for technical reasons you cannot set an arbitrary search engine as the default search engine. That's something we should fix.
Keyword searches work out-of-the-box using DuckDuckGo, though you can't configure them yourself. That's kind of a hidden feature, though. Anyway, I don't expect you to switch personally. :)
Michael
On Thu, Jan 7, 2016, 3:02 PM Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 02:57 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 14:17 -0430, Robert Marcano wrote:
Another features missing that I remember from using it for testing:
- No UI (yet) to add new search engines.
Yeah, nobody has complained about this is several years, but this would be good to have indeed. I think the vast majority of users are satisfied with the current options (DuckDuckGo, Google, and Bing) though. The problem with adding arbitrary search engines is that we don't want to expose users to format strings, so we have to think a bit about how the UI should work. Perhaps we should just expand the list of search engine options to match what Firefox offers.
For what it's worth, I'm a *huge* user of arbitrary search engines. In Firefox and Chrome, I have them saved as keyword searches so I can do things like `man gcc` and `bz 1296670` and `koji sssd`
and those will immediately take me to the appropriate pages on those sites. That to me is a killer feature that would prevent me from switching (but don't let that affect the default discussion; I will still install whichever browser works best for me).
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iEYEARECAAYFAlaOxC4ACgkQeiVVYja6o6NZGgCgj47bmlCQ4gbM/Ab9b4zm2g3M dhIAnRst1gbeAbnzgps59ysY3XZRdSxy =kK8j
-----END PGP SIGNATURE-----
desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
You're not really the intended user for Web. The intended user is someone who is unlikely to actually run Linux. Please, forgive the bitterness, but this, apparently, serious discussion of making Web the default solution seems insane. mcantanzaro has already explained in this thread the reasons why we shouldn't default to Web (although that wasn't his intention).
On 01/07/2016 03:27 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 14:17 -0430, Robert Marcano wrote:
For discussions about if Web is ready or not to replace Firefox, it doesn't matter to much if the implementation is on Web or a lower layer, only if the user can do it. The question if this is a needed feature is another thing to discuss.
Right, so currently you can do it, but only from the command line with the 'trust', which is certainly not ideal. But I think this will only be a problem for a small minority of users.
Another features missing that I remember from using it for testing:
- No UI (yet) to add new search engines.
Yeah, nobody has complained about this is several years, but this would be good to have indeed. I think the vast majority of users are satisfied with the current options (DuckDuckGo, Google, and Bing) though. The problem with adding arbitrary search engines is that we don't want to expose users to format strings, so we have to think a bit about how the UI should work. Perhaps we should just expand the list of search engine options to match what Firefox offers.
Check Edge UI. It discover sites with support for OpenSearch and add them to the search engine selection options. No need for format strings. I expect more search engines to advertise OpenSearch now that Edge can only use that. If people know about format strings, they can use the CLI to add one.
An example is Wikipedia. It is not added by default to Edge, but if you visit en.wikipedia.org it adds the option. I would probably only show the last three discovered search engines or it can become unmanageable.
- UI option for not automatically restore previous open tabs, this
default is annoying for me
It's a hidden option, org.gnome.Epiphany restore-session-policy. I'm in favor of exposing it in the UI, but I believe some of the other developers are opposed.
You can also close the browser with Ctrl+W (close tab; closing the last tab signals you don't want to see it again) instead of using Ctrl+Q or the close button.
Still annoying the need to close each tab one by one. I hope the hidden UI is exposed.
- (Desired) Import bookmarks from Firefox. There is an import menu
option but it should be able to detect the Firefox profile by default, with no need to install Firefox, export and then import. Migration should be easy
This is already implemented. Trying it out now, I see the option to import from Firefox is missing for me; I get a combo box with just one option, which is pretty bad. I don't know why; it's probably a bug. You can of course do the export->import dance, but it's supposed to work automatically, like you requested.
Michael
desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Thu, 2016-01-07 at 15:50 -0430, Robert Marcano wrote:
Check Edge UI. It discover sites with support for OpenSearch and add them to the search engine selection options. No need for format strings. I expect more search engines to advertise OpenSearch now that Edge can only use that. If people know about format strings, they can use the CLI to add one.
An example is Wikipedia. It is not added by default to Edge, but if you visit en.wikipedia.org it adds the option. I would probably only show the last three discovered search engines or it can become unmanageable.
Something like that sounds perfect for Epiphany.
Still annoying the need to close each tab one by one. I hope the hidden UI is exposed.
I will put this on my to-do list, should be easy to implement.
- (Desired) Import bookmarks from Firefox. There is an import
menu option but it should be able to detect the Firefox profile by default, with no need to install Firefox, export and then import. Migration should be easy
This is already implemented. Trying it out now, I see the option to import from Firefox is missing for me; I get a combo box with just one option, which is pretty bad. I don't know why; it's probably a bug. You can of course do the export->import dance, but it's supposed to work automatically, like you requested.
We display an "import from Firefox" option if a bookmarks.html can be found in a subdirectory of ~/.mozilla or ~/.firefox. It looks like Firefox stopped creating bookmarks.html files; they're now saved with names like bookmarks-2016-01-06_31_bjG4ZXCpPqCFqMYySclJrA==.jsonlz4. So it looks like it would be a project to get this working again.
Michael
On Thu, 2016-01-07 at 08:38 -0500, Stephen Gallagher wrote:
With respect, "Web" is lacking many features that a workstation user would rely on. It's not ready to be a default browser for Fedora IMHO.
Hi,
Do you have any specific feature requests? I'm planning bookmark sync support, but other than that I think we're largely feature-complete.
I was just running it now to try to get a list of some of its missing features, such as a JavaScript debugging console,
Right click -> Inspect Element -> Debugger, it's the same one that's in every WebKit browser.
But this is a very advanced feature. If you're digging around into the JavaScript debugger, you're more than capable of installing Firefox or Chrome or whatever browser you prefer to work with.
but it quite literally was crashing on almost any operation except clicking on a URL link. This is a Wayland Workstation on Rawhide.
So yeah, really not feeling that this is ready.
Can you please file a bug report, or give me a link if you have and I missed it? It works great in Fedora 23. In my GNOME jhbuild environment there are some serious drawing failures due to a bug in GTK+ 3.19, which a GTK+ developer is investigating, but I'm not aware of any issues that could cause frequent crashes.
Wayland support is mostly complete. We are missing accelerated compositing (affects performance on low-end hardware) and clipboard support (copy/paste, that's a big problem) when running under Wayland. Both are about half-completed, but I cannot say when they will land.
Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 12:56 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 08:38 -0500, Stephen Gallagher wrote:
With respect, "Web" is lacking many features that a workstation user would rely on. It's not ready to be a default browser for Fedora IMHO.
Hi,
Do you have any specific feature requests? I'm planning bookmark sync support, but other than that I think we're largely feature-complete.
I was just running it now to try to get a list of some of its missing features, such as a JavaScript debugging console,
Right click -> Inspect Element -> Debugger, it's the same one that's in every WebKit browser.
But this is a very advanced feature. If you're digging around into the JavaScript debugger, you're more than capable of installing Firefox or Chrome or whatever browser you prefer to work with.
Sorry, I probably could have found that if not for the crashes below.
but it quite literally was crashing on almost any operation except clicking on a URL link. This is a Wayland Workstation on Rawhide.
So yeah, really not feeling that this is ready.
Can you please file a bug report, or give me a link if you have and I missed it? It works great in Fedora 23. In my GNOME jhbuild environment there are some serious drawing failures due to a bug in GTK+ 3.19, which a GTK+ developer is investigating, but I'm not aware of any issues that could cause frequent crashes.
I just filed https://bugzilla.redhat.com/show_bug.cgi?id=1296670
I can reproduce this trivially, so let me know if there's anything else you need to solve it.
Wayland support is mostly complete. We are missing accelerated compositing (affects performance on low-end hardware) and clipboard support (copy/paste, that's a big problem) when running under Wayland. Both are about half-completed, but I cannot say when they will land.
On Jan 7, 2016 08:33, "Zoltan Hoppar" hopparz@gmail.com wrote:
Hi,
IMHO I say that Firefox lately gets problems, and we have better browsers in the repository already. We have Web, and pretty much usable.
Unless the Ephiphany/Web guys can show they will take security concerns very seriously and have the number of team members necessary TO take Security seriously... My two cents would be: don't default to Web. Browser security is not something we can just call "good enough" given how much trust we put into the browsers we use.
Note: I'm not saying Web doesn't take security concerns seriously right now. What i am saying we need to make sure and double check that they do.
On Thu, 2016-01-07 at 08:40 -0500, Eric Griffith wrote:
Unless the Ephiphany/Web guys can show they will take security concerns very seriously and have the number of team members necessary TO take Security seriously... My two cents would be: don't default to Web. Browser security is not something we can just call "good enough" given how much trust we put into the browsers we use.
Note: I'm not saying Web doesn't take security concerns seriously right now. What i am saying we need to make sure and double check that they do.
Hi Eric,
I am responsible for Epiphany security. If you're aware of any outstanding security issues, please let me know.
We had some difficulty releasing security advisories last year due to internal changes within Apple. We now have a new contact with Apple and were able to release [1]; we hope to be able to release smaller advisories more frequently in the future now that has been solved.
Apple has a team of developers that fixes these security issues. In the rare cases where security issues are discovered that do not impact Apple, Igalia takes responsibility for fixing them. We had one such issue last year, CVE-2015-2330. (I work for Igalia.)
The above are all WebKit vulnerabilities. If security issues are discovered in Epiphany itself, Igalia will take responsibility for fixing them, but this is quite rare.
Michael
On 01/07/2016 02:32 PM, Zoltan Hoppar wrote:
Hi,
IMHO I say that Firefox lately gets problems, and we have better browsers in the repository already. We have Web, and pretty much usable.
Does Web (Epiphany) support Firefox extensions? AFAIK not so it solves nothing regards to Firefox extensions. It will provide even less Firefox extensions available than the official FF ;-)
ma.
On Thu, 2016-01-07 at 14:59 +0100, Martin Stransky wrote:
Does Web (Epiphany) support Firefox extensions? AFAIK not so it solves nothing regards to Firefox extensions. It will provide even less Firefox extensions available than the official FF ;-)
No.
We would like to support Chrome WebExtensions, but it's not a priority for us, so it probably won't happen unless someone contributes code.
Michael
On Thu, 2016-01-07 at 14:32 +0100, Zoltan Hoppar wrote:
Hi,
IMHO I say that Firefox lately gets problems, and we have better browsers in the repository already. We have Web, and pretty much usable.
Zoltan
Thanks for your voice of support. I devote ~80% of my GNOME/Fedora development time to working on Epiphany, and I'll continue to do so because I believe it provides a better out-of-the-box user experience than Firefox.
Michael
On Thu, Jan 7, 2016 at 8:29 AM, Naheem Zaffar naheemzaffar@gmail.com wrote:
ESR will only delay the problem.
Can the Fedora build add a secodary key to accept signed extensions?
This is one of the suggested solutions, but it is not currently implemented upstream.
AFAIK the long term plan is todeprecate the current method of extensions in favour of a more browser agnostic approach.
Correct.
josh
On Thu, Jan 07, 2016 at 08:33:37AM -0500, Josh Boyer wrote:
On Thu, Jan 7, 2016 at 8:29 AM, Naheem Zaffar naheemzaffar@gmail.com wrote:
ESR will only delay the problem.
Can the Fedora build add a secodary key to accept signed extensions?
This is one of the suggested solutions, but it is not currently implemented upstream.
AFAIK the long term plan is todeprecate the current method of extensions in favour of a more browser agnostic approach.
Correct.
Is it just me, or does it seem odd to take Mozilla to task for doing something with their (relatively much larger) ecosystem we also endeavor to do with Fedora's?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 09:46 AM, Paul W. Frields wrote:
On Thu, Jan 07, 2016 at 08:33:37AM -0500, Josh Boyer wrote:
On Thu, Jan 7, 2016 at 8:29 AM, Naheem Zaffar naheemzaffar@gmail.com wrote:
ESR will only delay the problem.
Can the Fedora build add a secodary key to accept signed extensions?
This is one of the suggested solutions, but it is not currently implemented upstream.
AFAIK the long term plan is todeprecate the current method of extensions in favour of a more browser agnostic approach.
Correct.
Is it just me, or does it seem odd to take Mozilla to task for doing something with their (relatively much larger) ecosystem we also endeavor to do with Fedora's?
Could you explain what you mean? Mozilla's intent is lock-in: they're providing exactly one source from which you can retrieve extensions. With Fedora, we do signature signing for trust reasons, but you are always offered a way to bypass that (or add your own keys, etc.)
On 01/07/2016 04:19 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 09:46 AM, Paul W. Frields wrote:
On Thu, Jan 07, 2016 at 08:33:37AM -0500, Josh Boyer wrote:
On Thu, Jan 7, 2016 at 8:29 AM, Naheem Zaffar naheemzaffar@gmail.com wrote:
ESR will only delay the problem.
Can the Fedora build add a secodary key to accept signed extensions?
This is one of the suggested solutions, but it is not currently implemented upstream.
AFAIK the long term plan is todeprecate the current method of extensions in favour of a more browser agnostic approach.
Correct.
Is it just me, or does it seem odd to take Mozilla to task for doing something with their (relatively much larger) ecosystem we also endeavor to do with Fedora's?
Could you explain what you mean? Mozilla's intent is lock-in: they're providing exactly one source from which you can retrieve extensions. With Fedora, we do signature signing for trust reasons, but you are always offered a way to bypass that (or add your own keys, etc.)
I'm sure you're wrong here. lock-in means you can't change your software. How is it related here? How are you locked and by what? You can use the unbranded Firefox with your own extension without any limitations.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 10:30 AM, Martin Stransky wrote:
On 01/07/2016 04:19 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 09:46 AM, Paul W. Frields wrote:
On Thu, Jan 07, 2016 at 08:33:37AM -0500, Josh Boyer wrote:
On Thu, Jan 7, 2016 at 8:29 AM, Naheem Zaffar naheemzaffar@gmail.com wrote:
ESR will only delay the problem.
Can the Fedora build add a secodary key to accept signed extensions?
This is one of the suggested solutions, but it is not currently implemented upstream.
AFAIK the long term plan is todeprecate the current method of extensions in favour of a more browser agnostic approach.
Correct.
Is it just me, or does it seem odd to take Mozilla to task for doing something with their (relatively much larger) ecosystem we also endeavor to do with Fedora's?
Could you explain what you mean? Mozilla's intent is lock-in: they're providing exactly one source from which you can retrieve extensions. With Fedora, we do signature signing for trust reasons, but you are always offered a way to bypass that (or add your own keys, etc.)
I'm sure you're wrong here. lock-in means you can't change your software. How is it related here? How are you locked and by what? You can use the unbranded Firefox with your own extension without any limitations.
Right, you can't change the software and still call it "Firefox". If you want to use "Firefox", you must only use the extensions permitted by Mozilla.
Let's take another example: iOS and Android. iOS is allows only signed software to be run on it. All software run locally on this operating system must be acquired only from the iTunes store. Android operates similarly by default, allowing only carrier-installed software and content from the Google Play store, but it also offers an option in the settings to allow users to install packages from elsewhere as well.
Mozilla in this metaphor is striving to become iOS: you can only install Mozilla-approved software. In order to retain control of your own choices, you must switch browsers (either to Icecat or similar or else to the nightly developer edition).
On Thu, Jan 7, 2016 at 10:46 AM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 10:30 AM, Martin Stransky wrote:
On 01/07/2016 04:19 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 09:46 AM, Paul W. Frields wrote:
On Thu, Jan 07, 2016 at 08:33:37AM -0500, Josh Boyer wrote:
On Thu, Jan 7, 2016 at 8:29 AM, Naheem Zaffar naheemzaffar@gmail.com wrote:
ESR will only delay the problem.
Can the Fedora build add a secodary key to accept signed extensions?
This is one of the suggested solutions, but it is not currently implemented upstream.
AFAIK the long term plan is todeprecate the current method of extensions in favour of a more browser agnostic approach.
Correct.
Is it just me, or does it seem odd to take Mozilla to task for doing something with their (relatively much larger) ecosystem we also endeavor to do with Fedora's?
Could you explain what you mean? Mozilla's intent is lock-in: they're providing exactly one source from which you can retrieve extensions. With Fedora, we do signature signing for trust reasons, but you are always offered a way to bypass that (or add your own keys, etc.)
I'm sure you're wrong here. lock-in means you can't change your software. How is it related here? How are you locked and by what? You can use the unbranded Firefox with your own extension without any limitations.
Right, you can't change the software and still call it "Firefox". If you want to use "Firefox", you must only use the extensions permitted by Mozilla.
Let's take another example: iOS and Android. iOS is allows only signed software to be run on it. All software run locally on this operating system must be acquired only from the iTunes store. Android operates similarly by default, allowing only carrier-installed software and content from the Google Play store, but it also offers an option in the settings to allow users to install packages from elsewhere as well.
Mozilla in this metaphor is striving to become iOS: you can only install Mozilla-approved software. In order to retain control of your own choices, you must switch browsers (either to Icecat or similar or else to the nightly developer edition).
RHEL provides a set of software that is curated for quality and functionality. It, by default, signs it's packages and only allows signed packages to be installed. In order to retain control of your own choices, you must acknowledge that you are installing a 3rd party package and explicitly disable this check. That in turn may invalidate your support subscription, which is the only reason you have RHEL to begin with. If you choose to rebuild the software that does this, you must remove Red Hat trademarks as you cannot use them. RHEL in your metaphor would also be striving to become iOS.
I do not believe your metaphor is an accurate reflection of RHEL or Firefox.
josh
On 01/07/2016 04:54 PM, Josh Boyer wrote:
RHEL provides a set of software that is curated for quality and functionality. It, by default, signs it's packages and only allows signed packages to be installed.
This is not correct. A “yum install“ command which is given file system paths of the packages to install will not check signatures on those packages.
Florian
Right, you can't change the software and still call it "Firefox". If you want to use "Firefox", you must only use the extensions permitted by Mozilla.
You can change it and still call it Firefox. What you can't do is redistribute the modified version and keep calling it Firefox. Not very different from Apache License trademark clause.
----- Original Message ----- <snip>
Let's take another example: iOS and Android. iOS is allows only signed software to be run on it. All software run locally on this operating system must be acquired only from the iTunes store.
No, you can sideload apps with iOS devices, probably even using Linux and the imobiledevice utilities, and certainly with XCode on OSX.
Android operates similarly by default, allowing only carrier-installed software and content from the Google Play store, but it also offers an option in the settings to allow users to install packages from elsewhere as well.
Mozilla in this metaphor is striving to become iOS
Best get the metaphor technically correct then ;)
: you can only install Mozilla-approved software. In order to retain control of your own choices, you must switch browsers (either to Icecat or similar or else to the nightly developer edition).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 01:10 PM, Bastien Nocera wrote:
----- Original Message ----- <snip>
Let's take another example: iOS and Android. iOS is allows only signed software to be run on it. All software run locally on this operating system must be acquired only from the iTunes store.
No, you can sideload apps with iOS devices, probably even using Linux and the imobiledevice utilities, and certainly with XCode on OSX.
No, you cannot do this without rooting the phone. Even with XCode on OSX, you are required to have a developer account with Apple and then to test they actually require you to submit your binary to them and then they give you a special version of your binary tied to a specific device. It's horrible.
Android operates similarly by default, allowing only carrier-installed software and content from the Google Play store, but it also offers an option in the settings to allow users to install packages from elsewhere as well.
Mozilla in this metaphor is striving to become iOS
Best get the metaphor technically correct then ;)
Well, my point was mainly that on Android it's possible to install add-on software from anywhere by flipping a switch in settings. With Apple, it's only possible to install add-on software through their walled garden or by breaking the OS entirely. Mozilla's new signature approach is far closer to the latter (and it doesn't need to be!).
Honestly, I'd have far fewer issues with this if it was possible for the system administrator to add a new CA certificate that's trusted to sign extensions. That would solve the Fedora problem as well as for end-users.
: you can only install Mozilla-approved software. In order to retain control of your own choices, you must switch browsers (either to Icecat or similar or else to the nightly developer edition).
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Thu, Jan 07, 2016 at 10:46:29AM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 10:30 AM, Martin Stransky wrote:
On 01/07/2016 04:19 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 09:46 AM, Paul W. Frields wrote:
On Thu, Jan 07, 2016 at 08:33:37AM -0500, Josh Boyer wrote:
On Thu, Jan 7, 2016 at 8:29 AM, Naheem Zaffar naheemzaffar@gmail.com wrote:
ESR will only delay the problem.
Can the Fedora build add a secodary key to accept signed extensions?
This is one of the suggested solutions, but it is not currently implemented upstream.
AFAIK the long term plan is todeprecate the current method of extensions in favour of a more browser agnostic approach.
Correct.
Is it just me, or does it seem odd to take Mozilla to task for doing something with their (relatively much larger) ecosystem we also endeavor to do with Fedora's?
Could you explain what you mean? Mozilla's intent is lock-in: they're providing exactly one source from which you can retrieve extensions. With Fedora, we do signature signing for trust reasons, but you are always offered a way to bypass that (or add your own keys, etc.)
I'm sure you're wrong here. lock-in means you can't change your software. How is it related here? How are you locked and by what? You can use the unbranded Firefox with your own extension without any limitations.
Right, you can't change the software and still call it "Firefox". If you want to use "Firefox", you must only use the extensions permitted by Mozilla.
Let's take another example: iOS and Android. iOS is allows only signed software to be run on it. All software run locally on this operating system must be acquired only from the iTunes store. Android operates similarly by default, allowing only carrier-installed software and content from the Google Play store, but it also offers an option in the settings to allow users to install packages from elsewhere as well.
Mozilla in this metaphor is striving to become iOS: you can only install Mozilla-approved software. In order to retain control of your own choices, you must switch browsers (either to Icecat or similar or else to the nightly developer edition).
The nightly developer edition is still Firefox, just with new stuff. You don't have to give up the browser entirely. It seems to me the XO in its normal operating mode was a similar case here. I hope no one would claim that was non-free.
Am Donnerstag, den 07.01.2016, 16:37 -0500 schrieb Paul W. Frields:
The nightly developer edition is still Firefox, just with new stuff. You don't have to give up the browser entirely. It seems to me the XO in its normal operating mode was a similar case here. I hope no one would claim that was non-free.
Why not shipping both versions (dev-edition is not installed by default) of Firefox and make the packaged addons depending on the developer edition? So if someone needs packaged addons or wants bleeding edge features he could replace stable Firefox with the developer edition.
IMHO this would be a suitable solution.
On Thu, Jan 7, 2016 at 2:58 PM, Heiko Adams ml@fedora-blog.de wrote:
Am Donnerstag, den 07.01.2016, 16:37 -0500 schrieb Paul W. Frields:
The nightly developer edition is still Firefox, just with new stuff. You don't have to give up the browser entirely. It seems to me the XO in its normal operating mode was a similar case here. I hope no one would claim that was non-free.
Why not shipping both versions (dev-edition is not installed by default) of Firefox and make the packaged addons depending on the developer edition? So if someone needs packaged addons or wants bleeding edge features he could replace stable Firefox with the developer edition.
IMHO this would be a suitable solution.
More work for someone to do? If someone wants to do that, OK, but otherwise I think the ESR version is more appropriate balance between stable and current. Otherwise just get binaries of the developer version from Mozilla?
Chris Murphy píše v Čt 07. 01. 2016 v 15:16 -0700:
On Thu, Jan 7, 2016 at 2:58 PM, Heiko Adams ml@fedora-blog.de wrote:
Am Donnerstag, den 07.01.2016, 16:37 -0500 schrieb Paul W. Frields:
The nightly developer edition is still Firefox, just with new stuff. You don't have to give up the browser entirely. It seems to me the XO in its normal operating mode was a similar case here. I hope no one would claim that was non-free.
Why not shipping both versions (dev-edition is not installed by default) of Firefox and make the packaged addons depending on the developer edition? So if someone needs packaged addons or wants bleeding edge features he could replace stable Firefox with the developer edition.
IMHO this would be a suitable solution.
More work for someone to do? If someone wants to do that, OK, but otherwise I think the ESR version is more appropriate balance between stable and current. Otherwise just get binaries of the developer version from Mozilla?
It applies to Iceweasel, too. The Firefox team in Red Hat is not really in the position to throw resources into new things. We already have more development requirements than we can possibly do. So we'll keep packaging Firefox for Fedora because that's the browser we need to support in RHEL, too. So if the decision is Iceweasel (looks like a lot of people in the discussion find Icecat as not so good option), then the question also is who's going to maintain it.
Jiri
Am Donnerstag, den 07.01.2016, 16:37 -0500 schrieb Paul W. Frields:
The nightly developer edition is still Firefox, just with new stuff. You don't have to give up the browser entirely. It seems to me the XO in its normal operating mode was a similar case here. I hope no one would claim that was non-free.
Just another point: Do we know *how many* users use the packaged addons? IMHO it would be a bad idea to annoy the majority of the users with one of the suggested solutions while the problem only affects a minority.
Is it just me, or does it seem odd to take Mozilla to task for doing something with their (relatively much larger) ecosystem we also endeavor to do with Fedora's?
Could you explain what you mean?
Mozilla provides an API to sign extensions outside from their infrastructure. It's our infrastructural decision (correctly in my opinion) that prohibits this type of implementation.
On Thu, Jan 7, 2016 at 9:15 AM, Nikos Roussos comzeradd@fedoraproject.org wrote:
Is it just me, or does it seem odd to take Mozilla to task for doing something with their (relatively much larger) ecosystem we also endeavor to do with Fedora's?
Could you explain what you mean?
Mozilla provides an API to sign extensions outside from their infrastructure. It's our infrastructural decision (correctly in my opinion) that prohibits this type of implementation.
Why is it OK for Fedora infrastructure to sign the bootloader, the kernel, and kernel modules, but not application extensions?
On Thu, Jan 07, 2016 at 11:06:35AM -0700, Chris Murphy wrote:
Mozilla provides an API to sign extensions outside from their infrastructure. It's our infrastructural decision (correctly in my opinion) that prohibits this type of implementation.
Why is it OK for Fedora infrastructure to sign the bootloader, the kernel, and kernel modules, but not application extensions?
I don't think that's the question. The problem is that there isn't a way for us to sign them -- the above is just an API for Mozilla to sign them over the network, right?
On Thu, Jan 7, 2016 at 11:14 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Jan 07, 2016 at 11:06:35AM -0700, Chris Murphy wrote:
Mozilla provides an API to sign extensions outside from their infrastructure. It's our infrastructural decision (correctly in my opinion) that prohibits this type of implementation.
Why is it OK for Fedora infrastructure to sign the bootloader, the kernel, and kernel modules, but not application extensions?
I don't think that's the question. The problem is that there isn't a way for us to sign them -- the above is just an API for Mozilla to sign them over the network, right?
OK but shim is signed by Microsoft, which is clearly outside our infrastructure. The assertion that Fedora infrastructure prohibits external signing of things to be included in Fedora would seem to be incorrect, unless I'm misunderstanding some nuance.
Are there Firefox extensions only hosted by Fedora that aren't available in AMO? Why can't these be made available through AMO instead? Off hand it doesn't really make sense to me that a whole separate extension signing infrastructure needs to be created.
If there's some reason certain add-ons can't be in AMO, but need to be in Fedora, (and same for Chrome and any other browser) then yeah, we're going to need code signing infrastructure implemented for each of these browsers. I don't see a way around that. Disabling code signed in the browser is a bad idea, I don't like that at all, certainly not be default, that'd be a huge loss of trust in my mind if the default browser weren't doing everything it can to avoid executing malicious software.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 02:01 PM, Chris Murphy wrote:
On Thu, Jan 7, 2016 at 11:14 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Jan 07, 2016 at 11:06:35AM -0700, Chris Murphy wrote:
Mozilla provides an API to sign extensions outside from their infrastructure. It's our infrastructural decision (correctly in my opinion) that prohibits this type of implementation.
Why is it OK for Fedora infrastructure to sign the bootloader, the kernel, and kernel modules, but not application extensions?
I don't think that's the question. The problem is that there isn't a way for us to sign them -- the above is just an API for Mozilla to sign them over the network, right?
OK but shim is signed by Microsoft, which is clearly outside our infrastructure. The assertion that Fedora infrastructure prohibits external signing of things to be included in Fedora would seem to be incorrect, unless I'm misunderstanding some nuance.
You do not have to run Fedora with a signed shim. That's an added measure of security. You can turn this feature off trivially and still run Fedora. You can no longer do this with Firefox.
Are there Firefox extensions only hosted by Fedora that aren't available in AMO? Why can't these be made available through AMO instead? Off hand it doesn't really make sense to me that a whole separate extension signing infrastructure needs to be created.
No, but that's not really the point. One of the advantages to having extensions in Fedora proper is that it becomes much easier to produce a standard build for a company or home that has certain extensions available to all users, without all users needing to voluntarily download them from somewhere into their own Firefox profile. This can be for convenience or sometimes for compliance with a company's policies.
If there's some reason certain add-ons can't be in AMO, but need to be in Fedora, (and same for Chrome and any other browser) then yeah, we're going to need code signing infrastructure implemented for each of these browsers. I don't see a way around that. Disabling code signed in the browser is a bad idea, I don't like that at all, certainly not be default, that'd be a huge loss of trust in my mind if the default browser weren't doing everything it can to avoid executing malicious software.
Well, no extension gets added without the user's permission. This really only protects against trojans like installing an extension from a random website rather than a trusted source like AMO or Fedora repositories. I understand the intent and even approve of the implementation... almost. It needs to have a way for someone besides Mozilla to sign extensions or else it is producing a walled-garden. I don't necessarily trust that this won't lead to 1) The extension store! Pay $$$ for adblock software or 2) The NSA mandates that all extensions add on a mandatory reporting function, etc.
For some users, that peace of mind is necessary. In general, Fedora has been good about providing that up to now; I don't like sacrificing that degree of control to another organization.
On Thu, Jan 7, 2016 at 9:54 PM, Stephen Gallagher sgallagh@redhat.com wrote:
Are there Firefox extensions only hosted by Fedora that aren't available in AMO? Why can't these be made available through AMO instead? Off hand it doesn't really make sense to me that a whole separate extension signing infrastructure needs to be created.
No, but that's not really the point. One of the advantages to having extensions in Fedora proper is that it becomes much easier to produce a standard build for a company or home that has certain extensions available to all users, without all users needing to voluntarily download them from somewhere into their own Firefox profile. This can be for convenience or sometimes for compliance with a company's policies.
If you do the effort of providing a custom build you can also create a custom build of Firefox with certain signed extensions, like the Tor Browser does.
On Thu, Jan 7, 2016 at 12:54 PM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 02:01 PM, Chris Murphy wrote:
OK but shim is signed by Microsoft, which is clearly outside our infrastructure. The assertion that Fedora infrastructure prohibits external signing of things to be included in Fedora would seem to be incorrect, unless I'm misunderstanding some nuance.
You do not have to run Fedora with a signed shim. That's an added measure of security. You can turn this feature off trivially and still run Fedora. You can no longer do this with Firefox.
Secure Boot is not optional on all hardware. And even on hardware where there's a knob to disable it, it's less trivial to find it and disable it than to install Epiphany or Icecat, should the user want a browser that doesn't enforce code signing.
Are there Firefox extensions only hosted by Fedora that aren't available in AMO? Why can't these be made available through AMO instead? Off hand it doesn't really make sense to me that a whole separate extension signing infrastructure needs to be created.
No, but that's not really the point. One of the advantages to having extensions in Fedora proper is that it becomes much easier to produce a standard build for a company or home that has certain extensions available to all users, without all users needing to voluntarily download them from somewhere into their own Firefox profile. This can be for convenience or sometimes for compliance with a company's policies.
I recognize there might be some deployment inconvenience for multi user environments. But it doesn't look like an insurmountable barrier. How hard is it to create your own package and push it out to machines? I'd have to do that same thing on OS X or Windows, because they certainly don't offer their own repository of Firefox extensions.
If there's some reason certain add-ons can't be in AMO, but need to be in Fedora, (and same for Chrome and any other browser) then yeah, we're going to need code signing infrastructure implemented for each of these browsers. I don't see a way around that. Disabling code signed in the browser is a bad idea, I don't like that at all, certainly not be default, that'd be a huge loss of trust in my mind if the default browser weren't doing everything it can to avoid executing malicious software.
Well, no extension gets added without the user's permission. This really only protects against trojans like installing an extension from a random website rather than a trusted source like AMO or Fedora repositories. I understand the intent and even approve of the implementation... almost. It needs to have a way for someone besides Mozilla to sign extensions or else it is producing a walled-garden. I don't necessarily trust that this won't lead to 1) The extension store! Pay $$$ for adblock software or 2) The NSA mandates that all extensions add on a mandatory reporting function, etc.
The signing requirement only applies to add-on types 2 and 32, so themes and language packs aren't included in this. And it looks like nightlies and the ESR versions will still offer a functional disable switch. There's quite a bit of maneuvering room here, even if though it would be better if additional keys were allowed but I don't know how they'd implement that and not consider it a substantial modification.
The "submitting them to AMO" and then putting them into Fedora repository for distribution seems like the same thing as what's done with shim though.
For some users, that peace of mind is necessary. In general, Fedora has been good about providing that up to now; I don't like sacrificing that degree of control to another organization.
OK well at this point it looks like the short term Fedora 24 time frame choices are:
1. Firefox <current> which likely won't provide a code signing check disable knob. But users still have the choice to download Firefox ESR, or nightly, or developer versions which do have a know. Or install Epiphany or Icecat.
2. Firefox ESR 45, which by default enforces signed extensions, but has a knob to disable this. The download it is suggests ESR 45 for the life of Fedora 24 at least by default; the user would have to manually install a different Firefox package to be on the current rolling release.
3. Ephiphany.
4. Icecat
I have no real strong preference between 1 and 2. Both protect users by default. Both provide an option for users to opt out of enforced code signing checks.
On Thu, 2016-01-07 at 13:48 -0700, Chris Murphy wrote:
OK well at this point it looks like the short term Fedora 24 time frame choices are:
- Firefox <current> which likely won't provide a code signing check
disable knob. But users still have the choice to download Firefox ESR, or nightly, or developer versions which do have a know. Or install Epiphany or Icecat.
- Firefox ESR 45, which by default enforces signed extensions, but
has a knob to disable this. The download it is suggests ESR 45 for the life of Fedora 24 at least by default; the user would have to manually install a different Firefox package to be on the current rolling release.
Ephiphany.
Icecat
I have no real strong preference between 1 and 2. Both protect users by default. Both provide an option for users to opt out of enforced code signing checks.
There is also 5. Debian's Iceweasel, which is more similar to upstream Firefox than Icecat. Icecat has some nice privacy features that we probably want, but it also comes with LibreJS. I strongly recommend against shipping LibreJS in our default web browser.
I think 2. Firefox ESR seems like the best option for F22 and F23. I don't think that's a good option for F24; we should be shipping the latest version of Firefox/Iceanimal going forward.
Michael
On Thu, Jan 7, 2016 at 2:57 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, 2016-01-07 at 13:48 -0700, Chris Murphy wrote:
OK well at this point it looks like the short term Fedora 24 time frame choices are:
- Firefox <current> which likely won't provide a code signing check
disable knob. But users still have the choice to download Firefox ESR, or nightly, or developer versions which do have a know. Or install Epiphany or Icecat.
- Firefox ESR 45, which by default enforces signed extensions, but
has a knob to disable this. The download it is suggests ESR 45 for the life of Fedora 24 at least by default; the user would have to manually install a different Firefox package to be on the current rolling release.
Ephiphany.
Icecat
I have no real strong preference between 1 and 2. Both protect users by default. Both provide an option for users to opt out of enforced code signing checks.
There is also 5. Debian's Iceweasel, which is more similar to upstream Firefox than Icecat. Icecat has some nice privacy features that we probably want, but it also comes with LibreJS. I strongly recommend against shipping LibreJS in our default web browser.
I think 2. Firefox ESR seems like the best option for F22 and F23. I don't think that's a good option for F24; we should be shipping the latest version of Firefox/Iceanimal going forward.
I agree.
However, while Firefox ESR for Fedora 22 seems reasonable in any case, I'm unconvinced it should apply to Fedora 23 in the context of "we should ship the latest Firefox" going forward. Fedora 23 is the current release until May. So if Fedora 23 switches to ESR, then Fedora isn't shipping the latest Firefox until Fedora 24 ships in May.
Stephen Gallagher píše v Čt 07. 01. 2016 v 14:54 -0500:
On 01/07/2016 02:01 PM, Chris Murphy wrote:
On Thu, Jan 7, 2016 at 11:14 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Thu, Jan 07, 2016 at 11:06:35AM -0700, Chris Murphy wrote:
Mozilla provides an API to sign extensions outside from their infrastructure. It's our infrastructural decision (correctly in my opinion) that prohibits this type of implementation.
Why is it OK for Fedora infrastructure to sign the bootloader, the kernel, and kernel modules, but not application extensions?
I don't think that's the question. The problem is that there isn't a way for us to sign them -- the above is just an API for Mozilla to sign them over the network, right?
OK but shim is signed by Microsoft, which is clearly outside our infrastructure. The assertion that Fedora infrastructure prohibits external signing of things to be included in Fedora would seem to be incorrect, unless I'm misunderstanding some nuance.
You do not have to run Fedora with a signed shim. That's an added measure of security. You can turn this feature off trivially and still run Fedora. You can no longer do this with Firefox.
Are there Firefox extensions only hosted by Fedora that aren't available in AMO? Why can't these be made available through AMO instead? Off hand it doesn't really make sense to me that a whole separate extension signing infrastructure needs to be created.
No, but that's not really the point. One of the advantages to having extensions in Fedora proper is that it becomes much easier to produce a standard build for a company or home that has certain extensions available to all users, without all users needing to voluntarily download them from somewhere into their own Firefox profile. This can be for convenience or sometimes for compliance with a company's policies.
How many extensions are packaged in Fedora repositories? 6? 6 out of thousands available for Firefox. Yes, it's easier to make a standard build when you happen to need an extension that is packaged in Fedora repositories, but what are the odds? And if you take time to package any other extension yourself, it's not a problem for you to package a simple script that will download the extension from Mozilla. I don't see how it makes it much more difficult.
Jiri
On Fri, 2016-01-08 at 11:25 +0100, Jiri Eischmann wrote:
How many extensions are packaged in Fedora repositories? 6? 6 out of thousands available for Firefox. Yes, it's easier to make a standard build when you happen to need an extension that is packaged in Fedora repositories, but what are the odds? And if you take time to package any other extension yourself, it's not a problem for you to package a simple script that will download the extension from Mozilla. I don't see how it makes it much more difficult.
Yes, this is why we will never ask the user to pick software during installation. We pick a reasonable default instead. We can't please everyone, but that is what the software center is for.
Michael
On 1/7/2016 12:06 PM, Chris Murphy wrote:
On Thu, Jan 7, 2016 at 9:15 AM, Nikos Roussos comzeradd@fedoraproject.org wrote:
Is it just me, or does it seem odd to take Mozilla to task for doing something with their (relatively much larger) ecosystem we also endeavor to do with Fedora's?
Could you explain what you mean?
Mozilla provides an API to sign extensions outside from their infrastructure. It's our infrastructural decision (correctly in my opinion) that prohibits this type of implementation.
Why is it OK for Fedora infrastructure to sign the bootloader, the kernel, and kernel modules, but not application extensions?
"Just my two cents. Firefox cannot, and I repeat, cannot be dropped. I am not trying to tell anyone what to do, but if firefox is dropped, fedora will no longer be fully accessible to the visually impaired out of the box. Firefox is our only viable web browser at the moment. There are others, but they each have their own accessibility issues that keep them from being completely usable. Epiphany, aka web, has serious webkit gtk issues joanmeri diggs has filed, but as far as I know have not been fixed upstream. I could be wrong about this. This keeps some webpages from loading at all in epiphany, while others have controls, edit fields, check boxes, etc that orca cannot see. Chromium is utterly inaccessible. This is largely because google in it's wisdom does not interface with atk and at-spi, instead preferring you to download a 3rd party extension, known as chromevox, to use the browser, with their possibly non open source speech voices. There are command line switches you can use to make it use speech-dispatcher, but the support is limited and not really maintained, plus google complains when this is done. To be fair, google does not even make chromium/chrome usable on windows, so at least they're consistent. There's midori, which is what xfce uses I believe, but it has the same issues as epiphany. Once the webkitgtk issues are fixed, these browsers, as well as yelp, will be a lot more accessible with orca.
Sorry for my tone, I kind of came into this a bit late.
Just my two scents Kendell clark"
Firefox is our only viable web browser at the moment.
Here's an interesting idea for Workstation. There's a GNOME welcome screen that appears right after you first install Fedora and you login for the first time. What if you presented a setup screen that asked what you would like your default browser to be from either Firefox, Google Chrome and lastly GNOME's own in-house browser product?
---- What is your preferred default web-browser? - Google Chrome - Firefox - GNOME Web (default) ----
After selection a quick warning should appear about Google Chrome and Firefox regarding any relevant/present proprietary software, privacy or other items the user should be informed about.
When the user runs a Live Image for testing, without installing, you simply bundle it with GNOME's browser by default so they can read HTML documentation or look around or lookup information relevant to the installation they're about to perform.
There are a few problems with the browsers above though. With Google Chrome you would have to either package Chromium in Fedora or download the RPM directly from Google's own official Linux repo. Mozilla does not package an official RPM or have any Linux repo so Fedora needs to be able to provide both Firefox and Firefox Nightly for users in it's own repos. Providing Firefox Nightly would allow Linux users the same ease of installation as other Firefox users on Windows/Mac. Then GNOME Web might be in beta stage still and not ready for real world use.
GNOME Web is the ideal default choice because it conforms to the most up-to-date GNOME 3 HIG but is it ready?
Any thoughts?
On Thu, Jan 7, 2016 at 7:27 PM, kendell clark coffeekingms@gmail.com wrote:
On 1/7/2016 12:06 PM, Chris Murphy wrote:
On Thu, Jan 7, 2016 at 9:15 AM, Nikos Roussos comzeradd@fedoraproject.org wrote:
Is it just me, or does it seem odd to take Mozilla to task for
doing something with their (relatively much larger) ecosystem we also endeavor to do with Fedora's?
Could you explain what you mean?
Mozilla provides an API to sign extensions outside from their infrastructure. It's our infrastructural decision (correctly in my opinion) that prohibits this type of implementation.
Why is it OK for Fedora infrastructure to sign the bootloader, the kernel, and kernel modules, but not application extensions?
"Just my two cents. Firefox cannot, and I repeat, cannot be dropped. I am not trying to tell anyone what to do, but if firefox is dropped, fedora will no longer be fully accessible to the visually impaired out of the box. Firefox is our only viable web browser at the moment. There are others, but they each have their own accessibility issues that keep them from being completely usable. Epiphany, aka web, has serious webkit gtk issues joanmeri diggs has filed, but as far as I know have not been fixed upstream. I could be wrong about this. This keeps some webpages from loading at all in epiphany, while others have controls, edit fields, check boxes, etc that orca cannot see. Chromium is utterly inaccessible. This is largely because google in it's wisdom does not interface with atk and at-spi, instead preferring you to download a 3rd party extension, known as chromevox, to use the browser, with their possibly non open source speech voices. There are command line switches you can use to make it use speech-dispatcher, but the support is limited and not really maintained, plus google complains when this is done. To be fair, google does not even make chromium/chrome usable on windows, so at least they're consistent. There's midori, which is what xfce uses I believe, but it has the same issues as epiphany. Once the webkitgtk issues are fixed, these browsers, as well as yelp, will be a lot more accessible with orca.
Sorry for my tone, I kind of came into this a bit late.
Just my two scents Kendell clark"
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Fri, Jan 8, 2016 at 8:17 AM, Alex G.S. alxgrtnstrngl@gmail.com wrote:
Firefox is our only viable web browser at the moment.
Here's an interesting idea for Workstation. There's a GNOME welcome screen that appears right after you first install Fedora and you login for the first time. What if you presented a setup screen that asked what you would like your default browser to be from either Firefox, Google Chrome and lastly GNOME's own in-house browser product?
Chrome? Since when do we ship non-free software? Anyway, prompting the user on first run is not a very good idea. Imagine we do this for other apps too. Why choose a default image viewer or video player? Let's prompt the user on first run to choose one.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 08:29 AM, Naheem Zaffar wrote:
ESR will only delay the problem.
Right, that was proposed as a short-term solution for stable Fedora releases while a better one was implemented.
Can the Fedora build add a secodary key to accept signed extensions?
No, this is not possible at this time. It's one of the things we're asking Mozilla to add.
AFAIK the long term plan is todeprecate the current method of extensions in favour of a more browser agnostic approach.
Whatever the mechanism, the basic problem is that Fedora cannot ship any extensions by default. This may impact Workstation in other ways beyond simply the Firefox name: as I recall there have been discussions of having Workstation ship with a customized user-agent extension as well as possibly a theming extension. Neither of these will be possible because Firefox can no longer load it.
(Some other useful additions might have been some of the privacy extensions; I know people were working on that).
One alternative would be for us to switch to using Icecat as the default browser, possibly modifying the .desktop file to just report itself as "Browser". It is fundamentally the same browser as Firefox, except not bound by the "you cannot change anything and still call it Firefox" rules.
On 7 January 2016 at 13:26, Jiri Eischmann <eischmann@redhat.com mailto:eischmann@redhat.com> wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
The problem in short: The last release of Firefox doesn't allow the user to install add-ons which are not signed by Mozilla by default, in the next version, you won't even be able to disable this behavior. This means that a couple of add-ons that are packaged by Fedora won't work.
In my opinion, this problem has an impact on a relatively small number of users while suggested solutions will have an impact on majority of Workstation users. The author of the original ticket recommends Firefox is removed altogether if Mozilla doesn't change their plan, another suggestion is to switch to ESR which would mean that Fedora would have as conservative approach to Firefox updates as RHEL.
Firefox is probably the most important desktop app in Fedora, so I wonder whether the Workstation working group should voice its opinion in this before any decision is made.
Jiri -- desktop mailing list desktop@lists.fedoraproject.org mailto:desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject
.org
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject
.org
Stephen Gallagher píše v Čt 07. 01. 2016 v 08:34 -0500:
On 01/07/2016 08:29 AM, Naheem Zaffar wrote:
ESR will only delay the problem.
Right, that was proposed as a short-term solution for stable Fedora releases while a better one was implemented.
Can the Fedora build add a secodary key to accept signed extensions?
No, this is not possible at this time. It's one of the things we're asking Mozilla to add.
AFAIK the long term plan is todeprecate the current method of extensions in favour of a more browser agnostic approach.
Whatever the mechanism, the basic problem is that Fedora cannot ship any extensions by default. This may impact Workstation in other ways beyond simply the Firefox name: as I recall there have been discussions of having Workstation ship with a customized user-agent extension as well as possibly a theming extension. Neither of these will be possible because Firefox can no longer load it.
The user-agent is patched directly in Firefox. No extension needed. Theming is IMHO a branding issue. Changing the default theme may also require unbranding Firefox no matter if we can ship our extensions or not. But those are just potential situations. AFAIK we are not seriously considering to ship any extension in the default installation now. We don't have to get rid of Firefox brand just because we might want to ship some in the future. When the time comes, we can trade Firefox brand for a particular extension if it brings more value to us. Unbranded Firefox is already in repositories. It wouldn't require much.
(Some other useful additions might have been some of the privacy extensions; I know people were working on that).
One alternative would be for us to switch to using Icecat as the default browser, possibly modifying the .desktop file to just report itself as "Browser". It is fundamentally the same browser as Firefox, except not bound by the "you cannot change anything and still call it Firefox" rules.
Sure, we can default to Icecat, but even if Icecat is the default browser I don't see a reason why Firefox can't be in repositories. And I also think it should be a decision of working groups or spins what app from the Fedora repositories they pick as default in their installation.
On 7 January 2016 at 13:26, Jiri Eischmann <eischmann@redhat.com mailto:eischmann@redhat.com> wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
The problem in short: The last release of Firefox doesn't allow the user to install add-ons which are not signed by Mozilla by default, in the next version, you won't even be able to disable this behavior. This means that a couple of add-ons that are packaged by Fedora won't work.
In my opinion, this problem has an impact on a relatively small number of users while suggested solutions will have an impact on majority of Workstation users. The author of the original ticket recommends Firefox is removed altogether if Mozilla doesn't change their plan, another suggestion is to switch to ESR which would mean that Fedora would have as conservative approach to Firefox updates as RHEL.
Firefox is probably the most important desktop app in Fedora, so I wonder whether the Workstation working group should voice its opinion in this before any decision is made.
Jiri -- desktop mailing list desktop@lists.fedoraproject.org mailto:desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproj ect
.org
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproj ect
.org
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraprojec t.org
On Thu, 2016-01-07 at 15:04 +0100, Jiri Eischmann wrote:
But those are just potential situations. AFAIK we are not seriously considering to ship any extension in the default installation now. We don't have to get rid of Firefox brand just because we might want to ship some in the future. When the time comes, we can trade Firefox brand for a particular extension if it brings more value to us. Unbranded Firefox is already in repositories. It wouldn't require much.
I agree. The ticket is full of the hyperbole that we have come to expect from its author. Dropping firefox because of this when it is no not even causing any problems for us is entirely uncalled for.
On 01/07/2016 03:04 PM, Jiri Eischmann wrote:
Stephen Gallagher píše v Čt 07. 01. 2016 v 08:34 -0500:
On 01/07/2016 08:29 AM, Naheem Zaffar wrote:
ESR will only delay the problem.
Right, that was proposed as a short-term solution for stable Fedora releases while a better one was implemented.
Can the Fedora build add a secodary key to accept signed extensions?
No, this is not possible at this time. It's one of the things we're asking Mozilla to add.
AFAIK the long term plan is todeprecate the current method of extensions in favour of a more browser agnostic approach.
Whatever the mechanism, the basic problem is that Fedora cannot ship any extensions by default. This may impact Workstation in other ways beyond simply the Firefox name: as I recall there have been discussions of having Workstation ship with a customized user-agent extension as well as possibly a theming extension. Neither of these will be possible because Firefox can no longer load it.
The user-agent is patched directly in Firefox. No extension needed. Theming is IMHO a branding issue. Changing the default theme may also require unbranding Firefox no matter if we can ship our extensions or not.
Well, that's generally incorrect. The branding allows to ship any theme/extension with Firefox by default. (Signed in the future).
We don't ship the gnome-theme bu default because it provides extra maintenance cost (update to each FF release).
The branding is not related to extensions, only to the browser itself. This is also reason why Mozilla introduces the signing - to have more control about final user experience under the "Firefox" brand.
IMHO it's like we don't allow to add unfree (or somehow crafted) packages to Fedora and ship that under Fedora name.
But those are just potential situations. AFAIK we are not seriously considering to ship any extension in the default installation now. We don't have to get rid of Firefox brand just because we might want to ship some in the future. When the time comes, we can trade Firefox brand for a particular extension if it brings more value to us. Unbranded Firefox is already in repositories. It wouldn't require much.
Ubuntu does that (ship Ubuntu Firefox extension by default with the Firefox). And they ship branded browser with it. I have asked the Ubuntu guys but no reply yet...let's see how they handle this.
(Some other useful additions might have been some of the privacy extensions; I know people were working on that).
One alternative would be for us to switch to using Icecat as the default browser, possibly modifying the .desktop file to just report itself as "Browser". It is fundamentally the same browser as Firefox, except not bound by the "you cannot change anything and still call it Firefox" rules.
Sure, we can default to Icecat, but even if Icecat is the default browser I don't see a reason why Firefox can't be in repositories. And I also think it should be a decision of working groups or spins what app from the Fedora repositories they pick as default in their installation.
On 7 January 2016 at 13:26, Jiri Eischmann <eischmann@redhat.com mailto:eischmann@redhat.com> wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
The problem in short: The last release of Firefox doesn't allow the user to install add-ons which are not signed by Mozilla by default, in the next version, you won't even be able to disable this behavior. This means that a couple of add-ons that are packaged by Fedora won't work.
In my opinion, this problem has an impact on a relatively small number of users while suggested solutions will have an impact on majority of Workstation users. The author of the original ticket recommends Firefox is removed altogether if Mozilla doesn't change their plan, another suggestion is to switch to ESR which would mean that Fedora would have as conservative approach to Firefox updates as RHEL.
Firefox is probably the most important desktop app in Fedora, so I wonder whether the Workstation working group should voice its opinion in this before any decision is made.
Jiri -- desktop mailing list desktop@lists.fedoraproject.org mailto:desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproj ect
.org
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproj ect
.org
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraprojec t.org
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
One alternative would be for us to switch to using Icecat as the default browser, possibly modifying the .desktop file to just report itself as "Browser". It is fundamentally the same browser as Firefox, except not bound by the "you cannot change anything and still call it Firefox" rules.
But our users expect Firefox, not Icecat. Besides doesn't Icecat forbids you to install non-free extensions? So with that move we would actually exclude more extensions from our users than shipping Firefox.
Whatever the mechanism, the basic problem is that Fedora cannot ship any extensions by default. This may impact Workstation in other ways beyond simply the Firefox name: as I recall there have been discussions of having Workstation ship with a customized user-agent extension as well as possibly a theming extension. Neither of these will be possible because Firefox can no longer load it.
(Some other useful additions might have been some of the privacy extensions; I know people were working on that).
One alternative would be for us to switch to using Icecat as the default browser, possibly modifying the .desktop file to just report itself as "Browser". It is fundamentally the same browser as Firefox, except not bound by the "you cannot change anything and still call it Firefox" rules.
As Jiri mentioned in another email for Firefox we patch the code to modify the user-agent. For Chrome, we use an extension, but the way it works is that we submitted it to Google and then have it install from there as opposed to ship it on disk. We could do the same for Firefox extensions I guess.
Christian
On 01/07/2016 02:29 PM, Naheem Zaffar wrote:
ESR will only delay the problem.
Can the Fedora build add a secodary key to accept signed extensions?
Is it possible to use Mozilla API to sign our extensions?
https://developer.mozilla.org/en-US/Add-ons/Distribution http://olympia.readthedocs.org/en/latest/topics/api/signing.html
ma.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/07/2016 08:41 AM, Martin Stransky wrote:
On 01/07/2016 02:29 PM, Naheem Zaffar wrote:
ESR will only delay the problem.
Can the Fedora build add a secodary key to accept signed extensions?
Is it possible to use Mozilla API to sign our extensions?
https://developer.mozilla.org/en-US/Add-ons/Distribution http://olympia.readthedocs.org/en/latest/topics/api/signing.html
No, it is not. The primary reason being that Koji builds intentionally have no network access. This is to ensure that all builds are reproducible (since if they relied upon external network resources, the output from the same input could be different if it was rebuilt at a different time). Additionally it's to ensure that some third-party service isn't inserting unexpected code into the output, thereby resulting in us shipping a binary that doesn't match the sources.
On 01/07/2016 08:41 AM, Martin Stransky wrote:
On 01/07/2016 02:29 PM, Naheem Zaffar wrote:
ESR will only delay the problem.
Can the Fedora build add a secodary key to accept signed extensions?
Is it possible to use Mozilla API to sign our extensions?
https://developer.mozilla.org/en-US/Add-ons/Distribution http://olympia.readthedocs.org/en/latest/topics/api/signing.html
No, it is not. The primary reason being that Koji builds intentionally have no network access. This is to ensure that all builds are reproducible (since if they relied upon external network resources, the output from the same input could be different if it was rebuilt at a different time). Additionally it's to ensure that some third-party service isn't inserting unexpected code into the output, thereby resulting in us shipping a binary that doesn't match the sources.
And for Fedora we'd need to provide a mechanism within koji to actually sign the built work. We already have infrastructure to do this for the kernel/grub and friends but I'm not sure how much would it would take to extend that to other formats.
Peter
On 01/07/2016 01:26 PM, Jiri Eischmann wrote:
Firefox is probably the most important desktop app in Fedora, so I wonder whether the Workstation working group should voice its opinion in this before any decision is made.
The workstation should not be shipping default browser but instead either Gnome Initial Setup should present the end user with an browser list to choose from ( Firefox, Chrome etc ) an install based on that or an application called browser should present the end user with the same choice on first run.
JBG
On 01/07/2016 11:56 AM, Jóhann B. Guðmundsson wrote:
On 01/07/2016 01:26 PM, Jiri Eischmann wrote:
Firefox is probably the most important desktop app in Fedora, so I wonder whether the Workstation working group should voice its opinion in this before any decision is made.
The workstation should not be shipping default browser but instead either Gnome Initial Setup should present the end user with an browser list to choose from ( Firefox, Chrome etc ) an install based on that or an application called browser should present the end user with the same choice on first run.
A live image without a browser? if you remove the default, then the live image will not have a browser either. The Live CD browser become obsolete very fast, unless it is a writeable image, but there are uses for it
JBG
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
Hi,
I really think we should just keep shipping Firefox from mozilla with the addon restriction.
Why? Let's review the options.
We could ship ESR firefox, but it will only delay the problem and we will have to face it again anyway. And it will also mean Fedora users will not get the latest and greatest firefox, which is against what Fedora stands for in being "First", but also conflicts with our Workstation PRD - we want to ship an OS for *developers*, and specifically web developers are one of our main target audience. Developers needs a recent browser with all the new HTML5 features firefox adds every release.
We could switch to Epiphany, but this is also a bad idea, because, again, we are targeting web developers... and epiphany is not good for web developer. Its developer console is not very usable and doesn't look very good, and the debugger barely works. Firefox (and Chrome/Chromium) on the other hand ship with very powerful developer tools built in, and the ability to install Firebug which is always useful. While a web developer should be knowledgeable enough to install a browser which actually fits their needs, it adds another task to the ever-so-long list of tasks you need to do to get your brand new Fedora install into a usable state.
And I don't know about you but I don't feel comfortable using a browser which doesn't have adblock with custom filter lists, the HTTPS Everywhere extension, Firefox's tracking protection, and an option to sync with my phone. Epiphany has non of that.
We could ship IceCat, but that has weird GNU restrictions (and LibreJS) which will frustrate users.
Or we could ship IceWeasel, which will confuse users because it looks like Firefox but with a different brand, which means users will see it as a Firefox clone and think we ship a "lesser" product.
This is why I think shipping Firefox as we ship it today is still the best option. Considering the other options (and that afaik we can't ship Chromium) I think unbranded firefox (such as IceWeasel or whatever branding people would use) is our second-best bet.
This entire discussion is full of too much hyperbole already. People call Mozilla's decision a "lock in" or "DRM" and that's just silly. You know this isn't the case. The reason Mozilla is doing this is to prevent malware addons from being added to its browser either by malicious applications which install shady Firefox addons or by websites offering unsuspecting users to download Firefox still branded as Firefox but shipped with malware/adware extensions.
This decision was not made to force you to use Mozilla's addon website for their profit or whatnot which is usually the reason for actual vendor lock-in, and it's not DRM - it doesn't limit your "rights" since you can still download the developer edition if you need custom addons. It is a mechanism to protect users, similar to secure boot.
While it might be preferable that Mozilla would add an option to allow trusting additional keys, I can understand why they are not keen on doing so - if it's a runtime configuration it can be easily abused by malware. If it's a compile time option while still allowing people to use the original branding, it could be a way for malware authors to keep (legally) shipping their malware-filled Firefox installers.
So can we please stop with all the hyperbole and silliness and focus on the technical/political discussion here? That would be more productive for everyone.
Thanks,
As an happy Fedora user since many years now:
+1 keep upstream Firefox by default. Vast majority of users want this and don't use packaged addons by Fedora, so problem doesn't apply for them. To not let the others in the dust provide IceWeasel or whatever unbranded version you like (but honestly IceWeasel sounds a good idea since it's shipped in Debian from a long time... and seems to do the job). This is also the second best option if not keeping upstream Firefox.
Personally I could live with IceWeasel, but I would swap the icon with the Firefox one by hand honestly. I don't like this Mozilla signature thing, but I understand their motivation. However I don't really consider it like DRM since the source code of the signature checking is free (as in freedom). You are free to download the source code and remove the limitation, while with DRM you cannot do that. If Fedora ships with upstream FF, I can download the SRPM and tamper with it. I have an escape root, not the easiest but it's only limited by my knowledge of tampering with RPMs, and I think that's fine.
Let alone removing Firefox from Fedora.... that would just call a quit on my Fedora usage. Luckly it doesn't sounds like this will be the case :).
Cheers!
On 7 January 2016 at 23:45, Elad Alfassa elad@fedoraproject.org wrote:
Hi,
I really think we should just keep shipping Firefox from mozilla with the addon restriction.
Why? Let's review the options.
We could ship ESR firefox, but it will only delay the problem and we will have to face it again anyway. And it will also mean Fedora users will not get the latest and greatest firefox, which is against what Fedora stands for in being "First", but also conflicts with our Workstation PRD - we want to ship an OS for *developers*, and specifically web developers are one of our main target audience. Developers needs a recent browser with all the new HTML5 features firefox adds every release.
We could switch to Epiphany, but this is also a bad idea, because, again, we are targeting web developers... and epiphany is not good for web developer. Its developer console is not very usable and doesn't look very good, and the debugger barely works. Firefox (and Chrome/Chromium) on the other hand ship with very powerful developer tools built in, and the ability to install Firebug which is always useful. While a web developer should be knowledgeable enough to install a browser which actually fits their needs, it adds another task to the ever-so-long list of tasks you need to do to get your brand new Fedora install into a usable state.
And I don't know about you but I don't feel comfortable using a browser which doesn't have adblock with custom filter lists, the HTTPS Everywhere extension, Firefox's tracking protection, and an option to sync with my phone. Epiphany has non of that.
We could ship IceCat, but that has weird GNU restrictions (and LibreJS) which will frustrate users.
Or we could ship IceWeasel, which will confuse users because it looks like Firefox but with a different brand, which means users will see it as a Firefox clone and think we ship a "lesser" product.
This is why I think shipping Firefox as we ship it today is still the best option. Considering the other options (and that afaik we can't ship Chromium) I think unbranded firefox (such as IceWeasel or whatever branding people would use) is our second-best bet.
This entire discussion is full of too much hyperbole already. People call Mozilla's decision a "lock in" or "DRM" and that's just silly. You know this isn't the case. The reason Mozilla is doing this is to prevent malware addons from being added to its browser either by malicious applications which install shady Firefox addons or by websites offering unsuspecting users to download Firefox still branded as Firefox but shipped with malware/adware extensions.
This decision was not made to force you to use Mozilla's addon website for their profit or whatnot which is usually the reason for actual vendor lock-in, and it's not DRM - it doesn't limit your "rights" since you can still download the developer edition if you need custom addons. It is a mechanism to protect users, similar to secure boot.
While it might be preferable that Mozilla would add an option to allow trusting additional keys, I can understand why they are not keen on doing so
- if it's a runtime configuration it can be easily abused by malware. If
it's a compile time option while still allowing people to use the original branding, it could be a way for malware authors to keep (legally) shipping their malware-filled Firefox installers.
So can we please stop with all the hyperbole and silliness and focus on the technical/political discussion here? That would be more productive for everyone.
Thanks,
-Elad.
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Thu, 2016-01-07 at 14:26 +0100, Jiri Eischmann wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
We have many different opinions in this thread. Clearly, there is no solution that will make everyone happy. I tried to formulate a consensus position based on the comments in this thread, which I suspect the majority of us can support:
"Fedora Workstation prefers to ship the latest release of Firefox, not ESR releases. Shipping an unbranded version of Firefox is acceptable to us, but not ideal. Shipping a version of Firefox that blocks unsigned extensions is also acceptable to us, but not ideal."
In other words: we're fine with FESCo deciding for either unbranded or locked-down Firefox, but we won't be very happy either way. Does this seem fair?
Michael
On Sun, Jan 10, 2016 at 3:29 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, 2016-01-07 at 14:26 +0100, Jiri Eischmann wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
We have many different opinions in this thread. Clearly, there is no solution that will make everyone happy. I tried to formulate a consensus position based on the comments in this thread, which I suspect the majority of us can support:
"Fedora Workstation prefers to ship the latest release of Firefox, not ESR releases. Shipping an unbranded version of Firefox is acceptable to us, but not ideal. Shipping a version of Firefox that blocks unsigned extensions is also acceptable to us, but not ideal."
In other words: we're fine with FESCo deciding for either unbranded or locked-down Firefox, but we won't be very happy either way. Does this seem fair?
Other than the FESCo ticket itself, I didn't get nearly as much negative on signed extensions as on an unbranded Firefox substitution. There's no data provided thus far on popularity of the Fedora only unsigned extensions, or why they couldn't be submitted for AMO for signing; either made available on AMO or as a Fedora package.
Am Sonntag, den 10.01.2016, 16:29 -0600 schrieb Michael Catanzaro:
On Thu, 2016-01-07 at 14:26 +0100, Jiri Eischmann wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
We have many different opinions in this thread. Clearly, there is no solution that will make everyone happy. I tried to formulate a consensus position based on the comments in this thread, which I suspect the majority of us can support:
"Fedora Workstation prefers to ship the latest release of Firefox, not ESR releases. Shipping an unbranded version of Firefox is acceptable to us, but not ideal. Shipping a version of Firefox that blocks unsigned extensions is also acceptable to us, but not ideal."
In other words: we're fine with FESCo deciding for either unbranded or locked-down Firefox, but we won't be very happy either way. Does this seem fair?
As long as there's no reliable data about how many users are affected by this issue IMHO the whole discussion is bulls**t. I's guess the majority of Firefox users get their addons from AMO and not from the Fedora repos and only a minority of users is affected by this issue. But that are only my 5 cent.
BTW: An other interesting fact would be to know if other distributions got the same issue with Firefox and packaged addon and what's their solution.
On 01/10/2016 11:29 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 14:26 +0100, Jiri Eischmann wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
We have many different opinions in this thread. Clearly, there is no solution that will make everyone happy. I tried to formulate a consensus position based on the comments in this thread, which I suspect the majority of us can support:
"Fedora Workstation prefers to ship the latest release of Firefox, not ESR releases. Shipping an unbranded version of Firefox is acceptable to us, but not ideal. Shipping a version of Firefox that blocks unsigned extensions is also acceptable to us, but not ideal."
In other words: we're fine with FESCo deciding for either unbranded or locked-down Firefox, but we won't be very happy either way. Does this seem fair?
My personal take on this is that we need to ship with a mainstream browser that is actively developed and that web sites support. These days, I think it's a choice between either Firefox or Chrome.
We don't have Chrome in Fedora so this leaves Firefox.
Also, shipping a browser with a widely recognizable name (Firefox) as opposed to shipping a minor fork (Icecat) has a huge benefit when it comes to people finding the web browser -- they will have used the same browser on other operating systems, making switching to Fedora easier.
Habit plays a huge role. Take a familiar name away and it's suddenly much harder for us to compete.
I think it would be fine to ask Firefox upstream to support additional trust chains to support locally packaged extensions, but if that fails I don't think we should go with anything as drastic as switching to an unbranded Firefox fork.
----- Original Message -----
From: "Kalev Lember" kalevlember@gmail.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Monday, January 11, 2016 8:00:12 AM Subject: Re: Case against Firefox in FESCo
On 01/10/2016 11:29 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 14:26 +0100, Jiri Eischmann wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
We have many different opinions in this thread. Clearly, there is no solution that will make everyone happy. I tried to formulate a consensus position based on the comments in this thread, which I suspect the majority of us can support:
"Fedora Workstation prefers to ship the latest release of Firefox, not ESR releases. Shipping an unbranded version of Firefox is acceptable to us, but not ideal. Shipping a version of Firefox that blocks unsigned extensions is also acceptable to us, but not ideal."
In other words: we're fine with FESCo deciding for either unbranded or locked-down Firefox, but we won't be very happy either way. Does this seem fair?
My personal take on this is that we need to ship with a mainstream browser that is actively developed and that web sites support. These days, I think it's a choice between either Firefox or Chrome.
We don't have Chrome in Fedora so this leaves Firefox.
Also, shipping a browser with a widely recognizable name (Firefox) as opposed to shipping a minor fork (Icecat) has a huge benefit when it comes to people finding the web browser -- they will have used the same browser on other operating systems, making switching to Fedora easier.
Habit plays a huge role. Take a familiar name away and it's suddenly much harder for us to compete.
I think it would be fine to ask Firefox upstream to support additional trust chains to support locally packaged extensions, but if that fails I don't think we should go with anything as drastic as switching to an unbranded Firefox fork.
I agree with this; yes, lets work with upstream to try to resolve this and leave any thoughts on drastic action behind for now, even if that means we ship a Firefox which only supports signed extensions either temporary or permanently. Our browser team is overworked as it is, we don't need to add to the burden.
Christian
On Mon, Jan 11, 2016 at 02:00:12PM +0100, Kalev Lember wrote:
On 01/10/2016 11:29 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 14:26 +0100, Jiri Eischmann wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
We have many different opinions in this thread. Clearly, there is no solution that will make everyone happy. I tried to formulate a consensus position based on the comments in this thread, which I suspect the majority of us can support:
"Fedora Workstation prefers to ship the latest release of Firefox, not ESR releases. Shipping an unbranded version of Firefox is acceptable to us, but not ideal. Shipping a version of Firefox that blocks unsigned extensions is also acceptable to us, but not ideal."
In other words: we're fine with FESCo deciding for either unbranded or locked-down Firefox, but we won't be very happy either way. Does this seem fair?
My personal take on this is that we need to ship with a mainstream browser that is actively developed and that web sites support. These days, I think it's a choice between either Firefox or Chrome.
We don't have Chrome in Fedora so this leaves Firefox.
Also, shipping a browser with a widely recognizable name (Firefox) as opposed to shipping a minor fork (Icecat) has a huge benefit when it comes to people finding the web browser -- they will have used the same browser on other operating systems, making switching to Fedora easier.
Habit plays a huge role. Take a familiar name away and it's suddenly much harder for us to compete.
Agreed. From the average Firefox user's POV as they consider Fedora, assuming for a moment they're not put off by the lack of a browser they know and trust already, and install Fedora anyway. It's fair to say they'll visit Mozilla to download Firefox, and now they're simply using what we decided not to just provide them even though it's FOSS.
Shipping an unbranded version also increases instead our reputation of making things hard for users -- one from which we've been steadily (and somewhat successfully) fighting our way back. I see no gain here, especially when it doesn't seem we're providing a counterbalancing benefit for most users.
I think it would be fine to ask Firefox upstream to support additional trust chains to support locally packaged extensions, but if that fails I don't think we should go with anything as drastic as switching to an unbranded Firefox fork.
+1, that response seems out of proportion to me.
On 01/11/2016 07:00 AM, Kalev Lember wrote:
On 01/10/2016 11:29 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 14:26 +0100, Jiri Eischmann wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
We have many different opinions in this thread. Clearly, there is no solution that will make everyone happy. I tried to formulate a consensus position based on the comments in this thread, which I suspect the majority of us can support:
"Fedora Workstation prefers to ship the latest release of Firefox, not ESR releases. Shipping an unbranded version of Firefox is acceptable to us, but not ideal. Shipping a version of Firefox that blocks unsigned extensions is also acceptable to us, but not ideal."
In other words: we're fine with FESCo deciding for either unbranded or locked-down Firefox, but we won't be very happy either way. Does this seem fair?
My personal take on this is that we need to ship with a mainstream browser that is actively developed and that web sites support. These days, I think it's a choice between either Firefox or Chrome.
We don't have Chrome in Fedora so this leaves Firefox.
Also, shipping a browser with a widely recognizable name (Firefox) as opposed to shipping a minor fork (Icecat) has a huge benefit when it comes to people finding the web browser -- they will have used the same browser on other operating systems, making switching to Fedora easier.
Habit plays a huge role. Take a familiar name away and it's suddenly much harder for us to compete.
I think it would be fine to ask Firefox upstream to support additional trust chains to support locally packaged extensions, but if that fails I don't think we should go with anything as drastic as switching to an unbranded Firefox fork.
"I'll also add that the accessibility of those firefox forks is sometimes not as good as and sometimes much worse than firefox itself. This isn't always the case, but with icecat 24 for example, there were lots of little things, orca not being able to track the focus, controlls not being focusable, and when I brought them up to joanmeri I was told quite bruskly to "just use firefox". I don't like chrome or chromium, and my main reason for that is as I've said, google not talking to the assistive technology API's available on whichever platform it's running on, instead expecting you to download their own addon which somehow turns their internal representations of webpages into spoken text, using their own tts voices, instead of the system ones. In other words, I'm for sticking with firefox, but I will keep going if we switch to a fork, I'll just have more bugs to file. Thanks Kendell clark"
We don't have Chrome in Fedora so this leaves Firefox.
As long as there's no reliable data about how many users are affected by this issue IMHO the whole discussion is bulls**t.
Firefox and it's new policies are open to interpretation. It's debatable whether add-on signing actually constitutes DRM or is something more like what Fedora does with it's *.rpm packages and 'dnf' validating official GPG keys from a single verified source. It's a thing that's meant to establish trust. Most add-on packages used by Firefox users in Linux are the same as those used by Windows/Mac users from the official Firefox extensions web-site.
Most users won't notice the change and will probably benefit from the added security. The web-browser has become the number one attack vector on the desktop for Linux/Mac/Windows. This merely prevents a malicious add-on from installing itself in the background or tricking the user into installing it through a software bundle or clicking something a website.
This FESCo ticket should have really been about making Chromium available from the official Fedora repositories. Google Chrome is the leading browser currently [1] and growing. It's also default on the two leading Linux distributions Chrome OS and Android. In a sense this forces users to use the official Google Chrome packages and these ship with proprietary DRM extensions and Flash which doesn't make sense.
Instead you should revise the ticket or file a new one and make this about packaging Chromium so that Fedora users who make Chrome their default can avoid having to use these proprietary schemes.
[1] https://en.wikipedia.org/wiki/Usage_share_of_web_browsers
On Mon, Jan 11, 2016 at 12:00 PM, kendell clark coffeekingms@gmail.com wrote:
On 01/11/2016 07:00 AM, Kalev Lember wrote:
On 01/10/2016 11:29 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 14:26 +0100, Jiri Eischmann wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
We have many different opinions in this thread. Clearly, there is no solution that will make everyone happy. I tried to formulate a consensus position based on the comments in this thread, which I suspect the majority of us can support:
"Fedora Workstation prefers to ship the latest release of Firefox, not ESR releases. Shipping an unbranded version of Firefox is acceptable to us, but not ideal. Shipping a version of Firefox that blocks unsigned extensions is also acceptable to us, but not ideal."
In other words: we're fine with FESCo deciding for either unbranded or locked-down Firefox, but we won't be very happy either way. Does this seem fair?
My personal take on this is that we need to ship with a mainstream browser that is actively developed and that web sites support. These days, I think it's a choice between either Firefox or Chrome.
We don't have Chrome in Fedora so this leaves Firefox.
Also, shipping a browser with a widely recognizable name (Firefox) as opposed to shipping a minor fork (Icecat) has a huge benefit when it comes to people finding the web browser -- they will have used the same browser on other operating systems, making switching to Fedora easier.
Habit plays a huge role. Take a familiar name away and it's suddenly much harder for us to compete.
I think it would be fine to ask Firefox upstream to support additional trust chains to support locally packaged extensions, but if that fails I don't think we should go with anything as drastic as switching to an unbranded Firefox fork.
"I'll also add that the accessibility of those firefox forks is sometimes not as good as and sometimes much worse than firefox itself. This isn't always the case, but with icecat 24 for example, there were lots of little things, orca not being able to track the focus, controlls not being focusable, and when I brought them up to joanmeri I was told quite bruskly to "just use firefox". I don't like chrome or chromium, and my main reason for that is as I've said, google not talking to the assistive technology API's available on whichever platform it's running on, instead expecting you to download their own addon which somehow turns their internal representations of webpages into spoken text, using their own tts voices, instead of the system ones. In other words, I'm for sticking with firefox, but I will keep going if we switch to a fork, I'll just have more bugs to file. Thanks Kendell clark"
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Mon, Jan 11, 2016 at 12:46 PM, Alex G.S. alxgrtnstrngl@gmail.com wrote:
Instead you should revise the ticket or file a new one and make this about packaging Chromium so that Fedora users who make Chrome their default can avoid having to use these proprietary schemes.
Someone is already working on that, but it has absolutely nothing to do with this thread, the ticket or the issue presented to FESCo. It's a completely different situation. Please try to stay on topic, or start a new thread.
josh
On 01/11/2016 11:51 AM, Josh Boyer wrote:
On Mon, Jan 11, 2016 at 12:46 PM, Alex G.S. alxgrtnstrngl@gmail.com wrote:
Instead you should revise the ticket or file a new one and make this about packaging Chromium so that Fedora users who make Chrome their default can avoid having to use these proprietary schemes.
Someone is already working on that, but it has absolutely nothing to do with this thread, the ticket or the issue presented to FESCo. It's a completely different situation. Please try to stay on topic, or start a new thread.
"Someone please explain to me why chromium/chrome is so popular? Why do most popular linux distributions either come with it or make it available in it's repositories? Mind you I'm thinking about this from an accessibility standpoint, not a usability standpoint. For me and those who cannot see, chrome is unusable unless you use google's extension. I don't know whether chromevox and google's tts voices are open source, I suspect not, but that's really not the point. I'm not worried about chrome/chromium becoming the default in fedora. I am however concerned that we've become so focused on getting more users that we're willing to do just about anything to get them. If that means skype and chrome, so be it. Those just so happen to be programs I cannot use because they are inaccessible. I'm sorry for those of you who've had to hear me go on about this, but it's beginning to feel like I'm being heard, but dismissed. Yeah but most of us have sight so we don't have to deal with that, is the usual response. No one from fedora has said this, this is from the wider sighted linux community itself when I bring up chrome. It seems to have blown up overnight and I can't understand it. It's proprietary, and takes the best of open source and closes it off. Thanks Kendell clark"
josh
desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Mon, Jan 11, 2016 at 1:01 PM, kendell clark coffeekingms@gmail.com wrote:
On 01/11/2016 11:51 AM, Josh Boyer wrote:
On Mon, Jan 11, 2016 at 12:46 PM, Alex G.S. alxgrtnstrngl@gmail.com wrote:
Instead you should revise the ticket or file a new one and make this about packaging Chromium so that Fedora users who make Chrome their default can avoid having to use these proprietary schemes.
Someone is already working on that, but it has absolutely nothing to do with this thread, the ticket or the issue presented to FESCo. It's a completely different situation. Please try to stay on topic, or start a new thread.
"Someone please explain to me why chromium/chrome is so popular? Why do most popular linux distributions either come with it or make it available in it's repositories? Mind you I'm thinking about this from an accessibility standpoint, not a usability standpoint. For me and those who cannot see, chrome is unusable unless you use google's extension. I don't know whether chromevox and google's tts voices are open source, I suspect not, but that's really not the point. I'm not worried about chrome/chromium becoming the default in fedora. I am however concerned that we've become so focused on getting more users that we're willing to do just about anything to get them. If that means skype and chrome, so be it. Those just so happen to be programs I cannot use because they are inaccessible. I'm sorry for those of you who've had to hear me go on about this, but it's beginning to feel like I'm being heard, but dismissed. Yeah but most of us have sight so we don't have to deal with that, is the usual response. No one from fedora has said this, this is from the wider sighted linux community itself when I bring up chrome. It seems to have blown up overnight and I can't understand it. It's proprietary, and takes the best of open source and closes it off.
A few reasons, in my own personally believed order of popularity for Chrome:
1. Media "just works". Netflix, amazon video/music, spotify, etc. 2. Per process tabs mean one tab crashing doesn't take down the whole browser 3. Tight integration into the Google ecosystem. 4. For a while, it was much faster than Firefox for typical javascript heavy sites, etc. I believe Firefox has caught up for the most part.
Chromium lacks the media aspects, or at least will if/when it gets into Fedora. The rest apply.
josh
A few reasons, in my own personally believed order of popularity for Chrome:
- Media "just works". Netflix, amazon video/music, spotify, etc.
Netflix "just works" on Firefox too (due to EME support). Spotify is flash. If you install flash-plugin it works on Firefox too.
- Per process tabs mean one tab crashing doesn't take down the whole
browser
That's already the case with Firefox too. It's just not yet enabled by default on the stable version. https://wiki.mozilla.org/Electrolysis
- Tight integration into the Google ecosystem.
That's true. But that's an anti-feature. I don't think it's a nice user experience to distribute them a browser that tries to force them to create a Google account (that's Chrome's default first tab).
- For a while, it was much faster than Firefox for typical javascript
heavy sites, etc. I believe Firefox has caught up for the most part.
That's old news. At the moment even Edge is probably faster than Chrome.
On Mon, Jan 11, 2016 at 1:21 PM, Nikos Roussos comzeradd@fedoraproject.org wrote:
A few reasons, in my own personally believed order of popularity for Chrome:
- Media "just works". Netflix, amazon video/music, spotify, etc.
Netflix "just works" on Firefox too (due to EME support). Spotify is flash. If you install flash-plugin it works on Firefox too.
Having to install flash is a terrible thing these days. Also, Firefox as shipped in Fedora out-of-the-box doesn't work for this because Fedora out-of-the-box doesn't have the codecs. Chrome bundles them, so end users that don't care get them and "it works".
(I realize Chrome has flash built-in in some form, but at least it isn't separate.)
- Per process tabs mean one tab crashing doesn't take down the whole
browser
That's already the case with Firefox too. It's just not yet enabled by default on the stable version. https://wiki.mozilla.org/Electrolysis
So for 90% of browser users, it isn't the case yet.
- Tight integration into the Google ecosystem.
That's true. But that's an anti-feature. I don't think it's a nice user experience to distribute them a browser that tries to force them to create a Google account (that's Chrome's default first tab).
Depends on what the user is looking for.
- For a while, it was much faster than Firefox for typical javascript
heavy sites, etc. I believe Firefox has caught up for the most part.
That's old news. At the moment even Edge is probably faster than Chrome.
I said that.
Look, the original poster asked why Chrome/chromium were popular. These are some of the reasons why. It wasn't a comparison to Firefox or any other browser. I'm also not defending Chrome or any other browser for that matter.
josh
On January 11, 2016 8:28:43 PM GMT+02:00, Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Jan 11, 2016 at 1:21 PM, Nikos Roussos comzeradd@fedoraproject.org wrote:
A few reasons, in my own personally believed order of popularity for Chrome:
- Media "just works". Netflix, amazon video/music, spotify, etc.
Netflix "just works" on Firefox too (due to EME support). Spotify is
flash. If you install flash-plugin it works on Firefox too.
Having to install flash is a terrible thing these days. Also, Firefox as shipped in Fedora out-of-the-box doesn't work for this because Fedora out-of-the-box doesn't have the codecs. Chrome bundles them, so end users that don't care get them and "it works".
True, but are you sure most users want this? My feeling is that Flash media is something most users try to avoid.
- Per process tabs mean one tab crashing doesn't take down the whole
browser
That's already the case with Firefox too. It's just not yet enabled
by default on the stable version.
So for 90% of browser users, it isn't the case yet.
I'm just saying it's getting there. And there is a reason it got delayed (tab separation means higher overall memory consumption). I don't think though that most users care about tab separation, or that it's an important factor on how to choose a browser.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/11/2016 02:13 PM, Nikos Roussos wrote:
On January 11, 2016 8:28:43 PM GMT+02:00, Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Jan 11, 2016 at 1:21 PM, Nikos Roussos comzeradd@fedoraproject.org wrote:
A few reasons, in my own personally believed order of popularity for Chrome:
- Media "just works". Netflix, amazon video/music,
spotify, etc.
Netflix "just works" on Firefox too (due to EME support). Spotify is
flash. If you install flash-plugin it works on Firefox too.
Having to install flash is a terrible thing these days. Also, Firefox as shipped in Fedora out-of-the-box doesn't work for this because Fedora out-of-the-box doesn't have the codecs. Chrome bundles them, so end users that don't care get them and "it works".
True, but are you sure most users want this? My feeling is that Flash media is something most users try to avoid.
You give users too much credit. Users only care if the thing they are trying to do actually happens. Whether or not it happens via flash is so far down the list it might as well be ignored, until the inevitable security issue.
On Mon, Jan 11, 2016 at 12:23 PM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/11/2016 02:13 PM, Nikos Roussos wrote:
On January 11, 2016 8:28:43 PM GMT+02:00, Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Jan 11, 2016 at 1:21 PM, Nikos Roussos comzeradd@fedoraproject.org wrote:
A few reasons, in my own personally believed order of popularity for Chrome:
- Media "just works". Netflix, amazon video/music,
spotify, etc.
Netflix "just works" on Firefox too (due to EME support). Spotify is
flash. If you install flash-plugin it works on Firefox too.
Having to install flash is a terrible thing these days. Also, Firefox as shipped in Fedora out-of-the-box doesn't work for this because Fedora out-of-the-box doesn't have the codecs. Chrome bundles them, so end users that don't care get them and "it works".
True, but are you sure most users want this? My feeling is that Flash media is something most users try to avoid.
You give users too much credit. Users only care if the thing they are trying to do actually happens. Whether or not it happens via flash is so far down the list it might as well be ignored, until the inevitable security issue.
Normally I'd agree, but Flash is special.
If it ever consciously held a special place in one's heart, it's now migrated elsewhere. Part of the colonic I give to Chrome, is disabling its built-in Flash. Last year both Chrome and Firefox temporarily disabled Flash remotely due to severe vulnerabilities, and many users were made very aware of what Flash provides, because for a while it wasn't being provided.
Honestly I think we missed one, if not the most important reason why Chrome is so popular: one of the most visited on the internet used to say "Try Chrome". This is of course www.google.com. Also https://translate.google.com/ says at the top "Built-in translation for web Get Google Chrome". Being backed by a multi billion company with one of the most visited website on the entire internet, producing the most common platform for phones (where Chrome is usually installed by default and not even removable) helps.
That's also one of the reason: it's on phones by default, so why not installing it on the PC too?
If history teach us something, I think, is that technical merits of a software are not really related to it's market share. So looking into technical merits of Chrome over Firefox and vice versa is only good to decide which one Fedora will ship (well I hope), but not to find the reason why one is more popular than the other (as the first question of this thread asks).
On 11 January 2016 at 21:37, Chris Murphy lists@colorremedies.com wrote:
On Mon, Jan 11, 2016 at 12:23 PM, Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/11/2016 02:13 PM, Nikos Roussos wrote:
On January 11, 2016 8:28:43 PM GMT+02:00, Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Jan 11, 2016 at 1:21 PM, Nikos Roussos comzeradd@fedoraproject.org wrote:
A few reasons, in my own personally believed order of popularity for Chrome:
- Media "just works". Netflix, amazon video/music,
spotify, etc.
Netflix "just works" on Firefox too (due to EME support). Spotify is
flash. If you install flash-plugin it works on Firefox too.
Having to install flash is a terrible thing these days. Also, Firefox as shipped in Fedora out-of-the-box doesn't work for this because Fedora out-of-the-box doesn't have the codecs. Chrome bundles them, so end users that don't care get them and "it works".
True, but are you sure most users want this? My feeling is that Flash media is something most users try to avoid.
You give users too much credit. Users only care if the thing they are trying to do actually happens. Whether or not it happens via flash is so far down the list it might as well be ignored, until the inevitable security issue.
Normally I'd agree, but Flash is special.
If it ever consciously held a special place in one's heart, it's now migrated elsewhere. Part of the colonic I give to Chrome, is disabling its built-in Flash. Last year both Chrome and Firefox temporarily disabled Flash remotely due to severe vulnerabilities, and many users were made very aware of what Flash provides, because for a while it wasn't being provided.
-- Chris Murphy -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Mon, Jan 11, 2016 at 8:21 PM, Nikos Roussos comzeradd@fedoraproject.org wrote:
A few reasons, in my own personally believed order of popularity for Chrome:
- Media "just works". Netflix, amazon video/music, spotify, etc.
Netflix "just works" on Firefox too (due to EME support). Spotify is flash. If you install flash-plugin it works on Firefox too.
Installing Flash does not count as "just works"... and Firefox does not support EME on Linux, and it won't support it for a while. I tried it this week with both the release version, and nightly, and neither had EME working.
On 1/11/2016 1:01 PM, Elad Alfassa wrote:
On Mon, Jan 11, 2016 at 8:21 PM, Nikos Roussos <comzeradd@fedoraproject.org mailto:comzeradd@fedoraproject.org> wrote:
>A few reasons, in my own personally believed order of popularity for >Chrome: > >1. Media "just works". Netflix, amazon video/music, spotify, etc. Netflix "just works" on Firefox too (due to EME support). Spotify is flash. If you install flash-plugin it works on Firefox too.
Installing Flash does not count as "just works"... and Firefox does not support EME on Linux, and it won't support it for a while. I tried it this week with both the release version, and nightly, and neither had EME working.
-- -Elad.
"I'll look at this from a different point of view. What good is chrome, no matter how wonderful and fast and easy it is, if an entire segment of the population cannot use it? Where's the justification for not even bothering to make it usable except through their own addons? I for one have not bought into the wonderfullness of drm, or the "just works" philosophy. Some of my community has, but I have not. No matter how good a piece of software is, if I can't use it, it might as well be a black screen. My two scents, I'll shut up now, I've beaten this dead horse enough lol.
Thanks Kendell clark"
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Mon, Jan 11, 2016 at 2:07 PM, kendell clark coffeekingms@gmail.com wrote:
On 1/11/2016 1:01 PM, Elad Alfassa wrote:
On Mon, Jan 11, 2016 at 8:21 PM, Nikos Roussos comzeradd@fedoraproject.org wrote:
A few reasons, in my own personally believed order of popularity for Chrome:
- Media "just works". Netflix, amazon video/music, spotify, etc.
Netflix "just works" on Firefox too (due to EME support). Spotify is flash. If you install flash-plugin it works on Firefox too.
Installing Flash does not count as "just works"... and Firefox does not support EME on Linux, and it won't support it for a while. I tried it this week with both the release version, and nightly, and neither had EME working.
-- -Elad.
"I'll look at this from a different point of view. What good is chrome, no matter how wonderful and fast and easy it is, if an entire segment of the population cannot use it? Where's the justification for not even bothering to make it usable except through their own addons? I for one have not bought into the wonderfullness of drm, or the "just works" philosophy. Some of my community has, but I have not. No matter how good a piece of software is, if I can't use it, it might as well be a black screen. My two scents, I'll shut up now, I've beaten this dead horse enough lol.
You're asking fine questions, but nobody here is advocating for Chrome nor can we answer those questions even if we were. They should be asked of Google upstream.
josh
On 1/11/2016 1:22 PM, Josh Boyer wrote:
On Mon, Jan 11, 2016 at 2:07 PM, kendell clark coffeekingms@gmail.com wrote:
On 1/11/2016 1:01 PM, Elad Alfassa wrote:
On Mon, Jan 11, 2016 at 8:21 PM, Nikos Roussos comzeradd@fedoraproject.org wrote:
A few reasons, in my own personally believed order of popularity for Chrome:
- Media "just works". Netflix, amazon video/music, spotify, etc.
Netflix "just works" on Firefox too (due to EME support). Spotify is flash. If you install flash-plugin it works on Firefox too.
Installing Flash does not count as "just works"... and Firefox does not support EME on Linux, and it won't support it for a while. I tried it this week with both the release version, and nightly, and neither had EME working.
-- -Elad.
"I'll look at this from a different point of view. What good is chrome, no matter how wonderful and fast and easy it is, if an entire segment of the population cannot use it? Where's the justification for not even bothering to make it usable except through their own addons? I for one have not bought into the wonderfullness of drm, or the "just works" philosophy. Some of my community has, but I have not. No matter how good a piece of software is, if I can't use it, it might as well be a black screen. My two scents, I'll shut up now, I've beaten this dead horse enough lol.
You're asking fine questions, but nobody here is advocating for Chrome nor can we answer those questions even if we were. They should be asked of Google upstream.
josh
"nods, I get a little over the top when it comes to accessibility. I believe I have asked google at some point. Not directly of course, but through the chromium bug tracker. The answer is something like, we're trying to provide a uniform experience, so use our addons. Doublespeak for it's easier controlling accessibility our own way, rather than making code to support at-spi and atk on linux, msaa and such on windows, and whatever mac has. Mind you this is not proof, just what I remember hearing from google. I keep chromium around on my arch system, testing to see if it ever become accessible. So far it hasn't. Thanks Kendell clark"
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On January 11, 2016 9:01:30 PM GMT+02:00, Elad Alfassa elad@fedoraproject.org wrote:
On Mon, Jan 11, 2016 at 8:21 PM, Nikos Roussos comzeradd@fedoraproject.org wrote:
A few reasons, in my own personally believed order of popularity for Chrome:
- Media "just works". Netflix, amazon video/music, spotify, etc.
Netflix "just works" on Firefox too (due to EME support). Spotify is flash. If you install flash-plugin it works on Firefox too.
Installing Flash does not count as "just works"... and Firefox does not support EME on Linux, and it won't support it for a while. I tried it this week with both the release version, and nightly, and neither had EME working.
And given Linux current user base, I don't think that's a reason that makes Chrome more popular.
Chrome is the most popular browser for pretty much the same reasons that Windows is the most popular operating system. It has nothing to do with "just works" moments, which anyway are different for most users and hard to identify their impact. For instance cutting off third party trackers just works on Firefox. It is important for me, but does it matter for the majority of the users? Unknown.
Debian and other distributions (Trisquel, gNewSense, GuixSD) have used unbranded forks of Firefox for years and I don't think this has been a problem for them. In any case I don't think we can call "drastic" something that multiple other distributions do.
The Debian and GNU projects consider Mozilla Firefox as proprietary software because it does not meet the Debian Free Software Guidelines or GNU's definition of free software. Fedora didn't follow that stance.
I don't think whether we're using a fork or not is important. It'll be just as up-to-date, just as well supported by websites, and would work like Firefox so habbit would not be a problem. The Firefox name and branding is a problem for Fedora (it prevents us from modifying the browser), not a benefit.
On Mon, 2016-01-11 at 14:00 +0100, Kalev Lember wrote:
On 01/10/2016 11:29 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 14:26 +0100, Jiri Eischmann wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
We have many different opinions in this thread. Clearly, there is no solution that will make everyone happy. I tried to formulate a consensus position based on the comments in this thread, which I suspect the majority of us can support:
"Fedora Workstation prefers to ship the latest release of Firefox, not ESR releases. Shipping an unbranded version of Firefox is acceptable to us, but not ideal. Shipping a version of Firefox that blocks unsigned extensions is also acceptable to us, but not ideal."
In other words: we're fine with FESCo deciding for either unbranded or locked-down Firefox, but we won't be very happy either way. Does this seem fair?
My personal take on this is that we need to ship with a mainstream browser that is actively developed and that web sites support. These days, I think it's a choice between either Firefox or Chrome.
We don't have Chrome in Fedora so this leaves Firefox.
Also, shipping a browser with a widely recognizable name (Firefox) as opposed to shipping a minor fork (Icecat) has a huge benefit when it comes to people finding the web browser -- they will have used the same browser on other operating systems, making switching to Fedora easier.
Habit plays a huge role. Take a familiar name away and it's suddenly much harder for us to compete.
I think it would be fine to ask Firefox upstream to support additional trust chains to support locally packaged extensions, but if that fails I don't think we should go with anything as drastic as switching to an unbranded Firefox fork.
Technically speaking you can modify it and still call it Firefox with Mozilla authorization. The reason why the Firefox name and icon are not free to use is to protect the reputation of the browser and be able to sue abusers. Practical example: Firefox is open source, I include a malware in it, compile and ship it from my website calling it Firefox, including the source code (to comply with the license). Sure enough sooner or later my fraud would come to the light, but I surely did some damage in the mean time and ruined Mozilla's reputation. If I call it IceWeasel, to avoid being sued because of using the Firefox name and icon without Mozilla's authorization, and put a different icon it's a lot harder for a malicious attacker to trick the user to install it. This applies more to platforms where there is no package manager and the user has to actively search for software on the internet. Heck even on Linux it took so long to get my father into the idea he can do everything with the package manager.
That being said if you take away the name and the logo it's just a matter of time before some Fedora user is going to fall into the trap, so keeping the branding has some advantage.
On the other side: Fedora is already shipping a binary different from what Mozilla is shipping. It's many months Fedora enables gtk3 and, as far as I know, Red Hat is helping Mozilla in this since this is needed for Wayland (btw thank you, loving gtk3 Firefox). In Firefox 41 release Fedora disabled OMTC since compiling with system cairo breaks it (then switched to bundled cairo in 42 to ultimately solve the issue, this is very distro independent, I have the same problem in gentoo). Mozilla didn't sued Red Hat for this. The addon signing thing would be a slightly different matter I guess, but I'm sure (and hope) some sort of mediation is possible.
On 12 January 2016 at 06:09, Rastus Vernon rvernon@openmailbox.org wrote:
Debian and other distributions (Trisquel, gNewSense, GuixSD) have used unbranded forks of Firefox for years and I don't think this has been a problem for them. In any case I don't think we can call "drastic" something that multiple other distributions do.
The Debian and GNU projects consider Mozilla Firefox as proprietary software because it does not meet the Debian Free Software Guidelines or GNU's definition of free software. Fedora didn't follow that stance.
I don't think whether we're using a fork or not is important. It'll be just as up-to-date, just as well supported by websites, and would work like Firefox so habbit would not be a problem. The Firefox name and branding is a problem for Fedora (it prevents us from modifying the browser), not a benefit.
On Mon, 2016-01-11 at 14:00 +0100, Kalev Lember wrote:
On 01/10/2016 11:29 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 14:26 +0100, Jiri Eischmann wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
We have many different opinions in this thread. Clearly, there is no solution that will make everyone happy. I tried to formulate a consensus position based on the comments in this thread, which I suspect the majority of us can support:
"Fedora Workstation prefers to ship the latest release of Firefox, not ESR releases. Shipping an unbranded version of Firefox is acceptable to us, but not ideal. Shipping a version of Firefox that blocks unsigned extensions is also acceptable to us, but not ideal."
In other words: we're fine with FESCo deciding for either unbranded or locked-down Firefox, but we won't be very happy either way. Does this seem fair?
My personal take on this is that we need to ship with a mainstream browser that is actively developed and that web sites support. These days, I think it's a choice between either Firefox or Chrome.
We don't have Chrome in Fedora so this leaves Firefox.
Also, shipping a browser with a widely recognizable name (Firefox) as opposed to shipping a minor fork (Icecat) has a huge benefit when it comes to people finding the web browser -- they will have used the same browser on other operating systems, making switching to Fedora easier.
Habit plays a huge role. Take a familiar name away and it's suddenly much harder for us to compete.
I think it would be fine to ask Firefox upstream to support additional trust chains to support locally packaged extensions, but if that fails I don't think we should go with anything as drastic as switching to an unbranded Firefox fork.
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
Enrico Tagliavini píše v Út 12. 01. 2016 v 09:43 +0100:
Technically speaking you can modify it and still call it Firefox with Mozilla authorization. The reason why the Firefox name and icon are not free to use is to protect the reputation of the browser and be able to sue abusers. Practical example: Firefox is open source, I include a malware in it, compile and ship it from my website calling it Firefox, including the source code (to comply with the license). Sure enough sooner or later my fraud would come to the light, but I surely did some damage in the mean time and ruined Mozilla's reputation. If I call it IceWeasel, to avoid being sued because of using the Firefox name and icon without Mozilla's authorization, and put a different icon it's a lot harder for a malicious attacker to trick the user to install it. This applies more to platforms where there is no package manager and the user has to actively search for software on the internet. Heck even on Linux it took so long to get my father into the idea he can do everything with the package manager.
That being said if you take away the name and the logo it's just a matter of time before some Fedora user is going to fall into the trap, so keeping the branding has some advantage.
On the other side: Fedora is already shipping a binary different from what Mozilla is shipping. It's many months Fedora enables gtk3 and, as far as I know, Red Hat is helping Mozilla in this since this is needed for Wayland (btw thank you, loving gtk3 Firefox). In Firefox 41 release Fedora disabled OMTC since compiling with system cairo breaks it (then switched to bundled cairo in 42 to ultimately solve the issue, this is very distro independent, I have the same problem in gentoo). Mozilla didn't sued Red Hat for this. The addon signing thing would be a slightly different matter I guess, but I'm sure (and hope) some sort of mediation is possible.
Red Hat and Mozilla have an agreement and regular communication, so it's not like we're inconsiderately doing whatever we want with Firefox.
Jiri
On 12 January 2016 at 06:09, Rastus Vernon rvernon@openmailbox.org wrote:
Debian and other distributions (Trisquel, gNewSense, GuixSD) have used unbranded forks of Firefox for years and I don't think this has been a problem for them. In any case I don't think we can call "drastic" something that multiple other distributions do.
The Debian and GNU projects consider Mozilla Firefox as proprietary software because it does not meet the Debian Free Software Guidelines or GNU's definition of free software. Fedora didn't follow that stance.
I don't think whether we're using a fork or not is important. It'll be just as up-to-date, just as well supported by websites, and would work like Firefox so habbit would not be a problem. The Firefox name and branding is a problem for Fedora (it prevents us from modifying the browser), not a benefit.
On Mon, 2016-01-11 at 14:00 +0100, Kalev Lember wrote:
On 01/10/2016 11:29 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 14:26 +0100, Jiri Eischmann wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
We have many different opinions in this thread. Clearly, there is no solution that will make everyone happy. I tried to formulate a consensus position based on the comments in this thread, which I suspect the majority of us can support:
"Fedora Workstation prefers to ship the latest release of Firefox, not ESR releases. Shipping an unbranded version of Firefox is acceptable to us, but not ideal. Shipping a version of Firefox that blocks unsigned extensions is also acceptable to us, but not ideal."
In other words: we're fine with FESCo deciding for either unbranded or locked-down Firefox, but we won't be very happy either way. Does this seem fair?
My personal take on this is that we need to ship with a mainstream browser that is actively developed and that web sites support. These days, I think it's a choice between either Firefox or Chrome.
We don't have Chrome in Fedora so this leaves Firefox.
Also, shipping a browser with a widely recognizable name (Firefox) as opposed to shipping a minor fork (Icecat) has a huge benefit when it comes to people finding the web browser -- they will have used the same browser on other operating systems, making switching to Fedora easier.
Habit plays a huge role. Take a familiar name away and it's suddenly much harder for us to compete.
I think it would be fine to ask Firefox upstream to support additional trust chains to support locally packaged extensions, but if that fails I don't think we should go with anything as drastic as switching to an unbranded Firefox fork.
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproj ect.org
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraprojec t.org
On Tue, 2016-01-12 at 09:43 +0100, Enrico Tagliavini wrote:
Technically speaking you can modify it and still call it Firefox with Mozilla authorization.
Technically speaking you can modify Microsoft Word and redistribute it with Microsoft's authorization, but that doesn't make it free software, specifically because you need Microsoft's authorization. :)
The reason why the Firefox name and icon are not free to use is to protect the reputation of the browser and be able to sue abusers. Practical example: Firefox is open source, I include a malware in it, compile and ship it from my website calling it Firefox, including the source code (to comply with the license). Sure enough sooner or later my fraud would come to the light, but I surely did some damage in the mean time and ruined Mozilla's reputation. If I call it IceWeasel, to avoid being sued because of using the Firefox name and icon without Mozilla's authorization, and put a different icon it's a lot harder for a malicious attacker to trick the user to install it. This applies more to platforms where there is no package manager and the user has to actively search for software on the internet. Heck even on Linux it took so long to get my father into the idea he can do everything with the package manager.
Protecting the Firefox brand is justifiable from Mozilla's point of view, but has implications for redistributing the software.
That being said if you take away the name and the logo it's just a matter of time before some Fedora user is going to fall into the trap, so keeping the branding has some advantage.
On the other side: Fedora is already shipping a binary different from what Mozilla is shipping. It's many months Fedora enables gtk3 and, as far as I know, Red Hat is helping Mozilla in this since this is needed for Wayland (btw thank you, loving gtk3 Firefox). In Firefox 41 release Fedora disabled OMTC since compiling with system cairo breaks it (then switched to bundled cairo in 42 to ultimately solve the issue, this is very distro independent, I have the same problem in gentoo). Mozilla didn't sued Red Hat for this. The addon signing thing would be a slightly different matter I guess, but I'm sure (and hope) some sort of mediation is possible.
On GTK3, I'm sure Mozilla wouldn't mind (especially since Stransky is working on it upstream), but on addon signing Mozilla's position seems firm. Though, that doesn't mean we can't send a proposal to Mozilla. Debian initially had a trademark agreement with Mozilla, but it was revoked by Mozilla and Debian did not want to have to ask Mozilla for permission to backport security fixes and customize the browser to make it compliant with Debian policies (the artwork in Firefox is under a proprietary license and Debian did not want to ship it, but the trademark agreement was revoked because Mozilla didn't find the customizations acceptable).
Fedora could try to get a similar agreement with Mozilla, or alternatively could get Mozilla to do or allow what it needs upstream, but that forces Fedora to rely on Mozilla and to give up on its position if there is a disagreement. We can't get Fedora-specific customizations upstream, so we could only do them with extensions (assuming even we come to an agreement on addon signing) and that would also be a problem with the new WebExtensions that have less access to the browser than the current browser addons. There's a disagreement now on extension signing, and there would no doubt be other disagreements in the future. I don't want to see Fedora give up on its policies (as has been the case for some of the releases that introduced major changes and were shipped to the stable Fedora release regardless) or on other customizations just because Mozilla will not allow it, and rebranding Firefox now solves the problem we have at hand and any problem we might have in the future.
On 12 January 2016 at 06:09, Rastus Vernon rvernon@openmailbox.org wrote:
Debian and other distributions (Trisquel, gNewSense, GuixSD) have used unbranded forks of Firefox for years and I don't think this has been a problem for them. In any case I don't think we can call "drastic" something that multiple other distributions do.
The Debian and GNU projects consider Mozilla Firefox as proprietary software because it does not meet the Debian Free Software Guidelines or GNU's definition of free software. Fedora didn't follow that stance.
I don't think whether we're using a fork or not is important. It'll be just as up-to-date, just as well supported by websites, and would work like Firefox so habbit would not be a problem. The Firefox name and branding is a problem for Fedora (it prevents us from modifying the browser), not a benefit.
On Mon, 2016-01-11 at 14:00 +0100, Kalev Lember wrote:
On 01/10/2016 11:29 PM, Michael Catanzaro wrote:
On Thu, 2016-01-07 at 14:26 +0100, Jiri Eischmann wrote:
Hi, there is currently a case against Firefox discussed in FESCo: https://fedorahosted.org/fesco/ticket/1518
We have many different opinions in this thread. Clearly, there is no solution that will make everyone happy. I tried to formulate a consensus position based on the comments in this thread, which I suspect the majority of us can support:
"Fedora Workstation prefers to ship the latest release of Firefox, not ESR releases. Shipping an unbranded version of Firefox is acceptable to us, but not ideal. Shipping a version of Firefox that blocks unsigned extensions is also acceptable to us, but not ideal."
In other words: we're fine with FESCo deciding for either unbranded or locked-down Firefox, but we won't be very happy either way. Does this seem fair?
My personal take on this is that we need to ship with a mainstream browser that is actively developed and that web sites support. These days, I think it's a choice between either Firefox or Chrome.
We don't have Chrome in Fedora so this leaves Firefox.
Also, shipping a browser with a widely recognizable name (Firefox) as opposed to shipping a minor fork (Icecat) has a huge benefit when it comes to people finding the web browser -- they will have used the same browser on other operating systems, making switching to Fedora easier.
Habit plays a huge role. Take a familiar name away and it's suddenly much harder for us to compete.
I think it would be fine to ask Firefox upstream to support additional trust chains to support locally packaged extensions, but if that fails I don't think we should go with anything as drastic as switching to an unbranded Firefox fork.
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproj ect.org
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraprojec t.org
Rastus Vernon píše v Út 12. 01. 2016 v 00:09 -0500:
Debian and other distributions (Trisquel, gNewSense, GuixSD) have used unbranded forks of Firefox for years and I don't think this has been a problem for them. In any case I don't think we can call "drastic" something that multiple other distributions do.
Trisquel, gNewSense, GuixSD are not examples of particularly popular distributions, so not really good examples how the change cannot harm us. They target a pretty small user base which probably mostly appreciate such a policy. Debian is definitely more popular, but I still think our target audience is a bit broader, reaching segments where Debian-based distros are doing much better than Debian itself - Ubuntu, Linux Mint,...
The Debian and GNU projects consider Mozilla Firefox as proprietary software because it does not meet the Debian Free Software Guidelines or GNU's definition of free software. Fedora didn't follow that stance.
Yes, it'd be a bit hypocritical of Fedora to claim this is something bad since Red Hat does the same with RHEL.
I don't think whether we're using a fork or not is important. It'll be just as up-to-date, just as well supported by websites, and would work like Firefox so habbit would not be a problem. The Firefox name and branding is a problem for Fedora (it prevents us from modifying the browser), not a benefit.
I disagree. As I already mentioned earlier in this discussion, Firefox is one of the strongest brands in open source. Using artificial brands instead of well-established ones won't do us any good as I think it has never really benefited Debian. Normal users don't understand it and see it as uncalled for.
Jiri
Firefox is an essential desktop app. We should not be thinking about whether another browser is better or good enough. We should be thinking about what we want and what we need and why. What we want and what we need are not always the same thing. Like any other long lived project, Firefox has sever maintainability problems. Security, stability, and backward compatibility are constantly in conflict with each other. Perhaps Mozilla could work towards running Firefox as a shell over a collection of sandboxes that contain and separate the plugins. Then policies could be applied to determine what data a plugin should have access to. Once contained, a plugin would not need to know that it was being "managed". Also, Firefox would not hang if a plugin had problems. A plugin could be restarted independently. Then we might approach a state where we can have our cake and eat it too.
Mozilla needs to adjust to the changing environment. If it does not provide a pleasant experience then nobody will use it. I watch Netflix when I travel but I have to use Chrome because it doesn't work with Firefox. So I have to have Chrome and Firefox installed. I only use Window because I sometimes have to. I do not use if for entertainment,. If I could not watch Netflix on Linux then I would not watch Netflix. This is just an example of defining a need. How many other things are there? YouTube, FoxNews, FaceBook? Create a compliance table and order it by priority. Pick the top browsers that are most compliant or help the browser developers become compliant.
desktop@lists.fedoraproject.org