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