Import home page (start page) from Microsoft Edge

RESOLVED INVALID

Status

()

Firefox
Migration
P3
normal
RESOLVED INVALID
3 years ago
13 days ago

People

(Reporter: Dolske, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox43 affected)

Details

(Reporter)

Description

3 years ago
Spun out from bug 1192037. We decided to generally not migrate Edge settings, because they're sometimes actually broken or hijacked, making migrating them to more harm than good. But Verdi pointed out that our importer actually has a confirmation screen to allow the user to select either their old home page or Firefox's. That alleviates the hijacking concern, so we should probably go ahead and do that for consistency with the other migrators.


Gijs's bug 1192037 comment 2:

I've looked into the homepage here, which I think is arguably the most important out of all the non-advanced prefs.

Frustratingly, it seems like:
1) there were open registry keys that we use for IE
2) as of IE11 and maybe IE10, I don't think those even work anymore, though I've not checked. They use an opaque binary registry key that I don't know how to read
3) there are APIs for IE11 to:
  - check if your homepage is X
  - ask the user to set their homepage to X
... but apparently not to just ask "what is the user's homepage?"

4) Edge and IE definitely do not share a homepage preference, so that kind of moots most of that.
5) Edge has the same kind of unreadable binary registry key
6) I've verified that that gets written to if you change your homepage

Considering that the registry itself is in a folder that indicates you are not under any circumstances allowed to mess with it (https://twitter.com/gijskruitbosch/status/631763783636123649 , https://twitter.com/gijskruitbosch/status/631763994869633024 ), I wouldn't be surprised if the value was encrypted. (yes, I found that a while back - I was looking for History at the time, so since the reading list patch was written I've been looking at this / other ways of determining the home page.

Considering how hard MS makes it to change your homepage in Edge to anything other than the default about:start page, or MSN or Bing (something like 5 clicks to get to an input box where you can do that), I'm not sure how much time I should spend on trying to figure out anything else about that registry key...

Of course, if other people have found API information to retrieve this value, that would be quite useful!



At least some of the other settings seem to still be under 'Main' in the key HKCU\SOFTWARE\Classes\Local Settings\(...)\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge... I mostly spotted the home button one, I'll have to try and look for the other stuff (writing this on my mac).
(Reporter)

Comment 1

3 years ago
Aside: I think the current migration UI is rather non-ideal, and a whole step to confirm start page migration feels really heavyweight. But it's what we currently have, so is fair to be consistent with that. [Data from bug 731025 could be really interesting for revisiting that -- how many users actually import their IE homepage? And that does have any impact on adoption or sentiment?]
(Reporter)

Updated

3 years ago
Priority: -- → P3

Comment 2

3 years ago
Right, so. Some more info.

- this registry entry is indeed encrypted
- it is not clear with what algorithm or key
- the same plaintext in the edge options produces different ciphertext every time, suggesting some kind of nonce/salt is added to the plaintext
- the edge process reads the machine's guid from the registry every time it encrypts the homepage, suggesting that the value is specific to the machine (ie reusing the value on my machine on a different machine will not work, nor can we build a list of values that correspond to known URLs (see also previous point) to detect those homepages).
- the length of the plaintext influences the length of the ciphertext
- edge corrects the value it shows you to be a valid URL. Just inputting "a" results in the bing search for "a", and just inputting "0" results in http://0.0.0.0/. However, the value in the registry has a different length depending on whether you use "0" or "http://0.0.0.0/", and it therefore seems that the value is stored in the registry as-is, ie before the URL-ification that Edge shows.
- a 1-character "homepage" produces a 74-byte result on my machine, but I think I've seen 72 bytes on my other machine. Ciphertext length seems to (roughly) increase with 2 bytes for every character in the "URL" I use.
- I suspect the fixed "Start page" and the pre-supplied MSN/Bing pages all get stored as URLs - only that key seems to change, and the value's length for "Start page" matches setting the page to e.g. "about:stark" yourself (the actual URL being, of course, about:start).
- I would have liked to be able to detect the "Previous pages" setting in some way as well, but it seems that too somehow gets stored in this value.
- the first 4 bytes stored are always 01 00 00 00. It's possible this is some kind of version identifier that they can use to alter the method used to store/encrypt the homepage value if/when they choose to do so.

and that's about how far I got with this. I expect that even if we figure out exactly how this works, making that public would harm MS's ability to deal with malware that hijacks homepages, which would be sad.

It would be relatively easy for Edge to store the unencrypted value somewhere else for the purpose of interoperability, but it does not seem like it does this.

Given all that, I don't think it's useful to spend more time on this until/unless there is a good way to detect this value in a more reasonable way.
(In reply to Gijs Kruitbosch (gone until Tue 22 Sep) from comment #2)
> Given all that, I don't think it's useful to spend more time on this
> until/unless there is a good way to detect this value in a more reasonable
> way.

I agree with that. It would be surely fun to break this but if we'd open them up to Malware that probably isn't worth our time. Maybe we could talk to MS about offering a read-only API in the future.
Bug 1434167 made this invalid
Status: NEW → RESOLVED
Last Resolved: 13 days ago
Depends on: 1434167
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.