[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Captive-portals] captive portal detectors



Michael Richardson <[email protected]> wrote:
    > Yes, I agree.  That's the carrot part.  "Do X and life will be better"

    > But, I was talking about the stick part: "Until you do X, you'll get a
    > bad review"

    > I realize that this isn't a protocol we can write.  It is something
    > that the occured when we did the ECN experiment.

    > I am suggesting that when a platform fails to find X, I think it SHOULD
    > let the user know about it.

I was thinking more about IETF actions relating to poorly behaved legacy
portals.

I would like to propose that this WG write a document detailing how legacy
portals attempt to deceive hosts, standardizing the descriptions.

For each case where the host concludes that they have detected some specific
kind of deception, the document would provide a standardized description of
what kind of event was detected.  We would provide simplified (but common)
english descriptions of the kind of deception (i.e. "DNS request for
wellknown.example.com returned lie", or "DNSSEC bits were turned off", or
ICMP to 8.8.8.8 is not answered, or port-443 to wellknown.example.com returns
invalid certificate, etc...) along with an error code such that the
descriptions could be translated.

As an extension the user agents could collect the information for upload
to reputation systems of the end user's choice. (or not, as the user wishes)
(I suspect that MILE has all the common infrastructure we want for the
format)

So in effect, I'm asking for a standardized interface from a user space
application (an "app") to the captive portal detection system inside the
OS.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature