Ge0rGSam is bringing up a point. How do you protect a web service from files uploaded by users?
labdsfhas left
jonaswcontext?
Dave Cridlandhas left
Ge0rGI upload a html+js file via http-upload, share the link with you, it's executed in your browser, I get your webchat / account login session cookie
Chobbeshas joined
jonaswright, this should probably be in the security considerations
jonaswbut I don’t see where he brings that up
Ge0rGthe c.im cookie is only valid for account.c.im, so this specific issue doesn't apply
Ge0rGstandards, three days ago, re Council Minutes 2018-06-20
jonasw(the solutions I’ve seen so far is to (a) be careful with the domain you choose for your upload service and (b) use Content-Disposition: attachment with anything which may contain executable code)
jonaswsure, I see that mail, but not what you’re saying in it :)
j.rhas joined
j.rhas joined
Ge0rGmaybe I extended the focus of the question slightly. the general question was about "executable content"
Ge0rGwhatever that is.
jonaswright
Ge0rGthere is nothing about content-disposition in the XEP
jonaswsomehow I didn’t get at all what that bullet point was trying to say
jonaswbut what you interpret into it kinda makes sense
Ge0rGthis is actually something I didn't have on my agenda on the last LC.
jonaswor maybe not, I’m not sure. I think when I first read it I thought something along the lines of "okay, a client really should not download and run an .exe, but that’s obvious"
Ge0rGponders between "+1 but" and "-1 because"
jonaswI think those are mostly operational concerns which will probably evolve with how the web treats content in the future.
jonasw(nothing specific in mind)
jonaswthey’re also not directly related to XMPP
Dave Cridlandhas left
jonaswso I would probably not block based on that
marmistrzhas joined
danielhas left
jonaswthey also don’t require a namespace bump or otherwise interaction with the entities implementing the protocol, AFAICT
Ge0rGyes
Ge0rGwe are only giving server operators a huge, back-facing gun.
Ge0rGnothing wrong with that.
jonaswthat’s not what I wanted to s ay
jonaswI wanted to say that it should be expected that we have to modify this in the future anyways, so modifying it right when it goes to draft should be ok too (regarding your "+1 but").
Ge0rGyeah, also don't want to be an asshole for security's sake. I played that card last time already.
jonaswthis should be fixed ASAP, but blocking advancement based on that might not help with that
jonaswgoffi, I now recall that email. I do remember that you wrote it, but I also remember not seeing this as particularly important
goffiyou don't think expiration date is important ?
jonaswmaybe you should clarify on the mailing list why you think this is particularly important
jonaswI’m not sure it’s extremely important to have this on the protocol.✎
goffiwe upload file on a server, we don't know for how long, and we have no access to it then.
jonaswI’m not sure it’s extremely important to have this on the protocol level, it should be included in the Privacy Policy for sure. ✏
goffijonasw: OK I'll try to explain more, thanks for feedback, I had the feeling to be ignored which is quite frustrating as it is a major point to me (even if it's to say that it's not that important for whatever reason).
jonaswsure
jonaswI fully understand that
labdsfhas left
jonaswto me, it really did not come across to me that you thought that this is an important point, mostly because it lacked any rationale
moparisthebesthas joined
Chobbeshas joined
jonasw(typically when I try to raise a point I think is important, I’ll put a rationale on it *why* I think its important.)
Valerianhas joined
Kevhas left
ralphmhas joined
danielgoffi: in parts that was due to me being extremely busy with work these days. And in parts I was taking the easy way out and was waiting for someone to write a me too or something
jonaswdaniel, FWIW, I think this is a good idea and supplements the work I was aiming to do with ToS.
jonaswI also think that this can easily be added later because it’s a data form \o/
j.rhas joined
j.rhas joined
danielyeah i’m ok with just putting it in there as an optional data form field
danielbut I don’t see a technical use case for it because it won’t be reliable anyway
danieli see it as a pure TOS informational thing
jonaswmaybe
Valerianhas left
Valerianhas joined
Dave Cridlandhas left
goffijonasw: indeed, I've made a new message. daniel: OK, thanks to come in the discussion here, I've sent a new message to explain. I know it's not reliable, but it's informational, and there is a relation of trust with a server anyway (if I can trust retention date, I can't trust anything). It's the same with ToS.
Dave Cridlandhas left
lnjhas left
Dave Cridlandhas left
Dave Cridlandhas left
Ge0rGDid you just add data forms to http upload?
goffithe think with putting it in the HTTP Upload XEP is to make it mandatory. If it's not, nobody will set the data. Also the HTTP Upoad Component probably knows when the files are deleted so it can be set automatically.
jonaswGe0rG, they were always there
jonaswGe0rG, in disco#info
j.rhas joined
danielgoffi, i see and agree with most of your points. and don’t think the suggested solution is a very good one or a solution at all
Ge0rGAh
danielif anything we would need the client to mark a file as permanent (for avatars or blogs posts) or shortlived
danieland maybe a deletion command
jonaswdaniel, +1
Dave Cridlandhas left
j.rhas joined
danieljust putting the information in there on how long a server might store it doesn't do anything
danielor very very little
danieli mean what i'm a supposed to do? reupload the avatar every 30 days?
Dave Cridlandhas left
goffihaving a way to specify retention time in the request would be better, my email is not discarding this option.
Ge0rGPermanent storage requirements will break my GDPR compliance script... 🤔
j.rhas joined
Ge0rGOr we need to have multiple upload components for temporary and permanent storage
jonaswew
goffidaniel: is is possible to write your comments on standard@ even in a short email, so we can have other people input?
KevI imagine it's generally down to local policy.
jonaswGe0rG, your component could implement this trivially by putting permanant files in a different directory (and reflecting that in the URL)
KevBut avatars are an exception as they are 'always' permanent.
danieljonasw, yeah. the problem with that is that you still need some policy on the server that prevents stupid clients from always using the permanent store
danieland cluttering your file system
KevDo you?
KevI mean, you can always have usage limits.
jonaswdaniel, quotas? and explicit request for permanent storage so that stupid clients need to be actively stupid at least
jonaswthen it blows up in their face for reaching quotas and you’re done :)
jonaswquotas can be really small for permanent storage on IM deployments, 10 MiB or something
jonaswthat’ll be reached extremely quickly
danieljonasw, yes and yes. but it makes implementations a bit more complicated then 'just put it in a different folder' is what i'm saying
jonasw(when abused for sending gifs to MUCs)
jonaswdaniel, you need to have some type of quota anyways
j.rhas joined
danielright. but then you need different quotas
Dave Cridlandhas left
j.rhas joined
jonaswthat’s true
danieli'm not saying it can’t be done. but right now most http upload implementations are very very simple
Steve Killehas left
jonaswindeed
jonaswand I think if one went around and started abusing that, many servers would fail very quickly with ENOSPC
Dave Cridlandhas left
Ge0rGthis sounds like a quick escalation from "file sharing" to "cloud storage provider"
danielyes
danielespecially if you start doing delete
danieland list files
Steve Killehas left
jonaswjust implement WebDAV with XMPP auth
Ge0rGif you want to provide permanent storage, you need both listing and deletion. and quotas
danielhas left
jonaswactually, that doesn’t sound *too* bad for permanent HTTP-based storage.
danielthat’s why i see a general desire to have those features but am hesitent to put them in the xep
goffithat looks like the component I'm doing with Jingle.
Ge0rGjonasw: but custom http headers for obscure aws servers!11!
jonaswyou’ll probably find a WebDAV library and servers which support WebDAV. just make the client pass some token in the HTTP Auth header and done.
lorddavidiiihas left
goffiin this case why not keeping HTTP Upload for simple temporary storage, and specifying date of expiration, and having more elaborated components for stuff like avatar or blogs ?
Dave Cridlandhas left
jonaswgoffi, this sounds very reasonable
goffiand explicitly forbidding permanent storage with HTTP Upload
jonaswI wouldn’t go that far
danielwhat’s the use case for the expiration then?
Dave Cridlandhas left
daniel*the expiration date
goffiif we want to keep the implementation simple, which is the main interest of this XEP I think, permanent storage doesn't seem an option.
goffidaniel: knowing when the file is deleted, how long we can still use the link.
goffiI'm not confortable in uploading a picture if I don't know how long it will stay
goffiI can encrypt, but I then have the feeling to waster resources.
danielapperently you are comfortable with sending messages without knowing how long they will stay in archive
Dave Cridlandhas left
danielthat's what the TOS are for…
goffiI know how long they stay
goffion my server at least
KevHow?
jonaswyou also know how long files are stored on your server ;-)
Dave Cridlandhas left
goffiright, but I have no MAM at the moment, so my server is not keeping anything. But the same question is valid for MAM I've never said the opposite.
alexishas left
danielyeah i’m not sure that every feature in xmpp that has the ability to store something needs to signal it's own retention period
goffiand about resource, it's not the same about a couple of message, and one or several MB files
danielmy vcard service never report how long it will store that either
Valerianhas left
alexishas joined
jonaswgoffi, not your department; the server is responsible for managing the resources it offers to you.
jonaswit must not rely on your goodwill
Dave Cridlandhas left
goffidaniel: in this case in ToS, but it may be mentioned in the XEP
Dave Cridlandhas left
goffijonasw: I usually have different usage if I know I'm wasting resources
Dave Cridlandhas left
jonaswyou shouldn’t
goffiwhy ?
KevSure you should. Wasteful is wasteful.
jonaswit’s the servers responsibility to take care of that.
KevWhether it's you paying the bill or someone else doesn't change that.
jonaswI mean right, uploading a screenshot of each message instead of the message itself *is* wasteful and you shouldn’t do that
Dave Cridlandhas left
goffijonasw: put on an analogy, if I can choose between plastic and something else, and I know plastic can't be recycled correctly and something else can, I'll take something else.
jonaswbut I don’t think you should base your individual upload decisions on whether and which retention policy the server implements. you might base your decision which server to use on that, though (that makes sense to me for resource use and privacy reasons)
goffiand don't say "once it's in the trash, it's not my problem"
jonaswgoffi, I’m not arguing against that, it makes sense. and choosing a server based on those factors may make a lot of sense.
Dave Cridlandhas left
goffito get back to initial subject, it make sense to put this on ToS, but is there anyway to make it mandatory ? Or at least a SHOULD ?
jonaswhaving this information in the disco#info is good, I think
jonaswbut we need to make the semantics clear
goffiyes disco#info make sense
Dave Cridlandhas left
jonaswa service could have a dynamic retention time based on resource use for example. something like "at least 7 days, at most 14 days, and everything in between depends on how full our disk is". how would that be reflected? should the sevrice say 7 days (this will confuse users who expect their data to be gone after the threshold) or 14 days (which will confuse users who expect the data to be available up to the threshold)?
Valerianhas joined
jonaswdo we need a min-retention and max-retention field?
KevAnd how do you signal policy changes?
goffithat's what framadrop is doing
goffilarge file => short rentention
KevYou uploaded when it was a policy to keep for 30 days, and now the server is changed to 15.
Dave Cridlandhas left
goffiin this case it need to be returned in the HTTP Upload <IQ> result
jonaswgoffi, Expires header on the HTTP response would be my suggestion
alexishas joined
jonasw(which gives a min-retention)
goffijonasw: I'm fine with that as long as it is explained in a XEP, either HTTP Upload itself, or a separated one mentioned in HTTP Upload.
jonaswyupp
goffiif it's not specified anywher, nobody will do it.
Steve Killehas left
Dave Cridlandhas left
lorddavidiiihas left
Dave Cridlandhas left
Guushas left
Dave Cridlandhas left
Dave Cridlandhas left
danielhas left
blablahas left
blablahas joined
Dave Cridlandhas left
rishiraj22has left
labdsfhas left
alexishas left
marmistrzhas left
alexishas joined
Dave Cridlandhas left
muppethhas joined
Dave Cridlandhas left
Dave Cridlandhas left
muppethhas joined
Kevhas left
lorddavidiiihas left
Valerianhas left
vanitasvitaehas left
mikaelahas joined
Valerianhas joined
Valerianhas left
muppethhas joined
blablahas left
blablahas joined
lorddavidiiihas left
Valerianhas joined
muppethhas joined
muppethhas joined
Dave Cridlandhas left
moparisthebesthas joined
lumihas joined
moparisthebesthas joined
Dave Cridlandhas left
alexishas joined
alexishas left
alexishas joined
Kevhas left
j.rhas joined
j.rhas joined
alexishas joined
danielhas left
muppethhas joined
rishiraj22has joined
Dave Cridlandhas left
Dave Cridlandhas left
Andrew Nenakhovhas left
ThibGhas joined
Andrew Nenakhovhas joined
jubalhhas joined
rishiraj22has left
Dave Cridlandhas left
rishiraj22has joined
Guushas left
Valerianhas left
Nekithas left
Nekithas left
Dave Cridlandhas left
rishiraj22has left
Dave Cridlandhas left
edhelashas left
rishiraj22has joined
edhelashas joined
j.rhas joined
alexishas joined
lorddavidiiihas left
Ge0rGhas left
alexishas left
alexishas joined
Guushas left
danielhas left
Ge0rGhas joined
lorddavidiiihas left
j.rhas joined
Ge0rGhas left
moparisthebesthas joined
moparisthebesthas joined
jubalhhas joined
Dave Cridlandhas left
Nekithas left
alexishas left
Dave Cridlandhas left
alexishas joined
Dave Cridlandhas left
Dave Cridlandhas left
Guushas left
Dave Cridlandhas left
alexishas left
Valerianhas joined
Dave Cridlandhas left
Dave Cridlandhas left
pep.has left
alexishas joined
lumihas left
Dave Cridlandhas left
Dave Cridlandhas left
j.rhas joined
rishiraj22has left
flowhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
jubalhhas joined
Dave Cridlandhas left
Dave Cridlandhas left
j.rhas joined
Valerianhas left
Valerianhas joined
Valerianhas left
Valerianhas joined
Valerianhas left
Valerianhas joined
Valerianhas left
Dave Cridlandhas left
moparisthebesthas joined
Dave Cridlandhas left
moparisthebesthas joined
Dave Cridlandhas left
jubalhhas joined
karphas left
karphas joined
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
ralphmhas left
Guushas left
Dave Cridlandhas left
Kevhas left
marchas joined
ThibGhas joined
Dave Cridlandhas left
ThibGhas joined
jubalhhas joined
j.rhas joined
Dave Cridlandhas left
ThibGhas joined
ThibGhas joined
marmistrzhas joined
efrithas joined
Dave Cridlandhas left
Guushas left
Dave Cridlandhas left
Dave Cridlandhas left
j.rhas joined
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
Dave Cridlandhas left
jerehas joined
jerehas left
jerehas joined
jubalhhas joined
Dave Cridlandhas left
Dave Cridlandhas left
jubalhhas joined
Dave Cridlandhas left
j.rhas joined
SaltyBoneshas left
SaltyBoneshas joined
danielhas left
j.rhas joined
Dave Cridlandhas left
j.rhas joined
j.rhas joined
moparisthebesthas joined
moparisthebesthas joined
muppethhas joined
Dave Cridlandhas left
muppethhas joined
Dave Cridlandhas left
ralphmhas joined
efrithas left
danielhas left
jubalhhas joined
Dave Cridlandhas left
tuxhas joined
Dave Cridlandhas left
danielhas left
blablahas left
Valerianhas joined
blablahas joined
j.rhas joined
alexishas left
j.rhas joined
alexishas joined
marmistrzhas joined
mikaelahas joined
alexishas left
Dave Cridlandhas left
Dave Cridlandhas left
winfriedhas left
Dave Cridlandhas left
Dave Cridlandhas left
doshas joined
SaltyBoneshas left
SaltyBoneshas joined
jjrhhas left
Dave Cridlandhas left
andyhas left
andyhas joined
SamWhitedhas left
SamWhitedhas joined
danielhas left
Dave Cridlandhas left
la|r|mahas joined
Dave Cridlandhas left
marmistrzhas joined
Dave Cridlandhas left
marmistrzhas left
Guushas left
Guushas left
j.rhas left
jjrhhas left
Marandahas joined
j.rhas joined
ThibGhas joined
ThibGhas joined
Marandasince we're in disco#info topic, a good chunk of, if not all of, the examples in https://xmpp.org/extensions/xep-0045.html don't have the disco#info feature set (and apparently that's a MUST)
intosihas left
intosihas joined
jonaswMaranda, I think it is generally understood that examples showing disco#info query replies are always exceprts
Marandais it?
lskdjfhas joined
Maranda🤔
Maranda😁
jonaswall the XEPs do that
MarandaI see nothing that makes me assume that, but okay.
goffire: HTTP Upload, would a del URL as suggested by Tess Sterr be a big deal? I don't think it complicates too much on server side, and after it's up to the client to keep it or not.
Dave Cridlandhas left
jonaswMaranda, it’s easy. disco#info has the disco#info feature as MUST. it is not included. ergo, the examples are excerpts :)
jonaswgoffi, it’s not very useful IMO
goffijonasw: why ?
MattJgoffi, I'm not strictly against it (especially if optional for the server), but just because there's a delete URL doesn't mean the file will stay until it's deleted
jonaswit would require the client to save the URL somewhere, and the multi-client story isn’t tight either
Marandajonasw, if it was an excerpts I would expect some ... or around in 'em, https://xmpp.org/extensions/xep-0045.html#disco-rooms don't look like excerpts (to myself at least).
goffiit would solve the "oops I've uploaded nuclear codes" case, or at least reduce the problem.
jonaswMaranda, that’s disco#items, not disco#info :)
Marandajonasw, disco#info examples are in there as well.
Marandabrb
jonaswMaranda, feel free to submit a patch which adds ... to all the disco#info examples
goffiMattJ: I'm not sure to understand your sentence: "just because there's a delete URL doesn't mean the file will stay until it's deleted"
goffiyou mean if we want to upload it forever ?
MattJgoffi, I was referring to the second part of your message, "and after it's up to the client to keep it or not"
jonaswMattJ, that was referring to the delete URL I think
MattJSince earlier we were discussing retention times
MattJOh, I see
MattJOk, ignore me then :)
goffi:)
goffibut I think delete URL and retention time are complementary, and both are trivial to implement.
MattJI can certainly see value in DELETE, even if it only works from a single client it solves the "oops" problem
goffi(where retention time can be "forever as long as you don't kill your quota")
goffidaniel: ^
Dave Cridlandhas left
Marandahas left
MattJThough considering the "oops" problem, if your contact is online, they are probably already downloading your file, or downloaded it
ZashIs that not an UX issue? That clients send stuff without any confirmation
MattJDoes it ask for confirmation every time you press enter after typing a message?
danielthat reminds me that i still have feedback for activity pub
Dave Cridlandhas left
Dave Cridlandhas left
Kevhas left
jjrhhas left
ralphmhas joined
Ge0rGdaniel: could you add a subsection about properly securing a http upload service in a way that won't allow uploading of html/js to compromise other web applications on the same infrastructure? e.g. an account login portal, or a webchat client
MattJHmm, was there a standard for adding custom non-standard items in e.g. a MUC configuration form?
MattJI vaguely recall something, but I can't remember if it was just a discussion or actually a standard
MattJAha, found in XEP-0068
Zash-xep 68
BunnehZash: Field Standardization for Data Forms (Informational, Active, 2012-05-28)
See: https://xmpp.org/extensions/xep-0068.html
flowKev, Steve Kille: you are currently pursuing user#channel@domain(/resource) as MIX JID, is that still correct?
rionhas joined
Dave Cridlandhas left
anjanhas left
rishiraj22has left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
danielhas left
danielhas joined
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Kevhas left
marchas left
SaltyBoneshas left
Andrew Nenakhovhas left
Andrew Nenakhovhas joined
Steve Killeflow: yes. The spec of this is now in XEP-403, as this encoding is not needed for the basic message distribution specified in MIX core. This encoding is used for sharing presence status of MIX participants and to address Mix participants through the channel. The discussion concluded that it was desirable that each participant bare JID was unique to the participant.