On 10/8/2019 7:04 PM, Paul Walsh via dev-security-policy wrote:
On Oct 2, 2019, at 3:41 PM, Ronald Crane via dev-security-policy 
<dev-security-policy@lists.mozilla.org> wrote:

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 
<dev-security-policy@lists.mozilla.org> wrote:
[snip]
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 
front.
[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.
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.
2. Site owners should not use URL-shortening services, for the same reason as 
(1).
[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.
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.
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.
3. Site owners should not use QR codes, since fake ones are perfect for 
phishing.
Same as above. You don’t need to mask URLs to have a successful phishing 
campaign.
No, you don't "need" to do it. It is, however, a very useful weapon in 
phishers' quivers.
[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.

-R


_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to