W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2016

Re: Proposal: Marking HTTP As Non-Secure

From: Mark Watson <watsonm@netflix.com>
Date: Fri, 5 Feb 2016 08:50:42 -0800
Message-ID: <CAEnTvdC2ajH-wNyGSAjMyC4nc515dN8syGdSeJcefVAs4D=uJQ@mail.gmail.com>
To: Omar Herrera Reyna <0h3rr3r4@gmail.com>
Cc: Eitan Adler <lists@eitanadler.com>, Security-dev <security-dev@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, blink-dev@chromium.org, dev-security@lists.mozilla.org
On Fri, Feb 5, 2016 at 7:49 AM, Omar Herrera Reyna <0h3rr3r4@gmail.com>
wrote:

> Thank you for your comments and the suggested references Eitan.
>
> Sorry for touching on a topic that might have been heavily discussed in
> the past. I see your point now.
>
> Still, from the references I see that simple but persistent security cues
> are still noticed by users (security lock is noted by 2/3 of people), even
> if they ignore their interactive capabilities.
>
> Would a small set of simple and persistent security indicators have a
> different effect? The security lock signals a secure connection, but it
> does not certify the type of online transactions that user might do there
> with some degree of trust.
>
> Let me rephrase my proposal:
>
> 3 small and persistent icons and a text field:
> 1) A lock (just like we have now)
> 2) A credit card - to indicate that this site is in a certified white list
> to do online shopping
> 3) A bag of coins with the dollar sign - to indicate that this site is in
> a certified list to do online banking transactions
>

> Locks turn green when they satisfy the corresponding security indicators,
> otherwise they remain red (or even red and crossed).
>
> The text field would contain a word with the certified brand name (for
> indicators 2 and 3). This might actually not be necessary, but I would
> still like to know what other things.
>

​I think that would be important: I'm not sure if the browsers want to get
into the business of making these kind of attestations about websites, but
I'll let them speak to that.

​As you imply, there
 are a variety of companies that *are* in that business - auditing
​websites and providing them with marks that are supposed to signal some
level of trustworthiness in some domain. Those businesses do their best to
develop their own brands and gain users trust. I assume they have a problem
with misuse of their marks and I could see a role for browsers there: if a
site is authenticated, the browser could reliably provide users with
third-party attestations about the site: "this site has XYZ e-commerce
certification", "this site has PQR malware-free status" etc. where is it
XYZ and PQR, and not the browser, who are clearly responsible for the
attestation.

>
> There we have a mix of both positive and negative indicators, that are
> simple, require no interaction from the user and are persistent.
>
> Regards,
>
> Omar
>
> On Thu, Feb 4, 2016 at 8:26 PM, Eitan Adler <lists@eitanadler.com> wrote:
>
>> On 4 February 2016 at 15:28,  <0h3rr3r4@gmail.com> wrote:
>> > I've followed most of this discussion with great interest. It is a good
>> initiative, but have other alternatives been explored?
>> >
>> > For instance, why a blacklist approach instead of a whitelist?
>> >
>> > Why not a signal that certifies the name and activity of the company
>> being reached? For example: [XXX Company | Bank]  or [YYY Corp. | online
>> retailer]
>> >
>> > Simple signs are  easy to understand by users, that is what I like of
>> this initiative. However, you still need to enforce the message.
>>
>> This is demonstrability unhelpful.  UI/UX research has shown
>> consistently that people do not notice the absence of positive
>> indicators.
>>
>> Some things to read:
>> - Trust Me: Design Patterns for Constructing Trustworthy Trust Indicators
>> - The emperor’s new security indicators in Proceedings of the 2007
>> IEEE Symposium on Security and Privacy,.
>> - Use of Visual Security Cues in Web Browsers in Proceedings of the
>> 2005 Conference on Graphics Interface
>>
>> --
>> Eitan Adler
>>
>
>
Received on Friday, 5 February 2016 16:51:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:54 UTC