nautilus-dropbox forbids dropbox's non-free binaries to replace themselves by properly installing dropbox system-wide

Hello David,

this bug is in total contradiction to what you and Rian assured me by private mail: “In any case, I want to stress that you can distribute this package however you like for the Debian community. The Debian community has their own way of thinking about problems and we just differ here.”

Ubuntu is certainly a part of the bigger Debian community. If you want to escalate this bug further (e.g. the Ubuntu Technical Committee), then please share the conversations we had about the auto-update feature and the various compromises that I proposed you. In the mean time, I'm tagging this as wontfix since I have been doing the work to package nautilus-dropbox for Debian and Ubuntu.

I'm certainly looking forward to bring your package and the one I provide in Debian/Ubuntu closer. It's definitely possible to have the same package with just some default configuratioon altered. Alas you did not seem interested in pursuing this.

Cheers,
Raphaël Hertzog.

Hi Raphael,

I wasn't privy to the private discussion but as a Dropbox user I am why wondering why we would turn off auto update when the software itself depends on being updated on the user's machine by upstream. For example what happens in the case of a security update?

So, this package appears to download binary bits directly from Dropbox upon installation. Those binary bits will never get updated again in the future once the package is installed, which would prevent them from getting possible security fixes once this package is installed.

From a security point of vue, I don't think this package is suitable for our users, and may be hard to maintain if the binary bits change in the future.

I would recommend working with Dropbox to get a properly maintained package in the partner archive.

