Clarify goals for FOSS and telemetry #70
Comments
|
I'm against this proposed change to the language of the readme. While I think the proposed change is a good aspirational goal for the time being, and I think it potentially can be achieved, and if it can be achieved, should be achieved, at the present time, with the present upstream code and the present mobile web as it is, the problem is that the change in language commits the project and the browser to some things that may prove difficult to maintain in the future and that it may not want to maintain in the future for various reasons. For example, right now some tell me that the mobile web's videos for the most part don't require the EME DRM module that Firefox for desktop has. So, at least from what I've heard, this isn't in upstream Firefox-Fenix or Iceweasel. However, what if in the future, what has happened on desktop happens to Firefox and the mobile web? A strict interpretation of the proposed changed language would not allow Iceweasel to adopt the EME DRM module to play the videos in that scenario, which might be problematic from both the perspective of maintaining the fork and compromising the user experience. One issue is how tightly the code would be bound into Fenix. That's the maintaining the fork issue. My guess is that it would be easy to remove the module, which is, if I recall correctly, in desktop Firefox, an open-sourced wrapper around proprietary code where the wrapper limits and displays how the code interacts with the browser, but protects the code from being easily viewed and reversed engineeered- or something like that (DRM, but more compatible with open-source than what Chrome does). However, it may not be that easy in this hypothetical future Firefox mobile- or even possible to do and maintain for Iceweasel with however many maintainers/developers it has at that point and however many hours they have to contribute to the project at that point. If something gets bound too tightly in there, getting it out might require a hard fork (i.e. Making IceWeasel it's own upstream instead of having Firefox as the upstream) that I don't think this project is anywhere close to being prepared to absolutely commit to. Admittedly, that is the part of the scenario I only kind of vaguely understand. The second issue is user experience. Let's imagine that YouTube implements some DRM on all it's mobile web videos that is not currently present and must be supported browserside. Chrome, of course, officially adds support if it doesn't already have it. Then Google offers it anyone who wants it, so they don't get in trouble with anti-trust regulators in the EU or wherever. Would the browser refuse to take it and simply tell all it's users to go download the official Google YouTube app where they can't control their experience at all with content-blockers and the like? Granted, DRM would be a problem to users controlling how and what content is displayed, but at least if it remains in the browser, there is a fighting chance. I am not saying that IceWeasel should automatically adopt this hypothetical DRM if offered, but changing the language above seems to commit the browser to saying no, which is some hardcore GNU free as in freedom type stuff where a browser doesn't care if it loses compatibility with half the web and most of it's users to fight DRM if it has to. Since as I understand it, this is primarily a fork that is intended to enable more options, customization, and extendability than upstream, I would say that there is a case to be made that some future DRM, if it's necessary to view the mobile web of that era, as an optional module, perhaps, may arguably be necessary to support the browser's primary mission. It would be problematical to that mission if upstream Firefox offered more options than IceWeasel. With that said, currently, I don't see why the browser would need any telemetry or proprietary elements to deal with the mobile web as it is today (Unless I am unware of something, which is entirely possible.). However, I think it would be shortsighted to cut off any consideration of adding things in the future if the future mobile web demands them. I hope the future mobile most certainly does not demand them, but it's unlikely that IceWeasel will have the type of marketshare to fight them, and Firefox sort of did a conditional surrender on desktop (i.e. implementing within a module), so one can't count on upstream to be willing or able to fight and win that battle, especially if their marketshare on mobile stays where it is or only, say, doubles. So, then the question would be if Iceweasel wants to browse the Internet or not. That'd be a sad scenario, but it is also a potential reality that is not so farfetched from where I'm sitting. Now, granted, I feel odd typing this while the browser is named IceWeasel, because the history of that name conjures up visions of people who would absolutely just refuse that hypothetical module no matter what, as quickly as non-free artwork. However, this browser is not literally that browser or that group of people. There is an issue about changing the name, and it could be IceRaven (Which looks like the leading contender) or something any day now. So, I wouldn't let the browser's current name impact this discussion too much. I think the language is fine as-is: "In addition, we intend to try to cut down on telemetry and proprietary code to as great of an extent as possible as long as doing so does not compromise the user experience or make the fork too hard to maintain.". That describes a project that would get rid of all of it if was still maintainable and didn't compromise the user experience, but is flexible to consider bending to tomorrow's reality even if it isn't what the project would like, in order to be able to continue development at all and/or in order to serve the user's desires for options and customization, or even just basic features that allow it to do what it does today tomorrow. As mentioned, I certainly think the project should go as far as it can now towards being free of telemetry and proprietary code and disclose if and whether any remains after it's done, and has done a full assessment of what's in the code base it inherited from upstream when enough passes that is has had enough time to do so, and disclose any new stuff prominently (Including an off button or perhaps two separate builds if possible and maintainable under that scenario), but that's about it. I don't want to close off what may be necessary options as the mobile web evolves. The current language at least allows us to have discussions that we may need to have instead of being something that can be pointed at as committing the browser to a hard-line stance that may cripple it depending on what happens to the mobile web and mobile browsers in the future. Full disclosure: I wrote the sentence the original poster wants to change. :) |
|
Obviously this is for the maintainers like Interfect to decide, just my
suggestion. But ultimately if Iceweasel chose to eventually include
proprietary code, either that would exclude it from F-Droid, or require the
maintenance of two separate versions of Iceweasel. And being in F-Droid is
a current aim being actively worked on.
…On Fri, Sep 4, 2020, 11:34 PM CharmCityCrab ***@***.***> wrote:
I'm against this proposed change to the language of the readme.
While I think the proposed change is a good aspirational goal for the time
being, and I think it potentially can be achieved, and if it can be
achieved, should be achieved, at the present time, with the present
upstream code and the present mobile web as it is, the problem is that the
change in language commits the project and the browser to some things that
may prove difficult to maintain in the future and that it may not want to
maintain in the future for various reasons.
For example, right now some tell me that the mobile web's videos for the
most part don't require the EME DRM module that Firefox for desktop has.
So, at least from what I've heard, this isn't in upstream Firefox-Fenix or
Iceweasel. However, what if in the future, what has happened on desktop
happens to Firefox and the mobile web?
A strict interpretation of the proposed changed language would not allow
Iceweasel to adopt the EME DRM module to play the videos in that scenario,
which might be problematic from both the perspective of maintaining the
fork and compromising the user experience.
One issue is how tightly the code would be bound into Fenix. That's the
maintaining the fork issue. My guess is that it would be easy to remove the
module, which is, if I recall correctly, in desktop Firefox, an
open-sourced wrapper around proprietary code where the wrapper limits and
displays how the code interacts with the browser, but protects the code
from being easily viewed and reversed engineeered- or something like that
(DRM, but more compatible with open-source than what Chrome does). However,
it may not be that easy in this hypothetical future Firefox mobile- or even
possible to do and maintain for Iceweasel with however many
maintainers/developers and however many hours they have to contribute to
the project at this time. If something gets bound too tightly in there,
getting it out would require a hard fork that I don't think this project is
anywhere close to being prepared to absolutely commit to. Admittedly, that
is the part of the scenario I only kind of vaguely understand.
The second issue is user experience. Let's imagine that YouTube implements
some DRM on all it's mobile web videos that is not currently present and
must be supported browserside. Chrome, of course, officially adds support
if it doesn't already have it. Then Google offers it anyone who wants it,
so they don't get in trouble with anti-trust regulators in the EU or
wherever. Would the browser refuse to take it and simply tell all it's
users to go download the official Google YouTube app where they can't
control their experience at all with content-blockers and the like?
Granted, DRM would be a problem to users controlling how and what content
is displayed, but at least if it remains in the browser, there is a
fighting chance.
I am not saying that IceWeasel should automatically adopt this
hypothetical DRM if offered, but changing the language above seems to
commit the browser to saying no, which is some hardcore GNU free as in
freedom type stuff where a browser doesn't care if it loses compatibility
with half the web and most of it's users to fight DRM if it has to. Since
as I understand it, this is primarily a fork that is intended to enable
more options, customization, and extendability than upstream, I would say
that there is a case to be made that some future DRM, if it's necessary to
view the mobile web of that era, as an optional module, perhaps, may
arguably be necessary to support the browser's primary mission. It would be
problematical to that mission if upstream Firefox offered more options than
IceWeasel.
With that said, currently, I don't see why the browser would need any
telemetry or proprietary elements to deal with the mobile web as it is
today (Unless I am unware of something, which is entirely possible.).
However, I think it would be shortsighted to cut off any consideration of
adding things in the future if the future mobile web demands them. I hope
the future mobile most certainly does not demand them, but it's unlikely
that IceWeasel will have the type of marketshare to fight them, and Firefox
sort of did a conditional surrender on desktop (i.e. implementing within a
module), so one can't count on upstream to be willing or able to fight and
win that battle, especially if their marketshare on mobile stays where it
is or only, say, doubles. So, then the question would be if Iceweasel wants
to browse the Internet or not.
That'd be a sad scenario, but it is also a potential reality that is not
so farfetched from where I'm sitting.
Now, granted, I feel odd typing this while the browser is named IceWeasel,
because the history of that name conjures up visions of people who would
absolutely just refuse that hypothetical module no matter what, as quickly
as non-free artwork. However, this browser is not literally that browser or
that group of people. There is an issue about changing the name, and it
could be IceRaven (Which looks like the leading contender) or something any
day now.
So, I wouldn't let the browser's current name impact this discussion too
much.
I think the language is fine as-is: "In addition, we intend to try to cut
down on telemetry and proprietary code to as great of an extent as possible
as long as doing so does not compromise the user experience or make the
fork too hard to maintain.".
That describes a project that would get rid of all of it if was still
maintainable and didn't compromise the user experience, but is flexible to
*consider* bending to tomorrow's reality even if it isn't what the
project would like, in order to be able to continue development at all
and/or in order to serve the user's desires for options and customization,
or even just basic features that allow it to do what it does today tomorrow.
As mentioned, I certainly think the project should go as far as it can now
towards being free of telemetry and proprietary code and disclose if and
whether any remains after it's done and has done a full assess of what's in
the code base it inherited from upstream after it's had enough time to do
so, and disclose any new stuff prominently (Including an off button or
perhaps two separate builds if possible and maintainable under that
scenario), but that's about it. I don't want to close off what may be
necessary options as the mobile web evolves.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#70 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQQNFQZUFXT4VFWQ6YFX7M3SEGWWFANCNFSM4Q2BHD5A>
.
|
|
As far as I am aware, a formal unambigious public commitment to meet F-Droid's standards not only today, but until the end of the browser project or the end of time, whichever comes first, regardless of what happens with the mobile web and web browsing in general through the years to come is not a requirement to be listed on F-Droid today. :). What is required is that the browser code meet F-Droid's standards for code at the time of submission. Going forward from that, I would imagine that the browser as updated upon each update must continue to meet said standards of cease being listed on F-Droid. The current stance is thus not a blocker to being listed on F-Droid here in 2020. We both agree that IceWeasel should continue to attempt to strip out all telemetry and proprietary code that currently exists in it and then proceed with their F-Droid listing application ASAP. So, I think what we are talking about here in this issue is not what the course of action should be right now, but whether the browser should alter it's current readme in such a way as to tie it's hands later and allow people to claim it went back on a commitment it made if circumstances eventually require a compromise. I think the current wording is enough to clearly convey that the browser is against telemetry and proprietary elements, while leaving room to respond to the demands of the next iterations of the mobile web and remain useable for people who like a web browser that works on almost every site, providing the same customization options as upstream along with many more, and for the browser to remain maintainable with the amount of resources it can reasonably expect to have. So, what happens if in a few years if some sort of proprietary DRM is required to access half the mobile web and/or it is so tightly integrated into Firefox-Fenix that IceWeasel can not continue to incorporate it's patches without adding that too? The folks in charge could make that decision at that time, perhaps with the help of community input, and based in part on the specifics of how the problem manifests itself and the alternatives or lack thereof it has at that time. Depending on the specifics of the situation, there may be lots of potential ways to approach the situation then. My point is, I suppose, why tie the browser's hands in advance of some hypothetical events that may or may not happen down the road? It seems very ideological and not very practical to commit to saying no no matter what the future brings. I mean, that's another browser, it's called IceCat. Our principles aren't that different from a browser like that, but we should leave open the door to deal with whatever the future brings and not speak in absolutes IMO. That doesn't necessarily mean the browser should ever stray from its aims in this regard, it's just saying let's not make it so people can say we shouldn't even be able to have the conversation when and if a situation occurs. The proposed new wording feels like an attempt to lock something in that ultimately could doom the browser if certain things occur down the line. The existing language establishes the future the browser prefers and is pursuing today while allowing some room to adapt if it feels it has to because of changes beyond its contrll without having people complain that the project committed to falling on its own sword in such an eventuality. We also really don't know how important continuing to be in F-Droid will be when and if something happens years from now, or even if the browser or F-Droid will continue to exist in their current forms. So, let's meet the standards and get in now and then we can play it by ear and figure out the future when it arrives. :) I would also hasten to point out that while being in F-Droid while things are what they are is clearly important to the lead developer and I fully support that happening ASAP, we needn't necessarily limit ourselves to F-Droid and direct APKs as our only distribution methods. Since most Android users solely install software from the Google Play Store, it'd be smart to be in there, too. I keep meaning to open an issue about that, but haven't gotten around to it. There are other distribution methods as well. There's an Amazon.com Android marketplace, for example. Putting the browser on F-Droid doesn't necessarily lock IceWeasel into only using F-Droid. It could conceivably be listed in lots of places, which would increase the total number of users, and also give it much more of an ability to choose it's own path knowing it could survive one distributor choosing to drop it over it and there would still be trusted places for users to get the browser that vet the code's security. Anyway, maybe we should let some other people talk. I feel like I've said my piece and don't want to clutter up the the issue. Ultimately, like you said, it's probably up to Interfect, and I think we have both given him some impassioned comments that he can consider in coming to a decision.
|
|
I personally don't mind Mozilla gathering some telemetry. I do mind any Google servers and products (or any telemetry corporation) in the process of doing so though. Just overall glad I found this version no matter what as I use Aurora Store for my banking app and that is pretty much it - quite sad Mozilla didn't think about their open source/no-gapps users. |
|
To the extent that we can pull it out, I think we should pull out proprietary code. Obviously if EME becomes important on mobile we might have to reconsider. But even then, if Mozilla Fenix manages to ship an F-Droid flavor, we should be able to as well, just by drafting off the patches that relan has been maintaining. None of the extra settings and customization stuff is going to add more proprietary code. |
I think Iceweasel's goals regarding removal of non-free/proprietary components and telemetry could use some clarification. Currently, this is in the readme:
So a couple of notes:
So I suggest revising the goals in this area for Iceweasel to be something like
The text was updated successfully, but these errors were encountered: