First reason is to defeat Verizon's "UIDH" online tracking header https://www.verizonwireless.com/support/unique-identifier-header-faqs/ and no doubt to defeat similar tracking that other ISPs will roll out. They are used as unblockable trackers for ad serving partners but do not work with https because they require modification of content. I would not visit any non-https website over Verizon mobile due to that header, and also would not buy Internet service from Verizon mobile.
The UIDH header, unlike cookies, supercookies, and machine fingerprinting cannot be blocked at the browser level The only defense is https, and if enough of the net moves to https the incentive for other telecoms to develop similar tracking schemes is ended. In the same way, https prevents an attacker from modifying a downloaded file in transit without replacing the certificate to decrypt the content and then re-encrypt it, which requires the replacement certificate. That will trigger a warning in browser. A user who clicks through the warning will still get the botted file. An example of such a modified file could be a custom compiled binary claiming to be from almost any source that adds a keylogger binary and a systemd unit to start it up on every reboot. Some years ago a Russian malicious Tor exit node was caught patching binary files that moved through it other than via https, and Trobrowser now includes the https everywhere extension due among other things to this form of attack. Many feel that all of the Internet should move to https simply to remove the usefulness of governmental bulk surveillance tools, many of which cannot handle https for "off the wire" surveillance. Thus the existance of things like the "https everywhere" extension for Firefox. On 5/30/2017 at 3:12 PM, "Len Ovens" <l...@ovenwerks.net> wrote: > >I had this conversation on IRC. Anyone know if this is a problem? >My web >understanding is old. > >------------------------------------------------------------------- >-- >06:11 < mchelen> any reason why ubuntustudio.org doesn't default >to HTTPS? >07:56 < OvenWerks> mchelen: no idea. >09:15 < mchelen> OvenWerks: it's not great security practice, >given that >there are links to .iso downloads (which are also HTTP) >09:50 < OvenWerks> mchelen: that may be true, however, web page >setup is >not my thing. I am not sure who is doing web stuff right now. >09:59 < mchelen> OvenWerks: ok, yeah I wasn't sure where to create >an >issue or anything >09:59 < OvenWerks> mchelen: do you know if xubuntu's site is any >different? I think the same person worked on both >10:01 < mchelen> OvenWerks: visiting http://xubuntu.org correctly >redirects to https >10:04 < OvenWerks> mchelen: I will drop this coversation on the >dev >mailing list and see what comes from it. >10:36 < mchelen> OvenWerks: ok thanks! hopefully its just a matter >of >creating a redirect >------------------------------------------------------------------- >--- >My understanding, is that https is useful when personal info is >shared >over the net. ubuntustudio.org is, so far as I can tell, one way. >That is, >we provide info/files and the user DL them, they do not sign in or >give >comments or anything. Am I missing something? > > > >-- >Len Ovens >www.ovenwerks.net > > >-- >ubuntu-studio-devel mailing list >ubuntu-studio-devel@lists.ubuntu.com >Modify settings or unsubscribe at: >https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel -- ubuntu-studio-devel mailing list ubuntu-studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