Installing binaries in ~/.dropbox-dist/ of each user and letting any user process update them there is certainly not a good choice from a security point of view (and it's certainly not in line with the Debian policy). Having a single way to install the binary system-wide and having that mechanism verify the signature provided by Dropbox is the correct choice.

Marc, I tried to work with dropbox but they are not interested to improve the situation any further. They do control the software that gets installed and they could teach that software to force an upgrade in case of security issue (i.e. simply call "dropbox update" the wrapper script that installs the software) but for various reasons, they have not accepted to do this.

For the record, just like any wrapper, the user can force an update/re-installation at any point of time with "dropbox update".

Raphael,

I don't understand how working around upstream's updater is good for users here. I don't /want/ to remember to type "dropbox update", they already do that for me. Why do we even need a wrapper if Dropbox is accepting responsibility for the user's installation?

The user has already made the choice to use Dropbox, they're not going to care about if the package complies with Debian policy, they assume it acts like it does on other platforms, that it's zero touch and autoupdated for them.

Hi Raphaël,

At Jorge's request, I've had a look at the nautilus-dropbox package in precise. There seem to be two main differences between the upstream package and the one included in precise.

 - The precise package stores dropboxd in a central location instead of keeping one copy per user. This is in principle the preferred way to do so in the distribution, but has the side effect that users who don't have admin privileges are unable to ever get updates. Unless an admin user runs 'dropbox update' for them, or there is an upgrade of the package, the user will then be using an out of date and possibly insecure version of dropboxd.

 - The precise package drops the maintainer script code to automatically add an apt sources entry for the dropbox upstream repository. This is obviously the correct thing to do for a distro package; packages in the distro distribution channel should not be automatically enabling third-party repositories, and while it's understandable that third parties would do this in their own .debs because it's the least-bad available option for ensuring software updates for the user, it does distinctly undermine the security model of the distribution (cf. the session at the UDS discussing this and related issues). Nevertheless, the result of not enabling this repository is that users of the distribution package only get updates when a distro maintainer uploads them. That leaves the users dependent on Ubuntu for security updates to the package as well, and there has been no committment in Ubuntu to *provide* those security updates in a timely fashion. (Indeed, it's not clear that such updates would comply with our policies for such.)

As a result, despite the changes to the package all being sensible things to do on their own, the net effect is that the user experience when using the distro package is worse than if they had downloaded it from the dropbox website. Since the reasons for this are rooted in fairly fundamental policies of the archive, I think this is pretty clearly a case where Ubuntu should blacklist the nautilus-dropbox package in favor of the upstream one.

Do you see any reason this should not be the case?

Hi,

On Wed, 07 Mar 2012, Steve Langasek wrote:
> - The precise package stores dropboxd in a central location instead of
> keeping one copy per user. This is in principle the preferred way to do
> so in the distribution, but has the side effect that users who don't
> have admin privileges are unable to ever get updates. Unless an admin
> user runs 'dropbox update' for them, or there is an upgrade of the
> package, the user will then be using an out of date and possibly
> insecure version of dropboxd.

I fail to see why it's important that users who don't have admin
privileges can't update dropbox, they also can't update any other
packages that might have security issues.

Also I modified dropbox update to request admin privileges via policy kit.

> - The precise package drops the maintainer script code to automatically
> add an apt sources entry for the dropbox upstream repository. This is
> obviously the correct thing to do for a distro package; packages in the
> distro distribution channel should not be automatically enabling third-
> party repositories, and while it's understandable that third parties
> would do this in their own .debs because it's the least-bad available
> option for ensuring software updates for the user, it does distinctly
> undermine the security model of the distribution (cf. the session at the
> UDS discussing this and related issues). Nevertheless, the result of
> not enabling this repository is that users of the distribution package
> only get updates when a distro maintainer uploads them. That leaves the
> users dependent on Ubuntu for security updates to the package as well,
> and there has been no committment in Ubuntu to *provide* those security
> updates in a timely fashion. (Indeed, it's not clear that such updates
> would comply with our policies for such.)

This part is completely irrelevant. The package only contains a nautilus
wrapper and not dropboxd which is the daemon that Dropbox would
like to have auto-updated.

When dropbox (the company) wants to push an update, it's dropboxd that
replaces itself in ~/.dropboxd/. They do not push a new version of
nautilus-dropbox in their APT repository.

I have tried to convince upstream to modify dropboxd to execute
"dropbox update" (with a prior display of an explanation) instead
but they were not ready to do this. :-(

> As a result, despite the changes to the package all being sensible
> things to do on their own, the net effect is that the user experience
> when using the distro package is worse than if they had downloaded it
> from the dropbox website. Since the reasons for this are rooted in
> fairly fundamental policies of the archive, I think this is pretty
> clearly a case where Ubuntu should blacklist the nautilus-dropbox
> package in favor of the upstream one.

What would this mean? The Ubuntu repository would not contain
nautilus-dropbox at all? Or the upstream packages would replace it?

> Do you see any reason this should not be the case?

What about users who would like to use a policy compliant package?

It seems also weird to blacklist a package that a community member
was actively maintaining.

Anyway, I have an alternative suggestion f...

On Tue, 06 Mar 2012, Jorge O. Castro wrote:
> Why do we even need a wrapper if Dropbox is
> accepting responsibility for the user's installation?

Even the upstream package is only a wrapper. They do not provide a package
that directly contains their dropboxd daemon.

> The user has already made the choice to use Dropbox, they're not going
> to care about if the package complies with Debian policy, they assume it
> acts like it does on other platforms, that it's zero touch and
> autoupdated for them.

I'm a user too and I don't agree with this. I do care about Dropbox being
properly integrated on my system without violating Debian's policy
when that is reasonably possible.

Otherwise I would have stopped maintaining this package once upstream
started providing Debian packages.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/

I also want to highlight that Dropbox (the company) provides a single package and that it doesn't work across all Ubuntu releases (due to the different GNOME versions and changes at the nautilus level). So there's real value in having our own nautilus-dropbox that works with each corresponding Ubuntu release.

Hey guys,
We provide a single package because that's the easiest thing for our users. They don't have to think about which version of Ubuntu is running or anything else. We have fixed the package to work from all version from 8.04 to 11.10 even through different versions of GNOME. Obviously 12.04 isn't working right now because we're still waiting on what will happen here.
Regarding Raphael's solution of using a crontab. We've already got a working auto-update system that works when you use our package. Why build another solution?
And as I said before, we don't mind that Raphael made his package and is distributing it. The only thing we care is that when users install Ubuntu and go to their shell and type dropbox, they get a prompt telling them to apt-get install nautilus-dropbox and when they do that they get a un-upgradeable version of dropbox, that will have all of the support issues I mentioned above. Basically all we're asking is that Ubuntu not include this Debian package in its defaults.
Thanks,
David

I don't see what's different in nautilus-dropbox compared to other packages. It seems like upstream wants to open a potential security hole in our Ubuntu systems. I think people should already know Ubuntu packages are supported by the Ubuntu community, not by upstream, so where's the confussion. I've chosen to trust the Ubuntu community, not Dropbox, I wouldn't expect Ubuntu packages to be updated by upstream authors. What's different here?

> I've chosen to trust the Ubuntu community, not Dropbox, I wouldn't expect
> Ubuntu packages to be updated by upstream authors. What's different here?

I'm sorry, but if you believe that having dropbox packages in the Ubuntu
archive insulates you from having to trust dropbox, then you are very much
mistaken.

This sort of confusion is a pretty strong argument for not carrying
divergent packages in Ubuntu, IMHO...

Ok, I see your point now, thanks. I know the non-free binaries are already a security problem, but I think it's even riskier having non-free software that installs binaries in our home and upgrades itself without notice. I would expect packagers to make it the least insecure possible, lessenning the dangers, that's what I'd like to expect from a distro that provides non-free software.

Should I know that multiverse is as dangerous as using third party repositories?

Is there a final decision on this? What are the next steps?

Hi. I'm just a random Ubuntu user who is also a DropBox user. I intsalled the package from the Ubuntu repo, got the "running from an unsupported location" message, and found this bug report.

As I read this thread, the Dropbox company position is that it's better not to have the package in the Ubuntu repo at all than to have the install result in the present user experience.

Speaking as a user, I agree with Dropbox. If the desired installation and upgrade behavior can not be managed in a reasonable way based on Ubuntu's repo policies and security/upgrade expectations, and especially if an install results in an error message every time you boot up, then it does more harm than good to have the package in the Ubuntu-managed repo in the first place.

Just another random Ubuntu user here and I agree with Allan. I like DropBox and use it on five devices, but since the update issue above hasn't been sorted out it really doesn't belong in the repos. Keeping broken software in the software center is silly. Let the DropBox company continue handle the burden of advertising the .deb package and updates as they desire. I was surprised to find it in the Software Center in the first place since it isn't open source software.

I'm a Dropbox user. Dropbox worked fine for me under 11.10; on this machine it does not work under 12.04. I tried the procedure recommended by Dropbox:

cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | tar xzf -
~/.dropbox-dist/dropboxd

And I soon got this:

pwa@pwa-K60IJ:~$ dropbox start -i
Starting Dropbox...
Dropbox is the easiest way to share and store your files online. Want to learn more? Head to http://www.dropbox.com/

Error: Trouble connecting to Dropbox servers. Maybe your internet connection is down, or you need to set your http_proxy environment variable
The installation of Dropbox failed.

Is this a Ubuntu bug or a Dropbox bug? I have no way of knowing, and from the earlier comments in this bug I conclude that there's no agreement about that.

Meanwhile I struggle.

I forgot to mention: on a different machine, also running 12.04, I see that the "dropbox" package is installed and the "nautilus-dropbox" package is not installed. And on that machine, Dropbox works. However, I cannot determine where that "dropbox" package came from.

Update: I've gotten Dropbox working by downloading it from the website and using the Deb installer (which, conveniently, is offered by default).

So the situation is this, it seems. There are three possible ways to install Dropbox:

1. Download it from the Dropbox website and install it with the Deb installer.
2. Follow the procedure recommended on the Dropbox website.
3. Install nautilus-dropbox using Synaptic or another Ubuntu package installer.

All three of these are plausible, but only the first one yields a working Dropbox (for me, at least).

On Wed, 08 Aug 2012, Paul Abrahams wrote:
> pwa@pwa-K60IJ:~$ dropbox start -i
> Starting Dropbox...
> Dropbox is the easiest way to share and store your files online. Want to learn more? Head to http://www.dropbox.com/
>
>
> Error: Trouble connecting to Dropbox servers. Maybe your internet connection is down, or you need to set your http_proxy environment variable
> The installation of Dropbox failed.
>
> Is this a Ubuntu bug or a Dropbox bug? I have no way of knowing, and
> from the earlier comments in this bug I conclude that there's no
> agreement about that.

Do you know if you need a proxy to access the web? Please paste me the
output of "env" on your shell and of "dpkg -l nautilus-dropbox".

(for amd64, for i386 it should be "lnx.x86" at the end of the URL)

But I'm interested to learn why the download would not work for you.
Do you get a window asking your for admin privileges when running
the above command?

It might be related to the https redirection since the wrapper doesn't
copy over the https_proxy variable. I prepared an updated package
for this. The package is attached (built for Ubuntu LTS amd64 and i386),
please try it out and report back.

Cheers,

PS: In any case, the dropbox wrapper in nautilus-dropbox wants to install the
files in /var/lib/dropbox/ so the suggested wget should really be:

cd /var/lib/dropbox && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | sudo tar xzf -

But please don't do this for now. Please try the updated packages instead.
--
Raphaël Hertzog ◈ Debian Developer

Do you like what I do? Support my free software work on Debian and Ubuntu:
→ http://raphaelhertzog.com/support-my-work/

To clarify: the download does work and the proxy complaint is almost certainly bogus. I'm not using a proxy (systems settings confirms that). Here's the output you asked for:

pwa@pwa-K60IJ:~$ env
SSH_AGENT_PID=23805
KDE_MULTIHEAD=false
DM_CONTROL=/var/run/xdmctl
SHELL=/bin/bash
TERM=xterm
XDG_SESSION_COOKIE=d0cccc58e087a2964ecd082800000006-1344377500.331880-1152933625
XDM_MANAGED=method=classic
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/pwa/.gtkrc-2.0:/home/pwa/.gtkrc-2.0-kde4:/home/pwa/.kde/share/config/gtkrc-2.0
KONSOLE_DBUS_SERVICE=:1.110
KONSOLE_PROFILE_NAME=Shell
GS_LIB=/home/pwa/.fonts
GTK_RC_FILES=/etc/gtk/gtkrc:/home/pwa/.gtkrc:/home/pwa/.kde/share/config/gtkrc
WINDOWID=31457298
SHELL_SESSION_ID=08ecaf02cb364000b61f34b6c35093d6
GTK_MODULES=canberra-gtk-module:canberra-gtk-module
KDE_FULL_SESSION=true
USER=pwa
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
SSH_AUTH_SOCK=/tmp/ssh-tRbDQJW23752/agent.23752
SESSION_MANAGER=local/pwa-K60IJ:@/tmp/.ICE-unix/23890,unix/pwa-K60IJ:/tmp/.ICE-unix/23890
DEFAULTS_PATH=/usr/share/gconf/kde-plasma.default.path
XDG_CONFIG_DIRS=/etc/xdg/xdg-kde-plasma:/etc/xdg
DESKTOP_SESSION=kde-plasma
PATH=/home/pwa/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
PWD=/home/pwa
KONSOLE_DBUS_WINDOW=/Windows/1
KDE_SESSION_UID=1001
LANG=en_US.UTF-8
MANDATORY_PATH=/usr/share/gconf/kde-plasma.mandatory.path
UBUNTU_MENUPROXY=libappmenu.so
KONSOLE_DBUS_SESSION=/Sessions/3
HOME=/home/pwa
COLORFGBG=0;15
SHLVL=1
KDE_SESSION_VERSION=4
LANGUAGE=
XCURSOR_THEME=oxy-white
LOGNAME=pwa
XDG_DATA_DIRS=/usr/share/kde-plasma:/usr/local/share/:/usr/share/
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-rUH0LwhNtu,guid=25f60c2352f766d31bd0a5ce000065e2
LESSOPEN=| /usr/bin/lesspipe %s
WINDOWPATH=7
PROFILEHOME=
DISPLAY=:0
QT_PLUGIN_PATH=/home/pwa/.kde/lib/kde4/plugins/:/usr/lib/kde4/plugins/
LESSCLOSE=/usr/bin/lesspipe %s %s
_=/usr/bin/env
OLDPWD=/home/pwa/.local/share/local...

An afterthought: the most appropriate place for me to deal with my Dropbox problems would have been the Dropbox forums, but unfortunately they are down for renovation.

Another afterthought: I tried installing the new package you provided. It seems to work, although it needs to be started with "dropbox -i start", not "dropboxd". I need to do some other fiddling before I can be entirely sure.

Update: the dropboxd command from the new package doesn't work after all. It simply hangs.

Update: dropboxd does work after all. The problem was that I hadn't uninstalled my previous working version of Dropbox.

Hi Raphael, thanks for bringing us system-wide installation of dropbox!

But isn't the description of nautilus-dropbox, "Dropbox integration for Nautilus", misleading? Somehow, "Downloads non-free binary blob from somewhere" could be mentioned.

I think the downloader functionality should be split out into dropbox-installer, as in http://packages.ubuntu.com/precise-updates/flashplugin-installer . And if dropbox releases a new version, an update for the package could be published that re-downloads the binary (as in flashplugin-installer).

At the moment I'm really not sure what to do in an LTSP install. The weekly cronjob update is no good because it will sooner-or-later install a version that does not work and I won't even notice until I get bug reports from users.

Letting each user download 32MB to his home (the Dropbox, Inc solution) also seems somewhat soboptimal, but the real problem is that window that pops up on first start (screenshot attaced).

    "In oder to use Dropbox, you must download the proprietary daemon."

User: "Aha okay. Where can I download it? Should I head to http://www.dropbox.com/ ? What happens if I press ok?"
BTW what is the "Don't show this again" for? If the user ticks this box it's game over for dropbox for ever?

Lol I just tested the nautilus-dropbox solution for a new LTSP user. Screenshot shows what I got.
@David Euresti: So the result of the fruitless discussion is that you included a "unsupported location" nag screen ( see also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679963 ).

Hi,

On Mon, 20 Aug 2012, Jakob Unterwurzacher wrote:
> But isn't the description of nautilus-dropbox, "Dropbox integration for
> Nautilus", misleading? Somehow, "Downloads non-free binary blob from
> somewhere" could be mentioned.

It's in the full description:

Description: Dropbox integration for Nautilus
 Nautilus Dropbox is an extension that integrates the Dropbox web service with
 your GNOME Desktop.
 .
 Installing this package will download the proprietary dropbox binary
 from dropbox.com.

> I think the downloader functionality should be split out into dropbox-
> installer, as in http://packages.ubuntu.com/precise-updates/flashplugin-
> installer . And if dropbox releases a new version, an update for the
> package could be published that re-downloads the binary (as in
> flashplugin-installer).

I don't see any benefit here.

> At the moment I'm really not sure what to do in an LTSP install. The
> weekly cronjob update is no good because it will sooner-or-later install
> a version that does not work and I won't even notice until I get bug
> reports from users.

The binaries downloaded bundle most of the required libraries, so it's
unlikely to break unless we get some major update like a libc7.

> Letting each user download 32MB to his home (the Dropbox, Inc solution)
> also seems somewhat soboptimal, but the real problem is that window that
> pops up on first start (screenshot attaced).
>
> "In oder to use Dropbox, you must download the proprietary daemon."

You don't get that if the download during the initiall install worked.

> BTW what is the "Don't show this again" for? If the user ticks this box it's
> game over for dropbox for ever?

Good question. :-)

On Mon, 20 Aug 2012, Jakob Unterwurzacher wrote:
> Lol I just tested the nautilus-dropbox solution for a new LTSP user.
> Screenshot shows what I got. @David Euresti: So the result of the
> fruitless discussion is that you included a "unsupported location" nag
> screen ( see also
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679963 ).

Yes. During my discussions with them, they argued that they did not want
to implement a special call to "dropbox update" to invite Linux users
to upgrade because they want to keep the same behaviour across all users.

And now they prove that it's perfectly doable to implement a small special
case for Linux users...

Needless to say that this behaviour really pissed me off.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Do you like what I do? Support my free software work on Debian and Ubuntu:
→ http://raphaelhertzog.com/support-my-work/

I got the messags saying that Dropbox was running from an unsupported location after installed nautilus-dropbox from ubuntu repository. I clicked "Don't ask again" and it seems that Dropbox was running as intended. I just want to make sure Dropbox really works properly if I ignored the message.

To be honest I prefer installing all software from ubuntu repository in order to keep the consistency of package management system. So even if I know Dropox officially provides deb installer and newer releases，I don't want to choose it.

On 23/10/12 21:05, Alfred Zhu wrote:
> I got the messags saying that Dropbox was running from an unsupported
> location after installed nautilus-dropbox from ubuntu repository. I
> clicked "Don't ask again" and it seems that Dropbox was running as
> intended. I just want to make sure Dropbox really works properly if I
> ignored the message.
>
> To be honest I prefer installing all software from ubuntu repository in
> order to keep the consistency of package management system. So even if I
> know Dropox officially provides deb installer and newer releases，I don't
> want to choose it.
>
Don't worry, the Dropbox package from the repositories is OK. Choosing
"Don't Ask Again" will install the Dropbox client universally for the
whole system as this is in conformity with the Ubuntu package
management, as opposed to the upstream package which installs the client
individually per user.

Auto-update is disabled. If you want to have the latest version; when a
new one comes out from here https://www.dropbox.com/release_notes
<https://www.dropbox.com/release_notes>, just type in a terminal or run
a command (Alt+F2) "gksudo dropbox update", without the quotes, then
enter your password and that's it.

As a "normal user" ans usually happy camper, I came across this report when wondering what was the difference between installing Dropbox from Ubuntu repositories (nautilus-dropbox package) than from the package available on Dropbox website/repository.

Now that I understand, I do share many of the point of views expressed here: if, for whatever reasons, Ubuntu can't provide a reliable Dropbox package with auto-updating, then it should abstain from it and let Dropbox (the company) do the work itself. No need to dive into obscure philosophical/ethical consideration here, the solution is just not to provide an unreliable package.

On a side note: providing the Skype package in the partner repositories is nice, as this package will presumably auto-update Skype shortly when a new versions appears (or at least, upon upgrading Ubuntu to a newer version). If the same can't be done for Dropbox, then it doesn't make sense to go this route.

Even though this is an old discussion, I would still like to add a few things to it. I'm a systems administrator and I believe most of my kind would agree with me when I say that installing binaries in a user folder is bad practice in general. I work in an organization where Dropbox is used by a lot of people on both Windows and Linux systems, mostly because it's a convenient way for people to share files with other people outside of the organisation.

It's really annoying to find that there are still software developers who think they have the right to work around well established policies that are there for the stablility, security and managability of computer systems, with the argument that it's more convenient for unpriveleged users to be able to update the software on their own. I'm glad to see a Debian maintainer take action against this and come up with a solution that works, shame the Dropbox people feel a need to work against him or at least not cooperate.

I tried to make the same case almost a year ago on https://forums.dropbox.com/topic.php?id=54778 but that was for the Windows installer of Dropbox. It seems the same goes for the Linux client. In our organisation we try to keep the crap that gets into the users' space to a minimum, wether it's their Linux homedirectory or their Windows profile. That is for the benefit of both our users and our sysadmins.

I'm actually wondering why Dropbox isn't bundeling their binaries in their .deb package in the first place. They already have a repository in place to do this, and that way upgrading is done automatically with the regular system updates. This would be easier to maintain for everyone, because in a professional organisation updated should be automated anyway with no need for intervention from regular users, while at home the primary user of any machine would be the administrator of that machine anyway.

In any case, Raphaël keep up the good work and I hope the Dropbox people will be more forthcoming with a solution soon.