> On Oct 9, 2019, at 12:39 PM, Ronald Crane via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > 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?).
[PW] Possibly. It’s not something I’d personally participate in as I think there are other areas where I can add more value. I know you weren’t asking if I’d do something :) > >> 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. [PW] I hear you. And I agree. Sometimes encouraging best practices is more successful than banning something. I mean, look at Google’s AMP project - that’s the opposite - it turns perfectly formed, beautiful, logical URLs into a string of nonsense. I digress. >>>>> 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. [PW] Indeed. Let’s go back to discussing better and UI and UX for website identity inside Firefox. And then separately we can talk about how companies that provide identity verification services and tighten their belts. - Paul > > -R > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
