There is a proposal to support "report-only" violations for feature policy: https://github.com/WICG/feature-policy/blob/824de86f89599240c24b5ae3cd58d25984446af5/reporting.md
I think we should implement this API for these reasons: a. it unifies the reporting of violations and interventions. At the moment we have FeaturePolicy, Interventions, crashes and deprecated APIs, but it's easy to imagine reports coming from CSP violations, CORB, Origin-policy etc. b. Often, when an intervention is made, the only thing a browser does is to write a message in the console. autoplay heuristic and tracking protection are just 2 examples. Here we can do something more: we can communicate something to the page, using ReportingObserver. c. it's a nice diagnostic tool for websites. In the 'report-to' HTTP header, entry-points can be used as communication channel between the browser and the server. On Thu, Nov 15, 2018 at 5:25 PM Boris Zbarsky <bzbar...@mit.edu> wrote: > On 11/15/18 9:52 AM, Ehsan Akhgari wrote: > > The idea is to use Feature Policy in report-only mode > > There is no report-only mode in the Feature Policy spec, nor in our > implementation. See the note at the end of > https://wicg.github.io/feature-policy/#reporting > > So I'm back to my question: is this an API we actually want to > implement? It seems like a fair amount of complexity and overhead and > the one use case so far is for sites to have telemetry for when they're > ending up with feature policy violations, right? > > -Boris > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
