Subject: Re: 2 questions

From: Benjamin Carlyle <[email-masked]>
Date: Fri, 10 Apr 2015 00:25:04 +1000

On 29 March 2015 at 00:43, Glen <[email-masked]> wrote:
> 1. What were the reasons for HTTP/2 not requiring TLS?

I know this issue has been canvassed many times on the list, but I
thought since I am writing emails tonight I would share a perspective
that I think is novel on this list. To restate from my last email, I
mostly use HTTP/1.1, SPDY, and soon will h2 in the context of highly
available safety-related (not safety-critical) SCADA systems.

Firstly, I mostly like the use of TLS on the web. I think it is well
warranted. However in my environments I'm typically dealing with
"secure" networks where other protections exist at the IP layer or
below that ensure many of the properties that TLS provides. These
generally are isolated networks with air gaps to the Internet or at
least some multiple layers of networks and restrictive firewalls
before the Internet can be reached. Changes to these networks go
through processes to ensure isolation is maintained to the desired
degree, and privacy is not a concern. Rather, if there is a concern it
is potential attacks on the system and related infrastructure. In fact
eliminating privacy and having every action be fully accountable is a
requirement.

My primary concerns in this environment are about high availability,
maintainability, and durability of the system. In my line of work I
often come across systems that have been in place for twenty years,
some still with serial communications, some devices still on the
network but if they failed would require some digging through
paperwork to even find their physical location. Some using network
technologies that are obsolete and are still running only due to
careful spares management. Replacing these systems is expensive and
the accountants like to amortise the expense over a long period of
time.

Traditionally HTTP has been a good next protocol to replace some of
the older system protocols. It is generally possible to connect quite
old and quite new HTTP implementations together and have them
interoperate, and the focus on text-based communications has meant
that reverse-engineering is likely possible when an incompatibility
does come up and some form of information plumbing is possible to join
both ends together.

h2 has largely maintained these properties albeit with a compatibility
break from HTTP/1.1 and with somewhat reduced debuggability /
increased plumbing complexity due to header compression and the like.
TLS brings roughly the same hazards for both HTTP/1.1 and h2, such as:
- opaque data streams that are difficult to put a logic probe
(wireshark) into for reverse engineering purposes
- certificates that need to be acquired, or self-signed certificates
that need to be distributed. This can mean that certificate trust
needs to be installed on a replacement unit before it is sent out into
the field in case of a hardware failure
- the possibility that a certificate will unexpectedly expire. If you
have hundreds of devices around a network in awkward places across a
metropolitan-sized system then the tracking of regular maintenance
activities such as these can be non-trivial
- The cipher suites eventually become outdated, and you can end up
with a patchwork of equipment of various ages that have
old-to-the-point-of-useless encryption that newer devices won't want
to talk to, and potentially a bunch of equipment in between these
extremes. More to track, more to get right. More difficulty supporting
old equipment.
- TLS tends to couple the software implementation to end device. In
this business you tend not to want to update a device, but instead to
offload things that need regular maintenance onto a separate component
that you can physically replace. For example you might have a handful
of field units at a given location connected to an industrial router.
It is the router we would want to be taking on the encryption function
rather than the individual devices because touching one of the devices
requires much more expensive installation and revalidation work.

None of the problems are insurmountable and maybe just making sure
that TLS offload for h2 is well supported and well understood will be
enough to resolve them. But basically as it is the positives of TLS
seem generally more like net negatives in this environment. These may
also be somewhat temporary objections. The systems are always moving
closer to being core business systems rather than solely control
systems so both customer and suppliers are moving closer to
conventional IT practices. It may be that in another twenty years the
systems and practices I'm seeing will all be gone, but given the
distributed nature of the systems I think there will always be some
differences to the Web.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Apr 2015 09:56:18 -0700

You might find that durability is improved by using TLS.  As long as
the other considerations aren't more significant, TLS is far more
resilient to bit-level errors.  TCP, on the other hand, has a
non-negligible rate of undetected errors if the underlying medium
isn't properly robust.

Incidentally, you might be interested in reading the recent traffic on
the TLS working group list, there's some discussion of similar sorts
of environments to what you describe.

I will also note that if you have a high level of control, the primary
value in using standard protocols is in the existence of robust
implementations.  If certificates don't work for you, try PSK; if you
don't like the cipher suite flexibility, pick one that fits and stick
with it.  Obviously, every variation increases the work and risk, but
that's engineering.

Consider yourself privileged.  The rest of us have to deal with the
swamp that is the Internet.

---

From: OSCAR GONZALEZ DE DIOS <[email-masked]>
Date: Thu, 9 Apr 2015 22:52:09 +0000

Hi Glen, all

>Hi,
>
>I have 2 questions, if I may.
>
>Is there a significant performance consideration, is it related to the
>cost of certificates (which is now fairly low or even free), or are there
>other technical reasons?
>
>It would be nice if the web was just "secure by default", and I would
>have thought that now would be the right time to move in that direction.
>
>Also, at least 2 of the major browser vendors have said that they won't
>be supporting HTTP/2 without TLS, so surely no one is going to want to
>run their website without it?

There is a very interesting use case where TLS is an overhead related to
video streaming over HTTP/2. MPEG DASH provides DRM encryption for video
content. If you transfer DRM encrypted MPEG-DASH video over HTTP/2, you
will have double encryption, which is clearly an overkill. Generalizing,
when you need to use Digital Rights Management, there are no additional
benefits by encrypting again with TLS.

Best Regards,

        Oscar

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Apr 2015 16:24:40 -0700

On 9 April 2015 at 15:52, OSCAR GONZALEZ DE DIOS
<[email-masked]> wrote:
> Generalizing,

Only if you don't consider the meta-information to be valuable.  Using
DRM won't prevent someone from learning what you are watching.

---

From: Roland Zink <[email-masked]>
Date: Fri, 10 Apr 2015 10:37:56 +0200

TLS is of limited use for the meta-information when the browser 
multicasts the URL in the Referer header to 10 or more 
analytic/ad/library sites. Also you not necessarily learn what is played 
from the meta-information.

---

From: Glen <[email-masked]>
Date: Fri, 10 Apr 2015 11:53:32 +0200

(sending again as a subscriber, as I think this message went unnoticed)

Thanks for the replies.

1. As far as I understand it (which is not very far), opportunistic 
encryption is neither "by default" (since it requires extra server-side 
configuration) nor secure (no MITM protection, etc.)

I'm okay with HTTP/2 without TLS, however (my opinion):

a) User agents MUST show a security warning before you submit data over 
HTTP (you could have a "remember this choice" option per-user and 
per-domain). As far as I know, this is not currently implemented in any 
browsers (I think if you submit to an HTTP domain from an HTTPS one, you 
may receive a warning). The main point is, it's more important that 
users know that they're on an INSECURE domain, than it is that they are 
on a SECURE one (by then it's too late).

b) All vendors should support it. If I decide that my site does not 
require encryption (f.e. it's a read-only website or a website that runs 
within a LAN [like a router page]), then I should not be forced to use 
it in order to run over HTTP/2. I think that Mozilla and Google probably 
have good intentions, but I don't think that they have made the right 
decision at all. We don't want to go back to the stage where every 
browser was doing its own thing, and causing massive headaches for 
developers and even end-users. There are ways (see above) to make the 
web more secure (by default) without forcing anything on anyone. It's 
kind of like smoking – it's bad for you, and we should warn against it, 
but at the end of the day every person reserves the right to do as they 
please (screw up their lungs, or submit their (possibly) private 
information over an insecure connection.

2. Not being able to safely compress content seems like a big problem. 
Are there any (content) compression algorithms that are not susceptible 
to these vulnerabilities, or has there been any discussion regarding the 
development of a new algorithm to combat these issues? From what I know, 
compressing content can have a significant (positive) effect on 
performance, so it would be really unfortunate if this was no longer 
possible without exposing your website to various security exploits.

Glen.

On 2015/03/28 16:43, Glen wrote:
> cost of certificates (which is now fairly low or even free), or are
> there other technical reasons?
>
> Also, at least 2 of the major browser vendors have said that they
> won't be supporting HTTP/2 without TLS, so surely no one is going to
> want to run their website without it?
>
> 2. Are the BREACH and CRIME exploits still applicable, especially with
> regard to content (body) compression? If so, does that mean that it's
> not possible to compress content (with gzip, for example) and still
> maintain security?
>
> Please respond as if I were a layman, as my knowledge on these
> subjects is somewhat limited.
>
> Thanks.

---

From: ChanMaxthon <[email-masked]>
Date: Fri, 10 Apr 2015 18:20:24 +0800

Just throwing it out here, since DRM over TLS is pointless, why not just fold DRM schemes into TLS using the existing client certificate authentication mechanism or the like?

By standardizing DRM in TLS we also kill a lot of interoperability issues (e.g. proprietary DRM plugins that is only compatible with one browser but not another) and privacy issues (e.g. spyware in DRM plugin) and all that is needed to make DRM work is the content provider issuing and authenticating client certificates.

The same DRM in TLS mechanism can also be extended to protocols like RTP and DLNA for streaming live content. 

Sent from my iPhone

> On Apr 10, 2015, at 16:37, Roland Zink <[email-masked]> wrote:
> 
> TLS is of limited use for the meta-information when the browser multicasts the URL in the Referer header to 10 or more analytic/ad/library sites. Also you not necessarily learn what is played from the meta-information.
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Apr 2015 16:58:57 +0300

> configuration) nor secure (no MITM protection, etc.)

