(In reply to Steven Englehardt [:englehardt] from comment #6) > The "content" version of the cryptomining list is currently unused, as in we don't have any domains on it. In general we've used "content" versions of lists to include domains that are known to cause breakage when blocked. Since we're only just starting to build on this list and experiment with it, we haven't yet had to deal with breakage. I created the content version as a placeholder in the event we find there are some domains we're unable to block. > > I suspect we'll only consume the base version of the list in Firefox desktop as we generally take a conservative approach in our content blocking / tracking protection features. What are the norms for geckoview with regards to tolerance for breakage? It looks the content category of the tracking list is also off unless explicitly enabled by the user? With GeckoView our goal is to expose all effective privacy tools to give app developers a wide range of options. Since GeckoView's "user" is not the end user, our default don't have the same significance as it is the case with Firefox defaults. It is up to the app developer to decide on sensible app defaults and/or which app settings they want to expose to their users. At the same time, we would like to avoid exposing experimental APIs and settings to be in the position to ensure API stability at some point. So when exposing a Gecko feature, the main questions should not be about defaults, but about its effectiveness and side effects, which need to be properly documented in the API docs. Since the content blocklist is only a placeholder at this point, I think it's best to remove it from the implementation and revisit extending the API once we have more information on its effects. On a general note, do you think that exposing the cryptomining setting (with the base list) is a good idea at this point, do we have any data on the effects of the new blocklist?
Bug 1530789 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Steven Englehardt [:englehardt] from comment #6) > The "content" version of the cryptomining list is currently unused, as in we don't have any domains on it. In general we've used "content" versions of lists to include domains that are known to cause breakage when blocked. Since we're only just starting to build on this list and experiment with it, we haven't yet had to deal with breakage. I created the content version as a placeholder in the event we find there are some domains we're unable to block. > > I suspect we'll only consume the base version of the list in Firefox desktop as we generally take a conservative approach in our content blocking / tracking protection features. What are the norms for geckoview with regards to tolerance for breakage? It looks the content category of the tracking list is also off unless explicitly enabled by the user? With GeckoView our goal is to expose all effective privacy tools to give app developers a wide range of options. Since GeckoView's "user" is not the end user, our defaults don't have the same significance as it is the case with Firefox defaults. It is up to the app developer to decide on sensible app defaults and/or which app settings they want to expose to their users. At the same time, we would like to avoid exposing experimental APIs and settings to be in the position to ensure API stability at some point. So when exposing a Gecko feature, the main questions should not be about defaults, but about its effectiveness and side effects, which need to be properly documented in the API docs. Since the content blocklist is only a placeholder at this point, I think it's best to remove it from the implementation and revisit extending the API once we have more information on its effects. On a general note, do you think that exposing the cryptomining setting (with the base list) is a good idea at this point, do we have any data on the effects of the new blocklist?
(In reply to Steven Englehardt [:englehardt] from comment #6) > The "content" version of the cryptomining list is currently unused, as in we don't have any domains on it. In general we've used "content" versions of lists to include domains that are known to cause breakage when blocked. Since we're only just starting to build on this list and experiment with it, we haven't yet had to deal with breakage. I created the content version as a placeholder in the event we find there are some domains we're unable to block. > > I suspect we'll only consume the base version of the list in Firefox desktop as we generally take a conservative approach in our content blocking / tracking protection features. What are the norms for geckoview with regards to tolerance for breakage? It looks the content category of the tracking list is also off unless explicitly enabled by the user? With GeckoView our goal is to expose all effective privacy tools to give app developers a wide range of options. Since GeckoView's "user" is not the end user, our defaults don't have the same significance as it is the case with Firefox defaults. It is up to the app developer to decide on sensible app defaults and/or which app settings they want to expose to their users. At the same time, we would like to avoid exposing experimental APIs and settings to be in the position to ensure API stability at some point. So when exposing a Gecko feature, the main question should not be about defaults, but about its effectiveness and side effects, which need to be properly documented in the API docs. Since the content blocklist is only a placeholder at this point, I think it's best to remove it from the implementation and revisit extending the API once we have more information on its effects. On a general note, do you think that exposing the cryptomining setting (with the base list) is a good idea at this point, do we have any data on the effects of the new blocklist?
(In reply to Steven Englehardt [:englehardt] from comment #6) > The "content" version of the cryptomining list is currently unused, as in we don't have any domains on it. In general we've used "content" versions of lists to include domains that are known to cause breakage when blocked. Since we're only just starting to build on this list and experiment with it, we haven't yet had to deal with breakage. I created the content version as a placeholder in the event we find there are some domains we're unable to block. > > I suspect we'll only consume the base version of the list in Firefox desktop as we generally take a conservative approach in our content blocking / tracking protection features. What are the norms for geckoview with regards to tolerance for breakage? It looks the content category of the tracking list is also off unless explicitly enabled by the user? With GeckoView our goal is to expose all effective privacy tools to give app developers a wide range of options. Since GeckoView's "user" is not the end user, our defaults don't have the same significance as it is the case with Firefox defaults. It is up to the app developer to decide on sensible app defaults and/or which app settings they want to expose to their users. At the same time, we would like to avoid exposing experimental APIs and settings for API stability. So when exposing a Gecko feature, the main question should not be about defaults, but about its effectiveness and side effects, which need to be properly documented in the API docs. Since the content blocklist is only a placeholder at this point, I think it's best to remove it from the implementation and revisit extending the API once we have more information on its effects. On a general note, do you think that exposing the cryptomining setting (with the base list) is a good idea at this point, do we have any data on the effects of the new blocklist?
(In reply to Steven Englehardt [:englehardt] from comment #6) > The "content" version of the cryptomining list is currently unused, as in we don't have any domains on it. In general we've used "content" versions of lists to include domains that are known to cause breakage when blocked. Since we're only just starting to build on this list and experiment with it, we haven't yet had to deal with breakage. I created the content version as a placeholder in the event we find there are some domains we're unable to block. > > I suspect we'll only consume the base version of the list in Firefox desktop as we generally take a conservative approach in our content blocking / tracking protection features. What are the norms for geckoview with regards to tolerance for breakage? It looks the content category of the tracking list is also off unless explicitly enabled by the user? With GeckoView our goal is to expose all effective privacy tools to give app developers a wide range of options. Since GeckoView's "user" is not the end user, our defaults don't have the same significance as it is the case with Firefox defaults. It is up to the app developer to decide on sensible app defaults and/or which app settings they want to expose to their users. At the same time, we would like to avoid exposing experimental APIs and settings for API stability. When exposing a Gecko feature, the main question should not be about defaults, but about its effectiveness and side effects, which need to be properly documented in the API docs. Since the content blocklist is only a placeholder at this point, I think it's best to remove it from the implementation and revisit extending the API once we have more information on its effects. On a general note, do you think that exposing the cryptomining setting (with the base list) is a good idea at this point, do we have any data on the effects of the new blocklist?