XSF Discussion - 2018-02-26

Hello!

Is there author of XEP-0363 around?

it'd be helpful if you tell us who that is :)

oh, HTTP File Upload

that's Daniel Gultsch

(His JID is in the XEP, in case you're having trouble reaching him)

he's usually very responsive.

Yes

daniel, I'd like to discuss it

Guus, I guess, discussing XEPs in the MUC is better than privately

daniel, I don't know if this was already discussed, but I believe the XEP is missing file hash support.

daniel, how do you feel about adding it?

Yagiza: who should add and who should check the hash?

daniel, client should add and server should check

The idea is providing file hash in <request/> element instead of or along with file name.

A server must check the hash. If it already has file with provided hash, it must reply with <slot/> without <put/> element. Instead, it must contain <exist/> element.

Once client received such reply it must consider that file was already uploaded to the server before and should use URL provided in <get/> element to access the file.

So this is about dedup and not integrity?

daniel, we may neglect this possibility, like we do it with Avatars, Entity Caps and so on.

daniel, even bitcoin neglects possibility of duplicated wallet address. It just generates random hash. Probability of uploading two different files with the same SHA-1 (or SHA-256) on the server is about zero. So, I don't see any problem here.

daniel, but we get rid of unnecessary uploads, which is very useful.

Yagiza: I'm gonna keep this in mind in case I'm going to work on the XEP again

daniel, ok

daniel, if you have no time for that, I can try to make a PR or some other way send updates for the XEP if you like.

Keep in mind that this extension may leak "sensitve" information

Yagiza, if you dedup across users make sure to consider the privacy implications.

SaltyBones: what I said :)

Ah I thought this was only about your own uploads. And didn't get the point.

Yes you don't want to dedup across users.

marc, I know, just wanted to be explicit. ;)

It looks like a nice way to check if a service has certain files uploaded, yes.

SaltyBones, marc, what do you mean? Someone knowing file hash may and knowing a server where it is may get access to the file?

Yagiza: One would be able to automatically check if a file was shared on the server

Yagiza: What's your use case in practice? You and me uploading the same cat pic?

Holger, not only.

Also dog pics

Ah.

Holger, 1st use case: I've uploaded a pic, to embed it into my message with HXTML-IM.

Holger, then I try o send a message with the same pic to another contact.

In that case you already know the URI and can re-use it?

Kev, I must cache those URLs somewhere.

Kev: only if you are on the same device.

Kev, but why client must do such stupid things, if a server can?

(and client)

goffi, yes

Holger, another use case:

Yagiza: you could restric it for own file uploads but it would not work with OMEMO without leaking information I think

So the first use case doesn't cross user boundaries. Sounds like a corner case to me though. Not sure you want a protocol extension for optimizing a corner case.

marc, which leaks are you talking about?

marc: well the hash would be on the encrypted file

Which breaks the dedup of course

Holger, why not?

daniel: indeed

do we have a XEP for storing encrypted files?

Yagiza: Because keep it simple. If you start optimizing corner cases you end up with an unnecessarily bloated extension nobody wants to implement. 0363 is widely adopted because of its simplicity.

daniel: you could use the plain file hash but then you have to store the correspondig key on the device which leaks info and has the same issue as without this extension

What Holger said

Holger, what do you mean by "corner cases" now? What are use cases for this XEP, if not uploading files for sharing (and) reusing links to them?

Yagiza: By my definition, a corner case is one that applies to no more than 7.846 percent of the uploads in practice. According to my crystal ball, your case is way below that threshold.

Holger, so, please tell me your vision of use cases of XEP-0363

This is not super interesting in practice because http upload is restricted to small files anyway so reuploading is and storing copies is cheap.

Yagiza: sharing files is the main goal

Asynchronous and across multiple devices

And in group chats of course

Yagiza: Sharing cat pics.

Or maybe even dog pics. Daniel seems to support those as well.

So don't tell me I have no great visions!

Holger, ok. And when you share cat pics, it's not supposed to share the same pic with different contacts?

Yagiza: 0363 supports that. You just re-upload.

Yagiza, with small files adding dedup is just not worth the effort...

Yagiza, either re-upload, or keep a cache of the last N links shared in your client

you can even do that across devices, because you’[l download them for display anyways

Yagiza, if you want to share larger files maybe http_upload is not the right tool for the job?

Yagiza: Jingle-FT is more adapted for bigger file, and it already support hashes

if Http upload implementations were using SIMS, you’d even get the hash carbon-copied for free

so you can easily dedup locally without privacy implications :)

