Jonkman Microblog
  • Login
Show Navigation

  • Public

    • Public
    • Network
    • Groups
    • Popular
    • People

Notices by mangeurdenuage (mangeurdenuage@loadaverage.org), page 43

  1. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 18:26:24 EST mangeurdenuage mangeurdenuage
    >Firefox
    Is it ff or just some random JS abomination that is crippling your PC ?
    In conversation Wednesday, 18-Nov-2020 18:26:24 EST from loadaverage.org permalink
  2. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 18:18:23 EST mangeurdenuage mangeurdenuage
    Why ?
    In conversation Wednesday, 18-Nov-2020 18:18:23 EST from loadaverage.org permalink
  3. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 17:54:52 EST mangeurdenuage mangeurdenuage
    Problem is that these fat fucks (google etc....) are making my work/life more difficult each time they go take a shit. Hiring a honeypot bitcoin assassin is beginning to emerge in my mind and I don't like it either.
    In conversation Wednesday, 18-Nov-2020 17:54:52 EST from loadaverage.org permalink
  4. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 17:50:09 EST mangeurdenuage mangeurdenuage
    At this point the "web" should be just named "chrome".
    In conversation Wednesday, 18-Nov-2020 17:50:09 EST from loadaverage.org permalink
  5. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 17:49:36 EST mangeurdenuage mangeurdenuage
    https://lists.webkit.org/pipermail/webkit-dev/2020-November/031604.html

    Hi,

    Today I received a Google Developers email with subject "[Action
    Required] Starting January 4, 2021, we will block all sign-ins to
    Google accounts from embedded browser frameworks." It linked to this
    Google blog post:

    https://loadaverage.org/url/6299912

    Summary: Google will attempt to block logins from "CEF-based apps and
    other non-supported browsers." Presumably "non-supported browsers"
    likely includes non-Safari WebKit, considering how much time I spend
    trying to develop user agent quirks to suppress Google's unsupported
    browser warnings on Gmail, Google Docs, etc. I guess we will find out
    on January 4.

    Google says: "The browser must identify itself clearly in the
    User-Agent. The browser must not try to impersonate another browser
    like Chrome or Firefox." We cannot comply with this because user agent
    spoofing is required for compatibility with various Google websites. I
    am continually fighting to maintain our user agent quirks for Google
    domains, see e.g. [1] or [2]. Even if we were to remove all user agent
    quirks, it would still be impossible for Google to distinguish between
    a desktop browser and an embedded browser framework, since the user
    agent header is going to be the same: Epiphany doesn't even append
    "Epiphany" anymore, in order to maximize the chances that websites will
    treat us like Safari. Even if we did, there are many other WebKit-based
    browsers that would be impacted (off the top of my head: eolie, surf,
    etc.)

    So we'll see what happens on January 4. If our users get locked out of
    google.com, I'll try to come up with new quirks if possible, but if
    Google is really determined to block non-Safari WebKit, it will win.
    E.g. it's easy to do JS feature detection (scary) or TLS handshake
    fingerprinting (extremely scary) and see we are not really the browser
    that our user agent quirk claims to be. We are largely toothless here,
    unfortunately. If Google continues to discriminate solely on the basis
    of the user agent header, and doesn't adopt any more advanced
    discrimination mechanisms, then we will survive, although it would help
    if Apple is willing to take a hard stance and adopt the same set of
    cross-platform quirks in Safari, which would "work" by causing Safari
    to break in the same way as non-Safari WebKit... probably not very
    palatable, but if adopted well in advance of this Jan 4 flag date, it
    would at least make it *harder* for Google to hurt non-Safari WebKit.
    (Adopting the quirks *after* the flag date would likely just
    immediately break Safari.)

    But if Google does this properly and uses more sophisticated browser
    fingerprinting techniques, Epiphany is done for. This could be an
    existential threat for non-Safari WebKit browsers. Nobody is going to
    be interested in using a browser that doesn't support Google websites.
    Google's expressly-stated goal is to block embedded browser frameworks
    and non-supported browsers from signing into Google accounts. The blog
    post says: "This block affects CEF-based apps and other non-supported
    browsers." It says: "We do not allow sign-in from browsers based on
    frameworks like CEF or Embedded Internet Explorer." Clearly CEF is the
    main target, but I guess WebKit (and likely also QtWebEngine) is at
    risk too; even if we're not mentioned directly, it seems pretty clear
    that WebKitGTK, WPE, PlayStation and WinCairo ports, etc. are all
    likely non-grata.

    So what should WebKit do about this? I don't know. Nothing has happened
    yet, so I guess we could wait and see what happens on January 4. Maybe
    this won't affect us at all. But my fear is that January 4 will arrive,
    we will be blocked, and more user agent quirks may or may not work.
    Even if WebKit is not blocked, we can be confident January 4 will be a
    sad day for browser diversity. I wonder if this is something that
    WebKit as a project could push back against... somehow. Maybe publish a
    statement supporting browsers based on embedded frameworks (WebKit,
    CEF, QtWebEngine)? Or some new WebKit project policy? Any suggestions?

    Michael
    In conversation Wednesday, 18-Nov-2020 17:49:36 EST from loadaverage.org permalink

    Attachments

    1. Invalid filename.
      Guidance to developers affected by our effort to block less secure browsers and applications
      from Google Developers Blog
      News and insights on Google platforms, tools, and events.
  6. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 17:49:19 EST mangeurdenuage mangeurdenuage
    https://loadaverage.org/url/6299912

    Guidance to developers affected by our effort to block less secure browsers and applications
    Friday, August 28, 2020

    Posted by Lillan Marie Agerup, Product Manager

    We are always working to improve security protections of Google accounts. Our security systems automatically detect, alert and help protect our users against a range of security threats. One form of phishing, known as “man-in-the-middle”, is hard to detect when an embedded browser framework (e.g., Chromium Embedded Framework - CEF) or another automation platform is being used for authentication. MITM presents an authentication flow on these platforms and intercepts the communications between a user and Google to gather the user’s credentials (including the second factor in some cases) and sign in. To protect our users from these types of attacks Google Account sign-ins from all embedded frameworks will be blocked starting on January 4, 2021. This block affects CEF-based apps and other non-supported browsers.

    To minimize the disruption of service to our partners, we are providing this information to help developers set up OAuth 2.0 flows in supported user-agents. The information in this document outlines the following:

    How to enable sign-in on your embedded framework-based apps using browser-based OAuth 2.0 flows.
    How to test for compatibility.

    Apps that use embedded frameworks

    If you're an app developer and use CEF or other clients for authorization on devices, use browser-based OAuth 2.0 flows. Alternatively, you can use a compatible full native browser for sign-in.

    For limited-input device applications, such as applications that do not have access to a browser or have limited input capabilities, use limited-input device OAuth 2.0 flows.
    Browsers

    Modern browsers with security updates will continue to be supported.
    Browser standards

    The browser must have JavaScript enabled. For more details, see our previous blog post.

    The browser must not proxy or alter the network communication. Your browser must not do any of the following:

    Server-side rendering
    HTTPS proxy
    Replay requests
    Rewrite HTTP headers

    The browser must have a reasonably complete implementation of web standards and browser features. You must confirm that your browser does not contain any of the following:

    Headless browsers
    Node.js
    Text-based browsers

    The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox.

    The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins. We do not allow sign-in from browsers based on frameworks like CEF or Embedded Internet Explorer.
    Test for compatibility

    If you're a developer that currently uses CEF for sign-in, be aware that support for this type of authentication ends on January 4, 2021. To verify whether you'll be affected by the change, test your application for compatibility. To test your application, add a specific HTTP header and value to disable the allowlist. The following steps explain how to disable the allowlist:

    Go to where you send requests to accounts.google.com.
    Add Google-Accounts-Check-OAuth-Login:true to your HTTP request headers.

    The following example details how to disable the allowlist in CEF.

    Note: You can add your custom headers in CefRequestHandler#OnBeforeResourceLoad.

    CefRequest::HeaderMap hdrMap;
    request->GetHeaderMap(hdrMap);
    hdrMap.insert(std::make_pair("Google-Accounts-Check-OAuth-Login", "true"));

    To test manually in Chrome, use ModHeader to set the header. The header enables the changes for that particular request.
    In conversation Wednesday, 18-Nov-2020 17:49:19 EST from loadaverage.org permalink

    Attachments

    1. Invalid filename.
      Guidance to developers affected by our effort to block less secure browsers and applications
      from Google Developers Blog
      News and insights on Google platforms, tools, and events.
  7. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 17:40:54 EST mangeurdenuage mangeurdenuage
    > https://loadaverage.org/attachment/3426144
    In conversation Wednesday, 18-Nov-2020 17:40:54 EST from loadaverage.org permalink
  8. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 17:40:39 EST mangeurdenuage mangeurdenuage
    > https://loadaverage.org/attachment/3873554
    In conversation Wednesday, 18-Nov-2020 17:40:39 EST from loadaverage.org permalink
  9. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 17:31:32 EST mangeurdenuage mangeurdenuage
    in reply to
    • why.
    This is why extraterrestrial life doesn't want to come into contact with the plebs that we are.
    In conversation Wednesday, 18-Nov-2020 17:31:32 EST from loadaverage.org permalink
  10. why. (why@shitposter.club)'s status on Wednesday, 18-Nov-2020 17:22:55 EST why. why.
    relationship goals
    In conversation Wednesday, 18-Nov-2020 17:22:55 EST from shitposter.club permalink Repeated by mangeurdenuage
  11. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 17:18:12 EST mangeurdenuage mangeurdenuage
    >Maybe I do need a woman
    Woman needs a man and a man needs a woman.
    We all go by pairs.
    In conversation Wednesday, 18-Nov-2020 17:18:12 EST from loadaverage.org permalink
  12. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 16:55:04 EST mangeurdenuage mangeurdenuage
    When I mean low end I mean just a GPU for desktop usage, which is also brand new, and with a 2/3 years warranty.

    I tried to avoid retail hardware for customers, because 99.999% of all computer users don't maintain their hardware correctly if I buy a gpu and it dies the next month not only it will cost time and resources to my customer but to me too.

    My margins/profitability comes from me not having to move after the initial maintenance/repair, which is between 2 and three days, the longest that I ever did was 14 days. If I have to move and invest more time then I loose more money.

    I will use retail hardware only when I don't have a choice, and when that happens I'll have to invest more time to see if anything on the board is toasted.
    In conversation Wednesday, 18-Nov-2020 16:55:04 EST from loadaverage.org permalink
  13. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 16:39:42 EST mangeurdenuage mangeurdenuage
    If I ever get a woman I wonder she'll accept the electric generator, the piles of books and electronics laying around this room.
    In conversation Wednesday, 18-Nov-2020 16:39:42 EST from loadaverage.org permalink
  14. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 16:37:31 EST mangeurdenuage mangeurdenuage
    • lnxw48a1
    @Moon
    >I don't play that game.
    Good.
    >I have lost multiple women
    I never lost any, and I'll let you guess why.

    @lnxw48a1
    >If she's erasing your prior life, what happens when she tires of your new life?
    Indeed.
    In conversation Wednesday, 18-Nov-2020 16:37:31 EST from loadaverage.org permalink
  15. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 16:33:45 EST mangeurdenuage mangeurdenuage
    Rember when you could buy a low end gpu for 20 bucks and then*coin miners fucked up the market and now low end gpu can't get bought under 50 bucks ?
    In conversation Wednesday, 18-Nov-2020 16:33:45 EST from loadaverage.org permalink
  16. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 16:07:34 EST mangeurdenuage mangeurdenuage
    Tbh I thought you'd had a woman back in your life and she was asking that you'd throw away everything that she didn't like.
    In conversation Wednesday, 18-Nov-2020 16:07:34 EST from loadaverage.org permalink
  17. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 16:06:06 EST mangeurdenuage mangeurdenuage
    >being surrounded by piles of stuff.
    I can relate but with tools and books.
    In conversation Wednesday, 18-Nov-2020 16:06:06 EST from loadaverage.org permalink
  18. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 15:50:16 EST mangeurdenuage mangeurdenuage
    >all has to go
    Something bad happening ?
    In conversation Wednesday, 18-Nov-2020 15:50:16 EST from loadaverage.org permalink
  19. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 15:39:31 EST mangeurdenuage mangeurdenuage
    You're selling your stuff ?
    In conversation Wednesday, 18-Nov-2020 15:39:31 EST from loadaverage.org permalink
  20. mangeurdenuage (mangeurdenuage@loadaverage.org)'s status on Wednesday, 18-Nov-2020 13:39:55 EST mangeurdenuage mangeurdenuage
    Time for some flute.
    I wasn't able to play for a few days. https://loadaverage.org/attachment/6263744
    In conversation Wednesday, 18-Nov-2020 13:39:55 EST from loadaverage.org permalink
  • After
  • Before
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

Jonkman Microblog is a social network, courtesy of SOBAC Microcomputer Services. It runs on GNU social, version 1.2.0-beta5, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All Jonkman Microblog content and data are available under the Creative Commons Attribution 3.0 license.

Switch to desktop site layout.