In fact almost any staff member inside an organisation that receives a plausible vulnerability report should ensure it reaches the right people. It's not something you should shrug off.
It would be great if everyone was happy to drop whatever they're doing and lead resolution of customer's complaint, regardless of who the actual empowered/responsible person/team is. Alas, we live in the world where most people subscribe to Copenhagen Interpretation of Ethics. In this world, even forwarding a request to those responsible is dangerous. Anything more than that entangles you with the problem, meaning you'll be held responsible for it, no matter your actual connection to it.
We can call it "principal-agent problem", or just "survival in the world where requesters are hunting for anyone willing to engage with their requests".
(Source: I used to be the one willing to handle any internal request even tangentially related to my work, until my line manager told me to ask requesters for project ID or billing code before giving any help that requires more than 1 minute, because otherwise I'll end up doing none of the work we're actually being paid for.)
Keeping your jurisdiction small means you can do more within that jurisdiction, by ignoring even important problems that are outside it.
But the alternative is ineffective doomscrolling because all the world’s problems are yours.
It's just that practically nobody in the world can credibly demand Google's board, or even just upper middle management, to make a decision on small matters.
When a ticket reaches your average IT guy, they can't usually delegate it to a lower tier employee unless there are formal support tiers, like L1 and L2, and the ticket was sent to one of the upper layer techs (which usually doesn't happen straight away, because of how L1 and L2 support teams work).
If this is not the case, the only way out is forwarding the issue to another team.
Sorry guys, that’s another team. They’re extremely reluctant to deploy even very important things. Separation of responsibilities means we have no other choice.
Yeah, that's my read. Basically the first line of support said "parental controls and screen pinning don't count as security boundaries", and the author is upset not because of an abstract argument about impact but because they want to get paid.
Should they be security boundaries? Honestly I'm mixed on this. First because the threat mode is totally different when the attacker is your teenager (i.e. who exactly is the harmed victim? The parent?).
But mostly because the whole idea behind bug bounties is to encourage disclosure of vulnerabilities that would otherwise be sold and deployed against the public at large. That is, the bugs have "value", and we're all better off if the purchase price is borne by the software developer than the criminal. There's no market for parental controls bypasses in that sense.
Will be used in scenarios with much more at stake than someone's belligerent teenager.
Think of these features in the broadest sense you possibly can.
(Edit: <sigh> than the bug bounty that the linked author desires. Really?)
Remember that both of these technologies don't allow the device to do anything it isn't able to do in its default configuration. They're essentially a form of DRM: disallowing otherwise useful activities because of the desires of the owner (and not the user). Would you demand, say, Apple pay a bug bounty for a DRM bypass that let people rip Netflix videos? Probably not, right?
Since the bug bounty is zero. All the time?
I’d like to shift this a little:
Support who’s primary metric is handle time is in a game of hot potato.
From a business perspective the managers and leaders always feel like there’s too many fires which inevitably leads to either pressure on front-lines to “go faster” and “stop doing unnecessary work” (aka “taking time away from the fires”) or some level of management that’s intentionally blocking higher-ups from seeing those fires so that they look like they are managing the department well (and in this case not only is there the same pressure on the front-lines, but there’s additional pressure about not reaching out to anyone except through that manager.
When the primary metric is handle time, the issues pile up, there’s never enough people to handle it, and the business slowly sinks as no one with a budget sees the “ounce of prevention [that can prevent a pound of cure]”.
However: If the metric is minimum number of departments an issue touches before it’s resolved it’s a whole different thing. Suddenly playing hot potato is a problem and “problem ownership” is praised. There are other metrics too that produce different support cultures (and sometimes different games), but the reason hot potato is so popular is that those other metrics all require top-level execs to be comfortable with spending now to save down the road.
Distributed prioritization seems like a problem; you can get priority inversion if you’re not careful.
Something like reducing staff ticket time by 20%, then using that 20% for feedback, strategy, and structure. Some (maybe even most if you’re lucky) of the front-line staff will have enough experience and insight to be invaluable here (though it is likely they won’t have the language yet to express it in ways that make sense to management). As the company goes through the process of communication, discovery, awareness, planning, and execution (preferably with a tight feedback loop) some of the underlying causes will be addressed, the front-line pressure will ease off, the cascade effect will see ease-off in other departments as well, and that 20% can go down to 5% or even 0 (not recommended lol) which will further reduce the workload to give longer-lasting relief.
Then with staff time “out of the red” the company can start thinking about what they will do in a fire-free future.
Could you elaborate?
It also meant that some people had "forever tickets", that were a continuous series of tacked-on asks by the same faculty member. HigherEd IT can be crazy (and crazily-laid back).
The stubbornness of large organization can be maintained for several hundred years, assuming it exists for that long, so this isn't quite true.
Parental controls is essentially maintenance mode and has 1 dev nominally responsible for it, maybe their workload is divided between that and a bunch of other stuff that they deem their "real" work. The way the component works means that bugs typically get assigned elsewhere in the system very far away from parental controls; you, the owner of Contacts, land a bug like "Your feature XXX has the following failure in parental controls mode." The team responsible is like ... "Why do I care about this? Why should I take a code change for this? Isn't that your problem?" Whoever is responsible for parental controls might not care, but if they do, they don't have political leverage over the owner of the Contacts app or whatever. Therefore, won't fix.
"I've reached out to a colleague who has provided me with some additional context" or "this work requires some additional input from another team - I'm working to establish this and will get back to you with more details"
Neither of the above examples provide any more context on internal teammates or their organizations. However they do require additional work and a culture of customer support (which Larry Page was infamously against for years).
The problem as I see it is that Google came to be dominated by an egalitarizing culture which at first wasn't necessarily a problem. This was an explicit choice by Larry and Sergey, that your manager should not be able to unilaterally fire you just because of a personal disagreement, nor stiff you out of financial rewards, none of that. So, your manager lacks any formal authority over your day-to-day work: they have to use politics and soft power. Instead, performance is reviewed by a committee of your manager’s peers, who can “calibrate” that manager’s opinion of you against others and against empirical data.
The result of being judged by a faceless committee is that implicitly, some things generate the empirical data that they look at, and other things don't. It's helpful to oversimplify this to a common currency of “perfcoin” Ⓟ even though that was never explicit at Google. Some activities generate Ⓟ, some don't. Google has built dozens of new chat apps because whenever you can have a good excuse for how this aligns with your business priorities, they generate lots of Ⓟ. The design documents are rich in Ⓟ, the tracking issues for each feature are rich in Ⓟ, getting the thing privacy-analyzed and internationalized can get you some Ⓟ, the inevitable work to merge it into another chat app is also worth Ⓟ. But please understand that the existence of Ⓟ is a result of semi-hierarchy. The manager exists (hierarchy) but has to point to an objective measure (Ⓟ) to say that you're not doing what you're supposed to (semi-), it is almost a mathematical deduction that this has to exist given that structure.
Now networking with people outside of your team, will never get you any Ⓟ. And this is not for lack of trying! When I was there it was a job responsibility to do some things that were not your job responsibility (“community contributions”) to try and associate Ⓟ with some form of networking! And everyone hated it, and it didn't work anyways. Manager-committees immediately decided that Ⓟ would not be awarded for excessive networking, just that you had to prove a little bit of networking or else Ⓟ would be deducted. Furthermore the most reliable community contributions were noncommunal—conducting hiring interviews being the easiest: probably this person will not be hired, but even if they are, you will never interact with this person ever again. But, you conducted N interviews in the quarter and that is just barely enough to not get docked some Ⓟ for being a shut-in.
I am giving somewhat of a negative portrait and it is not all negative, see Laszlo Bock’s Work Rules for the better parts. I'm just saying that the culture of not-my-department has been created by, and is sustained by, incentivization.
Is bypassing the lock screen a security bug?
Like it's a frustrating response to this valid bug report, but it's not really a security risk here, either. You don't actually bypass the lock screen or anything.
Also other features are effected like kiosk mode etc. The implications are unclear but could conceivably be quite serious in some scenarios.
Is it? That's not demonstrated nor claimed in the linked article.
> I think it really is and could have serious safeguarding issues.
Elaborate. What's the security risk from your child using a browser after the parental control timeout expired? It's annoying that the automatic limits didn't fully happen, but data isn't compromised as a result, either.
No skin in the game, but this is very similar to the old Win95 "About... Help... $BROWSER" style bypasses.
Could you tell me more about this?
And being educated != being in jail.
But honestly, maybe re-read the HN guidelines: https://news.ycombinator.com/newsguidelines.html
> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
These are parental controls. They aren't working in this one specific way. That's. The. Scope.
The 'we analyzed the issue and decided it won't be fix' Is NOT the same as 'we don't cate about this, go talk to some other team and maybe they'll fix it'.
Deciding something is not a bug is not the same as just ignoring the bug and not fixing it
Google lost out in this case - because an employee pushed responsibility onto an outside party.
2. The flaw was publicly exposed which cause reputational damage.
Google is so huge that it's extremely common to know you have an important bug for another team, but not to be able to route it to them because you can't find their team name.
Most teams have "code names" that have nothing to do with the public name of the project. For example, the parental controls team might be named "pigglewiggle-team" and the Android contacts team might be named "katniss-team" and their bug components might have similarly obscure code names. If you don't work with those teams frequently it can be really daunting to find.
Even when the bug components have hints that get you close to the right place, it's not unusual to learn that most of the engineers are busy working on the new version of the app that isn't released yet, and the old version of the app (the one with the bug) has been destaffed and bugs are supposed to be routed to some other random team that's literally never touched the code.
If your infosec team does not have a contact email (or preferably, several, e.g. "incident@", "security@", etc), slack/teams/webex channel, or escalation process for reporting security issues, that is decently well-known to employees, they are not doing their jobs well.
Quarterly infosec bulletins? Infosec day? "Cool incidents" annual recaps?
I cannot imagine working on an infosec team that doesn't make itself very visible, and very *available*, to other groups, and always position themselves as the 'catch-all' place for any security issues (which these bugs clearly are).