XSF Discussion - 2018-02-26


  1. andy has joined

  2. Lance has joined

  3. ralphm has joined

  4. Guus has left

  5. daniel has left

  6. valo has joined

  7. lskdjf has joined

  8. Alex has left

  9. ralphm has joined

  10. intosi has joined

  11. Lance has left

  12. Guus has left

  13. andy has left

  14. Guus has left

  15. lskdjf has joined

  16. Guus has left

  17. intosi has left

  18. Guus has left

  19. Maranda has left

  20. Maranda has joined

  21. Guus has left

  22. Lance has left

  23. lskdjf has joined

  24. Guus has left

  25. ralphm has joined

  26. Maranda has left

  27. Maranda has joined

  28. Maranda has left

  29. Guus has left

  30. ralphm has joined

  31. jonasw has left

  32. jonasw has joined

  33. Dave Cridland has left

  34. Dave Cridland has left

  35. ralphm has left

  36. dwd has joined

  37. andy has joined

  38. Guus has left

  39. andy has left

  40. Guus has left

  41. ralphm has joined

  42. winfried has joined

  43. lskdjf has joined

  44. Guus has left

  45. dwd has left

  46. Dave Cridland has left

  47. Guus has left

  48. ralphm has left

  49. Guus has left

  50. efrit has joined

  51. dwd has joined

  52. andy has joined

  53. Guus has left

  54. dwd has left

  55. andy has left

  56. ralphm has joined

  57. efrit has left

  58. efrit has joined

  59. andy has joined

  60. Dave Cridland has left

  61. SamWhited has left

  62. dwd has joined

  63. ralphm has left

  64. Guus has left

  65. Guus has left

  66. Guus has left

  67. Yagiza has joined

  68. Dave Cridland has left

  69. ralphm has joined

  70. Guus has left

  71. Guus has left

  72. Guus has left

  73. Guus has left

  74. dwd has left

  75. Guus has left

  76. Guus has left

  77. Guus has left

  78. ralphm has left

  79. efrit has left

  80. Guus has left

  81. tux has left

  82. tux has joined

  83. ralphm has joined

  84. Guus has left

  85. rion has joined

  86. Guus has left

  87. Guus has left

  88. Guus has left

  89. Guus has left

  90. Guus has left

  91. Holger has left

  92. Guus has left

  93. ralphm has left

  94. rion has left

  95. Guus has left

  96. @Alacer has left

  97. @Alacer has joined

  98. Maranda has joined

  99. ralphm has joined

  100. rion has left

  101. Ge0rG has joined

  102. Guus has left

  103. Guus has left

  104. Guus has left

  105. ralphm has left

  106. Guus has left

  107. Dave Cridland has left

  108. dwd has left

  109. ralphm has joined

  110. Guus has left

  111. dwd has joined

  112. dwd has left

  113. Guus has left

  114. ralphm has left

  115. Guus has left

  116. ralphm has joined

  117. Guus has left

  118. Guus has left

  119. Guus has left

  120. ralphm has left

  121. Guus has left

  122. ralphm has joined

  123. andy has left

  124. andy has joined

  125. j.r has left

  126. j.r has joined

  127. blabla has left

  128. Guus has left

  129. ralphm has left

  130. andy has left

  131. lumi has joined

  132. Guus has left

  133. ralphm has joined

  134. Guus has left

  135. jere has left

  136. Guus has left

  137. blabla has left

  138. Lance has left

  139. Guus has left

  140. lumi has left

  141. j.r has joined

  142. j.r has joined

  143. Guus has left

  144. j.r has joined

  145. j.r has joined

  146. la|r|ma has joined

  147. Lance has joined

  148. Guus has left

  149. Dave Cridland has left

  150. dwd has joined

  151. Dave Cridland has left

  152. Guus has left

  153. ludo has joined

  154. lskdjf has joined

  155. Guus has left

  156. Guus has left

  157. ludo has left

  158. ludo has joined

  159. Dave Cridland has left

  160. Dave Cridland has left

  161. dwd has left

  162. dwd has joined

  163. jjrh has left

  164. Nekit has left

  165. Nekit has joined

  166. ludo has left

  167. ludo has joined

  168. dwd has left

  169. Tobias has joined

  170. Tobias has joined

  171. marmistrz has left

  172. marc has left

  173. la|r|ma has joined

  174. stefandxm has left

  175. pep. has left

  176. Fabian has joined

  177. Guus has left

  178. Guus has left

  179. rtq3 has joined

  180. Dave Cridland has left

  181. goffi has joined

  182. dwd has joined

  183. Dave Cridland has left

  184. dwd has left

  185. Dave Cridland has left

  186. lovetox has joined

  187. Guus has left

  188. Dave Cridland has left

  189. dwd has joined

  190. Dave Cridland has left

  191. dwd has left

  192. dwd has joined

  193. Dave Cridland has left

  194. dwd has left

  195. Dave Cridland has left

  196. Dave Cridland has left

  197. lovetox has left

  198. rtq3 has left

  199. xnyhps has joined

  200. xnyhps has joined

  201. Dave Cridland has left

  202. Kev has left

  203. Guus has left

  204. Dave Cridland has left

  205. andy has joined

  206. marc has joined

  207. Dave Cridland has left

  208. SaltyBones has left

  209. Dave Cridland has left

  210. daniel has left

  211. daniel has joined

  212. Dave Cridland has left

  213. Dave Cridland has left

  214. Guus has left

  215. daniel has left

  216. daniel has joined

  217. intosi has joined

  218. intosi has left

  219. intosi has joined

  220. Dave Cridland has left

  221. Guus has left

  222. lskdjf has joined

  223. Dave Cridland has left

  224. andy has left

  225. Guus has left

  226. marc has left

  227. rtq3 has joined

  228. Dave Cridland has left

  229. Dave Cridland has joined

  230. daniel has left

  231. daniel has joined

  232. dwd has joined

  233. daniel has left

  234. daniel has joined

  235. andy has joined

  236. Dave Cridland has left

  237. daniel has left

  238. daniel has joined

  239. daniel has left

  240. daniel has joined

  241. daniel has left

  242. daniel has joined

  243. stefandxm has left

  244. Dave Cridland has left

  245. andy has left

  246. Dave Cridland has left

  247. dwd has left

  248. Dave Cridland has left

  249. dwd has joined

  250. blabla has joined

  251. Dave Cridland has left

  252. Dave Cridland has left

  253. dwd has left

  254. stefandxm has joined

  255. Dave Cridland has left

  256. daniel has left

  257. daniel has joined

  258. Dave Cridland has left

  259. Dave Cridland has left

  260. Dave Cridland has left

  261. daniel has left

  262. daniel has joined

  263. dwd has left

  264. Guus has left

  265. dwd has joined

  266. Dave Cridland has left

  267. dwd has left

  268. Yagiza

    Hello!

  269. Yagiza

    Is there author of XEP-0363 around?

  270. Dave Cridland has left

  271. Steve Kille has left

  272. Guus

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

  273. Guus

    oh, HTTP File Upload

  274. Guus

    that's Daniel Gultsch

  275. Guus

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

  276. Guus

    he's usually very responsive.

  277. daniel

    Yes

  278. Dave Cridland has left

  279. Steve Kille has left

  280. Steve Kille has joined

  281. marc has joined

  282. dwd has joined

  283. Guus has left

  284. Yagiza

    daniel, I'd like to discuss it

  285. Guus has left

  286. Yagiza

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

  287. Dave Cridland has left

  288. Dave Cridland has left

  289. Yagiza

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

  290. Yagiza

    daniel, how do you feel about adding it?

  291. dwd has left

  292. daniel has left

  293. daniel has joined

  294. daniel

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

  295. Yagiza

    daniel, client should add and server should check

  296. Seve/SouL has joined

  297. andy has joined

  298. Yagiza

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

  299. Guus has left

  300. Yagiza

    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.

  301. Steve Kille has left

  302. rion has left

  303. Yagiza

    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.

  304. daniel

    So this is about dedup and not integrity?

  305. andy has left

  306. daniel has left

  307. daniel has joined

  308. Yagiza

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

  309. Yagiza

    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.

  310. Yagiza

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

  311. Martin has joined

  312. daniel

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

  313. Alex has joined

  314. ralphm has joined

  315. Yagiza

    daniel, ok

  316. marc has left

  317. Yagiza

    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.

  318. marc has joined

  319. lskdjf has joined

  320. marc

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

  321. SaltyBones

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

  322. ralphm has left

  323. marc

    SaltyBones: what I said :)

  324. Holger

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

  325. Holger

    Yes you don't want to dedup across users.

  326. SaltyBones

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

  327. Kev

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

  328. Yagiza

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

  329. rtq3 has left

  330. rtq3 has joined

  331. marc

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

  332. Holger

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

  333. Yagiza

    Holger, not only.

  334. daniel

    Also dog pics

  335. Holger

    Ah.

  336. Yagiza

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

  337. Lance has left

  338. Yagiza

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

  339. Kev

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

  340. daniel has left

  341. daniel has joined

  342. Yagiza

    Kev, I must cache those URLs somewhere.

  343. goffi

    Kev: only if you are on the same device.

  344. Yagiza

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

  345. goffi

    (and client)

  346. Yagiza

    goffi, yes

  347. daniel has left

  348. daniel has joined

  349. Yagiza

    Holger, another use case:

  350. andy has joined

  351. marc

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

  352. Holger

    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.

  353. Yagiza

    marc, which leaks are you talking about?

  354. Guus has left

  355. daniel

    marc: well the hash would be on the encrypted file

  356. daniel

    Which breaks the dedup of course

  357. Yagiza

    Holger, why not?

  358. marc

    daniel: indeed

  359. goffi

    do we have a XEP for storing encrypted files?

  360. Holger

    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.

  361. Lance has joined

  362. marc

    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

  363. flow

    What Holger said

  364. stefandxm has left

  365. Yagiza

    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?

  366. Lance has left

  367. ralphm has joined

  368. daniel has left

  369. daniel has joined

  370. Holger

    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.

  371. Yagiza

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

  372. SaltyBones

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

  373. marc

    Yagiza: sharing files is the main goal

  374. marc

    Asynchronous and across multiple devices

  375. marc

    And in group chats of course

  376. Ge0rG has left

  377. Holger

    Yagiza: Sharing cat pics.

  378. Holger

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

  379. andy has left

  380. Holger

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

  381. Yagiza

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

  382. Holger

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

  383. SaltyBones

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

  384. jonasw

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

  385. jonasw

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

  386. SaltyBones

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

  387. goffi

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

  388. daniel has left

  389. daniel has joined

  390. Guus has left

  391. jonasw

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

  392. jonasw

    so you can easily dedup locally without privacy implications :)

  393. Yagiza

    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?

  394. Holger

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

  395. SaltyBones

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

  396. lskdjf has joined

  397. Yagiza

    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?

  398. SaltyBones

    Yagiza, why do you want to add that optimization?

  399. Holger

    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.

  400. jonasw

    Yagiza, those are vastly different use-cases

  401. Yagiza

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

  402. jonasw

    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.

  403. Kev

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

  404. Yagiza

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

  405. Holger

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

  406. SaltyBones

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

  407. Kev

    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.

  408. Yagiza

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

  409. Holger

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

  410. jonasw

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

  411. Yagiza

    SaltyBones, which complexity are you talking about?

  412. Holger

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

  413. Yagiza

    jonasw, which troubles?

  414. jonasw

    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

  415. jonasw

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

  416. Holger

    jonasw: Sure it could be done.

  417. jonasw

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

  418. daniel has left

  419. daniel has joined

  420. jonasw

    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

  421. Holger

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

  422. jonasw

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

  423. Yagiza

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

  424. daniel has left

  425. daniel has joined

  426. jonasw

    Yagiza, at leaast it will require a namespace bump

  427. jonasw

    we don’t want those

  428. Holger

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

  429. Holger

    Yagiza: Yes.

  430. jonasw

    Holger, on *some* implementation s:>

  431. Holger

    jonasw: So?

  432. Yagiza

    jonasw, namespace bump? Why?

  433. Guus has left

  434. jonasw

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

  435. Yagiza

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

  436. jonasw

    Yagiza, but you still need to change the protocol

  437. jonasw

    -> namespace bump

  438. andy has joined

  439. Kev

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

  440. Yagiza

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

  441. Holger

    It *should* be true. πŸ™‚

  442. jonasw

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

  443. Holger

    (We keep having that discussion.)

  444. jonasw

    the last namespace bump caused quite a bit of disruption already

  445. Kev

    Holger: Why should it be true?

  446. Kev

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

  447. jonasw

    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.

  448. Kev

    No attribute, no de-dup.

  449. Kev

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

  450. SaltyBones

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

  451. jonasw

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

  452. jonasw

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

  453. Kev

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

  454. SaltyBones

    :)

  455. Yagiza

    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?

  456. SaltyBones

    In that case I agree.

  457. Holger

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

  458. SaltyBones

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

  459. jonasw

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

  460. rtq3 has left

  461. rtq3 has joined

  462. daniel has left

  463. daniel has joined

  464. Yagiza

    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.

  465. jubalh has joined

  466. daniel has left

  467. andy has left

  468. jonasw

    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.

  469. jubalh has left

  470. SaltyBones

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

  471. jonasw

    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.

  472. Yagiza

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

  473. jonasw

    or making it entirely optional, as Kev suggested.

  474. jonasw

    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

  475. SaltyBones

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

  476. jonasw

    yeah

  477. jonasw

    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.

  478. Yagiza

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

  479. jonasw

    lots of effort only to realize that nobody supports it.

  480. jonasw

    anyways, lunch

  481. lskdjf has joined

  482. la|r|ma has joined

  483. la|r|ma has joined

  484. SaltyBones

    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.

  485. marc has left

  486. Yagiza

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

  487. SaltyBones

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

  488. stefandxm has left

  489. Yagiza

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

  490. jere has joined

  491. marmistrz has left

  492. Martin has left

  493. jubalh has joined

  494. lskdjf has left

  495. lskdjf has left

  496. Martin has joined

  497. ovo has left

  498. ovo has joined

  499. rion has joined

  500. la|r|ma has joined

  501. lskdjf has joined

  502. Guus has left

  503. marmistrz has left

  504. Martin has left

  505. Martin has joined

  506. marc has joined

  507. andy has joined

  508. Guus has left

  509. la|r|ma has left

  510. la|r|ma has joined

  511. andy has left

  512. andy has joined

  513. daniel has joined

  514. Guus has left

  515. andy has left

  516. marc has left

  517. andy has joined

  518. Guus has left

  519. blabla has left

  520. SaltyBones has left

  521. andy has left

  522. vanitasvitae has left

  523. efrit has joined

  524. rtq3 has left

  525. rtq3 has joined

  526. Guus has left

  527. Guus has left

  528. andy has joined

  529. rtq3 has left

  530. rtq3 has joined

  531. andy has left

  532. Ge0rG has left

  533. ludo has joined

  534. ludo has joined

  535. moparisthebest has joined

  536. Ge0rG has joined

  537. daniel has left

  538. daniel has joined

  539. marmistrz has left

  540. ralphm has joined

  541. tim@boese-ban.de has left

  542. tux has joined

  543. daniel has left

  544. daniel has joined

  545. marc has joined

  546. winfried has joined

  547. stefandxm has joined

  548. marc has left

  549. Zash has left

  550. lskdjf has joined

  551. efrit has left

  552. lumi has joined

  553. stefandxm has left

  554. Ge0rG has joined

  555. stefandxm has joined

  556. Dave Cridland has left

  557. marmistrz has left

  558. ralphm has joined

  559. j.r has joined

  560. j.r has joined

  561. moparisthebest has joined

  562. Guus has left

  563. jere has left

  564. jere has joined

  565. moparisthebest has joined

  566. andy has joined

  567. Guus has left

  568. SaltyBones has left

  569. andy has left

  570. rtq3 has left

  571. rtq3 has joined

  572. Dave Cridland has left

  573. dwd has left

  574. Dave Cridland has left

  575. dwd has left

  576. andy has joined

  577. dwd has left

  578. andy has left

  579. rtq3 has left

  580. rtq3 has joined

  581. dwd has left

  582. jjrh has left

  583. vanitasvitae has left

  584. ralphm has joined

  585. winfried has joined

  586. ralphm has left

  587. ralphm has joined

  588. stefandxm has left

  589. ralphm has left

  590. ralphm has joined

  591. daniel has left

  592. daniel has joined

  593. lskdjf has joined

  594. daniel has left

  595. daniel has joined

  596. lskdjf has left

  597. daniel has left

  598. daniel has joined

  599. daniel has left

  600. daniel has joined

  601. daniel has left

  602. daniel has joined

  603. jjrh has left

  604. jjrh has left

  605. daniel has left

  606. daniel has joined

  607. jjrh has left

  608. daniel has left

  609. daniel has joined

  610. Guus has left

  611. daniel has left

  612. daniel has joined

  613. Steve Kille has left

  614. lumi has left

  615. daniel has left

  616. daniel has joined

  617. Steve Kille has joined

  618. daniel has left

  619. daniel has joined

  620. marmistrz has left

  621. daniel has left

  622. daniel has joined

  623. jjrh has left

  624. matlag has left

  625. jjrh has left

  626. daniel has left

  627. daniel has joined

  628. rtq3 has left

  629. rtq3 has joined

  630. Tobias has left

  631. j.r has joined

  632. daniel has left

  633. daniel has joined

  634. moparisthebest has joined

  635. Tobias has joined

  636. daniel has left

  637. daniel has joined

  638. ralphm has joined

  639. j.r has joined

  640. daniel has left

  641. daniel has joined

  642. jubalh has left

  643. vanitasvitae has left

  644. jere has left

  645. jere has joined

  646. jjrh has left

  647. jjrh has left

  648. ralphm has left

  649. Kev has left

  650. SaltyBones has left

  651. la|r|ma has left

  652. la|r|ma has joined

  653. marmistrz has left

  654. Tobias has left

  655. jubalh has joined

  656. stefandxm has joined

  657. Guus has left

  658. j.r has joined

  659. jjrh has left

  660. jjrh has left

  661. Guus has left

  662. Guus has left

  663. jjrh has left

  664. jjrh has left

  665. ovo has left

  666. Maranda has left

  667. Maranda has left

  668. Maranda has joined

  669. Dave Cridland has left

  670. Maranda has joined

  671. stefandxm has left

  672. la|r|ma has joined

  673. la|r|ma has joined

  674. moparisthebest has joined

  675. blabla has left

  676. j.r has joined

  677. Guus has left

  678. Guus has left

  679. blabla has left

  680. daniel has left

  681. daniel has joined

  682. daniel has left

  683. daniel has joined

  684. Guus has left

  685. daniel has left

  686. daniel has joined

  687. tim@boese-ban.de has left

  688. jubalh has left

  689. jubalh has joined

  690. dwd has left

  691. daniel has left

  692. daniel has joined

  693. ralphm has left

  694. Guus has left

  695. ovo has joined

  696. stefandxm has joined

  697. Maranda has left

  698. SaltyBones

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

  699. goffi

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

  700. Tobias

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

  701. Zash

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

  702. Tobias

    just not encoding things in HTTP like headers but in XML

  703. dwd has left

  704. SaltyBones

    thanks

  705. SaltyBones

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

  706. goffi

    SaltyBones: yes, it's already working actually

  707. SaltyBones

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

  708. goffi

    SaltyBones: it can work between 2 devices

  709. moparisthebest

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

  710. goffi

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

  711. Guus has left

  712. moparisthebest

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

  713. moparisthebest

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

  714. Kev

    Jingle isn't P2P.

  715. Kev

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

  716. SaltyBones

    goffi, what is this for?

  717. moparisthebest

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

  718. goffi

    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, ...)

  719. goffi

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

  720. SaltyBones

    goffi, just install nextcloud?

  721. goffi

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

  722. goffi

    SaltyBones: why installing and maintaining an other software?

  723. moparisthebest

    what http overhead ?

  724. moparisthebest

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

  725. moparisthebest

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

  726. Tobias

    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.

  727. moparisthebest

    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

  728. moparisthebest

    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?

  729. goffi

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

  730. stefandxm has left

  731. rion has left

  732. SaltyBones

    I didn't mean to criticize just curious.

  733. goffi

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

  734. moparisthebest

    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

  735. SaltyBones

    So you are building synchronizing on top of jingle ft?

  736. Kev

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

  737. andy has joined

  738. goffi

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

  739. goffi

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

  740. SaltyBones

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

  741. Tobias

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

  742. Holger

    The right tool for the job is FTP.

  743. moparisthebest

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

  744. Kev

    Holger: SFTP, I think.

  745. Tobias

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

  746. goffi

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

  747. moparisthebest

    FTP is the right tool for no job :P

  748. Zash

    Nothing wrong with FTP

  749. moparisthebest

    nothing wrong with SFTP, loads wrong with FTP

  750. Tobias

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

  751. Zash

    Hrr

  752. SamWhited

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

  753. moparisthebest

    over ssh, the other is ftps

  754. SamWhited

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

  755. goffi

    (jingle can use HTTP by the way)

  756. Zash

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

  757. moparisthebest

    yep completely different

  758. moparisthebest

    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...

  759. Zash

    Everything is terrible

  760. Zash

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

  761. SamWhited

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

  762. moparisthebest

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

  763. tim@boese-ban.de has left

  764. ralphm has left

  765. Maranda has left

  766. SaltyBones

    magic wormhole is kind of cute

  767. Zash

    "It's old, therefore obsolete"

  768. Holger

    Bashing FTP is so boring.

  769. Holger

    Yeah.

  770. andy has left

  771. daniel

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

  772. andy has joined

  773. moparisthebest

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

  774. moparisthebest

    it's not just the 'old' part

  775. Zash

    NAT is the evil here, not FTP

  776. Holger

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

  777. moparisthebest

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

  778. SamWhited

    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.

  779. Holger

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

  780. moparisthebest

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

  781. SamWhited

    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.

  782. SaltyBones

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

  783. Holger

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

  784. rtq3 has left

  785. rtq3 has joined

  786. Holger

    SamWhited: rsync is *very* expensive.

  787. moparisthebest

    hopefully not

  788. SamWhited

    Holger: that's fair

  789. SaltyBones

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

  790. SamWhited

    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

  791. jjrh

    Zash, amen.

  792. Seve/SouL has joined

  793. vanitasvitae has left

  794. moparisthebest

    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

  795. moparisthebest

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

  796. Maranda

    FTP? Who uses FTP nowadays anyways...

  797. moparisthebest

    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...

  798. jjrh

    Maranda, a surprisingly large amount of people.

  799. xnyhps has joined

  800. waqas has joined

  801. SamWhited

    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

  802. lovetox has joined

  803. moparisthebest

    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...

  804. jjrh

    adb push / pull?

  805. daniel

    SamWhited: locally or over the network?

  806. moparisthebest

    SamWhited, android phone?

  807. Maranda thinks he presses that SCP button in SSH clients from quite a while.

  808. SamWhited

    moparisthebest: yes

  809. SamWhited

    daniel: either, I normally do it over lan

  810. daniel

    mtp works fine for me

  811. jjrh

    mtp is kinda slow

  812. SamWhited

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

  813. Zash

    I use scp/rsync on my phone.

  814. daniel

    Probably depends on the implementation?

  815. daniel

    I don't transfer large files though

  816. jonasw

    mtp doesn’t work for me :(

  817. moparisthebest

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

  818. SamWhited

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

  819. jjrh

    just do it with ADB

  820. moparisthebest

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

  821. SamWhited

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

  822. SamWhited

    oh hey, that looks promising, thanks.

  823. jonasw

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

  824. moparisthebest

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

  825. Zash

    tarpipes!

  826. jonasw

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

  827. moparisthebest

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

  828. jjrh

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

  829. moparisthebest

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

  830. moparisthebest

    adb over wifi

  831. Maranda

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

  832. Maranda

    brb

  833. daniel has left

  834. daniel has joined

  835. rtq3 has left

  836. SaltyBones

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

  837. daniel

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

  838. rtq3 has joined

  839. Holger

    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.

  840. Yagiza

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

  841. SamWhited

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

  842. SamWhited

    thanks for the recommendation.

  843. jonasw has left

  844. Guus has left

  845. moparisthebest

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

  846. daniel

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

  847. daniel

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

  848. Holger

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

  849. daniel

    Most people use socks

  850. moparisthebest

    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 :'(

  851. moparisthebest

    also companies pay a lot for that software

  852. jjrh has left

  853. MattJ

    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

  854. Yagiza

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

  855. moparisthebest

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

  856. jonasw has left

  857. Zash

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

  858. Zash

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

  859. moparisthebest

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

  860. ralphm has joined

  861. andy has left

  862. andy has joined

  863. SamWhited

    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.

  864. moparisthebest

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

  865. goffi

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

  866. Zash

    But it's suffocating everything else :(

  867. Zash

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

  868. moparisthebest

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

  869. jubalh has left

  870. moparisthebest

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

  871. Zash

    And soon only TCP/TLS/HTTP

  872. goffi

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

  873. Maranda

    cat gifs 😻 πŸ’™

  874. waqas has left

  875. jjrh has left

  876. jjrh has left

  877. jonasw has left

  878. Maranda

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

  879. daniel has left

  880. daniel has joined

  881. winfried has joined

  882. Zash

    goffi?

  883. goffi

    Zash: yes?

  884. Zash

    Wait, wanted to not use bob because of size restrictions

  885. goffi

    no

  886. Yagiza

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

  887. goffi

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

  888. goffi

    and also to avoid sending them to the server

  889. Yagiza

    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.

  890. SaltyBones

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

  891. Maranda

    You do..?

  892. SamWhited

    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.

  893. ovo has left

  894. goffi

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

  895. Maranda

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

  896. ovo has joined

  897. Maranda

    I'm not sure where the Jingleing is required in there πŸ€”πŸ€”

  898. moparisthebest

    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

  899. goffi

    the LAN case in one major use case for me.

  900. goffi

    and in my experience P2P is working quite often

  901. goffi

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

  902. Guus has left

  903. goffi

    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@).

  904. jonasw

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

  905. jonasw

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

  906. goffi

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

  907. jonasw

    I can’t parse that sentence, sorry.

  908. waqas has joined

  909. waqas has left

  910. waqas has joined

  911. goffi

    my use case*. Sorry to disturb your parser.

  912. tux has joined

  913. Maranda has left

  914. moparisthebest

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

  915. goffi

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

  916. moparisthebest

    goffi, and how does this work with multiple clients?

  917. moparisthebest

    same account logged in on different resources that is

  918. goffi

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

  919. moparisthebest

    just super wasteful bandwidth-wise?

  920. moparisthebest

    you end up uploading it once for each client?

  921. goffi

    what are you talking about?

  922. jonasw

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

  923. jonasw

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

  924. jonasw has left

  925. moparisthebest

    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?

  926. Yagiza

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

  927. Yagiza

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

  928. moparisthebest

    but this is about file sharing no?

  929. Yagiza

    moparisthebest, Jingle FT? No.

  930. Yagiza

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

  931. goffi

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

  932. jonasw

    goffi, sounds like a good plan

  933. moparisthebest

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

  934. Yagiza

    moparisthebest, ah, ok

  935. andy has left

  936. rion has joined

  937. j.r has left

  938. j.r has joined

  939. ovo has left

  940. ovo has joined

  941. Dave Cridland has left

  942. jjrh has left

  943. jjrh has left

  944. jonasw has left

  945. Martin has left

  946. jonasw has left

  947. lskdjf has joined

  948. Maranda has joined

  949. jonasw has left

  950. Lance has joined

  951. Fabian has left

  952. Lance has left

  953. Lance has joined

  954. Yagiza has left

  955. blabla has joined

  956. jubalh has joined

  957. matlag has left

  958. dwd has left

  959. Lance has left

  960. ralphm has left

  961. ralphm has joined

  962. jonasw

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

  963. blabla has joined

  964. Steve Kille has left

  965. Steve Kille has left

  966. j.r has joined

  967. rion has left

  968. rion has joined

  969. dwd has left

  970. stefandxm has joined

  971. Zash

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

  972. Steve Kille has joined

  973. Dave Cridland has left

  974. Dave Cridland has left

  975. Syndace has left

  976. Syndace has joined

  977. j.r has joined

  978. dwd has left

  979. ludo has joined

  980. ludo has joined

  981. jere has left

  982. jere has joined

  983. stefandxm has left

  984. Steve Kille has left

  985. Maranda

    Uhhh that annoying iChat disco# bug.

  986. Maranda pfts.

  987. Dave Cridland has left

  988. marc has left

  989. Dave Cridland has left

  990. dwd has left

  991. j.r has joined

  992. j.r has joined

  993. andy has joined

  994. stefandxm has joined

  995. andy has left

  996. andy has joined

  997. Dave Cridland has left

  998. Dave Cridland has left

  999. Dave Cridland has left

  1000. Dave Cridland has left

  1001. dwd has left

  1002. Maranda has joined

  1003. dwd has left

  1004. moparisthebest

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

  1005. moparisthebest

    I would love that

  1006. Dave Cridland has left

  1007. Dave Cridland has left

  1008. Dave Cridland has left

  1009. Dave Cridland has left

  1010. Fabian has joined

  1011. stefandxm has left

  1012. Dave Cridland has left

  1013. moparisthebest

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

  1014. jonasw

    moparisthebest, NOOOO

  1015. jonasw

    we have TLSA for a reason!

  1016. moparisthebest

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

  1017. Guus has left

  1018. Maranda has left

  1019. Maranda has joined

  1020. moparisthebest

    sorry entire TLDs is what I meant to say

  1021. dwd has left

  1022. jere has left

  1023. Dave Cridland has left

  1024. Dave Cridland has left

  1025. Dave Cridland has left

  1026. Maranda has left

  1027. Dave Cridland has left

  1028. dwd has left

  1029. Ge0rG

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

  1030. Dave Cridland has left

  1031. Guus has left

  1032. Guus has left

  1033. moparisthebest

    TOFU is better than nothing but not as good as HPKP

  1034. moparisthebest

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

  1035. moparisthebest

    and they have absolutely no way to tell

  1036. moparisthebest

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

  1037. Ge0rG

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

  1038. Dave Cridland has left

  1039. Ge0rG

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

  1040. Zash

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

  1041. moparisthebest

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

  1042. winfried has left

  1043. moparisthebest

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

  1044. moparisthebest

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

  1045. Zash

    Isn't that hardcoded in the binary?

  1046. Zash

    As in, not protocol

  1047. winfried has left

  1048. winfried has joined

  1049. moparisthebest

    google ones are iirc

  1050. Ge0rG

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

  1051. moparisthebest

    Ge0rG, only for HSTS, not for HPKP

  1052. Ge0rG

    moparisthebest: oh, I thought you can get both.

  1053. moparisthebest

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

  1054. moparisthebest

    not unless they changed it

  1055. rion has left

  1056. Ge0rG

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

  1057. Ge0rG

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

  1058. dwd has left

  1059. j.r has joined

  1060. j.r has joined

  1061. rion has joined

  1062. moparisthebest

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

  1063. rion has left

  1064. Ge0rG

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

  1065. Dave Cridland has left

  1066. moparisthebest

    very rarely do you want to bypass it

  1067. moparisthebest

    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

  1068. ludo has joined

  1069. dwd has left

  1070. Dave Cridland has left

  1071. Dave Cridland has left

  1072. Dave Cridland has left

  1073. Dave Cridland has left

  1074. Ge0rG

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

  1075. Dave Cridland has left

  1076. Kev

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

  1077. Kev

    Because hotels and capture portals.

  1078. moparisthebest

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

  1079. moparisthebest

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

  1080. Kev

    I mean to get to the agreement page.

  1081. Kev

    I typically browse to 8.8.8.8 these days.

  1082. moparisthebest

    I usually type in like bob.com for that

  1083. moparisthebest

    but yea bad systems

  1084. SaltyBones has left

  1085. Zash

    example.com!

  1086. daniel

    neverssl.com

  1087. Fabian has left

  1088. Dave Cridland has left

  1089. moparisthebest

    daniel, nice!

  1090. Dave Cridland has left

  1091. dwd has left

  1092. ralphm has joined

  1093. dwd has left

  1094. Dave Cridland has left

  1095. Ge0rG used to use a large German news portal, but then they switched to https... πŸ˜’

  1096. Guus

    someone, invite me to a muc please?

  1097. daniel

    Ge0rG: me too 😁

  1098. daniel

    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

  1099. jonasw

    Ge0rG, heise has SSL by now? :-O

  1100. daniel has left

  1101. daniel has joined

  1102. Maranda has joined

  1103. moparisthebest

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

  1104. moparisthebest

    I see 1 or 2 a year :P

  1105. daniel

    moparisthebest: our high speed trains have them

  1106. moparisthebest

    ah, makes sense

  1107. SamWhited

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

  1108. SamWhited

    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.

  1109. Guus has left

  1110. moparisthebest

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

  1111. daniel

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

  1112. SamWhited

    Oh yah, and hotels. Every time I travel.

  1113. daniel

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

  1114. daniel

    Or if there isn't there should be

  1115. daniel

    Or just put it in Systemd πŸ˜†

  1116. SamWhited

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

  1117. Dave Cridland has left

  1118. SamWhited

    So I generally have to curl to login

  1119. moparisthebest

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

  1120. Kev

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

  1121. moparisthebest

    openconnect/ocserv is great for speed and firewalls

  1122. Dave Cridland has left

  1123. moparisthebest

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

  1124. marmistrz has joined

  1125. dwd has left

  1126. SamWhited

    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…

  1127. Dave Cridland has left

  1128. Dave Cridland has left

  1129. SamWhited

    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.

  1130. jonasw

    :D

  1131. daniel has left

  1132. daniel has joined

  1133. Dave Cridland has left

  1134. moparisthebest

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

  1135. dwd has left

  1136. jonasw has left

  1137. efrit has joined

  1138. daniel has left

  1139. daniel has joined

  1140. dwd has left

  1141. daniel has left

  1142. daniel has joined

  1143. dwd has left

  1144. Dave Cridland has left

  1145. Guus has left

  1146. goffi has left

  1147. ludo has left

  1148. ludo has joined

  1149. Fabian has joined

  1150. tux has left

  1151. Dave Cridland has left

  1152. dwd has left

  1153. Dave Cridland has left

  1154. Guus has left

  1155. jonasw has left

  1156. Maranda has left

  1157. Maranda has joined

  1158. dwd has left

  1159. j.r has left

  1160. j.r has joined

  1161. stefandxm has joined

  1162. Alex has left

  1163. ovo has left

  1164. ovo has joined

  1165. Seve/SouL has joined

  1166. rtq3 has left

  1167. rtq3 has joined

  1168. ludo has joined

  1169. stefandxm has left

  1170. Maranda has joined

  1171. daniel has left

  1172. Alex has joined

  1173. Dave Cridland has left

  1174. daniel has joined

  1175. j.r has joined

  1176. j.r has joined

  1177. Dave Cridland has left

  1178. dwd has left

  1179. Tobias has left

  1180. ralphm has joined

  1181. jonasw has left

  1182. Dave Cridland has left

  1183. dwd has left

  1184. vanitasvitae has left

  1185. jubalh has joined

  1186. marmistrz has left

  1187. dwd has left

  1188. rtq3 has left

  1189. rtq3 has joined

  1190. daniel has left

  1191. daniel has joined

  1192. daniel has left

  1193. Dave Cridland has left

  1194. daniel has joined

  1195. Dave Cridland has left

  1196. dwd has left

  1197. marmistrz has left

  1198. Dave Cridland has left

  1199. daniel has left

  1200. daniel has joined

  1201. dwd has left

  1202. andy has left

  1203. Dave Cridland has left

  1204. Ge0rG

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

  1205. lskdjf has left

  1206. Dave Cridland has left

  1207. dwd has left

  1208. Dave Cridland has left

  1209. dwd has left

  1210. Dave Cridland has left

  1211. jubalh has joined

  1212. Dave Cridland has left

  1213. Dave Cridland has left

  1214. dwd has left

  1215. Dave Cridland has left

  1216. Dave Cridland has left

  1217. Dave Cridland has left

  1218. ralphm has joined

  1219. Fabian has left

  1220. Dave Cridland has left

  1221. Dave Cridland has left

  1222. Dave Cridland has left

  1223. Dave Cridland has left

  1224. Dave Cridland has left

  1225. moparisthebest

    Been meaning to set that up

  1226. moparisthebest

    Sounds awful but as a last resort...

  1227. vanitasvitae has left

  1228. vanitasvitae has joined

  1229. dwd has left

  1230. Holger has left

  1231. Guus has left

  1232. Guus has left

  1233. marc has left

  1234. Dave Cridland has left

  1235. SamWhited has left

  1236. daniel has left

  1237. daniel has joined

  1238. valo has left

  1239. valo has joined

  1240. Guus has left

  1241. Guus has left

  1242. Guus has left

  1243. jjrh has left

  1244. rtq3 has left

  1245. waqas has left

  1246. valo has left

  1247. SaltyBones has left

  1248. rtq3 has joined

  1249. la|r|ma has left

  1250. Nekit has left

  1251. jubalh has left

  1252. lovetox has left

  1253. ralphm has joined

  1254. Alex has left

  1255. jjrh has left

  1256. waqas has joined

  1257. waqas has left

  1258. Guus has left

  1259. Guus has left

  1260. jjrh has left

  1261. Guus has left

  1262. ralphm has joined

  1263. Guus has left

  1264. vanitasvitae has left

  1265. Guus has left

  1266. vanitasvitae has joined

  1267. Guus has left

  1268. jubalh has joined

  1269. ralphm has joined

  1270. Dave Cridland has left

  1271. Guus has left

  1272. Guus has left

  1273. dwd has left

  1274. Dave Cridland has left

  1275. Guus has left

  1276. Dave Cridland has left

  1277. dwd has left