I don't think you can claim a loss when the reduction in revenue is due to a reserve. But I'm not a tax lawyer, circumstances may vary, yadda yadda.
Accrual of Reserves for Estimated Expenses
Although reserves for contingent liabilities are often set up in business practice, amounts credited to reserves are generally not deductible for income tax purposes because the fact of liability is not fixed ( Portland Copper & Tank Works, Inc., CA-1, 65-2 ustc ¶9687). For example, advance deductions have been denied for additions to a reserve for expected cash discounts on outstanding receivables, amounts credited by a manufacturer to a reserve for possible future warranty service, and additions to a reserve covering estimated liability of a carrier for tort claims. However, to the extent that the Code specifically provides for a deduction for a reserve for estimated expenses, the economic performance rules ( ¶1540) do not apply ( Code Sec. 461(h)(5)).
Not the original poster, but the book "The Best Way to Rob a Bank is to Own One" by William K. Black (former bank regulator during the S&L crisis) might shed some light onto the S&L crisis, if not 2008's comparative response, though not directly.
One of the only reasons I'm still with Google Voice is because having your number with them mitigates (far as I can tell) SIM swap attacks. Yeah, someone can swap my SIM, but effectively nothing goes to the carrier number, just the GV number, which is much harder to socially engineer (even if some of that is because it's impossible to get someone on the phone).
If you tightly lock down your GV account, it should be much more difficult to compromise than a random cell carrier. I don't know if there's a comparable service, but I'm dying to pay for one, if only to not have a single point of failure.
Yeah you nailed the reason that I still use them as my primary number. The problem is who knows if they will kill voice. It just seems random when they decide to kill products. I imagine that they have some kind of scorecard for apps, but it's a precarious place to be that your primary number sits with a product that could be killed on a whim. I agree with you, I would pay in a heartbeat for a service that I knew was going to stick around.
This point, mentioned in the article, bears repeating, especially if you aren't familiar with Lastpass or their 2FA:
Lastpass uses Yubico's one-time password, which is more similar to TOTP than it is to FIDO's U2F (which Yubico had a hand in). Lastpass has had this for YEARS, long before U2F was even a thing, or before Lastpass was bought by LogMeIn.
10 years or so ago (back when I was a paying user of LP), the Yubico OTP was a really nifty bit of security, and probably state-of-the-art, at least to a user like me. Now, not so much. I don't know if this feature has a future, or if there are any plans to phase it out, since U2F is more secure. I'm not sure if there are really any existing applications for it, but this isn't my field of expertise; there might be something novel that can be done.
What I DO know is that users of Lastpass have been asking for U2F as an option for several years now, with no real movement on LP's part. If a one man outfit like Bitwarden, or a famously reticent company like 1Password, can implement U2F, Lastpass has no excuse (to be fair, 1Password's reluctance to implement a second factor was understandable when they didn't have a cloud component in their software).
Unfortunately, the only thing that will likely move LP is if Yubico announces they're dropping the OTP feature entirely.
I'm hoping someone here has some insight they can share, because I've not really seen it addressed elsewhere.
As per the linked article:
> Another new feature it's testing, called "secure value recovery," would let you create an address book of your Signal contacts and store them on a Signal server, rather than simply depend on the contact list from your phone. That server-stored contact list would be preserved even when you switch to a new phone. To prevent Signal's servers from seeing those contacts, it would encrypt them with a key stored in the SGX secure enclave that's meant to hide certain data even from the rest of the server's operating system [1].
I assume that this is an offshoot or a continuation of what Signal started a few years back with Private Contact Discovery, a truly difficult problem considering the amount of user data and metadata Signal wants to avoid collecting [2]. It's a hell of a job, and I commend Signal's efforts.
Assuming I'm right, I'm curious as to why Signal is going down this road, specifically, relying on SGX (or any proprietary vendor solution) for security, or if they should. Due to the spate of speculative execution vulnerabilities in Intel hardware, it would seem to me (a layman) that this is a bad approach that will create more work for them down the line, and may rely too heavily on a single set of features. The Foreshadow attack was one that supposedly compromised SGX, with full mitigation only being possible with hardware revisions [3]. Even then, it may not be safe to assume that's the end of problems. Only recently, another attack on SGX was found, specifically, PlunderVolt [4], which at least can be supposedly mitigated via microcode update vs hardware refresh. Still, it seems like shaky ground, especially to be building additional Signal features upon.
Much further down the list of concerns, it seems like all these SGX-reliant features lock them into using Intel's platform exclusively. It's probably neither here nor there, but is this something they should be concerned about, or is that just the price to be paid for the advanced privacy features Signal offers? Is there any effort to disconnect these features from the hardware platform? Is it even possible? Should they? Am I even asking the right questions?
My worry is that Signal finally reaches some form of feature parity with the biggest messengers (I'd say it's there, mostly), SGX gets broken in a way that's not easy to fix, and all this time and effort will have been wasted, especially if they have to roll back user features which grow the platform in order to maintain safety.
I ask all this having no solutions myself, unfortunately. I'm neither dev nor cryptographer, only someone curious with some mild technical leanings. I generally lump myself in with the average user crowd, knowing just enough to be saddled with the 'Family's IT Person' label, but not enough to actually work in the field...as such, forgive any ignorance or obvious mistakes on my part. I've just not seen these issues addressed, and figured you would be the crowd best able to do so.
From what I understood of the article about secure value recovery [1], SGX is used to derive a more secure key from the password you provide, so a broken SGX alone is not enough to decrypt the data stored on the server, you still need to crack the user’s password. Of course this only helps those people with an actually secure password, which is why they go through all the trouble with SGX. This makes me feel a bit better about their reliance on SGX – as long as you use a long random password stored in my password manager, you don’t have to trust SGX at all.
Thanks for the reply. That makes sense in the context of Secure Value Recovery (to be rolled out, I think); it sounds similar in concept to how 1Password uses a user-derived master password along with a semi-random secret key in order to make a Master Unlock Key, which is then used to open the vault [1]. This seems pretty solid, at least to me.
It doesn't speak to any unexpected weaknesses in SGX due to hardware issues with Intel, though, that could be exploited with speculative execution attacks, and what possible information might be obtained were that to happen. I'm not certain how useful it would be to attack this specific feature to obtain saved social graphs when it may be easier to leverage those speculative execution flaws elsewhere in Signal's back end (I may be talking out my ass here, since even your link was pretty in the weeds for me).
I'm also not sure if it's prudent to trust SGX when it seems its protections can be overcome. Hiding all this information behind different SGX features might be all for naught if SGX itself isn't much of an impediment. Which all gets back to my original concern: is this trust in SGX (and by extension Intel) putting too many eggs in a single basket? Is there any fallback, just in case? What would that look like?
I sure as hell don't know, but I haven't even seen the question asked. Signal hasn't addressed it, and it may not even be worth making hay over, but I figured the smart folks around here would, if nothing else, be able to make some headway.
I was a paid user of LastPass for about a decade. I don't mind a subscription-based model, especially if there's cloud-syncing involved (I've evaluated the amount of risk I'm comfortable with, and cloud syncing is fine for my use case). Part of the benefit for a paid account is the ability to access your passwords when there's a network outage.
However, in the year before I left LP, they went down three times, at most for about 4 hours. Each time, I could not access my local vault, not through the browser extension, not through the Android app, and certainly not through the website; no matter what I did, it was nothing but errors, and their support was useless. It just would not work. That was enough to spook me and get me off their service.
I was complacent, thinking that no matter what, I could always see my vault, regardless of network status, until it actually hit the fan. I'm currently with 1Password, which is quite slick (their change on 2FA is what actually got me to give them a try), but I've killed network access to my devices and was able to access my vaults.
Just in case, though, I have KeePassXC as well. You never know.
It might be even more vulgar than you described, depending on regionalities. In my experience, 'año' indeed means year, while 'ano' literally translates to anus. It's that extra bit of specificity that kills me.
> GDPR compliance can be extremely expensive to implement, especially for complex software comprised of thousands of microservices that handle customer data. And imagine working in an industry where data retention is legally mandated by other jurisdictions...
I only know of the broad strokes of GDPR, but wouldn't the costs be mostly mitigated if one just decided to not collect data? I thought the cost was really only borne if an entity decided to collect and retain data.
Take this with a grain or two of salt, as I don't recall the source, but it seems plausible - I read somewhere that when it comes to businesses like bars, at least in the US, there is a normal rate applied to the cable package, and an additional rate applied 'per head' for the event in question. This may only be for pay-per-view events where multiple people can congregate at a single location which has paid the PPV fee, and not necessarily for widely broadcast events; I've seen sports bars charge cover for highly anticipated MMA matches.
How those rules are enforced is beyond me. Tangentially related, some of the legitimate, paid-for streams have been of pretty low quality, cutting out frequently. Not sure if it's because of draconian DRM or just excessive demand, but it would be interesting to find out.
For pay-per-view events there's usually a commercial PPV sales channel as well. Joe Hand Promotions handled it for the UFC up until this year (now it's all under ESPN+). JHP has some formula for determining cost, it's at least partially determined by venue capacity, hence the use of a cover charge.
I believe UFC still sells with a commercial formula for bars, I don't know if it's through JHP or not, but my understanding is that ESPN+ is for private consumers only
oh, I thought ESPN+ also was doing the commercial licenses. They might handle the delivery now, but yeah, it's Joe Hand still that does the negotiation.
Accrual of Reserves for Estimated Expenses
Although reserves for contingent liabilities are often set up in business practice, amounts credited to reserves are generally not deductible for income tax purposes because the fact of liability is not fixed ( Portland Copper & Tank Works, Inc., CA-1, 65-2 ustc ¶9687). For example, advance deductions have been denied for additions to a reserve for expected cash discounts on outstanding receivables, amounts credited by a manufacturer to a reserve for possible future warranty service, and additions to a reserve covering estimated liability of a carrier for tort claims. However, to the extent that the Code specifically provides for a deduction for a reserve for estimated expenses, the economic performance rules ( ¶1540) do not apply ( Code Sec. 461(h)(5)).
https://answerconnect.cch.com/contents-document/mtg012e61a34...