Filepicker.io (YC S12) lets content flow without worrying about bandwidth • Hacker News Board

Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth

#21

Post by JoshTriplett » Fri, Aug 17, 2012, 11:00 PM UTC

tagx wrote: post #20

JoshTriplett wrote: post #17

I like the concept of filepicker.io: a standardized widget for providing files that handles local files, remote URLs, and services people use. However, every time I read the phrase "by inserting a few lines into their source code", I think 'yeah, and one of those is a script tag pointing at a third-party server'. And sure enough, looking at the documentation, I see exactly that. I really wish web services would start…

We currently try to push people towards pointing the script tag to us so that we can more rapidly iterate on the product.

I understand the motivation; that doesn't make it acceptable for all sites, especially sites that care about minimizing their vulnerability surface. And since browsers don't currently have any security model for third-party scripts other than "full capabilities of the site that loads them", third-party scripts significantly increase the vulnerability surface of a site.

If browsers had a way to let third-party scripts run in a sandbox separate from the site, so that (for instance) filepicker.io can help with file uploads without having the full permissions of the logged-in users on every site that uses it, I'd have much less objection to third-party scripts.

Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth

#22

Post by theotherone » Sat, Aug 18, 2012, 12:51 AM UTC

JoshTriplett wrote: post #21

tagx wrote: post #20

Earlier quoted context omitted.

We currently try to push people towards pointing the script tag to us so that we can more rapidly iterate on the product.

I understand the motivation; that doesn't make it acceptable for all sites, especially sites that care about minimizing their vulnerability surface. And since browsers don't currently have any security model for third-party scripts other than "full capabilities of the site that loads them", third-party scripts significantly increase the vulnerability surface of a site. If browsers had a way to let third-party scripts…

You can run their scripts in an iframe, e.g.:

http://www.daemonology.net/blog/2012-08-13-tarsnap-credit-ca...

Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth

#23

Post by JoshTriplett » Sat, Aug 18, 2012, 1:49 AM UTC

theotherone wrote: post #22

JoshTriplett wrote: post #21

Earlier quoted context omitted.

I understand the motivation; that doesn't make it acceptable for all sites, especially sites that care about minimizing their vulnerability surface. And since browsers don't currently have any security model for third-party scripts other than "full capabilities of the site that loads them", third-party scripts significantly increase the vulnerability surface of a site. If browsers had a way to let third-party scripts…

You can run their scripts in an iframe, e.g.: http://www.daemonology.net/blog/2012-08-13-tarsnap-credit-ca...

Yeah, I normally do that when dealing with APIs that want to use third-party scripts. I'd just like to see more APIs that support running with local versions of the scripts, to avoid the need for a separate untrusted domain.

Re: Filepicker.io (YC S12) lets content flow without worrying about bandwidth

#24

Post by 13rules » Sat, Aug 18, 2012, 5:24 PM UTC

liyanchang wrote: post #5

combataircraft wrote: post #2

After I signed up to this, I started getting an e-mail everyday. All e-mails are titled like "Do you need help?" "Let's get you started with filepicker" etc etc. WTF is this? What is this rush for? I just gave a try your app, that's it. It sounded useful at first but you are losing respect by spamming.

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

Here's the email I just received when signing up (which I did right before Googling "Filepicker.io Hackernews" to find out more about HN's take on this service):

Hey - just wanted to reach out and thank you for signing up for Filepicker.io. I'm the developer assigned to help you get integrated, so let me know if you are having any trouble, want to know more, or just to say hi. It's always fun to hear from our users. -Brett van Zuiden

Simple. To the point. No pressure.

Now that I know that this was sent out manually by Brett instead of just another spammy auto-responder I like it even more.

I'd rather have a developer contact me and really want a reply rather than some HTML newsletter with tons of information and sales tactics on it.