Https-everywhere: HTTPS Everywhere extension for Microsoft Edge

[martinsuchan]

Microsoft released in July 2016 Windows 10 Anniversary Update which comes with a new version of Microsoft Edge browser that supports Extensions.
These extensions use similar structure and API as Chrome extensions - porting the existing HTTPS Everywhere extension should be then really easy.

Documentation for developing Edge extensions is available here:
https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/extensions/

[TheRyuu]

Just to update the AU is now out for Windows 10 and so is the documentation for developing extensions[1]. Hopefully minimal modifications are required since it is just the WebRequest API with some minor technical differences to Chrome's.

Just for reference uBlock Origin requires minimal changes to get it working[2].

[1] https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/extensions/
[2] https://github.com/gorhill/uBlock/pull/1486#issuecomment-234380212

[jeremyn]

The current HTTPS-Everywhere development and build process is *nix-centric. I was recently told here that people using Windows 10 who want to contribute to HTTPS-Everywhere need to use some sort of Linux VM. However the equivalent of ChromeDriver for Edge, WebDriver, which allows for command-line browser testing, must be installed on Windows 10. So it seems to me that the build process needs to be made to work on Windows 10, or at least a parallel build process just for Edge needs to be created, before an Edge extension could be created.

[Artoria2e5]

MS Edge uses the common WebExtensions API, which is used by Opera as well. For me it's fine to have the tests come later than the proof of concept alphas.

P.S. WebDriver is also a common W3C API.

Regarding the conversion tool, It looks generally like a lint tool that also adds a bridge for the chrome object. Attached is a sample of its bridge scripts, generated for Stylish 1.3.1-1. (Warning: heavy use of ES6.)
bridge.zip

[dxgldotorg]

Probably want to boycott the Windows DRM store:
https://arstechnica.com/gaming/2017/04/microsoft-formally-bans-emulators-on-xbox-windows-10-download-shops/
Or perhaps publish it as a sideloaded extension? https://docs.microsoft.com/en-us/microsoft-edge/extensions/guides/adding-and-removing-extensions

[martinsuchan]

Note that Windows 10 Creators Update was just released and it contains even wider API set for Edge Extensions:
https://docs.microsoft.com/en-us/microsoft-edge/extensions/api-support/extension-api-roadmap

[elyscape]

@WilliamFeely I don't see how that's relevant to the purpose of this extension.

[dxgldotorg]

If HTTPS Everywhere were to divest itself of EFF, it would be a non-issue, but the latter gives instructions on how to install extensions outside of the Store.

[jeremyn]

Let's not turn this into a discussion about boycotting Windows or Edge. HTTPS Everywhere means providing HTTPS rewrite protection wherever possible, including on Edge.

I believe @Hainish has the WebExtension rewrite on his to-do list. If anyone wants to help make HTTPS Everywhere available on Edge, that effort is welcome, and they should coordinate their work with him.

[xt0rted]

I was trying to get Stylus working in Edge and ran into a number of issues where html5 templates & the extensions api aren't feature complete compared to Chrome, even in v15 which was released this/next week.

I'm not sure if templates are used anywhere but the DocumentFragment api is only partially implemented so properties like .firstElementChild don't work.

The extensions api I had issues with was

chrome.tabs.query({ currentWindow: true }, function(tabs) { ... });

When the currentWindow option is set to true, even with other options, the result is always undefined. Setting it to false returns a result, but that's not how either plugin is using it so it's a blocking issue. I reached out to the Edge team about this and they passed the question on to a team member to look into and confirm if it's a bug, but I haven't heard anything on it yet.

[robinhood2014]

Well, this is not good. I replaced every instance of "chrome.xxx" (where "xxx" represents functions of Google Chrome) with "myBrowser.xxx", and even removed all comments from all JavaScript files referenced in manifest.json, and the Edge Extension Toolkit is still reporting manifest.json as malformed.
HTTPS Everywhere Prototype.zip

[Artoria2e5]

The toolkit does some heavy linting on the manifest. Have you checked for errors around things like the icon stuffs?

[robinhood2014]

According to the toolkit, only the manifest file has errors.

[Artoria2e5]

I fed the 2017.4.5 directory to the toolkit. This time it spits out the error as:

manifest.json  .author : invalid type: object (expected string)

The current value provided is in fact a violation of WebExtentions Spec, as per https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/author. Fixing that gives a "ready to go" message for the extension.

[gloriousjob]

Hi all,

I created this zip and it seems to work on my machine. Just extract it and sideload the extension.
https_everywhere_edge.zip

The process I followed was fairly simple (though it took a few tries to figure out and get working):

1. Extracted the chrome extension.
2. Opened manifest.json and made the following changes:
   a. changed author to "author": "[email protected]" since braces are non-standard (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/author)
   b. Added the following subproperty to "background": ,"persistent": true
   c. Added the following property: "locale": "en"
   d. Added the following property: "minimum_edge_version": "33.14281.1000.0"
3. Opened all js files with chrome references and placed this code at the top:
   if (typeof msBrowser !== 'undefined') { chrome = msBrowser; } else if (typeof browser !== 'undefined') { chrome = browser; }

[elyscape]

@gloriousjob Why are you using !== for checking typeof msBrowser but != for typeof browser?

[saschanaz]

@gloriousjob Why msBrowser? I think Edge uses browser.

[gloriousjob]

@elyscape Good call! I copied that code from elsewhere which said that is what MS was doing. It makes sense to do an actual equals there. I've updated my previous comment and uploaded a new zip.

@SaschaNaz I've read that Edge was using msBrowser and browser is where the browsers are trying to standardize to. It's safer to have both just in case. If msBrowser is wrong, the if statement will skip it anyway.

[gmng]

I tried gloriousjob's zip and loaded the folder in EDGE but it does not redirect the link what I tried to HTTPS. It was an http link in a gmail mail but it does not redircted it to the https proto. (the page has https access too, I tried it manually in the address bar)

[elyscape]

@gmng Does HTTPS Everywhere redirect the site in question when using Chrome?

[gmng]

@elyscape No, it doesn't. I use this extension in FF with no problem, and now I installed it in chrome to test, but no, it does not redirect the page. It's a parcel tracking page (GLS) and has both http and https access. Same behaviour like in EDGE, when I insert the link in plain HTTP it doesn't redirect to https. When I change the proto manually to httpS in the address bar, I can access the page over SSL.

[gloriousjob]

@elyscape thanks for asking the question
@gmng so the edge extension I made is just a port of the chrome extension.
This is really an issue with the chrome extension. Maybe you should write
up a separate issue?

On April 22, 2017 3:53:12 AM gmng [e-mail] wrote:

@elyscape No, it doesn't. I use this extension in FF with no problem, and
now I installed it in chrome to test, but no, it does not redirect the
page. It's a parcel tracking page (GLS) and has both http and https access.
Same behaviour like in EDGE, when I insert the link in plain HTTP it
doesn't redirect to https. When I change the proto manually to httpS in the
address bar, I can access the page over SSL.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/EFForg/https-everywhere/issues/5101#issuecomment-296355898

[jeremyn]

If anyone wants to let people know about a site that needs an HTTPS Everywhere redirect, you can just note it in issue https://github.com/EFForg/https-everywhere/issues/3069.

[nikrolls]

@gloriousjob msBrowser is not used by Edge, it can be removed entirely.

What are the next steps now for Edge support?

[martinsuchan]

So what's the status of the extension for Edge, any blockers I can help with or ETA when it could be ready?

[craige1]

With the converter and the steps gloriousjob did, it seems extremely easy to make this. Can i push for this to be put into the store officially?

[jeremyn]

@Hainish has authority here and I don't want to step on his toes, but, just to set expectations, right now I believe the big technical focus is on converting the XUL/XPCOM version of the Firefox extension to use WebExtensions in time for the Firefox 57 release where XUL/XPCOM extensions won't work anymore. See here for related tagged issues. Once the Firefox migration is public and settled then @Hainish / the EFF might decide to work on the Edge version. Firefox 57 is due out in November 2017 so Edge might not have priority until then at least.

[Hainish]

Thanks @jeremyn. In addition, our legal department needs to look at whether we are able to comply with the MS developer license agreement.

[dxgldotorg]

@Hainish
Could the issue with the developer agreement be resolved by making the HTTPS lists an external download, so as there are no hard-coded references to domains whose content may violate the Agreement or may even contain legal violations?

[craige1]

Thanks for getting back to me.
Its actually great news that this is being looked into. I understand that the dev work priority will lie with the current plugins, I just wanted to check in to see that an edge plugin wasn't being ignored, or forgotten. Here's to hoping the legal issues aren't an issue (how are the play store and apple store dealt with?).

[martinsuchan]

Once there is working beta of the extension I'd suggest creating Windows Store account and submitting the extension for test using this form:
https://developer.microsoft.com/en-us/microsoft-edge/extensions/requests/
Microsoft will then contact you with details and necessary info to get the extension into Store.

And since there is Windows 10 Fall Creators Update planned for September/October this year, it would be nice to have HTTPS Everywhere as a highlighted Edge extension when this Windows update is released.

[uncnqrd]

Is the main issue blocking a version for Edge the MS developers license agreement? Or is there a technical issue, such as specific API support missing?

[dxgldotorg]

I do not believe there is any license issue preventing creating an addon, just in submitting it to the Store, which does have various rules on what kind of software is and is not allowed.

[nikrolls]

Knowing their rules I don't believe this would be blocked, in fact it would be welcomed. You just need to apply for permission to launch Edge extensions at the moment

I publish uBlock for Edge and have an existing relationship with the team. I'd be happy to do it for this, though it would be under my personal name if that was the case, and I would need to upload all the releases. If it was to be done under the Foundation's name then someone would need to apply for a Company account and go through Verisign verification.

[jeremyn]

I assume the blocking problem here is that the one person who could make this happen officially -- @Hainish -- isn't interested, or at least has made an Edge extension low priority vs everything else.

I suggest anyone who wants this done on any definite schedule either become big enough for the EFF to listen, or fork/repackage the code.

Regarding a fork, take a look at issue https://github.com/EFForg/https-everywhere/issues/12606 "Discussion about out-of-band ruleset updates". The EFF wants to move to a model where the extension regularly fetches EFF-signed updates from the internet outside the browser update process. I encourage anyone who is considering a project fork, even for their own personal use, to participate in that discussion.

[ghost]

@jeremyn Great, now we are discussing fragmenting the user base with forks.

[ghost]

Let's develop Edge version as a part of this project, not as a third-party fork.

[jeremyn]

@koops76 A fork isn't great but the reality is that the EFF doesn't do well with big community efforts like this. I wrote about this a little in https://github.com/EFForg/https-everywhere/issues/9111#issuecomment-320453076. So we're in a position here where the EFF is, I think, unlikely to say either yes, they'll do it, or no, they officially disapprove. Instead it'll just float around forever unless someone else takes ownership of it.

The good news is that the EFF makes some effort to make HTTPS Everywhere friendly to downstream, for example see https://github.com/EFForg/https-everywhere/issues/6937 "Cultivate a list of HTTPS Everywhere downstream ruleset dependencies". So perhaps we should think of what @nikrolls is proposing as a downstream packaging of HTTPS Everywhere for Edge, rather than a (hostile) fork.

In any case, @nikrolls seems perfectly placed to do this since he is doing the same thing for uBlock Origin. If he wants to take on this work then I personally am all for it.

[ghost]

@jeremyn A fork means security patches will take more time to reach the users and also means that developers' efforts will be less focused.

[ghost]

@jeremyn A one-man repackaging of the extension would have trust issues. One person is easier to force to make unwanted modifications to the extension than a large organization such as EFF.

[ghost]

This extension is recommended for use by activists, and while I am not an activist, I don't want my machine to be compromised as a part of a campaign targeting activists.

[isshininu]

Any news about Edge version of extension?
Firefox 57 is already out.

[martinsuchan]

Hi, any update regarding this extension?
As I noted earlier, I have already published several Windows Store apps. Publishing Edge extensions to Store is a similar process, so if you need any help when creating Dev account or packaging the extensions, just let me know here or on Twitter, I'm ready to help.

[Hainish]

Last time I checked, several of the WebExtension APIs we use hadn't been implemented in Edge. I'd have to do some poking around to see if this is still the case. This may take some significant time to rewrite the codebase to work around this shortcoming. Currently, our development roadmap is detailed here: https://lists.eff.org/pipermail/https-everywhere/2018-January/002760.html.

[martinsuchan]

