Connect with us

Gadgets

Just one day after launch, Moto Razr durability problems begin to pile up

Published

on

So, just how durable is the new Moto Razr? Motorola’s nostalgic, folding-display flip phone has a number of unproven features that, after the public failure of the Galaxy Fold, every potential customer should be concerned about. Evidence is starting to pile up that the Razr might be another delicate foldable that isn’t up to the task of day-to-day smartphone usage.

In addition to the same display durability issues that the Galaxy Fold had—an OLED display that has to deal with both the stress of bending and an easily damageable plastic display coating—the Razr has a trick hinge system that is a lot more complicated than that of the Galaxy Fold. In an effort to keep the display from creasing deeply, Motorola says the Razr hinge “includes moveable support plates that rigidly support the display when the phone is open but collapse out of the way when the phone is closed.” There have been a few sources now that suggest this hinge design isn’t going to last.

The first piece of evidence comes from CNET, which just wrapped up a torture test of the Moto Razr with disappointing results. CNET got ahold of SquareTrade’s Foldbot, a robot designed to open and close folding smartphones repeatedly until they die. The Galaxy Fold survived the Foldbot for 120,000 folds before the fatigue from bending destroyed the display. CNET was hoping the Razr would last for a similar 100,000-fold torture test, but Moto’s phone only lasted for about a quarter of that time. After 27,000 folds, the hinge mechanism jammed up, and the phone wouldn’t close anymore.

After a few hours in the Foldbot, the Razr’s hinge became stiffer, and the smooth-closing action was significantly degraded. The video features a gross selection of groans, pops, and grinding noises from the worn-in hinge mechanism. CNET called off the test at 27k folds when the Foldbot was unable to close the phone. Apple says the average iPhone user unlocks the phone 80 times a day, while Statista puts heavier users at between 63 and 79 unlocks per day. If we apply that data to this Razr test, more active users would have hinge problems at around the one-year mark.

While CNET only gives us a sample size of one, there are other reports that the hinge mechanism leaves a lot to be desired. There are a few videos on Twitter now of the Moto Razr hinge squeaking and creaking right out of the box. The Razr only went on sale yesterday, but in-store demo units are already taking a beating, with other videos showing flickering displays and green lines running through the display.

Another potential problem is that the display isn’t attached to the phone around the perimeter, which could allow debris to get under the display and break it. The Galaxy Fold shipped with a plastic bezel around the perimeter of the display, covering the sides of the display as much as possible. The one spot Samsung couldn’t cover is the hinge area, and debris ingress around the hinge area ended up being one reason the device died an early death. After delaying the phone for a rework, Samsung added caps to the hinge area to try to cover the exposed sides of the display as much as possible. It doesn’t seem like Motorola learned from any of this, since the sides of the Razr display seem completely unprotected. Witness this gruesome BBC video where the screen can be picked up with just a fingernail.

Motorola isn’t helping matters much either, with an official video that claims “bumps and lumps are normal” in the flexible display.

So far, every flexible-display smartphone has seen some kind of durability issue. These are still first-generation devices with a lot of bugs to work out, and with sky-high prices (the Razr, at $1,500, is on the cheaper side!), anyone buying a folding smartphone is taking on a big risk.

Listing image by @JeremyDeBoseCom

Continue Reading

Gadgets

Apple‘s Tim Cook: Sideloading is “not in the best interests of the user”

Published

on

Enlarge / Apple CEO Tim Cook being interviewed remotely by Brut.

Apple has been under a mountain of scrutiny lately from legislators, developers, judges, and users. Amidst all that, CEO Tim Cook sat with publication Brut. to discuss Apple’s strategy and policies. The short but wide-ranging interview offered some insight into where Apple plans to go in the future.

As is so common when Tim Cook speaks publicly, privacy was a major focus. His response to a question about its importance was the same one we’ve heard from him many times: “we see it as a basic human right, a fundamental human right.” Noting Apple has been focused on privacy for a long time.

He explained:

You can think of a world where privacy is not important, and the surveillance economy takes over and it becomes a world where everyone is worried that somebody else is watching them, and so they begin to do less, they begin to think less, and nobody wants to live in a world where that freedom of expression narrows.

And when asked about regulatory scrutiny, he pointed to the GDPR as an example of regulation Apple supports and also said Apple would support further expanding privacy-related regulations.

But beyond regulations strictly centered on privacy, he wasn’t as effusive. “As I look at the tech regulations that’s being discussed, I think there are good parts of it and then I think there are parts of it that are not in the best interests of the user,” he said.

As an example of the latter, he said “the current DMA language that is being discussed would force sideloading on the iPhone.” He added:

That would destroy the security of the iPhone and a lot of the privacy initiatives that we’ve built into the App Store, where we have privacy nutrition labels and App Tracking Transparency… these things would not exist anymore.

Privacy watchdogs have praised Apple’s App Tracking Transparency move even as advertisers have lambasted it, but the nutrition labels have been less of a hit. Many observers have pointed out that the labels are often inaccurate or incomplete.

“Android has 47 times more malware than iOS does,” Cook claimed. “It’s because we’ve designed iOS in such a way that there’s one app store and all of the apps are reviewed prior to going on the store. And so that keeps a lot of this malware stuff out of our ecosystem, and customers have told us very continuously how much they value that, and so we’re going to be standing up for the user in the discussions.”

Tim Cook’s Brut. interview.

The interview wasn’t all about regulation and privacy, though; Cook also responded to open-ended questions about Apple’s future product strategy. When asked what he believes Apple’s products will look like many years from now, he carefully offered the caveat that no one can really predict where things are headed:

We approach the future with great humility because we know we can’t predict it. I’m not one of those people that is going to say I can see 20 years out, and 30 years out, and tell you what is going to happen. I can’t. I really don’t believe anyone can.

To back that point, he talked about Apple’s path towards putting its own silicon in Macs:

We didn’t know when we were working on the chip for the iPhone that it would become the heart of the iPad, and we didn’t know that it would eventually become the heart of the Mac as it just did in this past year. We didn’t know that, but we kept discovering, and we kept pulling the string, and we kept our minds open about where that journey would take us, and it’s taken us somewhere that’s incredible and that has a great future ahead of it.

That said, Cook named augmented reality (AR) and the intersection of health and tech as areas where he sees future potential. He said he sees AR “as a technology that can enhance life in a broad way.” And once again hinting at ambitions plans for future AR hardware, he said: “We’ve been working on AR first with our phones and iPads, and later we’ll see where that goes in terms of products.”

On the health side, Cook said he is “exceedingly optimistic” about the intersection of health and technology:

You know, when we started shipping the Watch, we did so thinking about it from a wellness point of view, but we put a heart rate sensor on it, and I was getting tons of emails about people that found out they had heart problems that they didn’t know about it. And so we started adding more function to the Watch… and I begin to get even more notes from people that found that they’d had a problem because of this ability to continually monitor themselves. I think the idea of continually monitoring the body, much like happens in your car with warning lights and so forth, I think this is a big idea that has a long road path ahead of it. All of those things make me incredibly optimistic.

The mention of a car as inspiration drew a smirk from Brut.’s interviewer, who shortly afterwards asked if Apple plans to design and begin selling a car. “In terms of a car,” Cook answered, “I’ve gotta keep secrets, and there always has to be something up our sleeve.”

Continue Reading

Gadgets

Tired of accepting/rejecting cookies? ADPC wants to automate the process

Published

on

The European Union’s General Data Protection Regulation (GDPR), passed in 2018, requires websites to ask visitors for consent prior to placing cookies. As any Internet user is now aware, this means an extra step required when visiting nearly any website for the first time—or potentially every time, if you choose not to accept cookies. A new proposed HTTP standard from None of Your Business and the Sustainable Computing Lab would allow the user to set their privacy preferences once, inside the browser itself, and have the browser communicate those preferences invisibly with any website the user visits.

Advanced Data Protection Control

The proposed standard enables two methods of automated preference delivery—one which communicates directly with the web server hosting a site being visited, and another which communicates with the website itself.

When ADPC communicates directly with the web server, it does so via HTTP headers—a Link header pointing to a JSON file on the server, and the ADPC header emitted by the user’s browser. When communicating with the website itself, the mechanism is via JavaScript— configuration is passed as an object to the DOM interface, e.g., navigator.dataProtectionControl.request(...).

In either case, the user’s privacy preferences are communicated to the website or server as a list of request identifiers they consent to. This list is sent in ADPC headers for the HTTP-based approach and as the final return value of the DOM interface in the JavaScript approach.

Although both mechanisms accomplish the same goal in similar fashions, there are plenty of reasons to support both. The HTTP-based approach is probably more efficient—but it obviously would require new versions of web server applications which explicitly support it (or at least, new pluggable modules in the case of servers like Apache which support them). Meanwhile, the JavaScript-based mechanism works without any special web server configuration necessary—but it won’t work for users who refuse to enable JavaScript.

Consent requests resource

A JSON file is at the heart of the website’s end of ADPC, whether using HTTP or Javascript mechanisms to reach it. That consent file will look something like this:

{
  "consentRequests": {
    "cookies": "Store and/or access cookies on your device.",
    "ads_profiling": "Create a personalised ads profile."
  }
}

In HTTP-based ADPC, the webserver links to the consent file directly in its response to an HTTP GET:

HTTP/1.1 200 OK
Link: </consent-request-resource.json>; rel="consent-requests"

When the web browser detects this link, it can either respond with previously user-configured settings or request an answer from the user via a pop-up dialog (most likely, one spawned from the browser’s lock button). Once the user has set their preferences accordingly, the browser includes an ADPC header on future HTTP GET requests:

GET /page.htm HTTP/1.1
Host: website.tld
ADPC: withdraw=*, consent=cookies

In the above example, we see a configuration similar to what one might see on a network firewall: a default DENY in the form of withdraw=*, overridden by a specific acceptance of cookies. So for our website which wanted both to set cookies and create an advertising profile, the cookie request is granted (allowing storage of, e.g., user authentication and personal settings), but advertising profile is denied.

Another benefit of the ADPC scheme is that the user is interacting with their own browser, with consistent UI regardless of website. Another benefit is that it’s possible for the user to set persistent preferences for a site without needing to allow cookies—something which isn’t possible for a website which must ask for consent via a banner embedded in the webpage itself.

Finally, cookie banners may frequently not be displayed at all—in our testing, popular ad-blocking plugins blocked the display of many cookie banners, including but not limited to The Guardian’s. Such blocking can be due to collateral damage caused by overly aggressive block rules or deliberate attempts to minimize “click fatigue.” In either case, they prevent the user from directly expressing consent or refusal to privacy-related issues.

Request, not command

It’s important to realize that ADPC is not a mechanism for enforcing a user’s privacy profile—it’s simply a normalized way of requesting it in compliance with the European Union’s GDPR and similar privacy laws elsewhere.

Nothing technically prevents a hypothetical ADPC-compliant website from requesting permission to create an advertising profile for a user, being denied, and then creating that profile anyway. But legitimate sites can request consent in a more machine-readable, consistent, and less user-fatiguing way.

ADPC does still assist users in dealing with shady sites that ignore their users’ preferences—in the event of a GDPR or other lawsuit, users’ preferences are more likely to be logged and readable from their own systems. If a user refuses to accept any cookies via a cookie banner, their expressed preference cannot be saved and logged—but ADPC preferences will be.

Even if a user interacting with a cookie banner accepts cookies (but disables ad profiling), that cookie is much more likely to be mistakenly “cleaned” by the user themselves. That “cleaning” could be in the quest to maintain privacy or even fix problems with frequently visited websites. Since ADPC preferences are only good for that one thing—expressing or refusing consent on privacy issues—there is much less reason for them to be destroyed.

Listing image by Jim Salter

Continue Reading

Gadgets

Google enables end-to-end encryption for Android’s default SMS/RCS app

Published

on

Enlarge / If you and your chatting partner are both on Google Messages and both have RCS enabled, you’ll see these lock icons to show that encryption is on.

Google

Google has announced that end-to-end encryption is rolling out to users of Google Messages, Android’s default SMS and RCS app. The feature has been in testing for months, and now it’s coming to everyone.

Encryption in Google Messages works only if both users are on the service. Both users must also be in a 1:1 chat (no group chats allowed), and they both must have RCS turned on. RCS was supposed to be a replacement for SMS—an on-by-default, carrier-driven text messaging standard. RCS was cooked up in 2008, and it adds 2008-level features to carrier messaging, like user presence, typing status, read receipts, and location sharing.

Text messaging used to be a cash cow for carriers, but with the advent of unlimited texting and the commoditization of carrier messaging, there’s no clear revenue motivation for carriers to release RCS. The result is that the RCS rollout has amounted to nothing but false promises and delays. The carriers nixed a joint venture called the “Cross-Carrier Messaging Initiative” in April, pretty much killing any hopes that RCS will ever hit SMS-like ubiquity. Apple executives have also indicated internally that they view easy messaging with Android as a threat to iOS ecosystem lock-in, so it would take a significant change of heart for Apple to support RCS.

The result is that Google is the biggest player that cares about RCS, and in 2019, the company started pushing its own carrier-independent RCS system. Users can dig into the Google Messages app settings and turn on “Chat features,” which refers to Google’s version of RCS. It works if both users have turned on the checkbox, but again, the original goal of a ubiquitous SMS replacement seems to have been lost. This makes Google RCS a bit like any other over-the-top messaging service—but tied to the slow and out-of-date RCS protocol. For instance, end-to-end encryption isn’t part of the RCS spec. Since it’s something Google is adding on top of RCS and it’s done in software, both users need to be on Google Messages. Other clients aren’t supported.

Google released a whitepaper detailing the feature’s implementation, and there aren’t too many surprises. The company uses the Signal protocol for encryption, just like Signal, Whatsapp, and Facebook Messenger. The Google Messages web app works fine since it still relies on an (encrypted) local connection to your phone to send messages. Encrypted messages on Wear OS are not supported yet but will be at some point (hopefully in time for that big revamp). Even though the message text is encrypted, third parties can still see metadata like sent and received phone numbers, timestamps, and approximate message sizes.

If you and your messaging partner have all the settings right, you’ll see lock icons next to the send button and the “message sent” status.

Continue Reading

Trending