Should "drop the feature" be one of our recommended mitigation strategies

[cynthia]

https://w3ctag.github.io/security-questionnaire/#drop-feature

Section 5.6 suggests that the simplest way is to drop the feature. This might be simple from the perspective of the reviewer, but presumably the design is being proposed with a motivation to solve an important problem for developers or end-users. Our work as reviewers is to help folks weigh this balance, rather than to suggest that they're simply wrong for wanting to solve problems. We have guidelines on the topic of putting powerful features behind permissions and I think the tone here contradicts with how we want the platform to advance. There are ways of balancing the risks, and we should be trying to help teams navigate that balance going forward. Suggesting they simply stop appears to put a thumb on the scales, suggesting the TAG is hostile to new features in general -- which we are not.

Ideally it should be reworded in a way that suggests tucking it behind a permission or dial down the granularity/power to mitigate the risks involved.

(Partially written by @slightlyoff.)

[hober]

See also w3cping#19

[hober]

FWIW, I disagree. One of the conclusions that emerged from the permissions workshop last fall (which will hopefully prominently feature in the as-yet-unpublished workshop report) is that the first question that should be asked when someone proposes to add a powerful feature to the Web platform which would require a permissions prompt is "does such a feature belong on the Web"/"should we be adding this feature in the first place?"

[mnot]

+1 to @hober. The onus needs to be firmly upon those who want to extend the platform, not the other way around.

[slightlyoff]

The advice the TAG gives to folks asking for review is about being collaborative in helping them sort out issues with the design. The TAG can't cause people to ship (or not) (as everyone on this thread knows).

What we should be asking for is evidence of need. That's what Explainers and most of the other process we have adopted are designed to do. As a review body with no formal power, the TAG retains whatever standing it has by being collaborative. Striking an argumentative tone at the front of the document is, in that context, perhaps unhelpful.

[cynthia]

the first question that should be asked when someone proposes to add a powerful feature to the Web platform which would require a permissions prompt is "does such a feature belong on the Web"/"should we be adding this feature in the first place?"

At the point where we have received the review, I suspect there was already a reasonable amount of self-assessment on this topic and I would like to think that it was deemed that the gain outweighs the risks.

The tone should be really about "how do we make this dangerous feature safe", not about "your problem isn't big enough to even consider in the first place". We can deal with the risk assessment in the review process, but the authors should be given something to work with rather than suggesting "no, please don't".

The conservative attitude in the past triggered numerous web-ish-but-not-quite-web forks which have been problematic to many of us. (JIL/BONDI come to mind, others I will not name as they are still being used and there are people still working on those standards.)

[lknik]

Hello. Thanks for your concern. I understand the concern expressed here. For starters, I could drop @mikewest under the bus as the original proponent, but why would I.

The spirit is more close as @hober highlighted, and we never meant to be aggressive here. I am all for improvement. This is why we have other suggestions in the document (and they are favored, we favor improvement and handling risk, it should be clear).

That said, we've seen in the past some UAs removing features or APIs due to privacy concern, so although the "drop the feature" (reword it?) mechanic sounds radical, it is actually being followed, even if very rarely. The rationale behind retaining this point was never towards "do not develop the web".

Furthermore, the environment (including state of the art, and knowledge) tends to evolve as well, and some features not seen as problematic today, may be - in the future.

[josephlhall]

+1 @lknik

[lknik]

Discussed in Reykjavik f2f. Consensus is the issue remains open and we're open for further feedback, but we keep this point in the questionnaire.

[jyasskin]

2¢: I think the questionnaire is correct to include the "drop the feature" section, and strikes a good tone in that section. It doesn't come across as argumentative to me, and it only presents "drop the feature" as one option it's important to consider, not the usually-preferred option.

One framework I tend to use when thinking about this, which I don't see mentioned in the document, is to ask both "What security/privacy risks are added by adding the feature to the web platform?" and "What security/privacy risks are removed by adding the feature to the web platform?" This led me to favor adding features like Web Bluetooth, where the simpler approach of asking only "what risks are added?" led Firefox and Safari to decide they shouldn't add it.

[lknik]

Thanks @jyasskin for your feedback. Indeed there are many options out there. Thanks also for sharing additional thoughts on the broad approach you use.

[dbaron]

One framework I tend to use when thinking about this, which I don't see mentioned in the document, is to ask both "What security/privacy risks are added by adding the feature to the web platform?" and "What security/privacy risks are removed by adding the feature to the web platform?" This led me to favor adding features like Web Bluetooth, where the simpler approach of asking only "what risks are added?" led Firefox and Safari to decide they shouldn't add it.

I think that's a fine thing to consider, although I'm far from convinced that it would lead to the conclusions that you say it does regarding Web Bluetooth. Detailed discussion of that specific point probably doesn't belong in that issue, though.

I also think there's a third piece that needs to be considered: not just the specific security risks added from one specific feature, but the effect of adding those security risks to the overall picture that users have about the idea that it is safe to visit websites. A big piece of the web's value is that it is safe for users to visit websites. In order for this value to exist, users must understand that it is safer to visit websites than to install apps or software, and act based on that understanding. Doing things that complicate that understanding or complicate what users need to understand about the safety of the web (e.g., adding features that are less safe) reduces the ability of users to act based on that understanding of safety, or to act in ways that correctly reflect the safety that exists.

---

I'd also note the TAG had a discussion of this specific point yesterday; minutes should be available within a few days, I hope.

[dbaron]

Here are the minutes I mentioned.

[hober]

Changed the title of this issue to reflect the lack of consensus on it.

[masinter]

If you want to help people with proposed new features, help them articulate what problem it solves, with something better than "the web doesn't have this feature".

The biggest problems for security and privacy are cross-layer attacks.

[floort]

I don't believe there is a good reason to avoid mentioning any reasonable measure to reduce risk.