Wouldn't it be possible to write some kind of local proxy server with MITM for HTTPS that modifies scripts and supplies the missing functionality for ublock origin?
partially, but it couldn't replicate all functionally. A lot of uBO rules apply to elements on the DOM. Like hiding a div with ID "#ads". That div often isn't sent as pure HTML, but is instead added to the page via JS code executing. At the MITM-level you won't be able to have rules that apply to the rendered DOM.
That said, selector based ad-blocking is still supported in MV3. So might be possible to get most of the functionality with both a MITM-level blocker and an MV3 selector based blocker.
I end up using both because neither is very good. The webmailer one is better at conversation threads. The native one is better at scheduling meetings.
There is not much need for a company like the one selling adblock plus to springer etc. I don't see any court going after ublock origin and there is no reason that ublock origin would be threatened by this in any way. However, the actions from google with manifest v3 are a real threat, as well as any obligation to use real name accounts to access services like newspapers or youtube.
If you right click a link and open in new window (or middle click), the frameset was gone and only the piece in the frame was visible. Also you could not bookmark anything. I remember doing a frameset per content frame url automatically and also redirecting to that frameset from inside the page via javascript if the content frame's url was directly opened.
>If you right click a link and open in new window (or middle click), the frameset was gone and only the piece in the frame was visible.
Feature, not bug in my book. Same thing happens in today's iframes. But for situations where that is a problem, the spec could have been extended to support every page being able to identify a preferred parent frame. Or browsers could have changed behavior to by default duplicate a frame's parent and siblings when opening a frame in a new window.
>Also you could not bookmark anything.
Again a limitation of the spec that could have been addressed rather than throwing out a useful feature. We support have text fragment identifiers in URLs these days; surely we could have supported URLs with multipart frame targets.
They could! window.parent exists for this! Also, the target attribute on a.
For multipart frame targets, the fix then, as it is now, is to parse out the URL fragment params into something reasonable. SPAs use the path for state; no reason you couldn’t use it for frames.
If browsers got around to actually implementing basic features on browser level like making a frame navigation work instead of coming up with new CSS properties that nobody is going to use we could be all building websites without any javascript.
How does this work? Do they demand you to use Azure for your servers so they get a discount? Or do you have to create instances of your product in e.g. VMs that are put in their Azure account? Did you have to completeley leave every last bit of gcp behind? How is this checked by MS?
Related: If you send an e-mail to "Some Name with something interesting" <a.person@company.org> and company.org runs Microsoft Exchange and a.person@company.org is in Active Directory, then Exchange will erase "Some Name with something interesting" <a.person@company.org> and replace it with a pointer to Active Directory and you will never see "Some Name with something interesting".
Like the opposite effect as discussed here. o365 is probably doing the same
reply