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 users,
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
On 13 June 2015 at 17:10, Michael Catanzaro mcatanz...@gnome.org 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
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
On 15 June 2015 at 13:07, Paul Wouters p...@nohats.ca 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
On Mon, Jun 15, 2015 at 12:07 PM, Paul Wouters p...@nohats.ca 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
On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač m...@redhat.com 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
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 do
On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač m...@redhat.com wrote:
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
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
seems
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
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 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 do
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 indication
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
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
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 could
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
19 matches
Mail list logo
