Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

September 10 2019

16:00

Experimenting with same-provider DNS-over-HTTPS upgrade

As part of  our long standing commitment to making the web safer to use, we will be conducting an experiment to validate our implementation of DNS-over-HTTPS (aka DoH) in Chrome 78. As the name implies, the idea is to bring the key security and privacy benefits of HTTPS to DNS, which is how your browser is able to determine which server is hosting a given website. For example, when connected on a public WiFi, DoH would prevent other WiFi users from seeing which websites you visit, as well as prevent potential spoofing or pharming attacks. This experiment will be done in collaboration with DNS providers who already support DoH, with the goal of improving our mutual users’ security and privacy by upgrading them to the DoH version of their current DNS service. With our approach, the DNS service used will not change, only the protocol will. As a result, existing content controls of your current DNS provider, including any existing protections for children, will remain active.

More concretely, the experiment in Chrome 78 will check if the user’s current DNS provider is among a list of DoH-compatible providers, and upgrade to the equivalent DoH service from the same provider. If the DNS provider isn’t in the list, Chrome will continue to operate as it does today. The providers included in the list were selected for their strong stance on privacy and security, as well as the readiness of their DoH services, and also agreed to participate in the experiment. The goals of this experiment are to validate our implementation and to evaluate the performance impact. 

Our experiment will run on all supported platforms (with the exception of Linux and iOS) for a fraction of Chrome users. On Android 9 and above, if the user has specified a DNS-over-TLS provider in the private DNS settings, Chrome may use the associated DoH provider, and will fallback to the system private DNS upon error.

By keeping the DNS provider as-is and only upgrading to the provider’s equivalent DoH service, the user experience would remain the same. For instance, malware protection or parental control features offered by the DNS provider will continue to work. If DoH fails, Chrome will revert to the provider’s regular DNS service. Opting-out of the experiment will be possible from Chrome 78 by disabling the flag at chrome://flags/#dns-over-https.


Most managed Chrome deployments are excluded from the experiment.  For enterprise and education customers, we invite administrators to read the upcoming release notes for details about DoH policies which will be published on our Chrome Enterprise blog.

With 35 years of history, DNS is used by multiple parties, and enables diverse use cases. In particular, we are aware of how DNS can play an important role in ISP-provided family-safe content filtering. So, we are and will continue to take an incremental approach where we respect any active user-facing features such as family-friendly filters, with steps informed by discussions involving key stakeholders, e.g. ISPs, DNS providers, and organizations with expertise in online safety. We will also take into account performance and reliability statistics sent by users who have agreed to help improve Chrome’s features and performance, as well as user feedback.

This experiment is the humble first step of a long collaborative journey to improve our users’ privacy, security, and safety. We can’t wait to see how DoH performs in the wild, and welcome your feedback!

Kenji Baheux, Chrome Product Manager

September 06 2019

21:38
Enabling Developers and Organizations to Use Differential privacy

September 03 2019

18:12
That’s a Wrap for Google Summer of Code 2019

August 26 2019

21:21

Clearly Recognizable Lines

This past week in Slate (2019-08-19):

Shared Article from Slate Magazine

The Grim Worldview That Explains Trump’s Anti-Immigrant Push, …

The world is not as orderly as these governments would like it to be.

slate.com


The Grim Worldview Behind Trump’s Anti-Immigrant Push, the Hong Kong Protests, and the Kashmir Crisis

The upheavals in all of these nations are all connected.

By JOSHUA KEATING

Also — according to Keating — so are the the revocation of birthright citizenship and ethnic cleansing of ethnic Haitians in the Dominican Republic, the assaults on Rohingya populations in Myanmar and Bengali Muslims in Assam, the One China policy, fears of renewed troubles on the Irish-Northern Irish border in case of a hard Brexit, and separatist conflicts in Kurdistan and Catalonia.

The grim idea that connects them all turns out to be. . . state projects of legibility:

These stories are all signs that national governments are waging a war against ambiguity—of citizenship, of territorial status—to enforce a rigid and uniform vision of statehood. Those who carry out and defend these policies believe they are enforcing order and protecting their societies from lawlessness, but they’re likely to result in a more chaotic and disordered world.

It’s been 100 years since U.S. President Woodrow Wilson, in the wake of World War I, called for the world’s empires to be broken up into states “along clearly recognizable lines of nationality.” . . . But the world is not as orderly a place as the 193 different-colored blobs on a world map would suggest. There are patches of land or groups of people that don’t quite fit neatly into the country they’ve been assigned, creating ambiguity—a condition where political sovereignty and citizenship status are ill-defined or even contradictory. These pockets of ambiguity consist of cultural minorities who find themselves on the wrong side of colonial-era borders, or places like Hong Kong that, for historical reasons, have a significantly different political culture from the country they’re now a part of.

