Some perspective, since I've been on the other side of exactly this issue, but for another bigco:
While there may well be a backend issue, in many cases, the HAR file contains tons of useful details (in my product's case) for things like "what were responses from other service calls, was anything failing locally, was any state in a weird... state" that can then let me better understand what's going on in the backend, or even know where to be looking in the backend. These large services are _so complex_ nowadays that looking at a slice of backend logs without the frontend to dovetail can often be a very partial view of the world, or be a needle-in-a-haystack scenario.
I'm giving them the benefit of the doubt here that it's similar to my project, clearly, they could maybe just be running a script (since we similarly request a HAR for all reports, since 99% of the time in practice it _is_ very useful), and you won't be harming anyone from trying to get a clear answer as to if the PG/triage group actually needs it to move forward and pushing back if they don't.
I also imagine that, if they're anything like us, you could request explicit deletion of all your support data from that case after the case is done, and they'd have to comply per GDPR/etc (We certainly would) and they likely already have to silo the information in ways that explicitly makes sure that sort of PII doesn't end up in buckets it shouldn't. I don't know if this moves the needle for you, CC #s are still touchy, but just thinking out loud.
Anyway, I hope this doesn't come across as apologetic for lax security practices, just wanted to give this perspective as I just remember the feeling of frustration of the customer refusing to send logs with a similar justification and my going "but it's going to be _much_ harder/impossible to diagnose your issue without that, and I have 0 doubts in my team's ability to properly handle and dispose of secure data as professionals, we are literally legally obligated to."
Appreciate the perspective. I do realise that HAR files are very useful, if for nothing else than being able to rule out any client-side issues. However, I don’t agree with their decision to make it impossible to get something looked at without HAR files - especially when there is a legitimate consern that they may contain highly sensitive data (even after their tool’s automated cleaning) and for something that is almost certainly a backend issue.
Also, it’s not so much that I don’t trust Google to handle the files responsibly, I just think it’s principally wrong to ask customers to send highly technical files (that most people won’t understand the implications of) in this day and age, when everywhere else we are all trying our best to educate people how NOT to get tricked into sharing security credentials and credit card info.
How easy wouldn’t it be to call someone you know are having a payment card issue, claim you are from Google Support, and then ask them to follow the procedure to record a HAR file while they are trying to add a new card, and then send it to some Google-like email? Even though many now have learned that they shouldn’t give out their password to anyone or click random links in emails, I suspect that a huge percentage of people would have no idea of what they just emailed to some stranger in this scenario.
Do we really want the major players to teach their customers that it’s perfectly fine to share whatever with someone claiming to be a support rep? Shouldn’t we be moving in the other direction instead?
There's definitely a line to walk there re: consumer education, but I'll give the analogy that if you walk into a bank to obtain a loan, you'll hand over _far_ more sensitive information than is in a HAR file. Typically this is fine though, because we're confident we're talking to a party that actually needs this and is whom they say they are, both to lend legitimacy and potentially follow back if something goes wrong. (The fact that we initiated the interaction as well would seem to lend some legitimacy to otherwise "escalatory" requests) I personally see a similar relationship when I reach out to some service provider/utility with an issue, e.g. I'll tell them my SSN but if someone on the street walks up and says "I'm from the water company tell me your birthdate" I'd... make a very confused face.
Both as such, and to be clear, I am sensitive to the making it impossible part, and stand by my earlier statement that ideally you should be able to push back enough to get a cogent answer from the PG as to why they need it, or get an exception if not. (We should absolutely teach people to have informed reservations. Ideally we'd also have better mechanisms for easily verifying identity and securely sharing and ring-fencing information, but if wishes were nickels etc.)
(To wrap this ramble up, I will grant you a scary addendum though: A slight variation to the phishing attack you described even broaches the "We initiated the communication" trust-exercise, as a more sophisticated phisher may be able to by side channel identify that you're having a certain issue and may have reached out for assistance, and can try to intercede in that by extending help pretending to be the intended respondent. The mitigation to this one is typically "never trust someone who reaches out to you, call the trusted verifiable root-of-identity yourself each time." but it illustrates the balance one has to strike in keeping ahead of the escalating cat and mouse game while still being able to securely exchange information when necessary.)
I can confirm this on pure (native) FF as well. As someone who has run multiple large web properties this hurts to see. I've observed firsthand the impact of what adding friction to certain browser segments does to utilization, if large corps decide that FF is a "risk" it will do a number on their already struggling traction, and we already live in far too much of a browser monoculture.
So, I normally stick very hard to tech topics on HN, but this (dance and tall folks) is so close to heart I have to chime in:
Have faith! Don't feel bad, lankiness while dancing is just "the emergent property" of what happens when a tall person is learning. Short dancers (of whom the 2 of the best footwork-heads in my old crew were) have their own pathologies to get over, it's not all free lunch, they just look differently when they do. And similarly, as they improve, they can gain a really distinctive style of crisp, clean, fast, small motions. HOWEVER, tall dancers aren't precluded from mastering styles that works with our body either, it just, tall as for short, takes practice. Have a link to one of my favorites, Kapela [0]. I can only hope it inspires others like it does me :) (Going to go do my footwork practice now, in fact, as talking about this got me excited.)
My somewhat cynical hypothesis regarding "Why does everyone insist on putting customers into price brackets based on such a useless metric" (And I do not mean this as a dig at Gitlab, to be clear, just an examination of the strategy.)
If there is a curve "amount of money a company of a given size will pay", in certain applications, server load, bandwidth, and disk space utilization likely scales far below that trendline, whereas per-user tracks far closer. It also ensures there is effectively no upper bound on CLTV as a given customer scales out, even if net-usage only increases logarithmically/asymptotically.
To try and be even-handed and take a more generous interpretation as well, the former is also less likely to be cogently communicable to a customer, and may have painful UX when limits are hit.
Also smaller companies tend to come with an outsize support burden that can chip away their profitability to be a net loss that grows over time. That burden grows the more people you have using the product.
Except I would say what instead of a certain applications this is true for the most of applications. If something doesn't uses tons of traffic/storage and is user facing then the resources spent per user are minuscule, you would spend more time and (even literal) energy to actually track and bill the user for the spent resources and somehow explain why some resources are billed for the insane rates (because you need to bill some thing for insane rates to make up $10 ARPU/month).
I had the same problem recently - I was musing about re-selling my monitoring solution (I'm using it myself, at like ~2% of the VPS I'm renting) and the first thing of course was the idea to base the price on the load each client would generate... and I pretty quickly come to a conclusion what I can't reasonably price things at $0.10 per unit, because the time I would need to spend on the setup is way, way more costly for me than that and that doesn't include billing hassles in any way.
So yes, billing per user is not only beneficial for the provider on the "user is paid wherever it uses the resource or not" but also allows the provider to not to spend time and money on actually implementing the way to bill the user for the resources.
and your costs track a certain number (e.g. number of checks/hosts)
why would you bill per user?
if you did all that and you have the right LTV and CAC numbers, at certain point you could basically run it on auto pilot
billing per user, but maybe you have 1 power user in a team, and a few extra accounts for non tech/backup/etc, which login once a month to check something
It isn't and the cost of developing something... is too much for a side gig with the intended purpose for the VPS to pay for itself.
> why would you bill per user?
In my situation I don't need to bill per user (and it would be counterproductive for me to do so in the long run), my point here is what my price calculation per resources spent doesn't correlate with my resources cost in any meaningful way, at least with anything with the word 'income' in it.
> and your costs track a certain number (e.g. number of checks/hosts)
In the end I just drew some arbitrary numbers for a checks/hosts numbers, slapped the price tag of a couple bottles of beer and called it a day. One person was happy with it and he uses only a couple of basic HTTP checks (so maybe around 0.002% of VPS? Who knows). Other one said it was too much for him. *shrug_emoji*
(I want to preface this comment by saying I don't mean in any way to rebut the thrust of the article, I worried this could be taken that way, rather it's a commentary on the inconsistency of feed implementations that I don't find discussed much.)
As a somewhat orthogonal observation, I've found it's surprisingly hard to write a crawler that's well behaved with consistent heuristics across a variety of different feed providers.
Usage of published vs pubdate vs updated, which is changed when, (or all three just containing 1970 and/or the current time), reordered feeds, items published out of order _regardless_ of the scheme used, changing urls/ids, etc. Whatever set of heuristics one uses for some sites may not apply to others. Now, this begs the question of "why not make parameterize and tune", and yes, this is largely what I've resolved to, but it's, to the core point, more of a moving target than one would expect from how ostensibly simple RSS is.
At the end of the day, in many cases I just fall back to using a cache of recently-seen-urls and, when possible, short-circuit the enumeration when I cross one. (Similar disclaimer, I do love me some RSS, I've just never had a good opportunity to rant about this.)
I can't speak for Google, but as a Microsoft eng/manager, I _CERTAINLY_ keep an eye out for discussions on my product not only here but on other social channels, and will, if actionable/relevant, try to get it in front of the right eyes; you can likely find some of this in my comment history.
Full disclosure, this is not some MS policy or otherwise, and I don't want to convey that I have some deep system/make assurances that I catch everything, just to emphasize that I find keeping an ear to the ground valuable, and that peers often appreciate hearing the news as well, even if (and sometimes especially if) it's bad news.
In terms of what they "make of it", that's obviously situational, but I've usually seen it approached constructively or as a potentially novel/holistic source of insight.
Hah, I must admit the shadow of that question crossed my mind while I was writing my post; for better or for worse I do not work for teams :) I'm currently on the power-query side of the world, and have largely worked in the data/distributed systems space.
I used to consider the dislike count. I am still inconvenienced by its absence.
To give one example: In the major categories of videos I watch (tutorials, niche historical topics, video games, music) it was very common for at least some type of "Trojan horse" content to show up (heavily amateur/improper/incorrect content, potentially troll content or in the music case bad rips/"remixes"/mislabeled songs etc.)
Previously, dislike count gave me a way of catching this trivially, even in cases when comments were disabled, before I wasted time loading the page or getting blasted with max volume noise (human screaming in one case IIRC) to the point of clipping my speakers (I hit this post-removal as well, thus this rant).
Low view counts are effectively meaningless as an oracle given that it's largely expected in many cases.
This change has for me as a user severely hampered Youtube's utility as a platform (I effectively no longer use it for discovery), and as a technologist, lowered my respect for the functionality/integrity of the software and its design choices. (I doubt they are unaware of this, but I also doubt I'm their target demographic, and find their stated justifications disingenuous at best.)
> when a dev tells me "two weeks" I smile and say "I believe you meant SIX weeks, right?"
Wanted to chime in and say _thank you_ for giving me the prompt that this is an "OK" thing to do. (as a technique for trying to encourage/help devs build in good buffer)
As another dev-converted-to-manger, who was also somewhat taken back by that same perception of the malicious manager (I certainly had that perception from time to time as an eng, so it's not entirely foreign although I am surprised by how widespread it seems to have become) what you've written really resonates with me; One consequence is that I've become way more forgiving (in terms of trying to proactively improve it) for what I used to perceive as "bad management" as I struggle to improve my own techniques :P
> This "Us vs Them" thing is bollox - we're all on the same team as far as I am concerned!
I swear I want to scream this from the rooftops in many of the ragging-on-management threads I see but I know it's not the dev's fault for feeling miffed, a bad manager can _wreck_ your life, but I wish I had a magic password I could tell devs to let them know "I'm here to make you/your work successful, not the other way around, and if I'm ever failing at that I _want to fix it_."
(As sister responses point out, this is something earned, and fully agree, it can just often be an uphill battle, potentially rationally from what devs have experienced prior; again just trying to give everyone in the picture the benefit of the doubt as I'd hope they would me.)
My perspective as a maintainer is _surprisingly beneficial_ in aggregate.
The changes aren't necessarily going to be the most impactful, or most visible, but I'm sure you've seen after N years on a project all the small "I'd love to fix this but can't reasonably prioritize it" items that accumulate, and someone with less expertise may often be the perfect candidate to help burn that down (it also helps build that expertise in doing so.)
I can see situations in which there might be more difficult tradeoffs of "time spent vetting contributions/ramping up new people" vs. "utility per capita" but at least for the projects I've had touch on, there are always a healthy slice of up-for-grabs issues that I was/am more than happy to see get knocked off and were often reasonably self-contained, but would still contribute incrementally to the polish+overall-goodness of the project.
I realize this is unsolicited, so I will feel no insult if you don't desire to respond, you've just got me very interested from a "management case study" perspective; so at the risk of a very naive question:
Do you have a good understanding re: what your folks are unhappy _about_? Like very specifically, do they feel overworked? Is there reliably political drama in the office? Is it a pay issue? I mention these not to suggest but give examples of how bluntly I mean. Problem here, is that it may be hard for you, given the power dynamic, to get that answer, but as an engineer, I can say it was always _pretty well known_ to the boots on the ground what was making the team unhappy. (and what was fascinating, and why I make this comment, is that it always seemed to run into a real bottleneck percolating up into management)
If you've already gone down this route, then again, ignore me entirely, but if you've not, or if you doubt the veracity of the message you got, I wonder if you can get a "spy in the ranks." I don't mean this in a negative way, but an engineer who for whatever reason (Naivete? self-sacrifice? I use these somewhat snide terms largely because I'm somewhat tongue-in-cheek referring to my past self) is willing to go against otherwise better judgement and be truly open with management about the situation (in that sometimes, management _may_ be the problem, and no one wants to fall on that sword), and who has enough trust with their peers to understand what's going down with them as well.
This can be hard to find, and isn't always present; but to summarize this ramble:
I would emphasize attacking the root of the problem in a very personal fashion, but that to do so requires having (or building) some conduit of trust and rapport; and I wonder if you've run into roadblocks trying to apply this.
Would having a "spy in the ranks" not further undermine the trust between founder and employees? Wouldn't it be ideal to lead by example and encourage a culture of open sharing over eavesdropping? I get that there will always be some power dynamic between manager/managee, but I felt encouraged enough with my previous manager's and skips to be open and direct about problems if there were some. That's probably an exception not the rule, though.
Having not been in management whatsoever, I'm asking purely out of curiosity
Truth is I probably didn't use the right wording there, was too tongue-in-cheek with the intent of poking jabs at myself.
You get at the issue I've seen with what you say here:
>I get that there will always be some power dynamic between manager/managee, but I felt encouraged enough with my previous manager's and skips to be open and direct about problems if there were some.
Namely, I've seen too many situations (both as an engineer and a lead) where the engineers really did NOT feel encouraged to be open; and even if it was encouraged, there was not necessarily sufficient trust to be entirely candid. As I gestured at earlier, sometimes the problem _is_ management, and even when it's not, it can sometimes be a risky proposition to be too negative to your boss (ESPECIALLY if they're a component of what needs to be addressed), so I've seen engineers default to limited disclosure.
So what I mean when I say "spy in the ranks" is something more benevolent than I think I conveyed. Namely, someone who is able to bridge that communication gap by conveying the "risky info" in a way that doesn't put anyone in the line of fire; consider the benevolent motive of "This affects all of us and I might as well put my neck on the line to try and get it fixed if other engineers are nervous to put theirs." I mentioned that I was largely poking fun at my past self, so I'll give a concrete example:
I've been on a team after a manager change. There was discontent on the team, because the prior manager had committed to but not managed to complete some QOL things the engineers has requested prior. The new manager was not really aware of this, but the engineers, having been burnt, were not super eager to spend time/effort/political capital to re-surface the issues, even though if addressed they would make life substantively better. I was in the lucky combination of both having some prior rapport with the new manager, as well as having a more senior role that gave me more confidence to "make waves", so I was able to slip in a comment of, "you know, there's X issue that you might not have been aware of. Not going to name any names, but it might be nice to re-surface this."
So to your point: is a culture of open sharing the goal? 100%. And I would be remiss to use the word "Eavesdropping." I wouldn't recommend an avenue to this information that requires "listening in" such that it would break trust. I primarily intend to convey there may be ways to get that information as a process of _building_ trust; the trick here (and why I use the difficult words) is to find the most effective ways to get to the real and honest ROOT of that, which can be hard to bootstrap from a trustless environment, and often requires finding some way to connect with engineers who can see the whole picture and will give you the straight and narrow, ideally in a blameless fashion. (Further to your point; that aspect (blameless) is something very important to build in this conversation, making it VERY CLEAR this is a culture of mitigation and improvement, not fault. Makes it easier to have more of these channels open and conversations in the future)
While there may well be a backend issue, in many cases, the HAR file contains tons of useful details (in my product's case) for things like "what were responses from other service calls, was anything failing locally, was any state in a weird... state" that can then let me better understand what's going on in the backend, or even know where to be looking in the backend. These large services are _so complex_ nowadays that looking at a slice of backend logs without the frontend to dovetail can often be a very partial view of the world, or be a needle-in-a-haystack scenario.
I'm giving them the benefit of the doubt here that it's similar to my project, clearly, they could maybe just be running a script (since we similarly request a HAR for all reports, since 99% of the time in practice it _is_ very useful), and you won't be harming anyone from trying to get a clear answer as to if the PG/triage group actually needs it to move forward and pushing back if they don't.
I also imagine that, if they're anything like us, you could request explicit deletion of all your support data from that case after the case is done, and they'd have to comply per GDPR/etc (We certainly would) and they likely already have to silo the information in ways that explicitly makes sure that sort of PII doesn't end up in buckets it shouldn't. I don't know if this moves the needle for you, CC #s are still touchy, but just thinking out loud.
Anyway, I hope this doesn't come across as apologetic for lax security practices, just wanted to give this perspective as I just remember the feeling of frustration of the customer refusing to send logs with a similar justification and my going "but it's going to be _much_ harder/impossible to diagnose your issue without that, and I have 0 doubts in my team's ability to properly handle and dispose of secure data as professionals, we are literally legally obligated to."