Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Jonas Haag
    @jonashaag
    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
    SleepProgger
    @SleepProgger
    just a quick check in: As in add a key -> function map and check if excluded in get / a utility function called from get for each function ?
    Jonas Haag
    @jonashaag
    yeah
    maybe even structure it as follows
    components = {
    canvas: function () {
      return ...
    },
    audio: function (audioOptions) {
      if (onIos && audioOptions.excludeIos11) {
        return ...
      } else {
        return ...
      }
    }
    }

    where return ... is the real fingerprinting code, and component functions are only passed their own options (if any), and simply return their value. That simplifies the code base a lot.

    For async components we'll have to pass a callback as well (maybe leave async components as-is for now; they're a bit more complicated)

    SleepProgger
    @SleepProgger
    ok, sounds good to me. Not sure if i find the time today, but i should get this done the coming days
    andy-law
    @andy-law
    Hi, is there a way to get ES6 import syntax working with Fingerprint2?
    SleepProgger
    @SleepProgger

    @jonashaag : sorry for my long silence, life got a bit busy.
    Current WIP here: SleepProgger/fingerprintjs2@012d255

    A bunch of changes in there:

    • Added components dict and asyncComponents dict
    • Each component now has its own options in options['components'][COMPONENT_NAME]; global options are on the "root" level (like options['preprocessor'] = foo)
    • All key/value pairs are now sorted by the key before hashing to keep the hash stable without having to hardcode the order like it was before (also allows easier async handling)
    • All keys are now camelCase
    • I merged flashFonts and jsFonts keys under the "fonts" component
    • Added fp.UNSUPPORTED and fp.EXCLUDED special values which components functions can return to signal that this component should be excluded/is unsupported. Both cases are currently removed in the get function.

    There is still a bunch of stuff missing + i am not 100% on some decisions (check for //TODO: comments)
    I am off to vacation in 2 days but will react to any critique / suggestions when back

    Jonas Haag
    @jonashaag
    @SleepProgger cool I'll have a look
    Jonas Haag
    @jonashaag
    @SleepProgger added some comments. looks great so far!
    Bonus points if you can remove as many this. attribute accesses as possible since that means readers will easily understand the components are essentially stateless
    at some point we could even move the components to separate files for readability
    SleepProgger
    @SleepProgger
    @jonashaag didn't thought you'd react that fast :)
    I replied to most comments in there and can prob push some minor changes today
    I think the biggest question remaining is how to handle errors.
    additionally error callback for async (Later to be changed to promises) and simply raising errors in sync components sounds like the nicest solution to me.
    Walle Cyril
    @GrosSacASac
    hi
    in last PR Valve/fingerprintjs2#388 did some suggestions of @SleepProgger and @jonashaag found here
    ultramaks
    @ultramaks
    am I correct that for using fingerprint2.js (1.8.2 version) there is no need to include jQuery library anymore?
    Walle Cyril
    @GrosSacASac
    @ultramaks yes
    ultramaks
    @ultramaks
    @GrosSacASac great, thanks! )
    Walle Cyril
    @GrosSacASac
    can I get help for the PR ?
    ultramaks
    @ultramaks
    Got a question. Have the latest version: 1.8.2. I have downloaded and unpacked zip file and run index.html
    And when I run it locally and run at my site I see one difference that leads to diff fingerprints:
    device_memory = 8 local and device_memory = -1 if I run it at my site (or even from local workstation but through local webserver). What is the difference? How does this value calculated?
    Walle Cyril
    @GrosSacASac
    Maybe because of unsecure restrictions, are you using HTTPS in both cases, local and site ?
    ultramaks
    @ultramaks
    No. http only
    Walle Cyril
    @GrosSacASac
    Well that might be it, I know that in chrome and firefox certain features are disabled when not using https, and there are exceptions for localhost
    ultramaks
    @ultramaks
    This is for Opera browser.... For Firefox there is also difference but in regular_plugins: local index.html does not see anything, while from website it sees "Shockwave Flash::Shockwave Flash 24.0 r0::application/x-shockwave-flash~swf,application/futuresplash"
    Walle Cyril
    @GrosSacASac
    chrome and opera use mostly same engine
    ultramaks
    @ultramaks
    I know... I just wondered about the difference for running local fingerprint and from a website