liyanchang

Hi there,

Filepicker here. Thanks for the compliment. Regarding the url not showing up immediately: We've been working hard to keep the system scaling and performant. One of those things is to have read slaves and you seem to have beaten our db propagation. I'll take a closer look at that and tune it a bit.

Super cool use of filepicker.io

Yeah. I had hoped to scope the conversation down to authentication quickly, because, yes, security means a lot of things. I clearly didn't do that well.

You distinguish between "knowing, doing, or owning" and "something you know, something you have, or something you are"? I guess there might be a slight difference between doing and something you are, but I'm not sure I see the difference?

re. Public Key Crypto. Yes. Using the public key to decrypt and the private key to encrypt is how to use Public Key for author verification and you can reverse it for encryption. One validates the author and the other protects the data.

You are right to say that a better way of saying the sentence would be: "in the case of digital signatures, the public key is used to decrypt thus everyone can decrypt."

Thanks for helping me with this. Will have to be more more clear next time I write something.

Correct. I was not careful enough with all the steps of my logic here.

Being able to encrypt the message proves that the party knows the secret, which if they are the only one who knows it, proves that they are who they say they are.

Indeed, the part about "which if they are the only one who knows it" is important. If you can't trust that, then security starts to break down.

You can sidestep it by instead trusting that they own a device that no one else has, like an one time password. Now, the statement gets a bit longer:

Being able to encrypt the message => the party knows the secret => (If you ask for multiple one, you can beter trust that)=> they have the otp => they are the only one who has it => they are who they say they are.

Hi Jerome.

Thanks for the kind words. In regards to your concern, the way we imagine this playing out is that in your app, the client asks to upload something. You use an ajax request to ask your server, with your cookies, if this is allowed. If the user is allowed, you can create a policy and sign it. You should also set the min and max size on the policy. Then you can pass this along. Thus, you know of and approve of every upload request.

Does that sound reasonable? We has also considered a post upload hook where you approve of it. However, we imagined that people would not only want to know the metadata, but maybe even the contents before approving it which seems silly to pass the entire data around.

I think what will really help is if you set up the policy as outlined above, and then, do the clean up that you mentioned when we do webhooks where you could sign up to receive a notification after every upload.

Our customers and supporters like you keep us going. Always be shipping :D

Founder here. We're excited to be able to begin offering security on Filepicker. Security in Javascript is hard because most of the possibilities (window.location, referrers) are easily bypassed. We've built this system based on a shared secret and signed polices; this method is a good start for us to help you easily enable file uploads while still protecting your storage.

We've tried to be careful and meticulous about how we approached the problem and tried to balance usability, clarity, and security. We've reached out to friends who do this kind of work at MIT, within our batch at YC, and with some beta customers.

Keeping our developers buckets safe and our user's files safe is one of our company's principles so feel free to email me at liyan@filepicker.io or post here; I'll stick around to answer questions or respond to comments.

Actually, I don't know of a single ie8 frame communication library. Most are part of bigger libraries and we were trying to keep things slim.

Thanks. The support of the community is really encouraging and keeps us going. Always be shipping. :D

Accurate. Also, the free plan is very generous at the moment as we want to reward our earliest users. A small tier might make a lot of sense later on.

Should be pretty straightforward. If it's not, shoot me an email and tell me where I messed up ;D

getFile is now replaced by the more explicit calls: pick and store.

If you're using the widget, data-fp-extension is now available.

No reason why not. Give it a spin and let us know how it goes. Also happy to help if you run into issues.

There are some files where it is not possible to write back. Local files is a good example of this. We throw a 409 HTTP error for files like that. You can of course write to the s3 copy.

Hi there.

Currently S3 is the only support backend storage. More are on the way. We take requests from customers seriously and so far we've heard rackspace, google, and dropbox. Feel free to send me an email at liyan@filepicker.io with your preference.

All files are mediated by fp.io. This lets us do interesting thing like implementing tcp/ip on tcp/ip. That is, we chunk up large files into manageable bits, retry, and reassemble on our servers.

One of the founders, just wanted to reply and say, yes, you are entirely right. We put up that endpoint for a separate purpose, didn't expect people to find it (underestimating people is clearly a bad strategy) and will be locking it down to require a password to create/find a apikey.

In general, the apikey doesn't actually provide very much security as is; by it's public by it's very nature as you have to put it client side and expose it to all your users. We've got HMAC and secret keys in the pipeline for next week :D

Ah. Sorry about the oversight. Should now work on rubygems.org

Thanks to Max Tilford who helped with the Ruby gem.

That's a good idea. We had been working under the assumption that you would want to change limits often, but I can see how a per-apikey cap would prevent gross abuse.

Hi there. Looking through server logs and all services look a-okay. Feel free to send me an email at liyan@filepicker.io and we can keep digging.

We enforce both the filetype and size limits on the server side.

We have some hostname verification and we also also adding in secret keys to sign requests so we can be even more sure.

We also have some checks that look for abnormal upload patterns that have found a couple oddities and will get better with time.

Correct. We currently do mimetype verification.

People have been asking for extensions as well, so that's on the roadmap as well.

We think that good file handling is important for the future of the web. When we first started, we weren't planning and didn't want to build a company.

However, as we went on, we kept needing server side components to make things work smoothly. For instance, we handle large files upload by chunking them up and reassembling them, retrying parts as needed. Image conversion baked in and other components in the pipeline that we want to build also require servers, something that you can't do with a plugin.

We fully support plugin developments and we fix bugs or add features as we see them.

When we first launched, we had people emailing us asking to pay and we've been growing week on week so the developer need is there. Part of me is just as surprised as you are, until I write some code dealing when multipart form uploads or box's inconsistent error codes. Then I remember.

Hi there. We think it's super useful too and therefore really excited to help developers onboard.

We've learned quite a bit about how to email developers and still continuing to learn to to best serve you all.

For instance, we started out sending html email, like we've seen other companies do. It wasn't nearly as helpful as personally emailing our new signups in plain text.

We've also experimented with newsletters like AWS does and targeted emails based on weekly actives and other metrics. In this, we're finding that the most effective emails match the relationship. If you are a current user, a short personal email works well. If you signed up a long time ago, a newsletter is relatively effective at getting someone to poke at it again, but also easy for them to ignore.

As you have discovered, we're also playing with frequency. I'd have to look it up in our db to be sure, but it looks like you happened to be in a small a/b test group that we've termed "eager". That in combination with being sent the monthly newsletter means you may have been emailed many times. I apologize for that.

We aren't big fans of spammy emails and we've been careful to watch the number of "spam reports" and been proud that it has been so low. However, it's good to hear this feedback from you so we can continue to learn.

I'm always happy to talk with customers; my email is liyan@filepicker.io.

Actually a really cool way of storing passwords in plain sight.

EDIT: Though if you were really secure, you shouldn't be typing your passwords into a third party website in plaintext. Alas, I'll have to write my own.

Saw something on HN a couple weeks ago. http://mit.edu/~georgiou/www/vi/

Ah. Sorry. I was talking about when I'm working in computer labs. Unfortunately, I can't download the client. Comment edited.

Pretty Cool. I hate having to download files from Dropbox just to upload again when I need to save. I think this might do the trick.

EDIT: I just realized that it's not clear. I do use the client and it works really well from my computer. It doesn't work very well from a computer lab.

Nice. I like how web applications get so much better once you can import your own content.

Hi Scott,

iOS video recording is ready and soon to be shipped. Send me an email for early access: liyan@filepicker.io

Man. Mentioning Heroku while in the Rackspace offices. Awkward :D