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

This is awesome, really want to see more of gmail become a platform.

-----


Only if its easy to migrate. Now that Elasticsearch has come a long way, I could see someone writing something similar to Graylog (which sits on top of ES, for app/ops logging data), but for email (frontend interface, ingester for mail through SMTP and new REST mail protocols).

-----


What about something like this: https://pistats.io/

This is my side project, basically I think that there is space for analytic tool on the top of email(GMail in this case). Because our emails contains much more useful data than we use. The stripe is one of examples.

-----


Without the gmail API limiting inbox search access to a particular filter (eg, "any email from uber.com"), there's no way people should be building a business this way...

opening your inbox up to random third parties is a disaster.

and frankly, I expect google to cut this form of access off, or severely limit it in the future.

-----


Well I can't other than agree with you. When I was doing research on this particular use case I was surprised that GMail APIs are open like this.

It was my priority to ensure that we are looking just for specific filter and I touch only emails from Uber and Lyft.

GMail API developers should definitely consider adding this kind of granularity to the system. I think it would allow to build much more sophisticated and trustworthy application.

-----


Yep. I tried to write my comment in a way that wasn't calling you out at all -- but really google for allowing this kind of unfettered or controlled access. :-)

I've no doubt you would do great things and get much greater adoption in a better API-enabled inbox. :-)

-----


Well, we've built the ingester/REST part and we're working on the frontend :) Our sync engine is open source: https://github.com/inboxapp/inbox

-----


iOS, Android, JS, OS X, Python, or just plain ol' HTTP :)

http://dropbox.com/developers/datastore

-----


While I can't comment on this specific case, I do want to say there is a tremendous amount of rigor (and layers of protection) to ensure the end clients are resilient to misbehaving computers and do the right thing. For example, you shouldn't have to worry about the clock being accurate as it has no bearing on the final sync state.

Just to dive in a bit for the HN crowd: We base the changes that should be applied to your Dropbox on whether the client has successfully synced the previous version of the file. The server doesn't allow the client to apply changes unless the client is fully up to date. And in the case of deletions, the desktop client is only permitted to issue deletes to files that have been successfully created on disk and then later deleted.

We also have a proper support team to catch things that fall through the cracks, and if you have issues, you should reach out to them first (and as soon as you notice; their ability to fix things becomes harder the more changes you make to your account).

Again, not commenting on the above issue, but I did want to point out that we take the integrity of your data very, very seriously.

-----


I've replied to this elsewhere, but let me reiterate here:

sean_lynch is not kidding about Dropbox's support staff. They are great, very helpful, and according to my colleague, are very serious about trying to restore everything. The issue he had was a software bug, and apparently some things are problematic to restore because of other technical reasons, but Dropbox has been very helpful.

And to make this clear - they were very helpful when this happened last week, before this thread - you don't need to write a blog post to get their help and attention.

-----


Client rigor doesn't help with server failure this severe.

The guy lost everything because a temporary team membership was revoked. And now you're coming back to talk about your rigor, and how you catch things that fall through the cracks.

This really comes off, to me at least, like LinkedIn did when after their breach and it was revealed they weren't even salting passwords, they tried to brag about their security, as a way to step around owning up.

I think you should consider this tone very carefully.

-----


Completely disagree. I found no problems with the tone here. Instead, you have an insider who shares a few implementation details to give us an idea about the depth at which they go to prevent data loss failures. I saw nothing in his post as "bragging".

The guy lost everything because a temporary team membership was revoked.

What would you like him to do, apologize profusely and robotically without knowing the details of this incident? Dropbox is a decent-sized organization and I am pretty sure they have guys already responsible for addressing specific issues like this. To expect every employee to know details of every issue seems unreasonable.

-----


> What would you like him to do, apologize

If you had stopped there, I'd have said yes.

.

> To expect every employee to know details of every issue

I ... had no such expectation?

-----


John - take a second to read the comment. He was providing feedback on a scenario in which a machine which had not been powered up in a long time apparently deleted files because they were not present. The Dropbox model does not allow this - you can only delete files that are already on your hard disk. This, is what he was trying to explain to the parent poster. His tone was entirely appropriate.

-----


He's replying to edanm, who had another problem, and not the blog author. His comment is more relevant to edanm's problem and I think it's fine.

-----


... whoooooooops.

Sorry. Thanks for explaining. `:(`

-----


I believe he was referring to the claim that switching on an old computer that hadn't been synced in awhile deleted tens of thousands of files. Not the original post.

