• 0 Posts
  • 38 Comments
Joined 9 months ago
cake
Cake day: June 5th, 2024

help-circle
  • I’d like to tack on that this point can be used to highlight why this is so. It’s a deep concept that can be explained simply and produces a lasting positive impact.

    Everyone has fantasies. Sometimes we want them to be realized. Most often: we don’t. Many people carry internal shame because of their fantasies and some of those people have difficulty with intimacy because of it.

    Good sex with other people requires our investment in their comfort and pleasure. This can be emotionally complex and fulfilling to navigate. Masturbation is free of those complications but we often make up the difference via fantasy. This is normal and there’s no need to confuse one space for the other. Masturbation and sex may fulfill similar basic needs on the surface but, in practice, they are very different exercises. It’s normal for one’s preferences to be different for each and for those preferences to shift over time.

    Don’t worry about “normal”. Focus on having a healthy, honest, and emotionally aware sex life instead.




  • Sure! That’s an SMTP Relay. A lot of folks jumped on the poopoo wagon. It’s common wisdom in IT that you don’t do your own email. There are good reasons for that, and you should know why that sentiment exists, however; if you’re interested in running your own email: try it! Just don’t put all of your eggs in one basket. Keep your third party service until you’re quite sure you want to move it all in-house (after due diligence is satisfied and you’ve successfully completed at least a few months of testing and smtp reputation warming).

    Email isn’t complex. It’s tough to get right at scale, a pain in the ass if it breaks, and not running afoul of spam filtering can be a challenge. It rarely makes sense for even a small business to roll their own email solution. For an individual approaching this investigatively it can make sense so long as you’re (a.) interested in learning about it, (b.) find the benefits outweigh the risks, and (c.) that the result is worth the ongoing investment (time and labor to set up, secure, update, maintain, etc).

    What’ll get you in trouble regardless is being dependent on that in-house email but not making your solution robust enough to always fill its role. Say you host at home and your house burns down. How inconvenient is it that your self-hosted services burned with it? Can you recover quickly enough, while dealing with tragedy, that the loss of common utility doesn’t make navigating your new reality much more difficult?

    That’s why it rarely makes sense for businesses. Email has become an essential gateway to other tooling and processes. It facilitates an incredible amount of our professional interactions. How many of your bills and bank statements and other important communication are delivered primarily by email? An unreliable email service is intolerable.

    If you’re going to do it make sure you’re doing it right, respecting your future self’s reliance on what present-you builds, and taking it slow while you learn (and document!) how all the pieces fit together. If you can check all of those boxes with a smile then good luck and godspeed says I.




  • You’ve fundamentally misunderstood this. Upholding Constitutional law cannot undermine the democratic process which it establishes.

    If I win a game by breaking its rules I am de-facto disqualified from that victory. Yes, all law is written by people, can be unmade by people, and is only in effect so long as we collectively agree to enforce it, however; if the law is not unmade and if we collectively sigh in apathy at its violation then we are no longer playing the game the rules have defined.

    This is the immense danger of the current Constitutional crisis. If there is no enforcement of the rules set forth in a government’s founding document then it can no longer be recognized as the body which that document defines.


  • I do. Thanks. You’re still focused on the wrong thing here.

    Section 3 of the 14th Amendment does not require any specific test which defines “insurrection”. The impeachment is a useful anchor for establishing an agreement that an insurrection did occur and that Trump was, at the very least, an active participant in that insurrection.

    The Insurrection Bar to Office: Section 3 of the Fourteenth Amendment (crsreports.congress.gov) provides an well crafted and neutral review of this. Its closing sentence is particularly relevant to our back and forth:

    Congress has previously viewed Section 3 of the Fourteenth Amendment as establishing an enumerated constitutional qualification for holding office and, consequently, a grounds for possible exclusion.

    Republican strategy has long revolved around the targeted devolution of norms. They hide in the cracks between definitions which assume good faith participation in the labor of mutually consensual governance and shield themselves in perpetual faux-victimhood. If Congress does not pursue the execution of Section 3 it is nothing less than an abdication of their duty to their Oath of Office.

    Your last paragraph is a result of misunderstandings and assumptions on your part.





  • It’s not too late. The 14th amendment Section 3 specifically prohibits an insurrectionist from holding public office unless a special Congressional vote is held and passes with a 2/3rds majority.

    Section 3. No person shall be a Senator or Representative in Congress, or elector of President and Vice President, or hold any office, civil or military, under the United States, or under any State, who, having previously taken an oath, as a member of Congress, or as an officer of the United States, or as a member of any State legislature, or as an executive or judicial officer of any State, to support the Constitution of the United States, shall have engaged in insurrection or rebellion against the same, or given aid or comfort to the enemies thereof. But Congress may, by a vote of two-thirds of each House, remove such disability.

    All US citizens should call their representatives and demand they uphold their sworn Constitutional duty to refuse the certification of Donald Trump’s victory as he is disqualified from holding office.

    This is not speculation. Donald Trump was successfully impeached for inciting insurrection. The US is in the middle of a Constitutional crisis which Congress must resolve.

    Finding your reps is easy. Go here:

    https://www.congress.gov/members/find-your-member

    Either let the site use your location or enter your home address. It’ll pull all the info you need in one click.


  • It’s clear you’re arguing from ignorance as your argument is patently absurd.

    The judgement is partisan, inconsistent with established case law, and relies on (at best) specious distinctions between “information service” and “telecommunication service”. Griffin creates a distinction without a difference to manufacture the perception of judicial leverage where none exists.

    It’s like arguing the DEA has no purview over cannabis because the Reorganization Plan No. 2 of 1973 refers to “marihuana”. It’s clear what the intention of the law is even if the language is imprecise. To argue that ISPs provide some new class of service that’s legally distinct from all other telecom service and therefore immune to regulation is an argument made out of ignorance, stupidity, corruption, or some combination of the three.


  • derek@infosec.pubtolinuxmemes@lemmy.worldnow I know why
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    2 months ago

    The features would break if they were built in.

    You can’t know that and I can’t imagine it would be true. If the plugins many folks find essential were incorporated into GNOME itself then they’d be updated where necessary as a matter of course in developing a new release.

    GNOME has clear philosophy and they work for themselves, not for you so they decide what features they care to invest time and what features they don’t care about.

    You’re not wrong! This is an arrogant and common take produced in poor taste though. A holdover from the elitism that continues to plague so many projects. Design philosophy leads UX decision making and the proper first goal for any good and functional design is user accessibility. This is not limited to accomodations we deem worthy of our attention.

    Good artists set ego aside to better serve their art. Engineers must set pet peeves aside to better serve their projects. If what they find irksome gets in the way of their ability to build functionally better bridges, homes, and software then it isn’t reality which has failed to live up to the Engineer’s standards. This is where GNOME, and many other projects, fall short. Defenders standing stalwart on the technical correctness of a volunteer’s lack of obligation to those whose needs they ostensibly labor for does not induce rightness. It exposes the masturbatory nature of the facade.

    Engineers have every right to bake in options catering to their pet peeves (even making them the defaults). That’s not the issue. When those opinions disallow addressing the accessibility needs of those who like and use what they’ve built there is no justification other than naked pride. This is foolish.

    Having a standardised method for plugins is in my opinion good enough, nobody forces you to use extensions. And if you don’t want extensions to break, then wait till the extensions are ready prior updating GNOME.

    I agree! Having a standardized method for plugins is good, however; the argument which follows misses the point. GNOME lucked into a good pole position as one of the default GNU/Linux DEs and has enjoyed the benefit of that exposure. Continuing to ignore obvious failures in method elsewhere while enshrining chosen paradigms of tool use as sacrosanct alienates users for whom those paradigms are neither resonate nor useful.

    No one will force Engineers to use accessibility features they don’t need. Not needing them doesn’t justify refusing the build them. Not building them as able is an abdication of social responsibility. If an engineer does not believe they have any social responsibility then they shouldn’t participate in projects whose published design philosophy includes language such as:

    People are at the heart of GNOME design. Wherever possible, we seek to be as inclusive as possible. This means accommodating different physical abilities, cultures, and device form factors. Our software requires little specialist knowledge and technical ability.

    Their walk isn’t matching their talk in a few areas and it is right and good to call them to task for it.

    Post statement: This is coming from someone who drives Linux daily, mostly from the console, and prefers GNOME to KDE. All of the above is meant without vitriol or ire and sent in the spirit of progress and solidarity.





  • There’s some good advice in the comments already and I think you’re on the right track. I’d like to add a few suggestions and outline how I think about the problem.

    Ask if the vendor has installation administrator guides, whitepaper, training material, etc. If yes: ask that they send it to you. You may also be able to find these on the vendor’s website, customer portal, or a public knowledgebase / PDF repo.

    I would want to know three things.

    1. How do users authenticate through the application?
    2. What are all of the ways users may access the application (local only, remote desktop, LAN only, full server/client model)?
    3. Does the vendor have any prescribed solutions for defining who has access to the application, at what privilege level, with access to what features?

    i.e. What parts of the user access, authenticate, authorize pipeline do application admins or system admins have control over and how can we exercise that control?

    Based on some context I assume that the app is reading from Active Directory using RADIUS or LDAP for user auth and that people are physically logging into the machine.

    If this is the only method of authentication then I would gate the application with a second account for each employee who requires access for business reasons defined in their job description (or as close as you can get to that level of justification - some orgs never get there). You can then control who has access to the machine via group policy. Once logged in the user can launch the application with their second account (which would have the required admin access) via “Run as…” or whatever other methods you’d prefer. No local admins logging in directly and yet an application which users can launch as admin. Goal achieved.

    This paradigm lets us attempt balancing security concerns with user pain. The technically literate and daringly curious will either already know or soon discover they can leverage this privilege to install software and make some changes to the system. The additional friction, logging, and 1:1 nature of the account structure makes abusing this privilege less attractive and more easily auditable if someone does choose the fool’s path.

    I can imagine more complex set ups within these constraints but they require more work for the same or worse result.

    Ideally you run the app with a service account and user permissions are defined via Security Groups whose level of access is tied to application features instead of system privs. There are other reasonable schemes. This one is box standard and a decent default sans other pressures.

    If other methods of auth are available (like local, social, cloud, etc) then you’ll have more decent options. I would define the security objectives for application access, define the user access objectives from the Organization’s perspective, and then plot each solution against those two axes (napkin graphs - nothing serious). Whichever of the top three is the least administratively burdensome is then selected as my first choice for implementation with the other two as alternatives.

    An aside: unless there is only one reasonable choice most folks find one option insufficient, two options difficult to decide between, and four options as having one option too many - whenever possible, if another party’s buy-in is desired, present either three options or three variations on one option. This succeeds even when the differences are superficial, especially when the subject is technical, and 2x if the project lead is ignorant of the particulars. People like participating.

    I’d then propose these options to my team/direct report/client, decide on a path forward together, and plan the rest from there. There’s more to consider (again dependent on org maturity) but this is enough to get the project oriented and off the ground.

    Regarding FOSS alternatives: you’re likely locked in with the vendor’s proprietary software for monitoring the cameras. There are exceptions but most commercial security system companies don’t consider interoperability when designing their service offerings. It might be worth investigating but I’d be surprised if you find any third party solutions for monitoring the vendor’s cameras which doesn’t require either a forklift replacement of hardware, flashing all of the existing hardware, or getting hacky with the gear/software.

    I hope this helps! <3