Holger, well. The idea is avoiding unnecessary reuploading. And now you telling that you have to reupload the file. So, why do you call that a coner case, if you admit that the problem is common?

Yagiza: I admitted that? Didn't I already quote my crystal ball?

Yagiza, he is not saying that at all. He said it is uncommon and if it happens you should reupload.

SaltyBones, I just want to add optimization where it may be easily implemented. Why do we have such optimizations for avatars, entity caps, BOB and other cases where amounts data we share is also small?

Yagiza, why do you want to add that optimization?

Yagiza: Your optimization is simple, and so are the next 10 enhancements people might suggest for special use cases. The end result is no longer simple.

Yagiza, those are vastly different use-cases

Holger, so, you don't agree with your crystal ball ;-)

Yagiza, avatars optimize having to re-download the same avatar of the same entity on each presence update. This is a way more massive optimization than optimizing the upload of a link shared twice which can easily be done by the client itself.

I don't buy that the optimisation is simple, FWIW.

SaltyBones, 'cause I like optimizations of course! Optimizations (if they are easy to implement) are always good.

Yagiza: You lost me. Whatever. You didn't convince me it's worth it, and I'd only repeat myself at this point.

Yagiza, that reason is not good enough to justify the work and complexity that it generates.

Clients remembering URIs is a pretty simple optimisation. Server doing hash checking changes the model for how it needs to be implemented on the server.

jonasw, IIRC making clients as simple as it possible, leaving all the job to server always was a good idea, wasn't it?

Right, it's not simple on the server side.

Yagiza, true, but I don’t think that the use-case is even worth the trouble on either

SaltyBones, which complexity are you talking about?

Yagiza: The idea wasn't making servers unnecessary complex though.

jonasw, which troubles?

Holger, actually, a very trivial implementation could be: (a) use hash as file name, (b) handle uploads atomically (like rsync does, it’s not too bad), (c) hash check is trivial now

Yagiza, having to think the privacy implications especially for single-user servers through

jonasw: Sure it could be done.

that’s not much more complex than what implementations are doing already tbh.

but I’d be worried about the privacy implications. ideally, the URLs would still be unique and ranodm per user, and that’s where things get complicated

jonasw: But changing an existing model is not trivial no matter how simple the new solution is.

that can probably not be done without a database anymore (for the reverse lookup (hash, user) -> user_file_url)

Holger, server's job become much more complex, if it will check hashes of files it store? Seriously?

Yagiza, at leaast it will require a namespace bump

we don’t want those

jonasw: There's existing code to handle quotas and whatnot.

Yagiza: Yes.

Holger, on *some* implementation s:>

jonasw: So?

jonasw, namespace bump? Why?

Yagiza, you’re going to require the client to send a hash, IIUC

jonasw, yes. But all modern clients already have code to calculate SHA-1, 'cause most of XEPs implemented nowadays require it.

Yagiza, but you still need to change the protocol

-> namespace bump

jonasw: I don't think that's true.

jonasw, but the protocol is still EXPERIMENTAL, so what's the problem?

It *should* be true. 🙂

Yagiza, it has massive deployment, that’s the problem

(We keep having that discussion.)

the last namespace bump caused quite a bit of disruption already

Holger: Why should it be true?

You're adding an attribute that it's easy to have backwards compat for being missing.

Holger, Kev, yeah okay, a namespace bump *or* a discoverable feature; but then the servers are going to complain that they can’t rely on the hash and so on.

No attribute, no de-dup.

I don't see why that should need a bump.

jonasw, isn't the point of the namespaces that bumps shouldn't cause disruption? :)

SaltyBones, they cause disruption if part of the network stops supporting one specific version

they don’t cause *erratic* disruption, just well-defined disruption, kinda

SaltyBones: No, the opposite. The point of a bump is to cause disruption.

:)

jonasw, anyone, who implement and deploy EXPERIMENTAL XEP's do know that everything may change dramatically from version to version. SO, once again: what's the problem?

In that case I agree.

Kev: I know the idea is ignoring unknown attributes, I just don't like it.

Yagiza, the problem is that you are trying very hard to ignore what people here are saying..

Yagiza, that users don’t care about EXPERIMENTAL vs. DRAFT. they care that they can’t share their catpics anymore.

jonasw, so, why do we need to develop XEP's? Let's just make every XEP FINAL from the beginning to avoid such problems for users.

Yagiza, I see your point, and I often concur. I’m just not sure your use-case is impactful enough to warrant a breakage. and also the feature creep mentioned by Holger.

Indeed, maybe this XEP shouldn't be experimental anymore if it is practically not experimental anymore.

if we could batch this up with another breaking change (should another one happen with 0363 before it goes to draft), I think that’d be okay.

SaltyBones, I didn't ignore anything, replying to almost every statement. I just want to understand your point of view.

or making it entirely optional, as Kev suggested.

might be the case that nobody implements it. which will lead to clients not supporting it and when a server does eventually implement it, they’ll notice that no client can do it and *bam* they drop support of it

jonasw, that's a lot of wasted effort ;)

yeah

I try to recall where that kind of thing happened to me… I think with vcard-avatar vs. pep-avatar. or pep-bookmarks vs. private-xml-bookmarks.

jonasw, yes. Making it optional is a good idea. But this solution will work even with a DRAFT XEP.

lots of effort only to realize that nobody supports it.

anyways, lunch

Yagiza, the problem is that it will always be too much work to do anything if people don't believe that it is necessary. And at least the people in here apparently don't.

SaltyBones, I'm not sure. You and Holger. Who else?

You don't have to be sure you can keep discussing but I'm out. ;)

Yes. I guess, discussion is over. Everyone, who was interested shared their opinion, Now it's up to daniel, what to do next.

Maybe this is a silly question but what is "Jingle"?

SaltyBones: XEP-0166, or in short a way to establish P2P session

It's an abstract peer-to-peer signaling protocol based on XMPP

If you are familiar with SIP, it's like that

just not encoding things in HTTP like headers but in XML

thanks

goffi, and you want to use that to build file sharing?

SaltyBones: yes, it's already working actually

but you have some sort of dedicated, always-on end-point so it's not really p2p, right?

SaltyBones: it can work between 2 devices

if they are on the same LAN and, in practice, in virtually no other case

(but I have also a component to store files, in this case it's not P2P)

otherwise you have to go through a TURN server which seems far worse than http upload

especially if you need such a component to store files, why re-invent http ?

Jingle isn't P2P.

It's a signalling protocol, nothing about it implies it must be P2P (indeed, it's how you negotiate IBB)

goffi, what is this for?

goffi, why is a custom component to store files in any way preferred over an http server?

in my experience the connection is direct most of time. jingle try to establish P2P, but if it can't it will fall back to other mechanisms (proxy, IBB, ...)

SaltyBones: many things. Keeping file for yourself, sharing with other, transmitting files between devices, etc.

goffi, just install nextcloud?

moparisthebest: I don't want/need the HTTP overhead, jingle FT is good, and there are already XEPs for file sharing

SaltyBones: why installing and maintaining an other software?

what http overhead ?

surely it's far less than anything you'll come up with in jingle/xmpp ?

just the negotiation probably takes far more time than an entire http download

moparisthebest, additional code to maintain, all the HTTP corner cases. If you don't have HTTP in your project yet it's a reasonable questions to ask whether you really need to add the full HTTP support.

in my opinion you should use the right tool for the job without reinventing the wheel if possible, if that job is putting files on a server for multiple clients to download, that tool is http

chances are you already have http in your project, but if not, adding it is surely less code to maintain than a custom xmpp component to store files?

there is already a right tool for that with XMPP, and I'm building a XMPP client

I didn't mean to criticize just curious.

it's OK to criticize, as long as it's not aggressive :)

there is the saying that if all you have is a hammer everything looks like a nail, it's still not always the right tool for the job

So you are building synchronizing on top of jingle ft?

moparisthebest: And that's a significant problem with people thinking everything needs to happen over HTTP, right? :)

SaltyBones: no synchronizing (at least not for now), just sharing files.

and also everything is linked to my XMPP account, so permission is trivial to handle.

goffi, how is file sharing different from file transfer then?

goffi, +1...getting permissions right with different user groups that fetch stuff via HTTP server gets tricky

The right tool for the job is FTP.

Kev, the reverse is true also, matrix was the opposite mistake :P

Holger: SFTP, I think.

Holger, right...which is for files, not just for Hypertext

SaltyBones: you can have a list of files, hierarchy, check XEP-0329 it's the one I'm using

FTP is the right tool for no job :P

Nothing wrong with FTP

nothing wrong with SFTP, loads wrong with FTP

Zash, as long as you tunnel it over HTTPS, right? :)

Hrr

