Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Drop the feature" is not really an option #48

Open
cynthia opened this issue Feb 7, 2019 · 12 comments

Comments

@cynthia
Copy link
Member

commented Feb 7, 2019

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

This comment has been minimized.

Copy link

commented Feb 7, 2019

See also w3cping#19

@hober

This comment has been minimized.

Copy link

commented Feb 7, 2019

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

This comment has been minimized.

Copy link
Member

commented Feb 7, 2019

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

@slightlyoff

This comment has been minimized.

Copy link
Member

commented Feb 7, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Feb 7, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Feb 7, 2019

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

This comment has been minimized.

Copy link

commented Feb 7, 2019

+1 @lknik

@lknik

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

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

This comment has been minimized.

Copy link

commented May 23, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

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

@lknik lknik self-assigned this May 23, 2019

@dbaron

This comment has been minimized.

Copy link
Member

commented May 24, 2019

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

This comment has been minimized.

Copy link
Member

commented Jul 3, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.