Agile peaked with Extreme Programming and paper story cards, since then all that seems to have happened is the adoption of more tools/process that missed the whole point of it. The most productive project I ever worked on followed that method - but it's very hard to scale up.
I worked somewhere where we dumped our (very complicated) 'agile' tracking tool and went back to cards, and productivity increased, people actually communicated. We did eventually add in JIRA, to support remote team members but banned 'customization', 'workflows' and all the things that actually get in the way of being an Agile team.
The most bizarre App Store rejection I’ve seen was for a TV app which was rejected by Play for ‘Policy Violation’ without much explanation… After several rounds of resubmissions and emails it turned out the problem was some channels on it were in 4:3 (not widescreen). Google required we add a ‘warning’ to the App Store description that it contains 4:3 content!
Try using Cloudflare R2 with zero egress and you'll rapidly discover there are lots of 'gotchas'...
- Want to use a cloudflare managed domain - pay for egress if you have enterprise account
- Want to use their 'dev' domain - rate limited
It's still a good service - but zero egress comes with conditions. The only exception I've found is Cloudflare pages which seems genuinely zero egress (as long as you don't proxy it through a managed domain).
The question is how did you do training. If in the process you 'copied' the image (e.g. from network to memory) you did require copyright.
Reading with a human is not copying, but reading by machine is - there are several cases where that has been enforced. This is covered by reproduction rights.
The law has passed - but it also has exemptions for security.... So we can expect a lot of negotiating between the EU & Apple/Google on what they actually have to do.
If you want to keep the google accounts working for things that free (photos, YouTube etc) you can switch first to the business essentials plan and then to the cloud identity plan. Then you can move the email elsewhere but the google accounts still work.
This was essential for me as I used g suite for my family and some are using it for photos.
It can prevent MITM IF it's loaded in client page (defining MITM as network interception).
It can't stop keyloggers, people looking over your shoulder, malware in the browser (MITB)/plugins as it still sits within the browser sandbox. It can in some cases detect that, and in some cases hinder it.
An attacker can stop it loading by MITM the connection, but then the site can't work against it's APIs as the solution also verifies as data goes into those API's the encryption is present and the code isn't tampered. If it's tampered a business rule is applied to decide what to do, either stop the messages, OR pass it back to risk management systems (very common in finance).
We did think of that :) - we can detect your tampering with the forms we protect. But that said it doesn't stop everything if you can install a keylogger, or get the user to enter data somewhere else we can't stop it and it does depend on where in the user journey you try and protect things, as someone else here has pointed out if any of the journey is HTTP (or HTTPS being MITM) then they can send the user somewhere else.
However I'd also argue you don't actually need to stop people grabbing the data. Noticing achieves a large chunk of that, as (for example) I can notify the credit card system it's happened.
In that case even if you MITM it - all the bad guy gets is encrypted (AES) data. Whitebox does sound a bit like black magic, but it's widely deployed (over 5 billion devices for Irdeto's) and add a nice layer to ensure that you're actually talking to the end users browser, and it's your code that's running on it.
I agree - but as you say OAuth also suffers from MITM weaknesses. I'm just not convinced 'plain' client certs solve that as it's very hard to distribute those securely and manage them.
I guess it depends where you see these being used, if used Server to Server it's not too bad, but if pushed out mobile devices (as I suspect they will be) they are very likely to leak unless strong app protection is applied.
If you're banking on strong app protection working you really need to be notified of it's state on the server which this won't do, you need to use a securely signed message from the verification/protection libraries on the client.
That can be done by storing this key into a cryptographic whitebox and then linking using it to integrity verification.
Even dev's can't cope. Most apps leak credentials severely. You need integratity verification, obfuscation and whitebox crypto to do this sort of thing securely.
All of that is available in the banking world and is often deployed by people like Irdeto (who I work for) and Arxan etc.
This is unlikely to work - developers in general can't cope with managing SSL certificates. They won't know what to do with them or handle them securely.
You need full integrity verification, with a secure store and whitebox crypto keys to make such a scheme secure.
I worked somewhere where we dumped our (very complicated) 'agile' tracking tool and went back to cards, and productivity increased, people actually communicated. We did eventually add in JIRA, to support remote team members but banned 'customization', 'workflows' and all the things that actually get in the way of being an Agile team.