> Consent must be "freely given, specific, informed, and unambiguous."
and
> Apollo notifies them when their data is added to Apollo's database of business contact information and provides them with instructions on how to opt out.
Now, their claim appears to be that they're processing business contact data under the legal basis of "Legitimate Interests". But as much as I am a big fan of not doing things that require a legal basis of "Consent", I'm unconvinced that they ensure their customers are sticking as tightly to their basis as they ought to be if they wish to claim it.
In other words: yes, if you have a CRM in then you might derive legitimate interests in sharing with Apollo. But you need to make sure you actually have the right legal basis for putting customer details into your CRM, and your support database almost certainly does not hold appropriate data!
So ultimately I think this is on both Browserstack (for connecting and sharing data other than in accordance with a legal basis) and Apollo (for making it too easy for their customers to send them data without a sound legal basis and then for sharing that data without suitably validating they had the legal basis to).
Apollo's privacy centre makes all the right claims about how they comply with GDPR, but the OP's story demonstrates that they're not as scrupulous in their verification as they claim to be. And strictly, both should be reporting the breach and taking steps to ensure it doesn't recur.
There would have been a power imbalance at the point of signing. I can well imagine that the implications of that particular clause weren't apparent at the time.
As a society (more so here in the UK than in the US, I'll grant) we have laws governing what one party may demand of the other. They don't prevent a genuine meeting of the minds, because enforcement of a contract will only be an issue if at least one party doesn't follow through. But they do limit the ability of the company to impose sanctions beyond a point.
One limitation in the UK is that penalty clauses that are "private fines", like this one, must be based on the actual damage caused.
In this case, as in the non-compete case, I would say that if a company wants to continue to influence what someone does, they should continue to pay them.
Given the Epic settlement means Google is allowing alternate app stores, and also the delay only applies for unregistered developers, I'm not certain it won't actually get easier to get folk set up on F-Droid.
It still remains to be seen what the actual requirements are, and even if F-Droid could become "approved" that doesn't mean they want to. Time will tell.
"only applies for unregistered developers" but remember the whole point is to allow Google to pull your "registered developer" status on a whim. Something they've shown over and over again they cannot be trusted with
Why the hell should we "mother may I" with Google for running apps on our own phones if it isn't sourced from the Play Store?
The "security" rationale is horseshit given just how much malware is readily download able on the Play Store. Google never cleans its own house before going after others.
Singapore is not big enough to dictate terms to Google. If Singapore wanted this change and Google didn't, Singapore's most extreme option would be to ban the import of standard Android phones to a market of a few million people.
The scammers are often in a very different country than the victim. Finding the scammer is only 50% of the work, the other 50% is diplomacy and hoping the other side is willing to extradite. This is not made easier if the police force in the scammer's country is extremely corrupt.
This is why those scams so often rely on gift cards (or sometimes on cash which a local mule converts to crypto).
The scams are likely to some from outside Play. In the US, these scams don't run because iPhone is the dominant platform and side loading in iOS is not possible. In the rest of world they are widespread.
"Likely"? Do you mean that based on actual data, or are you using it as a weasel word so you can present whatever convenient "facts" that benefit Google as truth?
I’m betting on the latter. No Kitboga video mentions custom Android apps. What actually appears on almost all videos are online ads/spam or fake celebrity accounts messaging random people on Facebook.
It's funny how you aggressively push solutions that ignore the most common scam vectors investigators encounter. Could it be a coincidence that your proposal conveniently places every aspect of people’s lives at the mercy of big businesses? Or that the scam vector you downplay, ads and social media, just happens to be cash cows for some of the richest companies in history?
We already have plenty of paid lobbyists cheering the transfer of wealth from the poorest to the richest. There's no need to do that dirty work for free. Weaponizing the elderly being scammed of their life savings while protecting those that benefit from it is beyond messed up.
The scams that are happening in the rest of world are calls posing as bank support about urgent security issues and telling people to install apps to protect their accounts.
Absolutely! Never had one problem with apps on FDroid. Not even when tbe Simple Mobile Tools suite was sold to a shady company without a heads up to its users. And that safety isn't an accident.
And how much grift happens through Android side loading? (BTW, I hate that weasel word used to vilify a perfectly reasonable activity.) Practically all grift on Android happens through apps on the Play Store. People who know how to 'side load' are also usually careful and smart enough to think about what they're putting in. That's not a useful target for grifts either.
As somebody put it, Google goes after others without cleaning their own house first. It's just abuse of power at this point.
F-Droid at least does a quick review to make sure there's nothing malicious in the app before adding it. Since we know Google does something similar and there is still malware on the Play Store one might reasonably conclude that Google doesn't actually care about malware.
Now, it might be a problem of vetting at scale or malware being really subtle, but if that's the case Google should focus on improving their process before locking down Android for "security".
My point is that Google does not want to protect users by restricting "side loading". If they actually wanted that, they would remove all the malware in their store. They are just building higher walls in the walled garden to lock you in.
Right, but the Debian Developers don't prevent you from installing (installing, not "sideloading") other programs. If you want to install malware you're free to, but they don't distribute it.
You can still install any ROM you want. Not having Play Store has some downsides, but those trades offs should be familiar to a free software enthusiast.
You can only do this on a tiny number of devices supporting free drivers (and mainline kernel), otherwise you are tied to an ancient Linux kernel. I'm using Librem 5 btw and don't believe that Android, whose development completely depends on Google, is a viable long-term solution.
We shouldn't let naive or mentally disabled people to dictate how computing should work. That's the same logic behind the age verification shit that's happening worldwide.
If you (not you specifically) are unsure of your abilities to use computers, let a friend or a family member buy a dumbed down device for you or install parental controls or something. Or maybe have clicking the build number 7 times reveal "toddler mode" where you can lock your device down irreversibly as much as you want.
It might be pro consumer if the power were lying in some kind of democratically justified organization, which then decides which apps are allowed and which are not.
This way, consumers are helpless victims of the same megacorporation, which will use its near-absolute power over the mobile ecosystem (shared with one other megacorporation) to profit on the back of consumers.
This is as pro-consumer as cutting off one's nose to cure a cold. Let me say this for the... I don't know how many times, that security, child protection, scam prevention, terrorism, miniaturization, sophistication, etc are all lies peddled by trillion-dollar megacorps to justify their cash grab, and by despotic governments to justify their consolidation of power over citizens. Nobody wants to know why all those problems still occur despite these unpopular measures. Meanwhile, NONE of those draconian restrictions on users' freedom and privacy are technically necessary to achieve any of those ideals. It's a lie that they convince the people by repeating incessantly.
This is 2026, for God's sake! How long has this grift been playing out? At least two decades? What will it take people, much less the tech savvy ones, to learn that all these are designs of greedy and power lusting minds?
Says who? The fanbois? What makes you think that ordinary people are any happier with Apple's abuses than Google's? This is not a worthwhile justification for what either one of them does.
I've only hit the compaction limit a handful of times, and my experience degraded enough that I work quite hard to not hit it again.
One thing I like about the current implementation of plan mode is that it'll clear context -- so if I complete a plan, I can use that context to write the next plan without growing context without bound.
Agreed. The only time I don't clear context after a plan has been agreed on is when I'm doing a long series of relatively small but very related changes, such as back-and-forth tweaking when I don't yet know what I really want the final result to be until I've tried stuff out. In those cases, it has very rarely been useful to compact the context, but usually I don't get close.
I really like this too - having the previous plan and implementation in place to create the next plan, but then clearing context once that next plan exists feels like a great way to have exactly the right context at the right time.
I often do follow ups, that would have been short message replies before, as plans, just so I can clear context once it’s ready. I’m hitting the context limit much less often now too.
One big difference between the UK's historic constitutionalia and the US is that the UK generally recognises that we only do things a certain way because agreeing how to change them is too hard, while the US appears to think that they do things in their certain way because that's the right way to do them.
Specific examples for the UK: inducting politicians into the Privy Council in order to qualify them for security briefings, Henry VII powers, and ministers' authority deriving from the seal they're given by the sovereign. Which would almost make as much sense if it were a marine mammal as it does being a stamp.
The thing being, they work well enough. And if you want to replace them, you need to work out what to replace them with and how.
Modern democracy starts to make a lot more sense when you realize the driving principles are "what works easy enough" and "how do we prevent getting to the point of violent revolution".
I'm glad the payload was usable and the author has fixed their problem, it's an interesting challenge.
However, there are other approaches. A public IP per client isn't going to be nearly as expensive as a VM per client, and lets you route your clients by target. Or you could route by source IP: either by having the client register their IPs, or with some combination with seeing where folk log in from.
Neither is necessary, though, given inspection does appear to work.
The author framed his issue as a choice between separate VMs (with high cost) per user or decoding the messages. As he, you, and I all say: what he's got does work. I'm absolutely not saying that now he's solved the problem he should do something else. But the choice wasn't between only those two extremes.
This protocol was amenable to inspection, the next might not be.
I use NextDNS, one of the features it provides is letting you register a source IP so requests from your network "just work". It might not be a mainstream consumer feature, but neither NextDNS nor managed Unifi controllers are mainstream consumer products.
Edinburgh doesn't enforce its 20mph zones, I follow them anyway. And I don't believe I actually make progress through the city any less quickly than drivers who speed, because it's rare that I'm not in any case sitting behind the speeders at the next red light.
Arterial roads are normally still 30mph, and it's not a huge city so it doesn't take that long to get from the outskirts to the centre. Or when it does, it's not because of low speed limits.
That does somewhat depend on the size of the context.
LLMs won't add information to context, so if the output is larger than the input then it's slop. They're much better at picking information out of context. If I have a corpus of information and prompt an extraction, the result may well contain more information than the prompt. It's not necessarily feasible to transfer the entire context, and also I've curated that specific result as suitably conveying the message I intend to convey.
This does all take effort.
My take is also that I am interested in what people say: I have priors for how worthwhile I expect it to be to read stuff written by various people, and I will update my priors when they give me things to read. If they give me slop, that's going to affect what I think of them, and I expect the same in return. I'm willing to work quite hard to avoid asking my colleagues to read or review slop.
> LLMs won't add information to context, so if the output is larger than the input then it's slop
That doesn't align with my observations. A lot of times they are able to add information to context. Sure it's information I could have added myself, but they save me the time. They also do a great job of taking relatively terse context and expanding upon it so that it is more accessible to someone who lacks context. Brevity is often preferable, but that doesn't mean larger input is necessarily slop.
I approve of Renovate's distinct recommendations for libraries vs applications.
For a library, you really want the widest range of "allowed" dependencies, but for the library's test suite you want to pin specific versions. I wrote a tool[1] that helps me make sure (for the npm ecosystem) my dependency specifications aren't over-wide.
For an application, you just want pinned specific dependencies. Renovate has a nice feature wherein it'll maintain transitive dependencies, so you can avoid the trap of only upgrading when forced to by more direct dependencies.
The net result is that most version bumps for my library code only affect the test environment, so I'm happy allowing them through if the tests pass. For application code, too, my personal projects will merge version bumps and redeploy automatically -- I only need to review if something breaks. This matches the implicit behaviour I see from most teams anyway, who rely on "manual review" but only actually succeed in adding toil.
My experience is that Renovate's lock file maintenance makes update a whole load safer than the common pattern of having ancient versions of most transitive dependencies then upgrading a thread of packages depended on by a newer version of a single dependency.
> Consent must be "freely given, specific, informed, and unambiguous."
and
> Apollo notifies them when their data is added to Apollo's database of business contact information and provides them with instructions on how to opt out.
https://knowledge.apollo.io/hc/en-us/articles/4409141087757-...
Now, their claim appears to be that they're processing business contact data under the legal basis of "Legitimate Interests". But as much as I am a big fan of not doing things that require a legal basis of "Consent", I'm unconvinced that they ensure their customers are sticking as tightly to their basis as they ought to be if they wish to claim it.
In other words: yes, if you have a CRM in then you might derive legitimate interests in sharing with Apollo. But you need to make sure you actually have the right legal basis for putting customer details into your CRM, and your support database almost certainly does not hold appropriate data!
So ultimately I think this is on both Browserstack (for connecting and sharing data other than in accordance with a legal basis) and Apollo (for making it too easy for their customers to send them data without a sound legal basis and then for sharing that data without suitably validating they had the legal basis to).
Apollo's privacy centre makes all the right claims about how they comply with GDPR, but the OP's story demonstrates that they're not as scrupulous in their verification as they claim to be. And strictly, both should be reporting the breach and taking steps to ensure it doesn't recur.
reply