Add sections on the Web being safe to browse, trusted user interface, and asking users for consent. #155

dbaron · 2020-02-07T00:49:09Z

This is a very rough draft of changes to add sections on the Web being safe to browse, trusted user interface, and asking users for consent. It is intended to fix #146, though it's possible I've gone a little bit beyond my remit in that issue.

This contains a bunch of ideas that I think are widely accepted, but also some that are probably less so, and some that could certainly use more research on what users actually understand about the web's safety. (I thought about whether to explicitly call out the desire for research on that, but so far haven't done so.)

I think this will likely need a considerable amount of review and refinement. I suspect if I kept it on my computer until next week and then looked at it again, I'd want to rewrite most or all of it. But nevertheless I think it's useful to get some feedback on it, particularly on the high-level aspects: are these the right topics to bring up here, the right way to organize them, and the right points to make?

I've picked a few reviewers who I think are likely to have comments, but I'd welcome comments from others as well.

… and asking users for consent. Fixes w3ctag#146.

hober

At a high level and on my first, hurried read, this looks really great. I'll try to take a closer look in the next few days.

alice

Some thoughts below. I think this is a good start, but I think we might need a few more iterations.

alice · 2020-02-09T23:38:21Z

index.bs

+Users who are following a link to a web page they haven't seen before
+should not have to fear for the security of their computer
+or for essential aspects of their privacy.
+(One caveat here is that users of the Web


I'm not sure I understand this caveat. I agree with the general principle, of course, but I'm not sure what it adds here - to me it reads as though there can/should be escape hatches from users' privacy protections in cases where the user is harming others, which I'm sure is not the intended reading.

So the caveat is really to the sentence before the quote -- the idea that following a link should always be safe. Taking that position absolutely would imply that we're taking the position that governments shouldn't punish people for, say, viewing child pornography. And I don't think that's a position that I'd like to take. So I want some way to say that we want it to be safe from a technical perspective but not necessarily from a legal one.

(At the same time, there's an entirely separate discussion about mechanisms that governments want to use to enforce some legal rules, and what the downsides of those mechanisms are, and while some of that discussion is relevant to the TAG, I'd like to avoid getting into it in this section.)

I should think more about a better way to word this.

alice · 2020-02-09T23:46:07Z

index.bs

+should not assume that they are free from consequences
+if their use of the Web is harming others.)
+
+Saying “essential aspects” here skips over quite a bit of detail.


I'm also a little unclear on what this paragraph is saying. What user interfaces are you referring to? Can we rephrase this to focus on the point about user expectations and privacy, and either omit the aspirational aspects or give them their own paragraph?

I've tried to do this; I think I pulled the aspirational bits out into their own paragraph, which I actually ended up structuring as a list.

alice · 2020-02-09T23:46:54Z

index.bs

+
+When we add new features to the Web
+that might weaken the security or privacy characteristics that the Web currently has,
+we should consider the tradeoffs involved in that particular feature.


Perhaps this is worthy of its own sub-heading?

Sorry for the delay getting back to these -- I'm going to post revisions soon (I hope) that will address many of the comments.

But while I'm working on that, I wanted to get back to this one: I think this paragraph is still pretty central to the idea that it should be safe to visit a web page, and I think I'd like to keep them together in the same subsection. (But perhaps some of the other edits I'm currently making will make this a little clearer.)

alice · 2020-02-09T23:52:59Z

index.bs

+or whether the connection is secure.
+Since users rely on this information to learn what site they're on
+and to make judgments about whether it is trustworthy,
+it is important that sites not be able to spoof or override this user interface.


This seems out of scope for API design, albeit a critical point for user agent UI design.

It seems like the point below is the more critical one: if a feature relies on adding extra decisions for a user to make, care should be taken that the feature is providing enough value (either through providing a clear user benefit, or through simplifying some other decision process for the user) to make it worthwhile.

I see your point, @alice, but I think it's in scope to the extent that different API shapes make different UI designs easier / more likely / etc.

Perhaps that point should be made more explicitly, in that case?

w3ctag/design-reviews#461 (comment) this seems like a good first pass.

I'm a little confused by @alice's last comment in this thread -- was it meant as a comment on the following section (on informed consent), rather than this section on trusted UI?

(Also, I think the "point below" in the initial comment was referring to the second paragraph of this section, and not the following section, but please correct me if I'm wrong.)

In any case, what I've tried to do here (and I realize I should comment before pushing the changes since pushing the changes will likely hide the review comments) in convert these two paragraphs into one and connect them more closely. Though perhaps you were looking for something different?

alice · 2020-02-09T23:53:43Z

index.bs

+that users will understand what is being requested
+and the main implications of giving their consent.
+
+We should also not ask users to consent to something


Is this worth a separate sub-heading as well?

Does this paragraph argue against the existence of private browsing mode? Users sometimes think that there will be no server-side record of what they did while visiting a site with private browsing mode on.

To @alice's question of separate subheading starting with the third paragraph of this section -- I think both the second and third paragraphs of this section are trying to define the "when appropriate" in the section's title, so I prefer not.

Regarding @hober's question on private browsing mode: I don't think it argues against the existence of such a mode, but I would argue (although this is more tied to the first of the three subsections) that implementations offering such a mode ought to try to adjust its user interface so that users have more accurate expectations of what it does and doesn't do.

alice · 2020-02-09T23:54:49Z

index.bs

+An example of such a feature might be support for location:
+many users seem likely to understand what it means to share their current location with a website
+and be able to consent to doing so
+(even though they might not fully understand the privacy implications of doing so).


Is this an editorial on the geolocation API?

I was trying to say that I think the geolocation API is ok since it's a question that users can understand, even if they don't necessarily follow all the implications of how location tracking is used in today's ecosystem of tracking/sharing/reselling user data.

I think the parenthetical might be best as its own clarifying sentence, in that case.

Perhaps, but I'm going to leave this one as is for now.

alice · 2020-02-09T23:55:39Z

index.bs

+We should not depend on asking the user for consent
+(via a permission prompt or other mechanism)
+if we don't have a way to express that request in a way
+that users will understand what is being requested


Which users? How do we determine what the "target audience" users will or won't be able to understand?

I'll expand on this based on w3ctag/design-reviews#461 (comment) and w3ctag/design-reviews#461 (comment) .

alice · 2020-02-09T23:56:40Z

index.bs

+Asking users for consent via permission prompts
+can both reinforce the idea that the web is safe
+by showing the user that certain things won't happen without their permission,
+and can also show how scary a place the web is


Is this a risk we're warning about?

Maybe. I fully admit it's a little bit off-topic for the section, but I think it's a risk worth mentioning. But I'm open to taking it out if you think it doesn't fit.

Perhaps it should be rewritten as two sentences illustrating two sides of a trade-off.

I changed it to 2 sentences.

hober

After a closer read, I'm still really happy with this. I've left some comments where I think the text could be improved, but I'm okay with landing this as-is and improving it in follow-up patches.

hober · 2020-02-18T21:51:51Z

index.bs

+For example,
+a person walking down the street generally expects to be recognized by their friends,
+but depending on the country,
+may not expect that they were walking down that street to be recorded in a permanent government database.


this sentence reads strangely to me. I think I know what you're trying to say, but this is a confusing way to say it.

Does this read better to anyone else:

For example, a person walking down the street generally expects to be recognized by their friends but,
depending on the country,
they may not expect the fact that they walked down that particular street at that particular time to be recorded in a permanent government database.

I agree it's better. I took most of your suggestions but turned "depending on the country" into a parenthetical and omitted a few words ("the fact", "particular", "particular").

hober · 2020-02-18T21:55:23Z

index.bs

+to make correct judgments about who they're interacting with
+and whether the user interface is trustworthy or spoofed.
+
+<h3 id="informed-consent">Ask users for informed consent when appropriate</h3>


Internally on the WebKit team, we tend to talk about "meaningfully informed consent", by which we mean that not only was the user informed of the risks, they were informed of the risks in a way we believe they're likely to be able to understand and make sound judgments based upon. I don't know if this is a distinction worth making here.

Maybe, though I'm actually worried, based on its definition in other contexts (particularly medical ones), that the term "informed consent" might even be too strong, since it seems to imply being properly informed of all risks. Does "meaningful consent" make sense? I've left it alone for now, but I'm definitely open to changing it.

I like "meaningful consent"

I changed it to "meaningful consent" (and the id to "consent").

hober · 2020-02-18T21:57:44Z

index.bs

+that users will understand what is being requested
+and the main implications of giving their consent.
+
+We should also not ask users to consent to something


Does this paragraph argue against the existence of private browsing mode? Users sometimes think that there will be no server-side record of what they did while visiting a site with private browsing mode on.

…s well, and also a few things I noticed while doing so.

…n the previous commit).

dbaron · 2020-03-03T02:33:18Z

Also, I've made a live version of the changes on this branch visible.

alice

Couple of thoughts that don't need to be addressed in this PR.

alice · 2020-03-03T22:04:28Z

index.bs

+to make correct judgments about who they're interacting with
+and whether the user interface is trustworthy or spoofed.
+
+<h3 id="informed-consent">Ask users for informed consent when appropriate</h3>


I like "meaningful consent"

alice · 2020-03-03T22:05:52Z

index.bs

+An example of such a feature might be support for location:
+many users seem likely to understand what it means to share their current location with a website
+and be able to consent to doing so
+(even though they might not fully understand the privacy implications of doing so).


I think the parenthetical might be best as its own clarifying sentence, in that case.

alice · 2020-03-03T22:07:42Z

index.bs

+Asking users for consent via permission prompts
+can both reinforce the idea that the web is safe
+by showing the user that certain things won't happen without their permission,
+and can also show how scary a place the web is


Perhaps it should be rewritten as two sentences illustrating two sides of a trade-off.

Add sections on the Web being safe to browse, trusted user interface,…

2708c83

… and asking users for consent. Fixes w3ctag#146.

dbaron requested review from hober and torgo February 7, 2020 00:49

hober approved these changes Feb 7, 2020

View reviewed changes

alice reviewed Feb 9, 2020

View reviewed changes

This was referenced Feb 12, 2020

Needs an Introduction #153

Closed

Web NFC w3ctag/design-reviews#461

Closed

hober approved these changes Feb 18, 2020

View reviewed changes

dbaron added 2 commits February 20, 2020 16:17

Address review from @alice which includes some feedback from @hober a…

722792b

…s well, and also a few things I noticed while doing so.

Address additional feedback from @hober's review (some of which was i…

a1fccdd

…n the previous commit).

dbaron self-assigned this Mar 2, 2020

alice approved these changes Mar 3, 2020

View reviewed changes

Address today's comments from @alice.

9122e6f

dbaron merged commit e398a21 into w3ctag:master Mar 3, 2020

dbaron added a commit that referenced this pull request Mar 4, 2020

Use a shorter id, followup to #155.

f905b41

dbaron added a commit that referenced this pull request Mar 4, 2020

Use a better id (again), followup to #155.

467ed06

Add sections on the Web being safe to browse, trusted user interface, and asking users for consent. #155

Add sections on the Web being safe to browse, trusted user interface, and asking users for consent. #155

Conversation

dbaron commented Feb 7, 2020

hober left a comment

Choose a reason for hiding this comment

alice left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hober left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dbaron commented Mar 3, 2020

alice left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment