- From: Jiri Danek <softwaredevjirka@gmail.com>
- Date: Fri, 26 Dec 2014 23:20:25 +0100
- 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>
- Message-ID: <CAMt6KBLCYMTf2DLfuQ5UKdv8NUdkSUOv308Y7H7FR2ZzZN4WHQ@mail.gmail.com>
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