Which one is SFTP? Is that file transfer over SSH or FTP over TLS?

over ssh, the other is ftps

One day I will remember which one is SFTP and which one is FTPS

(jingle can use HTTP by the way)

sftp isn't related to ftp afaik, other than in purpose

yep completely different

there was a really good rundown of all the reasons FTP is terrible written by the author of a really popular FTP server, but I can't seem to find it now...

Everything is terrible

If you think something isn't terrible, you aren't looking close enough

Not everything is equally terrible though. Some things are less terrible than others.

https://mywiki.wooledge.org/FtpMustDie ah there it is

magic wormhole is kind of cute

"It's old, therefore obsolete"

Bashing FTP is so boring.

Yeah.

Complains about FTP being obsolete. Does so on a website that is impossible to read on a mobile phone...

not being usable behind NAT or knowing whether uploads/downloads completed etc is also a thing not great for a file transfer mechanism

it's not just the 'old' part

NAT is the evil here, not FTP

moparisthebest: It's usable behind NAT if your firewall admin isn't stupid, or if you use passive FTP.

not disagreeing with you, but can't change the world

It doesn't matter which thing is broken and wrong if the thing I want to use doesn't work. I don't really care whos fault it is or who did or did not work around NATs.

moparisthebest: It's unencrypted if you don't use TLS, just like HTTP.

it also allows data to be unencrypted even if you do use TLS, unless you do special things

I am tempted to say that there is no situation in which FTP is the correct tool for the job when rsync exists, except that as far as I can tell the rsync protocol is completely undocumented.

The universal law of users: Whatever changed last is responsible for all problems. :)

moparisthebest: What? I don't know of an FTPS client that requests unencrypted transfer by default.

SamWhited: rsync is *very* expensive.

hopefully not

Holger: that's fair

goffi, does the jingle ft understand when your devices are both on lan and then send the file locally?

although it's not a problem I run into most of the time, I can see that being an issue if you have older or very limited hardware

Zash, amen.

anyway this is what I have against jingle for file transfer for, you end up doing complicated negotiation, and then 99.9% of the time uploading to a TURN server anyway

except unlike HTTP, you have to do it multiple times for each resource that wants the file

FTP? Who uses FTP nowadays anyways...

and if you don't have access to a TURN server it just fails, most xmpp servers support http upload nowadays, many more than have turn servers...

Maranda, a surprisingly large amount of people.

Unencrypted anonymous FTP is still the only decent way I've found of transfering files between my phone and my computer, although I desperately wish there were another way

that's my 2 cents anyway goffi , you are going to put all this work into this amazing software that just won't work on the majority of servers for the majority of users...

adb push / pull?

SamWhited: locally or over the network?

SamWhited, android phone?

moparisthebest: yes

daniel: either, I normally do it over lan

mtp works fine for me

mtp is kinda slow

yah, mtp always takes forever for me; not sure why.

I use scp/rsync on my phone.

Probably depends on the implementation?

I don't transfer large files though

mtp doesn’t work for me :(

nextcloud/syncthing or also I had an sftp server on my phone looking now...

I tend to be backing up lots of little-to-medium sized files. Pictures and music mostly.

just do it with ADB

SamWhited, https://arachnoid.com/android/SSHelper/

I really should figure out how to do ssh/rsync, that would be nicer.

oh hey, that looks promising, thanks.

jjrh, so the only way to sensibly transfer files from a commodity device to another one is with a CLI command? seriously? :D

that supports ssh/rsync, I recall having permissions issues though...

tarpipes!

SamWhited, I use KDE Connect and MTP, and if neither works (which happens, annoyingly) I eject the SD card.

haha Zash yes that's actually how I ended up transfering a whole internal sdcard once

jonasw, of course not. But adb is pretty easy to script, plug in your phone and have a udev rule pull everything.

something like tar [stuff] | adb shell su tar [stuff]

adb over wifi

and usb file transfers on my phone aren't that slow anyways.

brb

I have nextcloud. Works fine for small files or if you have time. :)

> SamWhited, https://arachnoid.com/android/SSHelper/ Oh that looks cool. Thx

You guys are all too bored (like me). A useless comment mentioning FTP is enough to spawn a 30 minute discussion on random file transfer issues.

Well... is there any XEP, which describes using TURN servers for Jingle FT?

This is great, I've already got it working better than the last SSH thing I tried…

thanks for the recommendation.

Holger, clearly file transfer is one of the great unsolved problems of computing

