#archiveteam-bs 2014-06-24,Tue

↑back Search

Time Nickname Message
01:12 🔗 Ravenloft https://www.flickr.com/photos/55408069@N04/
01:15 🔗 SketchCow Archive.org's been concentrating on just staying ahead of the flood.
01:16 🔗 SketchCow I really broke them, you know.
01:16 🔗 SketchCow Bringing on this shit, the shit I was doing, etc.
01:16 🔗 SketchCow Broke their rules, broke the limits, caused crashes
01:16 🔗 SketchCow So the more intense grabbing we're doing everywhere, that's new
01:38 🔗 joepie91_ alright
01:40 🔗 ohhdemgir Ravenloft, see image sizes, lovely quality :D - https://nymph.seedboxes.cc/skitty/flickr_55408069_N04/ - love flickr for such things
01:45 🔗 joepie91_ ohhdemgir: don't love it too much
01:45 🔗 joepie91_ :P
01:46 🔗 joepie91_ ohhdemgir: also, I presume that's being archived?
01:47 🔗 ohhdemgir is now
01:47 🔗 DFJustin ufufufu
01:49 🔗 ohhdemgir say wut
01:50 🔗 DFJustin conspiratorial laugh
01:50 🔗 garyrh huhuhuhu
01:51 🔗 ohhdemgir ahh, I'm forever learning this internet malarky
03:26 🔗 godane i know i break lots of limits with IA
03:53 🔗 balrog Wayback Machine saves the day again :)
04:20 🔗 yipdw hmm
04:20 🔗 yipdw "2.2. Your use of the [Redis To Go] Service must comply with all applicable laws, regulations and ordinances, including any laws regarding the export of data or software. You agree not to use the Service in the design, development, production, or use of missiles or the design, development, production, stockpiling, or use of chemical or biological weapons."
04:20 🔗 yipdw guess running my hyperloglog-based kill count simulation on redis to go is out :(
04:29 🔗 joepie91_ yipdw: 'MURRICA
04:30 🔗 yipdw joepie91_: I have this idea of someone using Redis to keep count of, like, VX canisters
04:30 🔗 yipdw they have a program to decrement/increment the count, but it doesn't use MULTI/EXEC/WATCH properly
04:30 🔗 yipdw so the count is all fucked due to concurrent operation
04:30 🔗 yipdw and they try to blame Redis To Go
04:30 🔗 joepie91_ it's really funny on its own :P but it's actually a fairly common TOS clause
04:30 🔗 yipdw yeah
04:31 🔗 yipdw it is
04:32 🔗 yipdw the idea of someone using a cloud service to manage weapons of mass destruction is something I find hilarious
04:33 🔗 joepie91_ "what do you mean, there's a box of nuclear warheads missing? I thought we used the Cloud?"
04:34 🔗 yipdw we can't access those shipping records because us-east-1d is down again
04:34 🔗 yipdw THIS IS WAR, AMERICA
04:35 🔗 yipdw Pixorial is deleting the photos of our stockpile
04:35 🔗 yipdw CONCLUSION: Archive Team aids terrorists
04:39 🔗 garyrh Weapons of Mass Archiving.
04:42 🔗 SketchCow ?
04:42 🔗 SketchCow WHAT is Pixoral doing?
04:43 🔗 yipdw shutting down July 18, 2014
04:43 🔗 yipdw db48x is working on fetch code
06:12 🔗 joepie91_ yipdw: "We can create a ZIP file containing all of your media files for you to download."
06:12 🔗 joepie91_ well that's something at least
06:12 🔗 joepie91_ that said, obligatory bashing
06:12 🔗 joepie91_ "Pixorial Photo & Video Sharing Without Limits"
06:12 🔗 joepie91_ ... without limits, until we shut down
06:13 🔗 yipdw you can share anything at pixorial
06:13 🔗 yipdw the only limit is yourself
09:36 🔗 joepie91_ ha
09:36 🔗 joepie91_ ISP in NL offering 'cloud storage' screwed up and baleeted user data
09:36 🔗 joepie91_ and is found to be liable for compensation
09:37 🔗 joepie91_ and their "no liability" clause was overruled in the case, because the provider had screwed up
09:41 🔗 Atluxity url to more details? this is relevant
09:43 🔗 Atluxity joepie91_?
09:43 🔗 joepie91_ Atluxity: http://blog.iusmentis.com/2014/06/24/kpn-aansprakelijk-voor-verloren-clouddata-ondanks-algemene-voorwaarden/
09:43 🔗 joepie91_ (lawyer blog)
09:43 🔗 Atluxity thanks
09:48 🔗 midas joepie91_: im not so fond about that
09:48 🔗 midas because i used to do alot of online backup
09:48 🔗 midas and we explained to our clients that if they loose the encryption key we would not be able to reset the data
09:48 🔗 joepie91_ midas: ISP screwed up, data was lost, customer had negative consequences - I don't see how there's any reasonable conclusion other than "ISP is liable"
09:48 🔗 joepie91_ um
09:48 🔗 joepie91_ you haven't read the article well enough
09:49 🔗 joepie91_ go read it again :P
09:49 🔗 midas Toen kwam er een harddiskcrash bij haar bedrijf, maar gelukkig had ze de online backup nog. Helaas geen logingegevens meer. KPN heeft dan het beleid dat ze een nieuw account aanmaken en de bestanden overzetten.
09:49 🔗 midas SHE didnt have her login credentials
09:49 🔗 midas SHE
09:49 🔗 midas not KPN, the client
09:50 🔗 joepie91_ midas: again, you did not read the article well enough
09:51 🔗 midas joepie91_: im sorry, but you didnt read it well enough in this case.
09:51 🔗 * joepie91_ sighs
09:51 🔗 joepie91_ midas: I really should not have to point this out to you, you're a native Dutch speaker
09:51 🔗 joepie91_ "Dit vonnis betekent niet dat élke cloudprovider nu automatisch onbeperkt aansprakelijk is voor alle schade. Er moet nog steeds wel een fout zijn gemaakt bij de dienstverlener. En niet elke fout zal zo ernstig zijn als wat KPN hier voor elkaar kreeg."
09:51 🔗 joepie91_ WHICH MEANS THAT IF YOU USE CLIENT-SIDE CRYPTO, THIS DOES NOT EVEN APPLY.
09:51 🔗 joepie91_ seriously, this isn't legalese
09:52 🔗 joepie91_ the explicit requirement is that /the ISP makes a mistake/
09:52 🔗 joepie91_ if you provide client-side encrypted stuff that you literally cannot access, and the customer loses their key
09:52 🔗 joepie91_ then /you did not make a mistake/
09:53 🔗 midas still, the blogpost is wrong and should be changed
09:53 🔗 BiggieJo1 just call the NSA they always have the backup key
09:53 🔗 midas they are stating that the client lost the keys, KPN should fix it
09:54 🔗 midas which is pure bullcrap
09:54 🔗 joepie91_ midas: no, the blogpost isn't wrong, that's not what they're stating, and you should learn to read
09:54 🔗 midas people should be aware that backups are the responsability of the client
09:54 🔗 joepie91_ context, dude
09:55 🔗 midas Lets agree to disagree on this
09:55 🔗 joepie91_ "omg but this sentence said that the customer lost the key and that's not a valid reason"
09:55 🔗 joepie91_ which is exactly WHY it's qualified latero n
09:55 🔗 joepie91_ no
09:55 🔗 joepie91_ it's very simple, you're complaining about a statement while completely ignoring the qualification later on
09:55 🔗 joepie91_ your complaint is logically unsound
09:56 🔗 joepie91_ so please get off your fucking horse and read it in context
09:56 🔗 midas I love my fucking horse and shall stay on it. Like it or not.
09:57 🔗 joepie91_ rather than just reading that single paragraph and concluding that it's "wrong" while entirely ignoring the rest of the article around it
12:46 🔗 midas awesome old shit on FTP's
12:46 🔗 midas Here's version 0.4e of UUDEVIEW (MS-DOS and MS-Windows versions). It's a
12:47 🔗 midas *very* good program for uu- and base-64 (de)coding. The newest version of
12:47 🔗 midas the program, as well as the Unix version and lots of information can be
12:47 🔗 midas found at UUDEVIEW's Home Page:
12:47 🔗 midas 1996
14:53 🔗 Smiley ooooo tinyback is back?
16:35 🔗 schbirid midas: it will be shipped tomorrow, i guess the shop is swamped. usually they are faster
16:35 🔗 schbirid shipped to me, not you yet :)
16:46 🔗 schbirid anyone here going to OKFest?
18:21 🔗 midas ok :)
18:22 🔗 midas where is OKfest?
18:22 🔗 midas berlin
18:22 🔗 schbirid berlin!
18:22 🔗 midas hmm should think about it
18:23 🔗 midas should get my work to sponsor me
18:29 🔗 godane so i'm uploading 1901 of The Sydney Morning Herald
18:29 🔗 godane i'm also uploading missing files in my 2007-01 cbsnews.com video uploads
18:30 🔗 godane there missing cause i got slowdown errors
22:06 🔗 joepie91_ hi, FYI
22:06 🔗 joepie91_ https://www.webhostingtalk.com/showthread.php?s=cd7d7e7514c11de3534bae7eb21fbde7&p=9155713
22:06 🔗 joepie91_ OpenVZ container breakout vulnerability
22:06 🔗 joepie91_ affects a number of common openvz setups
22:06 🔗 joepie91_ if your openvz provider hasn't emailed you about a reboot or patch yet, send them this
23:15 🔗 BiggieJ i got my own dedicated server
23:35 🔗 dashcloud on a related note, did you see the world-readable IPMI folder on Supermicro servers?
23:36 🔗 SN4T14 dashcloud, link?
23:40 🔗 dashcloud give me a minute
23:41 🔗 dashcloud this: http://blog.cari.net/carisirt-yet-another-bmc-vulnerability-and-some-added-extras/ and this: http://threatpost.com/plaintext-supermicro-ipmi-credentials-exposed

irclogger-viewer