Re: [Repo-criteria-discuss] HSTS screw?

[Hanno Böck]

On Tue, 11 Oct 2016 18:29:56 -0400
Richard Stallman <address@hidden> wrote:

>   > You have to access a page that is HTTP and will likely not go
>   > HSTS any time soon.  
> 
> That is not a solution.  That is the problem!

Well, I'd argue captive portals are the problem, but probably we won't
get rid of them any time soon, so we need workarounds if we want to
access the Internet through them.

> What I want -- and sooner or later I will arrange to get it -- is a
> browser that will use http when I tell it to.

You can certainly do that by either modifying your browser or using one
that doesn't support HSTS.

But I think it doesn't achieve what you want. As far as I understand
your goal is to choose a site to connect to that many other people use
in order to avoid identification of you.

However if you access Wikipedia through HTTP while almost everyone else
uses HTTPS then this is a very identifying pattern.
Even worse: If you change any modern browser to allow accessing
wikipedia over HTTP then you may generate a request that is so unique
that it completely identifies you (by either the user agent or the set
of features that are announced in the HTTP request).

>   > Several people have suggested using example.com or example.org
>   > for  
> 
> Yes, that is an option.  But it is a much smaller set of people,
> which means it does more to identify me.

Well, ideally one would agree to one site that everyone uses, which
would reduce identifiability.
(Not sure, but maybe this might even be a project for the FSF. What I'd
like to see is something like: This domain will stay HTTP forever, will
deliver a specific pattern if you access a certain file on the domain
and will not log any user data beyond what's necessary to run the site.
Whoever operates it would also pledge that in case he decides to
discontinue the service he will try to transfer the domain to someone
else who runs it in a similar fashion.)

> Isn't this a screw for everyone that uses any portals?

For many people this is solved by their OS, see below.

>   > Browser and OS vendors sometimes have their own pages to detect
>   > captive portals.  
> 
> I don't follow.  What does "detect" mean here?

What modern Android phones (and I believe also several other OSes, but
I don't know which exactly) is this:
* After connecting to the wifi they try to access a predefined URL on a
  Google domain that's reachable over HTTP and check the content.
* If they receive the expected content they assume there is no captive
  portal. If instead they receive some redirect they assume it's a
  captive portal. A notification is shown to the user and if he taps on
  that he'll get forwarded to the portal.

This makes things more convenient for users, but one could have privacy
concerns about it. (That's why it may be a good idea to have some
service URL for these kinds of things that pledges to not collect user
data.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: address@hidden
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

pgpRSLZYc5tYf.pgp
Description: OpenPGP digital signature