It gets difficult when you have users saying they can't connect to each other. Then you have to get a better grasp on networking to understand why they can't, sometimes staring at Chrome's webrtc-internals page hoping something clicks. Otherwise you'll have your hands tied and just assume their network is incompatible. Even with a TURN server configured, the same problem can occur.
This seems like a good start to understanding Electron security and why using it to do what the documentation expressly states is unwise might be less than optimal.
Can you give a specific example of what is wrong with Min's security configuration, assuming it is following Electron best practices. Asserting that the security model is bad and linking to Electron's security tutorial is not helpful.
For my own part, I find the introduction that specifically warns that Electron is not a web browser and should not be trusted to handle potentially malicious code from over a network to be clear enough. I understand that this is an opinion that not everyone will share.
For a single specific example, look at the information on permissions and compare to how min handles them. I also see no functionality that attempts to determine if code is malicious or not. Chrome does have measures in it to do this.
That said, I need to be clear. The matter at hand is not a matter of mere configuration and cannot be addressed by better configuration of Electron. Chromium was designed and built to run in a very hostile context. Electron has been built to run in a much more trustworthy context. There is no amount of configuration that will turn the latter into the former because it is not purely a difference of configuration.
Electron's security model is not bad in any absolute sense. It's designed for a particular context and set of scenarios. Dropping it into a very different one with very different needs makes it a poor fit for the job at hand. You may as well descend into a volcano with a home stove potholder.
I hope this has clarified matters. I understand that some people will be very discouraged by the stance I have taken on this. I have no desire to crush their dreams, only to ensure they make good and wise decisions around security.
First and foremost, electron runs on often outdated versions of chromium which are vulnerable to known 0days.
Electron RPC also makes it really easy to get RCE if you don't implement it properly, and most JavaScript developers don't implement it properly. Electron also does not have anywhere near as much security research into it.
It's probably worth mentioning that WebTransport just shipped in Chrome 97 (2022-01-04), which seems to be a worthy successor to WebSockets [0]. It allows for reliable and unreliable modes which is a problem for games using WebSockets, among other things.
> We are generally in support of a mechanism that addresses the use cases implied by this solution document. While major questions remain open at this time -- notably, multiplexing, the API surface, and available statistics -- we think that prototyping the proposed solution as details become more firm would be worthwhile. We would like see the new WebSocketStream and WebTransport stream APIs to be developed in concert with each other, so as to share as much design as possible.
I know, we're very excited about WebTransport and what it can offer. As you say, on the surface it seems to provide both a more performant and reliable transport for realtime communications. Once it hits mainstream, we'll be certainly adding it as another transport we support in our stack (currently websockets, HTTP, SSE, MQTT etc)
As someone who is intimately familiar with the Chrome extensions internals and is not employed by a big tech company, I believe most of the changes seem like a step in the right direction.*
I've been working towards implementing greater support for Chrome extensions in Electron which has involved reading and interacting with Chromium code [0].
- Using service workers instead of a hidden background webpage is more idiomatic for web developers.
- Forced non-persistent extensions guides developers to a better implementation which relies on less resources.
*The deprecation of webRequest's blocking behavior is what's most concerning. The implementation in Manifest V2 requires sending a message back and forth between processes with JS processing for each network request which seems to be in part why they redesigned it.
However, that optimization costs so much for innovative ad blocking technologies as gorhill of uBlock Origin has mentioned. When ad blocking begins requiring new methods of detection or filtering, it'll now be up to Chromium maintainers to implement support for it in the new declarativeNetRequest API. This is a tradeoff of performance for reduced flexibility where it is absolutely needed.
Are these changes actually needed, though? As much as it makes sense to use service workers, for instance, this seems like a rationalization to shoehorn in Google's anti-features.
It's not like background webpages are broken or even hard to use. It's not like everyone's clamoring for their ad blockers to use less resource or for Chrome to be faster.
There was a time when I switched to Chrome because I believed it to be superior. Now that I find the extensions I use to be nearly as important as the browser itself, I can't imagine why ad-hating privacy-focused individuals would punish themselves by using Chrome. Firefox has a few performance quirks in contrast to Chrome, but overall it's in a state where it competes in most cases. As much as I can complain about Mozilla's organizational issues, I can be far more assured that they aren't going to cause my extensions to become nerfed for A Good Reason (TM).
What's strange is my adblocker makes everything run faster. So making the ad blocker faster at the cost of being less reliable seems like the whole system will be slower in general.
> Does anyone seriously believe that an advertising company wants to improve the performance of ad blockers? It's obvious what Google is doing.
I believe some people at Google want to make plugins more efficient, some want to kill ad blockers and probably a few other reasons. Obviously Google is externally (and probably internally outside of specific teams) playing up the efficiency concerns. And I don't doubt most advocates we hear honestly think primarily about that.
That said, if you claimed they got the clout and priority to do that because of the ad concerns behind the scenes, I would say "duh"
I remember some people saying Safari's extension changes and specific content blocker API would be a good thing because ad blockers would use less resources.
The change happened, uBlock Origin broke for Safari and here we are several years later and the Safari ad blocker ecosystem is an absolute joke and most of it barely works or demands subscription fees (and the ones that do are certainly not worth paying for because they don't even block YT ads)
Enrolled in the Orion browser beta and haven't looked back. I get Safari's engine with all the energy optimziations with the ability to run uBlock Origin, Dark Reader, and they're working on greater WebExtensions API support.
I still use Safari for banking and eCommerce because its beta, but for everything else its wonderful. I even get a quality vertical tabs implementation built into the browser; can also shrink the top bar to pre-14/15 size in combination.
The browser will eventually be behind a paywall once the beta is up, but I'm all onboard for paying for an alternative to both Chromium and non-XUL Gecko.
It's such twisted economics for somebody to make a video, a platform to distribute it and an adblocker company to reap the benefits through its subscription fees.
I'd argue the same folks are ok with looting Neiman Marcus stores during some protests because "they've rigged the system and are all rich anyways"
The one I posted is free, I have no idea why you're answering to me.
I also don't like people doing bad things other people's property. This is why I use AdBlockers: to prevent those platforms from running shit I don't want on my computer.
That’s not true re the Safari ad blocker ecosystem.
We develop a Safari ad blocker [1] that works on iOS and macOS which provides performant and private ad blocking. Unlike previous ad blockers using other extension mechanisms, it also can’t see which web pages you visit. We recently released best in class YouTube ad blocking features too. The mechanisms for doing this is different, but the ad blocking results are as good with better performance.
did you ever notice how the only people who ever say anything positive about Safari's adblock ecosystem are those who literally sell adblocker software?
It is like clockwork.
Despite the fact that most of your posts on HN are ads for magiclasso, the fact remains that even most basic features (like whitelisting or blocking cookie banners) require payment.
Furthermore, you do not even come close to uBlock origin. Of course, we both know this, because it simply is not possible. Apple does not allow it. And yet, you continue to state the opposite even though it simply is not true.
On other platforms, using *entirely free* addons like uBlock, you can zap away annoying elements/bars/overlays... or enable some requests while blocking others selectively. You can block videos on some news websites, but allow javascript galleries, and do the opposite on a video site. You can block that overlay disabling right clicks or hijacking the scroll bar.
Once you know that it is possible, you do this every day.
None of that is possible with your product, magiclasso.co, no matter how much money I pay you or how many ads you write on hackernews.
There's a fine line when shilling your own product here. One should be humble.
If you write: Yes, compared to other platforms, the adblock ecosystem in Safari is absolutely dismal. However, we have this product where we are doing our best...
Okay...
Does uBlock Origin have a lot more customisable power user features? Yes. Are they relevant to the majority of users who want to be able to enable an ad blocker and get great results without a lot of fuss? Probably not.
Does uBlock Origin also use a slow, memory and performance inefficient means of blocking ads? Yes.
Does uBlock Origin also use ad blocking ruleset that have thousands of obsolete rules that are rarely pruned, leading to the complaints that Safari only supported 50,000 rules in a single extension? Yes.
There's a lot of Pros and Cons with different products. uBlock Origin has a lot of Pros for certain types of users and it's a fantastic tool – but it's approach to ad blocking is becoming legacy at this stage. They should be planning to re-architect their approach to suit a more modern, privacy focused API that is supported by the two biggest browser makers.
I am really not breaking new ground when I say that the "modern API" is entirely neutered. It has been discussed here at length. It is so neutered, that literally no one uses it except where it is mandatory.
And here is the real banger: YOU DON'T EVEN USE IT when you try to block ads on youtube.
Let's recap:
You are worse at blocking ads, because you can not block dynamically and the user can not add rules to sites or elements. For example, whenever my favorite news site fixes its ad block blocker, I'd have to wait for you to update the block list instead of just killing the new script. This happens on the reg, and you can't do anything about it.
Or consider websites who hijack right-clicking or scroll bars. Consider people who have to use usability tools to make those sites work for them, like text2speech. Your product doesn't do a single thing there.
Let's recap more:
You have "best in class" ad blocking on youtube? uBlock blocks all ads, period, with 100% success, on any video site. For years now.
Your product? "More or less" perhaps a good description?
And best of all, you have to follow 1Block and inject your own browser addon, literally breaking your privacy promise to the user for EVERY WEBSITE THAT HAS VIDEOS.
This is not even close to being a good option, but you come here and say your ad blocker is more privacy conscious when it just isn't (if it is supposed to block ads). What?
Let's move on:
You can't block trackers because you cannot block fingerprinting. You only have a block list when we now know that's not enough. You can't do things PrivacyBadger does, since the EFF has already determined it doesn't work due to the new and "improved" API.
You are selling snake-oil here.
So. Even without any expert features, your product is simply inferior. You can not even hold the promise of privacy, because you literally need to break it to have any chance of blocking anything on youtube. Well guess what, there are more sites than youtube out there.
None of this is news. We have been through this many times. In every measurable way the "legacy adblockers" are superior.
What IS necessary to discuss is you having the gall to come to this website and market your product with obvious falsities - things like the new API being anything but ineffective, and then going ahead and posting the refutation of exactly that point on your own website [1].
>Does uBlock Origin also use a slow, memory and performance inefficient means of blocking ads? Yes.
Is this true? It's been a little while but last time I looked over things it seemed like gorhill implemented a rather efficient machine. I'd appreciate if you could expand on this.
I mean, it’s anecdotal, but all those features are ones I never knew existed and I’ve used ublock origin for years.
I was always fine with _some_ ads but eventually got ublock when the internet hit this critical mass of being all ads all the time. If safari adblockers can keep the browser experience _mostly_ ad free out of the box then they are equivalent to me as an unsophisticated user at least
For me, once Apple made that decision, I started migrating away from Safari, and I haven't tried your product. I note that it does have a pro subscription option -- which I'm not opposed to -- but I do also note that this seems to be much more common than the "donationware" licensing model of most other browser extensions.
Out of curiosity, can Magic Lassoo present a detailed list of domain connection attempts by category, i.e. do anything like uMatrix does? The thing that keeps me on FF, even on MacOS (aside from warm fuzzy open source feelings) is that I really think the extension ecosystem is the best -- uMatrix, greasemonkey and the ilk are brilliant. I like Safari's isolated private browsing mode most of the time, and I like its dev tools. But the adblock situation is just so much better on FF; it makes the web usable again whilst respecting my privacy ideals. I really like being able to say 'Thou shalt not set thine cookie and contact all of these domains via an XHR request' and the site just...continuing to work.
No matter what all these adblocker advertisements tell you here on HN: Safari only allows these extensions to have a single blocklist and then your choice is whether to enable or disable the adblocker extension, with all its fixed and non-dynamic rules, on the website in question.
From that perspective, Safari adblockers are virtually identical, simply because they are all using the same interface and (I would suspect) resell blocklists you get to use for free elsewhere.
It's people selling you a subscription product that is vastly inferior to any free extension on Firefox (not on iOS obv) and the same discussion has been had many times before.
I mean, I don't want to be a negative nancy here, but it does get annoying with these ads that seemingly have lost all perspective of how bad adblocking on Safari truly is.
Not exactly, you can have multiple blocklists limited to 50k entries apiece. Many Safari content blockers support that.
Safari content blocking (and thus Chrome v3 manifest blocking) basically works OK at blocking ads today. The problem is this is an arms race, and as the advertising agencies come up with inventive ways to evade these strictly controlled content blocks, they have no real way to adjust.
At that point we'll need to rely on Apple or Google to add new features specifically to support blocking ads. Google seems particularly unlikely to do that. To say the least.
And even if they do, there will be long periods before new browser releases are available with those features, and then the blocker developers need to support them.
> the ad blocking results are as good with better performance
I invite you to go through all daily commits made in uBlock Origin's specific filter lists to solve reported real-world issues[1], and find out if every single one of these issues can also be solved in a typical Safari content blocker, just as they are immediately solved in uBlock Origin.
For instance, it would be an interesting exercise to find out how many of the fixes committed between Sep. 21 and Sep. 27 inclusively can or cannot be also be fixed in a typical Safari content blocker.
I don't use it, but it seems to be free, with an optional "pro" subscription for some extra features. The subscription pricing is only mentioned on the App Store page, and appears to be $3/month or $30/year.
Your claim that service workers are more idiomatic than background pages ignores months of debate and examples to the contrary collected by the w3c web extensions group. [0]
This could be an area where MV3 walks itself back. One proposal creates an Extension Worker which is a new concept like a Service Worker but better matches the use cases for background scripts. Another simply puts background pages back, but behind a permission.
Thanks for mentioning this. I've been aware of this group since its announcement, but have been ignorant of the ongoing discussions.
Hopefully Google and others are receptive to some of the proposals made in the issues. I recognize the value of reintroducing the persistent capabilities to the SW model.
You think it is a step in the right direction while acknowledging it breaks adblockers. You're going to have to explain why you're cool with that, because as it stands your post just isn't cohesive at all (as far as I can tell).
This isn't a single, monolithic change, there's plenty of changes between manifest V2 and V3. GP said he thought most of these changes are a step in the right direction, while expressing concern about one of the others. That seems like a cohesive and nuanced opinion to me.
It sounds like deflection and rationalization to me.
Not all features are equally important, the one seeing a regression is much more important, it's also the feature with a conflict of interest, and the conflict of interest lies in the direction of Google pushing this through over everyone else's objections.
I was in the process of writing a reply when I realised you presented the same arguments in a much more concise manner. For the record, this is what my problem was with the argumentation presented.
I am an extension developer, but have resigned from engaging with development in the ecosystem. One of my extensions has >300k subscribers on the Chrome Webstore which will be killed by MV3.
Many ongoing changes are being made in extensions and the web in general to improve security while reducing capabilities in existing applications.
At this point, for more complex use cases such as one of my own, the only hope is building your own web browser with complete control over its systems. I've changed focus to improving Electron for this reason.
Ideally, I'd like to see MV3 continue supporting the persistent context use case as well as maintaining webRequest blocking support.
>Ideally, I'd like to see MV3 continue supporting the persistent context use case as well as maintaining webRequest blocking support.
Same, which is why I engage with browser representatives in the W3C WebExtensions Community Group.
Unfortunately, the status quo is grim with Firefox seemingly uninterested in standing up to Chrome and citing compatibility as the main reason for following Chrome into mandatory Service Workers.
I appreciate that yourself and other folks are engaging in the community to request improvements.
Prior to the group being formed, most discussion regarding MV3 occurred on the Chrome Extensions Google Group [0]. While feedback was accepted and open there, I hadn't seen the Chrome team acting on it to make changes. That's where most of my pessimism on the situation comes from.
I believe the Chrome team's main motivation is removing any functionality in MV3 which would have the possibility of reducing performance in normal browsing. I personally don't have much hope that they'll be backpedaling on any changes.
> the changes seem like a step in the right direction [...] However, that optimization costs so much for innovative ad blocking.
This is fair. For an ad-blocker to be effective today it needs to be invasive, and that doesn't apply to most extensions.
It is too easy to grant invasive privileges to v2 extensions for those that do not understand the consequences. Downloading a whole new browser on the other hand is a far more obvious way of implicitly granting that trust... So I wonder if when push comes to shove, a "uBlocked-Chrome" browser might emerge. To be clear, I am suggesting a uBlock integration project, not a preservation of V2 for extensions.
I don't think that will work because Google controls Chromium. They will play a long game to sabotage the abilities of smaller Chromium browsers to block ads. Advertising is their business model and they have a lot of money to spend on crushing smaller browsers that have a different vision of what the Web should be.
Google is full of smart people who get paid to deal with obstacles like that. If your goal is to block ads and tracking, it's extremely unwise to depend on software that is fundamentally controlled by an ad company. If someone threatens their business model, they will throw an overwhelming amount of money at the problem. They are boiling frogs, so most people won't notice. Killing uBlock Origin and disallowing browser extensions on mobile are just small steps in a long-term plan.
Which ones? HN does, but a large part of the other sites I frequent need around a second or more to load. With or without ad-blockers - some load faster with, some faster without, but they never enter the "nearly instantly" range, which (last I checked) was 0-250 ms.
Yes, if you crush your computer into a cube you won't see ads again either. But people want to keep their computers and block content they don't like, so there's "problems to solve" there.
The problem of not disabling JavaScript and not seeing ads. I.e. granting users control over the code their browser runs that's finer-grained than "nuke it from orbit".
Not entirely sure on the actual origins of this specific number but I think a crucial piece is that it passes the Luhn algorithm check [0] that is used to validate card numbers (and in generation of them to make single digit errors not result in another valid card number). 42 itself also passes the test but card numbers usually come in blocks of 4 digits so 4242 probably seems more card-like.
As to where the 42 from the Guide came from, I would recommend consulting The Hunting of the Snark.
Wouldn't this completely break accessibility support of such web apps? This is part of the reason why omitting the DOM and rendering a UI with WebGL isn't the best idea. Maybe this could be resolved by sending the accessibility tree to the client, but it seems like a step backwards.
Loom does this while the video is being recorded to give you the link as fast as possible.