V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  mschultz  ›  全部回复第 7 页 / 共 56 页
回复总数  1103
1 ... 3  4  5  6  7  8  9  10  11  12 ... 56  
2024 年 3 月 25 日
回复了 yyzh 创建的主题 分享发现 中国银行香港现已支持在 APP 上远程开通香港银行账号
@lovelylain #5 香港的主流银行(汇丰、中银、恒生、渣打等等等等)在 2019 年 7-8 月前后都取消了基本账户(非高端理财户口)的小额管理费。

至少有香港身份证的话是这样。不知道对纯香港境外(包括大陆)身份的客户有没有什么幺蛾子收费政策。应该……没有吧?
@NoInternet #9 找一个类似 gfwlist 的在线规则,作为 rule-provider 最好支持 behavior: “domain” 的,可以不写 no-resolve

现在 GitHub 上用的人比较多的那些规则好像大多都考虑到这个问题了。国外网站一般都是域名规则,不会随便包含无“no-resolve”标记的 IP 规则
在任何 CIDR 规则之前先把(主流的需要代理的)国外网站用域名规则匹配,这样(至少提前被域名匹配的这部分网站)不会触发本地 DNS 查询导致 DNS Leak ,可以部分解决问题

例如

- RULE-SET,gfwlist,PROXY,no-resolve
- RULE-SET,cncidr,DIRCET
- MATCH,PROXY
2024 年 3 月 16 日
回复了 excit 创建的主题 程序员 苹果高级数据保护密钥丢失
@excit #8 我的 Recovery Key 是 2021 年设置的,2022 年才开启的 ADP ( iOS 16.2 推出),当时开启 ADP 的时候还验证了一下我 2021 年设置的 Recovery Key ,验证通过才成功打开 ADP 。(以上内容是我记录在密码管理器里的笔记)

你说的重新开关 ADP 导致 Recovery Key 改变有两种情况,一是发生在关闭 ADP 时,二是发生在打开 ADP 时。

1. 如果打开 ADP 会导致 Recovery Key 改变,结合我自己的笔记来看,这个操作确实是非常反直觉的,那我的数据也危险了,我现在的 Apple ID 实际生效的 Recovery Key 可能已经不是 2021 年我设置的那个了(感觉不太可能)

2. 自 2022 年初次打开后以后我倒是没再关过 ADP ,所以我暂时不能验证“关闭 ADP”这个操作是否会导致原 Recovery Key 一起失效,等我有时间再试试。

另外,如果如果关闭并重开 ADP 会导致 Apple ID 后台静默改变 Recovery Key 而且不提示不显示(不给你复制、抄写的机会),那确实是非常严重的 bug
2024 年 3 月 16 日
回复了 excit 创建的主题 程序员 苹果高级数据保护密钥丢失
OP 遇到的问题确实有点奇怪,有好多细节与我之前的理解不太一样,其中关键的一点是

Recovery Key 这个东西比 Advanced Data Protection 出现得早,这两个应该是互相独立的功能,前者管的是如何恢复 Apple ID (regain access to your account),后者管的是 iCloud 数据是否端到端加密(就像 ADP 和 Physical Keys 也是相互独立的功能)。

当然,开启 ADP 的 [前提] 是 [已经] 开启 Recovery Key 功能,这是我理解的这两个功能唯一的联系了。所以照理说开关 ADP 应该不会改变另一个安全功能设置的 Key 吧。

如果「 adp 每次关闭再开启都会更新恢复密钥」的话那情况就大不一样了。OP 可以发一下你查的相关资料的链接吗?
2024 年 3 月 14 日
回复了 polobug 创建的主题 京东 京东为了不让用户保价的骚操作
@google2020 #22 还有 ThinkPad 京东自营旗舰店、ThinkPad 京东自营官方旗舰店、ThinkBook 京东自营旗舰店,3 家不同的店😄
2024 年 3 月 12 日
回复了 SayHelloHi 创建的主题 香港 老哥们 下个月准备去 HK 开银行账户 需要带哪些资料~
@mschultz #28 勘误:Apple 的 App Store **美国区**(非 Apple Store )只接受美国发行的银行卡支付
漏掉了区域

