Hacker News new | past | comments | ask | show | jobs | submit | kuhsaft's comments login

> Smartphones and the internet have given the layperson awesome technology literally in their hands.

The quote is "awesome technological powers", which, I think, is different from having a technological device. There are the data brokers, social media giants, and governments that have the technological power to manipulate the masses.

> The entire election of 2024 was driven by the people specifically questioning those in authority

The quote: "when the people have lost the ability to set their own agendas or knowledgeably question those in authority". Are they serving their own agenda or the agenda of others through the media they consume? Are they knowledgable in their questioning?


> Are they serving their own agenda or the agenda of others through the media they consume? Are they knowledgable in their questioning?

Are you? I bet you think you are knowledgeable in your questioning, fully in tune with reality, serving your own agenda and above “their agenda”. I’d estimate that you probably are. Seems to me that most people are capable of understanding what is important to them so I don’t buy into the mass manipulation thing.


> There are the data brokers, social media giants, and governments that have the technological power to manipulate the masses.

During Trump's inauguration, it was a bunch of technologists with front row seats, not his government cabinet picks.

* https://www.kron4.com/news/national/bay-area-tech-ceos-get-f...


I think the point is a collapse of the existing system and consolidation of power. And, I think it'll only embolden other megalomaniacs.

Maybe when weapons were more limited in destruction. But, now the government has weaponry supremacy, and I don’t think you would want anybody to have access to artillery, fighter jets, etc.


> Do tell because as far as I'm aware Maxwell's equations don't have an asterisk on them that say "doesn't work below 1 GHz".

Did you really just pull out Maxwell's equations?

EM interacts with matter in different ways. Glass hardly attenuates visible light, but wood does. 2.4 Ghz can pass through walls better than 5Ghz.

There's the concept of permittivity wherein Maxwell's equations are defined in free space with vacuum permittivity.

https://en.wikipedia.org/wiki/Vacuum_permittivity#Permittivi...

To accurately model EM waves, you need more than just Maxwell's equations. You require material equations to model interactions of EM with media.

If you want to get really advanced, whereas Maxwell's equations are classical physics, there's Quantum electrodynamics (QED) which can model interactions of EM and matter.

https://en.wikipedia.org/wiki/Quantum_electrodynamics


> There's the concept of permittivity

> You require material equations to model interactions of EM with media

> Quantum electrodynamics (QED) which can model interactions of EM and matter.

It's amazing how condescending some people on here are; how could you possibly have missed literally in the first sentence of my response

> ... my physics degree


> It's amazing how condescending some people on here are

You literally started your comment with "Lol news to me", then you used your degree as if it made you more knowledgeable than anyone else here. Take a look in the mirror?

> ... Do tell

I did?

The extra information isn't to condescend. It's for other people that want to know more about the science.


RE "....Glass hardly attenuates visible light...." Clear glass blocks about 5% visible light


Depends on the frequency of EM. Fiber optic communications use specific frequencies to minimize attenuation in cables.

https://en.wikipedia.org/wiki/Optical_fiber#Mechanisms_of_at...

Same with communications over coax. Obviously visible light doesn't transmit well over copper, but a spectrum of radio waves do, some better than others.


Fiber optics also uses _exceptionally_ clear glass.

If the ocean were as clear as your average long-distance fiber cable, you would see down to the bottom of the Mariana Trench (also in the range of visible light, AFAIK).


> Fiber optics also uses _exceptionally_ clear glass.

Clear in certain wavelengths. Depends on the composition of the glass.

https://en.wikipedia.org/wiki/Optical_fiber#/media/File:Si_Z...

Silica glass behaves differently from ZBLAN (fluorozirconate glass).

Which goes to show how complicated EM interactions with media can be. It's generally easier to just empirically measure attenuation through some medium and use the empirical measurements as a model.


It's exceptionally clear compared to e.g. window glass even in the visible spectrum of light. You can shine a red light source into a 10 kilometer standard G.657 fiber (optimized for 1310/1550nm, i.e. deep infrared) and it will still be visible just fine on the other end. If you did that with regular glass, it would hardly go ten meters.


What are the relative contributions of the total internal reflection property of the fiber optic cable and the particular low-attenuation material it's made of?


The total internal reflection is to keep it focused, it's in a sense a different question.

IIRC, when Corning Co. first started working on optical fibers, the best available glass would be good for sending signals about ten meters. What was improved was not the total internal reflection; it was the purity of the glass.


Oh yeah. I'm not saying otherwise. Someone replied "Clear glass blocks about 5% visible light". I guess "clear glass" is pretty subjective. At what level of attenuation would someone consider glass not clear? xD


> To all the engineers working on this stuff, I hope you're happy that your work is essentially destroying the world that you and I grew up in.

That was a world where the user base was much more limited and devices were less capable. Now we have children, grandparents, educated, and uneducated users with access to web connected devices. These devices now contain everything about you. Compromise of a device can destroy someone’s life.

