Don’t worry, Google is committed to ensuring parity for all browsers.
It’s just they’re approaching it from the strategy of “all browsers become Chrome or reskins of Chrome”, not “things will actually work for non-Chrome browsers”.
Years ago I tried to tell Chrome to block all google cookies. Turns out cookie blocking doesn’t (or didn’t) work for google domains, but worked fine for non-google domains.
Now I don’t use Chrome, only use privacy enhanced forks of Chromium like Ungoogle Chromium (plus Firefox).
If we do, what are the chances it makes it far enough to set precisent rather than just settling and Google paying a nominal fee to nowhere and continuing
It’s said that an ethical software engineer could not write bombBaghdad() only bomb(Baghdad).
I wish we could set the record straight just among software engineers that this kind of self-serving is immoral and wrong. It shouldn’t be the companies pushing back against this kind of thing, it should be the people who work for them.
It’s sort of like saying “Clearly this law is unjust, because it would hurt me its creator”. But instead of changing the law you just give yourself a pass.
It’s hard to imagine bomb(place) being something where you would not even consider the ethical implications. Contrast that to “let’s just expose this API, we don’t want to support it so we’ll keep it private to google domains, that way meets can try to improve performance” and not realizing that you’re potentially being anti-competitive.
Yes, the point of the joke is that software engineers have tremendously shitty ethics; the special-casing in the joke is supposed to be an example of missing the bigger point while emphasizing technical details. I’m not sure if the parent comment misunderstood the joke or is just focusing on the minutia.
Really, you find that hard to imagine? I imagine most of the code that is required for dropping real bombs was written without a moral second thought, like code to compute fall time, say, which has many uses. I find it less convincing that the people making the bombs are morally culpable, because usually making the actual bombs comes only after a society has made a decision that bombs will be used. The software engineer who builds an anti-competitive system without being told because they don’t realize they have any moral agency or responsibility is somehow less sympathetic to me.
My point was just that in the real world there aren’t very many dropBomb() methods, yet people still manage to build systems that are effective at causing harm. Facebook allowed its products to foment a genocide, and it wasn’t out of malice just apathy and institution-wide ignorance that it was capable of that kind of damage.
This seems risky, are there are Google subdomains that allow for arbitrary file uploads like what Microsoft has? (which has been a huge source of scams and phishing attempts) If so, I can see this being exploited.
I saw someone in another conversation say that any XSS on a *.google.com domain is a guaranteed bug bounty - they’re pretty good at using alternative domains for hosting user content.
In fairness, Firefox does the samething. But it seems pretty clear to me that these are essentially just extensions of browser features into pages supporting the browser, not Mozilla treating a completely unrelated product preferentially.
Honestly I don’t think it’s particularly harmful - as far as I can tell Google use it for performance diagnostics for their video chat tools. The only fingerprinting input it provides is the platform and number of CPUs, which isn’t much more than what you get from the user agent.
The argument against it that I buy into here is that it gives Google an unfair advantage - other competing video chat implementations can’t provide the same level of diagnostics as Google can, because they are abusing (lightly) their ownership of the browser.
This doesn’t mean they’re actually using it this way (or that Chrome isn’t already reporting this kind of info regardless of whether or not the privileged API is ever called), but presumably it’s also a data point that could feed into an advertising profile. It’s not hard to imagine that this would be useful information if you’re trying to infer, say, a user’s wealth.
Don’t worry, Google is committed to ensuring parity for all browsers.
It’s just they’re approaching it from the strategy of “all browsers become Chrome or reskins of Chrome”, not “things will actually work for non-Chrome browsers”.
Years ago I tried to tell Chrome to block all google cookies. Turns out cookie blocking doesn’t (or didn’t) work for google domains, but worked fine for non-google domains.
Now I don’t use Chrome, only use privacy enhanced forks of Chromium like Ungoogle Chromium (plus Firefox).
For what it’s worth I’m not a Chome user, but use Ungoogled Chromium when I want to test things under Chrome: https://github.com/ungoogled-software/ungoogled-chromium
chrome.runtimeis undefined for ungoogled chromium, which may or may not mean that it’s susceptible to extra privilege. My guess is that it’s not.On a Mac you can grab that via
brew install --cask eloston-chromiumI wonder how that slipped through review. Curious to see how it plays out. Will we see a Zoom lawsuit?
I would bet a kidney quite a number of people signed off on it. I highly doubt it “slipped through”, like an accident.
If we do, what are the chances it makes it far enough to set precisent rather than just settling and Google paying a nominal fee to nowhere and continuing
It’s said that an ethical software engineer could not write
bombBaghdad()onlybomb(Baghdad).I wish we could set the record straight just among software engineers that this kind of self-serving is immoral and wrong. It shouldn’t be the companies pushing back against this kind of thing, it should be the people who work for them.
It’s sort of like saying “Clearly this law is unjust, because it would hurt me its creator”. But instead of changing the law you just give yourself a pass.
It’s hard to imagine
bomb(place)being something where you would not even consider the ethical implications. Contrast that to “let’s just expose this API, we don’t want to support it so we’ll keep it private to google domains, that way meets can try to improve performance” and not realizing that you’re potentially being anti-competitive.Yes, the point of the joke is that software engineers have tremendously shitty ethics; the special-casing in the joke is supposed to be an example of missing the bigger point while emphasizing technical details. I’m not sure if the parent comment misunderstood the joke or is just focusing on the minutia.
Really, you find that hard to imagine? I imagine most of the code that is required for dropping real bombs was written without a moral second thought, like code to compute fall time, say, which has many uses. I find it less convincing that the people making the bombs are morally culpable, because usually making the actual bombs comes only after a society has made a decision that bombs will be used. The software engineer who builds an anti-competitive system without being told because they don’t realize they have any moral agency or responsibility is somehow less sympathetic to me.
You quoted a function “bomb”, not a function “calculate fall speed”.
It’s a famous quote/joke https://blog.codinghorror.com/your-favorite-programming-quote/.
My point was just that in the real world there aren’t very many dropBomb() methods, yet people still manage to build systems that are effective at causing harm. Facebook allowed its products to foment a genocide, and it wasn’t out of malice just apathy and institution-wide ignorance that it was capable of that kind of damage.
I’m surprised by their restraint really.
This seems risky, are there are Google subdomains that allow for arbitrary file uploads like what Microsoft has? (which has been a huge source of scams and phishing attempts) If so, I can see this being exploited.
I saw someone in another conversation say that any XSS on a
*.google.comdomain is a guaranteed bug bounty - they’re pretty good at using alternative domains for hosting user content.In fairness, Firefox does the same thing. But it seems pretty clear to me that these are essentially just extensions of browser features into pages supporting the browser, not Mozilla treating a completely unrelated product preferentially.
https://lobste.rs/s/teiyo4/how_firefox_gives_special_permissions
What is the danger with this specific set of data? It’s read only, right?
Is it browser fingerprinting?
Honestly I don’t think it’s particularly harmful - as far as I can tell Google use it for performance diagnostics for their video chat tools. The only fingerprinting input it provides is the platform and number of CPUs, which isn’t much more than what you get from the user agent.
The argument against it that I buy into here is that it gives Google an unfair advantage - other competing video chat implementations can’t provide the same level of diagnostics as Google can, because they are abusing (lightly) their ownership of the browser.
This doesn’t mean they’re actually using it this way (or that Chrome isn’t already reporting this kind of info regardless of whether or not the privileged API is ever called), but presumably it’s also a data point that could feed into an advertising profile. It’s not hard to imagine that this would be useful information if you’re trying to infer, say, a user’s wealth.