You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi. Thanks for the nice tool. I get here from the mathjs.
Right now, if there's no crypto on global, we will use this as the default seed: [+new Date, GLOBAL, GLOBAL.navigator && GLOBAL.navigator.plugins, GLOBAL.screen, tostring(pool)];. And then do flatten to it and convert it to a string.
But, actually, there could be some problems with this since we don't know what is existed in the user's global environment. For example, if the global environment has some Symbol values or nested Symbol values in-depth 3, then it will break by TypeError: Cannot convert a Symbol value to a string.
It's just one case that may crash the program. And there may be some others. So, I think maybe we should not use the whole user global object and do operators to it. It's a little bit out of control.
The text was updated successfully, but these errors were encountered:
poppinlp
changed the title
Do you mind the auto seed not generated from the whole global?
Do you mind not generate the auto seed from the whole global object?
Aug 26, 2020
Looks like we want to get some data varies from person to person. The current navigator and screen seem to designed for the browser. And for nodejs, maybe we could use something like process.env which consists of just string pair.
And for the new Date, we could have more detailed time via performance.now for browser and process.hrtime for nodejs to make it more special.
Hi. Thanks for the nice tool. I get here from the mathjs.
Right now, if there's no crypto on global, we will use this as the default seed:
[+new Date, GLOBAL, GLOBAL.navigator && GLOBAL.navigator.plugins, GLOBAL.screen, tostring(pool)];
. And then doflatten
to it and convert it to a string.But, actually, there could be some problems with this since we don't know what is existed in the user's global environment. For example, if the global environment has some Symbol values or nested Symbol values in-depth 3, then it will break by
TypeError: Cannot convert a Symbol value to a string
.It's just one case that may crash the program. And there may be some others. So, I think maybe we should not use the whole user global object and do operators to it. It's a little bit out of control.
The text was updated successfully, but these errors were encountered: