One of their requirements is that you must supply fraud prevention headers when accessing their API.
Which headers are required depends on the type of connection, which in turn will depend on how Tryton is deployed, and which client is in use.
It seems like a lot of this data needs to come directly from the Tryton client, so I was wondering what’s the best way of generating and collecting this data.
Here are some of the headers that are required:
a persistant device uuid, generated and stored on/by the client
a list of all the local IP addresses on the device the client is running on
the IP address and port from which the client make the request
the width, height, scaling-factor and colour-depth of all the screens that are connected to the device the client is running on
the size of the window of the client
the timezone that is in use on the client
the version of the client and server
Also when using the desktop client:
a list of all the local MAC addresses on the device the client is running on
the operating system family and version, and device manufacturer and model, that the client is running on
the operating system user that is running the client
And also when using the web client:
Whether the Do Not Track option is enabled in the browser
The JavaScript reported user agent string from the browser
A list of the browser plugins reported by the browser
This is already generated by tryton. We have a device_id value on the context with contains the identifier and this is automatically generated by the clients.
As a client/server architecture if want to have client details on server side you need to make sure that the client sends this information to the server. I see several options there:
As you have a device_id you may store on server side all the details needed to be sent
The client should fill the context with the data needed so it’s always available and updated on the server.
For both cases you will need to have a plugin for the clients (one for sao and another for tryton) that collects this data and stores it on server side.
After reading a little bit, I must say that for me this has nothing to do with security. I do not know why the government is collecting such data but it does not enforce in any the security.
Any way I think you must focus only on two cases: Desktop application via server and Batch process direct.
It is not stored for now. But I do not see why it could not. Indeed it may be a nice behavior as we could notify client even if they have been disconnected/reconnected.
This is going to be a big issue. I do not think we could include in standard such intrusive private data collection. I think that as it is just declarative and as local IP addresses are pointless, I would go with faking it (ex: sending always 10.0.0.1).
This is available in the _request context.
Again we could not include in standard such collection. But if you go with the Desktop application, they are not required.
I would fake it also. This provides no security. It permits only to profile users.
I guess this could be interesting that the client put this information in the context. For example to format an UTC datetime in an error message using the user timezone.
I would go just with the trytond series as they both need to be the same.
I would fake all of them.
I would put a fixed value as True.
I would fake them also.
I think it is better that we protect our users from external profiling (even if it is a state) when this provide clearly no security feature at all.
According to me the big issue is that businesses that are compelled to submit those data are required by law to do so. Is it a stupid law? Yes it is.
Should we fake the data? I am not sure, we’re trying to help our users ; I would prefer if we explained that the module do not gather those data and that they must do it themselves instead of faking it.
But in case you’re not able to include your data, you have a fallback: you can still explain your situation by email .
It’s good to hear that at least some of the things I’ve listed can be done now, or could be included.
For the rest of the information that they require:
I agree, the amount of data does seem to be quite excessive.
I think this is exactly the point, they are not using it to add security. They are using it to profile users so they can try and identify transactions that don’t match that profile. They are doing this with the aim of finding any unusual activity that could help them identify transactions that might be fraudulent. At least I think that is the reasoning they would probably give you if you asked them.
I’m pretty sure that is not an option, and for anyone who is reading this I just want to be clear that this is not something I am going to do, especially as You are required by law to submit header data for the VAT (MTD) and Income Tax Self Assessment (MTD) APIs.
So:
I’m thinking it might be better to try to get the plugins to only collect this data when it is required for a call to the HMRC API? I’ll see what I can do.
Yes, in fact, I think Tryton could be considered to use nearly all the different connection methods, depending on how it is deployed, with the exception perhaps of the Mobile Application ones.
You can add the plugin only on a specific model and make the pluguin collect the additional data for the client-id and send it to the server.
Then from the server you can raise and Error if you do not have the collected data or it is outdated. This way you can force the user to only get the data before performing the requests.
Then you can create a cron job to delete the data from the tryton server every day to force them to re-run the data when required.
I’m wondering if it will not be simpler that the launch of the action would be made from a custom web page served by trytond (like the checkout of stripe). This page would collect all the information using javascript and post it to a route that launch the action (maybe using a simple user/password form). This way there is no need to customize the client.
.