Available only in a secure context?

[bicknellr]

Because this API relates to the ability to do work in the background, which is considered a privilege, functionality provided by this API is only available in a secure context.

I don't think this API itself should be limited to use in secure contexts. It would make more sense if you weren't in a secure context that the API exists but reports that there was no available budget for a particular action requiring a secure context.

[beverloo]

I think of background operations, the currently defined scope of features the spec is applicable for, as a privilege that should never be given to insecure contexts. Removing this restriction would also mean increasing the specification's scope.

Do you have specific features in mind that you think would benefit from the Budget API, and are available on insecure contexts?

[Krinkle]

@beverloo I can't think of use cases offhand, but I think the idea is that we'd rather have a single set of reusable code rather than the API sometimes not existing.

Alternatively, this can be done through a feature test. That seems straight-forward now; when it's early days and implementations are few; but this may be less intuitive some years later. It may be useful to then have the interface exist unconditionally and return falsey/no-op. That way, code optimised for newer browsers that support it can actually call it unconditionally.

This is moot of course if the API is only exposed in the scope of service workers / background sync, which themselves cannot be established outside secure contexts, either.