[former-aws]

Cannot up vote this enough. During my time both at Retail and AWS it was perfectly normal to trawl production customer data and come up with ideas to launch competing products. Prices were always set lower or free offering justified as data-driven and customer obsession. I hated the gas lighting their customers and left in disgust of the company and its leadership which encourages that behavior.

[munk-a]

I know it's hard to do when you're making good money and would be going against co-workers.

But, if you see something, say something. This crap continues because there are too many folks that are happy to help support immoral business practices for some extra scratch. This isn't all on you in particular but when google folks started raising hell about Chinese censorship the company was forced to move. We all have the power to withdraw consent over how our labour will be used and, as software developers, we've got a strong enough employment market that we have real power to help make companies behave better - power that folks working in the warehouse are absolutely deprived of.

[burtonator]

I mean the problem is corruption begets corruption. They WANT do to these things because you're going to get a massive bonus when the product you 'invented' does well because you stole the idea from an Amazon customer.

Amazon needs to be properly taxed so that this crap doesn't happen anymore.

The idea that they shouldn't pay taxes simply because they're large should absolutely enrage everyone.

[conductr]

This topic has nothing to do with taxes. They will always be trying to increase their bottom line whether that line is before or after taxes makes no difference. What is needed is a whistleblower. Not just a “when I worked for Amazon we did bad stuff”. We need that person to contact startup X, whose software and customer list was compromised. And then, this is key, share knowledge and proof of these accusations. Hell, do so through an attorney where you negotiate x% of resulting litigation proceeds of you’re worried about your privacy and financial situation. I’m pretty sure this would play out badly for Amazon in court.

[exy]

Here's the thing it's not just Amazon they're just the biggest fish in the manufacturing pond in NA. Who's fault is it exactly? The system is designed to MAKE SHARKS LIKE THIS.

You're a fish, eat other fish and evolve into a shark, you eat other sharks and become a whale shark, you start eating everything and then become godzilla.

A whistle blower isn't going to fix this. This is the system. The system MAKES godzilla sharks like this.

Oh yeah sure a whistle blower will do what? Get amazon fined for how much? Then they just change tactics. Outsource. Make agreements and partnerships and farm out doing the same thing just with different proxies. I mean come on man this is a company that can buy other countries.

And let's not forget Microsoft was pulling the same shit until they got put under the same charges and then all of a sudden years later after Bill got tired of stabilizing his empire and making sure it would live without him he became a saint all of a sudden. Cuz like yeah if I was richer than 99% of the people on the planet yeah I could start being a nicer person and shit too.

[munk-a]

The current zeitgiest is that taxes are Unamerican and tax evasion is American. Until that is fixed proposing solving problems with taxes is a pretty empty approach since people are happy to elect tax evaders to the highest office in the country and joyfully utilize services that are offered by companies that are famous for their tax evasion (Apple, Amazon, everyone honestly).

I think taxes aren't really a solution anyways - fines might be but taxes would hurt honest players just as much as dishonest ones. What they did is (AFAIK) illegal and needs to be punished, if it isn't then there is no incentive for them to correct their action.

[ampersandy]

Who is saying they shouldn't be taxed because they are large? There's no 'large company' tax break.

https://www.cnbc.com/2019/04/03/why-amazon-paid-no-federal-i...

There's specific credits/exemptions in the tax code that they are able to exploit (and perhaps they can only exploit some of them _because_ they are a big company), but it really isn't about their size.

[devin]

What you say is openly contradictory. They receive certain exemptions due to their size, but their tax bill has nothing to do with their size. ???

[ampersandy]

No, I said quite clearly there are no exemptions due to their size. There's a difference between an exemption for companies with N+ employees and tax credits/exemptions you can capitalize on because you are a company that makes billions of dollars and can afford to take on different behaviors to take advantage of them. That's not the same thing at all.

[jjeaff]

I see what you are saying, but I think that if things exist in the tax code that can only be taken advantage of by large companies, it is -effectively- the same thing as a big company exemption.

[cycomanic]

