On 10/8/2019 7:04 PM, Paul Walsh via dev-security-policy wrote:
Absent regulation, there's no "force". However, the formal adoption of
best practices, perhaps via an RFC, could help gradually to clean up the
namespace, and to install other good practices in place of the many bad
practices that currently are training users to do unsafe things.
On Oct 2, 2019, at 3:41 PM, Ronald Crane via dev-security-policy
On 10/2/2019 3:00 PM, Paul Walsh via dev-security-policy wrote:
On Oct 2, 2019, at 2:52 PM, Ronald Crane via dev-security-policy
Some other changes that might help reduce phishing are:
1. Site owners should avoid using multiple domains, because using them
habituates users to the idea that there are several valid domains for a given
entity. Once users have that idea, phishers are most of the way to success.
Some of the biggest names in, e.g., brokerage services are offenders on this
[PW] Companies like Google own so many domains and sub-domains that it’s
difficult to stay ahead of them. I think this is an unrealistic expectation. So
if other browser vendors have the same opinion, they should look inward.
It is not unrealistic to expect, e.g., Blahblah Investments, SIPC, to use only
"www.blahblahinvestments.com" for everything related to its retail investment
services. It *is* unreasonable to habituate users to bad practices.
[PW] I hear you Ronald. And I agree. My point was that it’s unrealistic for us
to expect this pattern of domain use to change. I can’t see how any stakeholder
can force or encourage organizations to use a single domain name or even a
small number of them for a given purpose. So there’s little point in directing
energy to something we can’t change.
2. Site owners should not use URL-shortening services, for the same reason as
[PW] ...We can try to encourage companies to stop using shortening
services, but we’re not likely to have much of an impact....
Still it's worth including in a best-practices document (RFC?).
People who don’t belong to a brand or organization will continue to
use shortening services too.
That's something, but it also continues to put the shortening service
inside the security perimeter of every legitimate site that uses it.
This is itself a Bad Thing that should be discouraged (and yes, here's
lookin' at every website that includes JS from ad brokers, which is very
nearly all of 'em). I understand why shortening services are useful for
tweets, but this modest convenience shouldn't come at the cost of the
entire web's security.
I have some ideas for shortening services. They can implement better trust.
Example: a URL that belongs to a site with website identity verified, could
look like https://verified.tinyurl.com/345kss or they could direct to a TinyURL
webpage where it informs the user of the verified destination.
3. Site owners should not use QR codes, since fake ones are perfect for
Same as above. You don’t need to mask URLs to have a successful phishing
No, you don't "need" to do it. It is, however, a very useful weapon in
[PW] I totally agree. I’d like to add, of the hundred million apps with a
WebView, many don’t display the URL at all. We also have Google’s AMP project
which does little to help. And then we also have social media cards and
previews where it’s possible to trick the system by displaying the og metadata
from the real website while linking to the malicious destination. Rabbit hole…
All this stuff should specifically be called out as bad practice in the RFC.
dev-security-policy mailing list