W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

From: Jiri Danek <softwaredevjirka@gmail.com>
Date: Fri, 26 Dec 2014 23:20:25 +0100
Message-ID: <CAMt6KBLCYMTf2DLfuQ5UKdv8NUdkSUOv308Y7H7FR2ZzZN4WHQ@mail.gmail.com>
Cc: mozilla-dev-security@lists.mozilla.org, "public-webappsec@w3.org" <public-webappsec@w3.org>, security-dev <security-dev@chromium.org>, blink-dev <blink-dev@chromium.org>
Have there been any suggestions what to do about <FORM>s sent over HTTP
that include <INPUT type="password">? For example marking the password
field itself as dubious/insecure? (I am absolutely not saying that is what
browsers should be doing, mind you)

On Wed, Dec 24, 2014 at 11:57 PM, 'Alex Russell' via blink-dev <
blink-dev@chromium.org> wrote:

> That change in attitudes and recommendations hasn't retroactively caused
> change in software is...well...the state of all human affairs.
>
> New APIs are absolutely being denied to HTTP content (see WebCrypro and
> Service Workers). The TAG will continue to recommend this. Stay tuned for
> the Finding.
>
> Regards
> On 24 Dec 2014 12:48, "Jeffrey Walton" <noloader@gmail.com> wrote:
>
>> On Wed, Dec 24, 2014 at 5:43 PM, Alex Russell <slightlyoff@google.com>
>> wrote:
>> > Which standards bodies are those? Cause the W3C TAG is recommending
>> > pervasive end-to-end transit encryption.
>>
>> W3C and IETF. They may be recommending it, but their deliverables are
>> failing to meet expectations.
>>
>> Jeff
>>
>> > On 18 Dec 2014 14:22, "Jeffrey Walton" <noloader@gmail.com> wrote:
>> >>
>> >> On Thu, Dec 18, 2014 at 5:10 PM, Daniel Kahn Gillmor
>> >> <dkg@fifthhorseman.net> wrote:
>> >> > ...
>> >> > Four proposed fine-tunings:
>> >> >
>> >> >  A) i don't think we should remove "This website does not supply
>> >> > identity information" -- but maybe replace it with "The identity of
>> this
>> >> > site is unconfirmed" or "The true identity of this site is unknown"
>> >> None of them are correct when an interception proxy is involved. All
>> >> of them lead to a false sense of security.
>> >>
>> >> Given the degree to which standard bodies accommodate (promote?)
>> >> interception, UA's should probably steer clear of making any
>> >> statements like that if accuracy is a goal.
>> >>
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> an
>> >> email to blink-dev+unsubscribe@chromium.org.
>>
>
Received on Saturday, 27 December 2014 22:20:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC