zagi
On June 23rd, we received notice from the NRA's counsel that sharethesafety.org was infringing NRA’s trademarks. The NRA demanded that we remedy the problem by removing the material. In response, we followed our standard procedures for trademark infringement notices and informed the customer immediately of the NRA’s demands. We provided more than 5 days for the customer to respond to or resolve the issue. We also spoke to the customer on several occasions to inform them that we intended to take action on the trademark claim. They chose not to remove the violating material. Accordingly, our Trust & Safety team restricted network access to their Droplet, which caused an outage to all of their user’s websites hosted on that Droplet. In less than 2 hours of the outage, the customer was able to address the trademark notice, and network access was immediately restored.
DigitalOcean followed procedures that help protect us from having to resolve what can be complicated disputes between third party rights holders and our customers regarding IP issues. In this case we should have given greater care to the customer’s voice and their right to engage in parody. In retrospect, we believe that the website identified in the NRA’s takedown notice was not a trademark infringement but was instead protected by the First Amendment. We at DigitalOcean champion freedom of speech and the free and open web.
Going forward, we will be working closely with our legal counsel to review our Trust & Safety procedures so we can make better decisions. We are committed to providing our customers with the best level of service and supporting their rights and freedoms. That is our responsibility as an infrastructure service provider and one that I take very seriously.
Sincerely,
Ben Uretsky Co-Founder & CEO
Our differentiators allow devs to get started faster, leveraging our UI and intuitive API to automate their deployments and scale with ease. Some of our larger customers have started with just a few Droplets in a stage/dev environment and have grown to thousands of production Droplets managed via their application.
We believe our platform is ideal for startups coming to market that need flexibility and ease of use when going through rapid feature iterations.. Our philosophy is that developers should be focusing on their applications, not managing their servers. This is baked into everything we do, including our straightforward pricing model, so that there’s no need to guess what your bill will be at the end of the month.
Also our price:performance ratio is outstanding and with a static pricing model it's trivial to calculate your bill and plan ahead for growth. And we provide the same on demand utility per hour pricing that allows maximum flexibility. One click snapshots, automated backups, web console, extremely friendly support, tons of documentation make DO a perfect fit for startups.
If you’d like to consider DigitalOcean for your startup just reach out to us via https://www.digitalocean.com/company/contact/sales/ and we’ll support you.
We will take the necessary steps so that if users are enabling scrub all data permanently then we will not store this temporary image and therefore destroys will be immediate and permanent.
We've now default scrub_data to ON for both web interface and API as we look at making this process permanent. Additionally, we've re-engineered the way we're provisioning disks and access to previously written data is no longer possible.
We've taken all steps in favor of security currently and will build a permanent solution that favors security and caution moving forward.
-----
All times are UTC.
Our monitoring picked up a malicious UDP traffic pattern on 2013-09-08 00:58:23. A ticket was then opened with the customer at : 2013-09-08 01:05:55 roughly 7 minutes later.
The customer informed us that it was a script that was crawling in the background.
We informed the customer that it may be a good idea to check through the virtual server to see if there were any signs of a compromise just in case.
The droplet was unlocked at this time.
A second UDP pattern was detected on 2013-09-24 12:27:09 and a ticket was opened 2013-09-24 12:27:14 to request more information from the customer.
Because this was already a second occurrence we had to do a more thorough follow up. Discussing the matter with the customer, he informed us that it was a mysql db dump script that was pushing data to dropbox.
He provided us a link to a github project that he wrote, we asked further questions. Specifically if you are writing a mysql dump remotely why are the packets being sent as UDP? Additionally if the final destination is dropbox that would be an SSL encrypted connection and again why would that transfer go over UDP?
We reviewed the code of the dump-to-cloud project and it was using the dropbox sdk, here is where the file transfer is initiated:
def upload_file(file_name)
client = DropboxClient.new(@access_token)
file = open(file_name)
puts 'Uploading file!! Please wait.'
response = client.put_file("/#{file_name}", file)
puts "uploaded:", response.inspect
end
def build_url(url, params=nil, content_server=false) # :nodoc:
port = 443
host = content_server ? Dropbox::API_CONTENT_SERVER : Dropbox::API_SERVER
versioned_url = "/#{Dropbox::API_VERSION}#{url}"
target = URI::Generic.new("https", nil, host, port, nil, versioned_url, nil, nil, nil)
#add a locale param if we have one
#initialize a params object is we don't have one
if @locale
(params ||= {})['locale']=@locale
end
if params
target.query = params.collect {|k,v|
CGI.escape(k) + "=" + CGI.escape(v)
}.join("&")
end
target.to_s
end
def do_put(url, headers=nil, body=nil) # :nodoc:
assert_authorized
uri = URI.parse(url)
do_http_with_body(uri, Net::HTTP::Put.new(uri.request_uri, headers), body)
end
Given that it was the second incident that a UDP traffic pattern was observed in less than 30 days and that the information the customer provided regarding the traffic did not match up, we made a determination that in fact it couldn't be this script that was generating the traffic.
All of this information was relayed to the customer that we did not believe that the traffic in question was related to this script because it would not rely on UDP, an insecure protocol to deliver files to a secure endpoint where data integrity was of the utmost importance.
Unfortunately, we could not unlock the account at this time because the information we received was not clear and we already had two incidents of outbound UDP traffic that appeared to be disruptive and abusive in nature totaling 1Gbps as if it were a denial of service attack, typically associated with UDP packets.
Most other providers do not restrict private network either, I'm talking about the big ones like RackSpace, Amazon and others.
What you're talking about is dedicated private VLAN's or private subnet's and that is not common especially in a cloud environment.
Cloud is defined as:
1. On demand automated provisioning 2. API interface for programatic control 3. Infinite resources from the customer's perspective 4. Virtual addresses for physical location 5. Utility measured service
This is the definition from NIST : http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145...
So in that context DigitalOcean and Amazon are both Cloud providers.
To answer your question directly, and without knowing the exact cost structure of our competitors, I would have say that we are generating less margin per unit but we are overall sustainable and growing healthy.
Yes. If you do the math they actually do break even and manage to squeeze some profit.
We are still deciding whether to roll out first some sort of block/tiered NFS storage that can be mounted or something API driven like S3, so feedback is welcome.