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

Beware the IP non-assert clause in AWS cloud service agreement

iam-media.com

Post reply on HN
Print view View original

51–60 of 60 posts

Re: Beware the IP non-assert clause in AWS cloud service agreement

#51

Post by acdha »

DannyBee wrote: post #40
acdha wrote: post #39

Earlier quoted context omitted.

The reason I disagree with your interpretation is due to the end of the sentence: “regarding any Service Offerings you have used”. The agreement currently has these definitions: “Service Offerings” means the Services (including associated APIs), the AWS Content, the AWS Marks, the AWS Site, and any other product or service provided by us under this Agreement. Service Offerings do not include Third Party Content. “Ser…

You can make this argument, for sure. You will almost certainly lose ;) I've seen cases where wording similar to this has been used. It was found to cover the pieces that provide the services, exactly because it is worthless as a protection otherwise. (If I can get an injunction against you stopping you from running a critical piece of your service , you won't be able to provide the service)

A lot of this would depend on the exact nature of the dispute. If this hypothetical open-source project was, say, an XML parser it'd be hard to claim that it was integral to AWS rather than an interchangeable component any more than, say, Intel hosting a microsite on S3 would give Amazon the rights to all of their processor IP. On the other hand, an AWS deployment tool or compute optimizer developed in a private beta that'd be a much harder case since Amazon could quite reasonably argue a privileged business relationship.

Right now we have one case which hasn't been settled and which apparently did involve a business partner. I think we'd need n > 1 or at least a final ruling before making the kind of sweeping claims presented originally.

Re: Beware the IP non-assert clause in AWS cloud service agreement

#52

Post by acdha »

rodgerd wrote: post #49
acdha wrote: post #15

Earlier quoted context omitted.

The entire article is FUD – the license is rather clear in indicating that as a condition of using AWS you promise not to bring IP lawsuits against Amazon, the duration bit is only too long if you don't read that clause all the way to the end, etc. This is easily explained by the attribution: “Bart Eppenauer, former chief patent counsel at Microsoft and now managing partner of law firm Shook Hardy & Bacon’s Seattle o…

An almost perfect example of an ad-hom. You've provided absolutely zero factual information about the point under discussion.

See https://news.ycombinator.com/item?id=9879188. It all comes down to whether you consider everything which has ever had a copy uploaded to AWS is included in the “each of the web services made available by us or our affiliates” definition in the license.

I don't see that term supporting the sweeping claims made in that article but you're certainly free to disagree. Ultimately I think this is somewhat moot until Amazon actually initiates action against anyone – the Appistry case was initiated by them and seems like to fail since the claims in e.g. https://www.google.com/patents/US7379959 don't appear to include anything which wasn't common HPC practice in 2002 – and we see how the courts react to it.

Re: Beware the IP non-assert clause in AWS cloud service agreement

#53

Post by nickpsecurity »

balls187 wrote: post #29
nickpsecurity wrote: post #19

Why do they call it the cloud? Because your exclusive I.P. just up and floats away one day. Stay out of the cloud. Invest in cost-efficient IT. Avoid so many issues. I predicted this specific one years back. I'm surprised I haven't heard more of it among cloud vendors.

Let's play a game. How long will it take you to get: 3 webservers 2 databases Across 2 data centers. Starting with nothing but a credit card, (and an email address).

I did high-security systems so let's modify that for what I would trust. Five servers that offload TCP/IP, a firewall, VPN, and packet/session authentication onto a PCI card with hardened RTOS (ex: Sentinel's HYDRA firewall). Let's me send sanitized data directly to application through trusted interface among other things. Further, the business's I.P. must be protected: physical separation rather than virtualization + legal protection through regulation and contracts. It will also need to run constantly, be tested periodically by intentional fail-overs, and have predictable cost despite this.

So, I spend 10-30 minutes Googling. I find Hong Kong and Switzerland are among best for regulations on data. Settle on Switzerland for various reasons. I haggle for a few hours with hosting companies to set up the deal. I have some hardware shipped 1-3 business days from other companies. We spend a few hours setting it up, doing disk encryption, configuring the guard (PCI card), setting up link encryption, and testing both sides in various ways. We save & standardize anything we figure out for scripted, instant deployment and testing when we scale out. I ship the relevant boxes to the datacenter. Meanwhile, I deploy the local boxes and thoroughly test the site.

Offshore site is probably up before the week is over. I spend a day re-running the tests. I simulate a bunch of fail-overs in various situations to make sure it works no matter what. Once I'm confident in it, we move all the relevant data into both of them. We might have already done that before shipping it if the situation allowed & then we just move what changed. We transition our domain to point at the new service. The users use it. If it fails, it fails over to the other one. The cost is likely $1,000+/mo and pretty flat except for the times where it takes the main load. Not likely to overdo my cap with only 3 webservers, though.

So, in summary, I have several secure boxes, total control of them, data at rest protection, data in transit protection, regulatory protection, acceptable network speed, predictable albeit higher cost, and long-term stability in various ways. It took around two weeks last time I did something like this. Given they usually charge for the rack, best to always ship a few extra boxes that stay off or idle: reduces impact of shipping time when boxes fail or workload increases.

What does Amazon charge and with what wait for a comparable offering with strong host, network, and I.P. protection?

Re: Beware the IP non-assert clause in AWS cloud service agreement

#54

Post by nickpsecurity »

balls187 wrote: post #44
ceejayoz wrote: post #41

Earlier quoted context omitted.

I'm going off the goalposts in your original question.

Outside of performance, how are hosted dedicated servers different than hosted VPS? Are you trading one cloud provider's feature set for another? You still outsourcing via PaaS, and not actually investing in IT.

Physical isolation, control of whole environment, and more security/reliability/predictability when these are leveraged properly. You also have less legal risk if the FBI decides to kick in that colo's doors as they have in the past and seize shared servers just because one client was on it. I doubt the quantitative risk of this is high but I like risks not existing where possible.

And you're never investing in IT if you are doing IaaS or PaaS: you're just paying a third party for a temporary good. Colocation is investing in IT because you own the equipment and what's in it. The other parts are their problem with them having a financial incentive (eg competitiveness) to improve them over time.

Cloud can shut down tomorrow and what do you get out of that? If it's my PC with my data, I can get it back from them somehow and people trying to stop that might face criminal charges. A VPS service shutting down means my system probably ceases to exist unless they have specific provisions for the situation that work during bankruptcy. You might know of them since you clearly study the cloud offerings more. I don't so I stay in a low-risk situation.

Re: Beware the IP non-assert clause in AWS cloud service agreement

#55

Post by balls187 »

nickpsecurity wrote: post #54
balls187 wrote: post #44

Earlier quoted context omitted.

Outside of performance, how are hosted dedicated servers different than hosted VPS? Are you trading one cloud provider's feature set for another? You still outsourcing via PaaS, and not actually investing in IT.

Physical isolation, control of whole environment, and more security/reliability/predictability when these are leveraged properly. You also have less legal risk if the FBI decides to kick in that colo's doors as they have in the past and seize shared servers just because one client was on it. I doubt the quantitative risk of this is high but I like risks not existing where possible. And you're never investing in IT if…

So you don't want to use AWS because the risk Amazon will shut it down tomorrow?

Re: Beware the IP non-assert clause in AWS cloud service agreement

#56

Post by balls187 »

nickpsecurity wrote: post #53
balls187 wrote: post #29

Earlier quoted context omitted.

Let's play a game. How long will it take you to get: 3 webservers 2 databases Across 2 data centers. Starting with nothing but a credit card, (and an email address).

I did high-security systems so let's modify that for what I would trust. Five servers that offload TCP/IP, a firewall, VPN, and packet/session authentication onto a PCI card with hardened RTOS (ex: Sentinel's HYDRA firewall). Let's me send sanitized data directly to application through trusted interface among other things. Further, the business's I.P. must be protected: physical separation rather than virtualization…

It's not difficult to come up with a specific set of requirements that make 3rd party hosting suboptimal or even impossible. We have customers who do not want their data to leave their data centers, so we must oblige.

For many situations, services like AWS are a god send. Resources that were typically allocated to infrastructure can now be reallocated to other areas. With a little bit of common sense hopefully areas that drive real business value.

Cloud isn't appropriate for all situations, but I assert that for many, it is, and "investing in IT" isn't a default directive.

Re: Beware the IP non-assert clause in AWS cloud service agreement

#57

Post by nickpsecurity »

balls187 wrote: post #56
nickpsecurity wrote: post #53

Earlier quoted context omitted.

I did high-security systems so let's modify that for what I would trust. Five servers that offload TCP/IP, a firewall, VPN, and packet/session authentication onto a PCI card with hardened RTOS (ex: Sentinel's HYDRA firewall). Let's me send sanitized data directly to application through trusted interface among other things. Further, the business's I.P. must be protected: physical separation rather than virtualization…

It's not difficult to come up with a specific set of requirements that make 3rd party hosting suboptimal or even impossible. We have customers who do not want their data to leave their data centers, so we must oblige. For many situations, services like AWS are a god send. Resources that were typically allocated to infrastructure can now be reallocated to other areas. With a little bit of common sense hopefully areas…

Oh, I agree with you that cloud offerings can be beneficial for a number of situations. I've strongly considered them for two areas in particular: non-confidential apps that need bandwidth that's too expensive to set up locally; one-off or temporary projects using non-confidential apps or data; backup storage of encrypted data or non-sensitive data. Hosting companies are usually good enough for most stuff but I've seen nice cost & ease of use arguments for above cases. I keep my eye open for other use cases I haven't seen.

The tech I'm most excited about are the various private cloud, open hardware, and cloud software initiatives. This stuff can bring a lot of the advantages in-house with few of the issues I gripe about. I hope to see continued innovation in that area.

Re: Beware the IP non-assert clause in AWS cloud service agreement

#58

Post by nickpsecurity »

balls187 wrote: post #55
nickpsecurity wrote: post #54

Earlier quoted context omitted.

Physical isolation, control of whole environment, and more security/reliability/predictability when these are leveraged properly. You also have less legal risk if the FBI decides to kick in that colo's doors as they have in the past and seize shared servers just because one client was on it. I doubt the quantitative risk of this is high but I like risks not existing where possible. And you're never investing in IT if…

So you don't want to use AWS because the risk Amazon will shut it down tomorrow?

I like how you ignored the most important stuff (first sentence) and a peripheral risk with precedent (second sentence) to focus on the lowest concern I had. Plus, that concern applies to more than Amazon: many vendors out there. Nice troll tactic, though.

Re: Beware the IP non-assert clause in AWS cloud service agreement

#59

Post by balls187 »

nickpsecurity wrote: post #58
balls187 wrote: post #55

Earlier quoted context omitted.

So you don't want to use AWS because the risk Amazon will shut it down tomorrow?

I like how you ignored the most important stuff (first sentence) and a peripheral risk with precedent (second sentence) to focus on the lowest concern I had. Plus, that concern applies to more than Amazon: many vendors out there. Nice troll tactic, though.

You raised the point. I just called attention to it.

Also, ad hominem.

Re: Beware the IP non-assert clause in AWS cloud service agreement

#60

Post by nickpsecurity »

balls187 wrote: post #59
nickpsecurity wrote: post #58

Earlier quoted context omitted.

I like how you ignored the most important stuff (first sentence) and a peripheral risk with precedent (second sentence) to focus on the lowest concern I had. Plus, that concern applies to more than Amazon: many vendors out there. Nice troll tactic, though.

You raised the point. I just called attention to it. Also, ad hominem.

To just that. What of the main points of dedicated vs VPS?

Physical separation from other users defeats virtualization attack surface and many, covert channels immediately. Control down to hardware layer lets you do neat improvements to performance (eg custom drivers), maintenance (eg transactional kernels), and security (eg CheriBSD on FPGA-based CHERI processor). I also pointed out you can get more predictable with the implication of using a RTOS or other deterministic software + hardware combos. Heck, might even send in AS/400's, NonStop's, and/or OpenVMS clusters on cheap Alpha/Itanium servers to get uptime you haven't seen in cloud world: 17+ years for one OpenVMS cluster.

Those are the strongest points that cloud can't touch at all so far. The cloud-style research on making something comparable with strong correctness arguments is in infancy and almost all academic R&D. Which implies things about what they're using now... Of course, the outages and papers at DEFCON etc already told us that, didn't they?

Post reply on HN