Not only that, but compromise of a device can cause collateral damage to other devices on the same network.

We now have to cater to every user. Not just to the technologically adept. Look at what people believe on social media. The bar is so low to con people into compromising their device.


The problem is one of balance.

Write insecure software and you'll get screwed by hackers. Write secure locked down software nobody can touch or modify, and you'll get doubly screwed by a large corporation that wants to pound every penny they can out of your bloody corpse, upto the point your device is compromised by the corporation who can do whatever they want, but you cannot tell.

There is no win situation here, there are only trade offs.


Still a shit poor pathetic excuse to screw over the userscript/grease monkey users.

The browser is called a user agent, but this shift to absolute security no matter what, no say about it is a shift to native apps, is a shift to the developer is in control, is a shift to this being Google and the sites browser, not ours, and that being done unilaterally with nearly no opt outs is the sort of mega tectonic shift that ruins this magical special unique place in software where users had some say in what was happening. We cannot pander to imagined ever worsening users forever.

It feels like the things being done in the name of security are really building an immense prison. The work being done to allow verified age and identity checking ranks up there highly in the this corals humanity, area, not giving us agency.


> Still a shit poor pathetic excuse to screw over the userscript/grease monkey users.

Tampermonkey still works fine with MV3

> We cannot pander to imagined ever worsening users forever.

The most popular software/hardware will always pander to the most users. That’s why they’re the most popular.

You can’t complain about the most popular option pandering to the most users. Well, you can complain, but you might be in the minority of the users.

> It feels like the things being done in the name of security are really building an immense prison.

I get that, but we are running so much untrusted code on our machines now. Applications that use thousands of dependencies with the hope that someone spots a bad actor.


The prohibitions against running code dynamically are quite severe. It took a long long time & there's some work to make sure userscript/contrntScript extensions aren't totally shit out of luck (after years and years of delay & nothing), but whole domains of extension - anything where you run code on the fly - have been outlawed.


> That was a world where the user base was much more limited and devices were less capable. Now we have children, grandparents, educated, and uneducated users with access to web connected devices. These devices now contain everything about you. Compromise of a device can destroy someone’s life.

Kids these days have much worse computer skills BECAUSE of the locked up platforms they are exposed to from a young age. Meanwhile two decades ago my non-technical grandpa learned to use a real PC just fine in his old age. Don't underestimate regular users ability to deal with technology when there is a will.


> Compromise of a device can destroy someone’s life.

So in order to prevent a hypothetical hacker bogeyman from getting our data we gladly entrust it to corporations that actively squeeze every possible cent out of it by, among other things, giving access to it to other corporations and uncountable "partners" that will feed us content with the goal of psychologically manipulating us into buying things we don't need, or thinking things someone else wants us to think, destroying the very fabric of society in the process.

I somehow find all of that delusional, our acceptance and support of it nightmarish, and trust hackers to be less diabolical in their schemes.

Computers should serve us, not the other way around. The solution to these problems is tech education, not tech babysitters.


On the contrary, MV2 used onBeforeRequest which let extensions see what requests you were making. They could then take that data and use it for malicious purposes.

MV3 doesn’t allow extensions to know what requests are being made, so extensions can’t use your data maliciously.

Requests to ads that are blocked are blocked.

I think you’re thinking of Privacy-preserving ad measurement which is an option in Firefox and Safari. https://support.mozilla.org/en-US/kb/privacy-preserving-attr...


> On the contrary, MV2 used onBeforeRequest which let extensions see what requests you were making. They could then take that data and use it for malicious purposes.

Which is something we know for a fact uBlock Origin doesn't do. It's open source, you can check the code yourself. MV3, on the other hand, doesn't do much to assure me that an addon isn't phoning home. Why not just give the user to ability to block network requests on a per-addon basis? Too difficult a task for the trillion dollar company? Or could it be that forcing users to switch to MV3 addons isn't about safety at all?


Doesn't onBeforeRequest still exist in Manifest v3? The thing that's been removed is the ability to block on it, not the ability to register handlers for requests.


It still exists, but now “ad blockers” can’t use the blocking API to record and forward metrics on hits. Ad blockers don’t even need the webRequest and webRequestBlocking permissions anymore.

Now, if an ad blocker has webRequest permissions it’s a red flag.

For example https://developer.chrome.com/docs/extensions/develop/concept... uses webRequest to send telemetry back to some remote server.


Thanks, I see how that can help.

With Manifest v3, let's say I'm an ad blocker and I want to get access to metrics not to violate privacy, but just to report them to the user (X domains blocked, Y out of Z requests blocked, etc). How would I get access to those metrics?


Separate permission for debugging only available for development essentially. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

Otherwise, you can’t really without more invasive permissions.

https://stackoverflow.com/questions/74813523/chrome-extensio...


Oh wow, that's wild. Closing the loop on reporting things is such an important part of a trustworthy user experience.


but op wasn't talking about what extensions are seeing, but what the ad servers do. You haven't address their point at all