另补充:说到 App Store ,如果有了香港银行卡及香港手机号,你可以充值一些香港当地电子钱包或者申请虚拟银行卡(大多会给你 VISA/Mastercard 虚拟卡),然后有 N 种方法做到合法绑定港区 App Store (好歹算个「外区」),这算是香港银行卡在支付功能上比大陆银行卡间接优越的一点吧。
2024 年 3 月 12 日
回复了 SayHelloHi 创建的主题 香港 老哥们 下个月准备去 HK 开银行账户 需要带哪些资料~
@xiaoyutongxue #26,27 仅就境外支付功能而言,如果不考虑各行信用卡的优惠活动,一般而言香港银行卡并不比内地银行卡有多少优势。且香港多数传统银行默认办出来的所谓「银行卡」是银联「提款卡」,在支付功能上非常受限。还不如在内地办一张 VISA/Mastercard 的信用卡支付方便。

至于你提到的 Netflix 、ChatGPT 、YouTube 之类能否支付,关键在于那家服务商是否限制付款卡的地区。例如 ChatGPT 不接受中国大陆**及**香港银行发行的银行卡; Apple 的 App Store (非 Apple Store )只接受美国发行的银行卡支付。(不管卡组织是 VISA/Mastercard 。主要检查发卡行所属国家/地区)

Netflix 及 YouTube 似乎宽松一些,除了在个别地区(比如印度)可能受政策限制外,一般可以接受全球各地发行的 VISA/Mastercard 信用卡。
2024 年 3 月 12 日
回复了 LBLK 创建的主题 全球工单系统 bing 被封了
@naminokoe #1 说明 OP 可能在使用黑名单规则(即只有确定被墙的部分域名使用代理,其他情况默认直连)🤣
2024 年 3 月 10 日
回复了 LeeReamond 创建的主题 软件 有没有老哥讲下 Vaultwarden
@mschultz #9 5. 补充:极少数网站使用的是私有的 TOTP 算法,比如 #8 楼提到的 Steam 。
不过有人说你想折腾的话其实也是可以实现支持的。推荐阅读: https://type.cyhsu.xyz/2023/12/fosspwman/
2024 年 3 月 10 日
回复了 LeeReamond 创建的主题 软件 有没有老哥讲下 Vaultwarden
5. 2FA 字面意义上是一种安全机制,不是一个具体的方法/算法。这里假定你指的是常见的 TOTP 算法(就是一般 6 位数字,30 秒变一次),这个算法是标准化的( RFC6238 ),基本原理就是一个函数 HOTP(K, T),其中 K 是密钥,T 是一个随着时间递增的整数,然后这个函数通过一些内部 Hash 之类的运算最后输出 6 位数字。

一个密码管理器所谓支持保存 TOTP 两步验证码,其实就是帮你保存那个密钥(在网站上设置 2FA 时生成的,经常以二维码的形式给你展示一次,让你用密码管理器去扫),然后支持在任意时刻把这个函数计算的 6 位数字显示出来。由于是标准化的,相当多的密码管理器(包括 Bitwarden 客户端 + Vaultwarden 服务端的组合)都支持这个功能,通用的,你自己写点代码也能实现这么一个输出 6 位验证码的函数出来。

另 Vaultwarden, 1Password 这些服务近年来也开始支持 Passkey 。
2024 年 3 月 10 日
回复了 LeeReamond 创建的主题 软件 有没有老哥讲下 Vaultwarden
3. Bitwarden 官方本身就有开源服务端自建方案( https://bitwarden.com/help/install-on-premise-linux/ ),不过对 Server 的性能要求较高。一般使用小内存 VPS 的玩家会选择 Vaultwarden 。Vaultwarden 是官方服务端自建方案的「平替」,占用资源较小,兼容 Bitwarden 官方的 API 。所以 Vaultwarden 用户在各平台客户端(包括浏览器插件)方面都是用 Bitwarden 官方的。Bitwarden 官方客户端在登录的时候可以选择连接官方服务( bitwarden.com )还是 Self-Hosted 服务(自己的域名)。

原来项目叫 Bitwarden_RS ,顾名思义就是 Bitwarden 服务端的一个第三方 Rust 实现,后来为避免商标争议和误导改名 Vaultwarden 。

4. Vaultwarden 的数据存储文件组织结构比较简单,主要就是一个 SQLite 和一个附件文件夹(如无附件可忽略),文档里有关于备份策略的详细说明: https://github.com/dani-garcia/vaultwarden/wiki/Backing-up-your-vault 多个月前我试过一次直接导入我备份的 sqlite 文件到新部署的 Vaultwarden 中,似乎没啥问题,数据都在。
2024 年 2 月 26 日
回复了 naminokoe 创建的主题 问与答 为什么 2024 年了农村人还死磕虚岁?
硬要解释数学/物理意义的话,虚岁计算的是「一个人自出生以来经历的农历年份数量」,即 #24 @param 的说法。程序来说是一个 「 SELECT COUNT(*) FROM "农历年份表" WHERE "我已出生=True" AND "农历年序号 <= 今年"」的操作。

Wikipedia: https://zh.wikipedia.org/wiki/%E8%99%9A%E5%B2%81

每个讨论虚岁的帖子下面都会有很多玩「娘胎起算」梗的,我觉得是玩错梗、偏题了(引用 #1 @NewYear 说的,「就像很多帖子里的梗,有的人看着很有趣,我看着只想打人。」🤣🤣)。

「娘胎起算」的算法本质上和周岁是一样的,只是起算点不同。除了玩梗,现实世界中绝少见到有人真的用「娘胎起算」法。
而虚岁则完全是另一种算法,传统上被广泛使用。
Email spoofing: https://en.wikipedia.org/wiki/Email_spoofing
另,Google 搜索「伪造发件人地址」也有很多科普文章。

所以情况大概是:1.这个邮件是群发的诈骗邮件,可以忽略它; 2.骗子可能用自动化程序,对某个(某些)以前泄露的数据库/社工库里面的邮箱都发了这种勒索邮件; 3.骗子并没有登录你的 163 邮箱,发件地址是伪造的

一些建议:
1.使用密码管理器,不同网站使用不同密码,能开 2FA 的开 2FA
2.除非你现有的 163 邮箱地址已经广泛用于工作或亲友等现实世界通信,暂不好放弃,其他使用场景下建议逐渐换用口碑更好、垃圾邮件识别更有效的邮箱服务,例如 Gmail 。
2024 年 2 月 5 日
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@changnet #127 至今还在讨论的原因是:1.新税法虽最合理,但新税法下很多人税负增加了,还不如用那个有问题的算法。
2.官方允许老算法继续应用到 2027 年。现行的政策就应该容许批评的声音。
3.这个补丁算法虽然是比更老的算法优惠,但人们永远希望它能更优惠。诶,它不是长得有点儿像超额累进税率吗?人们希望它真的是。毕竟那样又可以交更少的税咯。啊,仔细一看原来不是啊,遗憾,批判一下。

“如何让自己少交点钱” 这个话题别说 2024 年,4202 年也可以热烈讨论啊,如果那时候人类还没灭亡的话
2024 年 2 月 4 日
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@snw #119 你说问题的本质是「(应该)摊到每月收入上再超额累进」,我可不可以进一步解读为「月度收入高的人,其年终奖的税率应该更高一些;月度收入低的人年终奖税率也低一些」。也就是说,新税法的做法最接近问题本质。

只是 19 年前财税界电算水平不高,「最大的问题在于(每个人月度工资不同,所以在快捷计算上)没有实操性。」,所以才实行国税发〔 2005 〕 9 号补丁。

这个补丁其实做了一个隐含的、非常粗糙的假设:就是年终奖越高的人,他的平时工资大概也越高,如果将年终奖均摊到 12 个月(本质算法),均摊过来的这部分更可能直接适用高税率。

因此,年终奖直接适用「全额累进税率」更接近问题的本质。现行方案约等于在全额累进税率的基础上做了一定的「扣除数」补偿。

====
那么现在剩下的主要问题是:这个「扣除数」补偿的*数值选择* 和 *名词选择* 极具误导性,给补偿的解释也挺牵强的。不排除是官方刻意误导(?)。最后也免不了挨骂,这个帖子里那么多回复就是例子。
2024 年 2 月 4 日
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@cmdOptionKana #122 如果要求只是让函数给人感觉「更优美简洁」、不考虑国家税收收入数额问题(我的权力地位还没到考虑这个问题的地步😂)的话 —— 方案微调一下就可以的。

1. 如果想多收税,那就直接明说一次性奖金适用全额累进税率,36000 以下全额 3%,36000 - 144000 全额 10%,依此类推,没有扣除数的概念。
2. 如果不想多收税,想给人民群众优惠,那就一次性奖金直接单独适用 3% - 45% 的超额累进税率。

不用搞弯弯绕的参数,计算也方便好理解,也不怎么缝合。

====
现行的缝合怪方案与上述方案 1 有多大区别呢?感觉就是做了一个「超额累进」的样子,让人民群众观感好一点?
但实质上不是超额累进,然后就被看出端倪的群众骂。反正方案 1 也是挨骂,哈哈。可能骂的人会更多吧。
2024 年 2 月 4 日
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@cmdOptionKana #98
「但我有没有说过,我这个函数,它的计算结果是首尾相连的?我没说过。」
「注意,首尾相连这个要求,是你希望,不是我的承诺。」

实际上你「几乎」承诺了。

首先,根据国税发〔 2005 〕 9 号文的一个链接,https://guangdong.chinatax.gov.cn/gdsw/zjfg/2011-02/23/content_739bbfc1f7364a4a9b6091fc025662a2.shtml
我们进而找到对应的政策解读: https://guangdong.chinatax.gov.cn/gdsw/wzjd/2009-05/07/content_f354ca0442354599a94fc028217ed3d6.shtml

其中有一句:「计算方法是:用全年一次性奖金总额除以 12 个月,按其商数对照工资、薪金所得项目税率表,确定适用税率和对应的速算扣除数,计算缴纳个人所得税。」而这里的「工资、薪金所得项目税率表」,明显是指当时个税法里面的税率表,而个税法明确写了工资薪金所得适用超额累进税率。

也就是说:你引用了超额累进税率表中的数据,还引用了在超额累进税率计算中有特定数学意义的词汇「速算扣除数」,眼看就让广大群众都「觉得」你就就要按照超额累进税率的明确规则计算了 …… 但是一转头,在计算过程中悄悄埋陷阱多收税,导致计算结果根本不是超额累进税率,反而接近全额累进税率。

这就好比你给我一个函数 continuous_function( ),然后说:“我这个函数起名叫 continuous function ,但这只是个惯用名字,我并不保证它在数学意义上是连续的,多想了是你的责任”

怎么说呢,也许这不违法,但在普罗大众眼里,肯定是耍赖了。被喷的话不冤枉。

@chairuosen #99
2024 年 2 月 4 日
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@manasheep #112 取决于你除了年终奖之外的其他应纳税所得额(即除了年终奖外的全年收入,减去 6 万的基本免税额、减去各种专项附加扣除)。

如果这个应纳税所得额是 33000 ,且年终奖在 7-9 万区间。那么你选择按新税法合并计税与年终奖单独计税方案是一样的。如果低于 33000 ,合并计税更好。如果高于 33000 ,年终奖单独计税更好。

我口算的不知对不对,你可以根据税率表格自己验算一下
2024 年 2 月 4 日
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@xmumiffy @snw 又思考了一下国税发〔 2005 〕 9 号的内容,揣测制定者的意思的话,我现在理解是这样的:

1. 旧税法按月计征。
2. 旧税法下,全年一次性奖金会导致某个月收入畸高,那个月的按月税率会畸高。
3. 因此,国税发〔 2005 〕 9 号给旧税法打了个「补丁」,把一次性奖金除以 12 后再按累进税率计税。但这个补丁算法是个缝合怪(金额按全年计算但只减一个月的超额累进税率扣除数),结果从数学意义上既不是超额累进税率也不是全额累进税率,但仍具有全额累进税率的跳变陷阱(无效纳税区间)特征。
4. Nonetheless ,国税发〔 2005 〕 9 号 这个补丁可以认为初步有了新税法「按年计算」的精神雏形。
5. 新税法开始全面按年度综合收入计算,不再以每月计算值为准。
6. 但是,对某些人来说,如果全部收入合并适用新税法,发现应缴税额比「一次性奖金用国税发〔 2005 〕 9 号补丁 + 其他收入用新税法」方案要多。
7. 国家考虑到这种情况,网开一面,允许这些人自行选择缝合怪方案少缴税。这种网开一面目前延续到 2027 年底。

本帖吐槽的是上述第 3 点。

我觉得吐槽是有道理的,国税发〔 2005 〕 9 号那个补丁在计算上就是个缝合怪,很奇怪,不太合理。虽然它比旧税法合理,比旧税法优惠,在某些情况下甚至也比新税法优惠。

但优惠归优惠,合理归合理,两码事,个人认为新税法还是更合理 😄
1 ... 3  4  5  6  7  8  9  10  11  12 ... 56  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   941 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 22:38 · PVG 06:38 · LAX 14:38 · JFK 17:38
♥ Do have faith in what you're doing.