Re: The ability to automatically upgrade a reference to HTTPS from HTTP

Marc,
I would this this is a question, if phrased well, for Information Security
Stack Exchange <http://security.stackexchange.com/>
(security.stackexchange.com/)
I agree there is an issue of why there is a move to https.
I assume that it is correct, there is such a trend.
But is that volume of traffic, distinct addresses, or both?
It only makes sense as a trend where there is data being exchanged that
needs to be protected.
If we are talking about the fact of viewing a particular web site, as
opposed to the facts of how the web site was viewed (activity on that
site), https won't help.

Off topic but of attendant interest:-

I did just have a casual conversation with someone from Samsung research
who, without implying anything about their own research or suggesting any
solutions, thought that
a. It is an issue that, even if the person as client cannot be identified
using https, the site being served and the location by building of the
client can be identified, by an interested third party.
b. It is not possible to re-engineer the web, for instance to use
WebID-TLS, as I suggested to him. Moreover, while information maybe owned
by an individual, there is no bar on that information being copied out of
the frame of the permissions the data owner would like to impose.

I'm not sure about this last point.
But I do think there is a broader point which is that the internet is, in
one of its primary uses, a communication medium between people and, as
such, people should have an alternative to broadcast mode.
How that is engineered it seems would be on a use case by use case basis.
As an obvious example, this list isn't 'broadcast' but neither are there
particular privacy arrangements.

Adam

Adam Saltiel


On Sunday, August 24, 2014, Marc Fawzi <marc.fawzi@gmail.com> wrote:

> Here is a question that may be a bit controversial:
>
> The government can force Certificate Authorities to secretly hand over
> their root certificates and the CAs can't do anything about it because of a
> secret gag order. I'm also aware that some companies plan to snoop on
> their employees' https traffic by becoming a certificate authority.
>
> Both of these (confirmed?) facts should raise an alarm about the false
> sense of security that HTTPS provides and it should open up the debate on
> whether or not the move to HTTPS is anything more than a knee jerk reaction
> that doesn't really address the problem.
>
> This is to say that this proposal (I believe unintentionally) tries to
> address the problem of how to make the move to https a smooth one while
> ignoring the fact that HTTPS is breaking down as corporate governors and
> national governments (and potentially criminal organizations unknown to us)
> are able to bypass it.
>
> What's up with that?!
>
>
>
>
> On Fri, Aug 22, 2014 at 10:00 AM, Tim Berners-Lee <timbl@w3.org
> <javascript:_e(%7B%7D,'cvml','timbl@w3.org');>> wrote:
>
>>
>> There is a massive and reasonable push to get everything from HTTP space
>> into HTTPS.
>> While this is laudable, the effect on the web as a hypertext system could
>> be
>> very severe, in that links into http: space will basically break all over
>> the place.
>> Basically every link in the HTTP web we are used to breaks.
>>
>> Here is a proposal, that we need this convention:
>>
>>          If two URIs differ only in the 's' of 'https:', then they may
>> never be used for different things.
>>
>> That's sounds like a double negative way of putting it, but avoids saying
>> things we don't want to mean.
>> I don't mean you must always serve up https or always serve up http.
>> Basically we are saying the 's' isn't a part of the identity of the
>> resource, it is just a tip.
>>
>> So if I have successfully retrieved https:x  (for some value of x) and I
>> have a link to http:x then I can satisfy following the link, by presenting
>> what I got from https:x.
>> I know that whatever I get if I do do the GET on the http:x, it can't be
>> different from what I have.
>>
>> The opposite however is NOT true, as a page which links to https:x
>> requires the transaction to be made securely.  Even if I have already
>> looked up http:x < i can't assume that I can use it for htts:x.  But for
>> reasons of security alone -- it would still be against the principle if the
>> server did deliberately serve something different.
>>
>> This means that if you have built two completely separate web sites in
>> HTTPS and HTTP space, and you may have used the same path (module the 's')
>> for different things, then you are in trouble. But who would do that?   I
>> assume the large search engines know who.
>>
>> I suppose an exception for human readable pages may be that the http:
>> version has a warning on it that the user should accessing the https: one.
>>
>> With linked data pages, where a huge amount of the Linked Open Data cloud
>> is in http: space last time I looked, systems using URIs for identifiers
>> need to be able to canonicalize them so tht anything said about http:x
>> applies equally to https:x.
>>
>> What this means is that a client given an http:  URL in a reference is
>> always free to try out the HTTPS, just adding an S, and use result if the
>>  is successful.
>> Sometimes, if bowser security prevents a https-origin web page from
>> loading any http resources as Firefox proudly does, [1], is you are writing
>> a general purpose web app which has to read arbitrary web resources with
>> XHR, ironically, you have to serve it over HTTP!     In the mean time, many
>> client libraries will I assume need to just try HTTPS as that is all they
>> are allowed.
>>
>> Or do we have to only build serious internet applications as browser
>> extensions or native apps?
>>
>> For this any many related reasons, we need to first get a very high level
>> principle that if a client switches from http to http of its own accord,
>> then it can't be given misleading data as a result.
>>
>> I suspect has been discussed in many fora -- apologies if the issue is
>> already noted and resolved, and do point to where it has
>>
>> TimBL
>>
>> [1]
>> https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/
>>
>>
>>
>>
>>
>>
>> In order for this switch to be made, transitions
>>
>>
>