Governments don’t like ambiguity when it comes to their territory or citizenry. In his book Seeing Like a State, the anthropologist James Scott describes how modern states strive to make society “legible”: to “arrange the population in ways that simplified the classic state functions of taxation, conscription, and prevention of rebellion.” . . . This desire for “legibility and simplification” is something all modern bureaucracies share. But in this era, governments have found they can use this desire to fuel an ethnic nationalist political project. By enforcing strict legibility and outlawing ambiguity, governments have a ready pretext to keep undesirable foreigners out, demote the status of minority groups, or end special protections for populations who enjoy a certain level of autonomy. This strategy may not be new. But it’s been widely embraced in our era by governments of very different political persuasions.

–Joshua Keating, The Grim Worldview Behind Trump’s Anti-Immigrant Push, the Hong Kong Protests, and the Kashmir Crisis
Slate (2019-08-19).

See also.

August 22 2019

13:01

Potential uses for the Privacy Sandbox


Today on The Keyword, we outlined our vision for an initiative aimed at evolving the web with architecture that advances privacy, while continuing to support a free and open ecosystem. In order to work toward that vision, we have begun publishing a series of explainers that are intended to be shared and iterated on across the community.

Below, we’ve summarized each of these early proposals, which we are collectively referring to as the Privacy Sandbox.




User information

First, let’s identify how user information is currently used in the ad ecosystem so that we can explore the development of the Privacy Sandbox’s privacy preserving APIs.

Ad Selection

One of the most challenging questions is what your browser could do to allow a publisher to pick relevant content or show a relevant ad to you, while sharing as little information about your browsing history as possible.

We're exploring how to deliver ads to large groups of similar people without letting individually identifying data ever leave your browser — building on the Differential Privacy techniques we've been using in Chrome for nearly 5 years to collect anonymous telemetry information. New technologies like Federated Learning show that it's possible for your browser to avoid revealing that you are a member of a group that likes Beyoncé and sweater vests until it can be sure that group contains thousands of other people.

Conversion Measurement

Publishers and advertisers need to know if advertising actually leads to more business. If it’s driving sales, it’s clearly relevant to users, and if it’s not, they need to improve the content and personalization to make it more relevant. Users then benefit from ads centered around their interests, and advertisers benefit from more effective advertising.

Both Google and Apple have already published early stage thinking to evaluate how one might address some of these use cases. These proposals are a first step in exploring how to address the measurement needs of the advertiser without letting the advertiser track a specific user across sites.

Fraud Prevention

Publishers today often need to detect and prevent fraudulent behavior, for instance false transactions or attempts to fake ad activity to steal money from advertisers and publishers. Many companies, including Google, work to detect and prevent fraud, and that’s especially true of ad companies and ad fraud.

Some of the tools used to legitimately fight fraud today use techniques that can benefit from using more privacy safe mechanisms. One example is the PrivacyPass token, introduced by CloudFlare for Tor users, which is now moving through the standards process.




Protecting the Sandbox Boundary

Our experience has shown us that removing certain capabilities from the web causes developers to find workarounds to keep their current systems working rather than going down the well-lit path. We’ve seen this recently in response to the actions that other browsers have taken to block cookies - new techniques are emerging that are not transparent to the user, such as fingerprinting.

With fingerprinting, developers have found ways to learn tiny bits of information that vary between users, such as what device they have or what fonts they have installed. By combining several of these small data points together they can generate a unique identifier which can then be used to match a user across websites. Unlike cookies, users cannot clear their fingerprint, and this means that even if a user wishes not to be identified, they cannot stop the developer from doing so. We think this subversion of user choice is wrong.

As referenced in May at I/O, we are actively taking steps to prevent fingerprinting. We are proposing the implementation of what we call a privacy budget. With a privacy budget, websites can call APIs until those calls have revealed enough information to narrow a user down to a group sufficiently large enough to maintain anonymity. After that, any further attempts to call APIs that would reveal information will cause the browser to intervene and block further calls.

We appreciate you taking the time to read through our early proposals for building the Privacy Sandbox. We understand it is ambitious and can’t overstate how important it is that this be refined and improved as a result of collaboration across the industry, including other browsers and publishers. We look forward to hearing your thoughts!

Posted by Justin Schuh - Director, Chrome Engineering

August 20 2019

16:00

Chrome Dev Summit is now open for registration!


We’re excited to announce that registration for the seventh Chrome Dev Summit is now open and you can request your invite here today! During the Summit, we will share our vision for and updates on our work towards moving the web platform forward and of course, have a bit of fun. ‘Cuz what’s Chrome Dev Summit, without some fun? 



Event details:
Date: Nov 11-12, 2019
Venue: Yerba Buena Center for the Arts in San Francisco, CA

What’s happening?

Over the two days, we will focus on the latest best practices, tools and updates coming to the web platform and give developers a chance to hear directly from the Chrome product engineering teams. 


Similar to last year, we’ll have a single track of content in one hall so everyone can enjoy all the sessions and have meaningful discussions. We’re also bringing back the Forum where you’ll be able to enjoy demos of the latest web technologies and developer tools as well as engage with the Chrome team as well as folks from the community.


We’ll be adding more details on the event site , as we move closer to the event, so watch out for more in the coming weeks and months.

Can’t attend in person? 

As always, we want to ensure that Chrome Dev Summit stays inclusive and exciting for everyone, regardless of whether you’re joining us in person or online. We’ll be livestreaming the entire two days of content for our online attendees and will also include some exciting livestream-only content. 


Sign up here so we can send you updates on the livestream and other related info around the event.


The Chrome team is committed to making the Web the best platform to give everyone in the world universal access to content and apps. We want to make it easier for developers to bring best-in-class content and experiences to their users, by making it more powerful and by reducing the cost of development. And we hope to do this as responsible citizens of the community, working with others to uphold our principles of promoting the open web.


We look forward to seeing you in San Francisco for yet another awesome Chrome Dev Summit!



Posted by Paul Kinlan, Content-Herder-and-Speaker-Wrangler-in-Chief

August 19 2019

17:29

Things Like This Happen Every Day

But forget the particularities of my case. Here’s the larger point: things like this happen every day, dozens of times a day, in every municipal court in the land. And they happen more often than that in a large number of vehicle stops made on every roadway (and some driveways and parking lots) in the land. Huge numbers of traffic cases, along with misdemeanor and petty disorderly persons cases, give the appearance of serving some legitimate “law and order” purpose but are really just legalized and legalistic mumbo-jumbo tied to revenue-generating schemes. Such schemes are themselves driven not only by law enforcement agencies but by the kind of upstanding citizen who demands “government services” without wanting to pay for them.

–Irfan Khawaja, Cashing the Check of Justice
Policy of Truth (19-Sextilis-2019)

Shared Article from Policy of Truth

Cashing the Check of Justice

But we refuse to believe that the bank of justice is bankrupt. We refuse to believe that there are insufficient funds in the great vaults of opportuni…

Irfan Khawaja @ irfankhawajaphilosopher.com


August 16 2019

20:47
Bringing Live Transcribe's Speech Engine to Everyone

August 09 2019

21:19

Chrome 77 Beta: New performance metrics, new form capabilities, capabilities in origin trials and more

Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 77 is beta as of August 8, 2019.

New Performance Metrics

Largest Contentful Paint

It has not always been easy for developers to measure how quickly the main content of a web page loads and is visible to users. The usefulness of existing metrics varies. Some metrics are only measurable in a lab, while others tell nothing about content that users care about. Consider the example below, taken from a DevTools performance audit. At the time of the first contentful paint, there's no content on screen that a user can interact with.



Largest Contentful Paint attempts to provide more meaningful data by using the largest content element as a proxy for when the main content of the page is likely visible to users.

You're probably asking questions like what does the new metric track? When is the metric reported? How do I improve it if it's slow? For answers to these and other questions, see "Largest Contentful Paint" on web.dev.

First Input Timing

The PerformanceEventTiming interface provides timing information about the latency of the first discrete user interaction, specifically one of key down, mouse down, click, or the combination of pointer down and pointer up. Pointer down may be the start of scrolling, which is not tracked. This is a subset of the EventTiming API, but will be exposed in advance because it provides key metrics to help measure and optimize responsiveness.

New Form Capabilities

Many websites use custom form controls to either add features that aren't available in standard controls or to tailor a form's design. A drawback of custom controls is that data must be stored in hidden <input> elements.

Two new features support custom form controls. The formdata event lets sites use JavaScript instead of hidden <input> elements to add data to a form. With this feature, site builders add a formdata event listener to a form element. The passed event includes a FormData object containing the data being submitted, which can now be modified.

The formdata event only lets sites interact with the submission process. Form-associated custom elements let site creators build custom elements that act like built-in form controls, providing capabilities such as enabling input validation or submitting data to the server.

To learn more and to see example code, read More capable form controls on web.dev.

Origin Trials

This version of Chrome introduces the origin trials listed below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones listed below, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

A Contact Picker for the Web

The Contact Picker API is a new, on-demand picker that allows users to select entries from their contact list and share limited details of the selected entries with a website. It allows users to share only what they want, when they want, and makes it easier for users to reach and connect with their friends and family. See A Contact Picker for the Web for details.

Other features in this release

Enter Key Hint

The enterkeyhint content attribute
is an enumerated attribute for <form> elements that specifies what action label (or icon) to present as the enter key on virtual keyboards. This allows authors to customize the presentation of the enter key to make it more helpful for users. The attribute takes one of enter, done, go, next, previous, search, or send.

Feature Policy Control over Document.domain

The document-domain policy governs access to document.domain. It is enabled by default, and, if disabled, attempting to set document.domain will throw an error.

Layout Instability Monitoring

Adds the LayoutShift interface
to the Performance API, allowing developers to monitor changes to a DOM element's on-screen position.

Limit the "referer" Header's Length to 4kB

Strips the referer header down to an origin when it's size exceeds 4kB.
Servers will often behave in unexpected ways when presented with an overly-long referer header. This is unfortunate, because referer is one header whose length attackers generally retain control over when generating no-cors requests.

Limit registerProtocolHandler() url Argument to http/https

The registerProtocolHandler() now only accepts URLs with http or https schemas. Because the intent of the API is to allow an endpoint to handle something like an SMS message, for example, it doesn't make much sense for handlers to be data URLs, blob URLs, and so on.

New Features for Intl.NumberFormat

This change improves Intl.NumberFormat by adding support for measurement units, currency and sign display policies, and scientific and compact notation.

Overscroll Behavior Logical Longhands

Adds CSS flow-relative properties for controlling overscroll behavior through logical dimensions. flow-relative properties are those that are interpreted relative to the flow of content. The new properties are overscroll-behavior-inline and overscroll-behavior-block.

PerformanceObserverInit Buffered Flag

Adds a buffered flag to observer.observe() so that PerformanceObserver can receive entries created before the call is executed.

WebRTC

RTCPeerConnection.onicecandidateerror
Adds the incecandidateerror event which provides detailed information about WebRTC ICE candidate gathering failures, including the ones defined by STUN (RFC5389) and TURN (RFC5766).

Diagnosing ICE connectivity issues without access to detailed gathering failures can be a challenge. Support for ICE candidate errors is targeted towards better connectivity troubleshooting and network diagnostics.

RTCPeerConnection.restartIce()
Adds a method for triggering an ICE restart which causes a WebRTC connection to try to reconnect. This feature is already available in Chrome by passing the iceRestart argument to createOffer(). restartIce() is a version of this method that works regardless of signalingState.

Service Workers

Preserve Request Priorities through Service Worker
Preserves a request's original priority when it passes through a service worker. Previously, all requests going through a service worker would get "High" priority. This means render-blocking style sheets would have their priority clamped, while less important resources would get boosted.

Service Workers Support Basic HTTP Authentication
Displays HTTP authentication dialog boxes even if the request was from a service worker. This shows the native login dialog shown when an HTTP 401 response is received.

Stop Action for Media Sessions

Adds stop as a MediaSessionAction for calls to MediaSession.setActionHandler(). An action is an event tied specifically to a common media function such as pause or play. The stop action handler is called when the site should stop the playback and clear the state if appropriate. Samples are available on GitHub.

Web Payments: Throw a TypeError on Invalid "basic-card" Data

The PaymentRequest constructor now throws a TypeError when invalid supportedNetworks or supportedTypes are specified for basic card payment.

See Deprecations and Removals for an additional Web Payments update item. For more about recent web payments updates, see W3C Payment API changes in Chrome 77.

Interoperability Improvements

Support Step Timing Functions jump-start|end|both|none

Adds support for a richer set of step animations. Firefox already supports jump-* step timing functions. The step timing functions jump-both, jump-none, jump-start and jump-end were introduced to the spec for easing functions in 2018. Two of these, jump-start and jump-end are aliases for start and end. The remaining two provide increased flexibility for step transitions by enabling step functions in which both or neither endpoint has a discontinuous step. Previously, one and only one of the two endpoints could have a step discontinuity. Adding support in Chromium improves cross-browser interoperability.

white-space: break-spaces

Adds the break-spaces value for the white-space property which specifies that any sequence of preserved white space that would otherwise overflow a line and hang (as per the CSS Text Module spec's Trimming and Positioning rules) must be broken.

With white-space: pre-wrap it's possible to wrap and preserve white space sequences in the middle of a text line. However, if there is a sequence at the end of the line, it either collapses or hangs, maybe overflowing its box area. The new value overflow-wrap: break-spaces allows authors to wrap and preserve these white space sequences. This can be also useful for textarea or contenteditable elements, so that white space sequences added by spacebar press events are handled properly and generate line breaks if needed. Finally, there is an ongoing effort to enhance interoperability of the line breaking CSS properties (white-space, word-break and overflow-wrap) and this new value was defined precisely to achieve that.

Deprecations, and Removals

Card Issuer Networks as Payment Method Names

Remotes support for calling PaymentRequest with card issuer networks (e.g., "visa", "amex", "mastercard") in the supportedMethods field.

Deprecate Web MIDI Use on Insecure Origins

Web MIDI use is classified into two groups: non-privilege use, and privilege use with sysex permission. Until Chrome 77, only the latter use prompts users for permission. To reduce security concerns, permissions will always be requested regardless of sysex use. This means that using Web MIDI on insecure origins will no longer be allowed.

Deprecate WebVR 1.1 API

This API is now deprecated in Chrome, being replaced by the WebXR Device API, which is expected to ship in Chrome 78. The WebVR Origin Trial ended on July 24, 2018.

WebVR was never enabled by default in Chrome, and was never ratified as a web standard. The WebXR Device API is the replacement API for WebVR. Removing WebVR from Chrome allows us to focus on the future of WebXR and remove the maintenance burden of WebVR, as well as reaffirm that Chrome is committed to WebXR as the future for building immersive web-based experiences. Removal is expected in Chrome 79.
17:00
OpenCensus Web: Unlocking Full End-to-End Observability for Your Entire Stack

August 06 2019

15:30
Season of Docs Announces Technical Writing Projects

July 23 2019

14:26

Project Strobe: Updates to Our User Data Policy

On May 30, Google announced the next iteration of Project Strobe, a root-and-branch review of third-party developer access to user data. This announcement included the following two updates to our User Data Policy:

  • We’re requiring extensions to only request access to the least amount of data. While this has previously been encouraged of developers, now we’re making this a requirement for all extensions.
  • We’re requiring more extensions to post privacy policies, including extensions that handle personal communications and user-provided content. Our policies have previously required any extension that handles personal and sensitive user data to post a privacy policy and handle that data securely. Now, we’re expanding this category to include extensions that handle user-provided content and personal communications. Of course, extensions must continue to be transparent in how they handle user data, disclosing the collection, use and sharing of that data. 
The policies for these two changes are now published to the updated User Data Policy. They will go into effect on October 15, 2019.

To ensure compliance with this policy update, we suggest developers check their extensions per the guidelines below. After October 15, 2019, items that violate these updates to the User Data policy will be removed or rejected from the Web Store and will need to become compliant to be reinstated. We will continue to take action on violations of the User Data Policy in its current form.

  • Inventory your extensions' current permissions and, where possible, switch to alternatives that are more narrowly scoped. Additionally, include a list of permissions used and the reasons you require them in your Chrome Web Store listing or in an "about page" in your extension. If you expand the features of your extension and require a new permission, you may only request the new permission in the updated version of the extension.
  • If your extension handles Personal or Sensitive User Data, which now also includes, user-provided content and personal communications, your Product must both post a privacy policy and handle the user data securely, including transmitting it via modern cryptography. To add a privacy policy, use the developer dashboard to link to your privacy policy with your developer account. All your published extensions share the same privacy policy.

You can find more information in the updated User Data FAQ. Thank you for joining us in building a better web with transparency, choice and control for both users and developers.


Posted by Alexandre Blondin and Swagateeka Panigrahy, Chrome Product & Policy

July 22 2019

20:59
The Apache Beam Community in 2019

July 16 2019

22:00

The Color of American Citizenship and What Our Founders Had In Mind

Nancy Pelosi hit the news last week when she criticized Donald Trump’s now-abandoned proposal for a Census citizenship question, and when she described it as motivated by racial resentment:

Pelosi Says Trump Seeks to Make America White Again in Census

By Steven T. Dennis
July 8, 2019, 2:15 PM CDT Updated on July 8, 2019, 4:42 PM CDT

House Speaker Nancy Pelosi accused President Donald Trump’s administration Monday of wanting to make America white again with its plan to add a citizenship question to the 2020 census.

You know his hat? Make America white again. They want to make sure that people, certain people, are counted, Pelosi said at a press conference on election security. It’s really disgraceful and it’s not what our founders had in mind.

–Steven T. Dennis, Pelosi Says Trump Seeks to Make America White Again in Census
Bloomberg, 8 Quintilis 2019.

It’s not unusual for me to disagree with Nancy Pelosi about politically salient topics. But let me mention a few things that I certainly agree with her about:

  1. A lot of Trump’s political proposals coming are, obviously, fundamentally antagonistic to free immigration, hostile to immigrants as people, and harmful to immigrants and their families.

  2. This proposal for a citizenship question is pretty surely an example of that.[1]

  3. A lot of Trump’s anti-immigrant politics are driven by — or sold on the basis of — white racial resentment, and by more or less explicit anxiety about non-white immigrants and large-scale trends in race and demographics. The citizenship question is probably an example of that, too.

  4. That (#1, #2, and #3) really is disgraceful.

What I have to disagree with, here, is that bit at the end. The bit about what our founders had in mind. It’s really not that different from what they had in mind at all. It would have been nice, and it would have been better for America and the entire world if the Founders had something very different in mind from immigration policies crafted to Make America White. It would have been nice, but it isn’t so, and Patriotically Correct aspirational history can’t make it so.

Here’s what the Founders had in mind: in 1790, when Congress passed the first Naturalization Act for the newly-constituted United States, the language of that act directly stated that immigrants had to be white to become part of the citizenry of America: being a free white person was an explicit prerequisite for naturalization. Here’s where the Founders wrote down what they had, explicitly, in mind:

Section 1. Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled, That any alien, being a free white person, who shall have resided within the limits and under the jurisdiction of the United States for the term of two years, may be admitted to become a citizen thereof, on application to any common law court of record, in any one of the states wherein he shall have resided for the term of one year at least, and making proof to the satisfaction of such court, that he is a person of good character, and taking the oath or affirmation prescribed by law, to support the constitution of the United States, which oath or affirmation such court shall administer; . . .

— An Act to establish an uniform Rule of Naturalization (March 26, 1790)
United States Statutes at Large, First Congress, Second Session, 103ff. (Source: Legally White: Naturalization Act of 1790)

Every amendment to the Naturalization Act passed from 1790 up until 1952 repeated the free white person prerequisite formula, or a close variation on it.[2]

The Founders’ generation wrote the prerequisite of being white, quote unquote, over and over again, into constitutions and laws specifying the rights and obligations of citizenship more broadly, at the federal level and at the state level. Skin color prerequisites, nearly identical to the federal prerequisite, were written even more pervasively into the state constitutions and legal codes of antebellum Southern states. For example, in Alabama, the same formulas made white skin color an explicit prerequisite for the franchise and for political office. At the federal level, to take another example, in 1792 Congress said that the color of your skin (as well as your gender and citizenship) mattered to your eligibility, and obligation, to serve in the militia:

Section 1. Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled, That each and every free able-bodied white male citizen of the respective states, resident therein, who is or shall be of the age of eighteen years, and under the age of forty-five years (except as is herein after excepted) shall severally and respectively be enrolled in the militia by the captain or commanding officer of the company, within whose bounds such citizen shall reside, and that within twelve months after the passing of this act.

— An Act more effectually to provide for the National Defence by establishing an Uniform Militia throughout the United States (May 8, 1792)
United States Statutes at Large, First Congress, Second Session, 271-274. (Source: Legally White: Uniform Militia Act of 1792).

There is no question that the Founders conceived of the United States government, and framed it explicitly, as a racial state, and that whiteness was an explicit condition on citizenship and political participation. I don’t mean that a tacit desire to Make America White shows up if you read between the lines of political rhetoric in a slaveholding Republic; I mean that they wrote down the words white person in laws as a prerequisite. It directly shaped their conception of citizenship; it was explicitly part of their immigration and naturalization policy. If you weren’t a white person, you couldn’t become an American citizen.[3] That shouldn’t be very surprising: our Founders founded the United States as a slaveholding nation. Of course what they had in mind closely linked whiteness with immigration and citizenship. What else would you think they had in mind?

I hope it should go without saying that this is not any kind of argument in favor of racially discriminatory immigration politics, or whites-only naturalization laws, or the desire to whiten or re-whiten the American citizenry. The fact that the United States has a long tradition — going back to the Founders themselves — of racially discriminatory immigration and citizenship laws isn’t any reason to think kindly of the traditional, white supremacist approach. It’s a reason to think worse of the United States government, to be much more skeptical of traditional American patriotism and veneration or invocation of our Founders, and to put a lot less political weight on what our founders had in mind. Those fellows had some good ideas. They also had some really awful ideas. When it comes to questions of race, or to questions about whiteness and immigration specifically, the bad ideas were pretty prominent. Whatever deeper values Nancy Pelosi might find implicit in the best versions of the Founders’ very best intentions — and however much she might think or hope that the old racial prerequisite law was an aberration or an inconsistency — there is just no way that you can reasonably pretend that Make America White Again is something different from what they had in mind when they came together in Congress assembled and wrote laws like the Naturalization Act of 1790. Trump’s race-baiting immigration politics are certainly disgraceful. But then, so were theirs. You shouldn’t try to make your political points against the one with this kind of whitewashing of the other, or by substituting this sort of aspirational liberal self-identity in place of the much messier historical fact.

See also.

  1. [1]In that it seems to be mostly motivated by a political agenda to gather information that would be useful for anti-immigrant politics and for concrete policies to politically disadvantage communities with large immigrant populations (for example, by encouraging Republican-dominated state governments to use the information for apportionment and redistricting of legislative seats). In the current political climate, the question would be intimidating or actually dangerous to immigrants who are asked to fill out Census forms — and especially to undocumented immigrants. The possibility of real danger is an outside chance, but not a wild speculation. It’s not necessarily a very auspicious sign when the United States government becomes really interested in finding and counting politically controversial populations. And that information was turned over, at least once in American history, to other branches of the government, who used it to find targeted people and imprison them. The Census Bureau says that there are legal protections in place that prevent them from turning over the information to other branches of the government. But there were supposed to be legal protections in place in 1940, too. The legal protections were repealed in the midst of the war crisis. Maybe the government won’t ever do it again. But there is not much reason to be very certain about that.
  2. [2]In 1870, in the wake of the Civil War and Emancipation, Congress began to add other categories of race, color and nationality to make other, non-white groups eligible for naturalization, beginning with aliens of African nativity and … persons of African descent in 1870. But for the next 80 years they continued to use the racial prerequisite as a means to exclude any non-white immigrants who didn’t fall into one of the favored groups. From 1870 to 1924, they allowed them to immigrate but excluded them from citizenship; after 1924, they excluded them from immigrating at all, as aliens ineligible to citizenship. Throughout those eight decades, a series of prerequisite cases in the federal courts — beginning with In Re Ah Yup — repeatedly affirmed that being white or non-white absolutely did matter to a person’s eligibility for American citizenship. The difficult issue that they litigated over and over again was the uncertain or porous legal and social boundaries of who counted as white, or at least as white enough for government work. For example, Chinese and Japanese immigrants did not; Mexican immigrants did. For many immigrant groups, including Arabs and South Asians, different courts made numerous, sometimes inconsistent rulings. A good, standard reference on this series of cases is Ian F. Haney-Lopez’s White By Law: The Legal Construction of Race.
  3. [3]A standard historical shit’s complicated caveat: the Naturalization Act of 1790, and all the later amended acts that kept the free white person formula intact, were laws that governed naturalization, that is, citizenship; they were not — at the time — laws that restricted immigration. Until 1875, the U.S. had no federal laws that restricted free immigration to the United States or prevented aliens from residing in the country. Until 1924, the U.S. had no laws preventing aliens ineligible to citizenship from immigrating to or living in the country. So in the Founders’ day, there were plenty of non-white immigrants who could legally move to and live in the U.S., but who could never become U.S. citizens. That said, there’s percious little evidence that any of the Founders thought it was particularly desirable for lots of free but non-white immigrants to come to the U.S. It’s just that the use of large-scale, systematic immigration controls as a means of excluding supposedly undesirable immigrants are really the product of much later generations, and of a much more expansive and centralized national government.

July 10 2019

17:00
Announcing Docsy: A Website Theme for Technical Documentation

July 09 2019

16:30
Come Meet the Google Open Source Team at OSCON!

July 08 2019

17:00
Truth 1.0: Fluent Assertions for Java and Android Tests

July 02 2019

22:32

Easier Payments with Chrome

People have high expectations for their shopping experience on the web — whether booking a vacation, or buying tickets to a hot concert before they’re gone. They want a fast, seamless, and safe experience that works across all their devices.

That’s why today we are making payments in Chrome more convenient: When you’re signed into Chrome on your laptop, you’ll be able to use payment methods previously saved to your Google Account to fill in checkout forms. And you can use this feature without having to turn on Chrome sync. You'll also be able to use the payment info you’ve saved in your Google Account across your devices in Chrome where you’re signed in, and wherever Google Pay is accepted.


You are always in control: When you’re signed-in and Chrome offers you the option of using a card from your Google Account, it will ask you to confirm the card’s CVC. If you choose to save a new card to your account, you will receive a confirmation email from Google Pay with additional information. You can manage and delete the cards in your account at anytime by going to your Google Account > Payments & subscriptions > Payment methods.




Using this new feature doesn’t turn on Chrome sync. And of course, if you prefer to save your payment methods only locally on your device, you can still do that: Add your card in Chrome Settings  > Payment methods > Add. When you sign into any Google website, you’re also signed into Chrome with the same account. You can turn off "Allow Chrome sign-in" altogether in settings. 

Every time you open your browser, you have a task in mind to accomplish. We’ve built Chrome to help you do that as quickly and safely as possible, whether you are completing a search, viewing a website, or making a purchase. This feature is just one more way we are improving this experience for everyone.


Posted by Sabine Borsay, Chrome Product Manager



July 01 2019

14:00
Google's robots.txt Parser is Now Open Source

June 28 2019

16:24

No Decency

Donald John Trump, 45th and current president of the United States of America, Wednesday, June 26, 2019, speaking to the press:

Q. Does the photo of the drowned immigrants[1] cause you to rethink any of your policies?

[Donald John Trump]: Well, that’s like I’ve been saying. If they fixed the laws, you wouldn’t have that. People are coming up; they’re running through the Rio Grande. It’s a rough — it can be a very rough river of sorts. I mean, there are times when going across the Rio Grande is very, very dangerous, depending on the time of year and the conditions and the rapidity of the water. And we know that.

And we have many, many guards there, but people go through the guards. If we had the right laws that the Democrats are not letting us have, those people, they wouldn’t be coming up. They wouldn’t be trying.

We’re building the wall. It’s under construction. It’s — a lot of it is under construction. We’ll have over 400 miles next year, by the end of the year.

But it’s very important. They can change it very easily so people don’t come up. And people won’t get killed. Women are being raped on the journey up. You have these caravans. Women are being raped. And one of the terrible things: Children are actually being brought into slavedom [sic]. If you look at what’s happening — the cartels and the coyotes, they’re getting rich because the Democrats refuse to change the loopholes. They refuse to change the asylum. In one hour, we could have it done.

They want to have open borders, and open borders mean crime. And open borders mean people drowning in the rivers. And it’s a very dangerous thing.

— Remarks by President Trump Before Marine One Departure (2019/06/26, 1:30 PM)

On the face of it, this is one of the most lunatic statements, one of the most wildly inhuman political responses, and one the most obscene instances of talking with a corpse in your mouth that I have seen to date from a man and a governmental administration that have spent their time in the White House doing little other than cranking a built-to-purpose outrageous political palaver garbage machine generator.

Perhaps it does not need saying that open borders mean precisely that no little girl ever dies drowning in a river again. Because open borders mean that people could and obviously would cross over rivers openly, on bridges or ferries, in cars or boats or machines flying safely through the air. Open borders means breezing past long-abandoned checkpoints without fear of criminalization, arrest, internment or deportation. Blaming the deaths of Óscar Alberto Martínez Ramírez, and his daughter Valeria, on open borders is like blaming the Tiananmen Square Massacre on freedom of assembly — it is insane, because if you had the latter there wouldn’t be any particular reason for the former; and it is obscene, because it is blaming the victim for a situation that is entirely and only created by Power’s choice to keep on relentlessly pursuing repressive force. Open borders mean safe and open crossings; they don’t mean drowning, any more than an open swimming pool does.

Perhaps it does not need saying that it is precisely the relentless, maniacal insistence on walling off frontiers and choking off border-crossing that sends families out into the most dangerous, most inaccessible places in order to try with cartels, coyotes, smugglers and the roughest passages that remain. The great crime and the great shame of the Democratic Party is that they have never once called for open borders, and when in control of the presidency they have — over and over again — played the leading role in building up the machinery of overregulated immigration, paramilitary border policing, closed crossings and mass deportation that we unhappily live with — or die at the hands of — today. Democrats don’t want to have open borders. I desperately wish they did. I desperately wish they ever had done even one little thing to move in that direction. But they haven’t, and they don’t, and they probably never will. So much the shame of Democrats.

Bordercrats know this, of course — they know that if borders actually were open, then people would cross safely, openly and frequently. They know that if borders actually were open, Óscar Alberto Martínez Ramírez, Tania Vanessa Ávalos, and their daughter Valeria would be safe in Texas today, starting out in a new town and looking for work. It is precisely for that reason that they politically oppose open borders — because they don’t want that many people crossing the border, or they don’t want those specific people crossing the border, or they don’t want some of the people who would cross the border, if the Ramirezes could cross the border, to cross it. That’s precisely what it means to close or control the border; there is no third alternative. You might openly embrace the misery, suffering and death that results. Or you might acknowledge it, regretfully, as the necessary human cost of your political policy, and of its rigorous enforcement. Perhaps there is a sense in which the desire to shift the blame instead of doing either represents a certain sort of vestigial, suffering sense of decency that even Mr. Trump, at long last, still has left. Perhaps there is a sense. But if so, it doesn’t matter very much.

See also.

  1. [1]Their names were Óscar Alberto Martínez Ramírez, and his daughter Valeria. They came from El Salvador. He was 25. She was a little girl, only 1 year, 11 months old. She died trying to reach her father again. He died trying to save his daughter’s life. They are survived by Tania Vanessa Ávalos, Óscar’s wife and the little girl’s mother.
Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl