v2fly / v2fly-github-io

V2Fly Website & Documentation

Home Page:https://v2fly.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

访问 v2fly.org 时浏览器会向第三方域名发起请求

Mukou-Aoi opened this issue · comments

事情的起因是,最近我在统计自己访问的网站,想要维护一个自己经常访问的外国网站列表。今晚在整理日志的过程中发现了一个很不常见的域名

api.xuann.wang

经调查发现是官方文档 v2fly.org 网站上用于显示贡献者名单的 VuePress 插件所致,由该插件作者(大概也是域名控制人)的 PR #58 引入。

个人认为处于安全考虑,v2fly.org 不应请求由他人控制的域名。毕竟访问该网站的极大概率只有两种人:v2ray 的开发者、v2ray 的用户。而对第三方域名发起请求至少会暴露访问者所使用的 IP 地址和浏览器 UA 等信息。

在这里不是想指控任何人,实际上该域名所指向的服务器会不会记录上述的隐私信息也无所谓:有能力记录本身就是问题所在

This can be improved by reducing the information transmitted to third party domains. My initial solution to this issue will be creating a cloudflare worker that proxy the traffic to strip the user informations as much as possible.

An API Proxy will be used to strip user information from now on.
8f13d71
Screenshot from 2021-08-25 17-01-57

I have received objection from @database64128 about the manner this issue is handled. This change is currently subject to discussion.

commented

Hi, I'm the operator on api.xuann.wang, I want to answer a few questions and hope that will ease your concerns.

First, source code for the API is open source on GitHub and we do not (nor do we planning to) use the information available from visitors traffic.

Second, we have thought about a local solution for getting contributor info but it was ruled about for not being comprehensive enough. But the privacy concerns are real and we may reconsider the decision.

Third, as @xiaokangwang has pointed out, the requests are now gone through a proxy and we no longer have details about the traffic.

Hi, I'm the operator on api.xuann.wang, I want to answer a few questions and hope that will ease your concerns.

Hi, thanks for your reply. As I said, I'm not trying to accuse anyone of wrong doing here, simply voicing a concern.

First, I must emphasize that this behavior is not that easy to be spotted: search in the entire v2fly organization, you won't find a single line of code mentioning that domain. I only found it while going through my logs and the TLD is so uncommon that it catches my eyes instantly.

First, source code for the API is open source on GitHub and we do not (nor do we planning to) use the information available from visitors traffic.

The source code of the API is open or not is non-related. Said information gathering could happen on the server without the API's code involved. In other words: the hosting party of the API could do so without your acknowledgement.

Second, we have thought about a local solution for getting contributor info but it was ruled about for not being comprehensive enough. But the privacy concerns are real and we may reconsider the decision.

Third, as @xiaokangwang has pointed out, the requests are now gone through a proxy and we no longer have details about the traffic.

The current solution isn't perfect, as there are still requests to avatars.githubusercontent.com for the avatars, but I guess that is common enough you couldn't pin that on visiting v2fly.org. I'd say the best solution would be to get everything (including avatars) to local everytime the page is updated then serve them statically.

commented

The current solution isn't perfect, as there are still requests to avatars.githubusercontent.com for the avatar

avatars.githubusercontent.com is a GitHub domain.

I'd say the best solution would be to get everything (including avatars) to local everytime the page is updated then serve them statically.

Sadly that will make the build process quite a hassle.

Perhaps a "privacy enhanced" mode could be implemented in the plugin to address the issue.

avatars.githubusercontent.com is a GitHub domain.

Exactly. It's not something meant to be used on many websites like Gravatar. But still there are sites using them that way, since GitHub does allow them to be accessed outside their websites. So it's not that much a concern for me.

If you haven't accessed any GitHub websites but keep querying many avatars from avatars.githubusercontent.com, although I can't see which avatars you're querying for since the path is protected by TLS, it still could be a hint that you're visiting a website built with VuePress with your plugin added which has many collaborators on many pages, and I can't see many of those around, at least not any well-known ones.

Actually it is also possible to proxy requests made to avatars.githubusercontent.com in a similar way to prevent the leak of visitor ip address as well. If you think a proxy that hide the ip address will be acceptable, we can proxy the request made to Github as well.

Actually it is also possible to proxy requests made to avatars.githubusercontent.com in a similar way to prevent the leak of visitor ip address as well.

Surely if you want to, but as I said I don't really consider it that much a problem. It's just a possible hint , nothing like you can pin this behavior on visiting v2fly.org. Most user of V2Ray would be likely to use a proxy for githubusercontent.com anyway as it's included in the official geosites.dat ( geolocation-!cn > category-dev > github )

My main concern is:

  1. (Resolved) A third-party server could be logging privacy information like IP address and browser UA. Well, we had to trust GitHub for this matter since V2Ray is hosted here (and v2fly.org itself for the same matter).

  2. The request to a lesser-known third-party domain could very likely lead to a direct connection, hence leading to a privacy leak. For avatars.githubusercontent.com it's more likely to be proxied instead as mentioned above.

I still think it's better to make the site completely static, so problems like these can be solved once and for all. It's better performance-wise also, isn't that the whole point of using a static site generator like VuePress in the first place?

commented

@Mukou-Aoi Thanks for opening this issue. The API call has been removed in recent website updates.

Admittedly, requesting external API just to display contributors data seems overkill and too much hassle, but when this is implemented I did not consider the implications behind it.

Your concerns are valid, unfortunately I did not have time to properly resolve it back then.