Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tech Behind Dropbox’s New User Experience on Mobile, Part 2

tech.dropbox.com

Post reply on HN
Print view View original

31–37 of 37 posts

Re: The Tech Behind Dropbox’s New User Experience on Mobile, Part 2

#31

Post by deciplex »

timbre wrote: post #28
chrissnell wrote: post #25

Earlier quoted context omitted.

More importantly, what good is a code-signed executable when that executable can simply download a payload from the internet like this Dropbox installer does? Code signing seems like a feel-good mechanism for users. Yeah, we guarantee that the executable that you downloaded was signed by a legitimate entity but once you run it, good luck. This type of "meta installer" seems ripe for exploitation. Unscrupulous entitie…

I think the point of code signing is to ensure that the program was really written by Dropbox, so _if_ you trust Dropbox you should trust the program. That trust should definitely include both Dropbox's good intentions and their competency to prevent their payload system from being subverted.

>That trust should definitely include both Dropbox's good intentions and their competency to prevent their payload system from being subverted.

Only a fool would, after their actions of the past year, still believe this company has good intentions or that their payload system hasn't already been totally compromised (with their cooperation, no less).

Re: The Tech Behind Dropbox’s New User Experience on Mobile, Part 2

#32

Post by vdaniuk »

dang wrote: post #24
bronson wrote: post #22

Earlier quoted context omitted.

Gotta wonder about Dropbox and HN both being YC projects... Think that helps Rice be a non-issue?

Certainly not in any way that I'm aware of.

Really? Care to tell us why the okpl user is already hell banned after posting 2 comments in this thread criticizing Dropbox and Rice involment?

Re: The Tech Behind Dropbox’s New User Experience on Mobile, Part 2

#33

Post by dang »

vdaniuk wrote: post #32
dang wrote: post #24

Earlier quoted context omitted.

Certainly not in any way that I'm aware of.

Really? Care to tell us why the okpl user is already hell banned after posting 2 comments in this thread criticizing Dropbox and Rice involment?

Oh my hot-headed, un-Bayesian friends: do you really think we'd be so dumb as to ban people for criticizing Dropbox and Rice after just saying we don't do that? That would be the I Do Not Freebase Cocaine of website moderation [1].

Comments posted from Tor IP addresses by new accounts are killed automatically [2] because of past abuses by trolls. Moderators unkill these when we see them and mark the accounts legit when they're not obviously trolling. I just did that here, even though "Sounds like Condi didn't need much time" is pretty far from a quality comment.

Before you seamlessly segue into outrage at that instead, may I mention that we've got a sweet idea for dumping that practice and a truckload of others in a grand devolution of moderation powers to the community. Maybe one day we'll even get to implement it, instead of typing the same comments over and over. Lord and NSA knows it'd be one ginormous headache off our hands.

1. https://www.youtube.com/watch?v=2-ckIv1tiaU

2. https://hn.algolia.com/?q=noob+tor#!/comment/sort_by_date/pr...

Re: The Tech Behind Dropbox’s New User Experience on Mobile, Part 2

#34

Post by vdaniuk »

dang wrote: post #33
vdaniuk wrote: post #32

Earlier quoted context omitted.

Really? Care to tell us why the okpl user is already hell banned after posting 2 comments in this thread criticizing Dropbox and Rice involment?

Oh my hot-headed, un-Bayesian friends: do you really think we'd be so dumb as to ban people for criticizing Dropbox and Rice after just saying we don't do that? That would be the I Do Not Freebase Cocaine of website moderation [1]. Comments posted from Tor IP addresses by new accounts are killed automatically [2] because of past abuses by trolls. Moderators unkill these when we see them and mark the accounts legit wh…

Nope, I didn't think that you are dumb at all. However, I believe that you have a clear cut conflict of interest that you may not be able to mitigate no matter how hard you try.

http://www.ted.com/talks/dan_ariely_beware_conflicts_of_inte...

Also it would be really cool to add [tor noob] fair describing a hellban reason.

Re: The Tech Behind Dropbox’s New User Experience on Mobile, Part 2

#35

Post by mike_hearn »

chrissnell wrote: post #25
timbre wrote: post #12

I'm surprised you can sign an executable, then modify it while preserving the validity of the signature, as I always though this is exactly what code signing is meant to prevent. Can anyone who knows more about this than me (a low bar!) explain whether this is a flaw in the signing mechanism or is actually okay?

More importantly, what good is a code-signed executable when that executable can simply download a payload from the internet like this Dropbox installer does? Code signing seems like a feel-good mechanism for users. Yeah, we guarantee that the executable that you downloaded was signed by a legitimate entity but once you run it, good luck. This type of "meta installer" seems ripe for exploitation. Unscrupulous entitie…

Signing doesn't imply you are "legit", at least not much - it requires ID verification but in the absence of any hard rules about what's acceptable that's only useful in the most egregious cases, and anyway you can still run unsigned binaries.

Signing is mostly useful to help reduce anti-virus false positives. AV systems learn binary reputations just like spam filters do. It doesn't matter if the app goes off and downloads another program for this purpose - that's an implementation detail that doesn't impact whether the app is malicious or not.

Re: The Tech Behind Dropbox’s New User Experience on Mobile, Part 2

#36

Post by mike_hearn »

psychotik wrote: post #18
mwcampbell wrote: post #11

I wonder if there are any plans to rewrite the desktop client in C++ (with some Objective-C++ on Mac), presumably using the libdropbox C++ libraries that Dropbox has been developing for the mobile apps, to get the installer size down and leverage more common code across platforms.

Not currently, unfortunately. The complexity of how the Dropbox client works is enough to not pollute libdropbox with at this time. The idea here is correct though - were we to rebuild it at this time, we would look at potentially abstracting a lot things into a libdropbox-like library

I'm surprised you haven't tried harder to optimise the download size ... the blog post says it ships a nearly full Python runtime, but surely you don't actually use it all? The core interpreter is I'd think quite small and Python code should compress very well.

Re: The Tech Behind Dropbox’s New User Experience on Mobile, Part 2

#37

Post by huy2n »

shawn-butler wrote: post #21
ksb wrote: post #4

Earlier quoted context omitted.

There are a lot of places that we were seeing users drop off the radar when trying to install. Through a combination of logging analytics and user studies we figured out what the main problems were and designed this flow to solve them. (See my post from last week for more context on why we built this: https://news.ycombinator.com/item?id=8168792 )

>> Instead, we created a custom version of the signing tools which complied with the Authenticode spec (for Windows) while letting us safely modify content for each binary. Our custom tool allows us to create an unverified section of the binary in a way that is compliant with the Authenticode spec. >> Can you offer some more info on this topic in a follow-up post?

Inside the Authenticode signature, there is an area for unauthenticated attributes (e.g., if you timestamped your executable, the timestamp (PKCS#9) is stored as an unauthenticated attribute, http://blogs.technet.com/b/srd/archive/2013/12/10/ms13-098-u...). These attributes are not verified by Windows Authenticode when the executable is run. So if you can add a new unauthenticated attribute into the signature, you can make any change we want to that attribute without invalidate the signature.

In order to inject an unauthenticated attribute to the signature, you may want to use osslsigncode for signing (instead of MS signtool).

Post reply on HN