Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dmitry Nechay
    @dnechay
    @Valve thank you
    skiperz
    @skiperz
    @Valve отправил на майл
    Victor Castro
    @victor95pc
    @Valve hey do you know the chances to duplicate a fp2 hash? I'm not asking about confliting SHA256 I know it's almost impossible to happen, I asking the chances the value(that's about to get hashed) duplicate.
    Do you use it for how many users?
    I'm thinking to use this lib, but I have a traffic with 18M a day
    Valentin Vasilyev
    @Valve

    @victor95pc please see the detials here: https://github.com/Valve/fingerprintjs2/blob/master/FAQ.md#how-good-is-your-library-can-you-guarantee-that-different-devices-will-have-different-identifiers

    How good is your library? Can you guarantee that different devices will have different identifiers?
    This library is not good. It has an error margin of 10-20%

    I don't use it currently, I still use fpjs first version.

    xiuxiuxiaodi
    @xiuxiuxiaodi
    hi, anynoe has the augur.js that can generate the fingerprint from the augur.io website?
    SleepProgger
    @SleepProgger
    hi, i am currently preparing the "timezone from the internationalization API" (#356) PR and was thinking if an additionally hash over all timezoneOffset changes (like https://pastebin.com/2f7imVnr ) could be usefull. The values seem to be kinda stable over different devices and browser (android ff+chrome, linux ff + chrome, working but different values in konqueror)
    Besides acting as a fallback for browser not supporting the internationalization API this also helps for browser (like ff on android) which in my case fe. returns CET from the internationalization API while using the Europe/Berlin timezone (the timezone changes are the same -> same hash as on other devices)
    Any thoughts on that ?
    Jonas Haag
    @jonashaag
    I think it's a great idea. Go ahead.
    SleepProgger
    @SleepProgger
    awesome, will get to work in a bit. For client not supporting the Internationalization API simple returning an empty string seem to be the common way in that project ?
    Jonas Haag
    @jonashaag
    Yep, or null
    SleepProgger
    @SleepProgger
    about the null, incoming PR because index.html can't handle null results, because null.toString() won't work ;)
    SleepProgger
    @SleepProgger
    After reading a bit more about the internationalization API i think a lot of default value in there would be a good addition to FS2.
    https://www.ecma-international.org/ecma-402/1.0/#sec-A , but i am not really sure where some of the values are sourced from TBH.
    SleepProgger
    @SleepProgger
    @jonashaag what do you think about something like this: https://pastebin.com/cMZyeaVf for the specs ?
    It generalizes (or tries to) checking the exclude options.
    Not a big fan of all the workarounds, but not sure what to do else TBH.
    The hope is that it makes pushing new fingerprinting sources easier.
    SleepProgger
    @SleepProgger
    Messed the previous one up. Fixed: https://pastebin.com/wMHPpr8p
    Jonas Haag
    @jonashaag
    @SleepProgger better than what we have currently but if you're interested you may also refactor the exclude options schema to something like {exclude: ['webgl', 'canvas']} etc, and refactor all of the webglKey, canvasKey, etc function names to something that follows a sane scheme.
    I think refactoring this is long overdue and as long as we provide a deprecation path we might as well refactor all the things :)
    SleepProgger
    @SleepProgger
    @jonashaag the exclude:{key1, key2,...} way sounds way nicer, i like it. Am offline tomorrow, so i'll prob. send a PR for that in about two days
    shall i keep the other options like they are now ? ie: options = {someFlashOption: 1, someotherOption:2, exclude: [key1, key2,...]} or do we want an config object per check (flashFontOptions: {foo: 'bar'}) ?
    Jonas Haag
    @jonashaag
    let's keep the other options for now, maybe we can change these in a second step if it's useful
    SleepProgger
    @SleepProgger
    ok.
    Something else: currently some functions check if the relevant API is supported and if it isn't the corresponding entry isn't added to keys.
    I am not sure if it wouldn't be a better idea to always return the entry (with value set to null if the API isn't supported) if the fingerprint isn't excluded ?
    that would make the specs easier and also IMHO not supported APIs are a bit of FP information which would be easier to collect this way
    Jonas Haag
    @jonashaag
    hm
    not sure. excluding it doesn't change fp in case you enable a previously disabled option that the browser doesn't support
    like your browser didn't support audio fingerprint, but you also didn't have it included in the fp in the first place, and now you add it
    then with a special "unsupported" value your fp changes, with the value being excluded it doesn't
    maybe there are other cases to consider, not sure
    in any case we should have the component function return a special "unsupported" value and deal with unsupported values in a single place (in the main function probably)
    SleepProgger
    @SleepProgger
    true. i like the special "unsupported" value approach. We can then filter these out easily before returning the keys to the user (except some options is set maybe).
    But yeah, that part is prob for later
    anyway, am off for a bit
    Jonas Haag
    @jonashaag
    thanks!
    SleepProgger
    @SleepProgger
    @jonashaag about the change to the options ({exclude: []...}); two questions:
    1. How to handle per default disabled FPs ? That one would be easily fixed by using an Object instead of an array for exclude. This way user could enable a by default disabled FP "foo" by providing options like {exclude: {foo: false}}
    2. How to handle device specific excludes like "excludeAudioIOS11" ? Should they be in the exclude array/Object ? I planned to simply use the key name for the excludes because that make sense for the user and also test writing easier. Should we simply keep them out of the excludes thing and on the first level of the options object ? Feels a bit wonkey, but better as to throw them into the excludes thing IMHO.
    Jonas Haag
    @jonashaag
    @SleepProgger how about something like this
    const options = {
      canvas: false, // disabled
      audio: {
        ios11: false
      },
      fonts: {
        js: false,
        flash: true
      }
    }
    i.e. use the component name as key, false/true to disable/enable (or maybe use 'disable', 'enable' here?), and custom options as a sub object
    SleepProgger
    @SleepProgger

    Sry, i got lost a bit reading the FF bugtracker (bunch of interesting FP stuff in there)

    ACK to the option object or false.
    I would like to kept the fonts split into js_fonts and swf_fonts (or maybe better flash_fonts ?)
    So something like this ?

    const options = {
      canvas: false,
      flash_fonts: {
        swfPath: 'somepath',
        swfContainerId: 'somecontainer'
      },
      audio: {
        excludeIos11: false
      }
    }

    To match the the key format we should maybe change all the options from camelCase to underscore_case ? (am a py coder so i am biased tho ;) )

    SleepProgger
    @SleepProgger
    While we are at it, are you ok with moving both 'ie_plugins' and 'regular_plugins' into the same key, @jonashaag ? There can only be one of those at a time anyway
    Jonas Haag
    @jonashaag
    yeah but keep it camelcase, that is to say make everything camelcase that isn't. wrt fonts, i'd keep them as a single key unless they're different components (not sure if it's currently implemented as different components or rather as different methods to getting the list of fonts)
    interested to read your FF fp links!
    SleepProgger
    @SleepProgger
    FF FP rabbit hole entrance here: https://bugzilla.mozilla.org/show_bug.cgi?id=1329996 (some of them will be/are fixed with the TOR uplift project, but as this all opt in behind some about:config key i wouldn't bother about that really much)
    fonts is currently different components: swf_fonts and js_fonts
    so, keep the keys underscore_case but the options camelCase ?
    any thoughts about the plugins (have a single key for ie_plugins and regulat_plugins) ?
    *regular_plugins
    SleepProgger
    @SleepProgger
    WIP (with keys AND options) camelCased, because i am AFK till tomorrow evening SleepProgger/fingerprintjs2@bc6170b complains and suggestion welcome (altho its almost pure renaming)
    Jonas Haag
    @jonashaag

    keep keys and options camelcase. looks correct in your PR.

    For IE plugins, I think we can make the option as follows

    plugins: {
      ie: true
    }

    which would be the default

    Jonas Haag
    @jonashaag
    Asa next step I'd move all the "is foo option enabled" out of the component functions and have main function that checks this in a loop
    so that the component's code checks their own settings at most, but never the fact if they're enabled or disabled entirely, that would be the main function's job