{"action":"created","issue":{"url":"https://api.github.com/repos/igrigorik/feature-policy/issues/10","repository_url":"https://api.github.com/repos/igrigorik/feature-policy","labels_url":"https://api.github.com/repos/igrigorik/feature-policy/issues/10/labels{/name}","comments_url":"https://api.github.com/repos/igrigorik/feature-policy/issues/10/comments","events_url":"https://api.github.com/repos/igrigorik/feature-policy/issues/10/events","html_url":"https://github.com/igrigorik/feature-policy/issues/10","id":156794814,"number":10,"title":"Mechanisms to \"disable\" a feature","user":{"login":"igrigorik","id":10652,"avatar_url":"https://avatars.githubusercontent.com/u/10652?v=3","gravatar_id":"","url":"https://api.github.com/users/igrigorik","html_url":"https://github.com/igrigorik","followers_url":"https://api.github.com/users/igrigorik/followers","following_url":"https://api.github.com/users/igrigorik/following{/other_user}","gists_url":"https://api.github.com/users/igrigorik/gists{/gist_id}","starred_url":"https://api.github.com/users/igrigorik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/igrigorik/subscriptions","organizations_url":"https://api.github.com/users/igrigorik/orgs","repos_url":"https://api.github.com/users/igrigorik/repos","events_url":"https://api.github.com/users/igrigorik/events{/privacy}","received_events_url":"https://api.github.com/users/igrigorik/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-05-25T16:30:30Z","updated_at":"2016-05-26T19:36:23Z","closed_at":null,"body":"Page author sets a policy that disables features [a, b, c]. How do we enforce said policy?\r\n\r\n1. We can ignore the call and optionally log a console error\r\n - e.g. sandbox no-op's [alert/prompt/others](https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/LocalDOMWindow.cpp&q=%22is%20sandboxed%22%20file:.cpp&sq=package:chromium&type=cs&l=784) and logs an error message to console; [sync-script simply ignores](https://igrigorik.github.io/feature-policy/#sync-script) scripts that have their non-blocking flag unset.\r\n1. We can throw an exception when:\r\n - the interface constructor is invoked\r\n - a particular method and/or getter+setter is called (e.g. [document.cookie](https://igrigorik.github.io/feature-policy/#cookie))\r\n - some method arguments are rejected (e.g. [sync-xhr](https://igrigorik.github.io/feature-policy/#sync-xhr))\r\n1. We can force [PermissionState to 'denied'](https://www.w3.org/TR/permissions/#idl-def-PermissionState-denied) and return an error explaining why.. for API's that are mediated by Permission API.\r\n - e.g. In Chrome, [Geolocation API takes this route](https://developers.google.com/web/updates/2016/04/geolocation-on-secure-contexts-only?hl=en) on insecure contexts. \r\n1. We can \"hide\" the relevant interfaces.\r\n - [Origin Trials](https://github.com/jpchase/OriginTrials/blob/gh-pages/explainer.md) selectively enables certain interfaces at runtime, based on provided tokens. Theoretically, we could leverage similar plumbing to hide interfaces as well?\r\n\r\n\r\n... any other strategies that are missing from the list above? Additional examples:\r\n - [Sandbox enforcement in Chrome](https://code.google.com/p/chromium/codesearch#search/&q=%22is%20sandboxed%22%20file:.cpp&sq=package:chromium&type=cs)\r\n - [Specced disable directives in FP](https://igrigorik.github.io/feature-policy/#features)\r\n\r\n---\r\n\r\nGiven a mix of use cases that we're trying to prevent, ranging from disabling entire interfaces to rejecting calls based on certain method parameters... I don't think we can settle on a _single_ strategy, but it would be nice to develop some ordered preference list. \r\n\r\n- For example, while Origin Trials selectively enables interfaces. Is that a pattern we should consider (prefer?) for disabling interfaces? Pro: we don't have to patch other specs, we just hide the interface. However, is this practical to implement in all the various UA's? \r\n- If API access is mediated by Permission API, should we prefer the Permission denied route? We have many existing examples of this. Intuitively, I think it makes sense to developers: the result of a user declining access request is the same, we should trigger same (existing) code paths.\r\n\r\n/cc @ojanvafai @esprehn @mikewest "},"comment":{"url":"https://api.github.com/repos/igrigorik/feature-policy/issues/comments/221972005","html_url":"https://github.com/igrigorik/feature-policy/issues/10#issuecomment-221972005","issue_url":"https://api.github.com/repos/igrigorik/feature-policy/issues/10","id":221972005,"user":{"login":"igrigorik","id":10652,"avatar_url":"https://avatars.githubusercontent.com/u/10652?v=3","gravatar_id":"","url":"https://api.github.com/users/igrigorik","html_url":"https://github.com/igrigorik","followers_url":"https://api.github.com/users/igrigorik/followers","following_url":"https://api.github.com/users/igrigorik/following{/other_user}","gists_url":"https://api.github.com/users/igrigorik/gists{/gist_id}","starred_url":"https://api.github.com/users/igrigorik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/igrigorik/subscriptions","organizations_url":"https://api.github.com/users/igrigorik/orgs","repos_url":"https://api.github.com/users/igrigorik/repos","events_url":"https://api.github.com/users/igrigorik/events{/privacy}","received_events_url":"https://api.github.com/users/igrigorik/received_events","type":"User","site_admin":false},"created_at":"2016-05-26T19:36:23Z","updated_at":"2016-05-26T19:36:23Z","body":"Doing a bit more digging on (4)...\r\n\r\nFrom [Original Trials design doc](https://docs.google.com/document/d/1qVP2CK1lbfmtIJRIm6nwuEFFhGhYbtThLQPo3CSTtmg/edit):\r\n> The [OriginTrialEnabled] IDL attribute works similarly to the existing [RuntimeEnabled] attribute.  The [OriginTrialEnabled] attribute is intended as a drop-in replacement for the [RuntimeEnabled] attribute, including using the same runtime feature flag name.\r\n\r\nFrom [Blink Runtime Enabled Feature](https://www.chromium.org/blink/runtime-enabled-features):\r\n> Runtime flags enable Blink developers the ability to control access Chromium users have to new features they implement. Features that are hidden behind a runtime flag are known as Runtime Enabled Features.\r\n> - You can guard the entire interface\r\n> - You can guard individual definition members\r\n> - You can use overloading and guard arguments\r\n> \r\n> Warning: you will not be able to change the enabled state of these at runtime as the V8 object templates definitions are created during start up and will not be updated during runtime.\r\n\r\nIf you squint enough... One could imagine \"disabling\" features ~via:\r\n\r\n```idl\r\n[RuntimeEnabled=FeaturePolicyGeolocation] interface NavigatorGeolocation {\r\n   readonly attribute Geolocation geolocation;\r\n };\r\n\r\ninterface Document {\r\n    [RuntimeEnabled=FeaturePolicyCookie] attribute DOMString cookie;\r\n    [RuntimeEnabled=FeaturePolicyDocWrite] void write();\r\n};\r\n```\r\n\r\n- Pro: we don't have to monkey patch each spec and method.\r\n- Pro: much easier to reason about policies like \"disable webrtc\", which consist of many different API's and interfaces that need to be disabled.\r\n- Con: If we go down this route, I don't think we can do reporting... at least, not easily. That said, if the developers attempts to call one of the disabled API's, they can catch the exception via window.onerror and decide if they want to log it themselves.\r\n\r\nHmm? Should we prefer this route to other strategies? Even if we can make it work in Blink, would other UA's be able to support this?"}}
{"actor":{"display_login":"igrigorik"}}