Addons-server: Use https, not http, when automatically inferring a link from within the summary or description (About this extension)

[grahamperrin]

From https://github.com/michiel-roos/xposer-issues/issues/2#issuecomment-562926580:

… just had 'xposer.io' The http:// was added by AMO. …

A shot from before the developer worked around the issue:

[willdurand]

I have the feeling that this is a server issue but we cannot reproduce with the add-on mentioned above..

[grahamperrin]

Thanks,

cannot reproduce with the add-on mentioned above

The developer worked around the issue in the …/addon/xposer/ case; please see https://github.com/michiel-roos/xposer-issues/issues/2#issuecomment-562926580

I'll seek an alternative example.

[willdurand]

I was able to reproduce in -dev: https://addons-dev.allizom.org/api/v4/addons/addon/some-addon/, I confirm that's a server issue. There might be an existing issue about that.

[grahamperrin]

https://addons.mozilla.org/en-GB/firefox/addon/download-github-directory/ there's a description that includes a ⋯.io URL without a visible prefix, but the linked URL does use HTTPS so this is not a suitable example.

---

Comments crossed paths. I'll hide this.

[diox]

It's probably done by bleach's linkify feature somewhere in the translations app.

[eviljeff]

note, if we change this it will break a certain number of links to websites that do not support https. I'd lean towards wontfix because servers _should_ (imo) be setup to redirect to https from http if they support https.

[wagnerand]

I agree with @eviljeff.

[diox]

Yeah, as long as the developer is able to change it to https themselves, defaulting to http is probably fine.

[willdurand]

note, if we change this it will break a certain number of links to websites that do not support https. I'd lean towards wontfix because servers _should_ (imo) be setup to redirect to https from http if they support https.

On the other hand, making http the default is unsafe for users and we should lean towards promoting https everywhere :)

[grahamperrin]

Thank you all, to be clear: are these uses of HTTP occurring only where neither HTTP nor HTTPS is specified? (inference)

… we should lean towards promoting https everywhere :)

+1

https://groups.google.com/d/msg/mozilla.dev.platform/8EFRYDR3N1c/njX0E7jhBAAJ last week from Michael Thomson, in particular:

… The intent is to have that dialog to disappear some time after March next
year or for the exceptions to be more narrowly targeted. Re-enabling TLS
1.0 will still be possible via about:config for some time after that, so
people with a real need can always turn it back on if they need to
(including through enterprise policy if corporate services are stuck).
That's still inadvisable; ultimately, we'd like to ensure that TLS 1.2 or
higher is always used.

[diox]

Thank you all, to be clear: are these uses of HTTP occurring only where neither HTTP nor HTTPS is specified? (inference)

Yes. We're not transforming https links into http...

[grahamperrin]

Sure, thanks, I didn't imagine that, I just wanted to check that these HTTP cases are by inference (where a developer has not explicitly given a prefix).

… if we change this it will break a certain number of links to websites that do not support https. I'd lean towards wontfix …

Yeah, I agree, in retrospect I should have given more thought before raising this issue. wontfix at this time

---

The underlying thought, from the outset, was the importance of promoting use of HTTPS. Given Mozilla's stance on security, it'll be smart for AMO content to offer as few links as possible to HTTP content.

Way off-topic now, maybe developers can be automatically alerted (via e-mail? if in their profile) wherever there's an explicit or implicit/inferred link to HTTP. Sooner rather than later then eventually, if any web link in the More information panel uses HTTP, have a yellow alert re: the insecurity. Yeah, potentially cluttered however …

… step way back and imagine initial discovery of AMO, perceive it as Mozilla's Official Store for extensions, with payment required for some of the store's items. I'd expect any reputable store to not feature (in a standard panel) links that are insecure. That's _not_ to imply that AMO is disreputable :-) just food for thought, hopefully you get the idea. Apologies for rambling! I'll stop there.