V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  mschultz  ›  全部回复第 2 页 / 共 50 页
回复总数  995
1  2  3  4  5  6  7  8  9  10 ... 50  
44 天前
回复了 LBLK 创建的主题 全球工单系统 bing 被封了
@naminokoe #1 说明 OP 可能在使用黑名单规则(即只有确定被墙的部分域名使用代理,其他情况默认直连)🤣
45 天前
回复了 LeeReamond 创建的主题 软件 有没有老哥讲下 Vaultwarden
@mschultz #9 5. 补充:极少数网站使用的是私有的 TOTP 算法,比如 #8 楼提到的 Steam 。
不过有人说你想折腾的话其实也是可以实现支持的。推荐阅读: https://type.cyhsu.xyz/2023/12/fosspwman/
45 天前
回复了 LeeReamond 创建的主题 软件 有没有老哥讲下 Vaultwarden
5. 2FA 字面意义上是一种安全机制,不是一个具体的方法/算法。这里假定你指的是常见的 TOTP 算法(就是一般 6 位数字,30 秒变一次),这个算法是标准化的( RFC6238 ),基本原理就是一个函数 HOTP(K, T),其中 K 是密钥,T 是一个随着时间递增的整数,然后这个函数通过一些内部 Hash 之类的运算最后输出 6 位数字。

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

另 Vaultwarden, 1Password 这些服务近年来也开始支持 Passkey 。
45 天前
回复了 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 中,似乎没啥问题,数据都在。
58 天前
回复了 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 。
80 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@changnet #127 至今还在讨论的原因是:1.新税法虽最合理,但新税法下很多人税负增加了,还不如用那个有问题的算法。
2.官方允许老算法继续应用到 2027 年。现行的政策就应该容许批评的声音。
3.这个补丁算法虽然是比更老的算法优惠,但人们永远希望它能更优惠。诶,它不是长得有点儿像超额累进税率吗?人们希望它真的是。毕竟那样又可以交更少的税咯。啊,仔细一看原来不是啊,遗憾,批判一下。

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

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

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

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

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

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

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

====
现行的缝合怪方案与上述方案 1 有多大区别呢?感觉就是做了一个「超额累进」的样子,让人民群众观感好一点?
但实质上不是超额累进,然后就被看出端倪的群众骂。反正方案 1 也是挨骂,哈哈。可能骂的人会更多吧。
80 天前
回复了 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
80 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@manasheep #112 取决于你除了年终奖之外的其他应纳税所得额(即除了年终奖外的全年收入,减去 6 万的基本免税额、减去各种专项附加扣除)。

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

我口算的不知对不对,你可以根据税率表格自己验算一下
80 天前
回复了 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 号那个补丁在计算上就是个缝合怪,很奇怪,不太合理。虽然它比旧税法合理,比旧税法优惠,在某些情况下甚至也比新税法优惠。

但优惠归优惠,合理归合理,两码事,个人认为新税法还是更合理 😄
80 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@GuuJiang #83 😂 所以 @xmumiffy #82 楼认为如果直接叫「扣除数」,去掉「速算」两个字就没争议了。

翻译:我税务总局想扣除多少,你只有遵守的份。我们对年终奖本来实行的就是「全额累进税率」外加固定数额优惠的制度,并不是「超额累进税率」!那个扣除数是全额累进税率各级税率下的固定数额优惠!

但是这个解释仍然牵强。

====
首先,全额累进税率与公众认知、现行税法的精神都不相符。现行个税法对个税实行的是超额累进税率。

其次,如果只是为算法中一个参数改个名字,宣布这是硬性规定的常数 —— 并不能解决税后到手金额跳变的问题,这才是最容易引发争议的点。

再次,如果说这个常数就是算法本身,是个固定数额的优惠钱数,**不是**其他计算方式(即差额累进税率)的简便替代,那为啥偏偏选个「一眼就能看出是差额累进税率月度速算扣除数,仔细一看计算过程又发现在乱用」的数值?咋不选 100 ,200 ,500 这些整的?最后还是只能解释为拍脑袋。
80 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@PrinceofInj #76

这个扣除数是按月来的,比如说你年终奖 37200 , 分摊到每月 3100 ,落入 3000-12000 档,速算扣除数 210 ,那么你「每月分摊的奖金应纳税额」是 3100 x 10% - 210 = 100 元,因此每月分摊到到手奖金 3000 元。再换算回一年,到手奖金 3000 x 12 = 36000 ,共计缴税 1200 元。一切看上去都没问题,是吧?

好,现在离谱的来了,「国家文件规定」你不能像上面那样算,而是要像下面这样算:

假设你年终奖还是 37200 ,首先分摊到每月 3100 ,查表,落入 3000-12000 档,按 10%税率,速算扣除数 210 。然后,你必须用「全年」的奖金 37200 去乘税率,再减去「一个月」的速算扣除数 210 ,即应缴税 37200 x 10% - 210 = 3510 元,到手 37200 - 3510 = 33690 元。

这个陷阱不算高明,数学上的错误也显而易见,但它还是普遍施行了,我只能说挺有意思的。
80 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@PrinceofInj #65 大家吐槽的这个一次性奖金计税算法,其离谱之处正在于你说的「会把所有之前的按更高的税率计算」。

本来,正确的「速算扣除数」可以把多算的税额减掉。但是一次性奖金的计算规则中,不知道谁规定的,一年的奖金计算中,只能减一个月的速算扣除数(你问我为啥我也不理解啊),纳税额扣除得少了,无法抵消税率整体升级的影响,就导致了「多发一块钱到手更少」的情况。

再补充一条参考资料:
5. https://cwc.xtu.edu.cn/info/1025/1263.htm 湘潭大学计划财务处 2018 年的通知,其引用的附件 1 明确提到了「多发一元 多交上千税钱」
80 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@PrinceofInj #65 对,一般人都觉得「多发一块钱,导致税率升级了,只会对多出来的一块钱缴纳更高的税率」才是合理的,你这么觉得,我也这么觉得。

所以当我、楼主、还有这个帖子里很多人发现,现实中的政策居然真的会导致「多发一块钱到手更少」的时候,我们很震惊,觉得很离谱。

但你似乎没发现这种情况在现实中真的存在。如果你觉得这个说法只是一些不懂计算方式的人瞎起哄,那么:

1. https://www.shcpa.org.cn/journal/getJournalView.do?aid=755 《上海注册会计师》期刊文章 - 《年终奖发放中的无效纳税区间陷阱及其成因——兼议国税发[2005]9 号文》
2. https://cwb.hzau.edu.cn/info/1090/4336.htm 华中农业大学财务与资产管理部《关于做好年终绩效分配的通知》
3. https://cwc.xtu.edu.cn/info/1025/1395.htm 湘潭大学计划财务处《关于 2021 年全年一次性奖金个税扣缴有关事项的说明》
4. https://cwc.czu.cn/2021/0120/c4943a120440/page.htm 常州工学院计划财务处《关于全年一次性奖金计税的说明》
等等

都提到了这个无效区间,多发一块钱导致到手更少的问题,这些会计师杂志、大学机构财务处,他们都是瞎起哄吗?
80 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@XueRainey #60 你去搜一下年终奖单独计税时的税率表,它是用"**全年**的税前收入" x "本级税率" - "**一个月**的速算扣除数"

也就是 36001 的年终奖,缴税 36001 * 0.1 - 210 = 3390.1. 扣除的是 210 不是 2520. 大家说年终奖单独计税税率表 SB 就 SB 在这一点。

2520 是全年综合「应纳税所得额」计算个税用的税率表中的扣除数,那个在数学上是没问题的。
80 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
根据原帖内容,我相信 OP 发此贴的重点是讨论「全年一次性奖金单独计税」算法*本身*的反直觉之处,而不是将「单独计税」政策与「纳入综合所得计税」或者其他老税法*作比较*来看看谁优惠。

====

而这个贴里试图为该算法辩解的回复,包括 @snw #38, @PrinceofInj #55 等, 都花费了很多篇幅解释「这个一次性奖金单独计税算法不管怎么说它还算是优惠、人性化,以前/以后按其他算法你们就交更多税、更肉痛了」云云,但都回避了「算法本身为什么那么诡异」的问题。

照理说,任何一个确定的个税算法,最符合所有人直觉的情况应该是「税前越多,税后越多」,即 f(x) 是一个*连续单调增*函数,x 为税前收入,f(x) 为税后收入。这样一个符合直觉的函数,只要结合「一次性奖金单独计税」这个原则,按数学原理算出速算扣除数,制成税率表,同样也符合 @snw #38, @PrinceofInj #55 说的那些优惠啊人性化啊容易理解易操作云云。

但现在政策设计者偏偏要把这个函数搞成一个更奇怪的、不连续的锯齿状函数,如果你的税前收入落在一些(具体是 6 个)区间内时,税后收入还不如「税前收入更低一些」的人。为什么要设计成这样?与连续增函数相比,一定要设计成锯齿状的合理性在哪里?本贴里似乎没有人正面解释这个问题。

实际上你如果去网上搜索,也很难搜到对这个算法合理性的解释,你能搜到的几乎全部都是教你(和公司 HR )发年终奖时怎么规避这些无效区间的。一个全国通用的个税算法,网上搜不到解释其原理的文章,全是教你怎么避坑的文章,这本身不就能说明一些问题吗。

根据目前我能看到的信息(包括网上搜索及本帖内回复),我还是只能认为这种奇怪的算法能出现,要么是政策制定者故意设计的陷阱,想对数学不好的公司多收点儿税;要么是政策制定者本身数学不好。

好奇是否有更具说服力的解释。
81 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@snw #38 这几段,个人感觉好像也没解释「算法的本质」啊。

赞同大部分描述事实的内容(比如全年一次性奖金单独计税对一些人(尤其收入超过基本免税额度的人)而言是一种优惠;这是一种临时性政策;未来可能不再有这种选项,全部按新税法纳入综合所得)。

====
但如果试图接受你的解释,我仍有几点不能理解:


1. 首先按照你的解释,这里的所谓「速算扣除数」是「象征性地」「为了平衡」给出的,并没有严格数学意义。至少,它和个人全年综合所得税率表里面的那个「速算扣除数」(这个我是理解其数学意义的)还不一样。那么首先两个不一样的概念用同一个名字就有误导人之嫌。
2. 「宁可造成 bug 也要给个速算扣除数」—— 如果这个「 bug 」指的是税后奖金的跳变的话,那么「扣除数」并不是造成 bug 的原因。显然,如果不考虑扣除数,算法其他部分不变,即 36000 全额按 3% 计税,36001 全额按 10%,本身就有这个「跳变 bug 」。
3. 你的帖子没有说为什么选择了 210 、1410 、2660…… 这些数学上难以解释的值。只能解释为「税务系统里的专家拍脑袋」么?
4. 总体感觉 #38 之贴文,除了强调「历史/平衡/权衡/专业/不要质疑」等词汇之外,并未提供*具体*、专业而有说服力的解释,或给出参考文献/链接。

====
最后,既然你说(#42 )对财税一知半解/哗众取宠的人才会认为这是 bug ,我们在此引用一篇《上海注册会计师》杂志文章,说明财税界的人也难以解释这个问题:《年终奖发放中的无效纳税区间陷阱及其成因——兼议国税发[2005]9 号文》 https://www.shcpa.org.cn/journal/getJournalView.do?aid=755

> ... 由此可见,无效纳税区间的产生是国税发[2005]9 号的起草者在制度设计时的重大疏漏,简单地把按月计征工资的简便运算所用的速算扣除数用到了已经扩大了 12 倍的年终奖的计算上去了。笔者建议,国家税务总局应尽快修改全年一次性奖金等计算征收个人所得税方法,以实现国家、个人的双赢。
> ...
> 如果国家税务总局同意无效纳税区间的出现,是税收制度设计上的一个疏漏,适时修改全年一次性奖金等计算征收个人所得税方法是恰当的。
> 但是,修订任何制度政府机关都有一个全局的考虑和必要的流程。作为纳税义务人,只能按照现行的法律法规缴纳税金。如果继续按照国税发[2005]9 号计征 2011 年度年终奖的个人所得税,在选择年终奖筹划时,应尽量选无效纳税区间的下限作为年终奖最佳金额...
82 天前
回复了 unt 创建的主题 职场话题 今天才知道年终奖一次性计税的惊天 bug
@ZRS #4 我没理解错的话,现在情况就是

「一个全国范围的政策,其计算某个关键数值时,并非按照汉字字面定义,而是全国规定统一使用一个推导出来的快速口算算法;而这个算法中用到的常数参数,从小学数学意义上讲跟本就推导错了」?

离谱
1  2  3  4  5  6  7  8  9  10 ... 50  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5889 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 25ms · UTC 02:26 · PVG 10:26 · LAX 19:26 · JFK 22:26
Developed with CodeLauncher
♥ Do have faith in what you're doing.