Dropbox discontinuing HTML rendering / Public Folder

Just got this load of cheerful dumped into my inbox. Given that Hype can use Dropbox’s public folder to export and preview files, well … ouch.


Hi Warren,

We’re writing to let you know that we’ll be discontinuing the ability to render HTML content in-browser via shared links or Public Folder. If you’re using Dropbox shared links to host HTML files for a website, the content will no longer display in-browser.

Please note that this change will take effect for your account on October 3, 2016, and only impacts how shared files are displayed on the web. Your files will remain safe in Dropbox.

Thanks for being a loyal Dropbox user.

  • The Dropbox Team

i got the same email - I’m guessing this is really bad news for Hype previewing - this is a HUGE feature for me, i hope hype can come up with an alternative or workaround - unless one (just as seamless) already exists and i don’t know about it

One option might be to set up FTP access to a web server, if you have one, and mount that on your desktop as a remote volume, then export-to-folder there. But yes, the convenience of having a “live” Dropbox push for previewing files is significant, and unfortunately it looks like the clock is ticking on that one.

Ideally the Hype crew have known about this longer than the rest of us, and have something in the works. It would be no fun at all for them to have learned about the change in the same way as everyone else…

yeah i agree - the hype team are a bunch of genii so i’m sure they’ll find a way :slight_smile: Maybe integration with another cloud API…Onedrive, Google Drive perhaps? Also i wonder why Dropbox is removing this? I wager its tied to the hack perhaps?

I’m thinking security in general. When you enable HTML, you also enable a buttload of scripting extensions and backend possibilities, and that becomes another set (subset) of problems. Every time you discover a new leak and patch it, there’s another six that surface. I know of many web-based form entry systems that will not allow you to type in scripting or file-control characters precisely because of that. It’s brute-force security to keep crackers from entering scripts right in the comment section, which presumably could then be parsed and executed inadvertently.

Bandwidth might also be a concern. If users are using their DB accounts as “free” webservers, you know there’ll be some high-volume things happening there, including photo and video access.

The “hack” really wasn’t, per se; as I understand it, it’s actually fallout from the LinkedIn password crack of 2012. It was LI that compromised some 60-odd million passwords, and Dropbox users were a subset of that, if they’d connected DB to LI.

Now, connecting to Google might be a viable alternative, ayup.

Google Drive for web hosting isn’t an option either:

“You can host webpages with Google Drive until August 31, 2016. After that, googledrive.com/host/ID will no longer work.”

I think using a Bucket on Google Cloud Platform would be a good alternative for hosting and file storage.

I use Machighway web server FTP and have for 5 years, the only reason I still have any Dropbox account at all is that there are some files that I have been to lazy to move. Nothing important, no Hype files.

Maybe a direct to FTP server might be a solution. Instead of where it has an option to link to Dropbox in prefs maybe there could be a place there to input your own FTP server and have the same kind of function to automagically upload there instead?

3 Likes

I once tried to use dropbox to serve some pages for examples for here. But ran into a too many downloads issue within seconds.
Drop boxes algorithms were screwing things up, but what it did show was that dropbox had no intention of this being use a complete webspace/server.

I am in all favour if this being replaced with a built in ftp connection to user defined ftp servers.

2 Likes

Ayup, setting up FTP/sFTP would probably be the least fraught alternative, particularly since so many sites-in-progress have staging sandboxes already for code testing, and the likelihood is that most if not all web developers will have zero trouble getting something like that going, if it’s not already there.

The writing has been on the wall for a while, with our understanding that this would be discontinued as part of the Dropbox v1 API discontinuation in a year on June 28 2017. What is surprising to us was the timing of this feature being different and communicated with such little notice. I'm in communication with Dropbox about a possible extension, but I think this is unlikely.

I'm sorry that our users have to hear about this from Dropbox and not us!

Thanks to everyone for their feedback on what might meet their needs - very useful! I'm definitely a fan of trying to keep a free or low-cost method to very quickly share and preview Hype documents. I've been investigating Neocities, FTP/SFTP upload, and the possibility of a Tumult-created service for this. Each of course have their own tradeoffs (and to be honest, Dropbox also was a mixed bag!)

2 Likes

It doesn’t look, so far, like there’s a lot of clamor or alarum, no panic on the streets of London or anywhere else. It’s interesting that they’ve accelerated the Grand Plug-Pull, though.

I can’t honestly see what might be gained by going to another third-party hosting service, either, even one you guys pay for yourselves. I’d place long, long odds on proximally every Hype user having a website, and being able to handle their own FTP/sFTP setup. Personally, that’s the option I’d prefer anyway.

The only place it might cause problems is with employees at large companies who are stuck behind firewalls or net nannies. Their IT policy might be of the type that greenlights Dropbox, but not FTP.

1 Like

Yep this is what I would go for.

I’ve got a sort of elaborate setup, but it seems to be working.

I’ve been using Github Pages to host projects.

You have to take the extra steps to fully export the project and push it to github, bit it would be awesome if that got baked into Hype.

1 Like

Overall you are correct, but there's some users (such as myself honestly!) that need to share documents quickly and don't want to deal with the hassle of FTP setup. There's another very large set of users that do have a webhost or CMS (like wordpress.org) but it does not support arbitrary FTP uploading and instead need to link to a document via iframe.

Ah, yeah, fair points.

Well, for the former, packaging into a zip file might be one way to go, unless the aim is to not share the full HTML document collection. Or maybe just exporting to a widget. (I’ve been using that lately myself, for an iBooks title I’m working on.) The trouble there is that a widget needs to be installed into a framework, if I understand them correctly, such as OSX’s dashboard…

For the latter, linking via iframe might be one reason Dropbox is pulling the plug on HTML support. I expect that’s a pretty hefty bandwidth drain, cumulatively. But I have no useful suggestion for how to respond to it in a way that’s both quick and relatively painless.

I wouldn't give long odds. Whatever the limitations of a third party solution at least there would be a clear path (via the Hype interface) giving users the ability to post their projects without extra rigamarole. For those that have their own set-ups so much to their advantage; but why put a de facto limit on simplicity?

You bring up an excellent point, Jim.

If anyone really likes having dropbox be their file store, I did run across this article:

(Of course since all are paid options, I don’t think this will be a path forward for an easy share mechanism in Hype)

1 Like

If you already have a membership with Adobe, you can use the businesscatalyst built in inside Muse for make your own FTP sites:

Example:
http://gsgpetroleum.businesscatalyst.com/hype/WEBGSG2016/index.html