Yagiza: the jingle ft xep is agnostic of transport. So it should just work(tm)

I don't know if many people do implement it though

moparisthebest: True. But I think this works with more or less arbitray IT questions.

Most people use socks

this morning a co-worker was trying to send me a 3kb PDF over skype for business and it wouldn't work, ended up emailing it :'(

also companies pay a lot for that software

I tried emailing a tarball of .lua files to someone this morning, Gmail rejected it for security reasons and I ended up scp'ing to my server and sending them a URL

daniel, I thought Jingle FT uses the same transport types, which SI FT uses: IBB, SOCKS5 and OOB.

so, http upload is the only thing that worked? :P

Yay only the popular thing works because it's popular.

Ya'll know how much I hate things that are popular because of their popularity?

I still agree that sucks, but your choice is just never transfer the file on principle, or, use the way that works

It's not popular because of it's popularity, it's popular because it's simple and HTTP is a better tool for the job. It was literally made for downloading small files. Sucks for larger files, but most users want to send cat gifs so I don't really care.

you could also use sneakernet with a flash drive, but http is easier

SaltyBones: yes, that's one of the interest of the thing

But it's suffocating everything else :(

We can't have innovation at the lower layers anymore, and that makes me sad

that's true, udp/tcp is all we can ever have

and even then tcp is just getting re-invented over udp with things like QUIC

And soon only TCP/TLS/HTTP

moparisthebest: it's not only with the server, it's also between users (ex. tranfering files from your phone to your desktop machine)

cat gifs 😻 💙

But didn't someone just want to use BoB for those things :P?

goffi?

Zash: yes?

Wait, wanted to not use bob because of size restrictions

no

Maranda, I'm using BOB for small pics. For large pics I need to implement using something like HTTP File Upload.

it's not because of one thumbnail, it's if I want to transfer large amount of pictures/vidéos

and also to avoid sending them to the server

BTW, I don't see a way to use HTTP File Upload for file transfer without using Jingle FT or SI FT as session negotiation protocol.

goffi, I wonder how the fuck that works... :D

You do..?

I don't understand what innovating at the lower layers has to do with this; if you want to innovate and make something better than HTTP, do that. Using a bad thing that's complicated and not the right tool for the job isn't going to make it more likely that you displace HTTP.

SaltyBones: many candidate are tested, with priorities. The direct connection on local network is tried first.

To me it looked like XEP 363 used PUTs... But maybe I'm just having allucinations as usual.

I'm not sure where the Jingleing is required in there 🤔🤔

goffi, it's just highly unlikely p2p will work ever except in the case of LANs, seems odd to optimize for that, but even if you do go that way for p2p transfers, an http server would still be a better place to put uploads than a custom jingle component

the LAN case in one major use case for me.

and in my experience P2P is working quite often

and I have already all jingle implemented, so why should I implement something else ? Specially when there are already XEPs doing what I need

I really don't see the point of the whole discussion, I've implemented something which is working, based on current XEPs and I'm happy with it (except the point I'm trying to solve on standard@).

goffi, how do you solve broadcast/multicast (MUCs) and retrievability while the user is offline?

is that the Jingle Component you’re talking about? if so, that’s amazing

MUC is no my use can for now, but anyway I have a component so offline retrieving is not a problem at all.

I can’t parse that sentence, sorry.

my use case*. Sorry to disturb your parser.

goffi, what transfer method is used if both clients are on different LANs behind NAT ?

moparisthebest: check XEP-0234. Socks5 direct, w/ proxy, IBB in that order.

goffi, and how does this work with multiple clients?

same account logged in on different resources that is

I don't get your question, this always work with different clients.

just super wasteful bandwidth-wise?

you end up uploading it once for each client?

what are you talking about?

moparisthebest, IIUC, the jingle transfer is handled by a component. the sender uploads once, everyone downloads from componet.

it’s kinda like HTTP Upload, but with Jingle instead of HTTP.

if I want to share a picture from my mobile phone to a contact connected from 5 clients, my phone ends up uploading that once for each client no?

moparisthebest, FT XEPs usually used to transfer file from one client to another. Not to share a file.

moparisthebest, for file sharing something like HTTP Upload is better.

but this is about file sharing no?

moparisthebest, Jingle FT? No.

moparisthebest, it's just a modern way to do the same as SI FT does.

I think I'll publish a blog post with schematics to make things clear.

goffi, sounds like a good plan

Yagiza, I meant goffi's thing, but yea that'd be nice goffi

moparisthebest, ah, ok

what do you folks think about Trust-On-First-Use pinning for certificate public keys for XMPP servers?

It's fine until you change the key for whatever reason.

Uhhh that annoying iChat disco# bug.

jonasw, hpkp-type system would be better, there is even a not-yet-submitted xep

I would love that

jonasw, xnyhps is the one who wrote it but I cannot seem to find a copy...

moparisthebest, NOOOO

we have TLSA for a reason!

well obviously that's best I agree, but when entire domains never implement DNSSEC...

sorry entire TLDs is what I meant to say

jonasw: I've written a TOFU kind of library for Android back then for yaxim...

TOFU is better than nothing but not as good as HPKP

because you end up asking the user 'SHOULD THEY KEY HAVE CHANGED TO THIS CHUNK OF HEX/BASE64: XXXXX'

and they have absolutely no way to tell

as an admin *I* know, and can just set my pins correctly

moparisthebest: yes, server admins are the ones to know that best.

moparisthebest: except for the ones who don't give a yota and have self signed certificates in the first place.

Isn't that being deprecated because people shoot themselves in their foots too often?

they don't go the extra mile and set up pinned keys either, generally

well iirc chrome is dropping support sometime, I still think that's dumb though

you can bet they'll leave it enabled for google owned domains

Isn't that hardcoded in the binary?

As in, not protocol

google ones are iirc

You can get your domain onto the preload list with Google and Mozilla. No idea how that scales.

Ge0rG, only for HSTS, not for HPKP

moparisthebest: oh, I thought you can get both.

HSTS == only ever visit this site via HTTPS and enforce valid CA-issued certs, do not allow click-through bypass

not unless they changed it

You still can bypass HSTS with the hot key formerly known as "badidea"

HSTS is probably easier to scale with a bloom filter, as opposed to having a gazillion of server fingerprints shipped in your binary

mere mortals can't bypass it though, my mom couldn't

Before I learned that trick I couldn't either, and it was bothering me much.

very rarely do you want to bypass it

the whole point is because given the choice, people always click through, and if the site says not to, you shouldn't give people the choice

But *I* do know what I'm doing, sometimes even better than the admin of the site I want to visit.

Actually, it's something I'd like to do quite often.

Because hotels and capture portals.

yea but you nor I are what anyone would consider average computer users

Kev, so you allow the MITM to proceed? or you just mean to get to their terrible agreement page?

I mean to get to the agreement page.

I typically browse to 8.8.8.8 these days.

I usually type in like bob.com for that

but yea bad systems

example.com!

neverssl.com

daniel, nice!

someone, invite me to a muc please?

Ge0rG: me too 😁

Would probably be a good business model not to offer ssl on your news site. Then people would use it to get around captive portals and spend time on your website while there at it

Ge0rG, heise has SSL by now? :-O

out of curiousity, how many captive portals do you deal with on a weekly basis?

I see 1 or 2 a year :P

moparisthebest: our high speed trains have them

ah, makes sense

Lucky you; I see a captive portal basically every time I'm on the bus, train, or in most coffee shops.

Not that I take the train much (there is a small one, but it doesn't realy go anywhere here) and only some of the busses have wifi, so mostly just coffee shops.

I see them at hotels, but then there are no trains or buses around here and I don't go to coffee shops so...

And yes what Sam says. A lot of coffee shops have them

Oh yah, and hotels. Every time I travel.

There is probably a Firefox plugin that can auto accept the standard ones

Or if there isn't there should be

Or just put it in Systemd 😆

I have strict revocation checking on in Firefox, which is unfortunate since they all block their own OCSP servers and CRLs.

So I generally have to curl to login

the first thing I do on strange networks is connect to my VPN though, not open up firefox

I'm not sure how that would help. You won't be able to VPN until you've clicked through the page.

openconnect/ocserv is great for speed and firewalls

yea it doesn't work, then I know I need firefox...

At least one place I go sometimes works by stealing DNS, so if you use a VPN and know your IP (or hardcode 8.8.8.8 or something) then you don't need to sign in…

That same place also has "admin:password" for the credentials on the router though, so now I don't have a portal at all and if anyone is eating the coffee shop bandwidth with Bittorrent they get mysteriously QoSed.

:D

sounds like a case of nephew bob the IT guy setting it up for them

When I'm desperate enough I fire up iodine and tunnel through the captive portal dns

Been meaning to set that up

Sounds awful but as a last resort...