On 7 April 2017 at 10:44, David Bird wrote:
> the more familiar "boingo.com" in the FQDN
You mean boıngo.com ? Looks legit.
On the larger subject, as a browser person, the real reason for
sandboxing is - I believe - privacy. One basic security assumption
for the web is that it is easy to cau
David Bird wrote:
> - I think statements like 'portals attempt to deceive hosts'
> reinforces the belief that captive portals are themselves hostile,
> while in fact I think you mean public access networks are hostile.
No, I don't think that I'm saying that.
We have created a bunch
I think there are some good ideas here, however, :-)
- Is this really about "captive portals" or "public access" networks?
- I think statements like 'portals attempt to deceive hosts' reinforces the
belief that captive portals are themselves hostile, while in fact I think
you mean public access
Michael Richardson 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
David Bird wrote:
> A note about capport detection evasion: It is not always on purpose...
> As more hotspots do "social login" applications, they are opening up
> the walled garden surprisingly wide to get that to work...
I think that within the Android ecosystem (which I know a lot
Dave Dolson wrote:
> I’d like to hear from browser vendors as to why the browser gets
> sandboxed when interacting with a captive portal.
Security in layers.
The browser contains lots of interesting cookies and other state.
A captive portal could, for instance, provide a stack of img UR
David Bird wrote:
> I agree, but chances are VERY high that _something_ will trigger the Os
> capport detection to give the user a captive portal notification. If
> not, then the walled garden is so large that the UE (nor the user)
Only if the user hasn't got another network connect