Nobody said that there is a tax exemption for companies over N+ employees. The OP said that amazon doesn't have to pay taxes.

Can we please stop arguing like influencing is only true if it is done in the most direct way (similar to the quid pro quo debate). Obviously if big company lobbyists try to get tax law in their favour they are not pushing for "please write a law which exempts companies over N employees from taxes." They push for laws that sound innocent but only they will be able to take advantage of, just like it is at the moment. The outcome is still the same they pay less or zero taxes.

[rckoepke]

What types of AWS data would be trawled? Are we talking about data inside S3 buckets, database schemas, particular architecure styles, the fact that a product is consuming {x, y, z} amounts of cloud resources, or simply "spending $m / year" in gross?

[redredrobot]

I worked in an area where it is really hard to figure out exactly what workloads were being run and where it would have been extremely useful to know even basic things like CPU utilization patterns, network throughput patterns, etc for a specific customer.

We had access to absolutely none of that information. We flew blind, relying entirely on the fact that we gave our customers enough hand-holding support that they would willingly volunteer information about their workloads so we could help them optimize it/save money.

No one even attempted to get more detailed customer information AFAIK because it would have been extremely against company culture. That isn't Earning Trust or having Customer Obsession. The idea of reading data in someone's S3 bucket or inspecting what is happening inside of someone's EC2 instance in any way was unthinkable. Amazon is huge and imperfect, but from what I saw AWS takes data privacy extremely seriously.

[whoisjuan]

I can confidently tell you that Amazon's employees cannot see customers data inside S3 buckets or EC2 instances. They are extremely serious about that stuff since they know that will erode their customer's confidence.

But there's probably other superficial business data that's helpful to evaluate that.

[TimSchumann]

> I can confidently tell you that Amazon's employees cannot see customers data inside S3 buckets or EC2 instances.

From a technical standpoint, that statement is false.

Every employee might not have the credentials to, but for AWS to function as it does, SOMEONE inside the company has to have those credentials.

If you change 'cannot' to 'don't', well then we've just gotta take you at your word, which is where we started anyway.

[Aperocky]

> SOMEONE

That's not necessary unless SOMEONE includes computer programs.

Yes, when things go very seriously wrong, I believe AWS can have literal people override that permission, which will leave a mile long audit trail and likely accompanied by an internet scale outage.

[TimSchumann]

The point I’m trying to get across is that the default viewpoint of many knowledgeable developers I know is ‘Of course AWS can’t see inside my EC2 instance because X’ — where X is some magical technology that doesn't exist.

I don’t want to devolve into audit logs and permissions and multi user key signing and wether they actually do or not.

The statement that ‘they can’t’ is 100% false, full stop. That’s all I’m trying to get across.

[cameronh90]

The technology to do it does exist likely on hardware you possess. The trusted computed platform lets you build a signed OS that encrypts its data using keys on the TPM. Using this, you could build an S3 implementation that stores customer data, but doesn’t let you access it.

It’s probably not a good idea to make a system with no human fallback, but it IS possible with current, non-magic technology.

[count]

Except they get audited by 3rd parties on statements like that, and have controls tested. It's not like they're just ... digital ocean or somebody.

[jasonjayr]

Do you have evidence of this claim re DO?

I worked with a DO on an technical issue, and they were steadfastly against me granting them temporary access to our servers even though it would have made the issue easier to diagnose. Cloud provider that verifiably get caught doing this will quickly lose the trust of all their large customers

[webo]

DO doesn't have a great track record for customer trust. I run personal workload but couldn't recommend it over AWS to a larger company.

  - https://news.ycombinator.com/item?id=23117660
  - https://news.ycombinator.com/item?id=20064169

[discodave]

The audits check that controls are in place, not that the controls are technically bulletproof or people-proof.

Source: Worked at AWS for several years including working on systems that had audit requirements for [secret project where I could not know the name of the customer because I don't have TOP SECRET security clearance].

[count]

Nobody said things were perfect or bullet proof. But that they are there, and it's not just 'trust us'. And it's not just single technical controls - the control regimes include mitigations against technical failure and requirements for ways to catch collusion and actions taken outside of authority.

And there are lots of things that many folks at the big cloud providers don't know about their internal threat management and monitoring. Source: Audited most of them for that customer you weren't allowed to know the name of. :)

