Issue metadata
Sign in to add a comment
|
[Component Request] Blink>SecurityFeature>* |
||||||||||||||||||||||
Issue description1] Component Name: I'd like to add a few subcomponents to `Blink>SecurityFeature` to more reflect the issues we're seeing with more feature-specific granularity. I'd suggest the following: * ContentSecurityPolicy * CORS * CredentialManagement * Referrer * SameOriginPolicy * Sandbox * SecureContexts * XFrameOptions * XSSAuditor It's not entirely clear to me what the cost of adding a component actually is; if adding a few subcomponents is expensive, I can try to come up with a more condensed grouping. 2] Parent Component (e.g. Blink, UI>Browser, etc...): Blink>SecurityFeature 3] Description of Component: I don't think we need distinct descriptions for most of these; they should be self-explantory, as they map directly to web-exposed concepts or APIs. Happy to come up with descriptive text if you disagree. 4] Admin/ Owner: mkwst@chromium.org (I should probably be marked as the admin of `Blink>SecurityFeature` as well). 5] Please specify what triage practices will be followed for the component My team will triage each of these components via a small rotation. We haven't been doing a great job of that in the past, but I'm committed to it going forward.
,
Mar 2 2017
Not sure what the triage process is for these requests... sshruthi@, laforge@, should I be sending email to a list as well as filing this issue?
,
Mar 2 2017
The request is a little more complex than normal, will need some extras time to process. My main question would be how these components interact with existing ones.
,
Mar 2 2017
The components basically map to individual features that have security impact and are web/developer-facing. Right now, issues that fall into these categories get lumped into the `Blink>SecurityFeature` component; I'd appreciate more granularity for both triage and prioritization/allocation. Happy to chat in more detail if it would be helpful. I don't really understand the challenges y'all face from an organizational perspective, or the cost of adding components, so I'm happy to work with y'all to figure out what makes the most sense here.
,
Mar 6 2017
I've created those components and set you as the admin. Please go in and add appropriate descriptions (1). One note, for the moment, I flagged Blink>SecurityFeature>Sandbox as deprecated. The reason for this is that we already have an Internals>Sandbox component and I'm weary of creating a potentially confusing component that mirrors the naming, but is narrower in scope. How would you feel about replacing that with Internals>Sandbox>Renderer? (1) - https://bugs.chromium.org/p/chromium/adminComponents although I'm now
,
Mar 6 2017
Thanks! Hrm. I meant `SecurityFeatures>Sandbox` to cover `<iframe sandbox>`, not the process-level sandbox that `Internals>Sandbox` covers. I agree with you that the naming is confusing. WDYT about just dropping `SecurityFeatures>Sandbox`, instead using a combination of `Blink>SecurityFeature` and `Blink>HTML>Iframe` for `<iframe sandbox>` issues?
,
Mar 6 2017
How about IFrameSandbox?
,
Apr 10 2017
Hey Mike, I'm fine w/ using either Blink>SecurityFeature + Blink>HTML>Iframe or IFrameSandbox (added it today as well). Depending on your preference you are welcome to use or deprecate the new IFrameSandbox component (i.e. you're set as an admin on it, just need to flag "Deprecated"). https://bugs.chromium.org/p/chromium/components/detail?component=Blink%3ESecurityFeature%3EIFrameSandbox |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 Deleted