-----


Quite right. My bad.

-----


Let's say he's using packrat in this scenario, if he chooses to restore folder X, will it restore all the files ever in this folder with packrat?

-----


Hey guys - Dropbox product manager here,

tl;dr: The scenario described by the OP is now less likely to occur. Since October, individual Dropbox users are encouraged to create separate accounts when invited to a Team and warned that Teams admins will have control over the account.

We want individual and Team Dropbox users to have the best possible experience. Some users want to migrate their personal accounts into a Team. Others are much happier with separate personal and Teams accounts. We’ve been working to make that choice much clearer for the account holder and the Teams admin.

If users do choose to merge their personal account with a Team, things become a bit tricky. Teams admins want better control of data within a Team, and users want easy access to their personal stuff, but it’s not possible for us to differentiate between Team data and personal stuff in the same account.

Here are some thoughts on the points raised by the OP:

* Better support for multiple accounts: Users can quickly switch between using personal and Teams accounts on the web today and we intend to make this better across our platforms.

* Improved messaging to Teams admins: We plan to provide better messaging to admins before disabling an account that was migrated in.

* Disabled accounts are not immediately deleted: We can work with Teams admins and users to sort out account issues and recover users’ files.

We’ve contacted the OP to help resolve his case and are sorry for any pain this caused!

-----


> Teams admins want better control of data within a Team

Some admins do I'm sure. We had to cancel Teams because of this. :(

Let me explain: most people at Steamclock sync personal stuff in their Dropbox, and we want to also share a large folder. Upgrading everybody to Teams seemed like a good idea, but the "company owns what's in your dropbox" thinking forced everybody to have two separate accounts, and the "only one account can sync to your computer at once" restriction makes one of your two Dropbox accounts fairly useless.

We can only go back to Teams is when multiple accounts can sync to one computer seamlessly. All the problems around DB for Teams (privacy and TOS issues, personal and company data getting mixed up, weird consequences when people leave the plan) are caused by the lack of multiple account sync.

That said, we'd be happy to just pay monthly for a shared folder that doesn't count against users' storage limits. In the meantime, we have the company Visa on a bunch of personal Dropbox accounts which sucks.

For personal use though Dropbox is great. Merry Chrismas!

-----


Our company would also love the option of paying for shared folder, instead of teams. We currently have teams, but it's not quite what we want, and if we temporarily want to share a folder with a client it is an big hassle.

-----


I'm considering Google Drive for company filesharing. I've always found shared folders on Dropbox are pretty awkward. Hopefully GD will be a bit easier, but only time will tell. The one thing I can be sure of is it won't need to interfere with peoples personal Dropbox accounts.

-----


I've found that shared folders mostly just don't work - others can't see the files I put in there - or at least most of them. I don't know what else I could do. (If I share one file with a direct email link generation, that works, so the files certainly are there.)

Maybe I ran into some undocumented antipiracy feature as they were self made AVCHD videos of a few minutes length.

Google drive on the other hand just works.

-----


It's probably against their TOS, but it is possible to run your personal dropbox account and a team account on the same machine. It's a pain to set up, but works well once it's running. And since you're paying for both anyway, it seems like it's at least in the spirit of the TOS.

-----


Well it works but it's like running on 3 pistons. It's a serious pain to set up, when the Dropbox client is updated you need to update the 3rd party standalone client which breaks half of the time, and you need to manually switch to either one or the other (if you have one 'official' and one 'pendrive' version). Oh and it messes with your icon overlays on Windows. Massive pain, I regret going Dropbox for Teams but I'm sort of married to our setup now. The way it works is not clear at all - I had issues similar to the OP's which required support to resolve.

-----


Hey, OP here -

First of all, in Dropbox's defense, I probably did not give you guys enough time to respond before going public with this (also, living in Israel I sometimes forget that Sunday is a weekend for most people in the world). I apologize for that. I am not a journalist/blogger, and I was driven more by my emotions than by "journalistic ethics" (?) when submitting to HN.

Second, according to your support email (updated the original post with it) it looks like my particular case is going to be resolved. However, it does not seem to resolve the malicious use case I hinted at (and which people on HN did not seem to want to discuss that much): Give someone a terabyte as a gift, and then delete their account. In fact, from the support email it seems like it's even worse: The support staff will need the team admin to approve the account re-enabling. In the malicious case, the admin would not approve.

