V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ZE3kr  ›  全部回复第 10 页 / 共 187 页
回复总数  3731
1 ... 6  7  8  9  10  11  12  13  14  15 ... 187  
243 天前
回复了 ciyouwu 创建的主题 宽带症候群 如何合理的消耗手机流量?
那如果你的手机套餐跟我一样是无限流量(并且从不限速),你是不是得用几个 PB 才罢休

https://i.v2ex.co/NlKfq2w4.jpeg

吃自助餐是不是也得把餐厅全都吃完了;家里的宽带也不限流量,是不是得一直跑满带宽才算赚回来

不过有一说一,流量多的话就把 iPhone 上的 Allow More Data on 5G 打开,这样 iPhone 会使用蜂窝流量进行 iCloud 备份和照片同步,FaceTime 也会变得更清晰。视频软件也把画质全都调到最高,把那些省流量功能都关掉,蜂窝网络当 Wi-Fi 用。我一直是这样把 5G 当 Wi-Fi 用的(我的运营商 SIM 卡的 Allow More Data on 5G 甚至是默认开的),一个月也很难超过 100GB 。
246 天前
回复了 haierspi 创建的主题 iPhone 在纠结 是买 15 的 欧版 还是日版
送上全球各个版本 Apple Watch 支持的频段: https://www.apple.com/watch/cellular/
246 天前
回复了 haierspi 创建的主题 iPhone 在纠结 是买 15 的 欧版 还是日版
日版也没有美国这些频段啊,按照你的标准:

n258 (26 GHz) AT&T 、T-Mobile 在用(美国很重要)
n260 (39 GHz) Verizon 、AT&T 、T-Mobile 在用(美国很重要)
n261 (28 GHz) Verizon 、AT&T 、T-Mobile 在用(美国很重要)

用这些频段覆盖的地区已经超过了 b71 和 n71 。不买美版就支持不了这些频段。

不过有一说一,国行缺的那些频段都不是是很重要。比如你去看在美国/加拿大卖的蜂窝版 Apple Watch 就并不支持 b71 和 b29 ;日本销售的 Apple Watch 也不支持 b11 、b21 。但凡这些频段很重要 Apple Watch 蜂窝版也不会阉割掉这些频段。
250 天前
回复了 muscippe 创建的主题 Netflix 土区奈飞,又涨价了
@muscippe 美区限制相同 IP 登录,抱歉
253 天前
回复了 YongXMan 创建的主题 OpenAI GPT-3.5 可以免注册使用了
那怎么盈利,植入广告么?
253 天前
回复了 t41372 创建的主题 Telegram 为什么用 telegram 的人这么多
先问是不是,再问为什么。Telegram 的月活连 WhatsApp 的三分之一都不到,所以用的人算不上多,甚至还没微信多。而 WhatsApp 就是你说的默认端到端。

至于为啥微信和 Telegram 没有端到端还能做到 WhatsApp 的三分之一的用户量。Telegram 大量频道和评论本身就是公开的,对于谁都能加入的公开频道,甚至加入前就可以看到聊天内容的群(所有公开群都是如此),端到端加密自然也没意义了。微信的话也同理,发的东西默认是公开的,不想公开的内容我也不会通过微信发。
AWS 就行,文档和功能都齐全,市场占有率也高,而且还有中国区,而且中国区和国际区用的同一套 API
设置 - 蜂窝里把 Allow More Data on 5G 打开就行了。如果是无限流量的 5G 套餐建议打开这个
然后中国银联在美国可以被当作 Discover 卡组织的卡正常线上线下付款,所以接受程度还是很大的。
不过通过这种方式刷卡在美国是重罪
可以明确的告诉你,没有 CVV 也可以完成境外交易。很多商家让你填写 CVV 只是风控的一部分,建议把卡号涂掉
@hackenfu 有 Watch 版跟支持 WatchOS Call Kit 是两回事,国外论坛有讨论过,没见有支持 Watch Call Kit 的
你说的这两个软件也不支持 Apple Watch Call Kit 啊。我至今没找到支持了这个的软件
263 天前
回复了 arnoldxiao 创建的主题 iPhone Apple 账户余额怎么消费?
@leconio 开发者走的不是 App Store 付款,是 Apple Store 的付款,所以余额用不了
266 天前
回复了 JingXiao 创建的主题 问与答 京东自营的碎屏险靠谱么?
@JingXiao 主要是这样你就无法验证是否真的是原厂屏幕了。你细想一下就会发现我那种方式是唯一验证是 1. 原厂屏幕 2. 官方销售 3. 会在官方留下维修记录且下次官方维修不会出问题 的方式
当你使用前端加密,并同时修改后端加密,以尽可能避免这些攻击时,你会发现你最终实现的东西是跟 Passkey 一样的。Passkey 不但不会泄漏原始密码,同时每次登陆所传输的东西还是不一样的
@userKamtao 用处微乎其微

1. 如果泄漏行为本身发生在前端(如恶意浏览器插件),那无论如何 hash 还是会泄漏原密码(读密码输入框/键盘事件),从而所有网站登录被攻破(无论是否前端加密);
2. 原密码在其他未前端加密平台(是大多数网站)的后端或者传输层被泄漏,也一样可以计算出 hash 后的密文在你的平台上登录;
3. hash 后的密码在你的平台上的后端/传输层泄露,那所有用一样前端的前端加密算法的平台也一样可以登录了

下面考虑情况 3 ,能否每个网站做到不同的 hash ,从而实现每个网站的 hash 算法都不一样。这个可以做到(在 hash 前 append/prepend 一个平台 dependent 字符串就行)。但因为有 1-2 的存在所以 3 的意义有限。此外它带来的麻烦也不少,比如需要修改多个前端(不同客户端和网站)

而且我也提供了解决方案,直接用 Passkey 。用 Passkey 才是王道,而且绝大多数新版的 OS 都支持了
常规的解决方案就是前端不额外加密,密码直接 HTTPS 传,加盐 hash 后存数据库。我敢说绝大多数大厂的登录都是这样的。而且只要是 https 了,那就绝对不是“明文传输”了。如果 OP 觉得 devtools 里是明文有危险,那我可以告诉你,如果黑客都已经能读到这一层数据了,那直接监听键盘,或者直接读密码输入框都是可以做到的。
1 ... 6  7  8  9  10  11  12  13  14  15 ... 187  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   866 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 42ms · UTC 21:29 · PVG 05:29 · LAX 13:29 · JFK 16:29
Developed with CodeLauncher
♥ Do have faith in what you're doing.