• 0 Posts
  • 650 Comments
Joined 10 months ago
Cake day: April 13th, 2024
  • Kazumara@discuss.tchncs.detoNo Stupid Questions@lemmy.world•Isn't EU's "VAT" a regressive tax? Why do they have that, instead of something like, taxing the rich?
    1·
    2 days ago

    You probably mean the sales taxes, those look similar from a consumer point of view, but they work differently.

    In a VAT system the taxes are collected all along the value addition chain. Each sale of intermediary products has the VAT cost on it, but companies can claim the VAT that they pay for their inputs against the one they collected on their outputs. In effect each company hands over the part of VAT that is raised on their part of the value addition. In the end it all comes from the consumer who buys the final product but doesn’t sell anything onward so they can’t claim their paid VAT against anything. This system determines the end consumer automatically.

    In a sales tax system, only the sale to the final end customer is taxed, and intermediary products are not taxed. Intermediary companies must prove to their suppliers that they are not end customers, that they intend to sell things onward, and that they are therefore exempted from sales tax and the supplier does not have to collect sales tax. If that fails, then that means mistakenly a company has to pay sales tax, and then their customer has to pay it again.

    Other than that I don’t know enough to compare:

    • What is more or less administrative overhead.
    • What is more or less open to fraud.
    • To what degree this is linked to the existence of a single national or many regional tax rates
  • Kazumara@discuss.tchncs.detoAsk Lemmy@lemmy.world•Anybody here whose main use of computers is NOT games?
    5·
    5 days ago

    Hmm it’s difficult to quantify. On workday I spend an average of probably 6-8 hours on a computer with job related tasks. Not really coding most of the time, since we’re maintaining and building a network, so it’s more configuration, planning, coordination, and documentation work. Some days we’re out to actually deploy hardware, or run around and debug stuff, so it’s hard to estimate the average screentime.

    My free time involves a lot of computer time too, but it is split up into more smaller categories, either on the desktop computer or the smartphone computer. Manga, Games, Youtube, Movies, Anime Series, Lemmy, Pornography, News, Banking and Investments.

    In the end I think my job is the biggest unified chunk of time, but that’s kind of arbitrary, if I started subdividing it into different tasks maybe gaming would become the biggest chunk.

  • Kazumara@discuss.tchncs.detoTechnology@lemmy.world•Millions of Subarus could be remotely unlocked, tracked due to security flawsEnglish
    1·
    5 days ago

    Yeah, this kinda bothers me with computer security in general. So, the above is really poor design, right? But that emerges from the following:

    • Writing secure code is hard. Writing bug-free code in general is hard, haven’t even solved that one yet, but specifically for security bugs you have someone down the line potentially actively trying to exploit the code.
    • It’s often not very immediately visible to anyone how actually secure code code is. Not to customers, not to people at the company using the code, and sometimes not even to the code’s author. It’s not even very easy to quantify security – I mean, there are attempts to do things like security certification of products, but…they’re all kind of limited.
    • Cost – and thus limitations on time expended and the knowledge base of whoever you have working on the thing – is always going to be present. That’s very much going to be visible to the company. Insecure code is cheaper to write than secure code.

    There is nothing wrong with your three points, in general. But I think there are some things in this given case that are very visible weak points before getting into the source code:

    • You should not have connections from the cars to the customer support domain at all. There should be a clear delineation between functions, and a single (redundant if necessary) connection gateway for the cars. This is to keep the attack surface small.

    • Authentication is always server side, passwords and reset-question-answers are the same in that regard. Even writing that code on the client was the wrong place from the start.

    • Resetting a password should involve verifying continued access to the associated email account.

    So it seems to me that here the fundamental design was not done securely, far before we get into the hard part of avoiding writing bugs or finding written bugs.

    This could have something to do with the existing structures. E.g. the CS platform was an external product and someone bolted on the password reset later in a bad way. The CS department needed to access details on cars during support calls and instead of going though the service that communicates with the cars usually, it was simpler to implement a separate connection to the cars directly. (I’m just guessing of course)

    Maybe besides cost, there is also an issue that nobody in the organization has an overall responsibility or the power to enforce a sensible design on the interactions between various systems.