[EDIT: Recalled a third point I wanted to make.] Third, regarding what you said "it's not possible for us to differentiate between Team data and personal stuff in the same account". I simply don't understand why this is true. Maybe the general case is not like mine, but my Dropbox folder just has a bunch of subfolders, exactly one of which belongs to the "team". Is it possible that certain folders have mixed personal-and-team content? How does that even work? If you saw my account (I don't know if you can... but your code can) it would be blatantly obvious which folders (all but one) are personal.

-----


When migrating an account into a team, the account and all the data in the account becomes managed by the Teams admin (shared or otherwise). Letting an existing account to join a team lets us smoothly support the situation where a user has created a Dropbox account separately and needs to move that account into the team.

For most cases though, users should create a new account for the team. The Dropbox for Teams sign up process guides users towards creating a new account when joining a team for this reason.

-----


From your reply, it sounds much worse than I thought. I had no idea my team admin could see all my data until now!

If joining a team account changed after your October changes, then maybe it's okay now. But I included in my post the email I got for joining the team, and it makes no mention of the fact that the team admin now owns my data. One would think this email should be less bland and more cautioning.

-----


> ... individual Dropbox users are encouraged to create separate accounts ...

If only your software actually worked in that scenario. Every single piece of your software is hard wired to believe you only have exactly one account. For example the Windows, Linux, Mac, Android and iOS clients, as well as the website. To see your other account involves logouts and logging back in again having to enter the other account email and password (not saved).

> Users can quickly switch between using personal and Teams accounts on the web today

Huh, the only thing that works for me is to logout and log back in again. I have a personal paid account and a separate team account. What I would expect is how google do it - the account dropdown having your other logged in accounts available for selection.

-----


Dropbox engineer here. There should be a drop-down item to switch accounts: https://www.dropboxatwork.com/2012/12/easily-switch-between-...

The first time you select 'Switch Accounts' you will be able to log in your personal account. After that, you will be able to switch accounts without having to type the other username every time.

-----


I had checked before posting and there was no such option. I did manage to make it appear in the end but it required logging out as my personal user and then logging as the team account and then logging in as personal again.

Why not just make 'Switch Account' always be present rather than having one blessed starting point account? The wording also implies this won't work if you have two team accounts.

-----


my wording is my own; i have not checked exactly what the restrictions on this feature are.

-----


I meant the wording on the website. If I log out, then login to the team account and then choose "Switch Accounts" the resulting page says "Sign in to your personal account". That is what implies to me that it would have issues if I had two team accounts.

-----


You should really consider redesigning this feature. Having "Teams" control all the personal accounts of their employees means none of my companies can use it. So, we're stuck with folder sharing for the foreseeable future.

I'd expect Teams to work like folder sharing, but with the storage not counting towards the individual account space limits.

-----


Our company has a corporate account but none of the employees want to use it for this reason. If we could make "corporate" folders and share them using the same account, but not lose the storage credit, that would rock.

-----


I'm curious, why don't the Company doesn't just share the folders with the Individual and revoke access to the shared folder when the Individual leaves?

You won't have to combine to the Personal / Team together.

And make it so that the shared folders doesn't count towards the Individual's account space limit.

Bam. Problem solved (?)

-----


We were on Dropbox for Teams but these kinds of problems forced us to go back to the personal accounts plus shared folders model.

The problem is, our shared folders DO count towards the individuals' space limits. So, we have seven people's personal Dropbox accounts on the company credit card. Not convinced this will scale.

-----


That's what we do. What are the advantages of the Team plan over this?

-----


A lot more storage and some more features.

-----


Like what features?

It seems its a can of worms right now and the suitable fix seems to be removing the storage limit on shared folders (shared to those individuals who do not own the original folders being shared).

-----


Is it possible to run two instances of the Dropbox client on a machine, one for each account? If yes, ok, no big deal. If not... what a PITA.

-----


Yes, although there's not an officially supported method:

http://www.dropboxwiki.com/Multiple_Instances_On_Unix

http://theterran.com/blog/2012/6/14/use-two-dropbox-accounts...

The second link is basically a modification of the method from the first link, and has been working well for me for a few weeks. One caveat is that any apps which make us of dropbox for syncing (e.g. 1Password) seem to automatically use the first/normal dropbox instance, which can't be changed.

-----


* Teams admins want better control of data within a Team, and users want easy access to their personal stuff, but it’s not possible for us to differentiate between Team data and personal stuff in the same account.*

