Most data can be de-anonymized with some clever tricks. I don't know about Mozilla but the others definitely try to keep it just anonymous enough to later be correlated with the rest of your profile.
Edit: typos
Lifter
joined 1 year ago
No any self hosted isn't on the radar. By big, they mean the centralized giants, i.e. Meta, Google, Telegram, Signal(?) etc.
Force all the big platforms to share their encrypted data. Banning end-to-end encryption. It's all very stupid and will never actually catch any bad guys.
Maybe competitors are only up to 200 per year and these guys finally achieved 300 per year?
This will lead to change fatigue. People will rather not cleanup as they go anymore and just get the work done, with worse and worse code quality as a result.
Bank holidays would be really awkward. You start wort at 23 and the next day is off so you would just have to work that one hour.
Office workers could probably move hours around. It would get complicated for shift workers though. Paying overtime for work on holidays?
That's not true at all, mathematically. That's why we have a measurement for co-variance or correlation. If two dimensions are 100 correlation, they can most definitely be reduced to one.
To be fair, most of these apps were made before the notification categories were invented and they don't keep the consultants that made the initial app, or want to pay for the change.
Agreed but someone actually tried it - did the research.
That's just what we call people spending some time to figure something out. Security research is basically just trying to learn the technology and then trying to break it.
No thanks. It's way more fun to be part of the decision process. If a manager can anticipate all of the requirements and quirks of the project before it even starts, it's probably going to be a really boring, vanilla project at which point it's probably just better to but the software.ä somewhere else.
Creating something new is an art in itself. Why would you not want to be a part of that?
Also: Isn't it cheating to compare the two approaches when one of them is defined as having all the planning "outside" of the project scope? I would bet that the statistics in this report disregard ll those projects that died in the planning phase, leaving only the almost completed, easy project to succeed at a high rate.
It would be interesting to also compare the time/resources spent before each project died. My hunch is that for failed agile project, less total investment has been made before killing it off, as compared to front loading all of that project planning before the decision is made not to continue.
Complementary to this, I also think that Agile can have a tendency to keep alive projects that should have failed on the planning stage. "We do things not because they are easy, but we thought they would be easy". Underestimating happens for all project but for Agile, there should be a higher tendency to keep going because "we're almost done", forever.
I guess that wouldn't help the deaf people though. (: