2276 points 5 days ago by kristoff_it in 1740th position
2276 points 5 days ago by kristoff_it in 1740th position
2227 points 4 days ago by joeyespo in 66th position
While the senators championing the bill, which they've named the Eliminating Abusive and Rampant Neglect of Interactive Technologies Act (EARN IT Act), may have good intentions, they are seriously misguided about the impact of their proposal.
Encryption ensures our information, from our sensitive financial and medical details to emails and text messages, is protected. But the EARN IT Act will create a broad path for government actors to seriously undermine strong encryption, putting our information at risk. That's why Mozilla is joining dozens of other internet health and civil society organizations in calling on the U.S. Congress to vote no on the EARN IT Act.
1482 points 6 days ago by samdung in 1543rd position
The Indian government on Monday evening said it was banning 59 apps developed by Chinese firms over concerns that these apps were engaging in activities that threatened "national security and defence of India, which ultimately impinges upon the sovereignty and integrity of India" in what is the latest standoff between the world's two most populated nations.
Among the apps that India's Ministry of Electronics and IT has ordered to ban include ByteDance's TikTok, which counts India as its biggest overseas market; Community and Video Call apps from Xiaomi, which is the top smartphone vendor in India; two of Alibaba Group's apps (UC Browser and UC News); Shareit; CM Browser, Club Factory, which claims to be India's third-largest e-commerce firm; and ES File Explorer.
This is the first time that India, the world's second largest internet market with nearly half of its 1.3 billion population online, has ordered to ban so many foreign apps. New Delhi said nation's Computer Emergency Response Team had received many "representations from citizens regarding security of data and breach of privacy impacting upon public order issues."
"The compilation of these data, its mining and profiling by elements hostile to national security and defence of India," it said.
The apps India is banning
Tarun Pathak, an analyst at research firm Counterpoint, said the order would impact roughly one in three smartphone users in India. TikTok, Club Factory and UC Browser and other apps put together had more than 500 million monthly active users in May, according to one of the top mobile insight firms.
And, 27 of these 59 apps were among the top 1,000 Android apps in India last month, according to the mobile insights firm — data of which an industry executive shared with TechCrunch.
It's unclear what exactly the "ban" means and how mobile operating system makers and internet service providers are expected to comply. At the time of writing, all of the aforementioned apps were available to download from Google Play Store and Apple's App Store in India.
New Delhi said it had received "many complaints from various sources, including several reports about misuse of some mobile apps available on Android and iOS platforms for stealing and surreptitiously transmitting users' data in an unauthorized manner to servers which have locations outside India."
Monday evening's announcement is the latest standoff between the two neighboring nations following a deadly clash at the border earlier this month that stoked historical tensions. In recent weeks, custom officials at major Indian ports and airports have halted clearances of industrial consignments coming from China.
Jayanth Kolla, an analyst at research firm Convergence Catalyst, told TechCrunch the move was surprising and will have huge impact on Chinese firms, many of which count India as their biggest market. He said banning these apps would also hurt the livelihood of several Indians who directly or indirectly work for them.
Anti-China sentiment has been gaining mindshare in India in recent weeks, since more than 20 Indian soldiers were killed in a military clash in the Himalayas earlier this month. "Boycott China" — and variations of it — has been trending on Twitter in India ever since as a growing number of people posted videos demonstrating destruction of Chinese-made smartphones, TVs and other products.
Chinese smartphone makers command more than 80% of the smartphone market in India, which is the world's second largest. For SoftBank-backed TikTok, which has more than 200 million monthly active users in India, New Delhi's move is its latest headache. The Chinese firm has also faced scrutiny in Europe and the United States in recent quarters.
TikTok has been facing backlash in India since the second half of May after users unearthed and shared numerous recent TikTok videos on Twitter that appeared to promote domestic violence, animal cruelty, racism, child abuse and objectification of women. Many in India rushed to leave a poor rating of the TikTok app in the Google Play Store to express their disgust — and the Android-maker had to intervene and delete millions of comments.
Days later, an app called "Remove China Apps" gained popularity among some Indians. Google pulled the app later from the Play Store citing it violated its guidelines. A TikTok spokesperson did not immediately respond to a request for comment.
In April, India amended its foreign direct investment policy to require all neighboring nations, including China, with which it shares a boundary to seek approval from New Delhi for their future investments in India. The nation's Department of Promotion of Industry and Internal Trade said it was taking this measure to "curb the opportunistic takeover" of Indian firms that are grappling with challenges due to the coronavirus crises.
When TikTok app was blocked in India for a week last year, ByteDance had said in a court filing that it was losing more than $500,000 a day in the nation. In a statement on Tuesday (local time), TikTok said that it was working to comply with New Delhi's order.
1107 points 2 days ago by rwoll in 4428th position
Take a look at the below screenshot from Safari for iOS. What website am I on?
Based on the contents of the page, I'm clearly on a NYTimes property, but based
on the address bar I'm clearly on
google.com. If I click in the address bar
https://www.google.com/amp/s/www.nytimes.com/2020/05/22/technology/google-antitrust.amp.html. Confused, I consult Google's Safebrowsing FAQ:
How can I tell if a page is a fake?
The best thing to do is to check the page's URL to make sure it's actually controlled by the party it appears to be controlled by. The crucial part of the URL is the part between the http:// and the next slash ('/'). (If there's no slash, start at the end of the URL.) This is the part of the URL that determines site ownership. Some popular domains, for instance, are amazon, google, and ebay:
In some cases, URLs will be a bit more complex; be sure to check the name listed immediately to the left of the top level domain (.com, .net, .co.uk, etc.). For instance,
http://www.google.com/firefox/are all part of the same site. However,
google.com.fraudulentdomain.com/login.htmlis NOT! Neither is
www.g00gle.com(note that in this URL, the letter o is replaced by the number 0).
and determine I'm on a
https://www.google.com—but the confusion remains since
this is genuinely NYTimes content and branding.
This is a really dangerous pattern: Google serves NYTimes' controlled content on a Google domain. It confuses the user whether to trust the address in URL bar or the content of the page. This confusion is precisely why phishing attempts work so well. Humans trust visual indicators a lot. Google, with the AMP Cache Project, is confusing humans more and training them to trust visual content of the page over the URL in the address bar—despite telling them to do otherwise on different sites. This surprises me since Google spends a lot of time researching visual indicators of security in the address bar (like the padlock icon). In work security trainings and guides on the Internet, we are trained to look at the URL bar to help make a decision on whether to trust a site, but the Google AMP Cache requires contradictory assumptions.
Comments on the post can be viewed here: https://news.ycombinator.com/item?id=23729160.
1099 points 6 days ago by CM30 in 2264th position
In the last few years, you've likely seen a fair few comments about monopolies in the tech industry, and suggestions for breaking them up. These comments usually revolve around the big FAANG companies (or at least, Google, Amazon and Facebook) and suggest the power they hold is unhealthy for society.
And they're right. It is unhealthy, and definitely acts as a good reason to break up said companies.
But they're not the only ones that need it, nor the most important cases. No, there are two others that are far more dangerous to the internet, businesses and society right now.
Namely, the payment processing companies, like Visa and MasterCard. These companies handle billions of credit card transactions a day, and have a level of power the likes of Google can only dream of.
Like almost complete control over what can be sold online. Ever wonder why certain things are difficult to buy via PayPal or other similar systems? Why Patreon ban certain types of creators really easily? Why adult sites find it so tough to process card payments?
Because these guys set the rules, and those rules ban a lot of content that's either offensive or brings high risk of fraud. It's why adult sites usually keep switching payment processors, or running ads from less than savoury networks.
So you've got a huge part of the monetary system controlled by parties with zero interest in neutrality, and power beyond government control.
What's more, abuse of this power has already happened. Back in 2010, Visa cut off access to WikiLeaks, rendering the site unable to receive donations as a result. This was fortunately then overturned (by a Dutch court order no less), but it's a scary precedent regardless, and shows just how easily 'undesirable' media outlets and creators can be deprived of their income by companies like this one.
And that's not the only issue they bring either. No, their control over the system means outages are very serious indeed.
Just think back to the UK in June 2018, when Visa went down across the country. That caused a huge incident that took thousands of businesses and millions of credit cards offline.
Which in turn likely caused billions of dollars in economic losses, all due to a simple network accident. One small issue, whole economies on the verge of collapse.
And it could potentially have been even worse. Had their few competitors also gone down, literally all electronic payments would have broken at once. Had it been a worldwide issue, and basically the entire world economy would be unusable for hours or days.
This in turn also means it's a perfect target for malicious enemy forces. Theoretically like Iran, North Korea, etc. All of whom have a vested interest in their rivals losing some of their technological advantages over them.
So there's a potential cybersecurity disaster waiting to happen there.
Though it's not as if our governments likely aren't using these companies and systems for questionable purposes as is. They're a perfect way to target and cripple regimes we don't like at this point in time, and would almost certainly be cut off in the case of a war or major conflict.
Hence neither group really has reason to trust them. They're dangerous for our own societies, dangerous for our opponents and a huge security risk regardless of the situation, plus a force for censoring people who've done nothing other than annoyed the 'wrong' people overall.
But surprisingly, they're not worth breaking up.
And I know what you'll say. That I made a perfectly good argument for doing just that. That with all those downsides, breaking up Visa and MasterCard (and perhaps some competitors) is the best way forward.
However, here's the thing. It's not true.
Since at the end of the day, the problem isn't just that these companies are too big, it's that their industry has been left entirely privatised at all.
Cause payment processing for individuals and businesses isn't a competitive market. It's not some 'optional' product the world can exist without.
It's a crucial part of a large chunk of the world's businesses. It's crucial for the internet to function, and its absence makes it incredibly difficult to live in a modern society.
Hence the solution isn't just more competition. It's to regulate the whole industry as utilities, or even turn it into neutral, global infrastructure.
This would mean that in the same way everyone has access to water, electricity, or public transport, everyone has access to payment processing, regardless of their nationality, gender, ethnicity, sexual orientation, political views, wealth or anything else. Reactions to people asking to cut people off from receiving money should be treated like an attempt to say, remove a police station's access to water or electricity; called absurd and ignored.
It's time we called it a day for the large payment processing companies, and regulated their entire market as utilities like people are expecting us to.
Otherwise, individuals, organisations and businesses alike will suffer their ridiculous rules and limitations.
Thanks for reading!
1069 points 6 days ago by dirtae in 2322nd position
Starting June 30th, Apple will be enforcing a new rule in the App Store requiring many apps to support Sign in with Apple. AnyList is one of the apps affected by this new rule, which means that we must either implement Sign in with Apple or make other changes to our app. After considering the merits of Sign in with Apple, we have decided not to support it. We understand that this may surprise some of our customers, so we'd like to explain in detail why we made this decision.
Third-party login systems like Sign in with Apple cause many user experience and customer support headaches. People don't remember which login system they used to create their account. ("Hmm, I created this account a couple of years ago. Did I use my email address? Facebook account? Sign in with Apple?") Simple questions like, "How do I reset my password?" no longer have simple answers and depend on which system you used to create your account, if you can remember. And if you get locked out of your account and used a third-party login system, we may not be able to help you ourselves and will instead have to direct you to another company, with all of the hassles that entails.
In addition to these customer experience problems that are common to all third-party login systems, Sign in with Apple introduces several more that are unique to it.
One problem is that most Apple IDs are tied to an iCloud email address. So most accounts created via Sign in with Apple will use an iCloud email address. But many of those iCloud email addresses are unused and unchecked, because a customer's "real" email account is their Gmail, Yahoo, or Hotmail account. If we try to contact a customer using their iCloud email address, they may never see our message. We used to run into this problem constantly with customer support, back when AnyList used the built-in iOS email compose interface for sending support requests. This interface often defaults to using an iCloud email account. So people would ask for help, we'd reply, and they'd contact us again later, angry that we never replied. Our reply was going to their iCloud email account, but they didn't see it because they only ever looked at their Gmail account, in the Gmail app.
Another issue is Sign in with Apple's "Hide My Email" feature. With this feature, if you create an account with us, Apple will generate a special email address just for that account. So rather than your email address being [email protected], we will see your email address as something like [email protected]. While this is an intriguing idea that provides a measure of privacy, in practice it creates numerous support and user experience headaches. Here are a few:
If a customer contacts us asking for support, and we need to look up something in their account, typically we can just ask them for the email address on their account. But with "Hide My Email" that wouldn't be easily possible, because the customer would have to figure out the privaterelay.appleid.com email address used for their account.
Furthermore, if there are platforms where AnyList doesn't support Sign in with Apple, like Android, and someone wants to log into their account, they'd have to know their privaterelay.appleid.com email address. (And that certainly won't be easy to find if you no longer have an iOS device.) And then they'd have to create a password with us, since they wouldn't be able to sign in using Sign in with Apple.
Finally, for a service like AnyList, which is heavily focused on sharing lists with other people, the "Hide My Email" option greatly complicates collaboration. Typically, customers share a list by typing in the email address of the person they want to share with. If that person already has an account, the list is instantly shared. But with the "Hide My Email" option, your spouse or friends obviously won't know your privaterelay.appleid.com email address, so when they enter your email address, our systems will believe that you don't have an account. At that point, you'll get an email from us asking you to create an account. If you accidentally create a new account, it won't include the work you've done in your existing account created via Sign in with Apple. And if you manage not to make that mistake, then there would be a link between your email address and the account you created with Sign in with Apple, negating the value of hiding your email address.
We agree with Apple that privacy is a fundamental human right, and understand that the "Hide My Email" option in Sign in with Apple is well-intentioned, but it feels like Apple didn't really think through all of the implications for basic user experience, customer support, and collaboration. At AnyList, we respect your privacy. We're a small company that makes money when people like our app and pay for it. We do not make money with creepy tracking or by selling your information. When you provide us with your email address, it is never sold, shared, or used to invade your privacy.
Beyond customer experience, there are also many problems that Sign in with Apple creates for us as developers, which has knock-on effects for our customers.
First, implementing support for third-party login systems like Sign in with Apple significantly increases the complexity of handling user accounts in our systems. Instead of having one system for common operations like creating an account and signing in, supporting third-party login systems can quickly turn account management code into a rat's nest, with special logic necessary to handle each different login system. This is especially true when supporting multiple third-party login systems (e.g., Facebook Login, Google Sign-In, Sign in with Twitter, etc.). This makes maintenance more difficult and error-prone, and if there's any place where you cannot afford to have any errors, it's in security-critical code like account management.
It's also time consuming to implement support for a new third-party login system, particularly for a small company like ours that supports our app on multiple platforms. It's not enough for us to add Sign in with Apple to our iOS app. We also have to add it to our web app, Mac app, and Android app. (Creating even more complexity, Apple does not provide any real solution for supporting Sign in with Apple on Android, see below.) So if we choose to support Sign in with Apple, that means that we have to spend a significant amount of time to get it working everywhere, rather than spending that time improving the core list, recipe, and meal planning functionality of our app.
As developers, we always have to do our due-diligence in evaluating the security implications of our work. In the last month a massive security flaw was reported in Sign in with Apple, so serious that Apple paid $100,000 to the person who found it. If you read the linked report, you'll see that this serious flaw was also very simple, which doesn't provide a lot of confidence. For something as critical as a service for logging into accounts, it doesn't seem wise to use an immature service (less than a year old) that has recently been the subject of a serious security flaw.
Another sign of Sign in with Apple's immaturity is the sad state of the documentation for it. Good documentation is critical to facilitating developer adoption of any service. Since Apple is expecting developers to adopt this service by June 30th, it seems reasonable to expect decent documentation. Sadly, like most of Apple's recent developer documentation, it's sorely lacking. For example, Apple vaguely states that you can implement Sign in with Apple on Android, but there is no direct documentation on how to do it. We understand that Apple probably doesn't care much for Android, but if they are going to provide a login system, and are going to force developers of multi-platform apps to adopt it, then providing no real support for a major platform that these multi-platform apps run on is not acceptable.
Finally, from a policy perspective, Apple explicitly states in their usage guidelines, "Apple reserves the right to disable Sign in with Apple on a website or app for any reason at any time." If customers cannot log into their accounts, then they can't use our service. Giving a third-party such powerful control over a core part of our service when it's not absolutely required is unnecessarily risky, in our view.
At this juncture, you may be thinking:
These are both excellent points, and it's absolutely true that some of the arguments above apply to creating an account via Facebook. That's why we're also announcing that we'll be removing Facebook Login from AnyList. Our support for signing up using Facebook was begrudgingly added years ago as an experiment in offering another signup option, but we were never enthusiastic about it. That's become even more true as time goes on, since Facebook constantly seems to be upping the ante with creepy privacy practices. We use the Facebook SDK to provide login functionality, and every new release of the SDK seems to add new tracking options that are turned on by default, which we have to take action to disable. Furthermore, the Facebook SDK has quality problems, and recently caused a huge number of iOS apps to crash due to a misconfigured server. You can expect to see an AnyList app update soon that removes Facebook Login.
We hope this post has helped to explain why we won't be supporting Sign in with Apple. We'd love to hear your feedback on this post. If you have any comments or questions, please contact us and we'll get back to you.
Want to be informed when a new post is available? Sign up to be notified via email. Infrequent updates, no spam:
820 points 4 days ago by commotionfever in 3652nd position
First of all - I am a big fan of DDG
This is why I will now explain, (again) what the problem with your answer is and what it indicates.
Hi all, CTO of DuckDuckGo here. I thought it might be helpful if I briefly shared some of our internal thinking around this issue so folks can see how we got here and how we plan to move forward.
Your 'internal thinking' is what has raised this issue in public! It is basically the bare reason for our concerns! Because it shows, that you do not even understand our privacy argument! It is not about the bug, it is your action and the, like @calimeroteknik puts it, 'curios wording', that makes it appear, like you have not understood our critic at all.
Time of Events
Bugs can happen! Bad decisions can happen! But arguing with 'trust us, it anonymous', it 'saves user badwidth', and its 'the only visible attribute', on top of that 'we already have a anonymous [...] service'! It is pure poison for trust, because it indicates, you entirely missed the point! Either on purpose or not. Both would be alarming!
The logic behind how we've been displaying favicons in our apps is a function of how we operate our private search engine. Since we already have an anonymous favicon service through our search engine, using it has a number of benefits: it avoids more requests to known non-anonymous websites that are visited, it's way faster since it runs server side, saves user bandwidth, and the only externally visible attribute is that the app is connecting to DuckDuckGo.com (as the favicon location is actually encrypted in the path in transit). To our team, utilizing this anonymous service we had made for the search engine seemed like an optimal principled choice across a set of criteria.
Its not that we do not understand your reasoning or the reasoning of @tagawa. The problem is your reasoning, seems to entirely miss our point!
Now you continue - as CTO! This indicates no real insight at all!
We want to be clear that at no point was the actual visited domain otherwise exposed. This favicon service is fully anonymous on our end, and URL parameters (like the favicon domain) are encrypted in transit, just like the search engine (with search queries). This is also why when this issue was raised in the past, we decided to keep the solution as is. At no point was this ignored.
We said, please do not mix the search engine code and your browser code! They should not relate on each other if not necessary (for example if the user actually wants to do a search on DDG). Arguing 'we already have a anonymous [...] service' is very hard to understand from a technical point of view. It might make sense for a CFO, but not for nerds or hackers!
However, we understand that there is an alternative method of getting the favicons locally that a lot of folks prefer while still maintaining our privacy standards. We also believe that method is in line with our product vision of 'Privacy, simplified.', considering its a somewhat simpler method than the one we had been using.
Like @calimeroteknik already said: Luckily higher security standards meet your standard! -_-
So, we went ahead today and implemented the change for both Android (#878) and iOS (duckduckgo/iOS#667) that will move this logic onto the client, and we will no longer be using the favicon service in our apps. These changes are currently in the release phase and are rolling out live now.
You only took this action after enormous public pressure, there was no sign of insight or internal intention to resolve this! This is why you have been compared with BigCorp, because they act like this. (Or like pointed out by some people, are even doing a better job than you, handling these kinds of issues)
[LARP MODE ON] [Loading Game Data...] You currently have (3) quests! [(1) Closed Quest] Even under enormous public pressure, do not remove the criticized code, before at least one year has past! [(1) Open Quest] Understand the whole point, and communicate it in a acceptable way. [(1) Bonus Quest] Build trust back by transparent actions in the future, which reflect that you understood what we said [LARP MODE OFF]
We really appreciate the feedback and exchange of ideas on this topic, and on ways to further improve the privacy of our products in general.
You are welcome! I hope this helps!
794 points 6 days ago by catacombs in 1485th position
(Clockwise from top left) Stevan Molinar, left, with two squad leaders in 2016; Frank Scafidi prepares for a mission in Vietnam; Lt. Col. Harry Lesher pins a First Lieutenant bar on Tom Knutsen in 1971; Victoria Chamberlin at the NCO academy in South Korea in 2014. (Courtesy of Stevan Molinar, Frank Scafidi, Tom Knutsen, Victoria Chamberlin)
Many said they were moved to tears reading about the experiences of 1st Platoon. Others questioned how the soldiers could blindly follow orders to shoot at civilians.
793 points 3 days ago by infodocket in 312th position
It is my honor to introduce Abstract Wikipedia, a new project that has been unanimously approved by the Wikimedia Foundation Board of Trustees. Abstract Wikipedia proposes a new way to generate baseline encyclopedic content in a multilingual fashion, allowing more contributors and more readers to share more knowledge in more languages. It is an approach that aims to make cross-lingual cooperation easier on our projects, increase the sustainability of our movement through expanding access to participation, improve the user experience for readers of all languages, and innovate in free knowledge by connecting some of the strengths of our movement to create something new.
This is our first new project in over seven years. Abstract Wikipedia was submitted as a project proposal by Denny Vrandečić in May of 2020  after years of preparation and research, leading to a detailed plan and lively discussions in the Wikimedia communities. We know that the energy and the creativity of the community often runs up against language barriers, and information that is available in one language may not make it to other language Wikipedias. Abstract Wikipedia intends to look and feel like a Wikipedia, but build on the powerful, language-independent conceptual models of Wikidata, with the goal of letting volunteers create and maintain Wikipedia articles across our polyglot Wikimedia world.
The project will allow volunteers to assemble the fundamentals of an article using words and entities from Wikidata. Because Wikidata uses conceptual models that are meant to be universal across languages, it should be possible to use and extend these building blocks of knowledge to create models for articles that also have universal value. Using code, volunteers will be able to translate these abstract "articles" into their own languages. If successful, this could eventually allow everyone to read about any topic in Wikidata in their own language.
As you can imagine, this work will require a lot of software development, and a lot of cooperation among Wikimedians. In order to make this effort possible, Denny will join the Foundation as a staff member in July and lead this initiative. You may know Denny as the creator of Wikidata, a long-time community member, a former staff member at Wikimedia Deutschland, and a former Trustee at the Wikimedia Foundation . We are very excited that Denny will bring his skills and expertise to work on this project alongside the Foundation's product, technology, and community liaison teams.
It is important to acknowledge that this is an experimental project, and that every Wikipedia community has different needs. This project may offer some communities great advantages. Other communities may engage less. Every language Wikipedia community will be free to choose and moderate whether or how they would use content from this project.
We are excited that this new wiki-project has the possibility to advance knowledge equity through increased access to knowledge. It also invites us to consider and engage with critical questions about how and by whom knowledge is constructed. We look forward to working in cooperation with the communities to think through these important questions.
There is much to do as we begin designing a plan for Abstract Wikipedia in close collaboration with our communities. I encourage you to get involved by going to the project page and joining the new mailing list . We recognize that Abstract Wikipedia is ambitious, but we also recognize its potential. We invite you all to join us on a new, unexplored path.
Katherine Maher (Executive Director, Wikimedia Foundation)
661 points 2 days ago by DerWOK in 3796th position
In modern times, getting a hold of the flood of information is almost as hard as inserting a USB drive the right way on the first attempt. Zettlr allows you to connect pieces of information using state of the art Zettelkasten methodology. Links? Check. File IDs? Check. File tagging? Also check.
And the best is: Unlike many competitors, Zettlr never locks you in. Zettlr supports almost every conceivable way to create links and identify your files. In other words: No matter where you come from — all Zettelkästen are beautiful and supported by Zettlr. Out of the box.See what's possible
599 points 5 days ago by toomuchtodo in 1035th position
In March and faced with the chaos caused by the coronavirus pandemic, the Internet Archive (IA) launched its National Emergency Library (NEL)
Built on its existing Open Library, the NEL provided users with unlimited borrowing of more than a million books, something which the IA hoped would help "displaced learners" restricted by quarantine measures.
After making a lot of noise in opposition to both the Open and Emergency libraries, publishers Hachette, HarperCollins, John Wiley and Penguin Random House filed a massive copyright infringement lawsuit against the Internet Archive.
Declaring the libraries little more than 'pirate' services that have no right to scan books and lend them out, even in a controlled fashion, the publishers bemoaned the direct threat to their businesses and demanded millions of dollars in statutory damages.
Earlier this month the IA announced the early closure of the NEL, with IA founder Brewster Kahle calling for an end to litigation and the start of cooperation. There are no public signs of either. Indeed, the opposing sides are preparing for action.
Last evening the EFF announced that it is joining forces with California-based law firm Durie Tangri to defend the Internet Archive against a lawsuit which they say is a threat to IA's Controlled Digital Lending (CDL) program.
The CDL program allows people to check out scanned copies of books for which the IA and its partners can produce physically-owned copies. The publishers clearly have a major problem with the system but according to IA and EFF, the service is no different from that offered by other libraries.
"EFF is proud to stand with the Archive and protect this important public service," says EFF Legal Director Corynne McSherry.
"Controlled digital lending helps get books to teachers, children and the general public at a time when that is more needed and more difficult than ever. It is no threat to any publisher's bottom line."
Durie Tangri partner Joe Gratz agrees, noting that there is no issue with the Internet Archive lending books to one patron at a time.
"That's what libraries have done for centuries, and we're proud to represent Internet Archive in standing up for the rights of libraries in the digital age," he adds.
With Gratz on the team, the IA and EFF are clearly taking matters seriously. His profile states that he's as "comfortable on his feet in court as he is hashing over source code with a group of engineers", adding that he represented Google in the Google Book Search copyright cases.
Also on the team, according to the lawsuit docket, is Harvard Law School graduate Adi Kamdar, who was an affiliate with the Berkman Klein Center for Internet & Society. Before that, Kamdar was an EFF activist advocating on issues of privacy, speech, and intellectual property policy.
The docket reveals some prominent veterans acting for the publishers too.
Matthew Jan Oppenheim, for example, served as lead counsel in the record-breaking $1 billion jury verdict against Cox Communications for the music industry, and the $34 million verdict against Book Dog Books for the publishing industry.
A former partner at the music industry law firm Jenner & Block, Oppenheim previously worked at the RIAA, handling landmark cases against Napster and Grokster.
Meredith Santana represented Miley Cyrus in the "We Can't Stop' copyright infringement lawsuit while Linda Steinman represents and counsels content providers on how to protect their work from "challenges ranging from aggregators to ad blockers."
It's still not too late for the parties to reach a negotiated settlement but given the legal forces now massing on both sides, that is becoming a more distant prospect.
The stakes are high for all parties and beyond, with either side coming out on top having the potential to affect how the public can consume scanned and borrowed content in the future.
596 points 4 days ago by captn3m0 in 1260th position
Created on 1.7.20
Here's my little article about (almost) everything I know about Apple Lightning and related technologies: Tristar, Hydra, HiFive, SDQ, IDBUS and etc. But first a tiny warning...
Read this article on your own risk! The information in this artcile is based on a lot of AppleInternal materials (leaked datasheets, schematics, source codes) I read in a diagonal direction. And of course on my own research too. I have to warn you, the reader, that I have never done such a research before. Thus, this write-up might use incorrect or just weird terms and turn out partially or completely wrong!
Before going deeper, let's briefly sort out the terms:
You can see the female port pinout on the picture above and the connector pinout on the picture below: Please pay attention to the fact that in the connector, pins on both sides of connector aren't wired in exact same order. Thus, a host device have to detect orientation of a cable before doing anything else
Though it's not always applicable. Many Lightning accessories I've played with have mirrored pinouts in their connectors
So, IDBUS - is a digital protocol used for negotiations between Tristar and HiFive. Very similar to Onewire protocol
First connect logic analyzer's channels to both ID lines of the breakout (pins 4 and 8) and connect the breakout to the device, but do not connect the accessory just yet: Right after that start sampling (any rate from 2 MHz and up should be fine). You'll see something like this: As you can see, Tristar polls each ID line by rotation - one after another. But since we didn't connect any accessory, the polling obviously fails. At some point the device will grow tired of this endless stream of failures and stop it. Meanwhile let's examine what exactly happens while polling: First, we can see a long interval (~1.1 milliseconds) when the level is just high and nothing else is happening: Apparently that time is used to charge internal HiFive's capacitor - the energy from it will be then used to power-up its internal logic chips
What happens next is far more interesting: Obviously, that's some data flowing. But how to interpret it? How to decode it? Let's virtually split it to almost the least least significant parts - to something that I call words: So basically a word is a combination of fall-rise-fall:
|ZERO with STOP*||6||7||8||16|
|ONE with STOP*||1||1.7||2.5||21|
Using the above table we can now build a simple decoder of the protocol: As you can see, the first word a host sends is BREAK - when Tristar wants to send a new request, it always starts with it. Then comes a data stage. Please pay attention to the fact that last (8th) bit of a byte has longer Recovery Stage. When a data stage is over, a host sends another BREAK. Then a slave must send a reply (after at least a 2.5 us delay - see the table). Tristar will wait for around 2.2 ms for a reply. If it's not issued in this time interval, Tristar will try to poll another ID line
Now let's examine the data stage on the example above - 0x74 0x00 0x02 0x1f:
Not too much is known about how response 0x75's data is encoded. But some bits were available in a certain old Tristar datasheet:
Now let's sniff something more interesting:
|Accessory||ID (HOSTID = 1)|
|DCSD||20 00 00 00 00 00|
|KongSWD (no Astris running)||20 02 00 00 00 00|
|KongSWD (with Astris running)||A0 00 00 00 00 00|
|KanziSWD (no Astris running)||20 0E 00 00 00 00|
|KanziSWD (with Astris running)||A0 0C 00 00 00 00|
|Haywire (HDMI)||0B F0 00 00 00 00|
|UART Charge||20 00 10 00 00 00|
|Lightning to 3.5 mm/EarPods with Lightning||04 F1 00 00 00 00|
Tip #2: you can easily get cable's pin configuration with diags:
tristar -pPlease note that this command is only available on iOS 7+ diags
Tip #3: you can easily track 0x74/0x75 requests/responses generated by SWD-probes by setting debug env var to 3:
astrisctl setenv debug 3Then, on cable's virtual COM you'll see something like this:
But what if we want to launch Astris after a probe was already connected to a device? What will a cable do? How will it switch ACC lines to SWD? That's where WAKE breaks into the game! HiFive (or a device that emulates it) can initiate WAKE and IDBUS enumeration process will start again - Tristar will send 0x74 request, Kong/Kanzi will reply with new ID, Tristar will acknowledge that and route ACC lines to internal SWD lines (SoC must have Development fusing or be demoted for SWD to actually work, of course)
When a Lightning cable is just lying somewhere connected to a charger/computer, but not connected to a device, HiFive limits current on the PWR to a really small value (around 10-15 mA according to my measurements). To enable full current, 0x74 request must be issued by Tristar and processed by HiFive. For SecureROM/iBoot that's enough, but when a kernel is booted additional steps are to be made:
In simple words, by sending this blob to ttrs.apple.com, you can get device's serial number. This mechanism is used by Apple Store/Apple Premium Reseller' staff to retrieve SN from dead devices (considering Tristar is still alive though): The things that are happening on IDBUS while retrieving ESN were already documented by @spbdimka:
You can check provisioning status using diags:
tristar --prov_stat...and retrieve ESN as well:
tristar --esnBy the way, diags generally has rich set of Tristar commands (available since iOS 7):
Not much is publicly known about the registers. A lot of information about register map itself can be obtained from the leaked iBoot source code (for THS7383 (appears to be backwards compatible with CBTL1608) and CBTL1610 only), but not much about what to write to them to achieve some interesting results
Another source of knowledge is diags' Tristar module (easily extractable over SWD while it's running). For example, I did manage to reverse algorithms of reading provisioning state and ESN. I then implemented these as an addition to my iBoot payload, Lina:
I tried to reverse ESN writing algorithm as well, but failed - the mechanism was too complex for my skills. The code snippets from Lina though are available here
543 points about 9 hours ago by mkchoi212 in 4403rd position
_I originally wrote the following for my Chainline Newsletter, but I continue to get tweets about this idea, so I'm re-publishing the article here on my blog. This version has been lightly edited._
duplication is far cheaper than the wrong abstraction
And in the summary, I went on to advise:
prefer duplication over the wrong abstraction
This small section of a much bigger talk invoked a surprisingly strong reaction. A few folks suggested that I had lost my mind, but many more expressed sentiments along the lines of:
The strength of the reaction made me realize just how widespread and intractable the 'wrong abstraction' problem is. I started asking questions and came to see the following pattern:
Programmer A sees duplication.
Programmer A extracts duplication and gives it a name.
This creates a new abstraction. It could be a new method, or perhaps even a new class.
Programmer A replaces the duplication with the new abstraction.
Ah, the code is perfect. Programmer A trots happily away.
A new requirement appears for which the current abstraction is almost perfect.
Programmer B gets tasked to implement this requirement.
Programmer B feels honor-bound to retain the existing abstraction, but since isn't exactly the same for every case, they alter the code to take a parameter, and then add logic to conditionally do the right thing based on the value of that parameter.
What was once a universal abstraction now behaves differently for different cases.
Another new requirement arrives. Programmer X. Another additional parameter. Another new conditional. Loop until code becomes incomprehensible.
You appear in the story about here, and your life takes a dramatic turn for the worse.
Existing code exerts a powerful influence. Its very presence argues that it is both correct and necessary. We know that code represents effort expended, and we are very motivated to preserve the value of this effort. And, unfortunately, the sad truth is that the more complicated and incomprehensible the code, i.e. the deeper the investment in creating it, the more we feel pressure to retain it (the 'sunk cost fallacy'). It's as if our unconscious tell us 'Goodness, that's so confusing, it must have taken ages to get right. Surely it's really, really important. It would be a sin to let all that effort go to waste.'
When you appear in this story in step 8 above, this pressure may compel you to proceed forward, that is, to implement the new requirement by changing the existing code. Attempting to do so, however, is brutal. The code no longer represents a single, common abstraction, but has instead become a condition-laden procedure which interleaves a number of vaguely associated ideas. It is hard to understand and easy to break.
If you find yourself in this situation, resist being driven by sunk costs. When dealing with the wrong abstraction, the fastest way forward is back. Do the following:
This removes both the abstraction and the conditionals, and reduces each caller to only the code it needs. When you rewind decisions in this way, it's common to find that although each caller ostensibly invoked a shared abstraction, the code they were running was fairly unique. Once you completely remove the old abstraction you can start anew, re-isolating duplication and re-extracting abstractions.
I've seen problems where folks were trying valiantly to move forward with the wrong abstraction, but having very little success. Adding new features was incredibly hard, and each success further complicated the code, which made adding the next feature even harder. When they altered their point of view from 'I must preserve our investment in this code' to 'This code made sense for a while, but perhaps we've learned all we can from it,' and gave themselves permission to re-think their abstractions in light of current requirements, everything got easier. Once they inlined the code, the path forward became obvious, and adding new features become faster and easier.
The moral of this story? Don't get trapped by the sunk cost fallacy. If you find yourself passing parameters and adding conditional paths through shared code, the abstraction is incorrect. It may have been right to begin with, but that day has passed. Once an abstraction is proved wrong the best strategy is to re-introduce duplication and let it show you what's right. Although it occasionally makes sense to accumulate a few conditionals to gain insight into what's going on, you'll suffer less pain if you abandon the wrong abstraction sooner rather than later.
When the abstraction is wrong, the fastest way forward is back. This is not retreat, it's advance in a better direction. Do it. You'll improve your own life, and the lives of all who follow.
My next public Practical Object-Oriented Design course will be held in Durham, NC on May 2-4, 2018. Yup, it's time for another POODNC . This is your chance to spend three days with like-minded peers. Join us, and change how you think about objects.
99 Bottles of OOP is complete, and version 1.0.1 is now available. The book is co-authorized by Katrina Owen, and was years in the painful and painstaking making. Learn more about it, read an extended sample, peruse independent reviews, or buy it now.