Connect with us

Gadgets

Next Apple Watch could include new ceramic and titanium models – TechCrunch

Published

on

Apple’s next Apple Watch revision could include new materials for the case, including titanium and ceramic. That’s according to new assets pulled form the latest watchOS beta release, as uncovered by Brazilian site iHelp.br (via 9to5Mac). The new screens discovered in the beta show graphics used to pair the Apple Watch during setup, and list “Titanium Case” and “Ceramic Case” alongside model size identification info.

Apple has previously offered a ceramic Apple Watch, alongside its Series 2 and Series 3 models, with a premium price and white and black case options. The company hasn’t previously used titanium, but the lightweight, durable metal is popular among traditional watchmakers because it can really significantly reduce the heft of a watch case, while still providing a premium look and feel.

Last year’s Apple Watch Series 4 was the first significant change in body design for the wearable since its introduction in 2015, so it seems unlikely that Apple will change that this year again. The new physical design includes larger case sizes (40mm and 44mm, respectively, vs. 38mm and 42mm for previous generations), a thinner profile and a display with rounded corners and slimmer bezels.

Offering new materials is a way for Apple to deliver new hardware that is observably new on the outside, in addition to whatever processor and component improvements they make on the inside. Apple will likely also offer these alongside their stainless steel and aluminum models, should they actually be released this fall, and would probably charge a premium for these material options, too.

The Series 4 Apple Watch proved a serious improvement in terms of performance, and added features like the onboard ECG. Splashy new looks likely won’t be the extent of what Apple has planned for Series 5, however, especially since the company is revamping watchOS to be much more independent of the phone, which would benefit from more capable processors.

Source link



Source link

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

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