Of course it's possible. You just don't want to put the work in it make it happen.

-----


Out of pure curiosity, why is it that the OP's original requests for help were ignored? Is it recommended that to get better support you should make a public case of it? A lot of larger companies seem to operate this way.

-----


Honestly, OP didn't give them enough time to respond. OP said that it was only yesterday that the team revoked his account. I could imagine that given it was both a sunday and a day or two before Christmas (depending on where you are) that the Dropbox support probably wasn't fully staffed.

-----


Aha - thanks, I didn't realize how recent the request was.

-----


tl;dr: The scenario described by the OP is now less likely to occur. Since October, individual Dropbox users are encouraged to create separate accounts when invited to a Team and warned that Teams admins will have control over the account.

I am going to be blunt here and just say it: the 'Team admins will have control over the account' part is completely stupid and not well thought through.

Becoming part of a team should be about sharing data. Not about handing over accounts.

-----


> * Better support for multiple accounts: Users can quickly switch between using personal and Teams accounts on the web today and we intend to make this better across our platforms.

On Linux, I've gone out of my way to install the (pseudo-unsupported?) daemon headless under multiple users to get concurrent access to work and person accounts; would like to see this improve (while dealing with the "I have ten free accounts" and other pathological cases).

-----


One easy way to solve this problem would be to do it like how Github distinguish between personal and organization repositories (with a context switcher dropdown).

On the backend, this would involve converting all current accounts into "sub-accounts". Joining a team would basically create a brand new sub-account under the same login.

-----


How hard can it be? At least you could restore all the files that were present on the user's account before it was made into a Team account... If courts can do it in case of a divorce, I guess a technology startup could as well.

-----


Everything is easy if someone else has to do it, isn't it.

-----


It will be as easy as making a folder called TEAM (or the team name) in the user account when he joins a team and automatically delet that folder when he is out from the team

-----


less likely

Well, I guess that's a start...

-----


People should not need to switch accounts.

IMHO Dropbox should not count Team shared files onto each member. Let the admin pay the bills.

-----


> it’s not possible for us to differentiate between Team data and personal stuff in the same account.

I am really curious about this statement. Maybe you can explain a little further. I am thinking about something like this:

    git add .
    git commit -am "Account state prior to joining teams"
    
    git branch personal
    git branch team_x
    git branch team_y
    
    git checkout team_x
    git commit -am "Initial commit for team_x"
    git commit -am "Did some more work for team_x"
    
    git checkout team_y
    git commit -am "Initial commit for team_y"
    git commit -am "Did some more work for team_y"
    
    git checkout personal
    git commit -am "Added Dad folder for xmas pictures"
When someone leaves a team:

    git branch -D team_x
    git branch -D team_y
    
Obviously merging branches would not be allowed.

In other words, I am thinking that most of the heavy lifting required to manage the on-boarding and off-boarding of someone from teams, even multiple teams, is already done for your in the form of Git. Wrap it with some business-specific code and it could be really slick. Of course, that alone could be a six month project.

Anyhow, just seat-of-the-pants without much thought applied to it. Curious to hear your opinion.

-----


Sounds like you ought to figure out why people want to merge their personal accounts, and then implement that functionality in a way that doesn't require merging such that it's not possible to reverse the change afterwards.

This may be way harder than I make it sound, since I don't know about the hurdles this would face. But that does seem like the place to aim.

-----


> Disabled accounts are not immediately deleted: We can work with Teams admins and users to sort out account issues and recover users’ files.

Wait a sec, does this mean when I delete my files they are ... not being deleted?

> We’ve contacted the OP to help resolve his case and are sorry for any pain this caused!

Great, good for him. So basically next time when I or others have problems with Dropbox, post a rant about it and pray it will get to #1 spot on HN to get customer support response? Ok, dully noted, thanks.

-----


Wait a sec, does this mean when I delete my files they are ... not being deleted?

This is true of almost every service on the internet. If it wasn't, whenever the only disk that had your account on it failed you would be absolutely livid about the fact that they never made any backups. (It is generally infeasible to purge backups of any deleted data, because they're stored in compressed blobs.)

-----


> This is true of almost every service on the internet

can you back this claim up somehow? I recall Flicker losing bunch of profiles (photos) permanently because once its deleted, well its deleted.

What you are confusing is planned backups, in case of hard drive failure, and the fact that customer executed delete command and consent to get those files deleted. two different things.

-----


can you back this claim up somehow?

I don't know where to start collecting anecdotes and appeals to authority, but I shouldn't need to. See my parenthetical above--how would you go about digging through terabytes of compressed backups to find every instance of a single file and its corresponding database record so that you could delete it? It would be possible to engineer such a system, but in most cases it would be an extremely poor allocation of resources.

If you upload something to the internet and you want to be the only person who is ever able to pull it back out, you should encrypt it.

-----


as I recall they managed to restore most of those photos.

-----


Ability to recover deleted files for up to 30 days is a prominently advertised feature of Dropbox. It would be unthinkable for them not to allow that, given how easily files can be lost by users who aren't familiar with how syncing works.

Look at all of the people who consider Dropbox a "backup" service, and imagine being the guy on the phone who has to explain that yes, actually, deleting a file on one system is supposed to delete it from all other clients.

I will say that this is a really interesting story, in that it illustrates how Dropbox, like all of the similar services on the market, is handy for many use cases but ideal for almost none. A service that's basically a "scriptable" Dropbox would be pretty compelling.

-----


I appreciate that they don't delete files because this lets them offer some convenient features related to backup, account history and uploading. The biggest reason not to delete concerns sharing. If I share a folder, share a file, then a user deletes the file from the folder, I want to be able to retrieve it as I've sometimes had to do. I don't want someone else to be able to irretrievably destroy it on the Dropbox server.

However, I agree that users should be able to delete a file from Dropbox' servers if the user, since the beginning of the file's life on Dropbox, had the only account possessing the file on Dropbox. The procedure should involve a lot of red warning buttons and re-entering of the account password. I think this should be possible because some files really are too sensitive to be shared, and I can see how they might accidentally be pasted or dropped into the Dropbox folder and instantly duplicated. If the file is dropped into a shared folder, then there is probably nothing to be done because obtaining multiple permissions to permanently delete a file would be so complex socially.

-----


I've got all the parts of a good postmortem post floating around in my head. Unfortunately, it's probably going to have to wait a few weeks while we tackle our new product.

-----


There was no link to any blog (or any kind of site to see a postmortem for that matter). Any chance you could send a followup to the goodbye email when you finally get around to writing something?

I'm very interested in reading it and I have this fear that it'll slip between my frequent HN checking.

-----


We're not staying in the same space so I don't think we'll want to spam our current set of beta testers with our new product. If you track me down on Twitter though (sean_lynch), I'll send you a heads up when we launch.

-----


Was afraid that might be the case. That's an ok compromise though. Following.

-----


Is your new product still part of your YC experience?

-----


It is indeed. One of the amazing things about the YC program is the amount of support we received from the partners and other companies when we were facing the decision.

-----


Yeah, it sucks :( If there's anything we can do to help transfer your data back, please let us know.

-----


Both an Android and an iPhone versions are looking for beta testers :)

-----


Well I won't have a phone for another few months, but if you're still looking for testers then, I would be happy to help out.

And if you're already done testing, then I'll download the app anyways!

-----


We're both very big Billmonk fans, but unfortunately the application hasn't seen very much improvement since it was acquired a few years ago. Splitterbug helps you solve the same problem using some very cool tech that Billmonk didn't have access to (native iPhone apps/Android/Facebook graph/etc).

Our primary focus right now is building an app solves the problem of splitting bills and tracking debts. We've got a few ideas about monetization, but if we can't build a useful app first, that discussion is moot.

-----


What's the very cool tech? Why does an app like this require particularly new or innovative technology?

-----


Thanks for answering on it. I wasn't ever a big Billmonk user, but I can see your point about opportunity being present when acquired apps stagnate.

Again, good luck with it. I look forward to seeing where you take it.

-----


Good eye :) The web version lacks a lot of optimizations we were able to add on the client though. If you're excited to start using the thing now, shoot me an email at support [at] splitterbug.com and let me know what device flavor you prefer (iPhone/Android). I'll get you set up.

-----


Thanks -- I got in on the iPhone beta and it looks good so far. I'm excited to see this service become public -- I think it could be super useful.

-----


We have both iPhone and Android clients and we're looking for beta testers for both.

-----


I'm also happy to beta test the iPhone app.

I currently use something called Share-a-Bill quite heavily, but it has some shortcomings. I've also just moved into an apartment with 2 friends, so we're looking for a better application for sharing bills.

Email: edanm@btlms.com

-----


I'd be happy to help beta test for iOS. Email in profile.

-----

More

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

Search: