Jonkman Microblog
  • Login
Show Navigation
  • Public

    • Public
    • Network
    • Groups
    • Popular
    • People

Notices by drak (drak@sn.1w6.org), page 119

  1. drak (drak@sn.1w6.org)'s status on Wednesday, 26-Sep-2018 02:11:19 EDT drak drak
    Disorientation http://www.astrokatie.com/disorientation the only response is to make our own beauty and meaning and to share it while we can
    In conversation Wednesday, 26-Sep-2018 02:11:19 EDT from sn.1w6.org permalink

    Attachments

    1. File without filename could not get a thumbnail source.
      Disorientation
      from Katie Mack, Astrophysicist
  2. drak (drak@sn.1w6.org)'s status on Monday, 24-Sep-2018 17:32:04 EDT drak drak
    Mein erstes Papier: #Carbontracker und TM5-4DVar https://www.draketo.de/physik/erstes-papier-carbontracker-und-tm5-4dvar — mit up-goer-five
    In conversation Monday, 24-Sep-2018 17:32:04 EDT from sn.1w6.org permalink
  3. drak (drak@sn.1w6.org)'s status on Monday, 24-Sep-2018 17:20:36 EDT drak drak
    Erfahrung mit einem Upload-Filter https://twitter.com/ennopark/status/1044325329526018050
    In conversation Monday, 24-Sep-2018 17:20:36 EDT from sn.1w6.org permalink
  4. drak (drak@sn.1w6.org)'s status on Monday, 24-Sep-2018 16:10:04 EDT drak drak
    those who…used laptops had…worse understanding: https://www.nytimes.com/2017/11/22/business/laptops-not-during-lecture-or-meeting.html
    In conversation Monday, 24-Sep-2018 16:10:04 EDT from sn.1w6.org permalink

    Attachments

    1. Invalid filename.
      Laptops Are Great. But Not During a Lecture or a Meeting.
      By By SUSAN DYNARSKI from The New York Times
  5. drak (drak@sn.1w6.org)'s status on Monday, 24-Sep-2018 08:54:57 EDT drak drak
    • Eric Eggert
    I just wish we’d use HTTPS for variable content and HTTP+SRI for standard resources (i.e. JS libs): https://www.draketo.de/proj/sri-check/
    In conversation Monday, 24-Sep-2018 08:54:57 EDT from sn.1w6.org permalink
  6. drak (drak@sn.1w6.org)'s status on Monday, 24-Sep-2018 04:50:07 EDT drak drak
    Windows auto-installs bloatware on clean Windows 10 the moment you log in: https://www.windowscentral.com/microsoft-please-stop-trying-install-third-party-apps-my-clean-windows-10-install
    In conversation Monday, 24-Sep-2018 04:50:07 EDT from sn.1w6.org permalink

    Attachments

    1. Invalid filename.
      Hey, Microsoft, stop installing third-party apps on clean Windows 10 installs!
      from Windows Central
      Microsoft automatically installs six bloatware apps on every Windows 10 PC, even after a clean install. This needs to stop.
  7. drak (drak@sn.1w6.org)'s status on Sunday, 23-Sep-2018 18:41:16 EDT drak drak
    Material für den @nanowrimo: http://www.1w6.org/blog/drak/2018-09-18-ews-30-f-r-den-nanowrimo Beispiele & Ideen für den Entwurf von Personen
    In conversation Sunday, 23-Sep-2018 18:41:16 EDT from sn.1w6.org permalink
  8. drak (drak@sn.1w6.org)'s status on Sunday, 23-Sep-2018 18:04:21 EDT drak drak
    Why I’m done with Chrome https://blog.cryptographyengineering.com/2018/09/23/why-im-leaving-chrome/
    In conversation Sunday, 23-Sep-2018 18:04:21 EDT from sn.1w6.org permalink

    Attachments

    1. Invalid filename.
      Why I’m done with Chrome
      By Matthew Green from A Few Thoughts on Cryptographic Engineering

      This blog is mainly reserved for cryptography, and I try to avoid filling it with random “someone is wrong on the Internet” posts. After all, that’s what Twitter is for! But from time to time something bothers me enough that I have to make an exception. Today I wanted to write specifically about Google Chrome, how much I’ve loved it in the past, and why — due to Chrome’s new user-unfriendly forced login policy — I won’t be using it going forward.

      A brief history of Chrome

      When Google launched Chrome ten years ago, it seemed like one of those rare cases where everyone wins. In 2008, the browser market was dominated by Microsoft, a company with an ugly history of using browser dominance to crush their competitors. Worse, Microsoft was making noises about getting into the search business. This posed an existential threat to Google’s internet properties.

      In this setting, Chrome was a beautiful solution. Even if the browser never produced a scrap of revenue for Google, it served its purpose just by keeping the Internet open to Google’s other products. As a benefit, the Internet community would receive a terrific open source browser with the best development team money could buy. This might be kind of sad for Mozilla (who have paid a high price due to Chrome) but overall it would be a good thing for Internet standards.

      For many years this is exactly how things played out. Sure, Google offered an optional “sign in” feature for Chrome, which presumably vacuumed up your browsing data and shipped it off to Google, but that was an option. An option you could easily ignore. If you didn’t take advantage of this option, Google’s privacy policy was clear: your data would stay on your computer where it belonged.

      What changed?

      A few weeks ago Google shipped an update to Chrome that fundamentally changes the sign-in experience. From now on, every time you log into a Google property (for example, Gmail), Chrome will automatically sign the browser into your Google account for you. It’ll do this without asking, or even explicitly notifying you. (However, and this is important: Google developers claim this will not actually start synchronizing your data to Google — yet. See further below.)

      Your sole warning — in the event that you’re looking for it — is that your Google profile picture will appear in the upper-right hand corner of the browser window. I noticed mine the other day:

      The change hasn’t gone entirely unnoticed: it received some vigorous discussion on sites like Hacker News. But the mainstream tech press seems to have ignored it completely. This is unfortunate — and I hope it changes — because this update has huge implications for Google and the future of Chrome.

      In the rest of this post, I’m going to talk about why this matters. From my perspective, this comes down to basically four points:

      1. Nobody on the Chrome development team can provide a clear rationale for why this change was necessary, and the explanations they’ve given don’t make any sense.
      2. This change has enormous implications for user privacy and trust, and Google seems unable to grapple with this.
      3. The change makes a hash out of Google’s own privacy policies for Chrome.
      4. Google needs to stop treating customer trust like it’s a renewable resource, because they’re screwing up badly.

      I warn you that this will get a bit ranty. Please read on anyway.

      Google’s stated rationale makes no sense

      The new feature that triggers this auto-login behavior is called “Identity consistency between browser and cookie jar” (HN). After conversations with two separate Chrome developers on Twitter (who will remain nameless — mostly because I don’t want them to hate me), I was given the following rationale for the change:

      To paraphrase this explanation: if you’re in a situation where you’ve already signed into Chrome and your friend shares your computer, then you can wind up accidentally having your friend’s Google cookies get uploaded into your account. This seems bad, and sure, we want to avoid that.

      But note something critical about this scenario. In order for this problem to apply to you, you already have to be signed into Chrome. There is absolutely nothing in this problem description that seems to affect users who chose not to sign into the browser in the first place.

      So if signed-in users are your problem, why would you make a change that forces unsigned–in users to become signed-in? I could waste a lot more ink wondering about the mismatch between the stated “problem” and the “fix”, but I won’t bother: because nobody on the public-facing side of the Chrome team has been able to offer an explanation that squares this circle.

      And this matters, because “sync” or not…

      The change has serious implications for privacy and trust

      The Chrome team has offered a single defense of the change. They point out that just because your browser is “signed in” does not mean it’s uploading your data to Google’s servers. Specifically:

      While Chrome will now log into your Google account without your consent (following a Gmail login), Chrome will not activate the “sync” feature that sends your data to Google. That requires an additional consent step. So in theory your data should remain local.

      This is my paraphrase. But I think it’s fair to characterize the general stance of the Chrome developers I spoke with as: without this “sync” feature, there’s nothing wrong with the change they’ve made, and everything is just fine.

      This is nuts, for several reasons.

      User consent matters. For ten years I’ve been asked a single question by the Chrome browser: “Do you want to log in with your Google account?” And for ten years I’ve said no thanks. Chrome still asks me that question — it’s just that now it doesn’t honor my decision.

      The Chrome developers want me to believe that this is fine, since (phew!) I’m still protected by one additional consent guardrail. The problem here is obvious:

      If you didn’t respect my lack of consent on the biggest user-facing privacy option in Chrome (and  didn’t even notify me that you had stopped respecting it!) why should I trust any other consent option you give me? What stops you from changing your mind on that option in a few months, when we’ve all stopped paying attention?

      The fact of the matter is that I’d never even heard of Chrome’s “sync” option — for the simple reason that up until September 2018, I had never logged into Chrome. Now I’m forced to learn these new terms, and hope that the Chrome team keeps promises to keep all of my data local as the barriers between “signed in” and “not signed in” are gradually eroded away.

      The Chrome sync UI is a dark pattern. Now that I’m forced to log into Chrome, I’m faced with a brand new menu I’ve never seen before. It looks like this:

       

      Does that big blue button indicate that I’m already synchronizing my data to Google? That’s scary! Wait, maybe it’s an invitation to synchronize! If so, what happens to my data if I click it by accident? (I won’t give it the answer away, you should go find out. Just make sure you don’t accidentally upload all your data in the process. It can happen quickly.)

      In short, Google has transformed the question of consenting to data upload from something affirmative that I actually had to put effort into — entering my Google credentials and signing into Chrome — into something I can now do with a single accidental click. This is a dark pattern. Whether intentional or not, it has the effect of making it easy for people to activate sync without knowing it, or to think they’re already syncing and thus there’s no additional cost to increasing Google’s access to their data.

      Don’t take my word for it. It even gives (former) Google people the creeps.

      Big brother doesn’t need to actually watch you. We tell things to our web browsers that we wouldn’t tell our best friends. We do this with some vague understanding that yes, the Internet spies on us. But we also believe that this spying is weak and probabilistic. It’s not like someone’s standing over our shoulder checking our driver’s license with each click.

      What happens if you take that belief away? There are numerous studies indicating that even the perception of surveillance can significantly greatly magnify the degree of self-censorship users force on themselves. Will user feel comfortable browsing for information on sensitive mental health conditions — if their real name and picture are always loaded into the corner of their browser? The Chrome development team says “yes”. I think they’re wrong.

      For all we know, the new approach has privacy implications even if sync is off. The Chrome developers claim that with “sync” off, a Chrome has no privacy implications. This might be true. But when pressed on the actual details, nobody seems quite sure.

      For example, if I have my browser logged out, then I log in and turn on “sync”, does all my past (logged-out) data get pushed to Google? What happens if I’m forced to be logged in, and then subsequently turn on “sync”? Nobody can quite tell me if the data uploaded in these conditions is the same. These differences could really matter.

      The changes make hash of the Chrome privacy policy

      The Chrome privacy policy is a remarkably simple document. Unlike most privacy policies, it was clearly written as a promise to Chrome’s users — rather than as the usual lawyer CYA. Functionally, it describes two browsing modes: “Basic browser mode” and “signed-in mode”. These modes have very different properties. Read for yourself:

      In “basic browser mode”, your data is stored locally. In “signed-in” mode, your data gets shipped to Google’s servers. This is easy to understand. If you want privacy, don’t sign in. But what happens if your browser decides to switch you from one mode to the other, all on its own?

      Technically, the privacy policy is still accurate. If you’re in basic browsing mode, your data is still stored locally. The problem is that you no longer get to decide which mode you’re in. This makes a mockery out of whatever intentions the original drafters had. Maybe Google will update the document to reflect the new “sync” distinction that the Chrome developers have shared with me. We’ll see.

      Update: After I tweeted about my concerns, I received a DM on Sunday from two different Chrome developers, each telling me the good news: Google is updating their privacy policy to reflect the new operation of Chrome. I think that’s, um, good news. But I also can’t help but note that updating a privacy policy on a weekend is an awful lot of trouble to go to for a change that… apparently doesn’t even solve a problem for signed-out users.

      Trust is not a renewable resource

      For a company that sustains itself by collecting massive amounts of user data, Google has  managed to avoid the negative privacy connotations we associate with, say, Facebook. This isn’t because Google collects less data, it’s just that Google has consistently been more circumspect and responsible with it.

      Where Facebook will routinely change privacy settings and apologize later, Google has upheld clear privacy policies that it doesn’t routinely change. Sure, when it collects, it collects gobs of data, but in the cases where Google explicitly makes user security and privacy promises — it tends to keep them. This seems to be changing.

      Google’s reputation is hard-earned, and it can be easily lost. Changes like this burn a lot of trust with users. If the change is solving an absolutely critical problem for users , then maybe a loss of trust is worth it. I wish Google could convince me that was the case.

      Conclusion

      This post has gone on more than long enough, but before I finish I want to address two common counterarguments I’ve heard from people I generally respect in this area.

      One argument is that Google already spies on you via cookies and its pervasive advertising network and partnerships, so what’s the big deal if they force your browser into a logged-in state? One individual I respect described the Chrome change as “making you wear two name tags instead of one”. I think this objection is silly both on moral grounds — just because you’re violating my privacy doesn’t make it ok to add a massive new violation — but also because it’s objectively silly. Google has spent millions of dollars adding additional tracking features to both Chrome and Android. They aren’t doing this for fun; they’re doing this because it clearly produces data they want.

      The other counterargument (if you want to call it that) goes like this: I’m a n00b for using Google products at all, and of course they were always going to do this. The extreme version holds that I ought to be using lynx+Tor and DJB’s custom search engine, and if I’m not I pretty much deserve what’s coming to me.

      I reject this argument. I think It’s entirely possible for a company like Google to make good, usable open source software that doesn’t massively violate user privacy. For ten years I believe Google Chrome did just this.

      Why they’ve decided to change, I don’t know. It makes me sad.

       

       

  9. Free Software Foundation (fsf@status.fsf.org)'s status on Thursday, 20-Sep-2018 15:09:41 EDT Free Software Foundation Free Software Foundation
    Are you looking for a new way to support #freesoftware? #GNU Libtool needs a new maintainer: https://u.fsf.org/2o2 Learn about becoming GNU Maintainer here: https://u.fsf.org/2o3
    In conversation Thursday, 20-Sep-2018 15:09:41 EDT from status.fsf.org permalink Repeated by drak
  10. Free Software Foundation (fsf@status.fsf.org)'s status on Wednesday, 19-Sep-2018 10:37:46 EDT Free Software Foundation Free Software Foundation
    Developers, #freesoftware newcomers, activists, policymakers, hackers, artists, tinkerers: submit your sessions for LibrePlanet 2019! The Call For Sessions is open through October 26, and the conference is March 23-24. https://u.fsf.org/2nz
    In conversation Wednesday, 19-Sep-2018 10:37:46 EDT from status.fsf.org permalink Repeated by drak
  11. Free Software Foundation (fsf@status.fsf.org)'s status on Tuesday, 18-Sep-2018 18:17:55 EDT Free Software Foundation Free Software Foundation
    We're so pleased to have the support of other organizations participating in #IDAD International Day Against #DRM! See our list here: https://u.fsf.org/2of ...and see our list of ideas for taking action today!
    In conversation Tuesday, 18-Sep-2018 18:17:55 EDT from status.fsf.org permalink Repeated by drak
  12. Free Software Foundation (fsf@status.fsf.org)'s status on Tuesday, 18-Sep-2018 17:33:03 EDT Free Software Foundation Free Software Foundation
    From @CreativeCommons: #DRM is still here. It’s still bad. Digital freedom depends on the right to tinker, the right to access information and knowledge... https://medium.com/@creativecommons/drm-is-still-here-and-it-still-sucks-aad7a8c33b1f … #IDAD
    In conversation Tuesday, 18-Sep-2018 17:33:03 EDT from status.fsf.org permalink Repeated by drak

    Attachments

    1. Invalid filename.
      DRM is still here, and it still sucks – Creative Commons – Medium
      from Medium
      Here we are, another International Day Against DRM, and of course there are still countless stories about how DRM — digital rights…
  13. drak (drak@sn.1w6.org)'s status on Wednesday, 19-Sep-2018 03:05:10 EDT drak drak
    Ein Hauch von ‘33 – Und plötzlich stehen sie vor deiner Tür http://www.schleckysilberstein.com/2018/09/ein-hauch-von-33-und-plotzlich-stehen-sie-vor-deiner-tur/
    In conversation Wednesday, 19-Sep-2018 03:05:10 EDT from sn.1w6.org permalink

    Attachments

    1. Invalid filename.
      Ein Hauch von ‘33 - Und plötzlich stehen sie vor deiner Tür
      By Schlecky Silberstein from Schlecky Silberstein
      Ein Hauch von ‘33 – Und plötzlich stehen sie vor deiner Tür
  14. drak (drak@sn.1w6.org)'s status on Tuesday, 18-Sep-2018 17:55:44 EDT drak drak
    • Freenet Project
    The !Freenet Web of Trust keeps #communication friendly with total #anonymity: https://www.draketo.de/node/811 #censorship #spam #wot
    In conversation Tuesday, 18-Sep-2018 17:55:44 EDT from sn.1w6.org permalink
  15. drak (drak@sn.1w6.org)'s status on Tuesday, 18-Sep-2018 02:18:37 EDT drak drak
    By the way: my websites are available via #RSS https://www.draketo.de/rss.xml https://www.1w6.org/rss.xml —and have been for years; fulltext
    In conversation Tuesday, 18-Sep-2018 02:18:37 EDT from sn.1w6.org permalink
  16. Free Software Foundation (fsf@status.fsf.org)'s status on Monday, 17-Sep-2018 21:46:51 EDT Free Software Foundation Free Software Foundation
    For our French followers: @aprilorg did a #DRM special in it's radio show on @_CauseCommune_ With guests: JB.Kempf (VLC/@videolan) and the lawyer @mduponchelle For #IDAD it will be airing on Tuesday 18th, 3:30pm CEST on https://cause-commune.fm (around 4:08pm for the talk on DRM)
    In conversation Monday, 17-Sep-2018 21:46:51 EDT from status.fsf.org permalink Repeated by drak

    Attachments

    1. Invalid filename.
      La voix des possibles - 93.1FM
      By cath from Cause Commune
      La voix des possibles – 93.1FM
  17. drak (drak@sn.1w6.org)'s status on Monday, 17-Sep-2018 17:01:58 EDT drak drak
    Wow: https://www.youtube.com/watch?v=4k2Ib9ZtnpU
    In conversation Monday, 17-Sep-2018 17:01:58 EDT from sn.1w6.org permalink

    Attachments

    1. Invalid filename.
      Fairy Tail - Main Theme (Gingertail Cover)
      By Alina Gingertail from YouTube
  18. drak (drak@sn.1w6.org)'s status on Monday, 17-Sep-2018 16:27:44 EDT drak drak
    guile 3 update, september edition: https://lists.gnu.org/archive/html/guile-devel/2018-09/msg00018.html — now with JIT compilation
    In conversation Monday, 17-Sep-2018 16:27:44 EDT from sn.1w6.org permalink
  19. drak (drak@sn.1w6.org)'s status on Monday, 17-Sep-2018 16:11:58 EDT drak drak
    Kriegstote in Europa seit 1618: https://www.zdf.de/dokumentation/terra-x/der-dreissigjaehrige-krieg-verwuestung-und-versoehnung-100.html
    In conversation Monday, 17-Sep-2018 16:11:58 EDT from sn.1w6.org permalink

    Attachments

    1. Invalid filename.
      Der Dreißigjährige Krieg (2/2)
      Der Dreißigjährige Krieg ist als Urkatastrophe der deutschen Geschichte bezeichnet worden. Vierhundert Jahre nach dem Ausbruch des Krieges findet der Zweiteiler über Tagebücher und Briefe einen neuen Zugang zu den verheerenden Ereignissen und berichtet so aus der Sicht der einfachen Menschen.
  20. arunisaac (arunisaac@social.systemreboot.net)'s status on Monday, 17-Sep-2018 14:14:02 EDT arunisaac arunisaac
    • arunisaac
    • louis
    @demonshreder @louis Prompted by this thread, today, I translated 105 of the 605 strings of the Guix project. https://translationproject.org/domain/guix.html It will take a while for my work to be reviewed, and finally accepted upstr…
    In conversation Monday, 17-Sep-2018 14:14:02 EDT from social.systemreboot.net permalink Repeated by drak
  • 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.