Greasy Fork is available in English.
恢复Bilibili旧版页面，为了那些念旧的人。
并没有啊，那条console信息也与所谓“不安全脚本”无关。
按我的理解，所谓的“未经验证的来源”，其实就是说脚本来源主机和当前网页主机不一样，
但本脚本所av页都是同一套网页框架，也不该出现只有个别页面出现提示的情况
我能想到的可能是运营商劫持，往网页里注入了广告脚本之类的第三方脚本
这种我没办法发现，所以也没办法定位是什么脚本
想要知道的话，打开f12控制台，切换到network标签，然后f5刷新网页，如果依然出现这种提示，就可以在下面找到红名的被拦截的网络请求，看看到底是哪个脚本
方才答得有些匆忙，忽然想起来自己安装了默认拦截第三方数据的扩展，回来看看看截图，好吧并没有。
从图中可以看出
在这里就安利一下uMatrix这个扩展，只要安装上，就会帮你屏蔽掉除了css、图片外所有第三方来源的东西，包括很多广告、跟踪的脚本。需要自定义筛选放行(点成绿色) 就是上手难度有点高，因为默认屏蔽第三方，以B站为例，上述三个服务器，除了bilibili.com，另外两个都会被屏蔽，所以装上就默认打不开B站视频了，需要自己手动放行这两个服务器，然后点击那个“锁”，永久保存，一劳永逸。(像我对于B站就是把那个“全部”点绿，然后把“嵌套”默认的红名点掉——B站还是挺让人放心的，没有大部分网站那种直接被扩展内置规则给标红的第三方垃圾广告跟踪脚本)
哦，差点忘了，对于B站还得把上面“三点”那个图标中的“伪造Refferrer”关掉，天知道我第一次使用这个拓展时折腾了多久，把全部来源全部放行也播放不了B站视频的那种
只放行自己许可的，所以这大概也就是我从来没碰到过chrome这种安全提示的原因
@"Motoori Kashin" 十分感谢您的耐心回复！
不过我具体看了下，发现似乎拦截的脚本源头仍然是本脚本？
这一行具体为
xhr.open('GET',url,false);
所处第91行
@redapple0204 说道： @"Motoori Kashin" 十分感谢您的耐心回复！ 不过我具体看了下，发现似乎拦截的脚本源头仍然是本脚本？
这一行具体为
xhr.open('GET',url,false);所处第91行
我大概看懂了你是怎么点进去的，那第一条[deprecation] Synchonous是警告而不是错误，包括你后面展开的12条都是警告，这几条在任意一个av页面都是这样，它是提醒创建xhr链接时推荐使用异步而不是同步，同步会阻断页面渲染，会造成页面加载缓慢……
这些都与本话题“已拦截不安全内容”无关
如果被拦截的话，就不是黄色的感叹号而是红色的叉了
所以我推荐去network里找红名链接而不是在console里找报错，或者用uMatrix看一下到底不安全的来源是哪里
至少肯定不会是本脚本，不信你任意打开一个不会报错的av页面，那1+12条黄色警告依旧存在
@"Motoori Kashin" 说道：
@redapple0204 说道： @"Motoori Kashin" 十分感谢您的耐心回复！ 不过我具体看了下，发现似乎拦截的脚本源头仍然是本脚本？
这一行具体为
xhr.open('GET',url,false);所处第91行
我大概看懂了你是怎么点进去的，那第一条[deprecation] Synchonous是警告而不是错误，包括你后面展开的12条都是警告，这几条在任意一个av页面都是这样，它是提醒创建xhr链接时推荐使用异步而不是同步，同步会阻断页面渲染，会造成页面加载缓慢……
这些都与本话题“已拦截不安全内容”无关
如果被拦截的话，就不是黄色的感叹号而是红色的叉了
所以我推荐去network里找红名链接而不是在console里找报错，或者用uMatrix看一下到底不安全的来源是哪里
至少肯定不会是本脚本，不信你任意打开一个不会报错的av页面，那1+12条黄色警告依旧存在
emm我试着看了一下network里面的红名链接，发现有如下几个
https://api.bilibili.com/x/web-show/res/loc?pf=0&id=160&aid=2231425&jsonp=jsonp
当我把
cn-gdgz4-cmcc-v-07.bilivideo.com
这个域名Block掉之后，现象消失，然而此时无法加载视频（猜测这个地址是视频流播放地址）
如果使用代理，那么分配的地址就会不一样，现象会再次出现
我又研究了一下，发现别的视频的视频流格式都为m4s，只有这个视频是flv，且没有使用HTTPS。
以下为另外的正常视频的实例地址
大概知道了，我使用Chrome80无法复现此问题，猜测是后续版本的Chrome做了某种更改从而忽略此问题，打扰了！
根据你提供的日志：
document.write的执行逻辑，这个注入方式比较混沌，因为请求的资源地址和当前网址不在一个服务器所以浏览器认为它不受信任，但是它并不一定就会被拦截，它只是提示你it MAY be 它可能会被拦截，如果真的被拦截的话会有另外的提示。如果你自己不信任的话，那你就不应该使用这个脚本，因为这个执行方式确实有可能给你注入不安全的东西，实际上只要你安装了第三方脚本无论它是怎么执行的都可以给你注入不安全的东西，但是上面也说了，这个网址其实是B站的另一个服务器，信不信的话还是看你自己@indefined @redapple0204
如果拦截的是视频的话，那浏览器提示“该网页正试图从未经验证的来源加载脚本”提示的难道不只是脚本？还是chrome的本地翻译问题？
flv视频是http这个问题我大概知道，那是因为这个地址直接就写在了网页的html文档里。如今的B站似乎为了加快视频加载速度，不再优先使用playurl这个API获取视频地址，而是在你访问视频页面的时候就把视频地址直接写在了html文档里，如下图。
当然，这个代码我们一般看不到，因为经过浏览器解析所形成的DOM里会自动删除，包括通过该代码写进window的playinfo这个全局变量也会被删除，所以如果不是直接下载html文档的原始代码根本无从发现。
这个问题应该是最近才发生的，因为之前脚本的实现并不会继承这个playinfo数据，前一段时间因为B站开启4K灰度测试，而旧版播放器使用playurl这个API请求视频地址时不会附带fourk参数，服务器也就不会返回4k视频地址。我修改不了播放器请求的playurl链接，所以主动继承了playinfo数据，这样如果是4k视频playinfo就会有4k选项给旧版播放器，算是变相让旧版播放器也能支持4k视频吧，虽然实现上好像仍有问题。
至于为什么大部分视频给的都是https的DASH地址，而这个视频给的是http的flv地址，那只能说这个视频够老了，av号都这么短，老视频是没有DASH版本的。而flv作为一种和旧版播放器一样即将被抛弃的东西，没有用上https只能表示同情。
我试试遇到http直接替换为https看有没有用
关于document.write这个命令是没有办法的办法，因为除了这个命令我找不到阻止原生脚本运行的办法，使用window.stop的话chrome下又不能写入东西，所以那些警告只能无视了。
@"Motoori Kashin" 说道： 如果拦截的是视频的话，那浏览器提示“该网页正试图从未经验证的来源加载脚本”提示的难道不只是脚本？还是chrome的本地翻译问题？
应该确实是翻译问题，你可以直接在一个没有错误提示的https网页下用xhr请求一个http的资源就知道了也会出现相同拦截和提示，这种请求以前是不拦的，现在出于安全考虑以及推进https普及拦截在越来越严。其实如果这个网址本来就写死在初始数据里的话，你继承数据时直接把http:协议删掉就好了，网址只剩//开头的话浏览器会自己继承网页使用的协议，如果B站的后端人员脑袋没问题的话应该是双协议都支持的。或者直接无视反正反正它出错之后也会自己去请求到能播放的地址
关于
document.write这个命令是没有办法的办法，因为除了这个命令我找不到阻止原生脚本运行的办法，使用window.stop的话chrome下又不能写入东西，所以那些警告只能无视了。
出于你这个脚本的执行逻辑的话可能要用别的方法确实比较坑爹，虽然你这个脚本已经很复杂我也很难看懂了。以长期眼光眼光来看的话document.write里写的跨域内容真正被拦截也是早晚的事，不过至少现在还没拦就是了，如果真拦了的话，写入理论上倒是可以用同步等待方法，但是怎么阻止原有加载我就不知道了
已经主动将http替换为https。
其实如果这个网址本来就写死在初始数据里的话，你继承数据时直接把http:协议删掉就好了，网址只剩//开头的话浏览器会自己继承网页使用的协议，如果B站的后端人员脑袋没问题的话应该是双协议都支持的。 我其实尝试过不继承数据，才发现
playurl这个API返回如果是flv的话也是http的，所以还是得继承。去掉协议名称的话我以前也是url不写协议名的，可是之前版本的Tampermonkey偶尔出现过不带协议名称时直接把url(只剩//开头)当成相对引用来处理的情况，追加在当前地址后面造成请求报错，当然如今的版本已经不存在这个问题了，但也养成了主动加上协议名称的习惯。 以长期眼光眼光来看的话document.write里写的跨域内容真正被拦截也是早晚的事 比起这个我更担心B站和谐旧版接口。如今已经和谐的旧版动态更新数据接口，算是通过主动写入cookies的办法补救了一下。其他接口如果和谐的话，又是一番折腾。这些倒也还好。关键是怎么修改旧版播放器请求的链接我是没什么好办法，就像想为playurl主动补上fourk参数也一直没有成功实现。只能通过继承playinfo的办法拐弯地支持4k。
观看部分视频时Chrome会出现“已拦截不安全内容”
RT，例如
Chrome的提示
Console的信息