Building dav1d 0.2.1 - nasm error
Hi all, I've been trying to build dav1d 0.2 but I always end with meson error Unusable script '/usr/bin/nasm' Program nasm found: NO meson.build:324:4: ERROR: Program(s) ['nasm'] not found or not executable Eventhough the path /usr/bin/nasm has nasm in it(latest version). Maybe am I missing something here? please suggest me to get this error. THanks, Gangadharan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: cryptomining and fingerprinting resource blocking
Why are these sites not included in the "safe browsing" service that is used by most browsers? That way, everyone would be protected. On Thu, Mar 21, 2019 at 2:59 PM Steven Englehardt wrote: > Summary: > We are expanding the set of resources blocked by Content Blocking to > include domains found to participate in cryptomining and fingerprinting. > Cryptomining has a significant impact on a device’s resources [0], and the > scripts are almost exclusively deployed without notice to the user [1]. > Fingerprinting has long been used to track users, and is in violation our > anti-tracking policy [2]. > > In support of this, we’ve worked with Disconnect to introduce two new > categories of resources to their list: cryptominers [3] and fingerprinters > [4]. As of Firefox 67, we have exposed options to block these categories of > domains under the “Custom” section of the Content Blocking in > about:preferences#privacy. We are actively working with Disconnect to > discover new domains that participate in these practices, and expect the > lists to grow over time. A full description of the lists is given here [5]. > > Bugs: > Implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1513159 > Breakage: > Cryptomining: https://bugzilla.mozilla.org/show_bug.cgi?id=1527015 > Fingerprinting: https://bugzilla.mozilla.org/show_bug.cgi?id=1527013 > > We plan to test the impact of blocking these categories during the Firefox > 67 release cycle [6][7]. We are currently targeting Firefox 69 to block > both categories by default, however this may change depending on the > results of our user studies. > > To further field test the new lists, we expect to enable the blocking of > both categories by default in Nightly within the coming month. If you do > discover breakage related to this feature, we ask that you report it in one > of the cryptomining or fingerprinting blocking breakage bugs above. > > Link to standard: These are additions to Content Blocking/Tracking > Protection which is not a feature we've standardized. > > Platform coverage: > Desktop for now. It is being considered for geckoview: ( > https://bugzilla.mozilla.org/show_bug.cgi?id=1530789) but is on hold until > the feature is more thoroughly tested. > > Estimated release: > Disabled by default and available for testing in Firefox 67. We expect to > ship this on by default in a future release, pending user testing results. > An intent to ship will be sent later. > > Preferences: > * privacy.trackingprotection.fingerprinting.enabled - controls whether > fingerprinting blocking is enabled > * privacy.trackingprotection.cryptomining.enabled - controls whether > cryptomining blocking is enabled > > These can also be enabled using the checkboxes under the Custom section of > Content Blocking in about:preferences#privacy for Firefox 67+. > > Is this feature enabled by default in sandboxed iframes?: Blocking applies > to all resources, regardless of their source. > > DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1537627 > When blocking of either category is enabled, any blocked resources will be > logged to the console with the following message: `The resource at “ > example.com” was blocked because content blocking is enabled.` > > Do other browser engines implement this? > Opera and Brave block cryptominers using the no-coin cryptomining list > [8][9]. The cryptomining list supplied by Disconnect is, in part, created > by matching web crawl data against no-coin and other crowdsourced lists. > No other browsers currently block the fingerprinting list, as we are > working with Disconnect to build it for this feature. However, many of the > domains on the fingerprinting list are likely to appear on other > crowdsourced adblocking lists. > > Web-platform-tests: Since content blocking is not a standardized feature, > there are no wpts. > > Is this feature restricted to secure contexts? No. Users benefit from > blocking in all contexts. > > [0] https://arxiv.org/pdf/1806.01994.pdf > [1] https://nikita.ca/papers/outguard-www19.pdf > [2] https://wiki.mozilla.org/Security/Anti_tracking_policy > [3] > > https://github.com/mozilla-services/shavar-prod-lists/blob/7eaadac98bc9dcc95ce917eff7bbb21cb71484ec/disconnect-blacklist.json#L9537 > [4] > > https://github.com/mozilla-services/shavar-prod-lists/blob/7eaadac98bc9dcc95ce917eff7bbb21cb71484ec/disconnect-blacklist.json#L9316 > [5] https://wiki.mozilla.org/Security/Tracking_protection#Lists > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1533778 > [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1530080 > [8] > > https://www.zdnet.com/article/opera-just-added-a-bitcoin-mining-blocker-to-its-browser/ > [9] https://github.com/brave/adblock-lists/blob/master/coin-miners.txt > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list
Intent to implement: cryptomining and fingerprinting resource blocking
Summary: We are expanding the set of resources blocked by Content Blocking to include domains found to participate in cryptomining and fingerprinting. Cryptomining has a significant impact on a device’s resources [0], and the scripts are almost exclusively deployed without notice to the user [1]. Fingerprinting has long been used to track users, and is in violation our anti-tracking policy [2]. In support of this, we’ve worked with Disconnect to introduce two new categories of resources to their list: cryptominers [3] and fingerprinters [4]. As of Firefox 67, we have exposed options to block these categories of domains under the “Custom” section of the Content Blocking in about:preferences#privacy. We are actively working with Disconnect to discover new domains that participate in these practices, and expect the lists to grow over time. A full description of the lists is given here [5]. Bugs: Implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1513159 Breakage: Cryptomining: https://bugzilla.mozilla.org/show_bug.cgi?id=1527015 Fingerprinting: https://bugzilla.mozilla.org/show_bug.cgi?id=1527013 We plan to test the impact of blocking these categories during the Firefox 67 release cycle [6][7]. We are currently targeting Firefox 69 to block both categories by default, however this may change depending on the results of our user studies. To further field test the new lists, we expect to enable the blocking of both categories by default in Nightly within the coming month. If you do discover breakage related to this feature, we ask that you report it in one of the cryptomining or fingerprinting blocking breakage bugs above. Link to standard: These are additions to Content Blocking/Tracking Protection which is not a feature we've standardized. Platform coverage: Desktop for now. It is being considered for geckoview: ( https://bugzilla.mozilla.org/show_bug.cgi?id=1530789) but is on hold until the feature is more thoroughly tested. Estimated release: Disabled by default and available for testing in Firefox 67. We expect to ship this on by default in a future release, pending user testing results. An intent to ship will be sent later. Preferences: * privacy.trackingprotection.fingerprinting.enabled - controls whether fingerprinting blocking is enabled * privacy.trackingprotection.cryptomining.enabled - controls whether cryptomining blocking is enabled These can also be enabled using the checkboxes under the Custom section of Content Blocking in about:preferences#privacy for Firefox 67+. Is this feature enabled by default in sandboxed iframes?: Blocking applies to all resources, regardless of their source. DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1537627 When blocking of either category is enabled, any blocked resources will be logged to the console with the following message: `The resource at “ example.com” was blocked because content blocking is enabled.` Do other browser engines implement this? Opera and Brave block cryptominers using the no-coin cryptomining list [8][9]. The cryptomining list supplied by Disconnect is, in part, created by matching web crawl data against no-coin and other crowdsourced lists. No other browsers currently block the fingerprinting list, as we are working with Disconnect to build it for this feature. However, many of the domains on the fingerprinting list are likely to appear on other crowdsourced adblocking lists. Web-platform-tests: Since content blocking is not a standardized feature, there are no wpts. Is this feature restricted to secure contexts? No. Users benefit from blocking in all contexts. [0] https://arxiv.org/pdf/1806.01994.pdf [1] https://nikita.ca/papers/outguard-www19.pdf [2] https://wiki.mozilla.org/Security/Anti_tracking_policy [3] https://github.com/mozilla-services/shavar-prod-lists/blob/7eaadac98bc9dcc95ce917eff7bbb21cb71484ec/disconnect-blacklist.json#L9537 [4] https://github.com/mozilla-services/shavar-prod-lists/blob/7eaadac98bc9dcc95ce917eff7bbb21cb71484ec/disconnect-blacklist.json#L9316 [5] https://wiki.mozilla.org/Security/Tracking_protection#Lists [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1533778 [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1530080 [8] https://www.zdnet.com/article/opera-just-added-a-bitcoin-mining-blocker-to-its-browser/ [9] https://github.com/brave/adblock-lists/blob/master/coin-miners.txt ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts
On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones wrote: > It appears that if we want full security key support for Google > Accounts in Firefox in the near term, we need to graduate our FIDO U2F > API support from “experimental and behind a pref” I think it's problematic to describe something as "experimental" if it's not on path to getting enabled. "Experimental and behind a pref" sounds like it's on track to getting enabled, so simultaneously 1) sites have a reason to believe they don't need to do anything for Firefox, since for now users can flip a pref and the feature is coming anyway and 2) still the feature doesn't actually work by default for users, and, considering the penalty of using an experimental feature where the experiment fails is getting locked out of an account for this particular feature. So I think it's especially important to move *somewhere* from the "experimental and behind a pref" state: Either to interop with Chrome to the extent required by actual sites (regardless of what's de jure standard) or to clear removal so that the feature doesn't look like sites should just wait for it to get enabled and that the sites expect the user to flip a pref. As a user, I'd prefer the "interop with Chrome" option. > to either “enabled > by default” or “enabled for specific domains by default.” I am > proposing the latter. Why not the former? Won't the latter still make other sites wait in the hope that if they don't change, they'll get onto the list eventually anyway? > First, we only implemented the optional Javascript version of the API, > not the required MessagePort implementation [3]. This is mostly > semantics, because everyone actually uses the JS API via a > Google-supplied polyfill called u2f-api.js. Do I understand correctly that the part that is actually needed for interop is implemented? > As I’ve tried to establish, I’ve had reasons to resist shipping the > FIDO U2F API in Firefox, and I believe those reasons to be valid. > However, a multi-year delay for the largest security key-enabled web > property is, I think, unreasonable to push upon our users. We should > do what’s necessary to enable full security key support on Google > Accounts as quickly as is practical. This concern seems to apply to other services as well. > I’ve proposed here making the FIDO U2F API whitelist a pref. I can’t > say whether I would welcome adding more domains to it by default; I > think we’re going to have to take them on a case-by-case basis. What user-relevant problem is solved by having to add domains to a list compared to making the feature available to all domains? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
