search

aframevr / aframe

:a: Web framework for building virtual reality experiences.
https://aframe.io/
MIT License
16.67k stars 3.97k forks source link

GDPR compliance for websites using AFrame #5119

Closed Olm-e closed 3 weeks ago

Olm-e commented 2 years ago

Description: In the current state of the core code, and in many examples, it is made call to github cdn or other websites for assets and eventually components. In Europe since the the publication of the GDPR rules and more recently the Schrems II EUCJ ruling, the transfer of a website users data to a third party and more precisely ones located outside EU (and particularly in the US or under US-based company control) without specific informed consent from the user is outlawed. So for an unknowing person/organisation in Europe making use of the current distribution of Aframe without modification is liable and not "GDPR Compliant" because they cannot control the flow of data on their website for their users. This has huge consequence many don't (want to) see actually, but the good news is Aframe is easily fixable with a few things :

Distribute the /controller and /fonts directory from the assets rep inside a /asset directory in Aframe directly, and replace any occurrence of links to https://cdn.aframe.io and copy the https://dpdb.webvr.rocks/dpdb.json in the same asset dir while also replacing it's https://dpdb.webvr.rocks link in aframe(.min).js by the same /asset/ dir ...

this way Aframe is self contained, can work locally and does not leak user information to other possibly unwanted parties [edit] and also work without problem for people using "no-script" browser addons that restrict the use of external javascript ...

dmarcos commented 2 years ago

Thanks. How is moving the controller models from the aframe assets repo to this repo make a difference? Both are under the aframevr github org and cdn points to the aframe assets repo hosted on github pages. Notice those are passive assets like fetching an image. No user data is collected

Not sure if I understood your approach. You suggested we should bundle all the controllers (we now support 10 different devices and increasing) and default fonts with the A-Frame build? That would grow the build size by an order of magnitude and most would be dead weight. Not sure how moving things to a different repo makes any difference in compliance if assets are gonna be still served through github pages and lazy loaded from the builds. Notice that npm start from the repo is only meant for dev not production.

For sites that consider lazy loading / CDN problematic is not hard to make a custom A-Frame build to replace the URLs with self hosted ones. If you went through the process and want to write the steps down happy to link from docs / faq.

dmarcos commented 2 years ago

@Utopiah has generously written down instructions to make A-Frame work offline / self-hosted

Olm-e commented 2 years ago

when you access an image, the server is still getting some info from the download (thus the use of 1 pixel images by some company to track users) so it is still a leak of personal info (IP is one, like your street, address, phone number else, even if multiple person could use the same) Bundling the controllers and fonts is indeed a weight but not much : as it will not be used so often, the bw cost is linear to users use, and only limited to the webserver, as the users has always to dl them ... The ideas is assets are not downloaded through cdn but together with aframe are hosted on the website directly or it's controlled subsidiaries (and not hardcoded with uncontrollable sources) I'm not using npm generaly and have hand made my own distro as in the issue comment above, maybe will try a better how-to description ... ;)

dmarcos commented 2 years ago

Bundling all the controllers is a lot and I don't think it's viable. For instance, Windows mixed reality controllers alone are 2.6 MB. Just one of the supported devices alone is larger than the A-Frame build (1.89 MB). Those are only fetched from CDN if used.

I suggest generating a self-hosted build as described above if you think you need compliance.

Olm-e commented 2 years ago

the self-host build described above miss the dpdb.json file and as I said before I did it already for my own use with procedure indicated in the first post and done after reading utopia's post... ;) ... but _all_EUwebsites should/would need this for compliance (if you would like to understand what is said above) ... (edit : you are free and gladly invited to attend our discussion about this topic on the 6th of october : https://lvrm.vrse.be )

dmarcos commented 2 years ago

Happy to include more details in the FAQ. PRs are welcome if there are any details missing in @Utopiah's FAQ entry.

diarmidmackenzie commented 1 year ago

List of the issues I believe exist here:

Based on this search the problem components are:

Components & primitives that make use of these components will also be problematic, e.g.

From discussion above, it's clear that @dmarcos is not willing to increase the A-Frame bundle size to accommodate all these assets.

On the other hand @Olm-e is arguing that given the widespread need to deliver GDPR-compliance (I believe this applies to all websites accessible in the EU?), it should be easier than it is to build GDPR-compliant sites on A-Frame.

Small note: I don't see where the dpdb.json file is included. Is this WebVR stuff that's been deprecated? Only reference I can see to this file in the codebase is in the Cordova integration guidelines...

Envisaged Solution

I think a solution that should meet everyone's needs here could be as follows:

  1. A community contained npm package, aframe-gdpr, to be used as follows:
npm i aframe
npm i aframe-gdpr
... you now have a GDPR-compliant A-Frame set-up.
  1. Warnings in A-Frame docs on all the above components that flags that they download contant from a CDN, which may have GDPR implications + a link to aframe-gdpr on npm.

Implementation

Assuming the solution proposed above would work for everyone, what does an implementation look like?

Suggest the following:

Changes to A-Frame:

aframe-gdpr npm package

Maintenance

We need to be sensitive to maintenance costs as A-Frame ecosystem has suffered in the past (and to some extent continues to suffer) due to unmaintained components.

Maintenance on A-Frame will be minimal. Additional overhead is just that whenever a new component is introduced with external CDN dependencies (most likely: new controller models), the same CDPR warnings are put in place.

aframe-gdpr will require updates alongside each new A-Frame release, to copy new assets across. I suspect that's something the community will need to take on, but hopefully there are enough people who care about this to cover this level of maintenance. We can automate as far as possible.

Additional possible option: aframe-gdpr contains an explicit whitelist of components that are GDPR-safe, and deletes all components not on that list. This would address the risk that a non-GDPR compliant components "slipping through" aframe-gdpr. The failure mode in such a case would be the component being unavailable, rather than it violating GDPR by loading and pulling data from a CDN...

Next steps

I'd be happy to:

Would appreciate feedback from:

zach-capalbo commented 1 year ago

I'd suggest one additional use case for these changes:

Offline-only A-Frame apps. Right now, running an a-frame app on from a local server without an active internet connection can be tricky due to the hardcoded CDN paths. It would be very helpful to be able to serve all assets locally on a machine with no internet connection using the same mechanism.

(Edit: Missed the conversation about offline apps above. Still, could make sense to call this aframe-self-hosted or aframe-assets or something like that since it's useful for more than just gdpr compliance)

Olm-e commented 1 year ago

it seems a good solution to me, thanks a lot for the proposal.

On 14/01/2023 13:16, Diarmid Mackenzie wrote:

List of the issues I believe exist here:

  • base A-Frame 1.4.1 is clean AFAICT (based on checking the Network tab on this Hello World example https://aframe.glitch.me/)
  • problems lie in various components that are part of core A-Frame...

Based on this search https://github.com/aframevr/aframe/search?l=JavaScript&q=cdn.aframe.io the problem components are:

  • hand-controls
  • vive-controls
  • hand-tracking-controls
  • hp-mixed-reality-controls
  • magicleap-controls
  • vive-focus-controls
  • gearvr-controls
  • daydream-controls
  • oculus-go-controls
  • oculus-touch-controls
  • valve-index-controls
  • windows-motion-controls
  • text

Components & primitives that make use of these components will also be problematic, e.g.

  • a-text
  • laser-controls

From discussion above, it's clear that @dmarcos https://github.com/dmarcos is not willing to increase the A-Frame bundle size to accommodate all these assets.

On the other hand @Olm-e https://github.com/Olm-e is arguing that given the widespread need to deliver GDPR-compliance (I believe this applies to all websites /accessible/ in the EU?), it should be easier than it is to build GDPR-compliant sites on A-Frame.

/Small note: I don't see where the dpdb.json file is included. Is this WebVR stuff that's been deprectaed? Only reference I can see to this file in the codebase is in the Cordova integration guidelines.../

/Envisaged Solution/

I think a solution that should meet everyone's needs here could be as follows:

  1. A community contained npm package, aframe-gdpr, to be used as follows:

|npm i aframe npm i aframe-gdpr ... you now have a GDPR-compliant A-Frame set-up. |

  1. Warnings in A-Frame docs on all the above components that flags that they download contant from a CDN, which may have GDPR implications + a link to |aframe-gdpr| on npm.

/Implementation/

Assuming the solution proposed above would work for everyone, what does an implementation look like?

Suggest the following:

Changes to A-Frame:

  • Create a global variable |AFRAME_CDN_ROOT| set to |https://cdn.aframe.io|, and update all CDN URLs to
  • Docs updates at top level & on relevant components, to flag GDPR exposures due to CDN, and provide link to aframe-gdpr community component on NPM.

aframe-gdpr npm package

  • Monkey-patches AFRAME_CDN_ROOT to /public/aframe/ or similar
  • NPM package contains all assets required by core A-Frame components, as downloaded from https://cdn.aframe.io
  • When installed it copies them to /public/aframe/ in the project, from which they can be served.

/Maintenance/

We need to be sensitive to maintenance costs as A-Frame ecosystem has suffered in the past (and to some extent continues to suffer) due to unmaintained components.

Maintenance on A-Frame will be minimal. Additional overhead is just that whenever a new component is introduced with external CDN dependencies (most likely: new controller models), the same CDPR warnings are put in place.

aframe-gdpr will require updates alongside each new A-Frame release, to copy new assets across. I suspect that's something the community will need to take on, but hopefully there are enough people who care about this to cover this level of maintenance. We can automate as far as possible.

Additional possible option: aframe-gdpr contains an explicit whitelist of components that are GDPR-safe, and deletes all components not on that list. This would address the risk that a non-GDPR compliant components "slipping through" aframe-gdpr. The failure mode in such a case would be the component being unavailable, rather than it violating GDPR by loading and pulling data from a CDN...

/Next steps/

I'd be happy to:

  • do an A-Frame PR with the changes proposed above
  • build and publish an aframe-gdpr package on npm as proposed above (MIT License, provided as-is: explicitly making no claims that it actually delivers GDPR compliance).

Would appreciate feedback from:

— Reply to this email directly, view it on GitHub https://github.com/aframevr/aframe/issues/5119#issuecomment-1382725320, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABO6WOYV2AK355EE4XBEM63WSKKJVANCNFSM6AAAAAAQQHBZWY. You are receiving this because you were mentioned.Message ID: @.***>

vincentfretin commented 1 year ago

You also need a build of the aframe-inspector without Google Analytics. That was made easier with https://github.com/aframevr/aframe-inspector/pull/644 Please note the the textures modal is also using the aframe CDN for a list of images and https://maxcdn.bootstrapcdn.com is used for fontawesome icons. The code could be rewritten to use @fortawesome/react-fontawesome npm package and adding a flag to disable the textures modal.

vincentfretin commented 1 year ago

A first PR to just have a AFRAME_CDN_ROOT constant that we use in all components instead of hard coding https://cdn.aframe.io/ everywhere would be a big plus, so you have only one line to change to host assets locally or somewhere else. I believe the aframe cdn is actually the following repo https://github.com/aframevr/assets so you can probably clone the repo in the dist folder, and set AFRAME_CDN_ROOT="./assets/"

vincentfretin commented 1 year ago

If we had this in the aframe code and aframe-inspector code: var AFRAME_CDN_ROOT = window.AFRAME_CDN_ROOT || "https://cdn.aframe.io/"; We could use the following, not custom build required:

<head>
  <script>window.AFRAME_CDN_ROOT = "./assets/";</script>
  <script src="./aframe-1.4.1.min.js"></script>
</head>

We also need a variable to be able to disable GA in aframe-inspector.

vincentfretin commented 1 year ago

References to https://dpdb.webvr.rocks/dpdb.json come from webvr-polyfill and also its dependency cardboard-vr-display. You probably can comment the whole code here https://github.com/aframevr/aframe/blob/4f3ed328d0ad13c218caff6c43fc513a39216bda/src/index.js#L13-L26 and create your own build if you don't use Cardboard with an iPhone. Reminder: you need ≤a-scene vr-mode-ui="cardboardModeEnabled:true"> on aframe 1.4.1 if you want to use Cardboard with an iPhone.

Utopiah commented 1 year ago

IMHO the best way to help right now is publishing online a custom build for your, whomever needs and manages to do it first, platform of choice with your set of assets of choices then https://github.com/aframevr/aframe#generating-builds explaining how you did it. Once done and thoroughly tested it might even be interesting to consider it as the default build but because there are a lot of moving pieces and I believe the default build is trying to cover the most hardware, to verify first.

dmarcos commented 1 year ago
Wylt commented 4 months ago

Hello everyone !

Using A-frame 1.6 I don't see any GA cookies anymore. Is this latest build GDPR friendly or should I still setup a CDN Locally ?

dmarcos commented 4 months ago

No an expert on GDPR but think you should be fine.

Wylt commented 4 months ago

Very cool ! Thank you

vincentfretin commented 4 months ago

Yes, we removed GA code in latest aframe inspector, so no more cookie. Be aware that downloaded controllers models in aframe when you go in VR and textures if you open the textures modal in aframe inspector still download from aframe.io cdn (that's GitHub Pages as far as I know) so you may reference GitHub privacy policy (see https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages#data-collection) on your app privacy policy, or still self hosts those assets.

vincentfretin commented 4 months ago

For aframe inspector there is still this pending issue https://github.com/aframevr/aframe-inspector/issues/702 to allow easily self hosting the textures.

vincentfretin commented 1 month ago

For aframe inspector there is still this pending issue aframevr/aframe-inspector#702 to allow easily self hosting the textures.

With https://github.com/aframevr/aframe-inspector/pull/766 it's possible to self-host the textures used by the textures modal.

Utopiah commented 1 month ago

@Olm-e can you please have a look at the provided solution, i.e AFRAME_CDN_ROOT allowing to have no data leave a self-hosting server and potentially close the issue if this is sufficient?

PS: this assumes for non self-hosted content that the current CDN itself does not track. If not it might be important to clarify in e.g https://github.com/aframevr/assets/blob/master/README.md

Olm-e commented 3 weeks ago

Hi, from my pov it should be good, these changes give GDPR compliance and self hosting easy, great ! thanks a lot for the work on this. Now indeed some precise documentation on this would help (in another issue probably ;) )