Re: The purpose of Note use-cases

I did not point out that an existing use case violates any principle. I
pointed out the fact that we had an existing use case that dealt with
browsers being aware of reputation services. I want to make that distinction
very clear. I think it's fine for us to acknowledge the fact that services
and methods exist to say "a site is bad" either for reasons of phishing,
malware, or otherwise. I don't think we should delete any use cases, nor do
I think there is duplication.

As I stated earlier, I think the use case I proposed is different, and
here's why.

Malware is something of a special case. Sites distributing malware are often
sites that are trusted, known, and high-traffic, which have been compromised
and are now spreading crud to users. This is often difficult for a user to
understand, because a user might think "I trust example.com, I go there
every day. Now I'm being told that this is a bad site." This is very
different from "I'm being told example.com is bad and I've never been there
before and I know nothing about it." That's what differentiates my use case
from the use case I referred to in today's meeting, and why I think it
should be added.

Also, I don't want to get into the whole issue of processes and rec
proposals etc, nor do I want to get into methodology of how a user agent
finds a site to be bad. I just want to acknowledge the fact that many user
agents do this already, and see if we can't make some recommendations on how
to present such information to users in a meaningful fashion. I am not
trying to advocate anything in particular - either methods for finding
malware, warnings to present, anything - all I'm trying to say is that I
think this is an important issue that I think we should discuss.

Also, I wasn't going to bring this up, but this was sent out a long time
ago, there was email discussion about it, and consensus was declared (
http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0149.html) and so
I do find it a bit disconcerting that I am just now hearing about these
objections. I'm happy to re-write the use case to address your issue of not
proposing any particular methods (blacklisting, etc) but I fail to see the
more fundamental problem that you seem to believe exists.

On 8/29/07, Close, Tyler J. <tyler.close@hp.com> wrote:
>
>
> This WG is chartered to "... to enable users to come to a better
> understanding of the context that they are operating in when making
> trust decisions on the Web". The way I see it, the Note use-cases should
> provide concrete scenarios documenting the different kinds of trust
> decisions users need to make when using the Web. When evaluating
> recommendation proposals, we should then see how they work in these
> scenarios, to judge whether or not the user is being helped.
>
> In my opinion, the Note use-cases do not list the techniques that are on
> our agenda to study as possible recommendations. Were that the case,
> there are several techniques that are not represented. I think there is
> a basic issue of fairness in ensuring that the use-cases only describe
> user decisions, and not tilt the playing field toward any particular
> recommendation proposal by presupposing the use of a particular
> mechanism.
>
> I think Ian correctly pointed out in today's telecon that one of the
> existing use-cases violates this principle. See:
>
> http://www.w3.org/2006/WSC/drafts/note/#any-iui-2
>
> In my opinion, this use case is also a duplicate of the user decision
> described in:
>
> http://www.w3.org/2006/WSC/drafts/note/#any-iui-1
>
> I propose that to resolve this issue, we delete the first use case
> listed above from the Note, and encourage Ian to submit a recommendation
> proposal that covers the techniques he thinks this WG should be
> investigating. I think this resolution clarifies the purpose of the
> use-cases, making the Note better, and gets Ian's topics onto the agenda
> of things being considered for our FPWD. These are the results that I
> think we all want.
>
> --Tyler
>
>

Received on Wednesday, 29 August 2007 19:50:52 UTC