Hacker Newsnew | comments | show | ask | jobs | submit | bascule's comments login

It's an idea as old as Xanadu, which predates the web by decades:


But see also:

- BitTorrent's Project Maelstrom

- GNUnet

- Tahoe-LAFS

- MaidSafe

- MojoNation, the technology that inspired BitTorrent

...just to name a few.

The problem with these systems is they don't provide a whole lot of compelling benefits over the regular web, and generally provide a worse user experience.

Solving the UX problem is the real hurdle to adoption.

See https://github.com/ipfs/faq/issues for comparisons to existing systems. The plan is for IPFS to be able to transparently integrate with the existing web, e.g. https://github.com/ipfs/ipfs.js

This system looks overly complex. Too many components, too many protocols, ... It will be hard to maintain as source code, and it will be a brittle infrastructure.

This is a neat hack, but beyond that, I'm not sure what the practical usage is.

If '.authorized_keys` can be modified by the user, then one-time access is easily escalated to many-time access.

If not, they can still leave a process running on the host to obtain access later. After all, you're giving them remote code execution.

You could try to prevent them from obtaining shell access and use SSH as an encrypted transport and AuthN system. That's not really discussed in the post at all.

This post is really more like "Look ma, .authorized_keys can run commands!"


> After all, you're giving them remote code execution.

I may be wrong, but I believe ssh can be hardened more or less effectively against RCE, and still be of practical use (eg. for file uploads).

Edit: which you sort of say in your own comment - you and I can both imagine interesting uses :)


Data remanence is a really hard problem. Are you sure this lives up to your claims that "the file is completely deleted without a trace"? How are you storing them? Do they ever hit e.g. an SSD in plaintext?


Claims are irrelevant, data breaches happen all the time.

If you are concerned about the confidentiality of a file then use encryption or don't upload it to the internet.


That's not really what the confused deputy problem is about.

Instead, a confused deputy has too much authority, and is being asked to "switch hats" and pretend to have the authority of a user/caller.

Confused deputies arise because they don't have a clear picture of what the authority of the user/caller actually is, and accidentally expose some authority that the user/caller wasn't supposed to have.

Capabilities let you model this authority as a first-class principle.


In principle that's true, but let's consider something like auto run when inseting a USB or CD etc. When auto run means full user permissions to run any program that's a huge security issue. If on the other hand auto run is specifically a dialog box based on the device format that's a much smaller security issue.

The point being if you give an app permission to add a charge to a bill and only add a charge to a bill then the fact a user can increase there bill in an arbitrary fashion is still a problem, but it's a smaller one than letting them delete all charges.


The recent OS X DYLD_PRINT_TO_FILE local privilege escalation vulnerability was a classic confused deputy:



Hopefully they'll be able to address this then:


(from https://twofactorauth.org/)


Yes, addressed soon. The ideal answer for 2FA in a key-per-device app isn't really the same as the normal site + Google Authenticator / Authy kind of thing.


Their UI is a carbon copy of WhatsApp


This is one of the things I've always liked about JRuby. You can use the excellent tooling of the JVM ecosystem (e.g. YourKit, Coverity Dynamic Analyzer) to understand the behavior of your JRuby applications, and even attach directly to running production apps to debug them.

I've found tools like this essential for debugging multithreaded JRuby applications, and there's simply nothing else like them available for MRI.


Or BoringSSL: https://boringssl.googlesource.com/boringssl/


Has Google changed their stance on not wanting BoringSSL to be a replacement for OpenSSL as an open source project? https://www.imperialviolet.org/2014/06/20/boringssl.html


No, although I've been pinging Ben Laurie on having them slap version numbers on it periodically. I think that'd be nice.

The (perhaps obviously biased) TLS Under Siege talk by Google's Neel Mehta ranked BoringSSL #1 (of 2) when it came to OpenSSL forks, FWIW:



Folsom Avenue? More like Folsom Street. See the eponymous fair.

Also, this used to be Twitter HQ...



Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact