|
I don’t think the API should contain anything that would move control towards the UE. I think the API at most should be informative; as a decoration on the information it could provide the user by either sending him to the capport url, or as additional information that was not included in the icmp message that triggered the API call. Authentication of the icmp message could also be a role for the API, but I think if this could be solved without the API but with icmp itself, it would be much better.
I expect if the API would be rich, and hint towards control, adoptation will be low, and could lead to half/buggy implemetations. Also, I expect, if the capport provider is trying to defeat the sandboxed browsers, which seems to be because they lack control (analytics/tracking/marketing requirements), I think it’s safe to assume that an API that potentially can go beyond the sandboxed browser limitations, would not be something commercial capport providers would appreciate.
Also, I have my doubts concerning legal issues as well; for e.g. accepting t&c’s, would the capport-provider rely on a UE implementation that would display & handle accepting this? What if there is a legal dispute, and the question arises if the user actually accepted the t&c’s; where would you start the investigation and the capport or at the UE implementation that did some magic t&c accepting implementation? Moving (or keeping) that journey inside a browser would leave the control at the capport-side.
With that in mind, and back to my first statement, I think the only decoration that makes sense is too facilitate devices that aren’t capable of displaying the capport itself, but maybe are capable of displaying some message on a small display (internet of things, maybe e.g. a internet radio appliance). But maybe this could be solved by supplying a reason in the icmp.
The sandboxed browser is something interesting. If the icmp would trigger, instead of the capport detection, and the result would be that the capport sandboxed browser is opened; how would that fit the (e.g. mobile) use case where the user hit is quota when he was watching youtube. Most of the discussions focus on joining the network, while in my opinion this is just one half of the capport scope.
The ohare airport is interesting as well; if the icmp is the trigger, the capport might not be triggered immediately. I can imagine, they would like to inform the user upfront of what they provide; not wait until the UE visits something outside of the walled garden.
Would it make sense to hint the UE that the capport should not be opened in the sandbox browser, but should be opened in the default browser instead? Currently there is no formal means for the capport provider, other than give the correct responses on the magic urls. Though, I think if this option would exist, by default capport providers will choose to use the regular browser.
Van: Captive-portals [[email protected]] namens David Bird [[email protected]]
Verzonden: woensdag 5 april 2017 19:15 Aan: Dave Dolson CC: [email protected]; Christian Saunders Onderwerp: Re: [Captive-portals] Arguments against (any) Capport "API" I agree with that... but, to be clear, it really is just an improvement on WISPr XML, and with WISPr XML already, not only used, but used to make money, the reasons for supporting this API MUST be inline with the venue/Operator needs. 'Automating
login' (as a focus for the API) quickly becomes venue / regional / legal / vertical / application / access policy dependent.. Not to mention, I question the value for the user in making it super simple for their devices to auto-login into public access networks
(without clear user intent). This seems irresponsible, on our part, when there are solutions out there already that do automate this login, but only after taking extra security measures (presumably, hotspot aggregators conceal your identity when roaming, and
their Apps can do more things).
On Wed, Apr 5, 2017 at 9:51 AM, Dave Dolson
<[email protected]> wrote:
|