#archiveteam-bs 2017-01-29,Sun

↑back Search

Time Nickname Message
00:32 🔗 hook54321 Is mega.co.nz safe to use?
00:37 🔗 Frogging it's not unsafe
00:38 🔗 Frogging not more unsafe than other things, rather
00:39 🔗 hook54321 Kim Dotcom said he wouldn't trust it anymore...
00:39 🔗 pizzaiolo kim dotcom seems kinda shady to me
00:39 🔗 hook54321 How so?
00:45 🔗 Kaz anyone with a wikipedia entry that mentions the word fraud 10 times is likely sketchy
00:46 🔗 joepie91 hook54321: trying to determine safety of services based on public statements is a losing battle
00:46 🔗 joepie91 assume that every service is out to screw you over unless they're technically incapable of doing so
00:47 🔗 hook54321 What should I use instead of mega.co.nz then?
00:47 🔗 passerby do you mean safe or secure?
00:47 🔗 joepie91 hook54321: you haven't specified a usecase, nor did I state "you should use something other than mega.co.nz"...
00:48 🔗 * joepie91 feels like the point is being missed here
00:48 🔗 hook54321 passerby: both
00:49 🔗 joepie91 and there's no such thing as "safe" or "secure" without specifying a threat model - ie. what properties you're trying to protect (confidentiality? availability? integrity?) and from whom (ie. your potential adversaries or the potential situations)
00:49 🔗 joepie91 tl;dr insufficient information specified to give a useful answer
00:49 🔗 aschmitz If you're trying to get a file to other people, and you don't care about the confidentiality of it, mega.co.nz seems like it should get the job done. Other than that, we're pretty much just guessing what your specific needs regarding "safe" are.
00:49 🔗 joepie91 hook54321: like, the question you're asking right now is the equivalent of "what should I use instead of a spoon?"
00:50 🔗 aschmitz (And you don't care about availability or integrity either, I guess.)
00:50 🔗 joepie91 hook54321: you have no idea what I'm trying to do, how a spoon is relevant
00:50 🔗 joepie91 am I trying to eat? heat up drugs? dig myself out of snow?
00:50 🔗 joepie91 it's not possible to give a useful answer, or even determine whether a spoon is the appropriate tool, without first specifying the goal
00:51 🔗 joepie91 aschmitz: I feel like this can be summarized as "you don't care about anything"
00:51 🔗 joepie91 :p
00:51 🔗 hook54321 mega.co.nz isn't like a spoon though
00:51 🔗 Kaz I feel like you glossed over most of the important bits there
00:51 🔗 aschmitz joepie91: Well, it would, say, make it easier to transfer a file if you only have a bandwidth-limited trusted channel :P
00:52 🔗 hook54321 Safe as in, no one else can access the files because they are encrypted
00:52 🔗 aschmitz Oh, no, I don't know that I'd trust it for that.
00:52 🔗 Kaz I don't think I'd trust *any* cloud provider for that, unless I encrypted the stuff myself
00:52 🔗 aschmitz You should encrypt sensitive files before giving them to any file host, regardless of whether or not they say they'll encrypt them.
00:52 🔗 joepie91 hook54321: who is "no one else"? somebody who dislikes you? the NSA? the IRS?
00:53 🔗 hook54321 anyone
00:53 🔗 joepie91 hook54321: then give up now because you can't win
00:53 🔗 joepie91 :P
00:53 🔗 joepie91 hook54321: "anyone" includes "a conspiracy of the biggest countries' collective intelligence services with effectively limitless budget"
00:53 🔗 hook54321 If it is encrypted and decrypted by the client then you can
00:53 🔗 joepie91 no, you can't
00:53 🔗 joepie91 because they can just compromise your client
00:53 🔗 joepie91 or find a fault in the encryption algo you use
00:54 🔗 joepie91 or even just slip a backdoor into the tool you're usding
00:54 🔗 joepie91 using*
00:54 🔗 joepie91 this is why "anyone" isn't a useful threat model
00:54 🔗 joepie91 some random encryption tool isn't going to save you from targeted surveillance by the NSA
00:54 🔗 hook54321 If it's based on open source software then it shouldn't be a problem
00:54 🔗 joepie91 hook54321: license is 100% irrelevant to this and what I just described holds true in 100% of cases
00:55 🔗 odemg has quit IRC (Remote host closed the connection)
00:55 🔗 joepie91 hook54321: notice how one of the points I mentioned wasn't even related to the software you're using, but rather about just compromising your system through whatever means
00:55 🔗 joepie91 at which point it doesn't matter in the slightest what software you use
00:56 🔗 joepie91 I can take that even further and say "SWAT team knocks out your front door and arrests you, all the while extracting the keys from RAM"
00:56 🔗 joepie91 all of these are included in "anyone"
00:56 🔗 joepie91 hook54321: seriously, "anyone" is neither a useful nor a possible thing to protect from
00:56 🔗 joepie91 and you're not going to get a useful answer unless you narrow down what you're trying to protect from
00:56 🔗 aschmitz hook54321: Really, the most easily vulnerable part of mega.co.nz to anyone who can serve a court order to them is that you have no way to verify that the decryption code mega.co.nz is serving to you are "clean" and not giving your encryption keys back to someone else. (There may be other vulnerabilities - I haven't looked - but that's not something that can be fixed.) joepie91's point is probably sound regarding the general
00:56 🔗 aschmitz case of "if literally everyone is against you, you're going to lose anyway" too.
00:56 🔗 hook54321 ok, practically anyone
00:56 🔗 joepie91 there's no such thing as magic one-size-fits-all security
00:56 🔗 joepie91 hook54321: narrow it down.
00:57 🔗 joepie91 who is "practically anyone"?
00:58 🔗 hook54321 The company/person running the service, and anyone that could potentially obtain the encrypted files.
00:59 🔗 joepie91 hook54321: and now we're back to targeted surveillance by the NSA.
00:59 🔗 joepie91 because the NSA could potentially obtain the encrypted files
00:59 🔗 Kaz I'm going to save you the effort and basically say no, hook54321
01:00 🔗 hook54321 Excluding attempting to brute force decrypt it and other methods to attempt to decrypt it.
01:00 🔗 joepie91 "the company/person running the service" is a valid threat model however, and the solution to that is "use a well-tested and auditable tool that you can run locally, and don't trust anything web-based since this isn't reliably possible in browsers yet"
01:00 🔗 joepie91 but this does not cover "anyone that could potentially obtain the encrypted files"
01:00 🔗 Kaz Imagine I'm the person running the service
01:00 🔗 joepie91 hook54321: we're talking about people, not methods
01:00 🔗 joepie91 hook54321: "anyone that could potentially obtain the encrypted files" is still too wide
01:01 🔗 Kaz I don't need to decrypt your files, if you're using my client I can just decide that I won't encrypt them in the first place
01:01 🔗 hook54321 Open source client
01:02 🔗 Kaz open source != secure
01:02 🔗 Honno has quit IRC (Ping timeout: 370 seconds)
01:02 🔗 Kaz that's not how that works
01:02 🔗 hook54321 If the person is trustworthy, then it isn't an issue unless they are being water boarded or someone is pretending to be them
01:03 🔗 joepie91 hook54321: what person?
01:03 🔗 Kaz I think you're missing a middle ground between '100% trustworthy' and 'being waterboarded'
01:03 🔗 hook54321 The person running the service or developing the client.
01:03 🔗 Kaz most people don't fall into one of those absolutes
01:04 🔗 hook54321 i know
01:04 🔗 joepie91 hook54321: but you just said you wanted to protect from them
01:04 🔗 joepie91 hook54321: now they're suddenly trustworthy?
01:04 🔗 joepie91 pick one :)
01:04 🔗 hook54321 Both.
01:05 🔗 joepie91 hook54321: if they're trustworthy, you don't need to protect from them.
01:05 🔗 joepie91 they are mutually incompatible.
01:05 🔗 joepie91 hook54321: honestly I get the impression that you don't really understand what you're trying to protect from, or that there may not even *be* anything to protect from, and that you're just looking for the magical "secure"
01:06 🔗 hook54321 But if it's just sitting on a hard drive in their house or something anyone could get to it, therefore both are necessary.
01:06 🔗 joepie91 hook54321: no.
01:06 🔗 joepie91 hook54321: by extension, if you trust somebody with your data, you trust them to protect it from others
01:06 🔗 aschmitz Under any of the conditions you've articulated so far, mega.co.nz is not secure. If those come anywhere near your needs, do not rely on it for security. Encrypt your stuff offline, transmit it encrypted, transmit the encryption key some other (secure) way, and don't worry about the rest of it.
01:07 🔗 joepie91 a negligent person is not trustworthy.
01:07 🔗 odemg has joined #archiveteam-bs
01:07 🔗 hook54321 The most effective way to protect it from other people would also make it so they can't access the data either.
01:07 🔗 joepie91 aschmitz: I;d be very wary of giving blanket advice like that.
01:08 🔗 Kaz would be to destroy it*
01:08 🔗 joepie91 tends to just make people take it and run with it, without understanding the implications
01:08 🔗 joepie91 hook54321: doesn't matter. the point is, either you trust the provider, or you do not
01:08 🔗 joepie91 hook54321: if you do not trust the provider to secure your data from others, then you do not trust the provider
01:08 🔗 joepie91 that, however, STILL doesn't answer the original question
01:08 🔗 joepie91 which is "who are you trying to protect it *from*?"
01:09 🔗 hook54321 People that I don't want to access it, which is what encryption is for. I am aware that it can be broken.
01:10 🔗 joepie91 hook54321: and who are those people?
01:10 🔗 joepie91 what are their capabilities?
01:10 🔗 joepie91 does it include the NSA with effectively unlimited funds? if yes, do they have an interest in you specifically?
01:10 🔗 joepie91 or is it just your neighbours and classmates?
01:12 🔗 hook54321 Closer to neighbors and classmates, however also including administration, and potential legal concerns.
01:13 🔗 joepie91 hook54321: "I pirated a movie" legal concerns, or "I'm going to jail for a decade" legal concerns?
01:13 🔗 joepie91 (severity-wise)
01:15 🔗 joepie91 (and this should go without saying, but don't provide specifics...)
01:20 🔗 hook54321 both
01:21 🔗 joepie91 hook54321: the former is easy - stuff like piracy is totally uninteresting and if you apply even a modicum of obfuscation (doesn't even have to be encryption), it's highly unlikely to be picked up by anybody so long as detecting it isn't an automatable process
01:21 🔗 joepie91 hook54321: the latter is much, much harder
01:22 🔗 joepie91 because that goes into "targeted surveillance" area, at which point you need to start thinking about burner devices, only using public networks that are geographically distant from any place that's tied to you (including your home), etc.
01:22 🔗 joepie91 and usually the easy solution is "don't do the thing that can get you a decade in jail"
01:22 🔗 joepie91 neighbours and classmates are easy too, they're not going to bother with something that's encrypted with a non-trivial password
01:23 🔗 bwn hook54321: you just mentioned three threat categories, what will keep you 'secure' wrt neighbors and classmates will look very different than what would keep you secure against the state
01:23 🔗 joepie91 hook54321: so tl;dr... if you can drop the "decade in jail" type requirements, any well-tested encryption tool (that runs on your local system, not provided by the provider) will protect your data, confidentiality-wise, from the provider as well as neighbours/classmates/etc.
01:23 🔗 joepie91 hook54321: if you CAN'T drop the "decade in jail" type requirements, things get much hairier
01:24 🔗 joepie91 and the above is not likely to be sufficienbt
01:24 🔗 joepie91 sufficient*
01:24 🔗 hook54321 Maybe I should just rephrase my question. What trustworthy alternatives to mega.co.nz are there?
01:24 🔗 ranma hosting where anydvd^h^h^h^h^h^hredfox is hosted?
01:25 🔗 ranma and rarewares?
01:25 🔗 joepie91 hook54321: if you have the "decade in jail" requirement: none
01:25 🔗 hook54321 Practically everyone has the decade in jail requirement
01:25 🔗 joepie91 hook54321: if you have the neighbours/classmates/provider requirements: any provider with reasonable security measures that can sufficiently convince you that they won't look at your files
01:25 🔗 joepie91 hook54321: what?
01:27 🔗 hook54321 joepie91: Computer fraud and abuse act
01:27 🔗 hook54321 They should be able to convince you that they can't look at your files
01:28 🔗 joepie91 hook54321: most people can theoretically be prosecuted through the CFAA != most people are *likely* to be prosecuted through the CFAA
01:28 🔗 joepie91 (also, there's more to the world than just the US)
01:28 🔗 joepie91 [02:27] <hook54321> They should be able to convince you that they can't look at your files
01:28 🔗 joepie91 the only way to accomplish this is by removing their ability to do so and moving the 'workload' (of eg. encrypting) to your own systems
01:29 🔗 joepie91 anything provider-supplied/hosted will NEVER be able to do this
01:29 🔗 joepie91 ever
01:29 🔗 joepie91 (reliably, that is)
01:29 🔗 hook54321 BROWSER BASED ENCRYPTION/DECRYPTION
01:30 🔗 hook54321 I realize that they could create a fake webpage to obtain your decryption password though
01:30 🔗 joepie91 hook54321: I feel like this discussion is rapidly becoming completely non-constructive
01:30 🔗 joepie91 I've already addressed this
01:31 🔗 joepie91 it is NOT. POSSIBLE. to do this in a browser today, without an ability for the provider to subvert it
01:31 🔗 joepie91 100% no-matter-what completely fully totally impossible
01:31 🔗 joepie91 no exceptions
01:31 🔗 hook54321 That's where trust comes in
01:32 🔗 ranma with bare metal, isn't it impossible to MITM?
01:32 🔗 ranma FS
01:32 🔗 joepie91 hook54321: I've also addressed this as well
01:32 🔗 joepie91 you have your advice; I'm going to step out of this discussion because it isn't going anywhere
01:32 🔗 Frogging haha
01:34 🔗 passerby has quit IRC (Ping timeout: 492 seconds)
01:36 🔗 odemg has quit IRC (Remote host closed the connection)
01:37 🔗 odemg has joined #archiveteam-bs
01:50 🔗 odemg2 has joined #archiveteam-bs
01:50 🔗 odemg has quit IRC (Read error: Connection reset by peer)
02:10 🔗 SN4T14 has joined #archiveteam-bs
02:36 🔗 username1 has joined #archiveteam-bs
02:38 🔗 schbirid2 has quit IRC (Read error: Operation timed out)
02:53 🔗 icedice has quit IRC (Quit: Leaving)
03:18 🔗 ndiddy has quit IRC (Read error: Connection reset by peer)
03:35 🔗 rocode What is the preferred method of WARCing a github repo + github extras?
03:36 🔗 rocode i.e not just git clone but all the issues and extra pages.
03:50 🔗 Aranje has joined #archiveteam-bs
03:51 🔗 pizzaiolo has quit IRC (Remote host closed the connection)
03:56 🔗 odemg2 has quit IRC (Remote host closed the connection)
04:14 🔗 odemg has joined #archiveteam-bs
04:50 🔗 odemg has quit IRC (Remote host closed the connection)
04:51 🔗 odemg has joined #archiveteam-bs
05:41 🔗 Sk1d has quit IRC (Ping timeout: 194 seconds)
05:47 🔗 Sk1d has joined #archiveteam-bs
06:15 🔗 Stil3tt0 has joined #archiveteam-bs
06:20 🔗 rocode SFF.net is done. They commented out their block of ia_archiver on their main page, but their newsgroups are still blocked to all. https://webnews.sff.net/robots.txt *mumblegrumble*
06:20 🔗 rocode Newsgroup grab is here: https://archive.org/details/webnews.sff.net-read-2017-01-25
06:26 🔗 passerby has joined #archiveteam-bs
06:39 🔗 Aranje has quit IRC (Quit: Three sheets to the wind)
07:59 🔗 Honno has joined #archiveteam-bs
08:06 🔗 GE has joined #archiveteam-bs
08:22 🔗 GE has quit IRC (Quit: zzz)
08:22 🔗 GE has joined #archiveteam-bs
09:22 🔗 zyphlar has quit IRC (Quit: Connection closed for inactivity)
09:55 🔗 username1 has quit IRC (Quit: Leaving)
10:29 🔗 zyphlar has joined #archiveteam-bs
10:35 🔗 schbirid has joined #archiveteam-bs
10:50 🔗 odemg has quit IRC (Remote host closed the connection)
10:54 🔗 odemg has joined #archiveteam-bs
10:56 🔗 GE has quit IRC (Remote host closed the connection)
11:04 🔗 kristian_ has joined #archiveteam-bs
11:07 🔗 pizzaiolo has joined #archiveteam-bs
11:31 🔗 dashcloud has quit IRC (Read error: Operation timed out)
11:56 🔗 dashcloud has joined #archiveteam-bs
12:12 🔗 GE has joined #archiveteam-bs
12:36 🔗 mschfr has joined #archiveteam-bs
12:43 🔗 mschfr has quit IRC (Quit: Page closed)
12:43 🔗 mschfr has joined #archiveteam-bs
12:52 🔗 zyphlar has quit IRC (Quit: Connection closed for inactivity)
13:20 🔗 Zachary has joined #archiveteam-bs
13:22 🔗 kristian_ has quit IRC (Read error: Operation timed out)
13:23 🔗 kristian_ has joined #archiveteam-bs
13:42 🔗 BlueMaxim has quit IRC (Quit: Leaving)
13:58 🔗 odemg has quit IRC (Remote host closed the connection)
14:04 🔗 odemg has joined #archiveteam-bs
14:11 🔗 Zachary has quit IRC (Quit: Lost terminal)
14:12 🔗 pizzaiolo has quit IRC (Ping timeout: 246 seconds)
14:24 🔗 kristian_ has quit IRC (Read error: Operation timed out)
14:24 🔗 mschfr has quit IRC (Quit: Page closed)
14:27 🔗 pizzaiolo has joined #archiveteam-bs
15:08 🔗 kristian_ has joined #archiveteam-bs
15:17 🔗 nightpool has joined #archiveteam-bs
15:52 🔗 nightpool has quit IRC (Read error: Operation timed out)
16:06 🔗 kristian_ has quit IRC (Quit: Leaving)
16:28 🔗 dashcloud congrats rocode!
16:39 🔗 pizzaiolo does anyone know why sometimes I can't manually archive pages on IA but when I refresh, it works?
16:40 🔗 wp494 has quit IRC (Read error: Connection reset by peer)
16:44 🔗 wp494 has joined #archiveteam-bs
16:46 🔗 btfo has joined #archiveteam-bs
16:57 🔗 odemg has quit IRC (Read error: Connection reset by peer)
16:58 🔗 odemg has joined #archiveteam-bs
17:21 🔗 nightpool has joined #archiveteam-bs
17:56 🔗 odemg has quit IRC (Remote host closed the connection)
18:51 🔗 ravetcofx has joined #archiveteam-bs
18:56 🔗 odemg has joined #archiveteam-bs
19:06 🔗 SDr has joined #archiveteam-bs
19:07 🔗 VADemon_ has quit IRC (Read error: Connection reset by peer)
19:11 🔗 SDr hi guys, got a 4.3GB webscrape in .warc.gz format. attempting to start it via > webarchiveplayer my.warc.gz hangs the system (100% CPU for >5 mins) for 5 mins -I suspect this is indexing, despite the fact there's already an index in the directory. Is there any way to tell webarchiveplayer not to re-generate the index from scratch every time?
19:13 🔗 ravetcofx has quit IRC (Read error: Operation timed out)
19:21 🔗 BartoCH has quit IRC (Ping timeout: 260 seconds)
19:57 🔗 BartoCH has joined #archiveteam-bs
20:23 🔗 ravetcofx has joined #archiveteam-bs
20:51 🔗 ravetcofx has quit IRC (Ping timeout: 1208 seconds)
20:54 🔗 ravetcofx has joined #archiveteam-bs
21:00 🔗 BlueMaxim has joined #archiveteam-bs
21:07 🔗 Ravenloft has joined #archiveteam-bs
21:10 🔗 dashcloud has quit IRC (Read error: Operation timed out)
21:13 🔗 dashcloud has joined #archiveteam-bs
21:27 🔗 ravetcofx has quit IRC (Ping timeout: 506 seconds)
21:38 🔗 ravetcofx has joined #archiveteam-bs
22:21 🔗 ravetcofx has quit IRC (Read error: Operation timed out)
22:21 🔗 GE has quit IRC (Remote host closed the connection)
22:24 🔗 Ravenloft has quit IRC (Remote host closed the connection)
22:31 🔗 ravetcofx has joined #archiveteam-bs
22:46 🔗 Honno has quit IRC (Ping timeout: 370 seconds)
22:46 🔗 nightpoo1 has joined #archiveteam-bs
22:48 🔗 nightpool has quit IRC (Ping timeout: 190 seconds)
22:50 🔗 nightpoo1 has quit IRC (Ping timeout: 190 seconds)
22:53 🔗 godane SketchCow: turns out one your retweets url is gone
22:53 🔗 godane this one to be exact: http://web.archive.org/web/20170127224047/http://sanfrancisco.cbslocal.com/2017/01/27/source-carbon-monoxide-poisoning-killed-berkeley-couple/
22:53 🔗 godane luckly wayback has it
22:54 🔗 nightpool has joined #archiveteam-bs
22:57 🔗 antomati_ has joined #archiveteam-bs
22:57 🔗 swebb sets mode: +o antomati_
22:58 🔗 antomatic has quit IRC (Read error: Operation timed out)
23:18 🔗 odemg has quit IRC (Remote host closed the connection)
23:21 🔗 User404 has joined #archiveteam-bs
23:28 🔗 odemg has joined #archiveteam-bs
23:32 🔗 godane I'm starting to grab After School Club from Arirang
23:32 🔗 godane lucky for us there are still some episodes going back to 2014-08
23:46 🔗 ndiddy has joined #archiveteam-bs
23:50 🔗 jrwr has joined #archiveteam-bs
23:58 🔗 VADemon has joined #archiveteam-bs

irclogger-viewer