[whoisjuan]

Yeah. True. I guess what I meant is that just a handful of employees have access to that and they need to have legitimate reasons.

[count]

Also, it is possible to build systems such that, no, there isn't a 'root' or 'unlimited permission' or whatever. Or that there is, but it's a multi-person credential.

This is one area where AWS takes things MUCH more seriously than it's competition, and they don't talk about it enough publicly.

[ibejoeb]

The critical factor here is whether there are controls in place to prevent it. Sure, somebody probably could, but what to what lengths must that person go to do it, and what happens when it is discovered? Most things are not technically impossible, after all.

[throwawaybkhv]

for its faults aws takes data privacy super serious. if you are in support you cant even see attachments customers put on cases without providing auditable justification

and you def cant see in s3 buckets or instances. hell if a customer sends you a link to an object in their s3 youre not supposed to open it

[discodave]

Some group of people on the S3 team likely have root access to the machines where your objects are stored. If you don't have encryption turned on...

[mcqueenjordan]

You keep making factually incorrect statements. I'm not going to go into detail to refute them, because I don't feel comfortable sharing internal design details and security mechanisms, but your comfort in confidently asserting falsehoods is disconcerting, to say the least.

[Gibbon1]

I find it funny that none of the people here arguing really understand what data is important from a strategic sales point from view and what's not. The customers databases and other crap they store on the cloud. Not really important.

The raw billing information, oh motherfucking yes.

[kerng]

This is incorrect, at least from a logical POV and why it's hard to trust what cloud vendors say. A statement like this is either naive (most likely) or actively attempting to mislead.

Technically, its absolutely possible. Most likely you'll just need a support ticket or bug, and then you can troll around as engineer.

Also, security teams also usually have access to stuff when things get interesting.

Better to say that access is strictly on a case by case basis and monitored thoroughly.

Ideally customer is notified each time it happens - that would be cool, but likely technically not possible since data ends up in so many systems (like logs, SIEM, telemetry, debug files, backups, data scientist desktops,....)

[donavanm]

> Ideally customer is notified each time it happens - that would be cool, but likely technically not possible

You're underestimating the investments that AWS (and Amazon at large) make in to security, confidentiality, and auditing. You're also missing a fundamental implication of building AWS on AWS primitives.

As a relevant example there is only one AWS IAM and one CloudTrail. It's a core tenant of AWS IAM to put that control and root of trust in to the customers control. That means when developer support is helping with your ticket they do so via your accounts AWSServiceRoleForSupport role. That means you can control whether that role exists, which principals can assume it, the capabilities it has, and you can see those same API calls in your CloudTrail logs. Although it would make support difficult you're welcome to delete that service linked role and prevent support.amazonaws.com from assuming said role in your account.

https://docs.aws.amazon.com/awssupport/latest/user/using-ser...

[kerng]

Yes, those are great features for compliance. But you seem to believe that your AWS instance is indeed yours. IAM is a concept built on top of lower level primitives that you do not control, but Amazon does.

I'm not talking about Amazon SSH into your EC2 instance - but of course they can do that also - at will, without you authorizing it.

Lower level disks, logs, hypervisor, telemetry, etc.. are accessible beyond your control.

[donavanm]

> IAM is a concept built on top of lower level primitives that you do not control, but Amazon does.

Of course there are lower level primitives. And if the public documentation and observed behavior is insufficient I encourage you to inquire more about the various compliance, certification, and third party auditing programs in place https://aws.amazon.com/compliance/programs/. However at some point this approaches solipsism and I can’t prove a negative in a HN thread.

> I'm not talking about Amazon SSH into your EC2 instance - but of course they can do that also - at will, without you authorizing it.

No. Extraordinary claims need evidence. Either you have serious non public information counter to many AWS statements ... or you misunderstand some fundamentals of SSH and public key cryptography.

> Lower level disks, logs, hypervisor, telemetry, etc.. are accessible beyond your control

I would encourage you to read the AWS data privacy statements https://aws.amazon.com/compliance/data-privacy-faq/. Particularly the definitions of “customer content” and the “shared responsibility model.”

[ikiris]

This really isn't how modern security works at most cloud companies. Even if you have root class credentials or the ability to escalate to them in some way (and that's a big if by itself), its a LOT of steps to get access to customer data, almost always involving broken glass, many protection layers, and often requires cooperation of multiple other root level people/credentials from completely different teams.

Depending on how the infrastructure is built, or what the particular service set up, it may not even be possible to gain access to specific data without extraordinary means, possibly involving replacing physical hardware.

[whoisjuan]

I already corrected my statement in another reply. You're right. I said probably only a handful of people can access customer data to do their job. I personally never met one. The goal of my comment was to illustrate that in my experience handling customer data there was a big deal. It's not like something you can casually query to see if a particular customer has a good business or not.

[kaesar14]

Amazon is a massive company. How can you know this with confidence? Are you in the C-Suite?

[whoisjuan]

It’s the thing they tell you the most when you work there. Like in a a obnoxious way. Most infosec training is about that.

If someone has access to customer’s data for their work they have to do a bunch of extra training and do other stuff. Potentially sign some things and there’s probably a different way to authenticate. I really don’t know because I never had to do that and nobody I knew had that type of access but I heard when you do you have to put with more things.

[kaesar14]

But then what about other commenters saying that this is exactly what their sectors of the company do? Do you think it's impossible that a massive company like Amazon that controls an ungodly amount of the Internet would break those rules? Especially when the government of their home country hasn't pursued an antitrust case in God knows how long

[notatoad]

>But then what about other commenters saying that this is exactly what their sectors of the company do?

i don't see anybody claiming that amazon is harvesting data from inside their customer's infrastructure. amazon has a lot of data that's "amazon's data" that would tell them about businesses that are operating on AWS that might be ripe for competition.

For example, they know what your AWS bill is, and how it's been trending. If you pay a huge bandwidth bill and it goes up 50% each month, they know you've got a business model that's working and that they can undercut you on one of your big expenses.

[losteric]

Amazon does not trawl customer data.

However, metrics like AMI popularity is Amazon's data... and that definitely informs first-class AWS product development. Once the company identifies a business opportunity, different teams often investigate "build" and "buy" options simultaneously.

Same goes for retail - Amazon works backwards from high-margin categories to identify opportunities, then pursues investment in existing brands versus spinning up products under the company brands.

This all feels very monopolistic to me, but regardless it's worlds apart from the accusation of stealing private information through faux investment offerings.

[whoisjuan]

Yeah I don’t know. It’s possible that there’s some evil stuff happening. I’m just relating my experience as a pawn employee. They parrot this incessantly.

[KorfmannArno]

1. Did you work on a team at Amazon in the likes of what user throwaway_aws mentioned?

2. What measures that you know of is Amazon implementing to make sure no employees across all teams are having access to said resources?

[whoisjuan]

As I said below this is something that they will talk a about like every freaking day. They talk about customer’s data as the most important thing to take care of.

Basically is preferable to get a bullet in the head than to ever reveal or tamper with customer’s data.

I cannot answer your question about who has access or not but I’m telling you what’s the culture when it comes to customer’s data.

At the end of the day I was just another IC doing menial work so probably not a good reference, but that was my experience

[luizfelberti]

I'm sorry but what you just said is patently false:

https://www.bloomberg.com/news/articles/2019-07-29/capital-o...

Quote:

Capital One Financial Corp. said data from about 100 million people in the U.S. was illegally accessed after prosecutors accused a Seattle woman identified by Amazon.com Inc. as one of its former cloud service employees of breaking into the bank’s server.

While the complaint doesn’t identify the cloud provider that stored the allegedly stolen data, the charging papers mention information stored in S3, a reference to Simple Storage Service, Amazon Web Services’ popular data storage software.

[jburgess777]

My reading of this is that the ex-employee used the knowledge about EC2 instance credentials being accessible as a path to gain unauthorized access to data. In theory anyone could have exploited this vulnerability even if they had never worked for Amazon. They never say that Amazon employees had privileged credentaials that would give them unauthorized access to customer data.

AWS customers that want to avoid this vulnerability should disable IMDSv1 as per https://aws.amazon.com/blogs/security/defense-in-depth-open-...

[donavanm]

There was zero inside knowledge and they were an ex employee at all times relevant to the incident.

The EC2 instance credentials via the metadata url is public documented functionality. Its how things like the SDK “just work.”

The S3 bucket policy, instance creds, and (inferred) overly permissive IAM policy is all public documented functionality. This looks like a simple case of an initial intrusion being escalated via permissive configuration and controls. There would be no story if the suspect had not been employed by AWS in the past.

Disclaimer: Im a Principal jn AWS but have no direct or inside knowledge of this incident. Everything I know or have stated here is public record (eg the indictment) or public AWS docs.

[didibus]

That leak didn't involve any insider access. So it doesn't prove that employees get access to the S3 data.

[bg24]

Can speak for AWS. Only the later. Basically the usage information for cloud resources. This constitutes the foundation for billing. BTW, this is be true for any cloud, any SAAS.

There is no way an employee can look into customer data. There's enough trail inside AWS to prove that without any doubt.

[KorfmannArno]

What are the measures being implemented to ensure that no employee can look into customer's data?

[yandie]

I used to work for AWS and had to deep dive into IAM to build a feature.

Basically Everytime you touch AWS your session is tagged with your credentials and has a unique ID. So everything downstream you touch has your session ID associated with it.

Now say somebody from Redshift wants to access the customer's data. They will then need to access to the encryption key in KMS. The trail will be there since KMS lives in the customer's account (you can audit your own access). And for production services, human actors cannot access these keys - only production credentials can. An engineer who can log into a prod host in theory can grab the temporary credentials there but it expires in 15 minutes so your trail will be rather visible. Also access to prod host has a high bar - only senior people can do it.

Now in theory somebody can coordinate with a malicious user in KMS team - but the bar is high. Also the actual master key never leaves the premise for KMS so your attack surface is very limited.

Of course there are some core teams like IAM and KMS where if they become vulnerable the whole thing falls apart. But that's a big stretch for those systems since they are the core to the business.

[jacquesm]

This is about as bad a revelation as the original one. So the encryption key is fair game without explicit customer approval?

[dodobirdlord]

I think perhaps you misunderstand the architecture of KMS. KMS master keys are used to remotely decrypt the symmetric encryption keys for encrypted data that are stored alongside the encrypted data. KMS master keys don't ever leave the KMS servers themselves, and servers can't be accessed directly by anyone. AFAIK they don't have open ports except for handling production traffic and are hardened against opening a shell. An engineer on a different team with access to a host running a customer workload could potentially run off with a temporary customer credential being used by the customer workload, which they could then use to call KMS to decrypt encryption tokens for as long as the credential lasted. But they couldn't get at the KMS key itself or retain access past the expiration of the stolen credential, and all of the aforementioned audit logs would report all of the activity of the stolen credential.

[acruns]

I can tell you generally how this works in Azure, I can't speak for AWS, but unless a customer is using BYOK for encryption of their data, I can't imagine how AWS c o u l d n ' t be capable of accessing data, and even then I wouldn't gurantee they couldn't still get your data. In Azure (as of a couple years ago), in order to access a customer's tenant it required VP approval, the support engineer was granted access for a specific amount of time, and typically only to specific services, all with the customers knowledge beforehand. It may have changed since the last time I had to go through this process and was restricted to blue badge employees. I have worked support cases since then and the support engineer would not even do a log me in/WebEx, etc session as they said they were not allowed to see the portal. But it may have been that they were not a blue badge and/or bcuz the customer was a critical infrastructure customer.

In order for AWS to comply with LEO's they must have some way of accessing data, that is NOT to say they do this for business purposes.

[dodobirdlord]

At the end of the day there's obviously nothing other than remotely storing your keys that will keep your data opaque. Even supposing that the IAM team doesn't have a way to forge a valid credential if they need to, the confirm/deny response of their service to authorization checks is the source-of-truth for whether a credential is valid, and they could update their service endpoint to affirm bad credentials if they wanted to. Presumably for law enforcement purposes they have a way to forge a credential that doesn't show up in audit logs.

[dodobirdlord]

Other than the data each service actually retains themselves (i.e. the Lambda service themselves store your Lambda Functions because they need to execute them) customer data is generally stored encrypted at rest with KMS keys belonging to the customer (or sometimes managed by the storage team). It wouldn't be possible to peer into unencrypted data without persuading the KMS API to authenticate your access to the key. Presumably this capability exists, because otherwise Amazon wouldn't be able to honor warrants for customer data, but the premise that KMS is handing out decryption tokens for customer data for the benefit of Amazon Retail's business analysts is pretty silly.

And of course, you're always vulnerable to someone with access to the physical host of an EC2 instance where your workload is running. Only GCP AFAIK offers an encrypted-in-processing compute service, and it's like a week old.

https://cloud.google.com/blog/products/identity-security/int...

[ShroudedNight]

Given how granular AWS billing data is, I would expect the odds to be fairly good that it alone is sufficient to make a good analysis for which third-party offerings are compelling markets. Then AWS takes their execution advantage, along with things like the lower friction that arises from first-party integration with IAM and billing, as well as not having to pay retail for the cloud resources, and it becomes very difficult to retain a moat unless you have a paradigm or perspective that is both critical to succeeding and is also incompatible with AWS culture.

[QuinnyPig]

You’re correct. It’s disturbingly detailed as far as what it reveals about architecture.

[kapilvt]

aggregated api usage stats, api client headers is often enough to identify competitor products and their traction, and is non-sensitive, coupled with account id to customers.

[anonymousDan]

Do you have to use AWS to sell on Amazon?

[kapilvt]

no

[httpsterio]

Considering that OP created this account today and that they're admitting to what would be a felony and against Amazon's own privacy policy, I doubt this statement is true.

Even if the customer had a misconfigured S3 bucket that was exposed to the public, it would still constitute as accessing customer data you're not meant to see.

As other users have provided insight on, everything you do as an Amazon employee basically leaves a trail with your employee ID, even if you had access to private information (which you wouldn't basically because it's locked behind several layers of security). Fireable and sueable offense which Amazon would definitely not allow, let alone endorse.

[swiftcoder]

> everything you do as an Amazon employee basically leaves a trail with your employee ID

That might be true in retail, but it wasn't anywhere close to true in AWS. When I left most engineers still had SSH access to the production hosts (and a not-insignificant portion of operations relied on that fact).

[mcqueenjordan]

Leaving aside the question of what SSH access looks like today versus whenever you left...

There are many easy mechanisms to audit and monitor SSH sessions. So... no?

[swiftcoder]

They weren't audited at the time (nor was there a standardised way of doing so).

[tekknik]

Definitely not defending parent here, but in this day in age many people create burner accounts specifically to avoid tying any statements back to them. It’s pretty acceptable practice to create burner accounts on HN. That said, I agree, I doubt any of these claims are true.

[thoraway1010]

This frankly doesn't match my experience and I have to say I find it unlikely.

Before going into our AWS production S3 buckets, looking at our databases for customer lists AWS seems to be pretty careful to get an OK.

Now we are being told that production customer data was normal to trawl? How in the HELL are they passing all their certs with all production data so wide open. I do customer managed keys - I mean, this is a HUGE backdoor.

Either Amazon is lying about AWS security (and has fooled a bunch of others) or routinely trawling AWS customer production workloads for data is a false statement.

[starfallg]

My understanding is that Customer Managed CMK in KMS only means that the customer has control over the key operations - like rotation, key policies, IAM policies, etc. AWS still has actual control over the KMS system and full access to the HSM.

[donor20]

Even under this definition how in the HELL are they "routinely" trawling our production data secured by these keys. I mean, does not one think that is rediculous?

This isn't amazon billing data etc (obviously I expect they analyze that carefully given they bring in billions from billing). To ROUTINELY go through AWS customer production datasets is beyond all reason.

[p0rkbelly]

No. AWS has no access to your material, nor is there a code path where they could get it.

[thoraway1010]

We just had someone claiming to work for amazon who said it was "routine" to "trawl" through CUSTOMER production data.

How are they trawling through all our buckets and databases without codepaths for access?

Again, they aren't talking about amazon data (ie, billing, support inquiries etc). They are talking about customer production data.

[flak48]

I would assume the comment you're replying to means things like resource usage patterns and costs to estimate a client's profits for example. Rather than reading actual data from S3 or a database.

[daiwaka]

As I said to throwaway -- if you are of the mind to share, i am here to listen. my email is [e-mail]

[neilk]

Come on NYTimes! You can do better than email.

Don't ask someone to admit to felonies over email. Tech employers have a LOT of power to investigate their employees' digital behavior.

How about this instead: https://www.nytimes.com/tips

[julianeon]

I want to be careful here, as I respect that you worked at AWS (that is, most likely), while I never have, and don't know what goes inside the company.

But it would be helpful if you broke that down a little more than 'trawling customer data', because at the most innocuous, if they're just looking at what's publicly selling on Amazon, what goes into sales rank, that seems acceptable, to me anyway.

[ajross]

I think there's a difference there, though. Retail sales and reselling are parts of what most people broadly consider the "same industry". I mean, a small seller making a deal with Amazon to resell something that they know Amazon could sell on its own is at least always aware of the competition.

In this case, tech investing and online retailing are not the same industry. Amazon is using a dominance in one to fund the other, which then it uses to either drive valuations of potential competitors down or to simply outcompete them.

And that's a plausible antitrust problem.

I'm normally not in the Amazon haters camp. Most of the time I'll defend them against the typical charges of unfair competition. Not this time. This is sketchy.

[api]

Stallman was right:

https://www.gnu.org/philosophy/who-does-that-server-really-s...

[caralombardo]

Hi former-aws: I'm one of the reporters and would like to hear more about your experience. Mind sending me an email at [e-mail] so we can connect?

[neilk]

caralombardo: Please don't ask people to admit to felonies over email. That goes double for any FAANG employee; their employers have many options to surveil them. Your employer has a page listing better options

https://www.wsj.com/tips

[simonebrunozzi]

In fact, I would add: do not trust a journalist that doesn't try to protect his/her source. Nothing personal, Cara Lombardo.

[marta_morena_25]

"perfectly normal to trawl production customer data"

It's not. And there are plenty of trainings inside of Amazon to make you aware of that. It is your fault, in the end, to not report your team. I have been on several teams at Amazon and this would always be an absolute no-go. It's already difficult to even get basic ideas about customer data, things that you would consider "essential" to improving the customer experience.

[icelancer]

>> It is your fault, in the end, to not report your team

Talk about all time gaslighting. It's the managers/directors job to ensure compliance, not normal employees.

[httpsterio]

If you see another employee committing a crime, you're obligated to report it under US law. You can be considered an accessory if you don't.

[otterley]

Attorney here!*

That is totally false.

Conspiracy requires two elements: an agreement to commit a crime, and an act in furtherance of said crime. There is nothing unlawful about looking the other way. You might be a scumbag, but that's a different problem.

The elements of criminal accessory require one to harbor, conceal, or act in such a way as to help someone avoid or escape arrest or punishment (CA law here, other states may be different). Again, merely "looking the other way" is not an act. Otherwise, anyone who merely witnessed a crime could be charged with criminal accessory.

That said, corporate policy might be quite different. If I look the other way while a colleague violates customer security policies (and I'm aware of such violation), I can justifiably be fired.

*Not giving legal advice, seek licensed counsel in your jurisdiciton.

[3gg]

We need more attorneys. Attorney saves the day.

[tekknik]

We need more attorneys only in that their services will get cheaper.

[b20000]

no you're not

[rorykoehler]

Didn't you anonymously tip off the customer?