Well, security is relative.
 
> a) User agents MUST show a security warning before you submit data over HTTP
> (you could have a "remember this choice" option per-user and per-domain). As
> far as I know, this is not currently implemented in any browsers (I think if
> you submit to an HTTP domain from an HTTPS one, you may receive a warning).
> The main point is, it's more important that users know that they're on an
> INSECURE domain, than it is that they are on a SECURE one (by then it's too
> late).

In the distant past, web browsers did have submit over HTTP warnings. Those
were pretty universally turned off.

However, AFAIK browsers have not and are not showing HTTP connections as
actually insecure (there are plans to do so for Chrome). That is significant
due to it being much easier to notice signal than absence of it[1].

EV has positive security indications, but it is of limited value because
EV is not treated specially except for display purposes (e.g. there is no
HSTS RequireEV directive).

> b) All vendors should support it. If I decide that my site does not require
> encryption (f.e. it's a read-only website or a website that runs within a
> LAN [like a router page]), then I should not be forced to use it in order to
> run over HTTP/2. I think that Mozilla and Google probably have good
> intentions, but I don't think that they have made the right decision at all.
> We don't want to go back to the stage where every browser was doing its own
> thing, and causing massive headaches for developers and even end-users.
> There are ways (see above) to make the web more secure (by default) without
> forcing anything on anyone. It's kind of like smoking – it's bad for you,
> and we should warn against it, but at the end of the day every person
> reserves the right to do as they please (screw up their lungs, or submit
> their (possibly) private information over an insecure connection.

"Read-only website" may very well require encryption.
- Access to public data may not itself be public.
- Public data may need to be origin-authenticated.

LAN is its own can of worms. The devices are often totally unmanaged (even
if having CPU power to run TLS fully[2]), which causes lots of challenges.

[Fortunately, these devices tend to reside in IP ranges distinct from
anything else, like site locals, link locals and ULAs].

> 2. Not being able to safely compress content seems like a big problem. Are
> there any (content) compression algorithms that are not susceptible to these
> vulnerabilities, or has there been any discussion regarding the development
> of a new algorithm to combat these issues? From what I know, compressing
> content can have a significant (positive) effect on performance, so it would
> be really unfortunate if this was no longer possible without exposing your
> website to various security exploits.

HTTP content compression works in HTTP/2. And HTTP/2 does its own header
compression.

Of course, if you have things like anti-CSRF tokens in the payload, those
can't be safely compressed. In theory, it is possible to switch between
compressed and uncompressed in the fly. In practice, the OOB signaling
(between app and whatever compresses the data) required is unworkable.

[1] That's the basis of game named "Simon says".

[2] Meaning can do TLS without PSK or creative hacks.

-Ilari

---

From: Glen <[email-masked]>
Date: Sat, 11 Apr 2015 19:08:46 +0200

> due to it being much easier to notice signal than absence of it[1].

I assume that you're referring to this 
(https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure). 
I think that Firefox is considering the same thing 
(https://people.mozilla.org/~fqueze2/slides/fosdem2015/#28.0).

In my opinion though, this alone (and at this time) is not a good idea. 
Firstly, many users won't even notice it – I'm pretty sure that many 
(less technical) users are more focused on the content area of a page 
than the address bar. Secondly, for those that *do* notice it, it may be 
confusing, as it would be displayed on the vast majority of websites (at 
least in the short to medium term), which makes it seem like there's 
something wrong with their system, as the sites that they usually visit 
are marked as insecure.

The better option, IMHO, would be to alert the user "in their face" 
(modal window) only when attempting to *submit data* over HTTP. 
Explaining that the data that they are about to submit may be viewed or 
intercepted by a third party is far more explicit, and forces them to 
make a more informed decision.

> anything else, like site locals, link locals and ULAs].

Yes, but if the content is unimportant/not likely to be targeted 
("programming tutorials") or has little traffic ("my personal 
CV/résumé"), then using TLS should be the *developer's* choice, and 
browsing the ("insecure") site should be the *user's* choice.

> (between app and whatever compresses the data) required is unworkable.

 From what I understand, this would only give an attacker the ability to 
guess something within the page. For example, if you display the user's 
username on the page, they could guess that, but something like a 
session ID would be transmitted in a Cookie header, which would not be 
compressed, therefore it could not be guessed. Is that correct? If so, 
then it's not as big of an issue as I initially thought (unless I'm 
forgetting something obvious).

What about designing a compression algorithm that allows you to specify 
a set of substrings that should not be compressed? For example, all user 
input (query string, POST data, etc.) found in the response should 
remain uncompressed. That way, you could compress the majority of the 
page without the potential information disclosure. The same could be 
used for HPACK, perhaps on a per-header basis (don't ever compress the 
Cookie header, for example).

I don't know a lot about these things, so don't laugh if this is a 
really stupid idea! :-P

---

From: Jim Manico <[email-masked]>
Date: Sat, 11 Apr 2015 13:45:14 -0700

Whoa. 

Lack of well configured HTTPS is way more than just a breach of confidentiality. Integrity and Authenticity risks are at play here as well.

Not only will I see your data over HTTP, but I can easily modify your content, inject JS and now I have a new attack vector beyond just looking at your data.

But Glen, your idea is still awesome. I think any form post over HTTP should provide the user with a pretty dramatic warning to not hit submit or at lest explain the risk similar to Chromes current pinning warning.

Cheers,
--
Jim Manico
@Manicode
(808) 652-3805

> On Apr 11, 2015, at 10:08 AM, Glen <[email-masked]> wrote:
> 
> --
> Jim Manico
> @Manicode
> (808) 652-3805
> 
> 
> I assume that you're referring to this (https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure). I think that Firefox is considering the same thing (https://people.mozilla.org/~fqueze2/slides/fosdem2015/#28.0).
> 
> In my opinion though, this alone (and at this time) is not a good idea. Firstly, many users won't even notice it – I'm pretty sure that many (less technical) users are more focused on the content area of a page than the address bar. Secondly, for those that *do* notice it, it may be confusing, as it would be displayed on the vast majority of websites (at least in the short to medium term), which makes it seem like there's something wrong with their system, as the sites that they usually visit are marked as insecure.
> 
> The better option, IMHO, would be to alert the user "in their face" (modal window) only when attempting to *submit data* over HTTP. Explaining that the data that they are about to submit may be viewed or intercepted by a third party is far more explicit, and forces them to make a more informed decision.
> 
> Yes, but if the content is unimportant/not likely to be targeted ("programming tutorials") or has little traffic ("my personal CV/résumé"), then using TLS should be the *developer's* choice, and browsing the ("insecure") site should be the *user's* choice.
> 
> From what I understand, this would only give an attacker the ability to guess something within the page. For example, if you display the user's username on the page, they could guess that, but something like a session ID would be transmitted in a Cookie header, which would not be compressed, therefore it could not be guessed. Is that correct? If so, then it's not as big of an issue as I initially thought (unless I'm forgetting something obvious).
> 
> What about designing a compression algorithm that allows you to specify a set of substrings that should not be compressed? For example, all user input (query string, POST data, etc.) found in the response should remain uncompressed. That way, you could compress the majority of the page without the potential information disclosure. The same could be used for HPACK, perhaps on a per-header basis (don't ever compress the Cookie header, for example).
> 
> I don't know a lot about these things, so don't laugh if this is a really stupid idea! :-P
> 
>> 
>>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 Apr 2015 01:20:41 +0300

> On Apr 11, 2015, at 11:45 PM, Jim Manico <[email-masked]> wrote:
> 
> 

As others have said, browsers did try that. It certainly makes sense to warn if I’m about to submit my credit card number, social security (or equivalent), and other personal information. 

But any text box is a form. You can’t search Wikipedia without submitting a form. Doing what Glen suggests means that Wikipedia has to go to HTTPS or else have the users receive a warning when they search. So you’d have to have some “don’t bother me again” checkbox on the warning dialog, and that trains users to click this all the time, because you see that dialog box pretty much on any HTTP site. This is a common issue with every kind of UI warning that is most of the time a false positive.

Ultimately, unless it’s secret (like a password or a CC number), I don’t think what you send is any more or less sensitive that what you receive.

Yoav

---

From: Glen <[email-masked]>
Date: Sun, 12 Apr 2015 11:00:21 +0200

Yes, that's why I said "this alone", i.e. this could be in addition to 
the proposed changes to the address bar.

Regarding the Firefox mockup, if unidentified means that you could be 
sending data to a server that is not owned by Gmail/Google, then I think 
that "Secure connection" is misleading. I think that it should show 
something like:

Encrypted connection        YES (in green)
Identified/authenticated     NO (in red)

Glen.

---

From: Glen <[email-masked]>
Date: Sun, 12 Apr 2015 11:23:35 +0200

That's a good point. However, at the end of the day, what one person 
thinks is confidential may not be the same to somebody else.

Silly examples:

- I'm searching about some embarrassing illness, and I don't realize 
that someone may be tracking this information.
- I'm submitting my CV from my current work place, who monitor traffic, 
and I don't want them to find out.

Without a warning you may not think about this.

Yes, passwords, CC numbers, ID numbers, etc. are more private, but where 
do you draw the line? What about my physical address?

At a *minimum*, this type of warning should be displayed when submitting 
a form that contains a password field. Unfortunately, there are no 
built-in input fields for other types of private data, and checking for 
common labels might not be that easy or effective.

Yes, many people will hit "ignore" without even reading the prompt, but 
you can never control that, and if their information is compromised, 
it's their fault entirely.

They could ignore future warnings for a particular form (based on the 
form action), the entire domain, or everywhere.

Glen.

---

From: Jim Manico <[email-masked]>
Date: Sun, 12 Apr 2015 09:18:13 -0700

> - I'm submitting my CV from my current work place, who monitor traffic, and I don't want them to find out.

Well even over HTTPS your big-company-employer owns you. They likely assigned you a laptop, they likely have a local CA whose public cert is installed in your browser as a local authority and now they can MITM all of your HTTPS traffic - even through HPKP - even gmail with Googles pinning in place in Chrome is plaintext to your employer. That's just the way of the world, right?

But I still like this idea Glen, I'm just critiquing that one example.

--
Jim Manico
@Manicode
(808) 652-3805

> On Apr 12, 2015, at 2:23 AM, Glen <[email-masked]> wrote:
> 
> That's a good point. However, at the end of the day, what one person thinks is confidential may not be the same to somebody else.
> 
> Silly examples:
> 
> - I'm searching about some embarrassing illness, and I don't realize that someone may be tracking this information.
> - I'm submitting my CV from my current work place, who monitor traffic, and I don't want them to find out.
> 
> Yes, passwords, CC numbers, ID numbers, etc. are more private, but where do you draw the line? What about my physical address?
> 
> At a *minimum*, this type of warning should be displayed when submitting a form that contains a password field. Unfortunately, there are no built-in input fields for other types of private data, and checking for common labels might not be that easy or effective.
> 
> Yes, many people will hit "ignore" without even reading the prompt, but you can never control that, and if their information is compromised, it's their fault entirely.
> 
> They could ignore future warnings for a particular form (based on the form action), the entire domain, or everywhere.
> 
> Glen.
>

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 13 Apr 2015 13:34:32 +1200

> it's their fault entirely.

Yes you/we can control that. Easily understood message(s) occuring
rarely get read and decided on. Frequently occuring obscure message gets
a rote-learned "go away" response.

There are now 2 generations of users out there with decades of training
to click-away the TLS warning messages (and any other message that looks
similar) and malware authors are already taking advantage of that on a
large scale.

Amos

---

From: Maxthon Chan <[email-masked]>
Date: Mon, 13 Apr 2015 15:51:08 +0800

Even with a company-assigned laptop it probably won’t raise much flags if a tech-savvy employee installed some virtual machine software on it and just say I have Ubuntu on VirtualBox on my machine and what would happen if the Ubuntu installation detected the MITM?

> On Apr 13, 2015, at 00:18, Jim Manico <[email-masked]> wrote:
>

---

From: Glen <[email-masked]>
Date: Mon, 13 Apr 2015 10:52:33 +0200

Guys, emphasis on "Silly" examples. My point was that it is good to be 
reminded when submitting data over HTTP, and things that may seem public 
to you are private to others.

Glen.

---

From: Glen <[email-masked]>
Date: Mon, 13 Apr 2015 11:10:06 +0200

Well protecting some is better than protecting none at all.

[silly example] If you keep getting prompted to scan for viruses and you 
keep dismissing it (and/or not reading the message), and you have a 
virus, whose fault is that?

Also:

- I don't believe that it will be that frequent. A lot of the larger 
sites are already on HTTPS (Google, Facebook, Twitter, etc.), and many 
more will follow, especially if Firefox/Chrome refuse to support HTTP/2 
without TLS.
- The message does not have to be "obscure", it could be written in 
layman's terms, with links to additional information.

Do you honestly believe that letting users unknowingly submit private 
data (including passwords) over HTTP is the better option?

Glen.

On 2015/04/13 03:34, Amos Jeffries wrote:
> .

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 13 Apr 2015 12:32:40 +0300

> Well protecting some is better than protecting none at all.

Some things are just worse than useless.

> Also:
> 
> - I don't believe that it will be that frequent. A lot of the larger sites
> are already on HTTPS (Google, Facebook, Twitter, etc.), and many more will
> follow, especially if Firefox/Chrome refuse to support HTTP/2 without TLS.
> - The message does not have to be "obscure", it could be written in layman's
> terms, with links to additional information.
> 
> Do you honestly believe that letting users unknowingly submit private data
> (including passwords) over HTTP is the better option?

This has been tried. It did not work.

- If dialog has "don't show this again" option, it will be checked.
- If not, the dialog will be dismissed unread (the user never even recognizing
  that the warning existed) after the first few times.

-Ilari

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 14 Apr 2015 02:57:35 +1200

> virus, whose fault is that?

"
Application Status 0x008465F3 indicates you are in danger of event
notification EA0065-98-3fb459 03/02/2015.

 Yes / No
"

[Oh how I *wish* this were a silly example].

50% success rate on click-through on that one, so it shirely must be a
good thing to be doing.

Who would have thought theres a better way:
"
You have not run anti-virus scan in 4 weeks. Your computer may be in
danger from malware.

 Run One Now / Remind Me Tomorrow
"

Blame the users only when the message is clear enough to understand by
someone outside the development team who wrote it.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Apr 2015 09:24:07 -0700

>   that the warning existed) after the first few times.

This could change soon.  Browser vendors are discussing options that
disable insecure form submission.  That is, at least when the password
input element present.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Apr 2015 18:29:30 +0300

> On Apr 13, 2015, at 7:24 PM, Martin Thomson <[email-masked]> wrote:
> 

How many people will notice that the field with the label “Password:” is just a plain old text field?

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Apr 2015 09:08:46 -0700

> How many people will notice that the field with the label “Password:” is just a plain old text field?

Oh, don't get me wrong, this is trivial to work around.  But (at least
the theory runs) that adding HTTPS submission is easier than working
out how to implement password input using regular textboxes (or
canvas).