onBeforeRequest was removed because it is a massive spyware and malware vector.

> I do get that this sounds like conspiracy theory.

> … was not a coincidence.

Could it be that it was coincidence? Do you have a solution for reducing extension malware without removing onBeforeRequest?


> onBeforeRequest was removed because it is a massive spyware and malware vector.

Yet you can still inject js right into the page. You just can't stop a page that was going to load from loading. They could have taken away the onBeforeRequest redirect capability and left just the onBeforeRequest cancel capability.

Not sure I've heard of any spyware/malware depending on just that cancel capability.


That uses a different manifest permission.

https://developer.chrome.com/blog/crx-scripting-api#breaking...


That's remotely hosted code...also a problem, but you can inject code that's not remotely hosted.


The point is that it’s a different permission.

https://news.ycombinator.com/item?id=41812416

If you are really privacy conscientious, ad blocking extensions should be able to exist without any access to web requests now.


I feel like we're losing the plot here. Removing the cancel capability of onBeforeRequest didn't improve security much. It did, though, hobble ad blockers to just dealing with static lists if they want to prevent an ad from downloading in the first place.

Removing the onBeforeRequest redirect didn't add much security either, since you can just ask for permission B instead of permission A and just inject code. Though, ad blockers don't need that anyway.


It’s insane to think that an extension with the ability to snoop on all your requests is more privacy oriented than one that can’t.

It’s insane to want extensions to snoop on all your requests in an attempt at more privacy.


It only sounds insane because you're saying "want extensions to snoop" to describe "want extensions to run a function call locally".

It is a permission that could be used by a malicious extension to snoop, but that is far from the only use. Wanting the permission != wanting snooping.


Well, I would allow it for one specific extension that I feel does more good than harm for the capability. Call me insane.


I made a plugin for scraping using onBeforeRequest. It's very useful.


> The only way this is an improvement if you think the blockers are malicious

Extensions and in turn MV2 blockers can easily be malicious.

https://usa.kaspersky.com/blog/dangerous-chrome-extensions-8...

Look at how many in Kaspersky’s list are advertised as ad blockers. The majority of users aren’t tech savvy like HN.


> Look at how many in Kaspersky’s list are advertised as ad blockers

By my count 5, 6 if we include "Autoskip for Youtube", out of 34. That might be an argument for dropping extensions, but I don't think it's an argument for breaking ad blockers.


> That might be an argument for dropping extensions

Those extensions used the same API that ad blockers used, but for malicious purposes.

So, you would support removing that API? Well, that’s what they did for MV3 and implemented an API just for ad blocking.


> Those extensions used the same API that ad blockers used, but for malicious purposes.

Sounds like an obvious chance to flag the extension for further review, and probably a warning on the user side.

> So, you would support removing that API?

Of course not; that's throwing out the baby with the bath water. This brings us back to the "further review" thing; there's plenty of precedent for a platform having API surface that only a smaller subset of apps/extensions are allowed to use, because the features it exposes are legitimately needed for some things but it could be abused so it gets flagged and you have to write a detailed explanation for why your thing really needs this permission and then the reviewers can look at it particularly closely.

> Well, that’s what they did for MV3 and implemented an API just for ad blocking.

And then for bonus points they hobbled it so that it couldn't be used to make as good of ad blockers, which is why the whole thing is not okay.


It’s similar, but not the same. Safari lets you dynamically generate rules that are then compiled for privacy and efficiency. The limits were increased to 150000 rules per content blocker due to user demands [1]. And each extension can have multiple content blockers.

MV3 has a measly 30000 static rule limit. These rules are included with the extension and cannot be updated dynamically. And a 5000 dynamic rules limit. [2]

EDIT: Chrome now has a 300000 shared pool for static rules for extensions that go over their 30000 limit. And a 30000 dynamic rule limit [3].

[1] https://adguard.com/en/blog/adguard-for-safari-1-11.html

[2] https://adguard.com/en/blog/adguard-mv3-beta.html

[3] https://developer.chrome.com/docs/extensions/develop/concept...


The limit is 330000 rules:

"Based on input from the extension community, we also increased the number of rulesets for declarativeNetRequest, allowing extensions to bundle up to 330,000 static rules and dynamically add a further 30,000." https://blog.chromium.org/2024/05/manifest-v2-phase-out-begi....


It looks like it’s a shared quota now with a minimum per extension [1].

Still sucks that the rules are static though. AdGuard devised a method to diff ruleset changes with the built in rules to generate dynamic rules between extension updates. So, I guess it works.

[1] https://developer.chrome.com/docs/extensions/develop/concept...


I’ve been using AdGuard. There are some limitations with MV3, but it’s not noticeable [1]. AdGuard uses dynamic rules for updating rules between extension updates and for custom user rules. There’s the option using their system level AdBlocker too.

[1] https://adguard.com/en/blog/adguard-browser-extension-mv3-re...


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: