On Tue, 16 Jun 2015, Bastien Nocera wrote:
That’s what dnssec-trigger ideally _should_ do. What would it _actually_
do, e.g. with the current code?
That's defined by login-command: in /etc/dnssec-trigger/dnssec-trigger.conf
which we did not change from the default "xdg-open".
It uses the URL
- Original Message -
> On Mon, 15 Jun 2015, Miloslav Trmač wrote:
>
> >> Detect it and show the sandboxed browser. If that means that the user
> >> has to type their Facebook password again, then the user is welcome to
> >> do that. I don't see why we should make it easier to track use
On Mon, 15 Jun 2015, Miloslav Trmač wrote:
Detect it and show the sandboxed browser. If that means that the user
has to type their Facebook password again, then the user is welcome to
do that. I don't see why we should make it easier to track users,
though.
That’s what dnssec-trigger ideally
> On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač wrote:
> > What would dnssec-trigger do if an attacker^Wlegitimate hotspot provider
> > deliberately let the hotspot probe lookup and connection through, but kept
> > redirecting everything else?
>
> Detect it and show the sandboxed browser. If t
> Apple (foolishly) used to use something like http://apple.com/hotspot
> on their main site itself, which meant that using a VPN on demand could
> never protect apple.com because the iphone had to leave that domain out
> of the vpn trigger list or else all hotspot detection would be broken. It
> s
On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač wrote:
> Hello,
>
> On Jun 13, 2015 4:28 AM, "Michael Catanzaro" wrote:
>> On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
>> > >
>> > But that's not even right. Suppose you have a captive portal that
>> > wants you to log in via your G
Hello,
> On Jun 13, 2015 4:28 AM, "Michael Catanzaro" < mcatanz...@gnome.org > wrote:
> > On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
> > > >
> > > But that's not even right. Suppose you have a captive portal that
> > > wants you to log in via your Google account. It can send you
On 15 June 2015 at 13:07, Paul Wouters wrote:
> On Mon, 15 Jun 2015, Stephen John Smoogen wrote:
>
>> Is the code on how ChromeOS or Android detects captivity part of the
>> 'public' code? It seems to do a 'good' job in finding many captive
>> portals so might be something to get an idea on how ma
On Mon, Jun 15, 2015 at 12:07 PM, Paul Wouters wrote:
> On Mon, 15 Jun 2015, Stephen John Smoogen wrote:
>
>> Is the code on how ChromeOS or Android detects captivity part of the
>> 'public' code? It seems to do a 'good' job in finding many captive
>> portals so might be something to get an idea o
On Mon, 15 Jun 2015, Stephen John Smoogen wrote:
Is the code on how ChromeOS or Android detects captivity part of the
'public' code? It seems to do a 'good' job in finding many captive
portals so might be something to get an idea on how many weird ways
things are out there.
I think everyone do
On 13 June 2015 at 17:10, Michael Catanzaro wrote:
> On Sat, 2015-06-13 at 15:54 -0400, Paul Wouters wrote:
>> If the captive portal uses the system's DNS, and the system has
>> cached
>> www.gnome.org from when you were on a previous network, your captive
>> portal check might use a cached DNS re
On Sat, 13 Jun 2015, Michael Catanzaro wrote:
There is one thing I don't understand. Surely the above is exactly what
will happen if you were to get stuck behind a captive portal with
Firefox or any normal browser? But portals still work reliably for
users.
You should visit more hotels. The nu
On Sat, 2015-06-13 at 15:54 -0400, Paul Wouters wrote:
> If the captive portal uses the system's DNS, and the system has
> cached
> www.gnome.org from when you were on a previous network, your captive
> portal check might use a cached DNS resolve and try to use an HTTP
> connection to a blocked IP
On Sat, 13 Jun 2015, Michael Catanzaro wrote:
Hm... the captive portal helper loads www.gnome.org but it only runs
after NetworkManager has decided there is a captive portal. We can make
this URL configurable at build time if there's really a problem, but
I'm not sure there is, since it's not us
Am 13.06.2015 um 21:01 schrieb Michael Catanzaro:
There is a good reason we started hotspot-nocache.fedoraproject.org.
Hm... the captive portal helper loads www.gnome.org but it only runs
after NetworkManager has decided there is a captive portal. We can make
this URL configurable at build tim
On Sat, 2015-06-13 at 14:36 -0400, Paul Wouters wrote:
> using www.gnome.org is wrong. For one, you cannot guarantee they
> won't
> end up using some redirect and than the captive portal would fail.
I don't get it: what is wrong, what would fail? We expect them to
replace the contents of
www.gno
On Sat, 13 Jun 2015, Andrew Lutomirski wrote:
> It'd be nice to not show
> http://www.gnome.org (the test URL we load, expecting to be hijacked)
> if the portal decides not to redirect you to a new URI (not sure how
> common that is), but I think we will have to or we can't fix this
It coul
On Jun 13, 2015 4:28 AM, "Michael Catanzaro" wrote:
>
> On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
> > >
> > But that's not even right. Suppose you have a captive portal that
> > wants you to log in via your Google account. It can send you do
> > https://accounts.google.com, and
On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
> >
> But that's not even right. Suppose you have a captive portal that
> wants you to log in via your Google account. It can send you do
> https://accounts.google.com, and your browser can verify the
> certificate and show you an indic
19 matches
Mail list logo