@Hainish What kind of API is missing in Edge, that is required for the HTTPS Everywhere extensions?
Current list of supported APIs and roadmap is available here:
https://docs.microsoft.com/en-us/microsoft-edge/extensions/api-support/extension-api-roadmap

[jppmarujo]

It would be amazing to see this coming to life. This is a core extension for every major browser, and Edge lacking it is a shortcome that i think the browser does not deserve, if we look at its current state. It's stable, fast and has many great features - minus this potentially great one.

I don't know if this is still low-priority or not, but i think both Edge and HTTPS Everywhere userbase would grow if both complemented each other.

Nevertheless, great job, devs.

[andresbase]

Hi everyone,
Thanks for keeping this discussion going with all the helpful comments and feedback.
As an update on EFF's ability to ship on the Microsoft Store the last legal review was that we couldn't due to provisions that we could not comply with. Although it's an old post about Apple, it touches on similar issues https://www.eff.org/deeplinks/2014/12/sorry-iphone-users-apples-dev-agreement-means-no-eff-mobile-app-iphone.

I have requested a legal review of the latest developer agreements and looking forward to share the result end of April.

Thanks!

[martinsuchan]

@andresbase Hi, can you go please into details what are the points in Microsoft Store App Developer Agreement or Microsoft Store Policies that prohibits publishing the HTTPS Everywhere addon?

I've read the article you mentioned and it targets publishing EFF Alerts app on App Store. That's a quite different app and Store. It's known that Apple App Store had the most strict rules about published apps. There should be fewer showstoppers when publishing on Microsoft Store from my experience.

[jeremyn]

uBlock Origin is available for Microsoft Edge and is licensed under GPLv3. It's published by @nikrolls who commented earlier on this issue. Edge extensions have to be submitted for review by Microsoft so I assume Microsoft is okay with it.

HTTPS Everywhere is licensed under GPLv2 or later. If someone wanted to fork it, they could do so, immediately relicense it as GPLv3, and be in the same legal situation as uBlock Origin is.

I'm not sure what an EFF legal review is needed for. Maybe the EFF, as an organization, finds something about the Microsoft agreements or ecosystem distasteful, and doesn't want to publish something with Microsoft under its own name. I can understand that. However, as far as I understand it, the EFF can't legally block others from doing that, under the terms of the GPL.

So, I hope that @andresbase 's answer was not an attempt to say that a fork requires the EFF's approval, since imposing such a requirement is not allowed by the GPL, again, as far as I understand it.

[jeremyn]

the EFF can't legally block others from doing that

By "that", I mean forking HTTPS Everywhere and publishing it under their own name, not the EFF's name. Of course the EFF can block people from publishing software under the EFF's name.

[StephenVictor]

There does seem to be a lot of foot-dragging on this. I know some developers have an anti-Microsoft bias for various reasons. I do hope that's not causing this vital security issue to be neglected.

[nikrolls]

Regarding the discussion of an individual maintaining the publish process of HTTPS Everywhere under their own name, I'd like to re-iterate that I'm not biased against Microsoft, I have first-hand experience, and I'm happy to do it. I understand that this is not the ideal solution, but if it's the path we go down, my hat's in the ring (as I'm sure are others').

[jppmarujo]

Well, @nikrolls, uBlock Origin for Edge has been a success, so until EFF doesn't have legal green light to publish to Microsoft Store, i would say you're maybe the person best positioned to assume the fork. If i can help with anything, just let me know.

You would be supressing two of the major flaws Edge has, with the best adblocker extension out there, and a really important privacy one. Thank you for your availability to give the users the opportunity to enjoy them!

[martinsuchan]

@nikrolls That's a great idea! Since you have already published the uBlock Origin extension, publishing HTTPS Everywhere under your dev account should be pretty straightforward.
Even though I'm not fan of a fork for Edge, ideally all the development should be happening here, it's still better than no Edge extension at all.

[andresbase]

For clarification my comment did not mention in any way forks. Only:

EFF's ability to ship on the Microsoft Store

The part with which the last legal review warned was reverse engineering _"except and only to the extent that applicable law expressly permits, despite this limitation.”_ It would be hypocritical for us to fight for your rights and still sign some of these agreements, and for the same reason we can't encourage developers to sign it either. That said, it is OSS so you can fork it as it has already been mentioned.

EDIT:
In case you are interested on why the point of reverse engineering is important for us here is a useful FAQ:
https://www.eff.org/issues/coders/reverse-engineering-faq

[StephenVictor]

@nikrolls, I say go for it!

[jeremyn]

@andresbase Thanks for clarifying.

I would be interested in knowing the answers to these questions, if you could raise them with the EFF legal team when they review the situation:

(What follows is based on my own understanding and I could definitely be mistaken about some or all of it.)

Edge extensions are published through the Microsoft Store, which requires developers to agree to the App Developer Agreement. This agreement doesn't prevent the developer from reverse engineering anything. Is the problem that publishing to the store requires using some other Microsoft software, like Windows, that does include a no-reverse-engineering clause?

Chrome extensions are published through the Chrome Web Store, which requires developers to agree to the Google Chrome Web Store Developer Agreement. The Google agreement explicitly requires, in section 2.1, agreeing to the Google Chrome Terms of Service, which, in section 9.2, prevents the user from reverse engineering Chrome. What is the difference, if any, between Google's agreements and Microsoft's regarding restrictions on reverse engineering?

[jppmarujo]

@nikrolls , do you still plan on forking and making it available as an Edge extension?

[StephenVictor]

Thank you, @jppmarujo, for keeping this thread alive. The lack of response to @jeremyn's excellent questions is quite telling, IMO, and I don't think we can expect an official Edge extension as long as Microsoft is in the picture (disingenuous platitudes about hypocrisy notwithstanding). @nikrolls, I hope you're going to fork the extension and make it available. Thank you!

[nikrolls]

Sure thing! First step will be trying to get it working in Edge. I'll start looking into that shortly. If it works as-is … great! If not, we can try to get the fixes in the core (preferable to maintaining a fork). If we can't, or if changes in core end up repeatedly breaking Edge for instance, then I can maintain a fork (accepting PRs from the public).

Regardless, once it's running I can talk to Microsoft to get authorisation for it to be in the Store, and I can manage releases (under my name, as with uBlock Origin). If EFF decide to release officially, I will gladly assist with a transition.

[StephenVictor]

Since Microsoft has just announced its acquisition of GitHub, I thought I'd ping for status on the Edge extension. Any progress, or are too many heads exploding right now?

[charlottetan]

If it helps, there's also a tool to port extensions over to Edge: https://docs.microsoft.com/en-us/microsoft-edge/extensions/guides/porting-chrome-extensions

[frederiktoft]

@charlottetan I just tried using the tool you linked to, to convert https everywhere. By just using the tool and without any modification it can be loaded into Edge and it seems like it is running, BUT it looks like it does not do anything. Maybe someone else with better understanding of chrome and edge plugins can try it out, but regardless, looks like we are VERY close to a working Edge version.

[jeremyn]

@andresbase Do you have anything to report regarding the legal side of this, referring to your comment https://github.com/EFForg/https-everywhere/issues/5101#issuecomment-371329913 ?

[StephenVictor]

@nikrolls, are you still working on this?

[nikrolls]

Unfortunately I haven't made a lot of progress yet because the build setup is very *nix based. I tried on WSL but didn't have complete success -- mostly around requiring install of full browsers to run the test suites. I intend to keep working on it but life has gotten in the way a lot recently and I'm not sure how quickly I'll progress.

@charlottetan @frederiktoft: That tool is an OK way to port extensions, but unfortunately it only works on the _output_ of your build process. To really be able to maintain this extension for Edge we need the build process to support Edge, otherwise you'll just be running it through the converter on every release which is not usually maintainable long-term.

[andresbase]

@jeremyn we still can't officially deploy on the Microsoft Store. I try to monitor changes that will allow us to officially be in their store. If the situation changes I will update this issue.

@nikrolls thanks for working on this, really appreciated!

[TheRyuu]

@nikrolls msys2 can build https everywhere with the correct packages installed. I forget what's required but python3, etc are all there. I've successfully built https everywhere this way. I'm not sure if it'll ever be able to run some of the test suites that require full browsers on Windows (but we have *nix for that!).

[TheNavyBear]

@andresbase why can't you officially deploy on the Microsoft Store, but you can officially deploy on the Chrome Web Store? I am not trying to pick a fight here, I am genuinely curious. I have read the rules for both stores, and the Chrome store appears to have the same, if not more, restrictions as the Microsoft store. Please help us to understand what it is that keeps EFF products out of the Microsoft Store. I feel that the EFF's current stance of "if you want our protections use another browser" is unacceptable, especially considering that some people need these protections on an issued, locked-down, device where they can't just install another browser.

[andresbase]

@TheNavyBear Comparing Chrome's Developer Agreement (https://developer.chrome.com/webstore/terms) and Microsoft's (https://docs.microsoft.com/en-us/legal/windows/agreements/app-developer-agreement) the later has a clause about reverse engineering that the former doesn't.

More details about reverse engineering at https://www.eff.org/issues/coders/reverse-engineering-faq

[FranklinYu]

@andresbase In https://github.com/EFForg/https-everywhere/issues/5101#issuecomment-372495235, @jeremyn already explained that Chrome Store has the same issue. Maybe cover this evidence in next legal review?

[StephenVictor]

@franklinyu, there's really no point in trying to engage @andresbase in an honest discussion of the issue. He has avoided addressing @jeremyn's comment, nor has he provided the update on the legal review he said he would in https://github.com/EFForg/https-everywhere/issues/5101#issuecomment-371329913. It's quite clear that he and EFF have no interesting in supporting a Microsoft product, so our only hope is a fork.

[andresbase]

Hi @franklinyu I missed when I checked that the EULA mentions reverse engineering for Chrome. I will have to discuss this again with the lawyers to do a full review of the agreements for Apple, Microsoft and Google. As well as to assess what makes sense to provide the most protection to our users and continue fighting for the issues we have for a long time. I can not provide a timeline for that but will make it a priority. Sorry if this wasn't clear enough.

@StephenVictor I'd like to keep this thread respectful. We don't have any reason, other than legal, to not deploy on Microsoft. I would like to see our extensions to offer protections in as many places as we can.

[StephenVictor]

@andresbase, I certainly meant no disrespect, but the fact remains that you were asked about the Chrome EULA on March 12 and you failed to respond. If you missed the reverse engineering clause, why didn't your legal reviewers catch it -- and now that you're aware of it, are you going to pull Chrome support pending the legal review? That would seem to be the correct approach given your statement here: https://github.com/EFForg/https-everywhere/issues/5101#issuecomment-372450800.

[andresbase]

@StephenVictor That was my mistake which is why I'm requesting a full review. When we hear back from legal we will make a decision on the status of our deployments. Thanks for understanding.

[Hainish]

@StephenVictor we're all very busy here and face limited cycles. Edge development hasn't been prioritized since we'd like to focus on improving support for our already-deployed platforms. Even if legal says that the Microsoft Developer agreement is fine, we have to make the decision of if we want to prioritize this as a platform. Last I checked, Microsoft Edge was lacking in several of the WebExtension APIs that we need for HTTPS Everywhere. You can see in this comparison chart how far they lag behind: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs. This makes me think that it'll take quite some time to come up with workarounds for HTTPS Everywhere, which is discouraging. Furthermore, I'm unsure of how much there is a demand for HTTPS Everywhere in Edge. This is another question which is relevant to if and when we'd like to prioritize this feature.

This isn't to say that we won't do it, but it warrants further investigation. This at the same time as we're deploying important features that other users have requested. For instance, the ability to disable HTTPS Everywhere on specific sites. These are all features that are competing for time and resources from our development team, so committing to supporting another browser with limited WebExtensions support is an open question.

[FranklinYu]

@Hainish I believe several guys here are glad to help getting over the API issue of Edge, as well as urging Edge developer to implement them (like UserVoice), but we are probably not able to help the legal part. That’s why I was asking. It’s simply meaningless for us to push Edge team or hack the API ourselves if Edge is not even going to be reviewed by EFF. (In that case we’d better close this issue.)

Anyway, it’s good to hear that Microsoft Store will be reviewed again in future. Thank you all for the efforts. Let’s see how far this can go.

[andresbase]

Hi everyone, I have good news.

After further internal discussion, we've decided we can go ahead and publish in Microsoft Store. The next step should be putting together a pull request with fixes for Edge.

Thanks a lot for your support!

[StephenVictor]

Thank you all!

[dxgldotorg]

Hi everyone, I have good news.

After further internal discussion, we've decided we can go ahead and publish in Microsoft Store. The next step should be putting together a pull request with fixes for Edge.

Thanks a lot for your support!

Will Microsoft have any restrictions on the Store version, such as either removal of certain functionality or the removal of certain domains from the list?

[andresbase]

I don't think so unless there are technical restrictions on what the extensions can do. But if there aren't there shouldn't be.

[ghost]

According to https://github.com/MicrosoftEdge/MSEdge Edge will soon be built on Chromium. So much for an extension specific to old Edge?

[martinsuchan]

It might take some time before the Chromium-based Edge is released. It's also completely possible, that the extensions will be still deliverd through Store, so there is no use of waiting with releasing the extension for the current Edge.

[AnthonyBe]

Agreed. All formal information, and internal indications, are that this is just an 'under the hood' change of the edgeHTML engine with the Chromium engine but the UI, and thus the extension ecosystem, remains the same.

[ExE-Boss]

The thing is that Firefox and Edge use the browser namespace, but Chrome uses the chrome namespace.

[Hainish]

@ExE-Boss this shouldn't be an issue, Firefox still exposes the chrome-namespaced API. There are some inconsistencies between chrome and browser, as there are between Chrome's chrome and Firefox's chrome. But these haven't caused problems and we just use chrome in the extension for the most part.

[Hainish]

Work on this will commence at some point after the Chromium-based Edge browser is released.

[pipboy96]

Closing for now, since an unofficial version of HTTPS Everywhere for Edge already exists and Edge internals are going to severely change, making existing arguments related to EdgeHTML engine moot.

[pipboy96]

@edmael Do you know the details of publishing the extensions for Edge in their extension store?

[pipboy96]

(Reason for reopening: Edge version based on Chrome have been released, and it supports HTTPS Everywhere's Chrome version if you install it manually)

[martinsuchan]

First dev builds of Microsoft Edge browser based on Chromium is now available and the HTTPS Everywhere extension, when downloaded from Chrome Web Store, works just fine.
https://blogs.windows.com/msedgedev/2019/04/08/microsoft-edge-preview-channel-details/

[dxgldotorg]

@edmael Do you know the details of publishing the extensions for Edge in their extension store?

It does appear ESRB ratings are mandatory on Microsoft's store, and as a result the fact this extension contains references within it to websites that are potentially objectionable and/or illegal this may not fare well under their standards.

[pipboy96]

@dxgldotorg well, that would mean uBlock Origin or similar extensions are similarly illegal, since the block lists include not only NSFW websites, but also some that are most likely illegal in any jurisdiction.

[cschanaj]

I tried to install the unpacked chrome version of HTTPSE to Edge (Chromium), it seems to work nicely without significant breakage. So, it might worth re-visiting this request again. cc @zoracon @Hainish

[nikrolls]

I was able to install HTTPS Everywhere on Edgium directly from the Chrome Web Store. Everything appears to be functioning correctly.

[dxgldotorg]

@dxgldotorg well, that would mean uBlock Origin or similar extensions are similarly illegal, since the block lists include not only NSFW websites, but also some that are most likely illegal in any jurisdiction.

Is there a reason that HTTPS Everywhere (which is not a blocking extension) couldn't make their lists separate from the extension? This would also have the added advantage of being able to update lists without having to update the extension itself.

[Hainish]

@dxgldotorg we already do this: https://github.com/EFForg/https-everywhere/blob/master/docs/en_US/ruleset-update-channels.md

[pipboy96]

@dxgldotorg We do bundle the rulesets with the extension too though.

[nikrolls]

uBlock operates in a similar way. Every release goes out with the latest set of rules, so you are up and running immediately. Sometimes background update processes don't get to run for a little while, which would mean the extension is inoperable until then.

[zoracon]

So it looks like if they keep the "Download extensions from other stores" model with the future stable release of "Edgium" then we may not even have to do a separate release to the Edge marketplace! Will update if this changes.

[nikrolls]

Yes, for power users at least. But if we want discoverability for the layperson (maybe, maybe not?) it should be in the Edge store as well. The good news is that, at least so far, the auto-pull seems to be working.

[zoracon]

Yes, for power users at least. But if we want discoverability for the layperson (maybe, maybe not?) it should be in the Edge store as well. The good news is that, at least so far, the auto-pull seems to be working.

There's pretty short and clear instructions they provide we can refer to on the site to make sure the user is directed properly. It just makes the release process longer. But if it has to be done, it can since this is now an obtainable reality.

[nikrolls]

It just makes the release process longer.

Not necessarily - once you've set up the storefront (and providing this process passes Microsoft's criteria and they stick with it) releases are automatically pulled from the Chrome store. The developer doesn't need to do anything extra once initially linking it, they just release for Chrome as usual and the Edge store updates.

The only extra work is if you want to update the storefront (description, images, etc).

[pipboy96]

@zoracon @andresbase What's the current status of this?

[dxgldotorg]

Since EdgeHTML Edge is about to be replaced with Chromium Edge, there may be no more point in developing the Edge addon, as Chromium Edge is fully compatible with Chrome extensions, and can even access the Chrome Web Store to download and install extensions.

[pipboy96]

@dxgldotorg Do you think we shouldn't publish the extension in Edge's extension store?

[zoracon]

@zoracon @andresbase What's the current status of this?

This is being held up by the Manifest V3 planning and auditing. "Edgium" is still in Dev channel at the moment so monitoring when they will officially publicly release

[iNViTiON]

@zoracon It's in public beta channel. Not only in dev channel. https://blogs.windows.com/windowsexperience/2019/08/20/introducing-microsoft-edge-beta-be-one-of-the-first-to-try-it-now/

[zoracon]

@zoracon It's in public beta channel. Not only in dev channel. https://blogs.windows.com/windowsexperience/2019/08/20/introducing-microsoft-edge-beta-be-one-of-the-first-to-try-it-now/

Right, however my reasoning still applies. Hopefully there is news soon for public release since they have it on Beta

[pipboy96]

@zoracon Would it make sense to start preparing now to get ready for official release? Manifest V3 should be prioritized though.

[FranklinYu]

Right, however my reasoning still applies.

Sorry but I disagree. This reasoning holds for Dev channel, but public beta should be a signal for browser extension developer to start testing their extensions. For example if HTTPS-Everywhere break in Chrome beta I would report a bug here instead of waiting for the bug to propagate into Chrome stable.

[zoracon]

Right, however my reasoning still applies.

Sorry but I disagree. This reasoning holds for Dev channel, but public beta should be a signal for browser extension developer to start testing their extensions. For example if HTTPS-Everywhere break in Chrome beta I would report a bug here instead of waiting for the bug to propagate into Chrome stable.

@FranklinYu that's a good point about testing, but there has been a few reporting stability out of the extension since the dev channel. And my last comment was more geared toward the fact Chrome plans on changing this extension ecosystem in a very large way. So I have been committing more time and resources to Manifest V3 in the Chrome environment.

I admit there has not been much publicly said from HTTPSE about Manifest V3. But that's also due to the fact that the new API has new updates even up until the past few weeks. We have publicly asked certain features from the API for HTTPSE to still function. So far they have been 75% of the way granted.

17268

[ExE-Boss]

That’s probably because webRequest can do anything with web requests, like redirecting the request to HTTPS or blocking it entirely, and as such, is also used by adblockers to block remote advertisments and trackers, and because of that, Google’s management wants developers to switch to declarativeNetRequest, which greatly limits what can be done and increases their advertising margins.

Without webRequest, adblockers can only block advertisements by hiding them with display: none !important; in a user origin styleshhet, but by that point, the request has already reached the advertiser’s servers, and so they can still track you.

[pipboy96]

@ExE-Boss I guess when this hits we will have to shift focus from Chrome to Firefox and Chromium forks (Brave, eloston's Ungoogled Chromium, etc).

[nikrolls]

It will be interesting to see what Microsoft does about Manifest v3 in the new Edge.

[nikrolls]

Microsoft have not taken a stance on Manifest v3 yet. I've even asked their dev team personally.

[zoracon]

HTTPS Everywhere is now in the Edge store. Please report issues to Github if you see them :)
https://microsoftedge.microsoft.com/addons/detail/fchjpkplmbeeeaaogdbhjbgbknjobohb

[pipboy96]

@zoracon There is a problem with an icon: