> I have to imagine the vast majority of normal developers do not give a damn about security in being in security patch lifecycles on software.
I just don't think it's the developer's responsibility.
Depending on the size of the team of course, but the work that developer's do comes from someone else. Empower me to make decisions and I'll make them, but don't blame me for the choices other people make if you won't empower me.
I think I get where you're coming from. I've worked mostly on small teams (sub 30) so it's always been on us. The engineering leadership never prioritizes security unless it's something as big as the log4J stuff because it was on customers' minds.
That said, if they're software packages from something like Node or PyPI, I do think that it falls on the developer. If the point is that leadership needs to give devs the ability to act on that, that's very fair.
Exactly. It's not the bricklayer's responsibility when mortar fails. It's the person who specified that mortar.
So I'd agree it isn't not a coder or developer's responsibility when they're given a bill of materials and told how to build, but it is an engineer's responsibility. Comp should recognize that as well.
We set up our applications and services to be multi-AZ natively. It's not particularly difficult with how many AWS services are regional or global (Admittedly, I still expect a potential DNS failure to cause issues if and when that occurs). However we are just part of a workflow, we integrate with other applications that are not multi-AZ and would be impacted. That's just out of our hands.
It's like our on-prem systems were ordered to plan out and exercise DR plans to account for a data center going offline, but we can't exercise a DR plan fully if part of the plan is 'Adapt to how application X, which is hosted in the same datacenter, also chose to fail over.' We do not own application X. There is no appetite in the business to co-ordinate the DR exercise across the entire company at the same time.
We can't even do it all in a lower environment because there are dependencies on systems that are shared across environments. Some massive, redundant filesystem that is sync'd across our data centers, but the sync is a boolean. One datacenter instance of it is the primary and the others are read-only until they get promoted. We have one of these and lower environments are just a different root folder on the system with different access patterns, but they can't make DataCenter A the primary in prod and DataCenter B the primary in UAT.
Question who's never relied on this: how do you test whether your multi-AZ setup can withstand an AZ dropping? It sounds like your third party apps make it kind of pointless to test anyway, but I'm curious!
Ops type here, generally you have to fail an AZ and see what happens. If you have Dev/Staging environment that is exactly like production with plenty of tests, you can use that. I've seen only one environment actually like that though.
Since most companies would have to do it in production and they don't want to have customer impacting outage, they tend to do it during an actual outage.
Thans! So do you have a staging environment for everything, then cut off the network or kill the instances, Aurora DB, etc.? Simulate some load while its going on, and then check for data loss? Then if that works try it in prod?
It seems like a lot of work, and it seems that as architectures evolve it would be hard to ensure that the multi-AZ failover works well.
Yes, which means it's expensive which means companies don't usually pay for it so we should name and shame companies who aren't willing to pay that expense just to pad their bottom line.
So, if there are publicly-available records incorrectly connecting you to a phone number, then you should be able to delete accounts under from the rightful owners?
If there are publicly-available records that link you to a phone number because you used to use it, then you should be able to delete the current account which is used by the current owner of it?
> If there are publicly-available records that link you to a phone number because you used to use it, then you should be able to delete the current account which is used by the current owner of it?
You're talking about someone who is using my whatsapp account because they managed to get a phone number I used to use?
Yes, of course I should have control over my account, regardless of who else happened to hack into it.
No, I think the parent is about a number you had, and then abandoned, and it's now somebody's else's number. Phone numbers don't come with the guarantee of only one user given enough time.
No, the other guy is correct. It's about any situation where someone has taken control of your number (abandoned or not), causing you to lose access to accounts associated with it. If you can prove that you owned the number during the period that you created and used the account, you should be granted access to those accounts. You're looking for an abundance of circumstantial evidence to overrule a technical issue for which you have an explanation. The person who owns the number should of course have an opportunity to rebut the claims.
Losing a number shouldn't mean you lose control of an account that can be verifiably connected to you by name, historical use, etc.
But if they tried to use whatsapp with that number, they would either be unable to register, or would be using someone else's whatsapp account which was set up with that number, until the original whatsapp account expires, right?
> Phone numbers don't come with the guarantee of only one user given enough time.
Whatsapp seems to think they do, based on the article, and their logic of making the phone number the account. Therein lies the problem.
Not sure I understand what you mean. X had the number, so the fact is reflected in some searchable dataset. Then abandoned it. Maybe there was no WhA registered, or it expired after 120 days. Now Y gets the number from a mobile operator pool, and registers WhA.
>their logic of making the phone number the account
I see nothing wrong with it. It's clear and long-established offer: number=account, and WhA definitely neither the first, nor the only one who does it. Of course, it has its disadvantages, but it's ok for the majority of users who don't want to show id, or fill a questionnaire to start texting.
> What these kinds of platform agreements usually say is that you, the licensor, agree that you are fully representing that you can issue that license, and that any infringement is thus your fault and not the platform-licensee’s.
I know the comment is brief, but it's important to understand what it means when the infringement is 'your fault'.
If it's B's fault that it caused A to infringe on the copyright license of C, then that would be handled by B indemnifying A against a charge from C. C can still sue A, C can still win a suit against A, A would then utilize the contract with B to get reimbursed from B.
If B is small and can't afford to reimburse A, that's A's problem. If B goes out of business, that's A's problem.
In my field, we require this indemnification fairly frequently as we distribute content created by others where it's impossible to fully guarantee that content leaves us with no liability, in a reasonable timeframe of distribution.
We have many processes that give us a best effort to prevent us from distributing content that we would be financially liable for. We have processes where we let things go which are gray area, but the client has posted a bond with us and signed an indemnification agreement sufficient to cover the potential fine we may face if the content was an issue. Or we reject the same content from others who don't have that signed agreement and haven't posted that same bond. Sometimes we sign an agreement without a bond because we've had decades of experience with the client and the number of violations is small enough that we would eat the cost.
I wish that there were well defined, common sense limits on indemnification and liability for misrepresentations.
Compare both to bona fide insurance markets. If I buy insurance, there is a defined maximum payment. And if I defraud the insurer, I get in trouble. And the insurer knows that they’re getting into, and they understand the risks and get compensated appropriately.
When some random consumer contract states that the consumer indemnifies the service provider, the consumer usually has no idea what this means and probably literally never sees the contract text. There is rarely a limit specified and, if there is, it’s probably basically a joke. And the benefit to the consumer rarely has anything to do with the risk (in fact, often the consumer pays and supposedly indemnifies the party they’re paying).
And then we get to representations. In a real B2B contract negotiated by lawyers both sides, the representations are generally relevant, everyone does them, and the replying party is expected to do due diligence. But in contracts like this Meta thing, to the extent that there is a representation that the publisher can issue a license:
a) That representation has nothing to do with the actual reason the publisher is entering into a relationship with Meta (the customer probably just wants to run ads or use business messaging)
b) The customer is extremely unlikely to have had a lawyer review the contract and Meta would not allow any good faith negotiation anyway.
c) Meta is not doing due diligence.
I feel like some combination of a, b and c should invalidate Meta’s right to rely on the representations and, in an ideal world, would even serve as evidence of bad faith on Meta’s part and serve to shift additional liability to Meta.
I don't see how AI coding agents are going to create 'more software' until the PO's and PM's of the world step back and let developer's communicate directly with the stakeholders. Or the PO's and PM's could cross-train on AI coding agents.
We are still being stressed to create all stories with such fidelity that 'any' developer can pick it up and implement it in the timeframe allowed for the size the story was given. When the story is written in that detail, we may as well copy it into an AI agent and have it implement it. But we can't do that, so we have people who have SME write up story's that sit in the backlog for 2 weeks until a developer can bring it in, so that they can spend a day implementing it (really 2 hours with 2 hours of meetings and 4 hours of video games) because the smallest pointing size we can give is 1 point and people aren't allowed to take on more than 8 points a sprint.
How can we expect things to get done faster when the team that reports work up to senior management put's such strict limitations on our throughput?
Except it doesn't actually slow down the research. If anything it would likely drive investors to contribute more to the competitor that didn't destroy their own company and now you have the same amount of progress and a monopoly.
> This is an excellent use case for completely local, small model inference,
How small is this 'small model' inference?
Browsers especially are expected to operate on a very wide number of devices. It makes perfect sense to me to start off with a cloud driven approach and later allow people to configure it to run locally if they have the hardware to do so. Anyone with the hardware to do so is already signaling that they'd have the technical interest to make that change while having the default 'works for everyone' mode be one that doesn't require a powerful local device.
I say this as someone using a 6 year old computer and only upgraded to 8GB of ram when the latest WoW expansion was released.
To a degree, sure, but is it really 'MITM' if the site you are trying to visit has chosen to add cloudflare into the middle?
You may as well say all load-balancers are MITM because you might connect to a different host on each attempt and there's a man in the middle influencing your connection.
What makes it any different if the website executed the same logic cloudflare is on their own box?
I just don't think it's the developer's responsibility.
Depending on the size of the team of course, but the work that developer's do comes from someone else. Empower me to make decisions and I'll make them, but don't blame me for the choices other people make if you won't empower me.
reply