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